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. _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
