[Geojson] Interpretation of "extra" coordinate dimensions

Evan James Bowling bowlin10 at msu.edu
Wed Aug 31 10:18:10 PDT 2011


I am a user of the spec *(not an author)*, have good experience with web
mapping applications, and am working on a JavaScript library that utilizes
the spec. My thoughts are as follows:

1. The GeoJSON spec should specifically forbid any dimensions beyond XYZM
until enough practical applications can be brought up to merit the
flexibility.

2. JSON in general is used for transferring small-medium datasets. Locking
down the spec on this detail can help data sets to remain readable as well
as self-describing.

3. All of the uses of GeoJSON I have come across would be functional with
the limited amount of dimensions.

4. Perhaps a more general spec can be laid out for representing more types
of spatial information, and GeoJSON would be a more restricted version using
similar property names. There are certainly a lot of new web applications
that could benefit from a shared base data structure such as games, music
notation (vexflow), white boarding tools, and mind maps.

Thanks for bringing this up Daniel!
Evan

On Wed, Aug 31, 2011 at 12: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/5cdf7ec5/attachment-0004.htm>


More information about the GeoJSON mailing list