Problematic routing on road_class=3 ferry routes for hikers
In the Belgium OSM forum someone reported that in the hiking profile ferry connections are avoided. http://forum.openstreetmap.org/viewtopic.php?id=26980 I noticed in Basecamp that the road_class=3 might be the reason for this (=main highways). In the internal routing routines of the Garmin Oregon, these roads are blocked by default for hiking (but not in the pedestrian mode). Solution would be to assign ferries that are blocked for motorcars (tagged on osm with motorcar/motor_vehicle=no) with road_class=0 instead of 3. Can this be done in the default line style? I can't find any route=ferry strings in the lines nor access files anymore. Where does mkgmap set this road_class?
Oops. I forgot it was set in the water_lines ;-) https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/default... So I suggest to add route=ferry & (motorcar=no | motor_vehicle=no) {add mkgmap:ferry=1} [0x1b road_class=0 road_speed=0 resolution 19] before this existing rule route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19]
Hi Minko, I think it is in inc/water_lines Gerd ligfietser wrote
In the Belgium OSM forum someone reported that in the hiking profile ferry connections are avoided. http://forum.openstreetmap.org/viewtopic.php?id=26980
I noticed in Basecamp that the road_class=3 might be the reason for this (=main highways). In the internal routing routines of the Garmin Oregon, these roads are blocked by default for hiking (but not in the pedestrian mode).
Solution would be to assign ferries that are blocked for motorcars (tagged on osm with motorcar/motor_vehicle=no) with road_class=0 instead of 3. Can this be done in the default line style? I can't find any route=ferry strings in the lines nor access files anymore. Where does mkgmap set this road_class?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Problematic-routing-on-road-class-3-ferry-rou... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Yes Gerd, I already noticed ;-) One addition, maybe set this extra rule for non-car ferries to resolution 23 instead of 19, so it renders at the same level as cycle and footways.
Hi Minko, thanks, I've committed that as r3337. Gerd
Date: Mon, 20 Oct 2014 13:15:25 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers
Yes Gerd, I already noticed ;-)
One addition, maybe set this extra rule for non-car ferries to resolution 23 instead of 19, so it renders at the same level as cycle and footways.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Gerd, I forgot a few other combinations: access=no & foot=yes vehicle=no & foot=yes Of course if cars AND pedestrians are allowed, routing will still be problematic in hiking mode, but with these rules we can eliminate the problems on foot/bike ferries. Also note that in bicycle mode this won't be an issue because road_class=3 ways are routable for cyclists.
Hi Minko, I tried route=ferry & (motorcar=no | motor_vehicle=no | foot=yes & access=no | foot=yes & vehicle=no) {add mkgmap:ferry=1} [0x1b road_class=0 road_speed=0 resolution 23] route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19] but this still doesn't catch this one: http://www.openstreetmap.org/way/24222964 which doesn't look like a ferry for motor_vehicles, but doesn't say so. I guess this is a matter of missing tagging and not missing rules? Gerd
Date: Tue, 21 Oct 2014 10:35:00 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers
Thanks Gerd,
I forgot a few other combinations: access=no & foot=yes vehicle=no & foot=yes
Of course if cars AND pedestrians are allowed, routing will still be problematic in hiking mode, but with these rules we can eliminate the problems on foot/bike ferries. Also note that in bicycle mode this won't be an issue because road_class=3 ways are routable for cyclists.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Gerd wrote:
I tried route=ferry & (motorcar=no | motor_vehicle=no | foot=yes & access=no | foot=yes & vehicle=no) {add mkgmap:ferry=1} [0x1b road_class=0 road_speed=0 resolution 23] route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19]
but this still doesn't catch this one: http://www.openstreetmap.org/way/24222964
which doesn't look like a ferry for motor_vehicles, but doesn't say so. I guess this is a matter of missing tagging and not missing rules?
Hi Gerd I guess missing tagging on OSM, this should be repaired, because now it would also allow cars (ferry is connected with ways that are accessible for cars). See also http://www.vvvaalsmeer.nl/recreatief/veerdienst (ferry looks too small for cars ;-)) But anyway, I agree it doesnt catch all ferries that are accessible for pedestrians. There is another way to approach this issue, by adding a separate routable line 0x1b with road_class=0 for pedestrians only: route=ferry & foot!=no {set foot_ferry=yes; set foot=no; add mkgmap:ferry=1 } [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry & foot_ferry=yes {setaccess=no; set foot=yes} [0x1b road_class=0 road_speed=0 resolution 23] I tested it in Basecamp and it seems to work fine.
route=ferry & foot!=no {set foot_ferry=yes; set foot=no; add mkgmap:ferry=1 } [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry & foot_ferry=yes {setaccess=no; set foot=yes} [0x1b road_class=0 road_speed=0 resolution 23]
Oops, I forgot something. Above rules dont render ferries that are tagged with foot=no Maybe this works better: route=ferry & foot!=no {set foot_ferry=yes} route=ferry {set foot=no; add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry & foot_ferry=yes {setaccess=no; set foot=yes} [0x1b road_class=0 road_speed=0 resolution 23]
More improvements: It seems setaccess=no is not the correct command (?), so I changed it into setaccess no Then it turns out that in the finalize section mkgmap notice the tag bicycle=yes and converts it into mkgmap:bicycle=yes, so it somehow switches the bicycle access flag back off (means access allowed), what I dont understand because I use 'setaccess no'. This is either a bug or I don't understand the working of the finalize section. Anyway, as workaround I have to delete also bicycle and motorcar tags in the last step (for simplicity, other vehicles like taxi, bus etc are ignored): route=ferry & foot!=no {set foot_ferry=yes} route=ferry {set foot=no; add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry & foot_ferry=yes {setaccess no; set foot=yes; delete bicycle; delete motorcar} [0x1b road_class=0 road_speed=0 resolution 23]
Hi Minko, sorry for the delay. The statement "setaccess no" sets the access tags with prefix mkgmap: to no, e.g. mkgmap:bicycle, mkgmap:taxi, mkgmap:car etc. I think that works okay. I guess you expected that it sets the similar values without the prefix? Or do you think that the finalize section should not override any value prefixed with mkgmap: ? Anyhow, I am not really happy with your solution. I have the feeling that these rules should be placed in inc/access, but it seems that one cannot override the road_class in the finalize section. @WanMil: Do you see a better solution? Gerd
Date: Wed, 22 Oct 2014 16:04:30 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers
More improvements: It seems setaccess=no is not the correct command (?), so I changed it into setaccess no Then it turns out that in the finalize section mkgmap notice the tag bicycle=yes and converts it into mkgmap:bicycle=yes, so it somehow switches the bicycle access flag back off (means access allowed), what I dont understand because I use 'setaccess no'. This is either a bug or I don't understand the working of the finalize section.
Anyway, as workaround I have to delete also bicycle and motorcar tags in the last step (for simplicity, other vehicles like taxi, bus etc are ignored):
route=ferry & foot!=no {set foot_ferry=yes} route=ferry {set foot=no; add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry & foot_ferry=yes {setaccess no; set foot=yes; delete bicycle; delete motorcar} [0x1b road_class=0 road_speed=0 resolution 23] _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Problem here is that mkgmap:bicycle=no is overruled by bicycle=yes later in the access rules, imho there is an issue in the styles. So I have to add set bicycle=no motorcar=no etc if I use set access no which I find a bit unlogical.
Hi Minko, if I got it right, the idea is to use the prefixed tags like mkgmap:bicycle only in the finalize section. So that would include also the setaccess and addaccess actions. Don't know if the current rules in inc\access are meant to preserve values with where set before. Gerd
Date: Sat, 25 Oct 2014 09:19:40 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers
Problem here is that mkgmap:bicycle=no is overruled by bicycle=yes later in the access rules, imho there is an issue in the styles.
So I have to add set bicycle=no motorcar=no etc if I use set access no which I find a bit unlogical.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am Samstag, 25. Oktober 2014, 09:31:33 schrieb Gerd Petermann:
if I got it right, the idea is to use the prefixed tags like mkgmap:bicycle only in the finalize section. So that would include also the setaccess and addaccess actions.
Don't know if the current rules in inc\access are meant to preserve values with where set before.
addaccess and setaccess are very strong rules that block most other rules, if they are used to early highway=* with addaccess=* in 'lines' block every access rule except something like'set bicycle=*'. mkgmap:* are also showstoppers, which should be used only at the end of all actions. IMHO it is correct used in the default style with inc/access in the finalize section. In my style i try to separate rendering and routing rules/actions from access rules by adding all access rules to inc/access and i try to use only add access rules there. inc/access is called in the finalize section. i prefere to preserve the original access values and the default inc/access IMHO does this in the right way Bernd -- amarok2 now playing:
participants (4)
-
Bernd Weigelt -
Gerd Petermann -
GerdP
-
Minko