logo separator

[mkgmap-dev] Questions about carpool handling

From Minko ligfietser at online.nl on Thu Dec 5 12:52:47 GMT 2013

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,


More information about the mkgmap-dev mailing list