CRS 84 Requirement

[cmheazel]

/req/core/crs84 states "Unless the client explicitly requests a different coordinate reference system, all spatial geometries SHALL be in the coordinate reference system http://www.opengis.net/def/crs/OGC/1.3/CRS84".
So if I stand up an API-Features which serves up lunar features, I have to somehow represent them in CRS84?
I can see CRS84 as the default for all OGC APIs (this would be a requirement in API-Common) but we also need a way for the API to specify a different default.
I'll put together a proposal in API-Common and we can discuss.

[nmtoken]

I feel for the reason you state, and similar, that it's wrong to default to any CRS; OGC API Features has gone down that route, but let's not have it in common. Common should either not specify a default and leave it to the feature/coverages level, or the default should be the native crs of the dataset.

[cportele]

A common default is important. Users of an API may not know much about geospatial data and they may not have the knowledge or tools to handle integration of data from different sources, if these are in different CRSs. We know these problems are hard, often even for experts. It is important to minimize the interoperability risks here. We can not avoid them, but we can do our best to reduce them.

Yes, there are good reasons why you cannot support the common CRS, like the lunar data example. Or where very high accuracy is essential. As discussed in the Spatial Data on the Web Best Practices these cases of course exist, but for most users WGS84 is fine. In my view it is better to consider the edge cases as out-of-scope for the OGC API Features standard - at least for 2D feature resources - than to open it up too much and make it more difficult for developers to use the data from the APIs.

So, if there is a proposal how to open the requirements up without putting the burden in the non-edge-cases on the client developers (because data providers that could have provided WGS84 as the default decide not to do it), this would be welcome. But so far I have not seen how this could be phrased as I don't think there is a testable rule to determine where WGS84 is "not appropriate".

[nmtoken]

So what of OGC API Features standard - for 3D feature resources? They will have to support WGS84 lon/lat because it's mandated; all OGC API Features implementations must support it because it's in core.

AFAICT for a service provider now I have no options if I don't want to use, or the data can't support WGS84 lon/lat, other than not use OGC API Features, and if the requirement is in common too then it means not being able to take advantage of the OGC APIs, which seems a step away from interoperability.

[cportele]

One problem with 3D right now is that there is no CRS identifier for a CRS that is "WGS 84 longitude/latitude plus ellipsoidal height". Just like we have CRS84 to complement 4326 we would need to register something like "CRS84h" with the OGC-NA that is the same as 4979 but with lon/lat. Then we could change the crs84 requirement to:

Unless the client explicitly requests a different coordinate reference system, all spatial geometries SHALL be in the coordinate reference system http://www.opengis.net/def/crs/OGC/1.3/CRS84 (WGS 84 longitude/latitude) for geometries without elevation information and http://www.opengis.net/def/crs/OGC/0/xxx (WGS 84 longitude/latitude plus ellipsoidal height) for geometries with elevation information.

The "xxx" has to be replaced by the new CRS identifier.

For the bbox parameter I would keep the restriction to CRS84 in the Core as this is what the Simple Feature spec does ("it is possible to store and obtain z coordinate values but they are ignored in all other operations which are based on map geometries") and this is the basis of many libraries and implementations.

[cportele]

Discussion 17 June: A common default is essential, in particular for clients / developers that are not geo-experts. Discuss and decide how to deal with elevation support in Leuven.

[cportele]

Decision to follow the approach above. Add a note that the 3rd number is always the elevation.

Clemens/Peter to discuss the CRS registration with the CRS DWG and the OGC-NA.