[mkgmap-dev] Tiles pruned in DEM map

Wed Dec 30 11:21:55 GMT 2020

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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at 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 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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev