Car routing issue with --make-all-cycleways at tile boundary with cycle way lane
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
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
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? Gerd 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
mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Car-routing-issue-with-make-all-cycleways-at-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
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?
Because with --make-cycleways you create a cycleway in the same direction as the street, so that you have an alternate way for routing with a bicycle. With --make-opposite-cycleways you only create a in the opposite direction, so with bicycle=no, you cannot route any longer in the main direction. Thorsten
Gerd
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
mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Car-routing-issue-with-make-all-cycleways-at-... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
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
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
participants (3)
-
GerdP -
Michael Günnewig -
Thorsten Kukuk