[PATCH] Bicycle routing opposite to oneways for cycleways tagged as "opposite_*"
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
Hi Stefan, Looking at your patch, I see: + oppositeWay.addTag("access","no"); Doesn't this block all access to your new cycleway? Cheers, Mark
Hi Mark,
Looking at your patch, I see:
+ oppositeWay.addTag("access","no");
I included this part because I want to force not to use the new way, except for bicycles. It doesn't help, because the way is used - even for car/motorcycles. You can delete this part - it doesn't make a difference. Stefan
Hallo Stefan, Stefan Wenk schrieb:
Hi Mark,
Looking at your patch, I see:
+ oppositeWay.addTag("access","no");
I included this part because I want to force not to use the new way, except for bicycles. It doesn't help, because the way is used - even for car/motorcycles. You can delete this part - it doesn't make a difference.
Stefan
I think the problem is that there is no rule which makes a cycleway a cycleway in the default style. What about changing highway=cycleway [0x16 road_class=0 road_speed=1 resolution 23] into highway=cycleway { add motorcar=no; add hgv=no; add motorcycle=no } [0x16 road_class=0 road_speed=1 resolution 23] ? I just did the opposite (adding bicycle=no) for motorways and it works (before Mapsource wanted me to ride my bike on the Autobahn ;-) Viele Grüße Christian
Hello Christian, thanks for your suggestion:
I think the problem is that there is no rule which makes a cycleway a cycleway in the default style. What about changing highway=cycleway [0x16 road_class=0 road_speed=1 resolution 23] into highway=cycleway { add motorcar=no; add hgv=no; add motorcycle=no } [0x16 road_class=0 road_speed=1 resolution 23]
I have tested your suggestion and it does not make a difference. I think that the device does not accept any of these tags if the destination is located at that specific way. Even with the commercial card the device directs a car into a track in a forest if the destination is in the forest located at that track and cannot be reached via an "official" car road. I think the problem is that the device is searching for a destination located at the cycleway, and not at the original oneway. Grüße Stefan
Hello, I'm sorry for the traffic. I should have performed more testing - the patch isn't working at all, not even for bicycle routing. I just thought it was. In my initial tests I was coming from another direction to the test oneway. To me it looks as if there are some limitations in the routing capability if ways are overlapping. Stefan On Saturday 21 February 2009, Stefan Wenk wrote:
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
participants (3)
-
Christian Gawron -
Mark Burton -
Stefan Wenk