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

Tim Schaub tschaub at opengeo.org
Fri Nov 4 17:03:30 PDT 2011


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.



More information about the GeoJSON mailing list