[GeoJSON] Values along a line in GeoJSON

[Allan Doyle]

On Aug 8, 2013, at 11:23 AM, Jerry Sievert <jerry at legitimatesounding.com>
 wrote:

> The issue exists in other format conversions as well - Well-Known Text is the first one that I ran into.
> 
> WKT solves it by defining what the attributes mean in a mostly sensical order, but is still fairly limited:
> 
> POINT (1 2), POINT Z (1 2 3), POINT M (1 2 4), POINT ZM (1 2 3 4).
> 
> 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.
> 
> Perhaps an optional array added to properties to hint at the additional attributes might be a better solution?
> 
> properties: {
>   attributes: [ 'X', 'Y', 'Z', 'M', 'H' ]
> }
> 
> X - longitude
> Y - Latitude
> Z - Altitude
> M - Moment
> H - Heart Rate
> 
> etc.
> 
> If not standardized, at least an implicit agreement for interoperability?

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.

I'd go with

{
    "type": "Point",
    "coordinates": [42.0, 72.0, 10.0],
    "moment" : 15,
    "heartrate" : 20
}

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.

	Allan

> 
> 
> 
> 
> On Thu, Aug 8, 2013 at 7:57 AM, Mike Bostock <mike at ocks.org> wrote:
> Seems to me that you could use coordinate positions of the form [x, y, a, b, c, …], where a, b, c, … represent the values on your additional dimensions. This assumes that I’m reading section 2.1.1 of the specification correctly:
> 
> 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.
> 
> If I had to nitpick, the spec seems slightly contradictory here: if only two elements are required (x and y), 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 z to represent altitude / elevation. But it probably would be a good idea to start with x, y, z, regardless.
> 
> 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.
> 
> Mike
> 
> 
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> 
> 
> _______________________________________________
> 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/20130808/80510b20/attachment.htm>