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

Tim Schaub tschaub at opengeo.org
Sun Nov 6 16:53:36 PST 2011 

Thanks Andy.  I do believe it is important to provide some motivation
for modifying the spec, and examples help.  I was joking about the
idea that somebody would represent The Ellipse in DC as an ellipse in
GeoJSON, and guessed it was more likely about ballistics.

Again, because I believe it is important to provide some motivation
for modifying the spec, I'd be interested to think a bit more about
the potential benefits and drawbacks of adding ellipses to GeoJSON
geometries.  If there are a lot of people serializing ellipses in
different ways, and better interoperability could be gained by
specification, I'd consider that a benefit.  If very few user agents
are going to parse and maintain ellipses as geometries, that's a ding
against interoperability.  If those user agents fail in some way when
encountering an ellipse, we've introduced a significant drawback by
modifying the spec.

My guess is that very few GeoJSON parsers are going to properly deal
with ellipses.  As Sean points out, if people use any constructive
methods on an ellipse and any other geometry, GeoJSON doesn't
necessarily provide a way to serialize the results.  My point about
units may not appeal to that many others, but unless the radius units
are the same as the CRS units, a user agent cannot really do anything
at all with an ellipse in an arbitrary CRS unless they know otherwise
difficult to come by details about that CRS*.

Anyway, my feeling is that just because we *can* come up with a
concise way to represent an object in GeoJSON doesn't necessarily mean
we *should*.  I think there should be clear benefits to modifying the
spec.

Tim

* You can't approximate this ellipse as a polygon (i.e. you can't
render it, buffer it, cut it in half, or otherwise transform it)
unless you know the meters per unit of the CRS identified by "foo":

    {"type": "Circle", "coordinates": [0, 0], "radius": 1, "crs":
{"type": "name", "properties": {"name": "foo"}}}


On Sun, Nov 6, 2011 at 1:43 PM, andy e <virtualandy at gmail.com> 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?
> 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
>
>



-- 
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.

More information about the GeoJSON mailing list