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
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
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:
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
I think the mergeroads branch is functional complete. I want to know
if you are happy with all changes?
In such a case I would start to document the changes which need to be
done before merging the changes to the trunk.
A short overview of the changes:
* Roads are merged which reduces the
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
I'm sorry Wanmil, I'm still not familair with all the mergeroads changes and
I'm afraid that my styles wont longer work if it is merged with the trunk
version? Or is it backwards compatible with custom styles?
I think the mergeroads branch is functional complete. I want to know
if you are
