
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