Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRS 84 Requirement #233

Closed
cmheazel opened this issue Jun 14, 2019 · 6 comments · Fixed by #240
Closed

CRS 84 Requirement #233

cmheazel opened this issue Jun 14, 2019 · 6 comments · Fixed by #240
Assignees
Labels
OGC API: Common Issue related to general resources or requirements (see #190) Part 1: Core Issue related to Part 1 - Core progress: pull request available

Comments

@cmheazel
Copy link
Contributor

/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.

@cmheazel cmheazel added OGC API: Common Issue related to general resources or requirements (see #190) OGC API Hackathon labels Jun 14, 2019
@cmheazel cmheazel self-assigned this Jun 14, 2019
@nmtoken
Copy link

nmtoken commented Jun 14, 2019

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
Copy link
Member

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
Copy link

nmtoken commented Jun 17, 2019

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
Copy link
Member

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 cportele added the Part 1: Core Issue related to Part 1 - Core label Jun 17, 2019
@cportele cportele added this to the Part 1, Second Draft Release milestone Jun 17, 2019
@cportele
Copy link
Member

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
Copy link
Member

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.

cportele added a commit that referenced this issue Jun 25, 2019
* Move examples in Annex B/C outside of the document, resolves #239
* Bulk download, resolves #230
* CRS 84 Requirement, resolves #233
* Endpoint /api missing from OpenAPI specification, resolves #236
@cportele cportele mentioned this issue Jun 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OGC API: Common Issue related to general resources or requirements (see #190) Part 1: Core Issue related to Part 1 - Core progress: pull request available
Projects
Development

Successfully merging a pull request may close this issue.

3 participants