Questions about carpool handling
Hi, I am still very irritated about the meaning of the carpool bit of every road. The handling in the trunk is not consistent. It is handled in the following way and order: access=yes/1/true => carpool bit is cleared access=no/private => carpool bit is set carpool=yes/1/true => carpool bit is cleared carpool=no/private => carpool bit is set mkgmap:carpool=yes/1/true => carpool bit is cleared (emergency and bus is also cleared, all other bits are set) Some examples: highway=primary;access=yes the carpool bit is not set highway=primary the carpool bit is set highway=primary;carpool=yes the carpool bit is not set highway=path;access=no;foot=yes the carpool bit is set highway=secondary;mkgmap:carpool=yes the carpool bit is not set Can anybody explain how the carpool bit works? And how mkgmap should handle this bit? It should be handled correctly in the mergeroads branch. I found some threads which did not give the complete solution for me: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q4/005873.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006277.html http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012919.html Also a lot of threads complaining about non reliable carpool handling. I think above examples are a good explanation for this. WanMil
Great that you want to tackle this problem Wanmil. In Basecamp and the newer devices this is a big problem in routing. If you select bicycle mode, the carpool avoidance flag is by default activated. This means that every single road with access=no (even with bicycle=yes!) is blocked because Garmin now ignores bicycle=yes (in Mapsource and older devices bicycle=yes/no is still supported). What do you mean with "carpool bit is set/cleared"?
Great that you want to tackle this problem Wanmil. In Basecamp and the newer devices this is a big problem in routing. If you select bicycle mode, the carpool avoidance flag is by default activated. This means that every single road with access=no (even with bicycle=yes!) is blocked because Garmin now ignores bicycle=yes (in Mapsource and older devices bicycle=yes/no is still supported).
What do you mean with "carpool bit is set/cleared"?
Hi Minko, I am really talking about bits (not tags) in the compiled garmin map that define the access restrictions for each vehicle type. One bit is meant to define if a road has/is a carpool lane or not. I will commit a change to the mergeroads branch where mgkmap:carpool is not postprocessed, so mkgmap:carpool=yes sets the bit and mkgmap:carpool=no or mkgmap:carpool not defined will clear the bit in the garmin map. Then anybody can test if there is any usage of the carpool bit. I couldn't find any change in the routing behaviour. WanMil
So in the mergeroad branch the mkgmap:carpool tag will be totally independent of access=yes/no? This will be a big improvement because carpool avoidance will be one of the few instruments to block a road for traffic (access=no, bicycle=no etc are ignored by Garmin). Since Garmin sets this flag in the bicycle mode automatically on, I can use it in the style file to match bicycle=no with mkgmap:carpool=yes. At the moment this is not possible because it is connected with access=no and motorcar=no. Wanmil wrote
I am really talking about bits (not tags) in the compiled garmin map that define the access restrictions for each vehicle type. One bit is meant to define if a road has/is a carpool lane or not.
I will commit a change to the mergeroads branch where mgkmap:carpool is not postprocessed, so mkgmap:carpool=yes sets the bit and mkgmap:carpool=no or mkgmap:carpool not defined will clear the bit in the garmin map. Then anybody can test if there is any usage of the carpool bit. I couldn't find any change in the routing behaviour.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
So in the mergeroad branch the mkgmap:carpool tag will be totally independent of access=yes/no?
Yes that's the current behaviour in the mergeroad branch. The carpool bit is set if the tag mkgmap:carpool is yes or 1 or true. I am not sure if the carpool bit should be set or cleared to mark a road as carpool lane. But you can easily invert the bit by adding the following two lines to the end of the finalize block in your lines file: <finalize> ... mkgmap:carpool=yes { mkgmap:carpool=no } mkgmap:carpool!=* { mkgmap:carpool=yes } I would be happy if you (and anyone else) play a bit with the branch and report your findings. WanMil
This will be a big improvement because carpool avoidance will be one of the few instruments to block a road for traffic (access=no, bicycle=no etc are ignored by Garmin).
Since Garmin sets this flag in the bicycle mode automatically on, I can use it in the style file to match bicycle=no with mkgmap:carpool=yes. At the moment this is not possible because it is connected with access=no and motorcar=no.
Wanmil wrote
I am really talking about bits (not tags) in the compiled garmin map that define the access restrictions for each vehicle type. One bit is meant to define if a road has/is a carpool lane or not.
I will commit a change to the mergeroads branch where mgkmap:carpool is not postprocessed, so mkgmap:carpool=yes sets the bit and mkgmap:carpool=no or mkgmap:carpool not defined will clear the bit in the garmin map. Then anybody can test if there is any usage of the carpool bit. I couldn't find any change in the routing behaviour.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Wanmil wrote:
Yes that's the current behaviour in the mergeroad branch. The carpool bit is set if the tag mkgmap:carpool is yes or 1 or true. I am not sure if the carpool bit should be set or cleared to mark a road as carpool lane. But you can easily invert the bit by adding the following two lines to the end of the finalize block in your lines file:
<finalize> ... mkgmap:carpool=yes { mkgmap:carpool=no } mkgmap:carpool!=* { mkgmap:carpool=yes }
I would be happy if you (and anyone else) play a bit with the branch and report your findings.
In the default style of mergeroads-r2867 I added those two lines to the end of the finalize block but those are not recognised (I tried set mkgmap:carpool=no but this didnt work) Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool' Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool' Could not open style null Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool' Another thing I tried is to get rid of the carpool flags when access=no, for instance with cycleways this is a major bug in the mkgmap default style (cycleways are unaccesible in Basecamp in the bicycle mode). # the access tag defines all restrictions access=* { addaccess '${access}' } mkgmap:bicycle=yes { set mkgmap:carpool=no } # check for carpool lane # (carpool=yes | carpool=designated | carpool=permissive | carpool=official) { set mkgmap:carpool=yes } This didnt work too, so access=no still implies mkgmap:carpool=yes?
On Mon, Dec 09, 2013 at 09:20:41AM +0100, Minko wrote:
mkgmap:carpool=yes { mkgmap:carpool=no } [snip] Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool'
I guess you did not notice that WanMil forgot the "set". "add" would not work here, because the tag already exists and you want to override it. Best regards, Marko
Yes Marko, I thought he forgot that too, so I also tried: mkgmap:carpool=yes { set mkgmap:carpool=no } mkgmap:carpool!=* { set mkgmap:carpool=yes } Resulting in these errors: Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=* Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=* Could not open style null Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=*
I guess you did not notice that WanMil forgot the "set". "add" would not work here, because the tag already exists and you want to override it.
Best regards,
Marko
Argh, I am sorry. Of course you have to use "set mkgmap:carpool=no". The second line does not work because I forgot about the following rule taken from the documentation: "There used to be some restrictions on the kind of expression you could use. Now the only restriction is you must have at least one test that depends on a tag existing. So you cannot match on everything, regardless of tags, or test for an object that does not have a tag." The second line must look like: highway=* & mkgmap:carpool!=* { set mkgmap:carpool=yes } WanMil
Yes Marko, I thought he forgot that too, so I also tried:
mkgmap:carpool=yes { set mkgmap:carpool=no } mkgmap:carpool!=* { set mkgmap:carpool=yes }
Resulting in these errors:
Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=* Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=* Could not open style null Error in style: Error: (lines:206): Cannot start expression with: $mkgmap:carpool!=*
I guess you did not notice that WanMil forgot the "set". "add" would not work here, because the tag already exists and you want to override it.
Best regards,
Marko
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ok, error messages are gone now, but I still dont get it. In Basecamp cycleways are still avoided (when carpool avoidance is selected) even if I set highway=cycleway { set mkgmap:carpool=no }. So Basecamp still sees some carpool flag on those highways with access=no, I cant get rid of this in the style file??
Argh, I am sorry.
Of course you have to use "set mkgmap:carpool=no".
The second line does not work because I forgot about the following rule taken from the documentation: "There used to be some restrictions on the kind of expression you could use. Now the only restriction is you must have at least one test that depends on a tag existing. So you cannot match on everything, regardless of tags, or test for an object that does not have a tag."
The second line must look like: highway=* & mkgmap:carpool!=* { set mkgmap:carpool=yes }
WanMil
Hi Wanmil, I have now done some tests and here are my findings
Some examples: highway=primary;access=yes the carpool bit is not set
Ok, this is consistent with the behaviour in Basecamp
highway=primary the carpool bit is set
Are you sure carpool=1? I cant reproduce this with Basecamp.
highway=primary;carpool=yes the carpool bit is not set
Maybe because access=yes is default?
highway=path;access=no;foot=yes the carpool bit is set
This is what I notice in Basecamp too: roads are blocked with carpool avoidance on. Access=no seems no longer working, but carpool=1 or 0 works. Only if access=no implies carpool=1 then it makes sense.
highway=secondary;mkgmap:carpool=yes the carpool bit is not set
Does not make sense, roads with mkgmap:carpool=yes are avoided with carpool avoidance on, as expected.
Can anybody explain how the carpool bit works? And how mkgmap should handle this bit? It should be handled correctly in the mergeroads branch.
Since you mention this, it looks like even access=no is ignored by Basecamp. The only reason that a road is blocked in Basecamp is whether the carpool bits are set or not and how the carpool avoidance is set. Only in pedestrian mode, the carpool settings are ignored. So this is something we have take into account. Another observation: if {set access=no; set mkgmap:carpool=0} carpool bits are set anyway so the last setting doesn't clear it? Hope this helps, Minko
participants (3)
-
Marko Mäkelä -
Minko -
WanMil