I am a user of the spec <u>(not an author)</u>, have good experience with web mapping applications, and am working on a JavaScript library that utilizes the spec. My thoughts are as follows:<div><br></div><div>1. The GeoJSON spec should specifically forbid any dimensions beyond XYZM until enough practical applications can be brought up to merit the flexibility.</div>
<div><br></div><div>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.</div><div><br></div><div>3. All of the uses of GeoJSON I have come across would be functional with the limited amount of dimensions. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks for bringing this up Daniel!</div><div>Evan<br><br><div class="gmail_quote">On Wed, Aug 31, 2011 at 12:03 PM, Daniel Azuma <span dir="ltr"><<a href="mailto:dazuma@alumni.caltech.edu">dazuma@alumni.caltech.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi everyone,<br>
<br>
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. (<a href="http://virtuoso.rubyforge.org/rgeo-geojson/" target="_blank">http://virtuoso.rubyforge.org/rgeo-geojson/</a>) It parses GeoJSON into objects built by RGeo, which is a Ruby implementation of the OGC SF spec.<br>

<br>
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.<br>

<br>
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:<br>
<br>
{<br>
    "type": "Point",<br>
    "coordinates": [102.0, 0.0, 0.0, "2011-03-29T08:38:50Z", 3.54, 39.80]<br>
}<br>
<br>
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.<br>

<br>
Thanks!<br>
Daniel Azuma<br>
<br>
_______________________________________________<br>
Geojson mailing list<br>
<a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
</blockquote></div><br></div>