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

Sat Jan 27 13:21:47 GMT 2018

Hi Gerd,

first I would suggest to wait for Steve is merging the block size branch
and just afterwards merge DEM branch to trunk. I think it's causing
trouble merging DEM branch before, as user might end up with errors.
Later start another branch for DEM-optimization.

I don't know how other global map providers are working. If they all
reusing the tile boundaries. In my opinion it's the fastest way and they
are definitely don't change often. Of course it would be nice to have a
option for mkgmap, writing .DEM files only and read them again later.
You pointed out before it's possible already by a hack, (It's working, I
just remember I forgot to gave the feedback to you), but of course it's
strange to use than 3rd party tools to finalize the map. But of course,
I can understand if it's a lot of programming work and not useful for
many users properly.

As you only can reuse DEM-data, if you keep the tile boundaries, you
still need to process DEM-data somehow. Do you think there will be an
speed up compared to using uncompressed hgt files? I mean if I only need
hgt files for a small area, it doesn't matter so much, if they are
zipped or not.

In general I don't like your idea about such a container. I have
concerns regarding changing a small amount of hgt-tiles with better
sources. There will be an issue and the complete container needs to be
rewritten. I think it's better to stay with the 1° grid of hgt files and
just have an converter to an intermediate format. This makes it much
easier to exchange hgt-data later.

Just my spontaneous thoughts

Henning

On 27.01.2018 16:54, Gerd Petermann wrote:
> 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
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>