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