[mkgmap-dev] Car routing issue with --make-all-cycleways at tile boundary with cycle way lane

Fri Apr 20 15:31:17 BST 2012

Hi all.

On 20.04.2012 11:39, Thorsten Kukuk wrote:
> On Fri, Apr 20, GerdP wrote:
> 
>> Hi Micheal,
>>
>> I looked into the code. 
>> With --make-all-cycleways (and also with --make-cycleways) mkgmap may add a
>> tag 
>> "bicycle=no"
>> to the existing highway when it creates an additional way for the bicycle.
>> With --make-opposite-cycleways this doesn't happen.
>> I have no idea why this is not done for both cases, but it may explain the
>> different routing?

I had taken a look at that piece of code also.  Its only triggered if
the --make-all-cycleways option is given on a way with a non-opposite
cycleway.  It also just adds the "bicycle=no" onto the existing way if
it is lacking that value.  In my case the way contains an explicit
"bicycle=designated".  Though even if I change this to an explicit
"bicycle=no", the routing is still broken.

Such routing issues don't seem to occur in other areas with cycleways
being present, so I assume it is some special case here as the ways are
close to a tile border.  Could it be that the reason is the algorithm
that is used to "merge" ways again across tile borders?  I tried to find
such code, but couldn't.

  Regards,
    Michael

>> Michael Günnewig wrote
>>>
>>> Hi all.
>>>
>>> I have experimented a bit further, but the problem remains.  The logs of
>>> mkgmap does not spit out anything in that area.
>>>
>>> Has anyone some idea what the cause could be?
>>>
>>>   Regards,
>>>     Michael
>>>
>>> On 27.03.2012 22:21, Michael Günnewig wrote:
>>>> Hi all.
>>>>
>>>> I have some interesting routing issue with my self-generated OSM map
>>>> based on the All-In-One styles.  I could track the issue down in the
>>>> meantime to the --make-all-cycleways option being given to mkgmap.
>>>> The issue also occurs with old mkgmap or old splitter versions, even
>>>> though I'm quite sure that I didn't encounter it in the past.  I first
>>>> guessed that some additional data to the tiles leads to some overflow,
>>>> but even reducing the number of nodes for splitting has not resolved the
>>>> issue.
>>>>
>>>> The routing problem happens on this map excerpt:
>>>>   http://www.openstreetmap.org/?lat=51.50112&lon=7.34123&zoom=17&layers=M
>>>>
>>>> Coming from east on way 71933528 (Martener Straße) towards west to turn
>>>> left onto 55188142 (Westricher Straße) crossing the segments 55262354
>>>> and then 30889150 doesn't work on my Oregon 450, when using car routing
>>>> with --make-all-cycleways.  It usually directs me from 71933528 towards
>>>> east to do a great extra way avoiding streets with cycleways.  Bicycle
>>>> and foot routing that route works correctly nevertheless.  Also if I
>>>> just use the --make-opposite-cycleways option the car routing works also
>>>> fine with the same tiles.
>>>>
>>>> I have also already tried to explicitly forbid bicycle traffic
>>>> (bicycle=no instead of current designated) on the streets, as well as
>>>> renaming the street to just its first letter, which did not help either.
>>>>
>>>> When splitting the germany pbf files from GeoFabrik the tile border is
>>>> positioned approximately between way segments 55262354 and 30889150
>>>> (using 700k or 600k nodes).
>>>>
>>>> Any idea what the route cause could be here?
>>>>
>>>>   Regards,
>>>>     Michael