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

[Sean Gillies]

Dear all,

Going by what Andy's written – and we need to go by just that and not
other discussions elsewhere – this is about a geometry. Not every
"thing" within radius R of a point, but the set of all points within
radius R of a point. Like a polygon is the set of all points within
its rings and not all "things" within its rings.

One thing that I haven't seen pointed out yet is that we deal in
(rough) approximations of circles everyday. GIS systems routinely
buffer points, creating polyhedral approximations of circles, and ship
these almost circles around networks all the time, treating them as
geometries, not queries.

One practical reason for rejecting circles and ellipses is that we
don't have widely available algorithms for computing with them. GEOS
or JTS (for example) are based on points and polygons. What's the
union of an arbitrary number of circles. How would you compute it? How
would you represent it without resorting to polygon approximations?
How do these question affect your proposal, Andy?

I propose that we accept or reject the Circle/Ellipse proposal without
getting too caught up in the units details right now. If it can't be
solved and stalls out we can terminate it then. How does that sound?

On Wed, Nov 2, 2011 at 10:52 AM, Tim Schaub <tschaub at opengeo.org> wrote:
> 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
>>>

-- 
Sean Gillies