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

Sun Nov 6 22:03:51 PST 2011

Weems, to me, like radius is a distance. As such, wouldn't it be represented in whatever units the datum uses for measuring distance? For WGS84, that's meters. For other non-planar coordinate systems it varies, but it is always defined.

Arlo

From: geojson-bounces at lists.geojson.org [mailto:geojson-bounces at lists.geojson.org] On Behalf Of andy e
Sent: Sunday, November 06, 2011 12:43 PM
To: geojson at lists.geojson.org
Subject: Re: [Geojson] circles (was: Toward consensus on proposals)

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Geojson at lists.geojson.org>
> >> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> >>
> >> _______________________________________________
> >> Geojson mailing list
> >> Geojson at lists.geojson.org<mailto:Geojson at lists.geojson.org>
> >> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> >
> >
> > _______________________________________________
> > Geojson mailing list
> > Geojson at lists.geojson.org<mailto: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<mailto: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/20111107/f7d151d7/attachment.htm>