W3C home > Mailing lists > Public > public-sdwig@w3.org > August 2018

Re: [sdw] CRS negotiation in MapML

From: Peter Rushforth via GitHub <sysbot+gh@w3.org>
Date: Wed, 01 Aug 2018 13:46:46 +0000
To: public-sdwig@w3.org
Message-ID: <issue_comment.created-409580206-1533131205-sysbot+gh@w3.org>
@larsgsvensson and @dvh Interesting.  I don't think headers will work for MapML, because the "tiled coordinate reference system" concept, and the definition of 'WGS84' are defined only within MapML as "projection" [values](https://maps4html.github.io/MapML/spec/#semantics). 

MapML aims to be a defined internet media type (text/mapml), so the definition of the media type would make it self-describing, as I understand that concept. A profile would seem to be an extension of a media type, if I understand the concept correctly.   Perhaps when the definition of TCRS is widely enough accepted these could be considered profiles and header-based negotiation could also work.  As a first pass, and without implying deeper protocol inspection than I wanted to get into at this time, having the media type provide a facility to adapt to the runtime environment seemed like a win.

Early on I did try negotiating the projection off a media type parameter but that did not work very well, so I abandoned that idea.

> We chose to introduce an Accept-Crs request header to let the client negotiate a preferred CRS and a Content-Crs header to identify the CRS used in both the payload of the request as the payload of the response.

@dvh where an API would be negotiating with a client for GeoJSON or KML for example, what value of `Accept-Crs` would be used (the axes in those formats, like MapML, are ordered [long,lat], which is defined only in the format and not by a well-known CRS identifier, IIRC)?




-- 
GitHub Notification of comment by prushforth
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1058#issuecomment-409580206 using your GitHub account
Received on Wednesday, 1 August 2018 13:47:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 August 2018 13:47:24 UTC