[GeoJSON] Values along a line in GeoJSON

[Jerry Sievert]

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?




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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130808/04d9b3d2/attachment-0005.htm>