Hi Henning, Steve and I agreed that it is okay to merge auto-block into dem-tdb branch instead of trunk. This already happened, so there is no plan to merge auto-block into trunk. I think you are right, it should be easier to reuse complete DEM files. Maybe I can implement this as a faster alternative, e.g. a new option --reuse-dem=<path-to-old-map> where input could be a gmapsupp or gmapi or a directory containing *.img files. When calculating DEM for tile xyz the program would first to find tile xyz in that map, check if position and size matches, and then simply copy the file. This should not require much new code. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Samstag, 27. Januar 2018 14:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Is dem-tdb branch ready for trunk ? 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-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