geostandards-INDG20-60

The OGC API approach allows for modularity and "profiling" of APIs depending on your requirements. This means you can mix and match OGC APIs together.

You can read more about this topic in the building blocks website.

The OGC Web Feature Service (WFS) Interface Standard defines a set of interfaces for accessing geographic information at the feature and feature property level over the Internet. A feature is an abstraction of real world phenomena, that is it is a representation of anything that can be found in the world. The attributes or characteristics of a geographic feature are referred to as feature properties. WFS offer the means to retrieve or query geographic features in a manner independent of the underlying data stores they publish. Where a WFS is authorized to do so, the service can also update or delete geographic features. An instance of a WFS is also able to store queries in order to enable client applications to retrieve or execute the queries at a later point in time.

Source : Open Geospatial Consortium

The WFS standard is currently mentioned in the following sections:

3.4, 5, 6.4, 6.6 (QUAL-03), 6.9, 6.9.2 (WFS-01,WFS-02,WFS-03,WFS-04,WFS-05,WFS-06,WFS-07,WFS-08,WFS-09,WFS-10,WFS-11,WFS-12), 6.11, appendix B (Mapping: WFS metadata elements → GM03, Mapping: mandatory GM03 metadata elements → WMS, WMTS, WFS, WCS et CSW) & E

of the eCH-0056 document.

OGC API - Features is a multi-part standard that offers the capability to create, modify, and query spatial data on the Web and specifies requirements and recommendations for APIs that want to follow a standard way of sharing feature data. The Core part of the standard is called OGC API - Features - Part 1: Core. The Core part of the specification describes the mandatory capabilities that every implementing service has to support and is restricted to read-access to spatial data. Additional capabilities that address specific needs will be specified in additional parts. Envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, richer queries, and additional coordinate reference systems.

Source : Open Geospatial Consortium

The OGC API - Features standard is not mentioned in the eCH-0056 document.

The OGC Web Coverage Service (WCS) supports electronic retrieval of geospatial data as “coverages.” Coverages are digital geospatial information representing space/time-varying phenomena, specifically spatio-temporal regular and irregular grids, point clouds, and general meshes. WCS offer the means to retrieve or query geographic coverages in a manner independent of the format in which the data is stored.

Source: Open Gepspatial Consortium

The Web Coverage Service (WCS) standard is currently mentioned in the following sections:

5, 6.4, 6.9, 6.9.3 (WCS-01,WCS-02,WCS-03,WCS-04,WCS-05,WCS-06), appendix A (Mapping: WCS metadata elements → GM03, Mapping: mandatory GM03 metadata elements → WMS, WMTS, WFS, WCS et CSW) & E

of the eCH-0056 document.

The OGC API - Coverages draft specification defines a Web API for accessing coverages that are modeled according to the Coverage Implementation Schema (CIS) 1.1. Coverages are represented by some binary or ASCII serialization, specified by some data (en­coding) format. Arguably the most popular type of coverage is that of a gridded coverage. Gridded coverages have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid. Satellite imagery is typically modeled as a gridded coverage, for example.

The OGC API - Coverages standard is not mentioned in the eCH-0056 document.

Not applicable as it is not yet a valid standard.

OGC API - Environmental Data Retrieval is a standard that provides a family of lightweight interfaces to access Environmental Data resources. The standard, which is also called the Environmental Data Retrieval (EDR) API, addresses two fundamental operations; discovery and query. Discovery operations allow the API to be interrogated to determine its capabilities and retrieve information (metadata) about this distribution of a resource. This includes the API definition of the server as well as metadata about the Environmental Data resources provided by the server. Query operations allow Environmental Data resources to be retrieved from the underlying data store based upon simple selection criteria, defined by this standard and selected by the client.

Source: Open Gepspatial Consortium

Table 1 summarizes the access paths and relation types defined in this standard.

Where:

The OGC API - Environmental Data Retrieval standard is not mentioned in the eCH-0056 document.

The Sensor Observation Service (SOS) defines a web service interface that allows retrieval of observations, sensor metadata and representations of the features from which the observations are taken. The service interface also allows publishing of new observations, as well as registration and removal of sensors.

The Sensor Observation Service (SOS) standard is currently mentioned in the following sections:

5, 6.14 and the appendix E

of the eCH-0056 document.

Add a new section to the eCH-0056 document about the Sensor Observation Service (SOS) standard.

The Internet of Things (IoT) is a global information infrastructure that enables advanced services by interconnecting both physical and virtual “things” based on existing and evolving interoperable information and communication technologies [ITU-T]. To facilitate geospatial interoperability between devices in the IoT, the OGC has published the OGC SensorThings API.

The OGC SensorThings API is a multi-part standard for an open and geospatial-enabled approach for interconnecting devices, data, and applications of the Internet of Things (IoT). The first part of the standard describes the interface for Sensing. The second part describes the interface for Tasking. The Sensing part standardizes the management and retrieval of observations and metadata from heterogeneous IoT sensor systems. The Tasking part, which is to be developed in the future, is expected to provide a standard way for parameterizing - also called tasking - of IoT devices that can be instructed to carry out observations or perform other functions.

Source: Open Geospatial Consortium

The OGC SensorThings API standard is not mentioned in the eCH-0056 document.

The OGC Web Processing Service (WPS) Interface Standard specifies a standard interface that provides access to pre-defined processes and provides job control operations that can instantiate, control and monitor processing jobs. In this context, the term process refers to any algorithm, calculation or model that either generates new data or transforms some input data into output data. A WPS enables the execution of computing processes that typically combine raster, vector, and/or coverage data to produce new raster, vector, and/or coverage data. The inputs, processes and outputs offered by a WPS can also be non-spatial.

Source : Open Geospatial Consortium

The Web Processing Service (WPS) standard is not mentioned in the eCH-0056 document.

If WPS should be included in the eCH-0056 document, it would be interesting to use the (more recent) OGC API Processes. The issue will be addressed in the workshops dedicated to the eCH-0056 revision.

The OGC API — Processes standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application. The standard specifies a processing interface to communicate over a RESTful protocol using JavaScript Object Notation (JSON) encodings. The standard leverages concepts from the OGC Web Processing Service (WPS) 2.0 Interface Standard but does not require implementation of a WPS. The Core part of the standard is called OGC API - Processes - Part 1: Core. The Core part of the standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application either synchronously or asynchronously. Examples of computational processes that can be supported by implementations of this specification include raster algebra, geometry buffering, constructive area geometry, routing, imagery analysis and several others.

Source : Open Geospatial Consortium

The OGC API - Processes standard is not mentioned in the eCH-0056 document.

The OGC Web Map Service Interface Standard (WMS) defines a set of interfaces for requesting map images over the Internet. WMS makes it easy for a client to request images on demand changing parameters such as size and coordinate reference systems. A WMS server (i.e. a service that implements the WMS standard) provides information about what maps the service provides, and it produces a map and answers queries about content the content of a map.

Source : Open Geospatial Consortium

The Web Map Service (WMS) standard is currently mentioned in the following sections:

3.4, 5, 3.7, 6.3, 6.6 (QUAL-02), 6.7 (WMS-01,WMS-02,WMS-03,WMS-04,WMS-05,WMS-06,WMS-07,WMS-08,WMS-09,WMS-10), 6.11, 6.12, appendix B (Mapping: WMS metadata elements → GM03, Mapping: mandatory GM03 metadata elements → WMS, WMTS, WFS, WCS et CSW) & E

of the eCH-0056 document.

Nothing to mention.

The OGC API Maps specification defines a set of interfaces for requesting map images over the Internet. OGC API Maps makes it easy for a client to request images on demand changing parameters such as size and coordinate reference systems. A OGC API Maps server (i.e. a service that implements the OGC API Maps standard) provides information about what maps the service provides, and it produces a map and answers queries about content the content of a map.

The OGC API Maps standard is not mentioned in the eCH-0056 document.

The OGC API Maps standard has not yet been validated by the OGC. It is therefore difficult to take a position on its integration into the eCH-0056 document.

The OGC Web Map Tile Service Implementation Standard (WMTS) defines a set of interfaces for making web-based requests of map tiles of spatially referenced data using tile images with predefined content, extent, and resolution. The standard includes the WMTS Specification (“WMTS Spec”) 07-057r7 OpenGIS Web Map Tile Service Implementation Standard along with collateral documentation such as profiles and XML documents.

The Web Map Tile Service (WMTS) standard is currently mentioned in the following sections:

2, 3.4, 6.4, 6.8 (WMTS-01,WMTS-02,WMTS-03,WMTS-04,WMTS-05,WMTS-06,WMTS-07,WMTS-08) appendix B (Mapping: WMTS metadata elements → GM03, Mapping: mandatory GM03 metadata elements → WMS, WMTS, WFS, WCS et CSW) & E of the eCH-0056 document.

Add joint references to OGC API Tiles in eCH-0056 document.

The OGC API Tiles specification defines a set of interfaces for requesting map tiles over the Internet. OGC API Tiles makes it easy for a client to request tiles on demand changing parameters such as size and coordinate reference systems. A OGC API Tiles server (i.e. a service that implements the OGC API Tiles standard) provides information about what tiles the service provides, and it produces a tile and answers queries about content the content of a tile. The OGC API Tiles allows to access the same data as the Web Map Tile Service (WMTS) standard, but with a different API and could includes both vector and raster data.

The OGC API Tiles is intended to be used in conjunction with the following OGC standards:

The OGC API Tiles standard is not part of the current version of the eCH-0056 document.

The OGC API Tiles standard should be introduced in the eCH-0056 document alongside with the WMTS specification. Recommendations on its combination with other standards should also be proposed once these have been validated.

Geospatial data (vector and raster) have no intrinsic visual component. In order to see data, it must be styled. Styling specifies color, thickness, and other visible attributes used to render data on a map. A WMS provides a set of style options for each data set; however these are preconfigured by the server, and the user cannot create, inspect, modify a style. The Styled Layer Descriptor (SLD) is a standard that enables an application to configure in an XML document how to properly portray layers and legends in a WMS. It uses Symbology Ending (SE) to specify styling of features and coverages. The SLD Profile of WMS enhances a WMS with additional operations to support styling of features from WFS and coverages from WCS.

Source : Open Geospatial Consortium

Not applicable.

The Styled Layer Descriptor (SLD) standard is currently mentioned in the following sections: 6.7 (WMS-09), 6.12 (SLD-01) & appendix E of the eCH-056 document.

As an encoding, SLD should not be integrated in a separate section but combined with other standards (e.g. WMS).

Geospatial data (vector and raster) have no intrinsic visual component. In order to see data, it must be styled. Styling specifies color, thickness, and other visible attributes used to render data on a map. The Symbology Encoding (SE) standard defines the language to formally encode the rules of how to portray features and coverages.

Source : Open Geospatial Consortium

The Symbology Encoding (SE) standard is currently mentioned in the sections 6.11 the eCH-056 document.

The Symbology Encoding (SE) standard should be kept in the eCH-056 document alongside with the OGC Symbology Conceptual Model standard.

The OGC API - Styles draft specification defines a Web API that enables map servers, clients as well as visual style editors, to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine on features and/or coverages. The API implements the conceptual model for style encodings and style metadata.

The API building blocks support the resources and operations listed in the table below with the associated conformance class and the link to the document section that specifies the requirements.

The baseResource is a path template for any API resource with which styles can be associated.

The OGC API Styles standard is not mentioned in the eCH-0056 document.

The OGC API Styles standard has not yet been validated by OGC. It is therefore difficult to take a position on its integration into the eCH-0056 document.

The Symbology Conceptual Model is a new approach:

Although not applicable here, it is important to mention that the standard is divided into different classes such as:

The OGC Symbology Conceptual Model: Core Part standard is not mentioned in the eCH-0056 document.

Catalogue services support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community.

Source : Open Geospatial Consortium

The CSW standard is currently mentioned in the following sections:

3.4, 6.10 (CSW-01, CSW-02, CSW-03), appendix A, & appendix B

of the eCH-0056 document.

Refer to version 3.0 of the specification.

OGC API - Records is a new OGC API standard that provides a simple and consistent way to publish and access descriptive information about geospatial resources. It is based on the OGC API - Features standard and uses the same core concepts of resources, collections, and items. The OGC API - Records standard defines a core set of functionality that can be extended by additional functionality defined in separate standards.

The OGC API - Records standard is not mentioned in the eCH-0056 document.

As this is not yet an OGC standard, we cannot make any recommendations for the eCH-0056 document.

The Spatio Temporal Asset Catalog (STAC) specification is a common language to describe geospatial information, so it can more easily be worked with, indexed, and discovered. At its core, the SpatioTemporal Asset Catalog (STAC) specification provides a common structure for describing and cataloging spatiotemporal assets.

STAC is not mentioned in the eCH-0056 document.

It is suggested to integrate STAC into the eCH-0056 document to replace AtomFeeds.

Major Swiss authoritative national offices that manage monitoring network for environmental data are: (1) MeteoSwiss, the national meteorological office that collects weather information from the SwissMetNet that comprises about 160 automatic monitoring stations observing weather and climate variables and about 100 automatic precipitation stations :cite[suter2006swissmetnet]; (2) Federal Office for the Environment (FOEN) that use the hydrometric monitoring network composed by about 260 stations observing surface water levels and discharges :cite[schwanbeck2018reti]; and (3) Swiss Federal Institute for Forest, Snow and Landscape Research (SLF) that manage the IMIS (Intercantonal Measuring and Information System) network comprising 186 stations measuring snow, wind and other avalanche specific parameters. At the best knowledge of the authors, none of these offices uses any sensor related OGC standards and their Web application for data access are based on specific own non-standard solutions. In most of the cases, the Web application consists in a map with base layers served by OGC WxS services and a static vector layer of the stations localization (GeoJSON or KML) with owner defined metadata. Once a location is selected, the application, using the metadata, compose the URL that points to the observations stored in a static file (JSON, CSV or even PDF). For example, the FOEN exposes on the Web the location of monitored water temperatures as a static GeoJson (https://data.geo.admin.ch/ch.bafu.hydroweb-messstationen_temperatur/ch.bafu.hydroweb-messstationen_temperatur_de.json) with an id attribute, used to later access another static file in CSV (https://www.hydrodaten.admin.ch/lhg/az/dwh/csv/ BAFU_2167_Wassertemperatur1.csv) format and containing a series of Time-Value Pairs (TVP). Other similar examples can be found at https://meteolakes.ch and at https://meteoswiss.ch.

The hydro-meteorological monitoring network of the Canton Ticino is currently managed using the Sensor Observation Service (SOS) standard :cite[ogc-sos]. It has been selected as representative of a practical implementation of basic data required for the climate change impact assessment pipeline. The network, which has a 40 years long time-series, is currently composed of 60 stations and 140 sensors observing precipitation, air temperature and humidity, water temperature, river height. Collected information is operationally used by the local administration to design and actuate water resources protection and allocation to guarantee a sustainable management of the resource and the natural environment while protecting from the impacts of extreme events like floods and droughts. The Sensor Things API operational applicability is evaluated by testing this standard to fulfil all the major in place daily practical operations like for example data quality management, data sharing with third parties, data collection from vendor specific sensors and data analyses and visualization. At this stage of the research, the FROST implementation of STA has been set up and the data migration scripts has been prepared and are processing the data migration that is not yet completed. Nevertheless, some preliminary considerations can be derived.

The first tested step is the migration of the SOS service to the STA service. To perform this operation a number of mapping and assumption has to be done and consequently a script has been implemented to automatically migrate data. The equivalent of registering a sensor in SOS is the creation of a Datastream (POST request) that includes connection with (1) a sensor, (2) an observed property and (3) a things with possibly the location. To do so you therefore need to either have the IDs of the three related elements to be used as a reference, creating them in advance if they do not exists, or include directly the elements in the payload. It is worth to be noted that in FROST, any included elements in the request, if not indicated as a reference, is going to be created regardless the existence of a perfectly equal element. This potentially lead to duplicated elements: think of a set of 10 self registering sensors that measure precipitation, at each registration they will create a new ObservedProperty resulting in 10 elements with the same name, definition and description, but with different ID. For this reason the script, register only once the different elements keeping track of the IDs and finally create the Thing. After that, the script can start collecting observations from SOS and injecting them on the STA using a POST request of Observations. In istSOS we can register multiple observations at once providing a swe:DataRecord and in FROST we can uses the CreateObservations using the DataArrays format. Nevertheless to stress the system observations are going to be inserted one by one. This operation make the data migration a slow process, so that the data migration rate is of 1,88 observations/second. For a 20 years long series of 10 minutes data that therefore has 1,051,200 observations this result in a migration time of 22,87 days. It worth to be noted that this rate is not affected by the data retrieval request to SOS since observations are retrieved in chunks of 7 days and only when in memory sequentially injected in a loop of POST requests. Another aspect to consider is that in istSOS you can register observations of multiple observed properties making use of the swe:DataArray and similarly in FROST using the Multidatastream extension that represents a complex observation type. While in istSOS you can retrieve the observations of one of the observedProperties in FROST you can retrieve them only as a complex observation. Finally, in general in STA the three elements have a very minimal set of required information, and in this sense remove part of the complexity of SOS. Nevertheless to cope with compatibility it allows to extend metadata with generic fields to be used discretionally by the user to store "text-like" objects (e.g.: JSON, XML). For example USGS :cite[usgsSTA] in the \textit{Property} field of the Things inserted specific information like monitoringLocationType or hydrologicUnit that are then used to access data. This makes the solution compliant with STA but this lead to loosing practical interoperability since each agency would use it with non defined metadata (what an hydrologicUnit means? where is its definition?). Future analyses will investigate the performance of Message Queuing Telemetry Transport (https://mqtt.org/) interface for data migration, the compatibility with data validation procedures and possible implications derived by its adoption.

In the context of data discovery, access and portrayal, the well-known OGC WxS standards WFS :cite[ogc-wfs], WMS :cite[], WMTS :cite[ogc-wmts] have been used for more than ten years and still widely in use. In association with these standards, styling aspects are defined by the standards SLD :cite[ogc-sld] \& SE :cite[ogc-se]. These are typically referenced by the eCH-0056 Geoservices Application Profile: WMS 1.3.0 (section 6.7), WMTS 1.0.0 (section 6.8), WFS 2.0 (section 6.9.2), WCS 2.0.1 (section 6.9.3), CSW 2.0.2 (section 6.10), SE 1.1.0 (section 6.11) and SLD 1.1.0 (section 6.12).

For this project part, we focus on standardisation work at the OGC related to discovery, data access to visualisation, as made available at https://ogcapi.ogc.org/ and according to their versioning mentioned by the table below. Indeed, the table describes the relationship between the considered OGC APIs and their current equivalents in the context of raster and vector related standards.

To test and analyze these standards and specifications, two experimental cases are setup:

Such styling and symbology instructions described in spread- sheet may then be formatted according to an encoding in con- formance with SymCore extensions and encodings :cite[symcore]. The encoding example below uses GeoCSS :

Which allows to produce the following map :

Regarding the publication of vector data using the OGC API Features standard, we can state that all software packages already support this standard :cite[ogc-api-feature-implementations]. Regarding the tiling of data sets, for a long time the existing WMTS standard has been largely used, but a standard for vector tiling has never been established up to now. A possible explanation for this lack of standardization is on the one hand the complexity of vector tiling (e.g. regarding the handling of attributes or projections), but on the other hand the success of the Mapbox Vector tiles specification :cite[mvt-spec] that have been widely adopted. The OGC API Tiles specification is on a conceptual level similar to the WMTS standard and defines the addressing and tiling of the data. One difference is that the OGC API Tiles specification allows for several formats (both vector and raster) to be computed. This way of defining tiles assures on the one hand the compatibility with existing WMTS services (i.e. allowing applications to easily integrate both existing WMTS layers with tiled vector layers), but also with the Mapbox Vector tiles specification. On the software side GeoServer already supports the OGC-API tiles specification rendering the formats jpg, png, GeoJSON, topojson and mapbox-vector-tile.

Concerning portrayal, we may notice two related aspects: about OGC API Styles, about OGC SymCore. Firstly, OGC API Styles is inline with the conceptual model for styles, style encodings and style metadata as documented in chapter 6 of the OGC Testbed-15: Encoding and Metadata Conceptual Model for Styles Engineering Report. Especially it states that a style may be made available in one or more so-called stylesheets. Moreover style metadata are made available through the API with general descriptive information about the style, structural information (e.g., layers and attributes), and so forth to allow users to discover and select existing styles for their data. Having several stylesheets available does not guarantee the same visualization of the cartographic result for the final user, because each stylesheet may be based on different models and encodings (e.g. SLD, Mapbox style, GeoCSS, etc). Nonetheless, it opens the possibility to make full use of the cartographic capabilities and richness of the various underlying symbology models.

Secondly, OGC SymCore pushes forward portrayal interoperability with the idea to standardize also the symbology part. The approach is so-called one conceptual model, many encodings, which means that many flavors of encodings are possible but each in conformance with a common conceptual rendering behavior of cartographic capabilities. The intent is that finally, independently of the compliant encoding used, the cartographic result will be the same for the final user.