Sean,<div><br></div><div>Good point about splitting circles/ellipses. Not sure I can offer anything back in that regard. </div><div><br></div><div>Re: what we gain by adding to the spec (and I think this somewhat applies to the units concerns, too) - simplicity and conciseness, I guess?</div>
<div>Just as you are able to specify a polygon with just a few points, it would be nice to do the same with circles/ellipses. A polygon with 20+ points that is really just an ellipse seems too complex, irrespective of how it gets handled when parsed. As mentioned before, right now we are storing Points with radius/axis properties. Substituting "Circle" or Ellipse there would be helpful, as at a glance you could tell what you had.</div>
<div><br></div><div>I think of GeoJSON as a lightweight non-heavy-GIS format, i.e. I want to curl and API and get back GeoJSON I can glance at. Circles/Ellipses would be helpful for us in that regard. </div><div><br></div>
<div>Andy</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 9:25 PM, Sean Gillies <span dir="ltr"><<a href="mailto:sean.gillies@gmail.com">sean.gillies@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Tim,<br>
<br>
Mathematically perfect circles and ellipses will be rare in the<br>
landscape (if possible at all) but GeoJSON isn't restricted to<br>
lanscape features. Business objects or legal entities might be<br>
circular or elliptical and I think those are completely within the<br>
GeoJSON domain. And, as you said, we don't exclude triangles just<br>
because there are no mathematically perfect triangles in the<br>
landscape.<br>
<br>
Myself, I am increasingly troubled by the following issues of adding circles:<br>
<br>
* Cut a circle in two: we have no proposal to represent the resulting<br>
patches. We *can* represent split lines and polygons. To represent<br>
pieces of or products of circles, we will need arcs, and even then we<br>
don't have a general basis for computing with pieces or products of<br>
circles.<br>
<br>
* Even if we did have a circular basis (do we have a professional<br>
mathematician who can point me to the right vocabulary?) it seems like<br>
we're going to put users in the position of having to use one type of<br>
geometry for sets of exclusively circular/elliptical features and<br>
switch to another basis (our everyday one) for computing with lines<br>
and polygons. And then how would you mix them? Take the difference of<br>
a circle and polygon for example. If the solution is that GeoJSON<br>
parsers will almost always be converting circles and ellipses to<br>
polygon approximations in order to do anything with them, are we<br>
gaining much by adding them to the spec?<br>
<br>
Martin, have you been down this road with the OGC? Do circles and<br>
ellipses actually occur in real world GML? And how do systems deal<br>
with them?<br>
<div><div></div><div class="h5"><br>
On Fri, Nov 4, 2011 at 6:03 PM, Tim Schaub <<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>> wrote:<br>
> 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>
><br>
> Tim<br>
><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>
</div></div><font color="#888888">--<br>
Sean Gillies<br>
</font></blockquote></div><br></div>