Re: [mkgmap-dev] Automatic block-size setting
Hi Steve, it was my first impression, that MDR got only big blocks, but you are right, there are all sizes used. Now that I have looked more carefully, I see some inconsistency. MDR img has always the same structure, I would suspect, that block size increase with file size, but it is not true. See list of my files sorted by img size: File: SAmTopo_mdr.img, length 176291840 fat:400h - 600h - 6200h, block 16384 File: SAmOTBR_mdr.img, length 113917952 fat:400h - 600h - 7C00h, block 8192 File: AfricaHR_mdr.img, length 56901632 fat:400h - 600h - 2600h, block 16384 File: SAmOTS_mdr.img, length 35307520 fat:400h - 600h - 2C00h, block 8192 File: SAmOTN_mdr.img, length 18628608 fat:400h - 600h - 1C00h, block 8192 File: SAmOTEC_mdr.img, length 17248256 fat:400h - 600h - 2C00h, block 4096 File: AfricaN_mdr.img, length 13844480 fat:400h - 600h - 1800h, block 8192 File: AfricaS_mdr.img, length 11411456 fat:400h - 600h - 2000h, block 4096 File: AfricaW_mdr.img, length 8376320 fat:400h - 600h - 1A00h, block 4096 File: AfricaC_mdr.img, length 7897088 fat:400h - 600h - 1A00h, block 4096 File: AfricaE_mdr.img, length 6871040 fat:400h - 600h - 2400h, block 2048 File: AfricaSE_mdr.img, length 4153344 fat:400h - 600h - 1A00h, block 2048 File: AfricaSW_mdr.img, length 3403776 fat:400h - 600h - 1000h, block 4096 File: AfricaNE_mdr.img, length 2904064 fat:400h - 600h - E00h, block 4096 Probably something unimportant, but a bit surprising. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Automatic block-size setting
Hi Andrzej I have looked at block sizes and all is reasonable. Tiles are usually 2k or 4k, ovm_* are 512 or 1k, MDR are 8k or bigger. I guess you have set some preference for bigger blocks in case of MDR. I read your post where you noted that often bigger block sizes lead to a smaller file, so I made it calculate the whole file size and then pick the smallest one. Unless there is a bug, there should not be any special preference for larger blocks in the MDR case, I just did a run with trace information and I got: INFO: bs=512, whole size=47126016, hb=386, fb=91657, blocks=92043 INFO: bs=1024, whole size=47029248, hb=98, fb=45829, blocks=45927 INFO: bs=2048, whole size=46981120, hb=25, fb=22915, blocks=22940 INFO: bs=4096, whole size=46960640, hb=7, fb=11458, blocks=11465 INFO: bs=8192, whole size=46956544, hb=2, fb=5730, blocks=5732 INFO: bs=16384, whole size=46972928, hb=1, fb=2866, blocks=2867 [ hb = number of header blocks, fb = number of file blocks ] So the block size = 8192 does seem to give the lowest file size; only by 4k bytes. I was a bit suprised, but the number of header blocks needed goes down by a quarter when the block size is doubled, and that makes up for the wastage of bigger blocks. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi, here is my version of mkgmap for tests: http://files.mkgmap.org.uk/download/403/mkgmap-dem-tdb-r4071-bicubic.zip Changes are following: - dem-dists values are rounded to 16, - DEM coordinates are multiples of dem-dists, - DEM values are calculated with bicubic interpolation for layers with dem-dists <= 9942. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Gerd, > Maybe you can create a 2nd branch so that others can try the > different results? I hardly know java, have no IDE for work or any experience in SVN. Basically I can tweak your code and compile it with ant. I could post compiled version if there is any interest. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Automatic block-size setting
Hi Steve, I have compiled several maps with r4070 without even noticing, that it include your new code. I think it means, that you have done a good work, thanks! I have looked at block sizes and all is reasonable. Tiles are usually 2k or 4k, ovm_* are 512 or 1k, MDR are 8k or bigger. I guess you have set some preference for bigger blocks in case of MDR. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HGT - getElevation()
Hi Andrzej, I'll try this on monday, Maybe you can create a 2nd branch so that others can try the different results? BTW: I think that the calculation of qx and qy for the interpolation should be changed. The current code in 4071 adds up rounding errors when data for the upper right area is calculated in a large tile spanning multiple degrees. I am working on that. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Samstag, 20. Januar 2018 00:50:19 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] HGT - getElevation() Hi Gerd, I have included bicubic interpolation created by Ken Perlin: https://github.com/mlevans/pretty-heatmaps/blob/master/DensityArrayCreation/src/DensityArrayCreation/Bicubic.java Bicubic interpolation is used only for layers with good resolution (3 arc seconds or better). For other cases bilinear interpolation is used. Patch is attached. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] 28 bit prec in DEM section header ?
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 2900: 2291022,918105 to 2297489,946049 OSM data contains 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
