[mkgmap-dev] Tiles pruned in DEM map

Wed Jan 6 09:35:07 GMT 2021

Hi Ticker,

OK regarding the naming.
I think what I tried to point out is that the overview map probably never suffers the problem that should be solved with the order-by stuff, but on the other hand we really want to keep that map as small as possible to allow continent or maybe even planet wide overview maps.  So, I really prefer to enable the shape merging for the overview map.
A possible work around might be to merge the shapes before MapSplitter is executed. The number of points is rather small, so performance shouldn't be a problem as it is with real OSM data. We might even use java.awt.area for that.
Another question is if the --order-by could/should be disabled for the ovm_ maps.

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, 6. Januar 2021 10:19
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Gerd

Sorry about overview-dem-dists.

I'd prefer the Map variable to be called IsOverviewComponent to make
clear the distinction between the 2 types of overview and to be
consistent with the names used in MapBuilder. I can do a patch to this
effect.

--order-by is expected to increase the map size a bit; extra polygon
splitting (in the ovm_ and carried into the composite) is performed so
that all polygons at any given point are in the same subdivision and
some merges (in both the ovm_ and the composite) are inhibited.

An overview map is unlikely to have multiple overlayed polygons so
probably there won't be any cases where a fixed _drawOrder couldn't be
defined correctly, but it exists with the detail tiles that need a TYP
where all _drawOrders are equal.

Ticker

On Tue, 2021-01-05 at 15:35 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> there is a typo in the patch, overview-dem-dists instead of overview
> -dem-dist. My rather small overview map got 20MB instead of 181K ;)
> I also didn't like the idea that the overview map is recognized by
> the name. That can lead to strange effects with test maps, so I added
> a parameter.
>
> With the corrections the size increases by only by 5K, but I have no
> idea how these 5K improve the map.
> I see one small difference where a label of a lake (1)  is placed a
> bit of the center. The "patched" map contains two polygons for this
> lake, I assume the Garmin software avoids to render its name twice
> but uses a different algo to calculate the position. These are the
> results for my own style, a variant of Minkos OpenFietsMap Light
> style.
> Will try again with default style and type file sameOrder.txt.
>
> Gerd
> (1)
> https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 5. Januar 2021 10:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
>
> Hi Gerd
>
> shapeMergeFilter.merge() sorts the shapes according to typ, skipSize,
> fullArea and name. For --order-by to work for the overview, this must
> not happen; the order in the ovm_ files must be used. This is the
> same
> idea as when the more than 1 detail tiles are displayed on a device.
>
> The size of osmmap.img for my test area, with the patch, is:
>  9216 --no-order-by-decreasing-area throughout
> 10752 --order-by-decreasing-area throughout
>  9219 --order-by-decreasing-area at start,
>       --no-order-by-decreasing-area for the combiners
> So, there is a slight increase, as expected, it really isn't of any
> significance.
>
> --order-by-decreasing-area needs to be applied to both phases for it
> to
> work correctly.
>
> If applied to the tile phase only, the overview map will render
> polygons in order of the results of the the shapeMergeFilter.
>
> If applied to the overview phase only, probably similar; the order of
> the shapeMergeFilter governed ordering in the ovm_ .img
>
> Ticker
>
> On Mon, 2021-01-04 at 18:52 +0000, Gerd Petermann wrote:
> > 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
>
> _______________________________________________
> 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