Standardized CRS negotiation

[dvh]

I think there should be a standardized way to provide CRS negotiation on the web, so that:

1) servers can tell clients which CRS is used in the response (GeoJSON once had a crs property for this purpose but dropped it in the last RFC) 2) clients can tell servers which CRS is used in the request 3) clients can tell servers which CRS is preferred in the response

Why? Because we have a real world usecase at the Dutch government concerning the negotiation of different Coordinate Reference Systems at the moment. We also have been exploring possibilities to join the Profile-Negotiation development (https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/17) but it turned out to serve different needs. More details, examples and concrete proposals on each of the 3 situations can be found below.

1. Returned geometries

The server responds with geometries using an unknown CRS. Currently, there is no way to validate if the response actually met the non-default preference, unlike the Content-Language response header which informs the client which language was returned. Please note that the request didn't have to contain a geometry to serve this response, the response is completely seperate from the request.

Proposal: Introduce a Content-Crs response header to tell the client which CRS was used with the geometries in the response. This is comparable with the HTTP Content-Language response header. Value could be the alphanumerical value of the EPSG, e.g. epsg:28992.

2. Filter on geometry

Send a geometry as a request parameter, e.g. to find all results within a certain area. Currently there is no standardized way to tell the server which CRS the input geometry uses, unlike the Content-Type request header which defines the input content type. Please note that the response doesn't have to contain a geometry to answer this request, the request is completely seperate from the respone.

Proposal: Introduce a Content-Crs request header to tell the server which CRS was used while doing the geographical request. This is comparable with the HTTP Content-Type request header. Value could be the alphanumerical value of the EPSG, e.g. epsg:28992.

3. Request geometries

Request the server to return geometries using another CRS than the default (WGS84). Currently there is no standardized way to tell the server which CRS you prefer, unlike the Accept-Language request header which kindly asks the server to which language is preferred.

Proposal: Introduce an Accept-Crs request header to tell the server which CRS is preferred in the response. This is comparable with the HTTP Accept-Language request header and could be expanded with the q param to indicate the rank of preferred CRS. Values could be the alphanumerical values of the EPSG, e.g. epsg:28992.

Please give me your thoughts!

[jonblower]

Interesting idea that's well worth exploring. There's clearly a need for CRS negotiation to happen in many kinds of application - WMS is one example of course. One complication of this is that multidimensional datasets will in general use multiple CRSs (e.g. horizontal, vertical and temporal, maybe more), which may or may not be considered separable. Another issue is that conversion between CRSs will in general introduce errors, so data in one CRS are not exactly the same as data in another CRS - therefore it's not quite the same as the selection of an encoding. (I suppose that that's also true in, for example, image content negotiation, where JPEGs are lossy compared with PNGs. But images are not usually considered "data" and their exact numerical values are rarely important.)

Defining the semantics of CRS negotiation in a way that works across all spatial datasets could therefore be tricky. I wonder if it's better to leave CRS negotiation at the application level, where semantics can be defined according to the needs of the application?

Having said that, I guess servers would not have to support CRS negotiation unless they are comfortable with the semantics, however they are defined. So perhaps this could work with some restrictions (e.g. limited to 2D horizontal CRSs or something like that).

[dvh]

Hmmm... I must admit I haven't worked with non-2D spatial data yet. Do you have any examples of multidimensional spatial data with different CRS perhaps?

[jonblower]

Yes, there are lots in the world of weather, climate, oceanography, earth observation etc. To take one example, imagine a weather forecast that is issued as a grid with axes of longitude, latitude, pressure and time. (Pressure is commonly used as a vertical coordinate instead of elevation, for various reasons.)

The user might want to request a subset of the data at a particular pressure level and time, in their own preferred horizontal CRS (e.g. British National Grid). Or they might want a version of the dataset that uses elevation instead of pressure as the vertical axis. The conversion of pressure to elevation is not a trivial one, and one which users might want some control over.

(The issues are compounded by the fact that there are often no widely-agreed identifiers for these dimensions because they don't fall into the realm of standard 2D GIS/geodesy.)

[lieberjosh]

Dimitri,

Access to alternate geometries, such as in different CRS’s, has been a long topic of consideration in the SDWWG. We have generally concluded that choosing among various parameters options of data objects such as geometries would be a radical overloading of HTTP content negotiation protocols. We have focused instead on providing documentation of such parameters (including dimensionality, geometric type, resolution, etc.) in the metadata that is part of a geometry payload, so that standard or application-specific API’s can query them effectively, and so that delivered geometries are clearly identified. Available CRS’s are certainly part of standard interfaces such as WMS, although a particular implementation may provide so many CRS options that the cannot be included in the capabilities document. A client in that case just requests data in a CRS of interest and the server will either provide the data or return an exception. For most recommended formats, a returned geometry will be marked with its encoded CRS as a confirmation.

I should note that there is currently work in OGC on more RESTful versions of standard OGC services such as WFS that may make more use of custom HTTP headers. The wor, is worth following / participating in, but is still in progress and not ready at this time to cite as a best practice.

Cheers,

Josh

k

On Apr 26, 2017, at 8:32 AM, Dimitri van Hees notifications@github.com wrote:

I think there should be a standardized way to provide CRS negotiation on the web, so that:

servers can tell clients which CRS is used in the response (GeoJSON once had a crs property for this purpose but dropped it in the last RFC) clients can tell servers which CRS is used in the request clients can tell servers which CRS is preferred in the response Why? Because we have a real world usecase at the Dutch government concerning the negotiation of different Coordinate Reference Systems at the moment. We also have been exploring possibilities to join the Profile-Negotiation development (ProfileNegotiation/I-D-Accept--Schema#17 https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/17) but it turned out to serve different needs. More details, examples and concrete proposals on each of the 3 situations can be found below.

1. Returned geometries

The server responds with geometries using an unknown CRS. Currently, there is no way to validate if the response actually met the non-default preference, unlike the Content-Language response header which informs the client which language was returned. Please note that the request didn't have to contain a geometry to serve this response, the response is completely seperate from the request.

Proposal: Introduce a Content-Crs response header to tell the client which CRS was used with the geometries in the response. This is comparable with the HTTP Content-Language response header. Value could be the alphanumerical value of the EPSG, e.g. epsg:28992.

2. Filter on geometry

Send a geometry as a request parameter, e.g. to find all results within a certain area. Currently there is no standardized way to tell the server which CRS the input geometry uses, unlike the Content-Type request header which defines the input content type. Please note that the response doesn't have to contain a geometry to answer this request, the request is completely seperate from the respone.

Proposal: Introduce a Content-Crs request header to tell the server which CRS was used while doing the geographical request. This is comparable with the HTTP Content-Type request header. Value could be the alphanumerical value of the EPSG, e.g. epsg:28992.

3. Request geometries

Request the server to return geometries using another CRS than the default (WGS84). Currently there is no standardized way to tell the server which CRS you prefer, unlike the Accept-Language request header which kindly asks the server to which language is preferred.

Proposal: Introduce an Accept-Crs request header to tell the server which CRS is preferred in the response. This is comparable with the HTTP Accept-Language request header and could be expanded with the q param to indicate the rank of preferred CRS. Values could be the alphanumerical values of the EPSG, e.g. epsg:28992.

Please give me your thoughts!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw/issues/757, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhtvMFD1RVrKal-hE_lZkiuPdWTxwks5rzzl3gaJpZM4NIyza.

[dvh]

Thanks for the comments! @jonblower aren't these situations domain specific custom formats? e.g. is GeoJSON or WFS able to deal with these things? @lieberjosh the scenario you describe looks like the crs property in the body of a GeoJSON object, which has now been removed from the standard. While it was still in there, I was able to at least solve issues 1 and 2 from my usecase. Could you perhaps provide me a link to the OGC work to point me in the right direction?

[jonblower]

That example is certainly from a specific domain, but it's just an illustration of a multidimensional dataset. GeoJSON couldn't handle the data (it's a vector format and the data are array-based) but CoverageJSON could. With WFS, I'm not sure. I believe that WFS can be applied to a multidimensional case, but all the examples I know about are 2D.

It sounds like you're hoping to solve the limitations of a particular data format (GeoJSON) by pushing functionality to the HTTP layer, where I'm not sure it belongs. I agree with @lieberjosh, who put it more eloquently than I did - I think these things belong in the application layer, not the HTTP layer.

[dvh]

So basically you mean it should be put back in the GeoJSON standard ;)

[jonblower]

Haha, well maybe - but I'm sure they had their reasons.

[dvh]

Yes, they compared CRS with Character-Encoding and said these things belong anywhere but in the application layer... Now if this was only 1 specific format, but I think GeoJSON is widely used in the web developers/API community who are used to handling content-negotiation (type, date, time, language, encoding, etc.) in the HTTP layer instead of in the application layer. I'm going to have a look at the OGC efforts to get more RESTful.

[jonblower]

The GeoJSON RFC says, "where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted". I'm not sure how the CRS information is transmitted in this case, but presumably there's nothing stopping you using a crs attribute in the JSON, but the interpretation of this is out of band of GeoJSON itself.

I read this as them saying that the CRS stuff does belong in the application layer, because that is the only place where you know enough about your user community to be confident that they can interpret the CRS correctly (e.g. you know about both the server software and the client software that is in use).

Anyway, I think that CRS conversion is too complex for the web layer, and it's a somewhat niche concern compared with more general things like language and encoding. There are a lot of potential parameters involved, which users might want control over, and things get even more complicated with raster data (in 2D or nD).

[rob-metalinkage]

There are clearly many facets over which negotiation is important, because we'd need to preserve the possibility to link information via a single feature identity but use different representations for different purposes.

Language, encoding, data model, graph traversal depth, acess rights, crs, precision, trust model etc.

So am against ad-hoc patterns for single facets. But we dont have an option we can use safely yet.

Also, imho it would be unwise to ignore discovery of options available. Hence i think this may well fit into a data discovery WG scope.

Rob Atkinson

[jonblower]

@rob-metalinkage - I agree that this is well worth looking into. But my issue is that I don't think the question of CRS is the same kind of question as language, encoding, compression etc. We have gaps at both the semantic and mechanistic level. We can presumably solve mechanistic issues, but the semantic ones may be harder.

For example, if I tell you that I have a file in JPEG format, you know exactly what I mean. If I tell you that I have a file "in" a certain CRS, what exactly does that mean? For simple cases this can be well defined but there are many potential complications, some of which I mention above.

IIRC there was a related discussion on the GeoDCAT-AP list, where we wondered if it was correct to say that a dataset "dcat:conformsTo" a CRS, or whether the dataset simply "uses" it. I don't remember the details of this though.

[dr-shorthair]

But following on from this thought, HTTP negotiation is primarily to support the following question in the client side: “do I have software (e.g. a plugin) that can load the content”. Moving CRS issues into http negotiation might just be a challenge to the client to have software that can do coordinate transformations … ?

So I don’t see the blocker to use of HTTP negotiation for this task. .

[dvh]

A little update from our side :) We've decided to give Accept-Crs and Content-Crs a try and will share our findings here if they seem to be valuable. This is because we have to move forward and at the moment there are no best practices or standards in this area yet. Will keep you posted!

[jonblower]

Good luck! Despite my reservations I think an experiment is a very good idea and I'd be keen to see the results.

My guess is that this will work fine in cases where the resource in question is a set of 2D vector geometries, all in the same CRS. I can see difficulties with raster data, multidimensional data and content that uses multiple CRSs. Also, it becomes mechanistically tricky where CRS identifiers don't exist for the CRSs in question.

(Raster/gridded data is harder because a CRS transformation is not just a CRS transformation - it's also a resampling to the new grid. You don't just say "I want that raster in this CRS" - you also have to say how you want the resampling to be done, and this can get very complicated, depending on the use case. Even in simple cases you need more information than just the new CRS.)

[6a6d74]

This work item could be addressed by the planned SDW Community Group ...

We can't deal with it in the Best Practice because it is new stuff & clearly not an existing practice.

[larsgsvensson]

@dvh Since profile negotiation is a topic in DXWG it could make sense to provide CRS negotiation as a use case. If your institution is a member of that group you can add it to their use case wiki page yourself. Otherwise just provide some text and I can do it on your behalf (and cite this thread as a related resource).

[dr-shorthair]

Very good idea Lars. It is probably at the extreme end of what DXWG would consider, but worth stretching them.

Note @jonblower comments on additional challenges for raster data though.

[lieberjosh]

Hi Lars,

Recent discussion has focused on CRS, but it’s just one of a number of parameters that may characterize a particular geometric representation of a Spatial Thing, including the type of geometry, its relationship to the Thing, method of interpolation, scale or resolution. It would be hugely impractical to negotiate all of these factors in HTTP headers. Perhaps the DXWG would like to consider other more indirect means of negotiation, such access to available options and syntax for choosing geometries. I agree it is worth raising the question, but it may be a complicated answer.

—Josh

On May 23, 2017, at 8:10 AM, Lars G. Svensson notifications@github.com wrote:

@dvh https://github.com/dvh Since profile negotiation is a topic in DXWG it could make sense to provide CRS negotiation as a use case. If your institution is a member of that group you can add it to their use case wiki page https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space yourself. Otherwise just provide some text and I can do it on your behalf (and cite this thread as a related resource).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw/issues/757#issuecomment-303378278, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhkuixkypaqWHEeYifyy3sTCjRdhfks5r8sywgaJpZM4NIyza.

[larsgsvensson]

Hi Josh,

yes, there are answers and they seem to be complicated, but at least people seem to have thought about this before.... I was pointed to (the experimental) RFC 2295: Transparent Content Negotiation in HTTP and the possiblility to combine it with RFC 2938 Identifying Composite Media Features (which is on standards track). They are a bit intimidating to read but they do address the problems

Best,

Lars

[lvdbrink]

There is renewed interest for this item. See recent discussions in two different OGC groups:

• https://github.com/opengeospatial/ogcapi-processes/issues/217
• https://github.com/opengeospatial/ogcapi-common/issues/8

[jerstlouis]

@lvdbrink In Coverages, the current proposal for a CRS extension is very similar to Features - Part 2: CRS. The idea is also that this could be come a Common requirement module. With Processes - Part 3: Workflows, those Features & Coverages approaches can be used to trigger & retrieve the results of a process or workflow.