[mkgmap-dev] HGT - getElevation()

Wed Jan 17 14:35:32 GMT 2018

Hi Andrzej,

I've tried your areas.list with 3'' hgt files with three different mkgmap versions (r4068, r4068 + dem-align2.patch (4068_e) and  r4068+dem-move2.patch (4068_m) .
I looked at 49.200000 20.00000 which - I think - should give 1872 m.
r4068 with aligned pbf shows 1872 m
r4068 with unaligned pbf shows 1863 m (due to interpolation)
r4068e with aligned pbf shows 1872 m
r4068e with unaligned pbf shows 1872m
r4068m with aligned pbf shows 1872 m
r4068m with unaligned pbf shows 1872m

I also did not see any movement in DEM (good), so I wondered why results differ so much from my tests with a tile in bolivia.
So I tried other bboxes, and found this one:
29000002: 2291022,918105 to 2297489,946049
When you use this for splitter it produces an OSM file with
	<bounds minlat="49.1599988" minlon="19.700396" maxlat="49.2987657" maxlon="20.3000093"/>
This seems to be a worser case as it shows different results:
r4068 says height is 1862, the others say 1872 but this time I see a clear movement in DEM between unpatched and patched binary.
Also this one shows this problem:
29000000: 2291022,918106 to 2297527,946049

It seems that there is a range where aligning is not okay. Still trying to find out the threshold value(s).

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej at poczta.onet.pl>
Gesendet: Dienstag, 16. Januar 2018 22:30:21
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] HGT - getElevation()

Hi Gerd,

I have done 2 kind of tests, both with mkgmap patched with your patch
for aligned HGT.

Fist test is more or less the same what you propose. I looked for a
round peak on a map and then searched for the highest value of DEM on a
peak, moving cursor around. With zoom 20m, I tried to estimate area,
where DEM is the highest and then I noted coordinates of the center of
this area.

Then I loaded original HGT into QGIS and looked for the coordinates and
position inside HGT pixel, which is displayed by QGIS as a square. I got
very good match, coordinates were near the center of the pixel and
height was the same as in Mapsource.

In second test I calculated manually areas.list with 2 tiles for
splitter. One tile aligned with HGT raster, second with left and top
edge moved by about half of HGT pixel size. I had to tweak these tiles a
bit and the final result was this:

29000000: 2291022,918087 to 2297546,946049
#       : aligned

29000001: 2291022,918097 to 2297534,946049
#       : non-aligned

After compiling these tiles, I got 2 maps with following coordinates:

N: 49.299989, S: 49.159999, W: 19.700010, E: 20.300009
DEM layers: 1, N: 49.300010, W: 19.700010

N: 49.299731, S: 49.159999, W: 19.700224, E: 20.300009
DEM layers: 1, N: 49.300010, W: 19.700010

As you can see, DEM position was the same, but map position was a bit
different in both tiles. Then I saved both tiles on virtual drive, where
they could be seen by BaseCamp as independent maps. I could switch
between tiles and compare shading. I uploaded screenshots.

I think about 2 more ways of testing. Frank in his manual about DEM,
described a clever way to sample DEM values from Mapsource. His tools
could be used to validate DEM conversion.

Another way could be to artificially move DEM area by multiple of HGT
pixel size. This would create a DEM with bigger offset but with the same
heights taken from interpolation. If the look of the map wouldn't
change, then we could assume, that programs can deal with offset correctly.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev