[mkgmap-dev] Tiles pruned in DEM map

Mon Jan 4 18:52:46 GMT 2021

Hi Ticker,

thanks for the patch. I'll have a closer look during the next days. I don't yet understand why shapes aren't always merged.
What is the impact on the size of the overview map? What happens for those users who create the overview map in an extra step that doesn't have the --order-by-decreasing-area option? What happens when it's the other way around, no --order-by-decreasing-area option for the tiles but --order-by-decreasing-area for the overview map?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 4. Januar 2021 19:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Gerd

I found another unexpected case: giving the --dem... option caused the
overview map to have NET and NOD sections

To stops surprises, we should either pass in all the args and let the
receiver of them decide what to do with them or pass in only the
presumed significant options.

I think it much better to pass them all in; the logic to decide is then
all in the place where it is significant. I've made some changes to
this effect - attached.

In the case of --order-by-decreasing area, the final overview map needs
to know that this is wanted so it can keep the polygons in the same
order in each detail tile.

The large ovm_ size is because it has a LBL section containing all the
names for all levels. Unused ones don't make it into the final overview
so I don't think this is worth bothering with.

I've removed the scans for 0x4a polygons and do the equivalent when
they are inserted per detail tile. Also I've also removed some
misleading comments

Ticker

On Wed, 2020-12-30 at 11:21 +0000, Gerd Petermann wrote:
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev