Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
Hi Felix, Thilo, Is it possible to produce a small example OSM file that shows this problem? If so, please zip it up and send it to me or put it on a website I can access. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
I experienced a similar error, also with mkgmap rev 1053, when compiling germany.osm.bz2 with my own contour lines added. Mkgmap fails with an assertion error when I try to compile one of the resulting tiles. For some reason one road gets "stuck" while subdividing. When I omit the contour lines the tile will compile just fine. When looking at the log output there are a lot of ways with the name "SIEDLUNG NEUD?RFEL" (#35170047, #35160048, #35170059, #35170062, #35170063, #35170064, #35170070, #35170071, #35170072, #35170084, ... all in all 174) at about lat 51,08201/lon 14,67827. There are much less ways with that name in the original germay.osm.bz2! They consume 174 entries in TableA and TableB (whatever that is). But in TableB only 62 entries are allowed. This triggers a subdivision, but that doesn't help, as still they all get into one subdivision, which gets divided further and further until the assertion is triggered. Overriding the assertion by making sure that empty BBoxes are skipped doesn't help, as this will simply trigger a Stack Overflow. So what's the problem here? Maybe the splitter gets wild and generates a lot of duplicates? Splitter is the most recent version from svn (rev 33) by the way. And seemingly unchanged since ages... Looking at the ways of "SIEDLUNG NEUD?RFEL" there is only one obvious pecularity: the two points #413985320 and #413985328 are very near to each other (to four decimal places at least). The command line is java -Xmx2048m -ea -Dlog.config=logging.properties -jar trunk/dist/ mkgmap.jar --net --route problem.osm The log output is available at http://osm.arndnet.de/mkgmap.log.0 (15 MB) The input file problem.osm is available at http://osm.arndnet.de/problem.osm.zip (16 MB) The stack dump is very similar to that published by extremecarver: Exception in thread "main" java.lang.AssertionError: trying to get center of empty BBox at uk.me.parabola.imgfmt.app.net.NOD1Part$BBox.center(NOD1Part.java: 141) at uk.me.parabola.imgfmt.app.net.NOD1Part.toRouteCenter(NOD1Part.java: 286) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:242) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk .me.parabola.mkgmap.general.RoadNetwork.splitCenters(RoadNetwork.java: 161) at uk.me.parabola.mkgmap.general.RoadNetwork.getCenters(RoadNetwork.java: 166) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:186) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:90) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:151) at uk.me.parabola.mkgmap.CommandArgsReader $Filename.processArg(CommandArgsReader.java:237) at uk .me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java: 120) at uk.me.parabola.mkgmap.main.Main.main(Main.java:92) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
I assume there is a serious bug in the austria.osm.bz2 currently. See here the error output. It compiles 3 out of 7 tiles correctly, and then chokes on the 4. tile. I'm sure there is an error in the country extract (with the same command all other country extracts of europe compiled fine - the overflow is not related to split size (I reduced it drastically just to test, and yesterdays osm.bz2 extract compiled just fine). If someone wants to have a look at it, I could upload the broken file (only the splitted part that breaks mapbuilding - it's 12.1 MB) to my server. Maybe it's useful for bugtracking for you, I don't know (happens on rev 1053 and/or 1052 I did not testrun with older revisions)... D:\Garmin\mkgmap_680>start /b /wait java -jar -Xmx4800M mkgmap.jar --latin1 --lower-case --no-sorted-roads --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs --add-pois-to-areas --location-autofill=1 --route --net --country-abbr=at --country-name=austria --gmapsupp --mapname=6366 636600*.osm.gz Exception in thread "main" java.lang.StackOverflowError at java.util.regex.Pattern$BmpCharProperty.match(Unknown Source) at java.util.regex.Pattern$GroupHead.match(Unknown Source) at java.util.regex.Pattern$Branch.match(Unknown Source) at java.util.regex.Pattern$BranchConn.match(Unknown Source) at java.util.regex.Pattern$GroupTail.match(Unknown Source) at java.util.regex.Pattern$Curly.match0(Unknown Source) at java.util.regex.Pattern$Curly.match(Unknown Source) at java.util.regex.Pattern$BmpCharProperty.match(Unknown Source) at java.util.regex.Pattern$GroupHead.match(Unknown Source) at java.util.regex.Pattern$Branch.match(Unknown Source) at java.util.regex.Pattern$Branch.match(Unknown Source) at java.util.regex.Pattern$BranchConn.match(Unknown Source) at java.util.regex.Pattern$GroupTail.match(Unknown Source) at java.util.regex.Pattern$Curly.match0(Unknown Source) at java.util.regex.Pattern$Curly.match(Unknown Source) at java.util.regex.Pattern$GroupHead.match(Unknown Source) at java.util.regex.Pattern$Branch.match(Unknown Source) at java.util.regex.Pattern$Branch.match(Unknown Source) at java.util.regex.Pattern$BmpCharProperty.match(Unknown Source) at java.util.regex.Pattern$Start.match(Unknown Source) at java.util.regex.Matcher.search(Unknown Source) at java.util.regex.Matcher.find(Unknown Source) at java.util.Formatter.parse(Unknown Source) at java.util.Formatter.format(Unknown Source) at java.util.Formatter.format(Unknown Source) at uk.me.parabola.imgfmt.app.Coord.toDegreeString(Coord.java:191) at uk.me.parabola.imgfmt.app.net.RouteCenter.(RouteCenter.java:42) at uk.me.parabola.imgfmt.app.net.NOD1Part.toRouteCenter(NOD1Part.java:286) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:242) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) . This continues for around 200 lines, then breaks operation. Different output with -ea: D:\Garmin\mkgmap_680>start /b /wait java -jar -ea -Xmx4800M mkgmap.jar --latin1 --lower-case --no-sorted-roads --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs --add-pois-to-area s --location-autofill=1 --description=main1_openmtbmap_at --route --net --country-abbr=at --country-name=austria --gmapsupp --mapname=6366 636600*.osm.gz Exception in thread "main" java.lang.AssertionError: trying to get center of empty BBox at uk.me.parabola.imgfmt.app.net.NOD1Part$BBox.center(NOD1Part.java:141) at uk.me.parabola.imgfmt.app.net.NOD1Part.toRouteCenter(NOD1Part.java:286) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:242) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.NOD1Part.subdivide(NOD1Part.java:266) at uk.me.parabola.imgfmt.app.net.N
Re: [mkgmap-dev] [PATCH] Alpha code for pedestrian routing in plazas
On Jun 1, 2009, at 8:41 PM, gyp...@gmx.eu wrote: I think, streets and pedestrian squares need to be linked to allow routing. If there is no link, we should assume that this is intended as there is no connection reality. The more OSM related routings systems are being used, the more people will see to edit their data more precisely. I agree with this, and think this is most likely the best way to handle this. I have noticed, for example, that there are several pedestrian areas which are completely surrounded by buildings. Trying to create connecting ways could result in ways that go through buildings or other impassible objects. Therefore, as you suggest, we can only rely on existing links to the squares. This has the side-effect of making the coding much easier. ;-) Does anyone know how the other OSM routing programs (such as travelling salesman, etc.) solve this? (If at all) I didn't try it with TS yet, but www.openrouteservice.org leads you along the borders of pedestrian areas. This seems to be not the best solution but a practicable one. This is also the same way that routing with my patch will work (provided there are linking ways), so at least that is consistent. Thanks for your comments. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Alpha code for pedestrian routing in plazas
Hi Clinton, I think, streets and pedestrian squares need to be linked to allow routing. If there is no link, we should assume that this is intended as there is no connection reality. The more OSM related routings systems are being used, the more people will see to edit their data more precisely. > Does anyone know how the other OSM routing programs (such as > travelling salesman, etc.) solve this? (If at all) I didn't try it with TS yet, but www.openrouteservice.org leads you along the borders of pedestrian areas. This seems to be not the best solution but a practicable one. Of course, to connect the junctions to each other by additional edges would be better. But an algorithm which is able to cope with the "banana" problem has to be developed first. Markus Original-Nachricht > Datum: Sun, 31 May 2009 23:43:08 +0200 > Von: Clinton Gladstone > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] [PATCH] Alpha code for pedestrian routing in plazas > On May 29, 2009, at 10:18 PM, gyp...@gmx.eu wrote: > > >> Good idea with this! What do you think about creating pedestrian ways > >> that connect to each of the streets that touch the plaza instead of > >> just creating ways around the outside? > > > > That was my first thought too when I read Clintons post. > > But... what it the pedestrian area is shaped as a banana? Then you > > could get ways displayed which lead straight through a building. > > Does anybody have an Idea to solve this? > > Yes, these are things I have thought about. I believe this is a > general routing problem with OSM, and not just one affecting Garmin > maps created by mkgmap: this also applies to other routing programs > which attempt to provide routes suitable for pedestrians. > > Does anyone know how the other OSM routing programs (such as > travelling salesman, etc.) solve this? (If at all) > > I have also noticed that the success of pedestrian routing through > squares seems to be largely dependent on the person doing the mapping. > For example, most of the pedestrian squares in Rome appear to be > nicely linked to other streets; Siena, on the other hand, has its > Piazza del Campo drawn as an independent polygon. > > Somehow I suspect that for pedestrian routing to work reliably, in any > program, mappers must manually enter connecting ways. > > What do you think? > > Cheers. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1053: Demoted message from warn to info to reduce noise level.
Version 1053 was commited by markb on 2009-06-01 10:25:42 +0100 (Mon, 01 Jun 2009) Demoted message from warn to info to reduce noise level. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
