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

[andy e]

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

>
> 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 guess my point here was: We still specify the type as more than just
Point/Points. Even though internally clients may treat everything as a
series of Points.


> 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.
>
>
I thought about this when writing up the spec, but didn't want to force
clients looking for Circles to parse every Point looking for a radius
value. This is what we are doing now within MongoDB, storing Points with
radius/axis properties. It works that way, just isn't ideal. And hey, spec
changes gave us the option to make it 'ideal' for our use case. :)


> -- Chris
>

This second point (and my co-worker) presented things in a new light for
me. I tend to think of spec as "here's what the spec is, it's up to you how
you want to support it". A la HTTP (you can parse the HTTP message, but may
not handle the content type). This might be a bad assumption, but it seems
the geo-community tends towards a view where support a spec means being
able to process/handle that data and if valid, I can understand that.

A client that can't handle Circles/Ellipses (or doesn't want to) can parse
the JSON fine and ignore those geometries, or return a response indicating
as such. In my view, parsing is different from "conversion" or how a
provider/consumer might treat it internally.

But, I can see why that would be avoided, especially in a use case that
isn't widespread.

Andy


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