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

Thu Mar 22 16:08:27 GMT 2018

Hi Gerd
Doesn't it cause problems at roundabouts for messages like 'leave at 3rd exit'
Henning 

On 22 Mar 2018, 23:56, at 23:56, Gerd Petermann <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 & VeloMap.org
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>
>--
>Felix Hartman - Openmtbmap.org & VeloMap.org
>Schusterbergweg 32/8
>6020 Innsbruck
>Austria - Österreich
>
>
>
>--
>Felix Hartman - Openmtbmap.org & 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 & 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180322/6d2de226/attachment-0001.html>