logo separator

[mkgmap-dev] Questions about carpool handling

From Minko ligfietser at online.nl on Mon Dec 9 08:20:41 GMT 2013

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?



More information about the mkgmap-dev mailing list