Question on routing difference
Hi all, I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all. My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; } But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM. Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip Thanks Jan
Hi Jan, might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference Hi all, I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all. My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; } But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM. Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice. Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Jan, not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference Hi Gerd, do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice. Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Jan, the artifical way would be a highway=residential, not path. Anyhow, I tried to reproduce the different routing results with the mentioned change in the OFM lite style but found no difference, the wanted route is calculated for both versions. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 29. Mai 2022 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference Hi Jan, not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference Hi Gerd, do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice. Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, here OFM lite gives the same unwanted result as OFM full :-( Jan
Am 29.05.2022 um 14:54 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
the artifical way would be a highway=residential, not path. Anyhow, I tried to reproduce the different routing results with the mentioned change in the OFM lite style but found no difference, the wanted route is calculated for both versions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 29. Mai 2022 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Jan,
not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice.
Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi jan, maybe my routing profile for OFM bike is different? Not sure what Minko recommends today. Mine says "Faster Time", Standard Elevation Mode, only road type avoidance is for "Roll Roads". When I remove the toll roads avoidance the route is different and follows the major road. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 16:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference Hi Gerd, here OFM lite gives the same unwanted result as OFM full :-( Jan
Am 29.05.2022 um 14:54 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
the artifical way would be a highway=residential, not path. Anyhow, I tried to reproduce the different routing results with the mentioned change in the OFM lite style but found no difference, the wanted route is calculated for both versions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 29. Mai 2022 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Jan,
not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice.
Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I just played with the routing prefs to see if I could change something ;-) I´m using it like this: https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png <https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png> And same here, checked toll-avoidance routes as preferred, unchecked over the primary. Toll-avoidance should prefer bicycleroutes according to Minko. I´ve unchecked long ago for some reason, don´t remember why and have to recompare. But same as no path is routed there is no bicycleroute … Jan
Am 29.05.2022 um 16:17 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi jan,
maybe my routing profile for OFM bike is different?
Not sure what Minko recommends today. Mine says "Faster Time", Standard Elevation Mode, only road type avoidance is for "Roll Roads". When I remove the toll roads avoidance the route is different and follows the major road.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 16:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
here OFM lite gives the same unwanted result as OFM full :-(
Jan
Am 29.05.2022 um 14:54 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
the artifical way would be a highway=residential, not path. Anyhow, I tried to reproduce the different routing results with the mentioned change in the OFM lite style but found no difference, the wanted route is calculated for both versions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 29. Mai 2022 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Jan,
not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice.
Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Garmin routing seems to be like it uses only major roads (based on route class) to figure out any longer routes and uses small roads only in the beginning and end to get to the larger routes. This is a pain in bicycle routing because it can direct to large roads even when wanted. It seems if there is no valid route, garmin uses what is has. It can direct bicycle to a bicycle=no road like a major trunk or motorway. (That is at least how my cycling garmin devices definately work, even in cycle mode). If you increase road class of smaller roads, they get taken into account too. But the route calculation and recalculation can be VERY long. When I tried elevating cycleways to similar class with motorways, a 17km route took on some earlier devices something like 20mins to calculate/recalculate the route. I've never tried toll roads. Petrhaps I could misuse that in my style to make large roads that bicycle is not allowed to be "toll" and make garmin avoid them better. This message gave me an idea to try out. I've no idea how well that would work as there are practically no toll roads where I live. On 5/29/22 5:17 PM, Gerd Petermann wrote:
Hi jan,
maybe my routing profile for OFM bike is different?
Not sure what Minko recommends today. Mine says "Faster Time", Standard Elevation Mode, only road type avoidance is for "Roll Roads". When I remove the toll roads avoidance the route is different and follows the major road.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 16:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
here OFM lite gives the same unwanted result as OFM full :-(
Jan
Am 29.05.2022 um 14:54 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
the artifical way would be a highway=residential, not path. Anyhow, I tried to reproduce the different routing results with the mentioned change in the OFM lite style but found no difference, the wanted route is calculated for both versions.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 29. Mai 2022 14:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Jan,
not sure if you would find it with that id, since it would be an artificial way. Don't have time now, will look into this later.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Sonntag, 29. Mai 2022 14:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Question on routing difference
Hi Gerd,
do you mean another routable line? All (routable) highways are echotagged in my style atm, but I can´t find 27463238 twice.
Jan
Am 29.05.2022 um 09:16 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Jan,
might be the oneway:bicycle=no on way 27463238 which can create an additional path in the opposite direction.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Samstag, 28. Mai 2022 20:15 An: Development list for mkgmap Betreff: [mkgmap-dev] Question on routing difference
Hi all,
I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all.
My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; }
But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM.
Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip
Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Harri, Thats why I use on my Openfietsmap not routable lines for highways with bicycle=no. I misuse the avoidance of toll roads to force the routing to take cycle routes only. In my scripts I retag all highways that are not part of a cycle route relation with toll=yes, and all cycle routes with toll=no I also "upgrade" cycleways and lower classified roads, but this comes indeed with a penalty of slow or even impossible route calculations.
Hi all, we had some discussions on the weirdness of Garmin's routing algorithm in the past. In August 2014, I described an example, and popej could give a good explanation: https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/thread.html#21825 Beyond that, "newer" Garmin outdoor devices (ehm, my Oregon is from 2013) have "activity routing" which causes odd artifacts even when you think that you do not use it: it may send a car to a cycleway parallel to a primary road. or a bicycle onto a motorway. Hence the trick by ligfietser to use non-routable lines for non-cyclable ways is important. Perhaps you can find the messages some where on the forum https://forum.openstreetmap.org/ Regards, Bernhard Am 07.06.2022 um 16:16 schrieb lig fietser:
Harri, Thats why I use on my Openfietsmap not routable lines for highways with bicycle=no. I misuse the avoidance of toll roads to force the routing to take cycle routes only. In my scripts I retag all highways that are not part of a cycle route relation with toll=yes, and all cycle routes with toll=no I also "upgrade" cycleways and lower classified roads, but this comes indeed with a penalty of slow or even impossible route calculations.
Hi Minco Thanks for your suggestion of using the toll option. On my Fenix, this option is not available but instead I have used 'ferry' as a tag and this seems to work! r Nick On 07/06/2022 15:16, lig fietser wrote:
Harri, Thats why I use on my Openfietsmap not routable lines for highways with bicycle=no. I misuse the avoidance of toll roads to force the routing to take cycle routes only. In my scripts I retag all highways that are not part of a cycle route relation with toll=yes, and all cycle routes with toll=no I also "upgrade" cycleways and lower classified roads, but this comes indeed with a penalty of slow or even impossible route calculations.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I'm had problems combining different maps to a single file with mkgmap (latest version but this has been a long term problem) What are the requirements for combining? I seem to not find any documentation about it other than that mapname should be different on files. I'm generating multiple files, all with different family-id, product-id, mapname and map description. They all use different typ-files matching the file family/product-id of the compiled map. Combining with gmaptool (command-line on linux) has been successful with "./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very old 2015 version, just because I have had it installed) Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" give very small files and I get warnings like "WARNING (global): Could not copy MAKEGMAP.MPS uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists" What is the correct way to go? (Only my basemap has routing information, other files are overlay info like fixme marking, oneway arrows and similar) Chears, Harri
Hi Harri, you seem to try to combine different gmapsupp files? I think this is not supported by mkgmap. Why don't you combine the wanted tiles instead? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Harri Suomalainen <hsuomal@welho.com> Gesendet: Dienstag, 1. November 2022 14:09 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Combining img files to a single map I'm had problems combining different maps to a single file with mkgmap (latest version but this has been a long term problem) What are the requirements for combining? I seem to not find any documentation about it other than that mapname should be different on files. I'm generating multiple files, all with different family-id, product-id, mapname and map description. They all use different typ-files matching the file family/product-id of the compiled map. Combining with gmaptool (command-line on linux) has been successful with "./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very old 2015 version, just because I have had it installed) Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" give very small files and I get warnings like "WARNING (global): Could not copy MAKEGMAP.MPS uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists" What is the correct way to go? (Only my basemap has routing information, other files are overlay info like fixme marking, oneway arrows and similar) Chears, Harri _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes, I've been trying to combine multiple gmapsupp files. I have a workflow that makes uses mkgmap to make several files from the same splitted files using "mkgmap -gmapsupp ..." How does one combine tiles when there are multiple styles used with same source tiles? Compile without -gmapsupp option and then combine multiple .img -files? (Are there restrictions like should they be same family or whatever, as long as different mapname/id?) At the moment I have tiles, use mkgmap with some style and then run mkgmap with another style to make overlay like arrows for oneway streets and I need to combine that kind of results. On 1.11.2022 20.11, Gerd Petermann wrote:
Hi Harri,
you seem to try to combine different gmapsupp files? I think this is not supported by mkgmap. Why don't you combine the wanted tiles instead?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Harri Suomalainen <hsuomal@welho.com> Gesendet: Dienstag, 1. November 2022 14:09 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Combining img files to a single map
I'm had problems combining different maps to a single file with mkgmap (latest version but this has been a long term problem)
What are the requirements for combining? I seem to not find any documentation about it other than that mapname should be different on files.
I'm generating multiple files, all with different family-id, product-id, mapname and map description. They all use different typ-files matching the file family/product-id of the compiled map.
Combining with gmaptool (command-line on linux) has been successful with "./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very old 2015 version, just because I have had it installed)
Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" give very small files and I get warnings like "WARNING (global): Could not copy MAKEGMAP.MPS uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists"
What is the correct way to go? (Only my basemap has routing information, other files are overlay info like fixme marking, oneway arrows and similar)
Chears, Harri _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Harri, I don't understand why you want to combine the different gmapsupp files. What would be the advantage compared to having multiple files? I have four or five different gmapsupp on my device, I can enable/disable each and I can update each one separately. Why would I want to combine them into one large file? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Harri Suomalainen <hsuomal@welho.com> Gesendet: Mittwoch, 2. November 2022 15:44 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Combining img files to a single map Yes, I've been trying to combine multiple gmapsupp files. I have a workflow that makes uses mkgmap to make several files from the same splitted files using "mkgmap -gmapsupp ..." How does one combine tiles when there are multiple styles used with same source tiles? Compile without -gmapsupp option and then combine multiple .img -files? (Are there restrictions like should they be same family or whatever, as long as different mapname/id?) At the moment I have tiles, use mkgmap with some style and then run mkgmap with another style to make overlay like arrows for oneway streets and I need to combine that kind of results. On 1.11.2022 20.11, Gerd Petermann wrote:
Hi Harri,
you seem to try to combine different gmapsupp files? I think this is not supported by mkgmap. Why don't you combine the wanted tiles instead?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Harri Suomalainen <hsuomal@welho.com> Gesendet: Dienstag, 1. November 2022 14:09 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Combining img files to a single map
I'm had problems combining different maps to a single file with mkgmap (latest version but this has been a long term problem)
What are the requirements for combining? I seem to not find any documentation about it other than that mapname should be different on files.
I'm generating multiple files, all with different family-id, product-id, mapname and map description. They all use different typ-files matching the file family/product-id of the compiled map.
Combining with gmaptool (command-line on linux) has been successful with "./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very old 2015 version, just because I have had it installed)
Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" give very small files and I get warnings like "WARNING (global): Could not copy MAKEGMAP.MPS uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists"
What is the correct way to go? (Only my basemap has routing information, other files are overlay info like fixme marking, oneway arrows and similar)
Chears, Harri _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Harri, to keep your workflow you could possibly generate the .imgs with overlay info --transparent and give them increasingly higher --draw-priority to control, which is painted on top of which. Modern devices allow to enable and use multiple map layers this way, although heritage devices may not.
Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" Wouldn't the mkgmap syntax treat at least the last file named on the command line as typfile? <https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files>(https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files <https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files>)
But: In an old shellscript I do successfully merge multiple .imgs into one final .img using mkgmap with an args-file for the final map (including --gmapsupp) and several --input-file=....img lines for the individual .imgs. The individual .img's typfiles all are given individual names during the individual maps creation, although they typically (but not enforced) where just copies of the same source typfile in my usecase. No typfile named for the final map. The outcome works on Garmin Edge devices as well as QMapShack on Linux. # concatenate maps from subregions (if any) to main region ... # create options.arg file echo "overview-mapname=${MAPNAME}" > ${ARGS} echo "overview-mapnumber=${MFID}0000" >> ${ARGS} ... echo "draw-priority=30" >> ${ARGS} echo "transparent" >> ${ARGS} echo "gmapsupp" >> ${ARGS} for SUBDIR in $(ls -d "${PROJDIR}/${MREGION}/"*/) do if ! [ ${SUBDIR: -5} == ".bak/" ] 2> /dev/null then # ${SUBDIR} is subregion not .bak dir for IMGFILE in $(ls -d "${SUBDIR}"*.img 2> /dev/null) do echo "input-file=${IMGFILE}" >> ${ARGS} done fi done echo "output-dir=${PROJDIR}/tmp/" >> ${ARGS} echo "verbose" >> ${ARGS} # run mkgmap to tmp mkgmap -c ${ARGS} ... Cheers Felix
Thanks for all the tips everyone. I've been thinking the choises for a while and it seems probably the best way is to include all the symbols I need in a common TYP file and convert it all to overlays. The reason I would have liked to combine different files was it was very convinient to make something like one-way arrows separately in all roads (no need to include continue in every road statement). Separate files have worked fine with newer devices but I still use some older one that does not allow many img-files. Perhaps I just need to retire it finally. Thanks for the help everyone! A combination of different suggestions (and tinkering with the styles a bit) should do what I need. (at least with accepting it will hurt some older device). On 3.11.2022 11.47, Felix Herwegh wrote:
Harri,
to keep your workflow you could possibly generate the .imgs with overlay info --transparent and give them increasingly higher --draw-priority to control, which is painted on top of which. Modern devices allow to enable and use multiple map layers this way, although heritage devices may not.
Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp basemap.img fixme.img oneway.img" Wouldn't the mkgmap syntax treat at least the last file named on the command line as typfile? <https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files>(https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files <https://wiki.openstreetmap.org/wiki/Mkgmap/help/TYP_files>)
But: In an old shellscript I do successfully merge multiple .imgs into one final .img using mkgmap with an args-file for the final map (including --gmapsupp) and several --input-file=....img lines for the individual .imgs. The individual .img's typfiles all are given individual names during the individual maps creation, although they typically (but not enforced) where just copies of the same source typfile in my usecase. No typfile named for the final map. The outcome works on Garmin Edge devices as well as QMapShack on Linux.
# concatenate maps from subregions (if any) to main region ... # create options.arg file echo "overview-mapname=${MAPNAME}" > ${ARGS} echo "overview-mapnumber=${MFID}0000" >> ${ARGS} ... echo "draw-priority=30" >> ${ARGS} echo "transparent" >> ${ARGS} echo "gmapsupp" >> ${ARGS} for SUBDIR in $(ls -d "${PROJDIR}/${MREGION}/"*/) do if ! [ ${SUBDIR: -5} == ".bak/" ] 2> /dev/null then # ${SUBDIR} is subregion not .bak dir for IMGFILE in $(ls -d "${SUBDIR}"*.img 2> /dev/null) do echo "input-file=${IMGFILE}" >> ${ARGS} done fi done echo "output-dir=${PROJDIR}/tmp/" >> ${ARGS} echo "verbose" >> ${ARGS}
# run mkgmap to tmp mkgmap -c ${ARGS} ...
Cheers Felix
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hey Harri, do not retire an old friend easily. Re-reading my mail, I may have falsely assumed things as given and been to brief in places. Rereading yours carefully, I think, I see potential tripping points now. Why not give it one last fight? Nevertheless, the following is based on trial 'n error only (quite old trials even, from when I started to experiment with mkgmap), but I manually went through all the motions again right now and the merged maps load well. If things are misinterpreted along the way, please everybody pipe in . As for the potential tripping points: 1. Your first mail reads: "I'm generating multiple files [.imgs], all with different family-id, product-id, mapname and map description." But then your second mail details: "At the moment I have tiles, use mkgmap with some style and then run mkgmap with another style to make overlay like arrows for oneway streets and I need to combine that kind of results." I'm assuming you start with some Geofabric file, maybe use osmconvert with a bbox or polygone and then splitter, to get the tiles. One argument of splitter should be --mapid. I typically use --mapid=FID0001, e.g. --mapid=64100001 for a map wit FID 6410. These mapids stick with the tiles. If you reuse the tiles for different maps and the try to merge those into one final map, there will be conflicts. Please try, to split separate tiles with separate mapids for each of the maps to be merged. 2. Also from the first mail: " They all use different typ-files matching the file family/product-id of the compiled map." * From my understanding, there is no such thing, like a type-file having FID or PID, other than by filename. I know that TYPViewer has FID info in its header section, but afaik that is informal (comment) only. At least, when using UTF8 typefiles (I'm on Linux). TYPViewer exports/imports/converts UTF8 <-> .typ. If an UTF8 typefile (having whatever FID in the header) is provided to mkgmap on the commandline, mkgmap too compiles to .typ (on-the-fly, during map generation, saved to the working directory) and uses it for that generated map correctly. Works standalone too, iirc. * On the other hand, one .img can only use one typefile (although it can contain multiple, see below, 2.nd test). Hence all elements for the final map, must be declared in the typefile _used_ by the map. On merging maps (like we target here), only one of the individual maps typefiles gets used for the result; from the sample below, this could be the alphabetically first typefile (Gerd?). Its selection is not dependant on the order of calling the input files. So you can use the same typefile (w/o any modifications/adaptions) for different maps (I do that all the time) but you should take care, that the one used in the merged map has definitions for all elements of all maps merged. Maybe you'd want to use that one for the individual maps then anyway (last sample below). #1 Lets merge an .img file of Mallorca from 2 separate (simple) .imgs (built using the same, only renamed typefile): felix@TCHd:~/Downloads/mergetest$ ls -al insgesamt 92 drwxr-xr-x 2 felix felix 4096 Nov 26 16:41 . drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 .. -rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img -rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img -rw-r--r-- 1 felix felix 710 Feb 24 2020 options.arg felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Acuts-6410.img gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu File: Malle-Acuts-6410.img, length 61440 Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0 Mapset: TKM_Malle-Acuts-6410 Map length s-f CP prio PID FID name MAKEGMAP MPS 95 1 64106410 MPC 53363 3 1252 60 T 1 6410 TKM_Malle-Acuts-6410 06410FM1 TYP 888 1 1252 1 6410 00006410 SRT 912 1 Data MPS F: PID 1, FID 6410, TrackMap V: OSM map set (0) felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Bcuts-6420.img gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu File: Malle-Bcuts-6420.img, length 20480 Header: 27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0 Mapset: TKM_Malle-Bcuts-6420 Map length s-f CP prio PID FID name MAKEGMAP MPS 95 1 64206420 MPC 12475 3 1252 60 T 1 6420 TKM_Malle-Bcuts-6420 06420FM1 TYP 888 1 1252 1 6420 00006420 SRT 912 1 Data MPS F: PID 1, FID 6420, TrackMap V: OSM map set (0) felix@TCHd:~/Downloads/mergetest$ cat options.arg overview-mapname=Malle-6400 overview-mapnumber=64000000 description=TKM-Malle-6400 series-name=TrackMap family-name=TrackMap family-id=6400 mapname=64006400 product-id=1 product-version=0815 draw-priority=58 transparent gmapsupp input-file=./Malle-Acuts-6410.img input-file=./Malle-Bcuts-6420.img output-dir=./ verbose felix@TCHd:~/Downloads/mergetest$ mkgmap -c options.arg felix@TCHd:~/Downloads/mergetest$ ls -al insgesamt 184 drwxr-xr-x 2 felix felix 4096 Nov 26 17:31 . drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 .. -rw-r--r-- 1 felix felix 79360 Nov 26 17:31 gmapsupp.img -rw-r--r-- 1 felix felix 5120 Nov 26 17:31 Malle-6400.img -rw-r--r-- 1 felix felix 157 Nov 26 17:31 Malle-6400.tdb -rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img -rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img -rw-r--r-- 1 felix felix 319 Nov 26 17:30 options.arg felix@TCHd:~/Downloads/mergetest$ gmt -i gmapsupp.img gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu File: gmapsupp.img, length 79360 Header: 26.11.2022 17:31:21, DSKIMG, XOR 00, V 8.15, Ms 0 Mapset: TKM-Malle-6400 Map length s-f CP prio PID FID name MAKEGMAP MPS 174 1 64106410 MPC 53363 3 1252 60 T 1 6410 TKM_Malle-Acuts-6410 06410FM1 TYP 888 1 1252 1 6410 00006410 SRT 912 1 64206420 MPC 12475 3 1252 60 T 1 6420 TKM_Malle-Bcuts-6420 06420FM1 TYP 888 1 1252 1 6420 00006420 SRT 912 1 Data MPS F: PID 1, FID 6410, TrackMap F: PID 1, FID 6420, TrackMap V: OSM map set (0) Discard ...6400.tdb and ...6400.img and rename gmapsupp.img, if you so like. Loads fine, identical to stacking the individual maps. These are very simple map overlays I built from scratch from .gpx tracks only; very few ways and 1 tile per map only. #2 But the process functions as well, if I use a small bbox full "basemap" (FID 5403) and my much wider bbox transparent cyclenetwork overlay (FID 7121), both built from OSM data as outlined above. Here the merged map has way more tiles, shows many elements only for the small bbox and only the CN ways outside, but it is only based on my "BICYCLIN TYP" (used for 7121) and the (mkgmap?) inbuild standard typ for the rest, but not the "EDGE_NL- TYP" (used for 5403). See my initial remarks regarding typefiles. It's not that easy to fix that sample on the fly (since both typefiles declare identical element types differently), but I think, separating that and using one typefile for both maps declaring all elements unique would do the trick. felix@TCHd:~/Downloads/mergetest2$ gmt -i gmapsupp.img gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu File: gmapsupp.img, length 68075520 Header: 26.11.2022 17:57:05, DSKIMG, XOR 00, V 8.15, Ms 0 Mapset: Harri-4567 Map length s-f CP prio PID FID name MAKEGMAP MPS 19366 1 54030001 MPC 2754928 3 1252 31 1 5403 DE-Coesfeld 54030002 MPC 3449556 3 1252 31 1 5403 DE-Duelmen 54030003 MPC 2673582 3 1252 31 1 5403 DE-Bocholt ... EDGE_NL- TYP 28399 1 1252 1 5403 00005403 SRT 912 1 71210001 MPC 128048 3 1252 40 T 1 7121 DE-Cuxhaven 71210002 MPC 107451 3 1252 40 T 1 7121 DE-Husum 71210003 MPC 109457 3 1252 40 T 1 7121 DE-Husum 71210004 MPC 146058 3 1252 40 T 1 7121 DE-Elmshorn ... 71210040 MPC 76301 3 1252 40 T 1 7121 NL-Den Helder 71210041 MPC 77985 3 1252 40 T 1 7121 NL-Harlingen ... 71210161 MPC 133738 3 1252 40 T 1 7121 BE-Verviers ... BICYCLIN TYP 842 1 1252 1 7121 00007121 SRT 912 1 Data MPS F: PID 1, FID 7121, osm_dep-nwh-bcsurf-wide_7121 F: PID 1, FID 5403, osm_deh-tc_5403 V: OSM map set (0) I'm somewhat pressed on time atm to fully check that last assumption, but I will put that on my bucket-list too, at least to evaluate, if this tecnique (merging layers of different draw priority into one final map) finally allows, to control the draw-priority of elements (e.g. ways), at least to some degree. That is, to make sure your oneway arrows get plottet on top of the relevant roads... #3 I did one final test though; merging 2 maps created using the same typefile, but with different, non-overlapping bboxes. No problem! Please note, the FID 5406 maps typefile (EDGE_NL- TYP) is not even listed by gmt, hence not even included by mkgmap. That would (will?) be my way to tackle this task. felix@TCHd:~/Downloads/mergetest3$ gmt -i gmapsupp.img gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu File: gmapsupp.img, length 147324928 Header: 26.11.2022 18:45:09, DSKIMG, XOR 00, V 8.15, Ms 0 Mapset: Harri-4567 Map length s-f CP prio PID FID name MAKEGMAP MPS 2868 1 54030001 MPC 2754928 3 1252 31 1 5403 DE-Coesfeld ... EDGE_NL- TYP 28399 1 1252 1 5403 00005403 SRT 912 1 54060001 MPC 4410896 3 1252 31 1 5406 DE-Bremervoerde ... 54060030 MPC 2392746 3 1252 31 1 5406 PL-Szczecin 00005406 SRT 912 1 Data MPS F: PID 1, FID 5406, osm_deo_5406 F: PID 1, FID 5403, osm_deh-tc_5403 V: OSM map set (0) Please keep me posted, if you give it another try. Cheers Felix
Hi Jan, I also get the same route as test-route-b_yes-removed.jpg with the latest OFM Germany from 10=05-2022 (website is finally up to date since today). It only takes the Altengabengäßchen when you move the via point closer to the junction Altengabengäßchen, or when you select "avoid toll roads". I really don't know why, because there are no bike routes on these streets. What I use is routing over short distance. avoid nothing (sometimes unpaved). Actually I don't use my Garmin at all, I prefer Osmand with mobile phone (android) now 🙂 Cheers, Minko ________________________________ Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> namens jan meisters <jan_m23@gmx.net> Verzonden: zaterdag 28 mei 2022 11:15 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: [mkgmap-dev] Question on routing difference Hi all, I´m using an altered copy of the OFM style and therefore sometimes compare the results. One routing difference I found I was able to lead back, but the cause I don´t understand at all. My test-route should prefer the small residential „Altengabengäßchen“ over the primary „Viktoriastrasse“. Latest OFM does, my version not since I removed {add bicycle=yes} from this line: highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add motorcar=yes; } But unfortunately there is no path or pedestrian in the test-route, nor is it an option to use one. Anyone has an idea how this path>pedestrian rule could affect routing on residential/primary? Same happens when I replay the change with the original OFM. Up-to-date osm.pbf, route from BC and screenshots are here: https://files.mkgmap.org.uk/download/556/test_route.zip Thanks Jan _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Bernhard Hiller -
Felix Herwegh -
Gerd Petermann -
Harri Suomalainen -
jan meisters -
lig fietser -
N Willink