[mkgmap-dev] Tiles pruned in DEM map

Tue Jan 5 15:35:42 GMT 2021

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overview-v2.patch
Type: application/octet-stream
Size: 14317 bytes
Desc: overview-v2.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210105/c832195d/attachment-0001.obj>