TC E Vote Comments

NO vote comments

• Institut National de l'information geographique et forestiere (IGN) No

We can see the interest of this (Simple) API for Spatio-Temporal Resource Retrieval API, but we are facing some confusion (and potentially conflicts) with other environmental data and other features API in the OGC. The coherence / relations with STa, Observations API , Coverages and Moving features should be considered and clarified in this document. If this is done, we are happy to change our vote to YES. Our general and detailed comments supporting this vote are the following: General and major: This document is specified to address Environmental Data / Environmental Data Resource, and its aim is to provide an API for Environmental Data Resource retrieval, based on OGC API / Open API. This concept of “Environmental Data Resource” is loosely defined (in Scope and section 9) but the term is not part of the normative definitions in section 5. What the scope of this specification is ambiguous in the title, the scope and the normative content of the specification. Probably the best (IMHO) definition is in Introduction / Abstract: “family of lightweight query interfaces to access Environmental Data resources by requesting data at a Position, within an Area or along a Trajectory”, though Environmental Data resource remains an unclear concept, obviously to be understood as a flexible term.

From the definition “An Environmental Data resource is a collection of spatio-temporal data” (that can be sampled using the OGC-API EDR query patterns).

From 7.1, “EDR API can be considered a 'Sampling API'” (though the sampling mechanism is not specified and documented other than with the instance term and instance query).

IGN had a similar comment during the RFC, and the answer, together with an interesting explanation, was that it was unnecessary to add a definition for “Environmental Data resource”. In the response, “the API can be used with any data that has consistent space-time coordinates and may be non-environmental data.” As environmental data resource goes far beyond what is specified or exemplified in this specification, we suggest:

1 - Either to avoid the use of this term in the title and the content of this specification, and possibly replace it by Spatio-Temporal Resource.

2 - Or to clearly indicate in the scope and in the definition of “Environmental Data resource” that that the API may be used with “non-environmental data”.

One proposal for renaming of this API is “Spatio-Temporal Resource (Simple) Retrieval API”. This is a key and major issue.

Coherence / Relationship with other OGC APIs: This specification discusses and exemplifies the potential use for Observation, Features of interest and Coverages (on basis of Coverage-JSON), and compares with SOS and WCS. However there is clearly an overlap with emergent Coverages API and the revision of STA for OGC API alignment. There should be a section (or an annex) for the relationship with other OGC APIs summarizing the relations with other OGC API standards, including OGC API Features, Moving feature access and STA with which there is a significant overlap. If not, this specification will introduce overlap conflicts with Coverage, Observation, STA and Moving Feature access APIs, and this will be a source of confusion in the new generation of OGC APIs.

General/major: Supposedly there is no underlying data model behind this API, except the “Environmental Data Resource” under discussion and “Environmental Data Resource Collection”. This concept is not the object of any model, and seems to be designed to be flexible and versatile. However there is a need (for users) to properly define, name and document this base resource(s) of this specification, supposed to make it different from other OGC APIs (or add special value).

Chapter 5: This section reinvents the position term, defined in ISO 19133:2005: “data type that describes a point or geometry potentially occupied by an object or person”. If this definition is not acceptable, there should be a note explaining why another definition is specified. Note: There is also another ISO 19107:2003 for instance (which is probably not acceptable in this document).

C.3: Example to be included

• Fraunhofer-Gesellschaft No

Instead of trying to contribute to overcome the missing interoperability between OPC API and SensorThings API, this specification increases their divergence as it aims at resolving already resolved requirements of the environmental domain (such as sensor data management) in a different, incompatible manner. See detailed comment at https://portal.ogc.org/files/?artifact_id=96471 .

Abstain Votes

No comments

Yes Votes

• GeoConnections - Natural Resources Canada Yes

Noting concerns about the name of the standard through internal NRCan discussions and those put forward by other voting members. How can the name reflect potentially broader uses of the API?

• Geonovum Yes

Consider renaming the standard, as the term 'environmental' does not seem to cover the scope. Any spatio-temporal data could be exposed using an EDR API. As I see it, it provides a way to find and retrieve spatio-temporal data using different subsetting techniques, making it convenient for users to select the subset of the data they need.

• European Space Agency (ESA) Yes

Perhaps it could be made clear that this work for any sort of data and not only Environmental...