[GeoJSON] Removing CRS from GeoJSON

Thu May 16 11:32:11 PDT 2013

On 16.05.13 20:26, Sean Gillies wrote:
> All,
>
> How about this for a plan: submit an I-D that deprecates the old crs 
> object, omits the new proposed crsURN object, and doesn't otherwise 
> change the geojson.org <http://geojson.org> spec. After it is 
> submitted, we reexamine the CRS situation in light of comments we'll 
> (hopefully) get. My hypothesis is that this compatibility-breaking 
> change doesn't actually break very much in practice.
>

I think this would be very good. Requests for comments are a good thing 
:-) and there are mayn revisions imagineable: As an example Fielding, 
R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): 
Message Syntax and Routing" draft-ietf-httpbis-p1-messaging-22, 23 
February 2013. 
https://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/. Have 
finished the working group call for comments as of April, 30 and I think 
there will be a draft-ietf-httpbis-p1-messaging-23 coming up ...

All the best,

Stefan.
odata-v4.0-wd02-part1-protocol-2013-05-16
> As a consequence there will be what looks to a lot of GIS folks like a 
> gap in the spec. We'll need to be able to live with the multiple 
> gap-filling measures they'll come up with. For example, Tim, what's 
> GeoServer going to do to satisfy WFS requests for GeoJSON in 
> EPSG:27700 (or urn:ogc:def:epsg::27700)?
>
>
> On Wed, May 15, 2013 at 11:08 AM, Tim Schaub <tschaub at opengeo.org 
> <mailto:tschaub at opengeo.org>> wrote:
>
>     Tim, I think the situation that we have at the moment is better
>     than you describe, but not by much. We have "allow any CRS and
>     axis order will always be lon/lat or easting/northing". We did
>     that to avoid the burden of carrying around axis order knowledge.
>     But it still has the burden on needing to know what EPSG:27700, or
>     whatever, means. Web clients still have to get the WKT, Proj.4
>     string, etc, from that id (assuming that they can work with the
>     result). So we dodged one bullet, but not the other, arguably more
>     complex, one.
>
>
>     Regarding the bullet dodging, web clients don't actually have to
>     know squat about EPSG:27700 if they use GeoJSON and WMS 1.1 - they
>     just have to match strings to know that they are the same.  WMS
>     1.1 described a rendering service where coordinate order could be
>     mapped to rendering concepts like "top" and "left" (well known by
>     web clients who deal with images).  GeoJSON maintained the same -
>     a known mapping of coordinate order to rendering orientation.  So
>     we very intentionally made GeoJSON work well with existing
>     rendering services.
>
>
>         Here's a pull request of mine:
>
>         https://github.com/GeoJSONWG/draft-geojson/pull/3
>
>         Martin
>
>         *From:*geojson-bounces at lists.geojson.org
>         <mailto:geojson-bounces at lists.geojson.org>
>         [mailto:geojson-bounces at lists.geojson.org
>         <mailto:geojson-bounces at lists.geojson.org>] *On Behalf Of *Tim
>         Schaub
>         *Sent:* 15 May 2013 05:41
>         *To:* geojson at lists.geojson.org <mailto:geojson at lists.geojson.org>
>         *Subject:* [GeoJSON] Removing CRS from GeoJSON
>
>         So as to avoid hijacking Sean's thread, I'll start a new one here.
>
>         I'm in favor of restricting the allowed coordinate reference
>         systems for GeoJSON objects to 1: latitude, longitude
>         coordinates relative to an ellispoidal CRS based on the WGS84
>         datum.
>
>         I think the second best alternative would be to restrict to 2
>         CRS: CRS84 or EPGS:3857.
>
>         I don't like the "allow any CRS and let axis order follow the
>         CRS" because I think it either reduces interoperability or
>         imposes an unreasonable burden on web clients (I don't know of
>         a good web service - or really want to depend on one - that
>         provides axis order information for arbitrary CRS URN, and the
>         table is too big to ask every client to carry around).
>
>         I apologize for having missed earlier "discussion" [1]. I
>         haven't dug down to that epoch in my inbox yet.
>
>         And I'm in favor of the proposed RFC to IETF [2].
>
>         https://github.com/GeoJSONWG/draft-geojson/pull/2
>
>         [1]
>         http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000712.html
>
>         [2]
>         http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000713.html
>
>         Tim
>
>         PS - Do the build artifacts (xml, txt, etc) need to be in the
>         repo? If so, can someone update the README.md with detail on
>         building them?
>
>         PPS - Mildly curious what it means to be "commented out" as an
>         author. I do see a comment that suggests authors should be
>         asked if they are willing to be authors. Happy to entertain
>         that question.
>
>         -- 
>         Tim Schaub
>         OpenGeo http://opengeo.org/
>         Expert service straight from the developers.
>
>
>
>
>     -- 
>     Tim Schaub
>     OpenGeo http://opengeo.org/
>     Expert service straight from the developers.
>
>     _______________________________________________
>     GeoJSON mailing list
>     GeoJSON at lists.geojson.org <mailto:GeoJSON at lists.geojson.org>
>     http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>
>
>
> -- 
> Sean Gillies
>
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130516/567d8a34/attachment.htm>