[GeoJSON] Removing CRS from GeoJSON

[Tim Schaub]

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] *On Behalf Of *Tim Schaub
> *Sent:* 15 May 2013 05:41
> *To:* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130515/ea9666f2/attachment.htm>