[GeoJSON] Plug-Pull request to finalize a CRS-free I-D revision

[Bart van den Eijnden]

Is there any chance of simply using CRS:84 instead of EPSG:4326 as the default CRS so your coordinate order won't be perceived as wrong?

Bart

Sent from my iPhone

On Jun 14, 2013, at 8:36 PM, Tim Schaub <tschaub at opengeo.org> wrote:

> To clarify, I'm ok leaving it in as long as we don't touch the coordinate order.  The coordinate order we have now works well for clients interested in rendering (atop images that come with notions of top and left).
> 
> My primary motivation for wanting to remove the CRS member was because I know as long as we have it in there, people will argue that our coordinate order is wrong.  A secondary motivation is that I think all GeoJSON in one CRS is better for interoperability (I still believe that no matter how well you specify the CRS member, very few if any browser clients will be able to handle arbitrary CRS).
> 
> So while I think we're setting ourselves up for less interoperability in favor of efficiency, I won't object to doing nothing with the spec regarding CRS.
> 
> Tim 
> 
> 
> On Fri, Jun 14, 2013 at 10:37 AM, Sean Gillies <sean.gillies at gmail.com> wrote:
>> Since we don't have consensus on removing the CRS member, let's leave that as it was. Agreed? 
>> 
>> We have 3 pull requests pending right now:
>> 
>>   https://github.com/GeoJSONWG/draft-geojson/pulls
>> 
>> It seems the thing to do now is close 6 and 9, merge 10, and then restore the old language about CRS.
>> 
>> Thanks for your input, Mike and Nelson! 
>> 
>> 
>> On Fri, Jun 14, 2013 at 8:13 AM, Howard Butler <hobu.inc at gmail.com> wrote:
>>> 
>>> On Jun 13, 2013, at 6:48 PM, Allan Doyle <afdoyle at MIT.EDU> wrote:
>>> 
>>> > Final thoughts: I admit I was one of the people originally advocating dropping crs. I've changed my mind. We screwed it up, but it would be worse to compound the error.
>>> 
>>> Like Allan, I've changed my mind too. Changing srs in any way is likely to compound the problem. It is stinky for sure, and SRS interop beyond a simple EPSG code is likely to be more of a gentlemen's agreement rather than true interop, but its removal is not going to fix the problem. It will just fragment things and create more confusion.
>>> 
>>> I would like to propose that we add an Errata/Appendix C section to the bottom of the document that warns of the various pitfalls without making prescriptions about how people should act. Notes about srs would obviously go there, but also things like ring ordering in situations where spherical coordinates are being used, and axis ordering for the large swath of coordinate systems that GeoJSON insufficiently describes. This section can recognize the usage patterns that have emerged with GeoJSON in the 5 years since its release. Links to various mailing list discussions, github tickets, etc might also be useful for someone looking to do some deep research before declaring us and the specification to be idiotic.
>>> 
>>> Howard
>>> _______________________________________________
>>> GeoJSON mailing list
>>> 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
> 
> 
> 
> -- 
> Tim Schaub
> OpenGeo http://opengeo.org/
> Expert service straight from the developers.
> _______________________________________________
> 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/20130614/475df646/attachment.htm>