- mkgmap-dev - The mkgmap lists

r4072: slower but probably better
by Gerd Petermann 22 Jan '18

22 Jan '18

Hi all, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4072 I am not sure but I think it is a good idea to use 3312 for level 0 for 1'' hgt files now, and 9936 for 3''. As the values are rounded down, 3312 and 3314 will give the same result, as well as 9936 and 9942 My modifications compared to the patch are small, I've introduced constant EXTRA in DEMFile, removed unused import and adapted the unit test. I am not yet convinced that it is needed to round the dem-dist values, but Andrzej is right that this is what Garmin does and therefore it is less likely to cause problems certain devices. Maybe I'll add an option to use the exact value if that means that interpolation can be avoided. I'll also try to find faster code later. Frank is also working on a document regarding the problems adressed in the dem-align patches. Gerd

1 0

28 bit prec in DEM section header ?
by Gerd Petermann 21 Jan '18

21 Jan '18

Hi DEM experts, as Andrzej pointed out here [1] the Garmin maps seem to use 28 bit precision for some 32 bit values in DEM. I tried to find out if that means that MapSource actually ignores the lower 4 bits of the values. I've compiled two maps using --dem-dists=9942 for a tile created with split-file containing 29000000: 2291022,918105 to 2297489,946049 OSM data contains <bounds minlat="49.1599988" minlon="19.700396" maxlat="49.2987657" maxlon="20.3000093"/> One with original r4071, one with a change so that 9936 (0x26D0) instead of 9942 (0x26d6) is written to the DEM section header, If MapSource would ignore the lower 4 bits all should produce the same results, but that is not the case. Instead, the rectangle that contains DEM data is smaller with 9936, no height values are shown on the bottom and right side. The effect is clearly visible when I change the value in the header to 9000 instead of 9942, hill shading ara shrinks. Again: I only changed the value in the DEM header. I tried something similar with the location of the top left corner. The results are not that clear. I change both top and left by the same value. It seems that Garmin ignores rather small changes. -1000 : no effect -2000 : A large part of the map looks unchanged but there is a move of hill shading left from ~ E 19.75 -4000: Like with -2000 I see the same changes on the left but also a small change at the very top. -8000: all hill shading moves left and just a little bit up (!) -16000: all hill shading moves left and down , no obvious change near E 19.75 +1000 :no visible change +2000: all hill shading moves up +4000: again there is a boundary near E 19.75, data to the left moves up and maybe a little bit to the left, data on the right moves up and more to the right +8000: almost like with +4000, but small change on the bottom +16000: all hill shading moves up+right, but maybe not exactly by the same amount +32000: all hill shading moves up+right, no obvious change near E 19.75 To be continued. With very large values parts of the map have no hill shading. It is not that obvious to me how Garmin interprets the position values in the DEM header. Maybe one sees completely different results in other parts of the world or with larger maps containing more tiles. I guess that MapSources uses the position info to check if bbox of DEM data intersects bbox of tile, but there seems to be a complex rule how it determines where to place the calculated hill shading data. Maybe someone else finds a rule? [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027818.html ciao Gerd

2 1

Re: [mkgmap-dev] HGT - getElevation()
by Frank Stinner 21 Jan '18

21 Jan '18

Hi Gerd and Andrzej, > your choice of triangle is arbitrary. of course, but the version with 4 triangles isn't. > bilinear interpolation seems better Yes. It's a little bit more to calculate, but better. For our special case it is: h = h11 * (1 + y * x - x - y) + h21 * (x - y * x) + h12 * (y - y * x) + h22 * y * x (h11 is left-bottom in coordinate origin, the horizontal and vertical distance is 1) If your java-class have to much overhead, you can use this formula. By the way, i would be very defensive with interpolation in the case of missing values. The hgt values are only interpolated values from original measurments. I would not interpolate values in the near of missing values. That give us a nice but unreliably picture. Frank

6 57

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