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

[Tim Schaub]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130614/03060c2e/attachment.htm>