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

[andy e]

I was a little hesitant to use those examples, because I knew it would
bring up the "isn't this just a point with a buffer?" argument.

The GPS example was probably bad. Let's go back to the CEP:

" It is defined as the radius of a circle, centered about the mean, whose
boundary is expected to include 50% of the population within it."

In the work we do, it's not always treated as a point + error. It's treated
as "any point within this area, defined by a point and axis/radius".

Yes, totally agree on the conversion. But again, what does
conversion/implementation have to do with the spec? I may convert all
lines/polygons I come across into an infinite number of points, but that
doesn't mean all shapes should just be points, right?

Re: units, I'm fine with defaulting to CRS, hence the option for specifying
something other than that. If the default CRS uses the WGS-84 datum, I
guess I'm not clear on why using "units" : "meters" isn't appropriate.

Overall, I know this is a rare use case for the spec, but I can assure you
we'd make good use of it. :)

Thanks,




On Sun, Nov 6, 2011 at 1:00 PM, <christopher.schmidt at nokia.com> wrote:

>
> On Nov 6, 2011, at 1:05 PM, ext andy e wrote:
>
> > Tim,
> >
> > Nope, totally understand about wanting examples. Correct,
> ellipses/circles on Earth. Unfortunately, can't give concrete examples in
> this setting, but think along the lines of Circular Error (
> http://en.wikipedia.org/wiki/Circular_error_probable), where, while you
> have a center point, the "point" may be anywhere within the ellipse/circle.
> A la polygons.
> > GPS error/accuracy is another valid use case, I would think.
>
> But neither of these are really 'geometries' in the classical sense; a
> point
> with an error radius around it could be easily represented as a point, with
> a property describing the attribute that it is representing. (So,
>
> {"type":"Feature", "geometry": {"type":"Point"}, {"properties":
> {"uncertainty": 5, "uncertainyUnits": "km"}}
>
> This would leave the interpretation up to the client -- where it seems it's
> going to have to belong no matter what, I believe.
>
> If we felt this was a very common use case, I'd even be willing to say that
> a point geometry can have a radius indication:
>
>  {"type":"Point", "coordinates": [], "radius": 5, "radiusUnits": "km"}
>
> (Or some such.)
>
> But I think that it's important to recognize that for most clients, you're
> not going to be able to round trip that information through almost any
> conventional GIS system if you expect them to be treated as circles --
> because
> the first thing anyone does with a circle is convert it to a Polygon :)
>
> Treating this as a common extension of point falls into a couple things I
> don't think the current spec does:
>
>  - Compatibility (treating things as 'just points') with any application
>    that doesn't understand circles; this seems valuable to me
>  - Not providing a sane approach to ellipses -- I don't know if this is
>    important or not. (I've had needs where a radius of a circle might make
>    sense, but nothing I can think of that would be more accurately
> described
>    by an ellipse than a polygon).
>
> In general, I think that circles -- because they fall outside of commonly
> implemented
> geo features -- will quickly be converted to either points, or polygons. I
> think
> that making it an optional extension of point to deliver a radius-like
> property
> which applications can take advantage of helps maintain compatibility and
> round-tripping for people who use this data, and lets applications which
> *can*
> do something with circles do something meaningful with them.
>
> (Then my problems are just reduced to the ones that I think Tim has
> already mentioned
> and I don't think are adequately covered: If the units are anything other
> than
> 'coordinate system units', I'm not sure how clients are meant to interpret
> them,
> and if they are coordinate system units, I'm not sure that they'll
> typically have
> meaning.)
>
> -- Chris
>
> > Thanks,
> >
> > Andy
> >
> >
> > 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
> > >> >
> > >> >
> ********************************************************************************************************************
> > >> > Cadcorp is a trading name of Computer Aided Development Corporation
> > >> > Limited; registered in England;
> > >> > number: 1955756. Registered office : Sterling Court, Norton Road,
> > >> > Stevenage, Herts SG1 2JY
> > >> >
> > >> > This email is confidential and may be privileged and should not be
> used,
> > >> > read
> > >> > or copied by anyone who is not the original intended recipient. If
> you
> > >> > have
> > >> > received this email in error please inform the sender and delete it
> from
> > >> > your mailbox or any other storage mechanism. Unless specifically
> stated,
> > >> > nothing in this email constitutes an offer by Cadcorp and Cadcorp
> does
> > >> > not
> > >> > warrant that any information contained in this email is accurate.
> > >> > Cadcorp cannot accept liability for any statements made which are
> > >> > clearly the
> > >> > sender's own and not expressly made on behalf of Cadcorp or one of
> its
> > >> > agents.
> > >> > Please rely on your own virus check. No responsibility is taken by
> > >> > Cadcorp
> > >> > for any damage arising out of any bug or virus infection.
> > >> >
> > >> >
> ********************************************************************************************************************
> > >> >
> > >> > _______________________________________________
> > >> > Geojson mailing list
> > >> > Geojson at lists.geojson.org
> > >> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> > >>
> > >> _______________________________________________
> > >> Geojson mailing list
> > >> Geojson at lists.geojson.org
> > >> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> > >
> > >
> > > _______________________________________________
> > > Geojson mailing list
> > > Geojson at lists.geojson.org
> > > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> > >
> > >
> >
> >
> >
> > --
> > Tim Schaub
> > OpenGeo http://opengeo.org/
> > Expert service straight from the developers.
> >
> > _______________________________________________
> > Geojson mailing list
> > Geojson at lists.geojson.org
> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111106/111bb749/attachment-0005.htm>