[GeoJSON] Removing CRS from GeoJSON
Volker Mische
volker.mische at gmail.com
Thu May 16 13:10:04 PDT 2013
As mentioned in some previous thread. There could be a new JSONCRS which
defines how such a CRS might look like if you want one. That is perhaps
something for the MetaCRS people.
Cheers,
Volker
On 05/16/2013 09:10 PM, Allan Doyle 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
> <mailto: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
>> <mailto: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 <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.
>>
>> 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
>>
>>
>>
>>
>> --
>> 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
>
>
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
More information about the GeoJSON
mailing list