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

[Sean Gillies]

On Mon, Nov 7, 2011 at 9:39 AM,  <christopher.schmidt at nokia.com> wrote:
>
> 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

Chris, what would you think about a statement in the spec that parsers
MUST IGNORE unexpected properties? I tend to expect this of JSON data
and looking around on the web and I see many others do too. It's a
property that makes consuming JSON distinctly different from strict
XML parsing where you are supposed to stop when you hit unexpected
data.

I'm leaning -1 on circles and ellipses because they look like a
cul-de-sac to me: we could represent them but you can't go very far
with them. I'm interested in possibly adding a radius to points.
There's some precedent already in the Geo URI Scheme RFC.

-- 
Sean Gillies