[mkgmap-dev] Is dem-tdb branch ready for trunk ?

Sat Jan 27 13:57:51 GMT 2018

Hi
I think before having such a container we would need to have a clear 
idea what hgt sources are best. I have no objective method to compare 
hgt sources (is there any?) but I have done some test comparing contour 
lines generated from different sources. Copernicus (EU-DEM) data has 
been commented to be better than viewfinderpanoramas (VFP), but at least 
visually, the later seems better to me. The problem with VFP is that 1'' 
data is available only in a few places. SRTM1 seems to produce better 
results than EU-DEM, but in some places it has a lot of voids. Just my 
findings. If you are interested, I can post some screenshots for 
comparison.

El 27/01/18 a las 09:54, Gerd Petermann escribió:
> Hi all,
>
> I am not aware of any erros in r4091, so I think it is time to merge it into trunk.
>
> I see only one problem: HGT data changes rarely, so I'd prefer to do the costly DEM calculations
> only once and be able to store the results.
> I've already described how to do this here [1] but I'd prefer to have a container format that allows
> mkgmap to extract the Garmin DEM bitstream data for a given lat/lon pair from a file.
> Such a container could contain the DEM data for one or more dem-dist values. It could be empty first
> and grow each time you calculate DEM for a new area. In subsequent executions of mkgmap it would
> check if the container already contains the data for the wanted area.
> Advantage would be a faster tile compilation and less power consumption, disadvantage would be the
> additional disk space and higher complexity.
>
> [1] http://gis.19327.n8.nabble.com/Performance-with-zipped-hgt-files-tp5909756p5909801.html
>
> Gerd
>
>
>
>