Re: [mkgmap-dev] Regression: Revision 2448 breaking routing in some cases
Oh okay, well then let's put this on the list. I know the remove-short-arcs function is not touching it, but it's 2448 that breaks it. There must be something else touched on the routing side of it. And I would say it's very likely not only happening here, but probably happening in quite a few cases - it just popped up there. On 30.01.2013 22:19, Gerd Petermann wrote:
Hi Felix,
sorry, I have no idea what goes wrong. With r2466, the remove-short-arcs function doesn't touch the way 38693214 or 83196110. I think this is something Steve must look at.
Gerd P.S. I don't know why my answer to your first mail did not go to the list. This was not intended.
------------------------------------------------------------------------ Date: Wed, 30 Jan 2013 17:47:44 +0100 From: extremecarver@gmail.com To: gpetermann_muenchen@hotmail.com Subject: Re: [mkgmap-dev] Regression: Revision 2448 breaking routing in some cases
okay great, well I think there is some routing information missing on the road. Just see what happens when you try to click on it for a route with Basecamp or Mapsource - it puts the routing node somewhere completly else (a little bit, like what happens with merge-lines, just much further away). On 30.01.2013 17:39, Gerd Petermann wrote:
Hi Felix,
okay, I see if I can find anything special in this file. We already know that the algorithm is not 100 % correct, and I hope Steve will find a better solution,but maybe I can improve the existing algo first.
Gerd
------------------------------------------------------------------------ Date: Wed, 30 Jan 2013 17:22:30 +0100 From: extremecarver@gmail.com <mailto:extremecarver@gmail.com> To: gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> Subject: Re: [mkgmap-dev] Regression: Revision 2448 breaking routing in some cases
On 30.01.2013 16:23, Gerd Petermann wrote:
Hi Felix,
I want to find the special case in this. Please provide the osm data (66570017.osm.pbf )
it's here now: http://openmtbmap.org/65250017.osm.pbf
Are you able to reproduce the problem with the default style?
No, I'm really lost on the style issue. I can cut down the style quite far, and it's still broken. But even if I change routable lines, that are created after the breaking road (further down in the lines file), it can suddenly work again. On the other hand, there seems to be nothing special about the osm data there at all.
Gerd
> Date: Wed, 30 Jan 2013 11:46:24 +0100 > From: extremecarver@gmail.com <mailto:extremecarver@gmail.com> > To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: [mkgmap-dev] Regression: Revision 2448 breaking routing in some cases > > Well, I got notified that there is a routing problem in one of my maps, > and after trying around a long time, I tracked it down to release 2448 > that breaks routing under certain occasions. Here is a screenshot of the > the routing failing: > > http://openmtbmap.org/broken_routing.jpg > > So for a very short distance, the routing will actually route over the > broken road (the section where the route is missing). > However for longer sections on that road, or route that actually has a > routepoint manually set on it, Mapsource/Basecamp/GPS will fail to > calculate a route at all. (e.g. if you try to route from the North point > of the route in the picture, South to the Bergkirchen place POI/node). > > > It is dependant on the the style - but I played with deleting lots of > stuff from the style, and it seems to be quite random. > So here are the downloads (all .exe are lzma packed, just unpack them if > not on windows): > > http://openmtbmap.org/velonordrhein-westfalen_working_2447.exe > http://openmtbmap.org/velonordrhein-westfalen_broken_2448.exe > > Search for Bergkirchen, it is in the tile 66570017 > > > Maps are compiled with: > c:\OpenMTBMap\maps>start /low /b /wait java -jar -Xms4000M -Xmx10400M > c:\openmtbmap\mkgmap.jar --max-jobs=8 --generate-sea --latin1 > --precomp-sea=c:\openmtbmap\maps\sea > "--style-file=c:\openmtbmap\velomap_style" --nsis --index --transparent > --adjust-turn-headings --add-pois-to-areas --ignore-maxspeeds > --reduce-point-density=3 --x-reduce-point-density-polygon=6 > --link-pois-to-ways --ignore-turn-restrictions --remove-short-arcs=5.4 > --min-size-polygon=18 --description=velomap_dnw --show-profiles=1 > --location-autofill=bounds,is_in,nearest > --bounds=c:\openmtbmap\maps\bounds --route --country-abbr=dnw > --country-name=nordrhein-westfalen --mapname=66570000 --family-id=6657 > --product-id=1 --series-name=velomap_nordrhein-westfalen_30.01.2013 > --family-name=velomap_dnw_30.01.2013 --tdbfile > --overview-mapname=mapsetc --keep-going > --area-name="nordrhein-westfalen_30.01.2013_velomap.org" -c > c:\openmtbmap\maps\template.nordrhein-westfalen 7*.img 1>NUL > > --remove-short-arcs == resulting road will be broken > --remove-short-arcs=5.4 == resulting road will be broken > without remove-short-arcs == resulting road will be broken > > So it doesn't directly have to do with the --remove-short-arcs function. > > > (also Compiled with --remove-short-arcs=5.4 ) > http://openmtbmap.org/velonordrhein-westfalen_broken_2466.exe > > then Uncommented the following lines in my style-file, which shouldn't > affect routing at all, but it does as the mistake is gone: > # power=line [0x29 resolution 22 continue] > # power=minor_line | powerline=yes | power_line=yes | powerline=true | > power_line=true [0x29 resolution 24 continue] > http://openmtbmap.org/velonordrhein-westfalen_nopower_2466.exe > > However I can also leave that line in the style-file, and delete some > other lines, and routing will work again. There seems to be no clear > pattern (except that the bug go introduced with rev 2448). I use the > same line in my openmtbmap, and there the routing error doesn't happen. > > > -- > keep on biking and discovering new trails > > Felix > openmtbmap.org & www.velomap.org <http://www.velomap.org> > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails
Felix openmtbmap.org &www.velomap.org <http://www.velomap.org>
-- keep on biking and discovering new trails
Felix openmtbmap.org &www.velomap.org <http://www.velomap.org>
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix, Felix Hartmann-2 wrote
Oh okay, well then let's put this on the list. I know the remove-short-arcs function is not touching it, but it's 2448 that breaks it. There must be something else touched on the routing side of it. And I would say it's very likely not only happening here, but probably happening in quite a few cases - it just popped up there.
Did you try to run mkgmap with -ea ? The error in BaseCamp looks like a wrong pointer. If that doesn't help: The most important changes between r2447 and r2448 are: 1) removeShortArcsByMergingNodes() is only called for ways that are roads 2) In StyledConverter, the (OSM) ways that are roads are processed after all other (OSM) ways were processed. As far as I know the order should not matter, but maybe it does somehow. Maybe that rings a bell? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Regression-Revision-2448-breaking-routing-in-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 31.01.2013 07:00, GerdP wrote:
Hi Felix,
Felix Hartmann-2 wrote
Oh okay, well then let's put this on the list. I know the remove-short-arcs function is not touching it, but it's 2448 that breaks it. There must be something else touched on the routing side of it. And I would say it's very likely not only happening here, but probably happening in quite a few cases - it just popped up there. Did you try to run mkgmap with -ea ? The error in BaseCamp looks like a wrong pointer. yes -ea enabled, >NUL disabled, no error or info outpout.
If that doesn't help: The most important changes between r2447 and r2448 are: 1) removeShortArcsByMergingNodes() is only called for ways that are roads 2) In StyledConverter, the (OSM) ways that are roads are processed after all other (OSM) ways were processed.
As far as I know the order should not matter, but maybe it does somehow. Maybe that rings a bell? Could there be a patch to disable 2) for a try? That would explain why changing removing power=line solves it (but again I don't think this is to blame, but just mkgmap putting some routing information wrong).
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Regression-Revision-2448-breaking-routing-in-... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
Could there be a patch to disable 2) for a try? That would explain why changing removing power=line solves it (but again I don't think this is to blame, but just mkgmap putting some routing information wrong).
No, this can't be changed, and probably I was not precise. With --preserve-element-order the elements are processed in the order of the OSM id, else there is no specific order. You may try --preserve-element-order, if that fixes the error we can be rather sure that it is related to the order. Or, you can send your style to my private email address. I promise not to use it for anything else but debugging. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Regression-Revision-2448-breaking-routing-in-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Each road has an entry in the NET section that lists the line(s) that make it up. The lines are specified by subdivision number and the index of the line in the subdivision. In turn, inside the RGN section are the actual lines ordered by subdivision/index which contain a pointer back to the NET road-def section. In the broken map these are out-of-step. There are only a small number of subdivisions that are faulty, but most of the roads in the affected subdivs show the problem. I have written a program to cross check between RGN and GET. It is test.check.CheckNet in the display project. It is not immediately obvious why this is happening as the changes that we are suspecting seem to occur well before subdivisions are created. But perhaps I am misreading the code, anything that removes a line after the RoadDef's are created might be the problem. ..Steve
Hi, Steve Ratcliffe wrote
It is not immediately obvious why this is happening as the changes that we are suspecting seem to occur well before subdivisions are created.
But perhaps I am misreading the code, anything that removes a line after the RoadDef's are created might be the problem.
the old code changed the preserved() flag for more coords. This preserved flag is taken into account in the filters like DouglasPeucker. If something is removed in r2448 but not in r2447, I assume that this is the reason (and it is intended). I just don't see how this can effect the road net. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Regression-Revision-2448-breaking-routing-in-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
If something is removed in r2448 but not in r2447, I assume that this is the reason (and it is intended). I just don't see how this can effect the road net.
Me neither. Furthermore with the default style there are zero errors detected. I can't think how the style could affect it either... Probably comparing the two sets created with 2466 with and without powerlines may help; does the problem disappear or does it just move somewhere else? I won't have any time to look into this further as I should be preparing to travel to the mkgmap weekend in Essen ;) ..Steve
Hi, Steve Ratcliffe wrote
Probably comparing the two sets created with 2466 with and without powerlines may help; does the problem disappear or does it just move somewhere else?
I won't have any time to look into this further as I should be preparing to travel to the mkgmap weekend in Essen ;)
I am able to reproducde a problem with r2472. I just use java -jar mkgmap.jar --route input.osm.pbf A following java -cp display.jar;mkgmap.jar test.check.NetCheck 63240001.img shows these errors, while r2447 doesn't: --------- NET 3 (Road index) --------------------------------------------------- Got <♠K7 AN DER BLANKENBURG 742/10>, expected <OBERE MARTINISTRASSE 742/10> Got <TOPFERSTRASSE 742/39>, expected <MASURENSTRASSE 742/39> Got <BONHOEFFERSTRASSE 742/52>, expected <IRISWEG 742/52> Got <ANNE-FRANK-STRASSE 742/55>, expected <AN DER WIHOKIRCHE 742/55> Got <POTTBACKERWEG 742/67>, expected <GRAF-STAUFFENBERG-STRASSE 742/67> Got <GOERDELERSTRASSE 742/71>, expected <TOPFERSTRASSE 742/71> Got <IM HAIN 742/72>, expected <GOERDELERSTRASSE 742/72> Got <RHEINER-LANDSTRASSE-001-098 742/142>, expected <IM SCHLOH 742/142> Got <RHEINER LANDSTRASSE 742/143>, expected <RHEINER-LANDSTRASSE-001-098 742/143
Got <IM KURZEN BUSCH 742/146>, expected <IM LANGEN BUSCH 742/146> Got <HAKENBUSCH 742/149>, expected <RHEINER-LANDSTRASSE-001-098 742/149> Tomorrow I will try to run it against Felix files. Maybe this info helps me to find the cause of the error. Have fun in Essen! Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Regression-Revision-2448-breaking-routing-in-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I don't know if the issue is related to the one Felix describes but I also have problems with broken routing after r2447. It happens on some places where I want to point the cursor on the map to, but the cursor jumps like 100m further on that road (http://www.openstreetmap.org/browse/way/121164340), almost like this part of the road seems "infected" there and the cursor likes to skip that part of the road. If I click the cursor a little further down this road, Mapsource gives an Error code 3. There has been no osm edits nor changing of my styles at that point so I also think it is due to changes in the mkgmap routing after r2447 that causes this broken routing.
If you use --merge-lines, then this could (but doesn't have to) also be the root of the bug. Typical for this bug is, that when you try to move the map with the hand tool, it will jump the 100m (this doesn't happen with the bug I'm speaking about since 2448)... If you don't use --merge-lines, then yes, this is the same bug. If you try to autoroute over it this will happen: a) short stretch - the route works, but you cannot see the "pink" line b) routing fails with unkown error. On 03.02.2013 22:58, Minko wrote:
Hi,
I don't know if the issue is related to the one Felix describes but I also have problems with broken routing after r2447. It happens on some places where I want to point the cursor on the map to, but the cursor jumps like 100m further on that road (http://www.openstreetmap.org/browse/way/121164340), almost like this part of the road seems "infected" there and the cursor likes to skip that part of the road. If I click the cursor a little further down this road, Mapsource gives an Error code 3. There has been no osm edits nor changing of my styles at that point so I also think it is due to changes in the mkgmap routing after r2447 that causes this broken routing.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
merge-lines seems not of any influence, with or without this option the cursor is making weird jumps (I'm using mkgmap-r2459). With mkgmap r2447 routing is fine. If I use only the default style & mkgmap-r2459 there are no routing issues, so I can confirm it is style file related. Here are some screenshots: https://dl.dropbox.com/u/64716698/OSM/Forum/error1.jpg https://dl.dropbox.com/u/64716698/OSM/Forum/error2.jpg Felix wrote:
If you use --merge-lines, then this could (but doesn't have to) also be the root of the bug. Typical for this bug is, that when you try to move the map with the hand tool, it will jump the 100m (this doesn't happen with the bug I'm speaking about since 2448)...
If you don't use --merge-lines, then yes, this is the same bug. If you try to autoroute over it this will happen: a) short stretch - the route works, but you cannot see the "pink" line b) routing fails with unkown error.
participants (4)
-
Felix Hartmann -
GerdP -
Minko -
Steve Ratcliffe