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

[Tim Schaub]

Yeah, I agree.  I think people want circles to represent relationships
(everything within x distance of this point on a plane or maybe on a
spheroid or maybe on planet earth, it's ambiguous), not geometries or
features.  So far, GeoJSON is just about representing geometries and
features - using coordinates to approximate the spatial extent of some
object.

If others agree that circles are critical to specify, I'm very opposed
to anything that assumes that a client is supposed to know the meters
per linear unit given a CRS identifier.

Tim

On Wed, Nov 2, 2011 at 9:44 AM, Allan Doyle <afdoyle at mit.edu> wrote:
> 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.
>
> 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?
>
> If the use case for circles is coffee shops within a given distance, that feels like a buffer operation, not a geometry.
>
> 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).
>
> 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.
>
>        Allan
>
>
> On Nov 2, 2011, at 11:04 AM, Martin Daly wrote:
>
>>> We've got two proposals for changes to the spec and one that may be
>>> arriving (Andrew?), so it shouldn't take long to decide whether to
>>> accept them or not.
>>>
>>> Circles and Ellipses:
>>> https://github.com/GeoJSONWG/geojson-
>>> spec/wiki/wiki/Proposal%20Circles%20and%20Ellipses%20Geoms
>>>
>>> Let's be clear whether we're specifying paths or patches. Center
>>> coordinates + radius feels natural to me. If a CRS is defined,
>>> wouldn't it be best to apply those units to the radius? Otherwise,
>>> could we require units to always (MUST) be meters?
>>>
>>> An ellipse is complicated by the two axes and their orientation.
>>> Defining these differently than GML does would need a strong argument.
>>>
>>> Circles and ellipses can be approximated by polygons, but it becomes
>>> onerous for good approximations. I'm in favor of this proposal.
>>
>> I'm in favour too, although I would prefer it to be circles only, as per OpenSearch Geo.
>>
>> 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)?
>>
>> 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.
>>
>>> Data Series Proposal:
>>> https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal
>>>
>>> I'm concerned about adding something so specialized to the spec and
>>> also wonder why a data series object needs to be privileged instead of
>>> simply going in the properties object.
>>
>> I agree that this looks too domain-specific for the core spec.
>>
>> 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
>



-- 
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.