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. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster@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@hotmail.com> Datum: Samstag, 27. Januar 2018 08:54 An: <mkgmap-dev@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-tp5909756p5...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev