[Geojson] Toward consensus on proposals

[Carl Smyth]

In the OGC world, we’ve been trying to make specifications modular for the last few years. This usually means that there is a single core and (potentially) many modules. The modules each depend on the core and there *may* be dependencies on other modules. A developer only has to understand the modules that target a specific application. While it has been/will be hard to retrofit old monolithic standards in some cases, it’s a good structure going forward for allowing application-specific extensions that don’t create any unneeded complexity. It also encourages new ideas and lets survival of the fittest decide which are really good.

I would suggest that we might think of  GeoJSON as it exists as a core and the new proposals as modular extensions which can live or dies on their own merits.

…steve

From: geojson-bounces at lists.geojson.org [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Matt Priour
Sent: Monday, October 31, 2011 11:41 AM
To: Sean Gillies; geojson at lists.geojson.org
Subject: Re: [Geojson] Toward consensus on proposals

I’ll be the first to admit that the Data Series proposal is not fully baked. It was my attempt to simplify a specific but fairly widespread use case. Representing a series of data that is associated with a single feature is excessively onerous and there is not an accepted standardized way to do that in the current GeoJSON spec.

I was hoping that there would be some discussion of this proposal by those with the most interest in seeing this problem solved. However if the community feels that this is too specific to write into the general GeoJSON spec, then maybe I could write up a separate specification that would be an “official” extension. Maybe something like an Data Series extension to the more general spec would be more acceptable.

As to the reason the Data Series would be a privileged object and not in the normal properties, that made more sense to me since the data series would likely be tied to a specific feature with its own specific properties that would apply to all the collected data.

Two things that are most obviously lacking from the data series proposal are
1. Multi-dimensional series
2. Metadata about the observations (measurement units, full name / label of data property, etc...)

Matt Priour

From: Sean Gillies<mailto:sean.gillies at gmail.com>
Sent: Monday, October 31, 2011 12:27 PM
To: geojson at lists.geojson.org<mailto:geojson at lists.geojson.org>
Subject: [Geojson] Toward consensus on proposals

Hi all,

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.

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.

Let's discuss. I'll split the subject in two as soon as it seems needed.

--
Sean Gillies
_______________________________________________
Geojson mailing list
Geojson at lists.geojson.org<mailto: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/20111031/064e2bb8/attachment-0005.htm>