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-boun...@lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkg...@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-boun...@lists.mkgmap.org.uk> im Auftrag > > von Ticker Berkin <rwb-mkg...@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-boun...@lists.mkgmap.org.uk> im > > > Auftrag > > > von Ticker Berkin <rwb-mkg...@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/1 > > > > 1. > > > > 19 > > > > 91 > > > > > > > > ________________________________________ > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im > > > > Auftrag > > > > von Ticker Berkin <rwb-mkg...@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@lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
