Clarify whether spatial extent in collection document should be in CRS84 or storage CRS

[jerstlouis]

Consider implications for APIs implementing a future CRS extension or not, for datasets where the coverage is not natively stored in CRS84.

See:

https://github.com/opengeospatial/ogcapi-common/issues/91#issuecomment-894713298 https://github.com/opengeospatial/ogcapi-common/issues/91#issuecomment-894759911 https://gitlab.ogc.org/ogc/T17-D012-Geo-Data-Cube-API-ER/-/issues/22

Also consider that if the collection is available as both Features and Coverages, Features requires that the spatial extent be specified in CRS84.

[jerstlouis]

SWG 2021-09-22: Members present agree that the following approach would make sense:

• OGC API - Coverages - Part 1: Core would only support the storage/native/default CRS
• The bbox reported in /collections/{collectionId} extent's spatial would always be in CRS84 or CRS84h (regardless of the storage CRS), allowing a collection to be available as both Features and Coverages
• The domainset e.g. at /collections/{collectionId}/coverage/domainset would always be in the storage CRS
• OGC API - Coverages - Part 2: (CRS by reference?) would allow to specify a subsetting (subset-crs) and output crs (crs) to change either or both
• We could start putting together requirement modules in Common based on the commonnality between Coverages and Features CRS extension

See also proposal on how domainset information in alternate CRS could work in #129

@chris-little would this align well with EDR as well?

[pebau]

what is called "storage CRS" above is referred to as "native CRS" in the coverage standards.

[jerstlouis]

@pebau right, I highlighted that above as storage/native/default CRS

In Features Part 2 it is called storageCRS. I see native and storage as equivalent here, and we should state that in OGC API - Coverages so that we can re-use the common storageCRS member in the collection description, while aligning this with the coverage standards.

default refers to the CRS for the subset parameter as well as the CRS for the returned output coverage, when no CRS is explicitly specified (as well as the only CRS supported when the CRS extension is not supported).

What we are saying here is that for OGC API - Coverages, the default CRS is the native/storage CRS. By contrast, in Features, the default CRS is always CRS84 or CRS84h.

[chris-little]

@jerstlouis Of the5 bullet points above, the second

The bbox reported in /collections/{collectionId} extent's spatial would always be in CRS84 or CRS84h (regardless of the storage CRS), allowing a collection to be available as both Features and Coverages

is fine, but we will discuss all of them at the next EDR API SWG next week.

Having the same terminology as API-Features is good, as we went for compatibility with both API-Common and API-Features
where possible.

I am not sure about the implications of the last , fifth, bullet point, as the Features SWG have already mapped out several successive Parts covering a lot of possible commonality.

[m-burgoyne]

The advantage of keeping the spatial extent in collection documents in CRS84 is that it simplifies spatial data discovery.

[cmheazel]

The bbox element of the extent is now required to be CRS84 or CRS84h. The bbox-crs can still be used with the bbox parameter, allowing this parameter to be used to filter the domainset. This looks to me all of the changes required to address this issue.

[cnreediii]

As these days I look through many standards decisions/activities through the CDB 2.0 lens, I think this decision is OK from the client implementing OGC-API Coverages perspective. I believe that the only difference from 4326 and CRS84 is the axis order. If so, then the fact that CDB 2.x datastores will typically be WGS84 2d or 3d, then dealing with axis order is trivial.

Please correct me if I am wrong!!!

[nmtoken]

EPSG:4326 vs CRS84 may be equivalent save lat/long axis order, but what is the EPSG CRS equivalent for CRS84h when we step into a third dimension?

[jerstlouis]

@nmtoken EPSG:4979

[jerstlouis]

SWG 2022-06-08: Today we discussed that to unconditionally require CRS84 (strictly talking about for collection spatial extent bbox, not native/storage/access CRS) as implemented in https://github.com/opengeospatial/ogcapi-coverages/commit/a5aab39e629ef2d8a502af54612c81065f0d5b17 might be too exclusive to use cases beyond Earth, and that the current wording of Requirement 4 "SHALL be interpreted as" could perhaps more clearly target the server e.g., "SHALL be specified as". We had a similar discussion in Maps and we should probably address this in Common as well (Currently in Common - Part 2 the CRS84 restriction is only in the extent.yaml schema enum, and mentioned in Permission 1).

My suggestion is a requirement that includes conditional text For spatial data on Earth. An ETS could still test for CRS84, but a justification could be provided for failing the test in the highly unlikely case where an implementation is using non-Earth data for conformance tests. @cmheazel @joanma747.

[nmtoken]

I assumed that for data that didn't have any mapping to latitude or longitude or ellipsoidal height, the mandated bounding box would be null, or contain null elements.

[chris-little]

In API EDR V1.0, we relaxed the requirement that there SHALL be CRS84 in collection endpoints, precisely because we support off-earth data (e.g. on a satellite, in interplanetary space, or on other planets), data in engineering coordinates (e.g. medical scan), etc. Then nobody will find our data if they search using BBOX in CRS84 or whatever, which is the desired outcome (unless perhaps you specify complex (as in i = sqrt-1) long and lat ;-)

[jerstlouis]

SWG 2022-06-16: Discussed and recommending that Requirement 4 be changed to:

For spatial data on Earth, the coordinates in the bbox schema element SHALL be interpreted as WGS 84 longitude/latitude (http://www.opengis.net/def/crs/OGC/1.3/CRS84) OR WGS 84 longitude/latitude/ellipsoidal height (http://www.opengis.net/def/crs/OGC/0/CRS84h).

[nmtoken]

How will a validator know if the data described is "on Earth"?

[jerstlouis]

@nmtoken I suggested in the comment above:

"An ETS could still test for CRS84, but a justification could be provided for failing the test in the highly unlikely case where an implementation is using non-Earth data for conformance tests. "

I imagine at a point where data outside Earth becomes common place, a separate property indicating a planet or a class of CRS may be useful to address that problem.

But actually the validator could potentially look up a non-CRS84 CRS to verify whether it is for Earth or another planet.

[nmtoken]

Not just for formal conformance testing; any client, should have the ability to test whether the response is valid.

To me too there is a difference between for Earth and on Earth, the former means any Earth location, the latter implies to me the surface.

I get that a validator could look up a non-CRS84 CRS to verify whether it is for Earth or another planet or indeed non-spatial, but I'm stuck on the logic.

[jerstlouis]

@nmtoken "any Earth location" is the intended meaning, therefore For Earth.

The logic would require a CRS database, and definitions schemas that enable this.

[nmtoken]

The validation logic shouldn't be based on whether the validator has access to a CRS database.

It mustn't be that if no CRS database is accessible to the client, the server must supply a CRS84[h] bounding box. There should be a 'unworldly' flag &/or nil reason on the bounding box.

[pebau]

what cannot be validated is not in the standard. So if Mars data cannot validate, OAPI-Coverages does not support them.

[jerstlouis]

@nmtoken

There should be a 'unworldly' flag &/or nil reason on the bounding box.

Well that was what my suggestion of "a separate property indicating a planet or a class of CRS may be useful to address that problem." was about. Mars is still a world and hopefully some of us will be living there soon :) Having a separate URI for the planet or CRS class would solve that problem.

However I am not sure we need to go into so much details at this version of the specification. What we want to ensure is not to exclude any use cases right now, while keeping things easy to extend in the future.

[jerstlouis]

2022-10-05: Fixed by #144.