[mkgmap-dev] Tiles pruned in DEM map

Wed Jan 6 09:19:46 GMT 2021

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