<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Arial'; COLOR: #000000; FONT-SIZE: 10pt">
<DIV>Ok, so you are right Christopher.</DIV>
<DIV>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”.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Matt Priour</DIV>
<DIV> </DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<DIV style="FONT: 10pt tahoma">
<DIV><FONT face=Arial></FONT> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A
title=christopher.schmidt@nokia.com
href="mailto:christopher.schmidt@nokia.com">christopher.schmidt@nokia.com</A>
</DIV>
<DIV><B>Sent:</B> Monday, November 07, 2011 10:39 AM</DIV>
<DIV><B>To:</B> <A title=mpriour@kestrelcomputer.com
href="mailto:mpriour@kestrelcomputer.com">mpriour@kestrelcomputer.com</A> </DIV>
<DIV><B>Cc:</B> <A title=Arlo.Belshee@microsoft.com
href="mailto:Arlo.Belshee@microsoft.com">Arlo.Belshee@microsoft.com</A> ; <A
title=geojson@lists.geojson.org
href="mailto:geojson@lists.geojson.org">geojson@lists.geojson.org</A> </DIV>
<DIV><B>Subject:</B> Re: [Geojson] circles (was: Toward consensus on
proposals)</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none"><BR>On
Nov 7, 2011, at 9:53 AM, ext Matt Priour wrote:<BR><BR>> 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?<BR><BR>1. Adding in a geometry type of Circle will
almost certainly break existing<BR> parsers. We have defined a
static list of geometry types which map<BR> to native GIS types that
most clients support; extending that will<BR> likely cause parser to
blow up. Right now, the assumption is that<BR> anything which
produces GeoJSON can expect to have it consumed by<BR> GeoJSON
supporting clients. Adding new geometry types breaks that<BR>
assumption.<BR>2. One of the key points of GeoJSON is strong interoperability.
Because<BR> it is simple and limited, it is easy to implement; very
few consumers<BR> of GIS data would have a hard time round-tripping
GeoJSON with reasonable<BR> accuracy through their existing internal
data structures. Circles<BR> change that.<BR><BR>> Circles or
curved linestrings are supported by GML, EWKT and SQL-MM standards and
implemented in JTS, PostGIS 1.4+ and other programs.<BR><BR>> What is the
harm of allowing a more compact representation of these geometries?<BR>> Most
GeoJSON parsers are robust enough to just ignore unsupported types.<BR><BR>Which
GeoJSON parser do you think is robust enough to ignore<BR>unsupported types? Do
we have an analysis of what happens<BR>when you throw a circle type at various
parsers? (I'd be sort<BR>of surprised if they all 'just work' in some way; which
is <BR>part of why I'm leaning towards a representation which most<BR>clients
*will* handle by default...)<BR><BR>-- Chris<BR><BR>> <BR>> The
biggest issue I see is the radii units question. However, even with that I think
we have hit upon a good compromise:<BR>> Specify a ‘units’ member or else the
parser MUST default to coordinate units.<BR>> <BR>> Matt
Priour<BR>> <BR><BR></DIV></DIV></DIV></BODY></HTML>