January 2018 - mkgmap-dev - The mkgmap lists

Automatic block-size setting
by Steve Ratcliffe 20 Jan '18

20 Jan '18

Hi The branch auto-block contains changes to automatically find a suitable value for the --block-size option. Previously the default block size was almost always OK, but with the DEM changes the tiles are larger and a larger block size is sometimes required. All kinds of .img file (tiles, overview, gmapsupp and mdr) now work the same way. Gmapsupp.img files have always selected an appropriate block size, so there should not be much change there. Regular tiles may be a little bit smaller (~1%) as a larger block size sometime results in a file that is a bit smaller and if they are large enough to require a larger block size that will happen automatically. The osmmap_mdr.img files will typically be a lot smaller as previously they had a fixed block size of 16M and wasted a lot of space. Now the correctly block size will be selected and the file will be as small as possible. Currently the --block-size option still exists, but it just determines the smallest block size that will be used - if it is not large enough it will be increased. I could remove the option altogether or make it override the automatically determined value. ..Steve

3 4

splitter r586 still doesn't always align properly with --align-for-dem option
by Gerd Petermann 20 Jan '18

20 Jan '18

Hi all, I don't know yet why but alignment doesn't always work well. One problem is that we keep bbox data only with 24 bit resolution, but there must be more to it. I'll try to find out more but I have not much time until monday. Gerd

3 4

splitter r585 implements new option align-for-dem
by Gerd Petermann 18 Jan '18

18 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=585 If I got that right you can use dem-dist 9942 for level 0 if hgt files are in 3'' resolution and splitter was executed with --align-for-dem=1200. For hgt 1'' files use dem-dist 3342 for level 0 and --align-for-dem=3600. This should reduce DEM size a lot AND increase precision. Gerd

4 9

r4070 in dem-tdb branch
by Gerd Petermann 18 Jan '18

18 Jan '18

Hi all, I've merged branch auto-block into r4070 in the dem-tdb branch. I've first reverted the block-size.patch and fixed two conflicts manually. Gerd

2 1

confusing test results
by Gerd Petermann 17 Jan '18

17 Jan '18

Hi all, it seems that I am doing something wrong with my tests reg. Andrzejs dem-align-2.patch. I really tried hard to double check all steps, but now I see again other results compared to early afternoon :O Now I see again movement in DEM with all offsets, only an aligned tile looks good. Please, can someone else verify these results? In case you cannot patch or compile please use this binary: http://files.mkgmap.org.uk/download/398/mkgmap.jar I see this movement when I don't use --dem-dists or set it to 9942 (no further values). split-file (areas.list) for aligned tile: 29000000: 2291022,918087 to 2297546,946049 split-file (areas.list) for unaligned tile: 29000000: 2291022,918097 to 2297534,946049 In the meantime I'll see how I can change splitter to align data to hgt raster.... Gerd

1 0

v4058 dem-tdb crashes
by Andrzej Popowski 16 Jan '18

16 Jan '18

Hi Gerd, I have uploaded example at http://files.mkgmap.org.uk/download/392/test-crash.7z. java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Unknown Source) at java.nio.DirectByteBuffer.getShort(Unknown Source) at uk.me.parabola.mkgmap.reader.hgt.HGTReader.ele(HGTReader.java:203) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getElevation(HGTConverter.java:108) at uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getHeights(HGTConverter.java:302) at uk.me.parabola.imgfmt.app.dem.DEMSection.calcTiles(DEMSection.java:127) at uk.me.parabola.imgfmt.app.dem.DEMSection.<init>(DEMSection.java:74) at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:96) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:322) 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:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option -- Best regards, Andrzej

2 8

r4046: new algo for background (0x4b) in overview map
by Gerd Petermann 14 Jan '18

14 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4056 I am not sure how this works when you combine tiles that were created with the --transparent option with tiles that have a background, esp. if they cover different areas. Please test and report . Gerd

4 8

what do the 0x4a polygon in the mean?
by Gerd Petermann 14 Jan '18

14 Jan '18

Hi experts, today I played with a map that has non-rectangular shape. I tried this: Use the dem-poly option to cut also the 0x4b polygon for each tile, use these 0x4b polygons also in the overview map and also for 0x4a in the overview map. I expected that this would create nicer maps but found no effect in MapSource. I tried this with the sample from Andrzej. The DEM data in the Winterkarte does not show the steps which are produced by mkgmap at polygon boundary. What am I doing wrong? Gerd

3 11

DEM file and the block-size option
by Gerd Petermann 14 Jan '18

14 Jan '18

Hi all, the current default block-size is 512. This is used for most *.img files and gives a maximum file size of 65534*512 ~ 32MB. For large DEM files you might need a --block-size=1024 or even 2048. If I got that right you may run into the next problem when using this option as the mdr file will be also created with this value, and if no value is given it uses 16384 (which means the mdr file can grow close to 1GB) This disadvantage of a larger block-size is that your img files are typically a bit larger. @Steve: If I got that right we should be able to calculate the optimal block-size as we do know the number of bytes that we will write to the img-file before anything is actually written to the disk. Wouldn't that be much better? Gerd

5 15

The 0x4b background polygon in the overview map
by Gerd Petermann 12 Jan '18

12 Jan '18

Hi all, up to now mkgmap always creates a rectangular 0x4b polygon for the overview map. I wonder if I should change that so that the 0x4b polygons of the sub tiles are used. This seems to be the better way if we start using non-rectangular 0x4b polygons? Gerd

4 18