[mkgmap-dev] Tiles pruned in DEM map

Tue Dec 29 15:52:45 GMT 2020

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