[mkgmap-dev] Tiles pruned in DEM map

Thu Jan 21 17:45:57 GMT 2021

Hi Gerd

This hasn't changed. For each input ovm_ img it gets an Area from
FileInfo.getBounds() then makes a 0x4a polygon from this, setting it's
name to the tile "Descriptions \n Mapname".

I've not found anything in recent versions that do anything different,
including suppressing the above if it finds an existing 0x4a in the
input.

Ticker

On Thu, 2021-01-21 at 15:45 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> oops, I wanted to remove the foreach loop. Anyway, my understanding
> is that the new code doesn't allow non-rectangular 0x4a shapes in the
> overview map while the old code did, at least when a *.mp file
> contains a non-rectangular 0x4a polygon. So, if the ovm_* file
> contains a 0x4a polygon we should use that.
> I just looked at the overview map for the Adria demo map and it has
> non-rectangular 0x4a polygons (close to the country boundaries )
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 21. Januar 2021 16:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
> 
> Hi Gerd
> 
> Each 0x4a polygon generated by the OverviewBuilder corresponds to a
> detail tile and I avoided changing anything relating to this except
> stopping them getting chopped up into SubDivisions by the --order-by
> logic (the initial reason for this thread) and outputting them before
> the other polygons in the detail tile area.
> 
> If the detail tiles are transparent (implemented as none of the input
> tiles having a 0x4b polygon), OverviewBuilder adds one. It is
> generated
> as a rectangle covering all the detail tiles rather than the shape of
> all the tiles. I've not changed this apart from outputting it first.
> 
> A shape that matches all the detail tiles is generated for use by the
> DEM overview and could, maybe, be used for the 0x4b. I don't think
> this
> is worth doing as part of this change.
> 
> I haven't made any changes to existing polygons that are input into
> OverviewBuilder (from whatever source); all, including 0x4a and 0x4b
> are passed on. It is unlikely that a user defined 0x4a polygon would
> be
> correctly set up, and, as seen by Carlos in his Australia map,
> getting
> it wrong has very strange effects as you zoom in and out of the
> overview.
> 
> I've attached a slightly updated patch - it looks like there was a
> for
> loop that should have been deleted when replaced by a forEach in
> OverviewBuilder::addMapCoverageArea
> 
> Ticker
> 
> On Thu, 2021-01-21 at 06:48 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > sorry for the delay, I started a very time consuming mapping in my
> > area to unglue landuse areas from highways....
> > 
> > I looked at overview-v3.patch in more detail. I don't understand
> > the
> > changes regarding 0x4a polygons. I am not sure but I think it is a
> > step in the wrong direction. I think one goal is to allow arbitrary
> > polygons with 0x4 with OSM input (similar to the --dem-polygon) as
> > we
> > already do with polish (*.mp) format. So, you should not assume
> > that
> > the 0x4a polygon is a rectangle. I might be confusing this with
> > 0x4b
> > though.
> > Besides that I changed a few things to improve readability.
> > 
> > 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, 13. Januar 2021 11:01
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
> > 
> > Hi Gerd
> > 
> > My understanding of the overview map was that it was for BaseCamp
> > and
> > MapSource, and it is used instead of the detail tiles as you zoom
> > out.
> > I had also assumed that it shares the same TYP as the detail tiles.
> > For
> > --order-by, this TYP will have equal [_drawOrder]. So the overview
> > map,
> > to display correctly, must also output polygons in the display
> > order.
> > 
> > Ticker
> > 
> > On Wed, 2021-01-13 at 09:46 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > I fear I don't get it. If --order-by option is only improving the
> > > map
> > > on the device I see no need to use it for a map that is not used
> > > on
> > > the device, esp. not when it has negative effects.
> > > 
> > > 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, 13. Januar 2021 10:41
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
> > > 
> > > Hi Gerd
> > > 
> > > I don't think this is the point of the patch.
> > > 
> > > --order-by is known to increase the size of the main map. This is
> > > accepted by users who consider the benefit worthwhile. The
> > > overview
> > > map, needing to operate in the same environment, has to keep to
> > > the
> > > same principals and this can lead to a size increase and the
> > > effect
> > > you
> > > mention of a label being off-center, because the named area has
> > > been
> > > split and the display software labels one part and suppress the
> > > label
> > > on the other.
> > > 
> > > A good example depends on finding overlayed polygons that either:
> > > 
> > > a/ conflict with a given TYP [_drawOrder] - for example, using
> > > mapnik.txt, you won't see any land features within Amenity/0x23,
> > > Parking/0x05, Industrial/0x0c
> > > 
> > > b/ have equal [_drawOrder], ie most landuse areas etc, where what
> > > will
> > > be displayed depends mostly on the internal logic of mkgmap, and,
> > > slightly by OSM extract ordering and the original object
> > > complexity.
> > > 
> > > Finding these examples would be tedious. I originally noticed
> > > these
> > > types of problems because the eTrex HCx starts displaying as soon
> > > as
> > > possible, and I'd see interesting features disappear from the
> > > display
> > > as it worked through everything that should be on the screen.
> > > 
> > > Ticker
> > > 
> > > 
> > > On Wed, 2021-01-13 at 08:21 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > I've hoped for a good example that shows how --order-by...
> > > > really
> > > > improves the overview map. I gave an example where the only
> > > > visible
> > > > difference is a label that is slightly off (so the patch
> > > > worsens
> > > > the
> > > > map).
> > > > 
> > > > Gerd
> > > > 
> > > > ________________________________________
> > > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > > Auftrag
> > > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > > Gesendet: Montag, 11. Januar 2021 12:39
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
> > > > 
> > > > 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.58
> > > > > > 15
> > > > > > /1
> > > > > > 1.
> > > > > > 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
> > > > _______________________________________________
> > > > 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
> > _______________________________________________
> > 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