[mkgmap-dev] Tiles pruned in DEM map

Wed Dec 30 08:50:37 GMT 2020

Hi Gerd

I'm going to experiment with the combined overview map and which
options cause problems. Also look at the effect of 0x4a polygons at
just 1 level.

I also notices that the combined overview (osmmap.img) is a fraction of
the size (~1%) of the sum of the ovm_ images that are used to build it.

Ticker

On Tue, 2020-12-29 at 15:52 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> thanks for the hints. I agree that the code in OverviewBuilder is not
> very clear. I'll have a closer look tomorrow, but at least we should
> remove the -order-by-decreasing-area when copying the options. Or
> maybe I change the code so that only the hgt/dem options are copied.
> I guess I was too lazy there.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 29. Dezember 2020 10:50
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
> 
> Hi Gerd & Carlos
> 
> Reading and trying to understand the code, I'm finding a few strange
> things with the Overview map generation, DEM, 0x4a etc
> 
> The most significant is that the MapBuilder invocation for the
> combined
> overview map normally runs without any options being passed to it.
> Only
> if --overview-dem-dist is supplied are all the other options
> (including
> --order-by-decreasing-area) passed in. I'm not sure if would be a
> good
> idea to supply all every time or just be more selective and filter
> out
> all but the necessary DEM options.
> 
> I'm still investigating the overview map levels. The ovm_ files are
> produced with all the overview-levels as specified by options. When
> this is read back by the overview combiner, a 0x4a polygon is added
> covering each ovm_ tile, but it looks like it is at all levels, so,
> for
> a tile with a large area or lots of detail is very likely to be split
> (if --order-by) or shunted around into another subdivision and
> multiple
> copies might exist.
> 
> My understanding of the purpose of the 0x4a is that, in the overview
> map, there should be exactly 1 per detailed tile. It would be
> sensible
> to set its maxResolution so it only occurs at one level.
> 
> After the 0x4a polygon has been added, a couple of bits of code scan
> for them in all the overview polygons. It might be possible to
> improve
> this, given they have just been added in the same processing phase.
> 
> If --order-by-decreasing-area is used, the overview map combiner
> shouldn't attempt to respect it because it doesn't have the full size
> information of polygons that cross a tile boundary. Rather it should
> respect the polygon ordering in each ovm_ tile. I'm not sure yet this
> is feasible; Maybe something like the equivalent of --preserve
> -element
> order for this phase and look at all the logic paths of polygons to
> stop any other order changes due to merging etc.
> 
> Ticker
> 
> 
> _______________________________________________
> 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