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

[christopher.schmidt at nokia.com]

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
>