In that attachment you find an addition to enable support for bicycle routing opposite to oneways if the way is tagged as cycleway="opposite*". If a way matches these two conditions the code creates a new overlapping way, without a "oneway" tag and "highway=cycleway" instead of the original highway type. The patch is intended for the osm routing mode. The code works for me with one drawback:If I change the routing mode from "bicycle" to "car/motorcycle" and the destination is located at one of those oneways, which are also opposite cycleways, then I'm seeing a similar behavior, which was fixed in r906/r907 earlier this week: On the first glance it looks as the device routes into the oneway, but if you look at the proposed route more closely one can see that the device directs into the artificially created cycleway. Anyway, this problem is not related to the proposed patch, because the routing on the device and mapsource currently also directs a car/motorcycle into ways, which, are tagged as "highway" = "cycleway" if the destination is there. I have verified this by removing the "oneway" tag and by changing the highway type to "cycleway" in the osm input. Maybe somebody has an idea how to fix this problem. If this problem cannot be solved, then possibly a command line option could be introduced with gives the user the choice to either create maps with optimized cycleway routing or optimized car/motorcycle routing. Stefan