[Geojson] Toward consensus on proposals

[Evan James Bowling]

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.

On Wed, Nov 2, 2011 at 10: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?
>

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.

>
> 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
>
>
Thanks,
Evan Bowling


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111102/0b7c1604/attachment.htm>