[mkgmap-dev] Tiles pruned in DEM map

Tue Jan 5 09:58:00 GMT 2021

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