<span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">I am in favor of extending the spec with a modular approach, and I think the dataseries would be a good candidate for a module. I am in favor of the second approach because a null check will be required either way, but the first dataseries proposal does not make it clear what should be used for a null value. The second approach makes this clear (i.e. the property would simply be undefined) and is more suitable for realtime editing because all previous would not need to be altered if an additional field is added.</span><br>
<br><div class="gmail_quote">On Wed, Nov 2, 2011 at 10:44 AM, Allan Doyle <span dir="ltr"><<a href="mailto:afdoyle@mit.edu">afdoyle@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm top-posting because this is a higher-level question. Let me also preface this with the disclaimer that I'm *not* a GIS person.<br>
<br>
To what extent are circles and ellipses really geospatial geometries? Would you ever have a circle or an ellipse that's a "raw" geometry or wouldn't it really be a feature?<br></blockquote><div> </div><div>
<span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">While I agree that true circles and ellipses would rarely exist as a recorded geospatial geometry, I do think they should be considered as part of the core geometry spec. I am particularly interested in using circle geometries to represent the positional error of point features. In addition, GML includes circles and arcs as part of the geometry primitives.</span> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If the use case for circles is coffee shops within a given distance, that feels like a buffer operation, not a geometry.<br>
<br>
I can see the impetus behind defining specific feature types, but that could be done outside of GeoJSON or could be a module (c.f. Steve Smyth's email).<br>
<br>
So maybe both the circle/ellipse and data series proposals should be handled as modules. If there's something inside core GeoJSON that makes it hard to do that, then we should consider how to fix that.<br>
<font color="#888888"><br>
        Allan<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">Thanks,</div>
<div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">Evan Bowling</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
<br>
On Nov 2, 2011, at 11:04 AM, Martin Daly wrote:<br>
<br>
>> We've got two proposals for changes to the spec and one that may be<br>
>> arriving (Andrew?), so it shouldn't take long to decide whether to<br>
>> accept them or not.<br>
>><br>
>> Circles and Ellipses:<br>
>> <a href="https://github.com/GeoJSONWG/geojson-" target="_blank">https://github.com/GeoJSONWG/geojson-</a><br>
>> spec/wiki/wiki/Proposal%20Circles%20and%20Ellipses%20Geoms<br>
>><br>
>> Let's be clear whether we're specifying paths or patches. Center<br>
>> coordinates + radius feels natural to me. If a CRS is defined,<br>
>> wouldn't it be best to apply those units to the radius? Otherwise,<br>
>> could we require units to always (MUST) be meters?<br>
>><br>
>> An ellipse is complicated by the two axes and their orientation.<br>
>> Defining these differently than GML does would need a strong argument.<br>
>><br>
>> Circles and ellipses can be approximated by polygons, but it becomes<br>
>> onerous for good approximations. I'm in favor of this proposal.<br>
><br>
> I'm in favour too, although I would prefer it to be circles only, as per OpenSearch Geo.<br>
><br>
> I think, while agreeing with Dale's point, that it *has* to use linear units for the radius: who has ever asked for coffee shops within a fraction of an arc second of here (to use the standard example)?<br>
><br>
> I'd be comfortable with either metres only, or the linear units of the CRS (coordinate units for projected, ellipsoid units for geographic). It is up to the software that is reading or writing the data to cope with converting to its own internal units.<br>

><br>
>> Data Series Proposal:<br>
>> <a href="https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal" target="_blank">https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal</a><br>
>><br>
>> I'm concerned about adding something so specialized to the spec and<br>
>> also wonder why a data series object needs to be privileged instead of<br>
>> simply going in the properties object.<br>
><br>
> I agree that this looks too domain-specific for the core spec.<br>
><br>
> Martin<br>
><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">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>
</div></div></blockquote></div><br>