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're often pulling our OSM data out of VEX which will soon be backed by an RDBMS. That means the workflow will be RDBMS -> PBF -> MapDB -> R5. We could instead just do RDBMS -> R5.
It is tempting to just push the data from the RDBMS side through to the network builder in nodes, ways, relations order, but there are a few problems with that. The network builder can't just consume OSM entities in the order nodes, ways, relations because it may need to go back and look at the characteristics of certain nodes while it's building the edges. We don't even use the tags on the nodes, just their locations which are stored in the resulting vertices. But of course we only create vertices for the intersection nodes. And we need to iterate over all the ways once in order to find out which nodes are intersections.
So we'd have to push all the OSM data in a bounding box through several times, skipping huge chunks of the data each time. That's not more efficient. So instead we need to pull the data from the network builder side. First iterate over all the ways to find intersections or issue a query that just returns all the intersection nodes. Then fetch all the ways, and sub-fetch all the constituent nodes for each one.
Optimizations: switch off initializing the tags on the nodes (actually, very few nodes have tags so maybe not). Filter to return only highway ways and restriction relations, after filtering down to a box.
The text was updated successfully, but these errors were encountered:
We're often pulling our OSM data out of VEX which will soon be backed by an RDBMS. That means the workflow will be RDBMS -> PBF -> MapDB -> R5. We could instead just do RDBMS -> R5.
It is tempting to just push the data from the RDBMS side through to the network builder in nodes, ways, relations order, but there are a few problems with that. The network builder can't just consume OSM entities in the order nodes, ways, relations because it may need to go back and look at the characteristics of certain nodes while it's building the edges. We don't even use the tags on the nodes, just their locations which are stored in the resulting vertices. But of course we only create vertices for the intersection nodes. And we need to iterate over all the ways once in order to find out which nodes are intersections.
So we'd have to push all the OSM data in a bounding box through several times, skipping huge chunks of the data each time. That's not more efficient. So instead we need to pull the data from the network builder side. First iterate over all the ways to find intersections or issue a query that just returns all the intersection nodes. Then fetch all the ways, and sub-fetch all the constituent nodes for each one.
Optimizations: switch off initializing the tags on the nodes (actually, very few nodes have tags so maybe not). Filter to return only highway ways and restriction relations, after filtering down to a box.
The text was updated successfully, but these errors were encountered: