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.<div>
<br></div><div>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.</div>
<div><br></div><div>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 (<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 "Content-Type" : " text/html ..."</div>
<div>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). </div>
<div><br></div><div>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. </div><div><br></div><div>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. :)</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks to my co-worker Nathan for input here.</div><div><br></div><div>Andy</div><div><br></div><div><div><div><div class="gmail_quote">On Fri, Nov 4, 2011 at 7:29 AM, <span dir="ltr"><<a href="mailto:christopher.schmidt@nokia.com" target="_blank">christopher.schmidt@nokia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><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 see that a compact representation of a circle would be useful for some situations.<br>
><br>
> 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.<br>
<br>
</div>BBOX is not a representation of a geometry. It's a piece of metadata about a feature<br>
or FeatureCollection. It doesn't replace a geometry.<br>
<br>
-- Chris<br>
<div><div></div><div><br>
><br>
> Martin<br>
> ********************************************************************************************************************<br>
> Cadcorp is a trading name of Computer Aided Development Corporation Limited; registered in England;<br>
> number: 1955756. Registered office : Sterling Court, Norton Road, Stevenage, Herts SG1 2JY<br>
><br>
> This email is confidential and may be privileged and should not be used, read<br>
> or copied by anyone who is not the original intended recipient. If you 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 not<br>
> warrant that any information contained in this email is accurate.<br>
> Cadcorp cannot accept liability for any statements made which are clearly the<br>
> sender's own and not expressly made on behalf of Cadcorp or one of its agents.<br>
> Please rely on your own virus check. No responsibility is taken by Cadcorp<br>
> for any damage arising out of any bug or virus infection.<br>
> ********************************************************************************************************************<br>
><br>
> _______________________________________________<br>
> Geojson mailing list<br>
> <a href="mailto:Geojson@lists.geojson.org" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br></div></div></div>