[Geojson] Interpretation of "extra" coordinate dimensions

Arlo Belshee Arlo.Belshee at microsoft.com
Wed Aug 31 10:34:44 PDT 2011


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.

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.

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.

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.

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.

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.

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.

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.

Arlo

From: geojson-bounces at lists.geojson.org [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Evan James Bowling
Sent: Wednesday, August 31, 2011 10:18 AM
To: Daniel Azuma
Cc: geojson at lists.geojson.org
Subject: Re: [Geojson] Interpretation of "extra" coordinate dimensions

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<mailto: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<mailto: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/4ea6cb09/attachment.htm>


More information about the GeoJSON mailing list