I've thought about this a bit more and instead of attaching this to the instructions we should create a new details sections. This way we can show all the details not just a summary of the streets between turns. Also interesting to fetch arbitrary OSM data from a route and potentially interesting for the map matching component.

The only problem is the potential big result set for long routes, but we could optimize this a bit via using the interval instead of repeating the geometry here again. Here is what I thought:

"details": {
 "surface": { "unpaved": [[0, 3], [7,11], ...] },
 "avg-speed" : { 69 : [[0,10], ..] },
 "street-type": { "motorway": [[0, 10], ...]}
}

The interval notation is used identical to the instructions pointing with the index into the points array. To save a bit space one could also use [index, offset] instead, not sure. We need to find a balance between simplicity and compactness.

Furthermore all these key|value pairs should be more or less independent from OSM as we have to support other data sets here.

Additionally we could provide a statistics entry doing some simple average or max/min calculations for every key|value pair:

"statistics": {
 "surface": { "unpaved": 0.69 },
 "avg-speed" : { 69 : 0.05, 56: 0.04, ... },
 "street-type": { "motorway": 0.66, ... }
}

Lastly we can even point out the internal edge representation for debugging purposes as well as for an efficient way on the client side to split the data into meaningful 'street segments':

"details": {
"edges": { 
   "ids": [1,2, ...], 
   "lengths": [1, 7, 6, 5, ...]
}}

Where lengths is the number of coordinates for each edge and an edge is then the connection between two junctions.

Add speed, time and more informations to instructions #439

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions