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

Sat Jan 27 15:52:10 GMT 2018

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 at lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm at hscholland.de>
Gesendet: Samstag, 27. Januar 2018 14:21
An: mkgmap-dev at 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-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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev