Tim,<div><br></div><div>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 (<a href="http://en.wikipedia.org/wiki/Circular_error_probable">http://en.wikipedia.org/wiki/Circular_error_probable</a>), where, while you have a center point, the "point" may be anywhere within the ellipse/circle. A la polygons.</div>
<div>GPS error/accuracy is another valid use case, I would think.</div><div><br></div><div>Thanks,</div><div><br></div><div>Andy</div><div><br><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 6:03 PM, Tim Schaub <span dir="ltr"><<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Andy,<br>
<br>
Maybe it would help sway the curve-haters if you could provide some<br>
ellipse examples.  Are we talking about ellipses on Earth?  Any links<br>
to pictures?<br>
<br>
Perhaps this one:<br>
<a href="http://maps.google.com/maps?ll=38.893956,-77.036503&z=18" target="_blank">http://maps.google.com/maps?ll=38.893956,-77.036503&z=18</a> (though I<br>
think you'd get more accuracy with a polygon)<br>
<br>
I'm not trying to be crass, I'm honestly interested.  I also know we<br>
didn't make this same request to proponents of the other geometry<br>
types.  Guess we all just bought into the point, line, poly (and<br>
multi-part cousins) without question.<br>
<font color="#888888"><br>
Tim<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Fri, Nov 4, 2011 at 5:39 PM, andy e <<a href="mailto:virtualandy@gmail.com">virtualandy@gmail.com</a>> wrote:<br>
> Thanks for the discussion/feedback on circles/ellipses. Sorry for not<br>
> responding sooner (been busy trying to work up a proposal that will get us<br>
> more time with these very circles/ellipses :) ). Also wanted to talk with<br>
> coworkers about this.<br>
> To reiterate what Sean has stated, the inclusion of circles and ellipses is<br>
> to support raw geometries and not queries/relationships/features. The data<br>
> that we are handling is purely just that - a circle or ellipse with a<br>
> radius/axii (typically in meters) and in the case of ellipses, a rotation<br>
> (typically in degrees). To be honest, Ellipses are much more important to us<br>
> than Circles, but I threw that in as "Just use a even Ellipse for a Circle"<br>
> seemed like a cop-out. I did not realize GML supported Ellipses, so I will<br>
> try to make the change to the spec to line that up.<br>
> In regards to units, in other specs, if a "unit" is not widely standardized,<br>
> it is defined by the requestor/provider. Take HTTP and Content-Type<br>
> (<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html" target="_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html</a>), where they specify<br>
> "Content-Type" : " text/html ..."<br>
> That was my intention here - to clear up any possible confusion, specify the<br>
> units. As mentioned (by Tim S and others, sorry, forgetting right now), the<br>
> problem with keeping units in the CRS occurs when you start specifying geoms<br>
> in lat/lon. Radians and CRS conversions are not very intuitive for those<br>
> without strong GIS backgrounds (like myself).<br>
> I would be okay with defaulting to CRS if no units were specified (or vice<br>
> versa with meters). Hence the option of using that field.<br>
> I realize it is somewhat repetitive/complex, but given that no one seems to<br>
> be using Circles/Ellipses anyway, maybe it just won't show up that often. :)<br>
> With regards to GEOS and JTS, I understand the concern, but wonder if we<br>
> should even think about implementation when defining the spec. As previously<br>
> mentioned, it is likely that even we will just store Ellipses/Circles this<br>
> way and convert to approximate polygons when processing.<br>
> Thanks to my co-worker Nathan for input here.<br>
> Andy<br>
> On Fri, Nov 4, 2011 at 7:29 AM, <<a href="mailto:christopher.schmidt@nokia.com">christopher.schmidt@nokia.com</a>> wrote:<br>
>><br>
>> On Nov 4, 2011, at 5:13 AM, ext Martin Daly wrote:<br>
>><br>
>> >> I propose that we accept or reject the Circle/Ellipse proposal without<br>
>> >> getting too caught up in the units details right now. If it can't be<br>
>> >> solved and stalls out we can terminate it then. How does that sound?<br>
>> ><br>
>> > I hate curves as much as, if not more than, the next person, but I can<br>
>> > see that a compact representation of a circle would be useful for some<br>
>> > situations.<br>
>> ><br>
>> > Also, while not exactly a precedent, we already have "bbox" as a compact<br>
>> > representation of a rectangular polygon, albeit restricted to the "Feature"<br>
>> > and "FeatureCollection" objects.<br>
>><br>
>> BBOX is not a representation of a geometry. It's a piece of metadata about<br>
>> a feature<br>
>> or FeatureCollection. It doesn't replace a geometry.<br>
>><br>
>> -- Chris<br>
>><br>
>> ><br>
>> > Martin<br>
>> ><br>
>> > ********************************************************************************************************************<br>
>> > Cadcorp is a trading name of Computer Aided Development Corporation<br>
>> > Limited; registered in England;<br>
>> > number: 1955756. Registered office : Sterling Court, Norton Road,<br>
>> > Stevenage, Herts SG1 2JY<br>
>> ><br>
>> > This email is confidential and may be privileged and should not be used,<br>
>> > read<br>
>> > or copied by anyone who is not the original intended recipient. If you<br>
>> > have<br>
>> > received this email in error please inform the sender and delete it from<br>
>> > your mailbox or any other storage mechanism. Unless specifically stated,<br>
>> > nothing in this email constitutes an offer by Cadcorp and Cadcorp does<br>
>> > not<br>
>> > warrant that any information contained in this email is accurate.<br>
>> > Cadcorp cannot accept liability for any statements made which are<br>
>> > clearly the<br>
>> > sender's own and not expressly made on behalf of Cadcorp or one of its<br>
>> > agents.<br>
>> > Please rely on your own virus check. No responsibility is taken by<br>
>> > Cadcorp<br>
>> > for any damage arising out of any bug or virus infection.<br>
>> ><br>
>> > ********************************************************************************************************************<br>
>> ><br>
>> > _______________________________________________<br>
>> > Geojson mailing list<br>
>> > <a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br>
>> > <a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
>><br>
>> _______________________________________________<br>
>> Geojson mailing list<br>
>> <a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br>
>> <a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
><br>
><br>
> _______________________________________________<br>
> Geojson mailing list<br>
> <a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br>
> <a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
Tim Schaub<br>
OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
Expert service straight from the developers.<br>
</div></div></blockquote></div><br></div>