[Geojson] Interpretation of "extra" coordinate dimensions

[Jeremy Cothran]

Hi Daniel,

Our use case for extending geojson I think falls under a similar category -
specifically in better support of recent time-series and collections of
collections - more specifically we work with a collection of observing
platforms with each platform collecting a range of observations usually say
once an hour.  The final format ended up looking like the example at

http://neptune.baruch.sc.edu/xenia/feeds/obsjson/all/latest_hours_24/ndbc:41001:met_data.json

with previous discussion on this format at
http://code.google.com/p/xenia/wiki/ObsJSON

Thanks
Jeremy

On Wed, Aug 31, 2011 at 1:03 PM, Daniel Azuma <dazuma at alumni.caltech.edu>wrote:

> Hi everyone,
>
> Just joined the list, so a quick intro: My name is Daniel Azuma. I wrote
> and maintain a GeoJSON builder/parser for Ruby called rgeo-geojson. (
> http://virtuoso.rubyforge.org/rgeo-geojson/) It parses GeoJSON into
> objects built by RGeo, which is a Ruby implementation of the OGC SF spec.
>
> Right now my parser ignores and throws away any "extra" dimensions beyond
> XYZ(M), because the SF spec (and hence RGeo) doesn't have any notion of
> dimensions beyond XYZM. However, I notice that the GeoJSON spec does allow
> for any number of dimensions in a coordinate. I wanted to ask what is
> generally expected of parsers when dealing with such "extra" dimensions,
> whether they should be considered meaningful.
>
> I ask because I have a user who wants to use extra dimensions to store
> metadata associated with point coordinates. That is, he wants to do this:
>
> {
>    "type": "Point",
>    "coordinates": [102.0, 0.0, 0.0, "2011-03-29T08:38:50Z", 3.54, 39.80]
> }
>
> where the coordinates are X, Y, Z, timestamp, speed, bearing. I responded
> to him that I thought such metadata should be represented as properties in a
> Feature object, but he prefers conciseness over expressiveness in his use
> case. So I was wondering about the intent of allowing arbitrary extra
> dimensions in a coordinate, and whether, in the opinion of the authors of
> the spec, this was a case that GeoJSON parsers do (or should) handle.
>
> Thanks!
> Daniel Azuma
>
> _______________________________________________
> 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/20110831/c40c7a1e/attachment-0004.htm>