[mkgmap-dev] Tiles pruned in DEM map

Mon Jan 11 11:39:53 GMT 2021

Hi Gerd

Here is an updated patch with the naming changes.

Ticker

On Wed, 2021-01-06 at 09:35 +0000, Gerd Petermann wrote:
> 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.19
> > 91
> > 
> > ________________________________________
> > 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
> _______________________________________________
> 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-v3.patch
Type: text/x-patch
Size: 14338 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210111/96967fb0/attachment-0001.bin>