[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?
- Previous message: [mkgmap-dev] Questions about carpool handling
- Next message: [mkgmap-dev] Questions about carpool handling
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list