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

Wed Apr 25 10:40:36 BST 2012

Hi all.

I have played around a bit further with my scripts and found out that
using the --legacy-mode of splitter r200 resolves that problem.

  Regards,
    Michael

On 20.04.2012 16:31, Michael Günnewig wrote:
> 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.

>>> 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