Incompatibility with Common - Part 2 for "crs" / "trs"?

[jerstlouis]

OGC API - Common - Part 2 and Features require the "crs" and the "trs" inside the "extent" as well as in the list of supported "crs" to be URIs, but in EDR the "extent" ones are WKT strings, while those in the "crs" list are non-fully qualified identifiers like e.g. "CRS84".

For the list of CRS, if https://github.com/opengeospatial/NamingAuthority/issues/92 is implemented, it would be allowed to be e.g. simply "ogc:CRS84" instead of "http://www.opengis.net/def/crs/OGC/1.3/CRS84". (this aspect was already discussed in #324)

Additionally, in order to be able to serve a collection as OGC API - Features Core, the "crs" for the spatial extent must be specified as "http://www.opengis.net/def/crs/OGC/1.3/CRS84" (or "http://www.opengis.net/def/crs/OGC/1.3/CRS84h") and the "trs" for the temporal extent should be specified as the infamous "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian" (discussed in https://github.com/opengeospatial/architecture-dwg/issues/29 & https://github.com/opengeospatial/NamingAuthority/issues/101).

Thus for Coverages, we have opted for having the same requirements for the purpose of the collection description, even though the native CRS/TRS of the data and/or the supported output or subsetting CRS might be in another CRS ( see https://github.com/opengeospatial/ogcapi-coverages/issues/144 ).

Since it would be desirable to provide access to the same collection of spatio-temporal data using EDR as well as other access mechanisms, would it be possible to consider re-aligning this with the approach of the other OGC APIs?

@chris-little @ghobona @cmheazel

[m-burgoyne]

The issue is that the Naming Authority approach lacks the flexibility that using WKT gives the API, with WKT it is possible to define custom coordinate reference systems that may only be applicable to a small number of use cases or domains.

[chris-little]

@jerstlouis @m-burgoyne the other shortcoming of the naming authority approach is there is no consensus, or support for those CRSs that may be parametrized, such as the tangent longitude of a tranverse Mercator. The ability of naming authorities to support these more dynamic 'methods' that are a halfway house, between fully, statically, defined (NA) and fully flexible (WKT),. has been raised by Martyn Desruisseaux, but progress is slow.

[jerstlouis]

@chris-little @m-burgoyne I agree there is a need to support custom and parameterized CRSes, whether it's using something like PROJJSON (or future WKT2 CRS encoding) or other mechanisms. However the issues here are that:

1. In the spatial extent and temporal description, the crs specifies only in which CRS/TRS the spatial/temporal extent is reported (not how the data is available). Furthermore to be compatible with Features - Part 1: Core and Coverages, this must always be https://www.opengis.net/def/crs/OGC/0/CRS84 or https://www.opengis.net/def/crs/OGC/0/CRS84h for spatial, and Gregorian/ISO8601 for temporal.
2. In the list of available CRSes (crs property of the collection description), the CRS must be a fully qualified URI (or CURIEs, possibly), not only CRS84

As for where to specify a custom full WKT2 or PROJJSON definition, I am not sure whether or not that could be included directly in that list of CRS without breaking compatibility.

[chris-little]

@jerstlouis We agree that the use of CRS84 is very useful to denoting the extent of offered data from collections for many use cases, but how do I declare my collection of weather data for Mars with CRS84?

Another use case we mentioned was returning data from a tomographic body scan from an MRI? The CRS84 location of the scanner is not particularly helpful.

We discussed this again in EDR API SWG69, and concluded mandating CRS84 was unduly restrictive, though for geospatial data is is probably a worthwhile restriction for interoperability.

[dblodgett-usgs]

As discussed at EDR#73 there are two issues here that need to be treated separately and the way this is posed is not direct enough to address it effectively.

The first issue, around support of CRS84 and ISO8601 for extents, the current specification does support them but allows more flexibility. We don't see this as an incompatibility. @jerstlouis feel free to open a follow up tagging this issue, but please hone your issue description citing particular requirements from Common or EDR that need to be addressed.

The second issue, allowing non-fully-qualified CRSs, we have fixed this oversight in v1.0.1. If there are still outstanding examples of this, please open direct issues pointing them out in the specification.

[jerstlouis]

@dblodgett-usgs @chris-little

About the first issue for CRS84(h) and ISO8601, what other APIs (e.g. Features, Coverages) are doing is that even though the native CRS of the data is other than CRS84(h)/ISO8601, if it is of this Earthly world and can be described using these, then the spatiotemporal extent is always described using these in the Collection description. This facilitates discovery / queries from the /collections and allows to make the collection accessible using different mechanisms, since the use of these is a requirement for OGC API - Features - Part 1: Core. Common does not require that, but this extra flexibility, when talking about Earthly data, makes it difficult to fit nicely with Features. It makes sense of course to provide the dimensions in the native CRS, but this may best be done somewhere else (e.g. in Coverages, that is provided in the domainset resource).

I understand that at this time EDR might not have a separate mechanism to describe the domain of the data. I appreciate that the CIS domainset may appear over-complicated and that the spatiotemporal extent and the domainset resource are somewhat redundant. I wish we could all sit in a room and agree on a single consistent way to describe the domain (and also the range/datarecord fields/observed properties) of the data :)