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

[Sean Gillies]

Tim,

Mathematically perfect circles and ellipses will be rare in the
landscape (if possible at all) but GeoJSON isn't restricted to
lanscape features. Business objects or legal entities might be
circular or elliptical and I think those are completely within the
GeoJSON domain. And, as you said, we don't exclude triangles just
because there are no mathematically perfect triangles in the
landscape.

Myself, I am increasingly troubled by the following issues of adding circles:

* Cut a circle in two: we have no proposal to represent the resulting
patches. We *can* represent split lines and polygons. To represent
pieces of or products of circles, we will need arcs, and even then we
don't have a general basis for computing with pieces or products of
circles.

* Even if we did have a circular basis (do we have a professional
mathematician who can point me to the right vocabulary?) it seems like
we're going to put users in the position of having to use one type of
geometry for sets of exclusively circular/elliptical features and
switch to another basis (our everyday one) for computing with lines
and polygons. And then how would you mix them? Take the difference of
a circle and polygon for example. If the solution is that GeoJSON
parsers will almost always be converting circles and ellipses to
polygon approximations in order to do anything with them, are we
gaining much by adding them to the spec?

Martin, have you been down this road with the OGC? Do circles and
ellipses actually occur in real world GML? And how do systems deal
with them?

On Fri, Nov 4, 2011 at 6:03 PM, Tim Schaub <tschaub at opengeo.org> wrote:
> Hey Andy,
>
> Maybe it would help sway the curve-haters if you could provide some
> ellipse examples.  Are we talking about ellipses on Earth?  Any links
> to pictures?
>
> Perhaps this one:
> http://maps.google.com/maps?ll=38.893956,-77.036503&z=18 (though I
> think you'd get more accuracy with a polygon)
>
> I'm not trying to be crass, I'm honestly interested.  I also know we
> didn't make this same request to proponents of the other geometry
> types.  Guess we all just bought into the point, line, poly (and
> multi-part cousins) without question.
>
> Tim
>
>
>
> On Fri, Nov 4, 2011 at 5:39 PM, andy e <virtualandy at gmail.com> wrote:
>> Thanks for the discussion/feedback on circles/ellipses. Sorry for not
>> responding sooner (been busy trying to work up a proposal that will get us
>> more time with these very circles/ellipses :) ). Also wanted to talk with
>> coworkers about this.
>> To reiterate what Sean has stated, the inclusion of circles and ellipses is
>> to support raw geometries and not queries/relationships/features. The data
>> that we are handling is purely just that - a circle or ellipse with a
>> radius/axii (typically in meters) and in the case of ellipses, a rotation
>> (typically in degrees). To be honest, Ellipses are much more important to us
>> than Circles, but I threw that in as "Just use a even Ellipse for a Circle"
>> seemed like a cop-out. I did not realize GML supported Ellipses, so I will
>> try to make the change to the spec to line that up.
>> In regards to units, in other specs, if a "unit" is not widely standardized,
>> it is defined by the requestor/provider. Take HTTP and Content-Type
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), where they specify
>> "Content-Type" : " text/html ..."
>> That was my intention here - to clear up any possible confusion, specify the
>> units. As mentioned (by Tim S and others, sorry, forgetting right now), the
>> problem with keeping units in the CRS occurs when you start specifying geoms
>> in lat/lon. Radians and CRS conversions are not very intuitive for those
>> without strong GIS backgrounds (like myself).
>> I would be okay with defaulting to CRS if no units were specified (or vice
>> versa with meters). Hence the option of using that field.
>> I realize it is somewhat repetitive/complex, but given that no one seems to
>> be using Circles/Ellipses anyway, maybe it just won't show up that often. :)
>> With regards to GEOS and JTS, I understand the concern, but wonder if we
>> should even think about implementation when defining the spec. As previously
>> mentioned, it is likely that even we will just store Ellipses/Circles this
>> way and convert to approximate polygons when processing.
>> Thanks to my co-worker Nathan for input here.
>> Andy
>> On Fri, Nov 4, 2011 at 7:29 AM, <christopher.schmidt at nokia.com> wrote:
>>>
>>> On Nov 4, 2011, at 5:13 AM, ext Martin Daly wrote:
>>>
>>> >> I propose that we accept or reject the Circle/Ellipse proposal without
>>> >> getting too caught up in the units details right now. If it can't be
>>> >> solved and stalls out we can terminate it then. How does that sound?
>>> >
>>> > I hate curves as much as, if not more than, the next person, but I can
>>> > see that a compact representation of a circle would be useful for some
>>> > situations.
>>> >
>>> > Also, while not exactly a precedent, we already have "bbox" as a compact
>>> > representation of a rectangular polygon, albeit restricted to the "Feature"
>>> > and "FeatureCollection" objects.
>>>
>>> BBOX is not a representation of a geometry. It's a piece of metadata about
>>> a feature
>>> or FeatureCollection. It doesn't replace a geometry.
>>>
>>> -- Chris
>>>
>>> >
>>> > Martin

-- 
Sean Gillies