[mkgmap-dev] Tiles pruned in DEM map

Wed Jan 6 13:59:59 GMT 2021

Hi Gerd

Because (I presume) the overview map needs to share the same TYP as the
detail tiles, something must be done to ensure that polygons in the
overview map are ordered in the correct way.

The main problem in the overview is that it doesn't have the
original/full areas, before tile clipping and other splitting happens.
So it seemed most correct, and certainly the simplest method, to
preserve the order in each tile.

It might be possible to have a special version of the merging that
keeps all the partial orders per tile except for the polygons that get
merged into another polygon. This will require a bit of work to
implement and could suffer two problems that I can see.

1/ Some apparently mergeable polygons shouldn't be merged because they
derive from different objects, the knowledge of which has been lost by
this point. If merged, it could then disrupt the partial ordering logic
(a bit like a file compare syncing on the the wrong line).

2/ The merged areas might overflow their subdivision and this would
lead to the non-order-by MapSplitter logic shifting some polygons into
a new subdivision that overlaps the same area. This could cause the
rendering to be incorrect.

Another option would be:
 No need to generate the ovm_ imgs with order-by.
 Allow full merging.
 Calculate the areas of the merged polygons and sort by this.
   This could be inaccurate because of the low resolution and not give
   the correct order, for reasons given above.
 In the map splitting phase, prevent the 0x4a polygon from being split;
   this is what caused the Australia problem.
The significant problem with this is that the style (and the sea
default) can override the rendering order and this information is lost.

Is this extra size of the overview map (5k in your case, 1.5k in mine
where the full gmapsupp.img is 27M), such a problem.

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