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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
