<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I am also not a GeoJson spec author. I’m fairly new to this protocol. So please don’t take what I say as implying what was in the
heads of the authors as they were writing it. However, I see some strong advantages of the current design.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The need for extra dimensions shows up commonly in scientific and maritime navigational data. It also probably shows up in other places, but those I know off
the top of my head.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In both cases, you have a feature that has a spatial property that is not just a point. For example, it could be a linestring that the boat is travelling. There
are data items that you want to associate not with the path as a whole, but with each control point.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In navigation, you get cases like Daniel’s: at each point in the path, you want to store not just its location, but the bearing, speed, water depth, and other
values to aid in navigating the boat.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">You don’t want to store these at the feature level, because you need them directly mapped to the control points in your path. You could have them as separate
arrays, with cross-correlation by index, but this increases the chance of off-by-one errors resulting in crashed boats.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Similarly, marine scientific measurements often include measuring a whole bunch of different things at different locations. Again, these may be a one feature
per measurement point, but often are not. It is very reasonable for a feature to represent a particular journey, a particular body of water, or the like.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For example, you might have a feature “Mississippi River.” It has a geographic property that marks the position of the river, with measurements of flow & temperature
at each location.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">All of these are advanced uses of geospatial data. GeoJson could well choose to not support them, in order to “better” support simpler uses. But a number of
simpler uses just naturally extend to advanced uses. It’s nice to not have to change format when that happens.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Arlo<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> geojson-bounces@lists.geojson.org [mailto:geojson-bounces@lists.geojson.org]
<b>On Behalf Of </b>Evan James Bowling<br>
<b>Sent:</b> Wednesday, August 31, 2011 10:18 AM<br>
<b>To:</b> Daniel Azuma<br>
<b>Cc:</b> geojson@lists.geojson.org<br>
<b>Subject:</b> Re: [Geojson] Interpretation of "extra" coordinate dimensions<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. The GeoJSON spec should specifically forbid any dimensions beyond XYZM until enough practical applications can be brought up to merit the flexibility.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3. All of the uses of GeoJSON I have come across would be functional with the limited amount of dimensions. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for bringing this up Daniel!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Evan<o:p></o:p></p>
<div>
<p class="MsoNormal">On Wed, Aug 31, 2011 at 12:03 PM, Daniel Azuma <<a href="mailto:dazuma@alumni.caltech.edu">dazuma@alumni.caltech.edu</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>