[mkgmap-dev] Bug in Road Merging - actually doubling roads.

Fri Mar 23 08:15:54 GMT 2018

Hi Gerd, I just was thinking about if one road is leaving the roundabout at two angles it may count on the Garmin as two roads and will lead to 'exit on 3rd exit' instead of 'exit on 2nd exit' for example. 

But I haven't gave it a try yet. 
Henning 

⁣Sent from BlueMail 

On 23 Mar 2018, 09:07, at 09:07, Gerd Petermann <gpetermann_muenchen at hotmail.com> wrote:
>Hi Henning,
>
>Do you think that the patch causes problems? I'd be very surprised. Why
>do you think that? Do you have an example where this happens?
>The patch only changes the heading values, the expected effect is that
>the angles shown in the routing instructions differ by maybe 5°
>degrees.
>Maybe other arcs are preferred because of that, so yes, I expect
>effects on routing, but not a special effect at roundabouts.
>I've also created a test case where a roundabout is partly overlapped
>by a link road, still, Garmin shows the enter roundabout / leave
>roundabout messages.
>Maybe this was good luck, but my current thinking is that the Garmin
>algo reads the information about all available arcs and somehow prefers
>one
>without completely ignoring the others.
>
>I might still add code to print warnings for the case that (too) many
>arcs with the same heading are connected to one node, if you want that.
>
>Gerd
>
>________________________________________
>Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
>Henning Scholland <osm at hscholland.de>
>Gesendet: Donnerstag, 22. März 2018 17:08:27
>An: Development list for mkgmap
>Betreff: Re: [mkgmap-dev] Bug in Road Merging - actually doubling
>roads.
>
>Hi Gerd
>Doesn't it cause problems at roundabouts for messages like 'leave at
>3rd exit'
>Henning
>On 22 Mar 2018, at 23:56, Gerd Petermann
><gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
>wrote:
>
>Hi Felix,
>
>I tried to remove duplicate arcs but that is probably not allowed.
>Mapsource says that there is an error in the map product when I try to
>route over the remaining
>arcs. Maybe not always but it doesn't look promising.
>I've noted that even with the default style you get many duplicated
>arcs, for example here:
>The oneway residential road
>https://www.openstreetmap.org/way/183285165
>is overlapped by hw=residential + area=yes
>https://www.openstreetmap.org/way/393299955
>Interesting is that Mapsource seems to ignore the arcs produced way
>393299955 because it will not route in the wrong
>direction of the oneway.
>
>So, I'm back at somehow changing the heading values now.
>This turned out to be quite simple. We already have code in
>AngleChecker to modify heading values so that junctions don't show
>sharp angles.
>Please try attached patch in combination with your version of
>count-same-bearing-v2.patch.
>This patch changes groups of arcs with equal initial heading (delta <
>1°) so that they are stored with slightly different heading values.
>You should see no more messages from the count patch and - crossing my
>fingers - better routing.
>
>Gerd
>
>
>
>________________________________
>
>Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
>Felix Hartmann <extremecarver at gmail.com>
>Gesendet: Mittwoch, 21. März 2018 14:01:49
>An: Development list for mkgmap
>Betreff: Re: [mkgmap-dev] Bug in Road Merging - actually doubling
>roads.
>
>Okay - 5 Arcs are sometimes causing problems too - but it's like a
>50/50 chance.
>Also if at the very beginning of a route - there are 6 Arcs - then the
>Oregon will somehow just skip it and get into the route. So actually
>some of the samples that follow work, because of that. In general even
>if one arc is related to oneway line, it seems that both directions are
>affected.
>
>4 Arcs seems to be always safe. Tested a couple and it never failed.
>
>https://openmtbmap.org/More_Tests.gdb
>
>
>
>
>
>On 21 March 2018 at 10:23, Gerd Petermann
><gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
>wrote:
>Hi Felix,
>
>okay, I can reproduce the problem with your map and gdb file on my
>Oregon. If I got that right overlapping highways are likely to cause
>multiple identical arcs.
>I think it should be rather easy to detect and remove them (together
>with the reverse arc), so I'll try to code that first.
>Regarding the "funny" example that doesn't break routing:
>I'll have a closer look. Maybe it's also the order of the arcs that
>matters, maybe this one works because there are only two nodes with
>dulicate arcs.
>I think the other examples contain more.
>
>Gerd
>
>
>
>________________________________
>
>Von: mkgmap-dev
><mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>
>im Auftrag von Felix Hartmann
><extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
>Gesendet: Dienstag, 20. März 2018 23:35:06
>An: Development list for mkgmap
>Betreff: Re: [mkgmap-dev] Bug in Road Merging - actually doubling
>roads.
>
>Just for testing to make it much easier - here are the routes:
>https://openmtbmap.org/Test_routes.gdb
>
>On 20 March 2018 at 23:19, Felix Hartmann
><extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
>wrote:
>The new patch seems to work pretty well - most ways that are supposedly
>not routable (according to my understanding so far if there are 6 arcs
>or more it will break) are actually broken.
>
>Map (just unpack the lzma installer:
>https://openmtbmap.org/mtbitaly_test.exe
>
>All broken - in simulation routing gets stuck.:
>SEVERE (RouteNode): E:\openmtbmap\maps\63670040.osm.pbf: 8 or more arcs
>with the same initial bearing, expect routing problems at
>44.528092<tel:528092><tel:528092<tel:528092>>,7.857529 when routing to
>132░ (http://www.openstreetmap.org/browse/way/310376420)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670040.osm.pbf: 7 or more arcs
>with the same initial bearing, expect routing problems at
>44.528092<tel:528092><tel:528092<tel:528092>>,7.857529 when routing to
>132░ (http://www.openstreetmap.org/browse/way/310376420)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670068.osm.pbf: 7 or more arcs
>with the same initial bearing, expect routing problems at
>45.984356,9.206016 when routing to 203░
>(http://www.openstreetmap.org/browse/way/273387447)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.750019,12.707582 when routing to 189░
>(http://www.openstreetmap.org/browse/way/457631339)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.749947,12.707799 when routing to 294░
>(http://www.openstreetmap.org/browse/way/457631339)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.749966,12.707912 when routing to 258░
>(http://www.openstreetmap.org/browse/way/457631339)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.746202,12.752692 when routing to 109░
>(http://www.openstreetmap.org/browse/way/303828386)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.746165,12.752832 when routing to 99░
>(http://www.openstreetmap.org/browse/way/303828386)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.746144,12.753007 when routing to 113░
>(http://www.openstreetmap.org/browse/way/303828386)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.746083,12.753196 when routing to 117░
>(http://www.openstreetmap.org/browse/way/303828386)
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.746027,12.753341 when routing to 130░
>(http://www.openstreetmap.org/browse/way/303828386)
>
>Funnily this one works and routing is not broken:
>SEVERE (RouteNode): E:\openmtbmap\maps\63670002.osm.pbf: 6 or more arcs
>with the same initial bearing, expect routing problems at
>41.903471,13.182355 when routing to 245░
>(http://www.openstreetmap.org/browse/way/519285722)
>
>
>I'll test some more tomorrow or in the upcoming days. I always tested
>both directions just to make sure and could not see a difference.
>All of them are based on OSM mapping error with (several) ways
>overlapping each other. If mkgmap could drop identical ways
>(disrespecting the name field, or even better remove ways that have the
>same routing profile) it would already solve all but the first
>problematic way.
>
>On 20 March 2018 at 20:44, Felix Hartmann
><extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
>wrote:
>Yes it only happens on device.  Simulating routing via: 
>http://www.openstreetmap.org/browse/way/310376420 will in this case not
>switch off the device, but just get stuck. Map moving forward/backwards
>slightly.
>Here you could reproduce it by simply doubling the routable lines - one
>routable line for highway=path, another one for the relation
>route=hiking or route=mtb. 6 Routable lines (which are not oneway) with
>exactly the same way on top of each other are enough to reliably cause
>the Oregon 600 to break routing in my experience.
>
>The arc list actually helped me to identify some common problems in my
>style so I could reduce some routable lines - but in my experience
>adding several lines on top of each other - with different
>road_class/road_speed helps prioritise those ways. For highways this is
>not needed - as they are straight. But with mountain pathes - often a
>road_class 4, road_speed 2 is already too high importance to be chosen
>for curvy pathes, so adding a road_class 3, road_speed 1, and
>road_class 1, road_speed 0 will help to prioritize such ways. Also
>adding relations as routable lines often helps in so far that at least
>according to gpsmapedit they have much less routable nodes than the
>underlying way - so maybe that helps prioritizing them too?
>
>
>Felix
>
>On 20 March 2018 at 17:30, Gerd Petermann
><gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>>
>wrote:
>Hi Felix,
>
>well, up to now I thought that you want to fix the problem in your
>style and just need help to find out where it happens.
>I still don't understand why your style adds so many routable lines, in
>my eyes this is an errpr on your side.
>But you may be right, mkgmap might be able to change the bearing values
>of an arc when there are too many equal ones.
>You never told me what exactly I should do to reproduce a problem. In
>previous posts you wrote about crashes, now you
>mention broken routing. I guess this still only happens on the device?
>
>Gerd
>
>
>
>________________________________
>
>Von: mkgmap-dev
><mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>>
>im Auftrag von Felix Hartmann
><extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
>Gesendet: Dienstag, 20. März 2018 13:23:37
>An: Development list for mkgmap
>Betreff: Re: [mkgmap-dev] Bug in Road Merging - actually doubling
>roads.
>
>well I think if ways are overlapping which have identical nodes it
>should be possible to throw away according to say this prinicple:
>a) identical tags (except name which is not important) - throw away the
>copy/copies. I think here it is clear the copies are not needed.
>b) identical tags (except name) plus more tags.
>Eg way 1 has: key1=a key2=b     way 2 has key1=a, key2=b key3=c. So
>throw away way1.
>If there is however
>way 1 has: key1=a key2=b  key3=c    way 2 has key1=a, key2=b key4=d. it
>is more complicated but it could still be merged to a single way
>consisting of key1=a, key2=b, key3=c, key4=d
>if
>way 1 has: key1=a key2=b  key3=c    way 2 has key1=a, key2=b key3=d we
>could keep both ways, or throw away one of them - but yeah then it is
>not clear which one so better keep.
>
>
>For the problems related to 
>http://www.openstreetmap.org/browse/way/310376420
>and the other 2 ways. Following a) removes one copy. Following rule b)
>would actually get rid of the second copy and now information/detail
>will be lost.
>
>
>I'll try the new patch and see if I can find out more about problems.
>
>
>BTW - would it not be better to just use a test map for finding the
>error? I'm pretty sure any 6 routable roads on top of each other
>(identical direction) cause routing to break on Oregon 600. As soon as
>some way is slightly different angle - it is fine.
>
>
>
>
>________________________________
>
>mkgmap-dev mailing list
>mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>--
>Felix Hartman - Openmtbmap.org<http://Openmtbmap.org> &
>VeloMap.org<http://VeloMap.org>
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>
>--
>Felix Hartman - Openmtbmap.org<http://Openmtbmap.org> &
>VeloMap.org<http://VeloMap.org>
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>
>--
>Felix Hartman - Openmtbmap.org<http://Openmtbmap.org> &
>VeloMap.org<http://VeloMap.org>
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>________________________________
>
>mkgmap-dev mailing list
>mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>--
>Felix Hartman - Openmtbmap.org<http://Openmtbmap.org> &
>VeloMap.org<http://VeloMap.org>
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>________________________________
>
>mkgmap-dev mailing list
>mkgmap-dev at lists.mkgmap.org.uk
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>_______________________________________________
>mkgmap-dev mailing list
>mkgmap-dev at lists.mkgmap.org.uk
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180323/74f2194f/attachment-0001.html>