<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 8, 2013, at 11:23 AM, Jerry Sievert <<a href="mailto:jerry@legitimatesounding.com">jerry@legitimatesounding.com</a>></div><div> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><div dir="ltr">The issue exists in other format conversions as well - Well-Known Text is the first one that I ran into.<div><br></div><div>WKT solves it by defining what the attributes mean in a mostly sensical order, but is still fairly limited:</div>
<div><br></div><div style="">POINT (1 2), POINT Z (1 2 3), POINT M (1 2 4), POINT ZM (1 2 3 4).</div><div style=""><br></div><div style="">We attempted to solve this in Terraformer by adding boolean properties to solve what the additional points meant. I'm not sure if this is the best method, especially if order can change, and is a failure for interoperability.</div>
<div style=""><br></div><div style="">Perhaps an optional array added to properties to hint at the additional attributes might be a better solution?</div><div style=""><br></div><div style="">properties: {</div><div style=""> attributes: [ 'X', 'Y', 'Z', 'M', 'H' ]</div>
<div style="">}</div><div style=""><br></div><div style="">X - longitude</div><div style="">Y - Latitude</div><div style="">Z - Altitude</div><div style="">M - Moment</div><div style="">H - Heart Rate</div><div style=""><br></div><div style="">etc.</div>
<div style=""><br></div><div style="">If not standardized, at least an implicit agreement for interoperability?</div></div></blockquote><div><br></div>It seems as though you're basically trying to shove CSV into an array. That's perfectly legitimate, but seems counter to the spirit of JSON. Especially if you're explicitly serializing/deserializing it and using it in structures internally.</div><div><br></div><div>I'd go with</div><div><br></div><div><div>{</div><div><div><div> "type": "Point",</div><div> "coordinates": [42.0, 72.0, 10.0],</div><div> "moment" : 15,</div><div> "heartrate" : 20</div><div>}</div><div><br></div><div>Some of the data that can be found in a gpx file is non-numeric, e.g. waypoint names, so those would have to be carried outside the array anyway.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Allan</div><div><br></div></div></div><blockquote type="cite"><div dir="ltr"><div style=""><br></div><div style=""><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 7:57 AM, Mike Bostock <span dir="ltr"><<a href="mailto:mike@ocks.org" target="_blank">mike@ocks.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Seems to me that you could use coordinate positions of the form [<i>x</i>, <i>y</i>, <i>a</i>, <i>b</i>, <i>c</i>, …], where <i>a</i>, <i>b</i>, <i>c</i>, … represent the values on your additional dimensions. This assumes that I’m reading section 2.1.1 of the specification correctly:<div>
<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A position is represented by an array of numbers. There must be at least two elements, and may be more. The order of elements must follow x, y, z order (easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). Any number of additional elements are allowed -- interpretation and meaning of additional elements is beyond the scope of this specification.</blockquote>
<div><br></div></div><div>If I had to nitpick, the spec seems slightly contradictory here: if only two elements are required (<i>x</i> and <i>y</i>), and the interpretation and meaning of additional elements is beyond the scope of the specification, then it seems to me like it wouldn’t be strictly required for the third dimension <i>z</i> to represent altitude / elevation. But it probably would be a good idea to start with <i>x</i>, <i>y</i>, <i>z</i>, regardless.</div>
<div><br></div><div>A related problem is whether the GeoJSON should be self-describing in naming these additional dimensions, or if the reader simply has to know what they mean. I don’t know the answer here.</div><span class="HOEnZb"><font color="#888888"><div>
<br>
</div><div>Mike<br></div><div><br></div></font></span></div>
<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>
<br></blockquote></div><br></div>
_______________________________________________<br>GeoJSON mailing list<br><a href="mailto:GeoJSON@lists.geojson.org">GeoJSON@lists.geojson.org</a><br>http://lists.geojson.org/listinfo.cgi/geojson-geojson.org<br></blockquote></div><br></body></html>