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

[andy e]

Sean,

Good point about splitting circles/ellipses. Not sure I can offer anything
back in that regard.

Re: what we gain by adding to the spec (and I think this somewhat applies
to the units concerns, too) - simplicity and conciseness, I guess?
Just as you are able to specify a polygon with just a few points, it would
be nice to do the same with circles/ellipses. A polygon with 20+ points
that is really just an ellipse seems too complex, irrespective of how it
gets handled when parsed. As mentioned before, right now we are storing
Points with radius/axis properties. Substituting "Circle" or Ellipse there
would be helpful, as at a glance you could tell what you had.

I think of GeoJSON as a lightweight non-heavy-GIS format, i.e. I want to
curl and API and get back GeoJSON I can glance at. Circles/Ellipses would
be helpful for us in that regard.

Andy



On Fri, Nov 4, 2011 at 9:25 PM, Sean Gillies <sean.gillies at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111106/08d23ca9/attachment-0005.htm>