[Geojson] circles (was: Toward consensus on proposals)

[Matt Priour]

Ok, so you are right Christopher.
OpenLayers, OGR, and GeoTools will all throw errors and stop processing if they hit an unsupported geometry type. This is the exact opposite of what I would expect from a JSON parser. I would have expected a warning and continued processing. Given this fact and that the ONLY substantive change between GeoJSON 1.0 & GeoJSON 1.1 would be the inclusion of circle and ellipse geometry types which would have a direct and obvious benefit for a small-ish subset of the GeoJSON community, I have changed my opinion from “definitely in favor of” to “neutral”.

I would however be strongly in favor of formalizing a circle and ellipse as points with radius or major/minor axis properties and a default to coordinate units unless there is an explicit units member. Whether these circle defining properties go in as first order members or as required members of the ‘properties’ object is something I am firmly neutral on.

Matt Priour


From: christopher.schmidt at nokia.com 
Sent: Monday, November 07, 2011 10:39 AM
To: mpriour at kestrelcomputer.com 
Cc: Arlo.Belshee at microsoft.com ; geojson at lists.geojson.org 
Subject: Re: [Geojson] circles (was: Toward consensus on proposals)


On Nov 7, 2011, at 9:53 AM, ext Matt Priour wrote:

> I’m still not understanding why there is so much opposition to adding circles and ellipses. GeoJSON is a transport format. Why do we even care about what happens on the GeoJSON client/interpreter end if spec changes don’t break currently working/expected behavior?

1. Adding in a geometry type of Circle will almost certainly break existing
   parsers. We have defined a static list of geometry types which map
   to native GIS types that most clients support; extending that will
   likely cause parser to blow up. Right now, the assumption is that
   anything which produces GeoJSON can expect to have it consumed by
   GeoJSON supporting clients. Adding new geometry types breaks that
   assumption.
2. One of the key points of GeoJSON is strong interoperability. Because
   it is simple and limited, it is easy to implement; very few consumers
   of GIS data would have a hard time round-tripping GeoJSON with reasonable
   accuracy through their existing internal data structures. Circles
   change that.

> Circles or curved linestrings are supported by GML, EWKT and SQL-MM standards and implemented in JTS, PostGIS 1.4+ and other programs.

> What is the harm of allowing a more compact representation of these geometries?
> Most GeoJSON parsers are robust enough to just ignore unsupported types.

Which GeoJSON parser do you think is robust enough to ignore
unsupported types? Do we have an analysis of what happens
when you throw a circle type at various parsers? (I'd be sort
of surprised if they all 'just work' in some way; which is 
part of why I'm leaning towards a representation which most
clients *will* handle by default...)

-- Chris

>  
> The biggest issue I see is the radii units question. However, even with that I think we have hit upon a good compromise:
> Specify a ‘units’ member or else the parser MUST default to coordinate units.
>  
> Matt Priour
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111107/e14aaaa1/attachment-0005.htm>