logo separator

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

From Gerd Petermann gpetermann_muenchen at hotmail.com on Sat Jan 27 10:21:12 GMT 2018

Hi Thomas,

I see two major problems with this:
1) A file containing all DEM data for e.g. dem-dist=9936 would be huge, and most users only need a small portion of it
2) I am not sure if it is allowed to publish this data when input comes from e.g. 1'' hgt files which are not free.
My understanding is that you may need a licence for this.

Besides that my idea of a container format would be close to that. Maybe it would allow to create a download
service, something like "request the precompiled DEM data for dem-dist x for a given bounding box or polygon".

Unfortunately it seems impossible to reuse complete DEM files unless you also re-use the tile boundaries.
If I got that right only a few users are using splitter with the split-file option.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster at img2ms.de>
Gesendet: Samstag, 27. Januar 2018 10:40
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

Maybee we can create a ready to use DEM-model, store it like the bounds.zip
and see.zip ? The user can download it and mkgmap reads the DEM from
downloaded #DEM.ZIP# ?
This method would be a graet advantage for users, who not so familiar with
the DEM .
Regards Thomas
Von: "Gerd Petermann" <GPetermann_muenchen at hotmail.com>
Datum: Samstag, 27. Januar 2018 08:54
An: <mkgmap-dev at lists.mkgmap.org.uk>
Betreff: [mkgmap-dev] Is dem-tdb branch ready for trunk ?

> 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
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list