- mkgmap-dev - The mkgmap lists

Description is too long (max 50)
by Felix Hartmann 06 May '18

06 May '18

Exception in thread "main" java.lang.IllegalArgumentException: Description is too long (max 50) at uk.me.parabola.imgfmt.sys.ImgHeader.setDescription(ImgHeader.java:336) at uk.me.parabola.imgfmt.sys.ImgHeader.createHeader(ImgHeader.java:168) at uk.me.parabola.imgfmt.sys.ImgFS.createInitFS(ImgFS.java:372) at uk.me.parabola.imgfmt.sys.ImgFS.createFs(ImgFS.java:123) at uk.me.parabola.imgfmt.sys.ImgFS.createFs(ImgFS.java:102) at uk.me.parabola.imgfmt.app.map.Map.createMap(Map.java:99) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:182) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:104) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:678) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143) at uk.me.parabola.mkgmap.main.Main.main(Main.java:114) I'm pretty sure that the --description value is well below 50 characters. However the area-name was 54 characters. Is the area-name also not allowed to be bigger? Also maybe the family name was 51 or 52 characters long. Or is this bug somewhere else? -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

2 3

Commit r4185: tags5.patch: Improve the RuleIndex.
by svn commit 06 May '18

06 May '18

Version mkgmap-r4185 was committed by gerd on Sun, 06 May 2018 tags5.patch: Improve the RuleIndex. Attached patch reduces again the number of evaluated rules, but should still evaluates all necessary rules. The old index still returned too many rules. Let's look at the example that I added as unit test. Set of rules: 0: a=* {set b=1} 1: b=1 {set c=1} 2: d=2 {set c=2} 3: c=* {set a=2} 4: c=1 {set d=2} 5: c=2 {set d=1} 6: d=1 [0x10401 resolution 24] 7: d=2 [0x10402 resolution 24] Assume we have no index and an element with only one tag a=1. We check each rule: Rules 0 matches and sets b=1 Now 1 matches and sets c=1 Rule 2 doesn't match. Rule 3 matches and sets a=2 Rule 4 matches and sets d=2 Rule 5 doesn't match. Rule 6 doesn't match. Rule 7 matches. The index is used to reduce the number of evaluated rules. In the best case it should return rules 0,1,3,4, and 7 for the given element. But the current code returns all rules because it thinks that rule 4 can set d=2 and therefore rule 2 might be triggered (which is wrong). The patch changes the index to recognizes the order of the rules which change tags and therefore returns only the needed rules. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4185

1 0

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?
by Frank Stinner 05 May '18

05 May '18

For my opinion your data sources are very interesting. This is a short look to the alps, the tile E40N20 from https://land.copernicus.eu/. There seem's to be a little problem at the near of some coastlines, but we have on the other hand a high resolution of 25m. I belive, a bigger problem is the coordinate reference system. Copernicus data have EPSG:3035, garmin use EPSG:4326. It would be fine, if mkgmap could be read geotiffs and calculate with different coordinate reference systems. This would perhaps collect the interpolation for changing the coordinate reference system and for the garmin map. On the other hand: this is a lot of mathematical stuff. I'm not a java hacker and i don't know, if there are usable geografic librarys for this work. At the moment we have to translate the tiffs from EPSG:3035 to EPSG:4326, then the segmentation in 1°x1° tiffs an at last the conversion to hgt files. This should not be a very great problem with gdal-tools or so, but it is additional work. Frank

5 13

patch to improve style throughput
by Gerd Petermann 02 May '18

02 May '18

Hi Steve, I think I found a simple patch to improve the rule index. I've noticed that the unpatched version often returns far more rules to check than expected. e.g. if an element has the tag a=3 and we have these 3 rules a=1 {...} a=2 & b=1 {...} a=3 & c=1 {...} all three are evaluated, in fact all rules which have a keystring beginning with a= are returned by the index. The patch changes this so that rules which cannot match are not returned. This makes style evaluation a bit faster. I've tried it with a few styles and some input files and found no changes in the output, also all unit tests pass, so I hope I did not miss something. What do you think? Gerd

3 11

Commit r4183: add unit test that failed with code in r3821
by svn commit 28 Apr '18

28 Apr '18

Version mkgmap-r4183 was committed by gerd on Sat, 28 Apr 2018 add unit test that failed with code in r3821 I've now noticed that the problem was not in the index, it was in the code that arranges rules http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4183

1 0

Commit r4182: improve RuleIndex: Reduce number of evaluated rules
by svn commit 27 Apr '18

27 Apr '18

Version mkgmap-r4182 was committed by gerd on Fri, 27 Apr 2018 improve RuleIndex: Reduce number of evaluated rules The old index returned more rules than needed, thus the style evaluation was slowed down a bit. You can use logging to find the actual changes with this setting in logging.properties: uk.me.parabola.mkgmap.osmstyle.stats.level=INFO Slightly modified tags3.patch. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4182

2 1

Current mkgmap version has another java.lang.AssertionError:
by Felix Hartmann 27 Apr '18

27 Apr '18

java.lang.AssertionError: minlong=-8388608 at uk.me.parabola.imgfmt.app.trergn.TREFile.setBounds(TREFile.java:359) at uk.me.parabola.imgfmt.app.map.Map.setBounds(Map.java:162) at uk.me.parabola.mkgmap.build.MapBuilder.processInfo(MapBuilder.java:1000) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:288) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:290) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:286) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) I'm sure back 30-40 versions mkgmap had no problems here - I basically did not change my style (only removed one resolution) - and the data is the same. Happens on Asia continent map dem/contourline creation. java -ea -jar -Xmx20000M /home/contourlines/mkgmap.jar --dem=/home/contourlines/hgt/VIEW1/,/home/contourlines/hgt/ SRTM1v3.0/,/home/contourlines/hgt/VIEW3/,/home/contourlines/hgt/SRTM3v3.0/ --dem-dists=9936 --dem-poly=/home/contourlines/bounds/asia.poly --max-jobs=6 --reduce-point-density=3.6 --transparent --description=openmtbmap-srtm-Asia --style-file=srtm --latin1 --draw-priority=24 --mapname=74500000 --family-id=7450 --product-id=1 --series-name=openmtbmap-srtm-ASIA --family-name=mtbmap-srtm-ASIA --overview-mapname=mapsetz --tdbfile 7*.osm.pbf -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich

3 24

Commit r4181: Uncomment new code
by svn commit 27 Apr '18

27 Apr '18

Version mkgmap-r4181 was committed by gerd on Fri, 27 Apr 2018 Uncomment new code Sorry, commented it while writing the svn log message. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4181

1 0

Commit r4180: prevent AssertionError when writing TRE bounds at 180°
by svn commit 27 Apr '18

27 Apr '18

Version mkgmap-r4180 was committed by gerd on Fri, 27 Apr 2018 prevent AssertionError when writing TRE bounds at 180° The value 8388608 doesn't fit into a 3 bytes signed integer. We write -8388608 instead and Garmin seems to expect that. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4180

1 0

DEM directories and output
by Steph Ixus 26 Apr '18

26 Apr '18

Hi, With my scripts (GNU/Linux), the standard output changes if paths for dem include variables or not. Script with: --dem=/home/steph/srtm_Suisse/hgt/VIEW1/,/home/steph/srtm_Suisse/hgt/SRTM1v3.0/,/home/steph/srtm_Suisse/hgt/VIEW3/,/home/steph/srtm_Suisse/hgt/SRTM3v3.0/ Output: Found one style in /home/steph/osm/styles/default/ finished check-styles HGTReader: file N45E006.hgt not found but it should exist. Height values will be 0. HGTReader: file N45E007.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E006.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E007.hgt not found but it should exist. Height values will be 0. HGTReader: file N47E006.hgt not found but it should exist. Height values will be 0. HGTReader: file N47E007.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E005.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E008.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E009.hgt not found but it should exist. Height values will be 0. HGTReader: file N46E010.hgt not found but it should exist. Height values will be 0. HGTReader: file N45E008.hgt not found but it should exist. Height values will be 0. HGTReader: file N47E009.hgt not found but it should exist. Height values will be 0. HGTReader: file N47E010.hgt not found but it should exist. Height values will be 0. HGTReader: file N45E009.hgt not found but it should exist. Height values will be 0. HGTReader: file N47E008.hgt not found but it should exist. Height values will be 0. Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 But script with: --dem="$WORKDIR"/srtm_"$COUNTRY"/hgt/VIEW1/,"$WORKDIR"/srtm_"$COUNTRY"/hgt/SRTM1v3.0/,"$WORKDIR"/srtm_"$COUNTRY"/hgt/VIEW3/,"$WORKDIR"/srtm_"$COUNTRY"/hgt/SRTM3v3.0/ Output: Found one style in /home/steph/osm/styles/default/ finished check-styles Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Anyway, BaseCamp displays DEM shadows, so it's not a big deal. Just a weird difference… Regards Steph

2 1