You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to be able to handle route relations and networks:
Cycling networks
Pedestrian networks
Public transport networks.
Other case this could apply to:
Low emission zones.
A country ID with country specific rules.
These are usually not modeled as part of the edge attributes and have the following issues:
An edge can be part of multiple sets.
The attributes can be similar but different making copying the attributes to the attributes set problematic:
Workarounds
Copying the attributes:
This could be done using a namespace prefix set1_(key)=(value) for example. This is problematic because these semantics will have to be taken over and used everywhere:
Profiles interpreting the edges will need to know about the set prefix.
The resulting routes or the part building the route object need to know about this part of they let this internal bookkeeping leak to client applications.
The order of the sets is irrelevant and it becomes harder to compare profiles for edges.
Suggested solution:
We add another layer on top of the current attributes and edge has in the form of 'edge sets'. These sets could be used to express general properties about edges that are generally not part of the their attributes. This includes but is not limited to: cycling|foot|transit networks, low emissions zones, country ids
Advantages
The data model is clearer, an edge has properties but can be part of a set that is independent on it's own properties (for example a route or 'zone').
The attributes or the sets are store in one location (or per tile) and can be update without updating all member edges.
No attributes in the edges attribute set that are artificial.
Disadvantages
The concept needs to be introduces in Itinero and bleeds through everywhere:
The profiles need to implement set membership as a option.
The route output needs to become more advanced and include sets.
The data model of a tile has to be adapted to be able to store set membership.
The data model of cached edge types needs to include set membership.
The text was updated successfully, but these errors were encountered:
Problem
We need to be able to handle route relations and networks:
Other case this could apply to:
These are usually not modeled as part of the edge attributes and have the following issues:
Workarounds
Copying the attributes:
This could be done using a namespace prefix
set1_(key)=(value)
for example. This is problematic because these semantics will have to be taken over and used everywhere:set
prefix.Suggested solution:
We add another layer on top of the current attributes and edge has in the form of 'edge sets'. These sets could be used to express general properties about edges that are generally not part of the their attributes. This includes but is not limited to: cycling|foot|transit networks, low emissions zones, country ids
Advantages
Disadvantages
The text was updated successfully, but these errors were encountered: