[Talk-us] Bridges, nodes, and routing engines (Navit, Gosmore, etc)

[Chris Lawrence]

I've been playing with some of the routing engines for OSM
(YOURS/Gosmore, Navit) to try to make sure all the TIGER cleanups I've
been doing around Laredo* are working correctly, and I've stumbled
across a bit of a puzzler.

Part of my work has been to add bridges (flyovers, overpasses etc.)
where necessary along I-35, US 83, TX 255, and Loop 20.  In doing so,
I've broken the "bridges" off into separate ways and added the
bridge=yes and layer=1 (or 2, occasionally) attributes to the bridges,
but left the nodes created in the import where the ways intersect.
The problem is that the routing engines still think because there is a
shared node that the two routes intersect and you can turn there
rather than using the ramps or frontage roads to get onto the bridged
route.

Now the question is: should I remove the shared nodes (or detach them
in JOSM), or is this a bug in the routing engines that should be
fixed?  My gut feeling is that the routing engines should be smarter
(basically, don't allow a route to change layers except at the ends of
OSM ways - in other words, you can't change from layer=0 to layer=1 by
turning off a way - in other words, any sane turn off a way not at its
end can't take you across layers,** and you can only "descend" or
"ascend" layers at the ends of OSM ways) but maybe this is a cleanup
that needs to be done in the data instead.

I've been reluctant to remove the nodes since we may need them to
match up other TIGER data (for example, the addressing data really
needs the tilds off the nodes to be able to figure out how to
associate addresses with the existing imported linework- the way tlids
alone are way too imprecise for this in many cases).  And we need some
of these shared nodes to make sure the lines are in the right place
anyway - for curved bridges and the like.

Alternative three (at least for navit) would be to hack the
osm2navit.c code to figure out which nodes are intersecting ways at
the differing layers and clone them for each way as separate nodes,
but that wouldn't help other engines that use OSM directly.

Alternative four is to throw in a lot of turn restrictions, which
would just be ugly IMHO.  It would have the benefit of being easy to
retrofit alogrithmically.

Suggestions on the way to go from here?  File bugs on the routing
engines or try to figure out some way to fix this problem
systematically in OSM?


Chris

* http://www.openstreetmap.org/?lat=27.5459&lon=-99.4891&zoom=12
** Unless of course you're Evil Knievel.