Open xivk opened 4 years ago
This should be handled by the profile, as parsing can get pretty complicated with tags as except=hgv/emergency
Positive restrictions (as restriction=only_right_turn
) should be handled by an extra preprocessing step:
~~1) Start with raw OSM data 2) Preprocess this which creates relations (aka supersets) for LEZ, fixes only_right_turn into the inverse for the crossroads of 'no_left_turn', 'no_straight_on' and other fun 3) Have another valid .osm file 4) Input this in itinero 2.0 tile creation 5) Do route planning~~
Preprocess this which creates relations (aka supersets) for LEZ, fixes only_right_turn into the inverse for the crossroads of 'no_left_turn', 'no_straight_on' and other funHave another valid .osm file
Disagree with the restriction handling being in the OSM preprocessing because it requires users to change the OSM data before loading it, Itinero should handle this internally.
Agreed with reversing the relations during preprocessing.
After some more research it is concluded turning weights are different from turn restrictions. Turn restrictions can be simpler (single node) and more complex (turns with a via-way). It is possible to model a single node restriction by modelling it as infinite turning weights but it doesn't seem trivial to do the same with a restriction spanning 3 edges or more.
Internal data model
Let's go for full turn-weight support. We model turning weights on vertices using a turn-weights table. This idea is loosely is based on this research paper and it seems the CRP paper more or less contains this approach too.
We maintain a single table per vertex and the edges around that vertex are the indexes in that table. We model this as follows:
Turn weight table storage
Similar to edge types we maintain one index of highly common turning weight tables we can point to. The edge indexes are rewritten to maximize reuse of common turning weight tables. This means we have two types of turn weight tables:
global
: Commonly reused, global turn weight tables.local
: Unique local versions at tile level. The turn weight table pointer has to contain a flag at vertex level to determine the type of table.The turn weight tables can also different per used profile. We given them a string ID describing what they are for, for example 'bicycle', 'car'. These can then be reused for multiple profiles. The commonly used turning weight tables are shared.
Relation to (turn-)restrictions
There are three main types of restrictions:
local
.Conceptual data model
TBD
How is this handled from a profile perspective, what do we ask the profile and what do we store in the routing graph? The turn weight tables are the edge type equivalent, they can only be built after the routing graph has been interpreted by the profile(s).
Ideas:
Implementation
Implement turn-restriction support on a per-tile base. What needs to be done: