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

christopher.schmidt at nokia.com christopher.schmidt at nokia.com
Sun Nov 6 12:59:55 PST 2011 

On Nov 6, 2011, at 3:43 PM, ext andy e wrote:

> 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?

Actually, that's exactly what all shapes are: 

"The "coordinates" member of a geometry object is composed of one position (in the case of a Point geometry), an array of positions (LineString or MultiPoint geometries), an array of arrays of positions (Polygons, MultiLineStrings), or a multidimensional array of positions (MultiPolygon)."

I'm suggesting that for circles (though not ellipses), I think that we 
get the same benefit out of adding an optional radius parameter to the 
point object, which could be handled at the application level. 

The reason that I prefer this is that applications which don't
'understand' circles can maintain the circle more easily than
if we create an entirely new type -- which almost all applications won't
understand, and most will just convert to a polygon.

It also means that applications which produce circles have an 
expectation of what the default behavior they can expect from
non-circle supporting clients are -- and I think that "returning
the point at the center of the circle" is more valuable than
"returning a parse error", if it's still possible to satisfy
most of the need of the circle extension.

-- Chris


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

More information about the GeoJSON mailing list