Perhaps the next generation data specification for WebGIS - OGC API series

1 Introduction

1.1. Classical OGC Standard Review

To this day, GeoServer is still in play, and several major service standards of WebGIS are still applied:

• WMS , web map service
• WMTS , network tile map service
• WFS , Network Feature Service

These three should be familiar, and there are others that will not be listed. The focus of this article is not to introduce these current standards. For a quick check of the above three standards, please refer to my previous articles.

1.2. Common Features and Times Changes

Existing standards share some common features. For example, the request behavior is more dependent on XML - the reason is that in the era before the "big front-end" was popular, the back-end often used XML, and the front-end could only use the browser API to parse the returned XML. For example, the transaction operation (Transaction, generally called WFS-T) of the modification element of WFS, the XML written in the request body is written in JavaScript, which is relatively boring and tedious.

Now, the front-end and back-end functions are separated, and the front-end development is obvious to all. In map development, most of the time, the front-end wants to send and get JSON, which is easier to parse by the JS engine, rather than XML.

The set of OGC APIs to be introduced today is what the OGC organization has been working on 2 years ago. They changed the original OGC official website domain name and LOGO, and even created a new one for this set of APIs. website.

1.3. Disclaimer

This article was written in July 2022. This API has not yet been fully implemented. This article is only used as a guide, not a guide. Everything is subject to the reader's time point. I introduce this API only for this impetuous atmosphere. The industry brings some news. After all, OGC's official website is so big, and I can't find an article in China, even if it is a brief introduction.

This article only reserves the copyright and the right of interpretation, and you are welcome to reprint it by name.

2. What is OGC API

2.1. The OGC API is an open, dynamic family of specifications

The OGC API currently has 13 subclasses (with a public definition), up from 9 last year. As long as it conforms to the OGC API public definition, the network request interface specification can be formulated for the emerging data requirements in the industry.

Some of the APIs described in this article may disappear in the future, or they may be added. All are subject to the officially released version you see.

2.2. OGC API Features

The most notable features can be summarized as:

• The interface style is REST
• Data transfer defaults to JSON format

2.3. Public API Brief (July 2022)

First, give an official website: OGC API

The OGC API came into being in response to the rapid development of front-end technology in the past decade. The biggest difference between it and the above-mentioned old standards is:

• Use REST style
• Exchange data to use JSON by default

This series of API standards has also upgraded the original major service standards and supplemented the needs of other fields.

For example, WFS 3.0 standard is directly changed to OGC Feature API , WMS is upgraded to OGC Map API

New API	Current OGC Web Services Standards	state
OGC Features API	WFS	Published Part 1/2, a total of 4 Parts
OGC Maps API	WMS	Drafting, preview available
OGC Tiles API	WMTS	Drafting, preview available
OGC Processes API	WPS	Released 1.0, a total of 1 Part
OGC Coverages API	WCS	Drafting, preview available

Some friends may not be familiar with the latter two, Processes API the task API. The biggest feature is that it allows you to initiate a data processing task to the interface. The old standard is WPS. The release of this API is done at the interface level. Unified; Coverages API (ie WCS) may be oriented to remote sensing applications, this API is more interested in the band information of raster data, raster pixels and other data.

In addition to upgrades and renovations, other standards have also been supplemented and improved:

Added API	use	state
OGC Common API	Public Definition of OGC API	Part 1/2 is being drafted, preview available
OGC EDR API	Environment data, much like the Features API	Released 1.0, a total of 1 Part
OGC Records API	The data of the query data, that is, the metadata, is generally used in conjunction with the Features API	Part 1 is being drafted, preview available
OGC Styles API	A style interface that can be used for data that needs to be rendered	Part 1 is being drafted, preview available
OGC DGGS API	An interface to access grid data	Drafting, preview available
OGC Routes API	Routing data interface, the most direct application is network analysis	Part 1 is being drafted, preview available
OGC Joins API	Provides an interface for connecting operations to spatial data	Drafting, preview available
OGC MovingFeatures API	Temporal Dependent Feature Data Interface, an extended version of the Features API	Drafting, preview available
OGC 3DGeoVolumes API	3D volume data interface, which is expected to unify access to 3D data formats such as 3DTiles and I3S	Drafting, preview available

These APIs are more unfamiliar than the previous 5, so I will explain more:

• OGC EDR API - Environmental data, the result of its query does not seem to be "spatial elements", but various environmental data combined with spatial information, such as wind speed, air temperature, humidity, somatosensory temperature, etc.; coordinates are allowed , radius, range, positioning name and other parameters to query environmental data, the application in meteorological and marine fields may be wider, and it should be closely related to multi-dimensional data formats such as NetCDF
• OGC Records API - Slightly overlaps with Feature API in design, URLs will overlap when used, but the focus of query filtering may be different. Feature API queries focus on spatial analysis filtering , and this The API focuses more on attribute filtering of descriptive properties, that is, non-spatial analytical filtering , such as title , externalIds , etc.; because the spatial filtering section specification of the Features API has not been released, and the Records The API specification has not been officially released, and there are few examples that can be experienced, so everything is subject to the official
• OGC DGGS API - DGGS, i.e. Discrete Global Grid Systems , which uses a more general grid than a quadtree to divide the Earth sphere, there are some studies done on this particular grid geometry, It is generally used with the Features API and the Processes API. After all, grids are also a special element; however, the design of the API is more inclined to these "grids", which are implemented statically.
• OGC Routes API - A specification similar to pgRouting, which is unified at the data interface level. You can use it to query routing (understood as a path with a destination and a direction), and it returns vector elements, or you can Call the supporting Processes API for network analysis (shortest path, etc.), this API is relatively hard-core, usually the implementation of the server is relatively heavy
• OGC Joins API - Spatial connection, so that the existing feature data and the newly provided data can be connected. Those who are familiar with the back-end database, ArcGIS attribute table connection and other related operations should be able to roughly guess what this API does. , is a behavioral API, used together with the Features API, but the current process of this API is relatively slow, and there is no specific implementation
• OGC MovingFeatures API - is a time-related vector feature API, used together with the Features API, and has not yet been implemented. I think this is also an API that tests the organization ability of the back-end database
• OGC 3DGeoVolumes API - The purpose is very simple, to unify the 3D data standards of various companies, there is not much content at present, but it is a good start; I think at least a few existing standards can be merged together. It is difficult to achieve. It will be a very long process to unify the major 3D data specifications at the API level; at present, most of the community cases are simple 3DTiles, which can only be accessed through the REST interface tileset.json The JSON content of the file; the goal of this API is very large, and it is hoped that glTF, 3DTiles, I3S, CityGML/CityJSON, etc. have the format of entity data content together, and spatially aggregate through the concept of 3DGeoVolumes Together, unify at the API level instead of re-proposing a data specification
• OGC Styles API is easier to understand, standardizes the interface for adding, deleting, modifying and checking various style information, which can be used for the rendering of tiles and vector elements; the style types include but are not limited to SLD, MapboxStyle, etc.

3. Can I use the OGC API?

3.1. Implementation of each API (official statistics)

Each API basically has an independent warehouse on GitHub. Each warehouse basically records the software implementation of the current API, including server software, front-end library, development library, etc. After I check one by one, there will be records. The API implementation record documents are listed as follows:

• List of OGC Feature API implementations
• List of OGC Tiles API implementations
• The OGC Maps API implementation list has not been updated yet, but GeoServer has implemented some drafts
• OGC 3DGeoVolumes API Implementation List When this article is published, there is only a simple 3DTiles static file service, I have not seen I3S
• OGC Coverages API Implementation List
• List of OGC Processes API implementations
• OGC Records API Implementation List
• OGC Joins API Implementation List This API is not yet implemented at the time of publication
• OGC Routes API Implementation List
• OGC Styles API Implementation List

The rest have not yet been found (it is also possible that the OGC has not made its repositories public yet).

Please note that the validity of these links is not guaranteed because the OGC API is still in the development process. Please visit the corresponding GitHub repository by yourself.

3.2. Implementation of front-end map library

Introduce several well-known JavaScript library implementations.

① ArcGIS API for JavaScript

Only V4 supports OGC Feature API, use OGCFeatuerLayer .

② OpenLayers6

Currently only the OGC Tiles API is supported.

• For raster tiles, use ol/source/OGCMapTile and ol/layer/Tile to achieve
• For vector tiles (MVT format), use ol/source/OGCVectorTile and ol/layer/VectorTile to achieve

But please note that because the OGC API is still unstable, there is still no documentation for the related classes, but you can find examples by searching for OGC in the official Examples.

③ LeafletJS

OGC Map API is supported using extension: GitLab - Leaflet.ImageOverlay.OGCAPI

3.3. Implementation of GeoServer

Please refer to the stable version document / latest version document . Simply put, GeoServer has implemented Tiles, Coverages, DGGS, Features, and Images in the latest version 2.21 (this is the API in the request, it has not been recorded on the official website, it can be more Reflecting that the OGC API is an open specification family), Styles, Maps APIs.

3.4. Development library support

• TypeScript - haoliangyu/ogcapi-js
• JavaScript - koopjs/provider-ogcapi-features
• Python - geopython/pygeoapi
• C# - sam-is/OgcApi.Net
• Rust - camptocamp/ogcapi
• Golang - WouterVisscher/ogcapi

For more resources, please search on GitHub.

4. Try GeoServer's OGC API

Currently, only community expansion packages with OGC API are seen in versions above 2.18.

https://build.geoserver.org/geoserver/

Unzip the corresponding version of the community extension package to the WEB-INF/libs/ directory (to choose to replace), restart GeoServer, and you can see the supported APIs on the right side of the home page

Click the version number of the API you want to enter, and you can see the corresponding API on the interface.

4.1. Known bugs

After installing the OGC API, GeoServer's WMTS will fail for unknown reasons. Do not experiment on production environments and personal GeoServers with important data! ! !

4.2. Try the OGC Maps API

After installing the OGC API plugin, directly access the following URL in your browser (pay attention to your port, data parameters, etc.):

 http://localhost:4800/geoserver/ogc/maps
/collections/spatial_base:guangxi_cities
/styles/polygon
/map
?transparent=true
&f=image%2Fpng
&layers=spatial_base%3Aguangxi_cities
&styles=polygon
&crs=EPSG%3A4326
&width=768
&height=553
&bbox=104.04052734375%2C20.6048583984375%2C112.47802734375%2C26.6802978515625

It returns almost the same result as WMS GetMap :

In addition, the OGC Map API also has other operations, which can be found on the API experience page:

https://developer.ogc.org/api/maps/index.html (local Swagger has not been integrated on GeoServer version 2.21 for local testing, otherwise visit http://localhost:4800/geoserver/ogc/maps/api You can test it locally, and the rest of the APIs should be tested by readers)

4.3. Try the OGC Tiles API

The template for the Tiles API is as follows:

 http://localhost:4800/geoserver/ogc/tiles
/collections/{layerName}
/styles/{style}
/map/tiles
/{tileMatrixSet}/{tileMatrix}/{tileRow}/{tileCol}?f={ImageMIMEType}

So, make a tile request:

 http://localhost:4800/geoserver/ogc/tiles
/collections/spatial_base:guangxi_cities
/styles/polygon
/map/tiles
/EPSG:900913/EPSG:900913:7/55/103?f=image/png

The resulting tiles are:

Compare WMTS's REST-style URLs:

 http://localhost:4800/geoserver/gwc/service/wmts/rest
/spatial_base:guangxi_cities
/polygon
/EPSG:900913/EPSG:900913:7/55/103?format=image/png

The style is similar and the upgrade cost is lower.

4.4. Try the OGC Features API

 http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items
&limit=5

check only one

 http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items/guangxi_cities.1

or

 http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items/1

Query a single returned result:

 {
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "guangxi_cities.1",
      "geometry": {/* ... */},
      "geometry_name": "geom",
      "properties": {/* ... */}
    }
  ],
  "numberMatched": 1,
  "numberReturned": 1,
  "timeStamp": "2022-07-18T16:48:12.381Z",
  "links": [/* ... */]
}

Compared with the key-value pair form of WFS, it is not too convenient. I think the Features API is a very good upgrade.

As for the third part of the Features API: spatial filtering, and the fourth part of adding, deleting, modifying and checking (corresponding to Transaction in WFS), we have to wait for the draft to be stabilized and the implementation of major communities.

4.5. Try the OGC Styles API

You can directly use the API request tool to access the Styles API provided by GeoServer on your local machine, similar to:

 http://localhost:4800/geoserver/ogc/styles
/styles

This double styles may be a little confusing, that is /styles/styles , in fact, the latter one styles is the GeoServer default style set, and its name is "styles". This query returns all styles in the style set named "styles" on GeoServer.

As we all know, the built-in style of GeoServer is ugly. Take the built-in polygon style as an example:

It's actually a very simple SLD definition:

 <?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0" 
 xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd" 
 xmlns="http://www.opengis.net/sld" 
 xmlns:ogc="http://www.opengis.net/ogc" 
 xmlns:xlink="http://www.w3.org/1999/xlink" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- a Named Layer is the basic building block of an SLD document -->
  <NamedLayer>
    <Name>default_polygon</Name>
    <UserStyle>
    <!-- Styles can have names, titles and abstracts -->
      <Title>Default Polygon</Title>
      <Abstract>A sample style that draws a polygon</Abstract>
      <!-- FeatureTypeStyles describe how to render different features -->
      <!-- A FeatureTypeStyle for rendering polygons -->
      <FeatureTypeStyle>
        <Rule>
          <Name>rule1</Name>
          <Title>Gray Polygon with Black Outline</Title>
          <Abstract>A polygon with a gray fill and a 1 pixel black outline</Abstract>
          <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill">#AAAAAA</CssParameter>
            </Fill>
            <Stroke>
              <CssParameter name="stroke">#000000</CssParameter>
              <CssParameter name="stroke-width">1</CssParameter>
            </Stroke>
          </PolygonSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

SLD is actually a kind of XML, there is a specification. For the above SLD, you can request it like this:

 http://localhost:4800/geoserver/ogc/styles
/styles/polygon

The style API is actually a relatively simple one, including its additions, deletions, changes, and checks, so far.

5. Summary

OGC API general, all walks of life and all aspects are basically considered, and they are very focused on discussing "geospace", even from a partial research field DGGS API and EDR API is still seriously writing technical specifications, participating in discussions, implementing OpenAPI examples, and actively merging with existing technologies or directly providing simple cases of implementation, rather than domestic illusory concepts.

Howling, what is the industry doing? Sand hard to form a tower...

In fact, for developers, the function of API is to request, OGC API is a constraint for developers or callers, most map libraries do not need to fully support all OGC API , for example Feature API don't need -- just like WFS in CesiumJS/MapboxGL, you need vector feature data, you also know there is a data source of Features API You just request the vector data according to the specification. Moreover, or subject to the technical level, or subject to the scope of business, some interfaces may be completely unnecessary or impossible to implement in the application process, such as Joins API , Routes API , etc., only Can wait for the community to give the packaging results.

I think the client may need to access Tile API or Map API , after all, the maps and tiles provided by the front-end native support or extended support services are like a map library.

And like Routes API , Joins API , MovingFeatures API these have relatively high requirements on the back-end database and algorithm program, you need to weigh them. Is it waiting to use the results of others, or bite the bullet and realize it yourself.

But having said that, the basic parts of a few APIs have only been officially announced in 2020. Waiting for this set of APIs to be fully released and implemented, I think that friends who rely on this industry for food, if they do not have the power to leverage the entire domestic market, they will still be It is good to be honest and practical with the existing results, but the scientific research team has more time to follow up and understand.