Extension for per-node attributes

[e-n-f]

It would sometimes be useful to have per-node attributes within a LineString, MultiLineString, Polygon, or MultiPolygon feature, for example to link these nodes back to the OSM IDs that they came from.

I'm thinking this could look in GeoJSON something like this:

{ "type": "Feature", "properties": { ... }, "geometry": " { ... },
  "linear-attributes": [ null, null, { "node": 12345 }, { "node": 56789, "way": 66 }, null, { "node": 55 }, null ] }

where there the linear-attributes array has the same structure as the geometry.coordinates array, and each element is either null if there is no attribute, or a set of key-value pairs if there are attributes. (Or some other syntax if anybody has any better idea.)

In the vector tile, it could be part of the Feature:

repeated sint linear_attributes = 5 [ packed = true ];

where each positive number represents a key or value in the layer attributes, like in the keys, and each negative number represents (forward) motion through the geometry, so the above would be encoded as:

-2 (move 2),
0 (node), 0 (12345), -1 (move 1),
0 (node), 1 (56789), 1 (way), 2 (66), -2 (move 2),
0 (node), 3 (55), -2 (move 2)

Alternately we could define new geometry types where each position contains x and y coordinates followed by a count of attributes and a set of key-value references, since the parallel arrays might be awkward to maintain.

Any opinions on this idea?

[benjamintd]

I agree that this is a feature that would be much needed when analyzing road graphs. Working with graph normalization on tiled if was often hard to determine whether the node refs in the properties field matched with the LineString's coordinates.

Alternately we could define new geometry types where each position contains x and y coordinates followed by a count of attributes and a set of key-value references, since the parallel arrays might be awkward to maintain.

I tend to like this alternative version better. It seems easier to manipulate and extends how we have been using timestamps for telemetry so far. The only thing is that it goes against the GeoJSON standard's use of the position array.

[lucaswoj]

As I recall, @tmcw has a concrete GeoJSON syntax proposal for this feature.

[e-n-f]

Thanks @lucaswoj, I see that in https://github.com/mapbox/geojson-coordinate-properties now.

[andrewharvey]

This together with https://github.com/mapbox/geojson-coordinate-properties would hopefully help open up functionality in GL JS like mapbox/mapbox-gl-js#4095.

[andrewharvey]

@flippmoke is this being considered for mvt3?

[flippmoke]

@andrewharvey yes, it is definitely being considered. The real question here for me is a dynamic structure like that in #75 sufficient or does another more specific data structure work here.

I think for some data such as lidar data where attribute data needs to be highly compressed, the metadata indexes might benefit from delta encoded indexes to attributes. Additionally, highly compressing floating point data in this situation becomes complex as well.