Store auxiliary data with edges

[emiltin]

in our "I Bike CPH" bike router app for ios and android, we provide GPS turn-by-turn navigation. we would like to use things like way type, surface, etc. to provide additional cues. this is relevant for bikes, since many bike paths don't have names.

a workaround is to encode the tags as part of the way name in the lua profile, for example "Vesterbrogade {'highway':'primary'}" or "{'highway':'cycleway','surface':'gravel'}. but this takes up extra space.

a more efficient way of storing tags and passing them to the front-end would be great. one idea would be to store the encoded tags as a separate name string, ie store "Vesterbrogade" and "{'highway':'primary'}" separately. since many ways would have the same tags, it would take up less space. but a better solution can probably be found.

[emiltin]

related to #282.

[TheMarex]

What you basically want is a a mini key-value storage engine inside OSRM that maps edge/node ids to properties. Could be worthwhile to invest some time in this, as this often comes up. However implementing this is not trivial.
Should be doable without any runtime/memory penalty if you don't use it.

[emiltin]

right. preferably, the lua script will be able set the keys/values for each way.

[systemed]

I use the way name workaround at cycle.travel. The results are heavily tokenised (one character for surface type, etc.) which saves some space and download time. But yes, a PBF-like key-val store wouldn't be a bad thing.

[TheMarex]

This would also unblock #77 since we could move the speed inside that field.

[marcioaguiar]

I'm also interested in this feature, specifically on the surface, lanes and width property. Maybe it could be customized on the profile?

[danpat]

If you can handle a second network round-trip, you can use this to get tag data:

https://github.com/mapbox/route-annotator