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