Hi Ticker, yes, this code needs review, thanks for this. For now I've just disabled the --order-by-decreasing-area option for the overview map in r4590 I am not sure if it would be better to always pass the args to MapBuilder or only those for DEM. I'd prefer to always pass them but maybe there are other side effects Reg. size 1%: My understanding was that the merging of shapes is responsible for all of this, but I might be wrong. I am working on a routing issue that I found while looking at Carlos' problem. It only happens with --x-no-force-end-nodes-routing-nodes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 30. Dezember 2020 09:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map 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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev