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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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