Problem with mdr creation (if contourline maps are included)
I want to join contourline maps (created with mkgmap ~ rev 1230) with my normal maps and create an mdr index for them. This works fine as long as I only try to create an mdr/mdx index for my "normal maps", however when I include any contourline maps mkgmap crashes: Can anyone identify the error easily? (the maps in question are here: http://openmtbmap.x-nation.de/maps/mtbaustria.7z.zip (6*.img) and the contourlines theese http://openmtbmap.x-nation.de/maps/contourlines/openmtbmap_at_srtm.7z.zip (7*.img) D:\Garmin\0mtb\mtbaustria2>start /low /b /wait java -enableassertions -jar -Xmx4800M d:/garmin/mkgmap_svn_mdr/dist/mkgmap.jar --family-id=7365 --product-id=1 --overview-mapname=MDR --index --max-jobs=3 6*.img 7*.img Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -68 at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.imgfmt.sys.BlockTable.physFromLogical(BlockTable.java:112) at uk.me.parabola.imgfmt.sys.Dirent.getPhysicalBlock(Dirent.java:262) at uk.me.parabola.imgfmt.sys.FileNode.read(FileNode.java:156) at uk.me.parabola.imgfmt.app.BufferedImgFileReader.fillBuffer(BufferedImgFileReader.java:256) at uk.me.parabola.imgfmt.app.BufferedImgFileReader.get(BufferedImgFileReader.java:86) at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.linesForSubdiv(RGNFileReader.java:147) at uk.me.parabola.imgfmt.app.map.MapReader.linesForLevel(MapReader.java:123) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:201) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:112) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:358) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:121) For the contourlines my style-file was very simple so I don't really understand how that could have caused the problems: # Contours take their name from the elevation setting. contour_ext=elevation_minor & ele>0 { name '${ele|conv:m=>ft}'; } [0x20 resolution 23] contour_ext=elevation_medium & ele>0 { name '${ele|conv:m=>ft}'; } [0x21 resolution 22] contour_ext=elevation_major & ele>0 { name '${ele|conv:m=>ft}'; } [0x22 resolution 20] contour_ext=elevation & ele>0 { name '${ele|conv:m=>ft}'; } [0x21 resolution 20]
Hi Felix
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -68
Thanks for the examples, it was a problem that has been reported a few times but your example quickly showed that the problem was a sign extension bug, now fixed. Thanks, ..Steve
Steve Ratcliffe wrote:
Hi Felix
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -68
Thanks for the examples, it was a problem that has been reported a few times but your example quickly showed that the problem was a sign extension bug, now fixed.
Yip great, working now. Just tested it out. I just noticed that searching for streets starting with A or B works when I compile the index from *.img. Are there any drawbacks to create the address index seperately from the maps? (I prefer to compile maps with trunk because of the new patches introduced with 1277-1279 which are really important to me and don't compile against mdr branch). If there are no advantages of creating the index together with the maps directly form .osm then maybe the mdr branch could be completely forked out to be seperate from mkgmap?
Thanks,
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi On 15/10/09 22:17, Felix Hartmann wrote:
Yip great, working now. Just tested it out.
OK good.
I just noticed that searching for streets starting with A or B works when I compile the index from *.img.
Are there any drawbacks to create the address index seperately from the maps?
Well there shouldn't be any difference as it does osm to img first and then creates the index from the img files. However I've been merging the mdr branch back to trunk and I am seeing that there is a difference in how labels sort and so if you compile to img with mkgmap-trunk there may be differences compared to compiling with mkgmap-mdr. I am able to search for names beginning with A or B, so the problem is not quite that simple, it probably depends on how labels with shields should be sorted in the index.
If there are no advantages of creating the index together with the maps directly form .osm then maybe the mdr branch could be completely forked out to be seperate from mkgmap?
There is no advantage apart from ease of use, however the same could be said of gmapsupp, tdbfile file, overview map etc all of which will work happily on the .img files. The new code for mdr will also be useful to create a proper overview map too. ..Steve
If there are no advantages of creating the index together with the maps directly form .osm then maybe the mdr branch could be completely forked out to be seperate from mkgmap?
There is no advantage apart from ease of use, however the same could be said of gmapsupp, tdbfile file, overview map etc all of which will work happily on the .img files. The new code for mdr will also be useful to create a proper overview map too.
..Steve
Thanks for your answer. Better Overview map sound good, because it was not yet really correct. Could you look into the issue that for big maps like germany.osm.bz2 index creation happens "there is not enough space in a single .osm img...." Garmin City Navigator 2009 _mdr.img is 407MB big, so there are some limatations that are not needed for mdr.img
On 16/10/09 10:23, Felix Hartmann wrote:
Thanks for your answer. Better Overview map sound good, because it was not yet really correct.
Could you look into the issue that for big maps like germany.osm.bz2 index creation happens "there is not enough space in a single .osm img...." Garmin City Navigator 2009 _mdr.img is 407MB big, so there are some limatations that are not needed for mdr.img
That message has nothing to do with creating the index, it comes from compiling the maps to .img. Are you saying that they fail in mdr, but not in r1222 on trunk? If it something that has been fixed since the branch was made then it should be OK after the merge. ..Steve
participants (2)
-
Felix Hartmann -
Steve Ratcliffe