[GeoJSON] Removing CRS from GeoJSON

Thu May 16 12:36:23 PDT 2013

Cool. Pending assent from Stefan, Tim is going to get the repo back on
track. Then we can edit for readability and correctness w/ respect to the
geojson.org spec (okay with you all to do this via pull requests?), run the
scripts, and submit :)

On Thu, May 16, 2013 at 1:10 PM, Allan Doyle <afdoyle at mit.edu> wrote:

>  I agree with deprecating CRS with no replacement.
>
>  Maybe if people want other coordinate systems, they can reuse the
> GeoJSON syntax but embed it into some kind of CRS wrapper. That lets people
> reuse GeoJSON parsing code but the wrapper should not be called GeoJSON.
> (Not sure if I'm making sense here…)
>
>  Allan
>
>  On May 16, 2013, at 2:58 PM, Tim Schaub <tschaub at opengeo.org>
>  wrote:
>
>  I like the proposal Sean.  Curious exactly what you mean by deprecate
> (remove "crs" with no text mentioning it, or say "crs" is deprecated and
> describe what it used to be like?).
>
>  Regarding GeoServer, it is a good question.  I haven't discussed this
> with others in that community, but I'd say GeoJSON would become more like
> KML - GeoServer can serialize feature collections as both, but you can't
> request data in arbitrary reference systems.
>
>  It's also my opinion that clients can use other formats if they need
> functionality not covered by GeoJSON (we don't handle complex features
> particularly well, for example).  A capable web client can consume GML from
> GeoServer's WFS if it wants data in an arbitrary crs or needs complex
> features.  In addition, I don't personally feel like GeoJSON + WFS is a
> natural mix (WFS-T for example, doesn't work).
>
> Tim
>
>
>
> On Thu, May 16, 2013 at 12:26 PM, Sean Gillies <sean.gillies at gmail.com>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 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.
>>
>> 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>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] *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.
>>>
>>>  _______________________________________________
>>> GeoJSON mailing list
>>> GeoJSON at lists.geojson.org
>>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>>>
>>>
>>
>>
>> --
>> Sean Gillies
>>
>
>
>
>  --
> 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
>
>
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130516/8ddb458e/attachment-0005.htm>