Hi Gerd I had to zoom in to < 10miles, with detail set to "Highest", before the forest appeared. It was difficult to know where to start from. Then, at that level, it is very tedious to scroll around trying to finds the holes. Ticker On Tue, 2021-04-27 at 12:48 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for investigating. I've used the patch with trunk r4680 and just --gmapi option. I see that GpsMapEdit shows no hole, but Mapsource and Basecamp still don't show the map. Any idea why?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 27. April 2021 13:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Empty rectangles in map
Hi Gerd and others
The cause for this unrendered area is as follows:
A large multipolygon (larger than the maximum size for a level 1 subdiv) exists, and is broken into some similar size pieces and some smaller pieces to expose inners/holes. The same problem can be caused by any polygons having these size properties.
Option --order-by-decreasing-area is not in effect (with this option the problem goes away).
At the outermost level, the large pieces are split into the grid of subdivs necessary to be within size limits. Small pieces that fit within a subdiv are allocated to the correct one. Intermediate pieces that extend out of the nominal subdiv bounds, but don't exceed the actual addressing limits, are allocated to an existing subdiv based on their centre. Larger pieces that fit in a subdiv but would cause size problems if added to an existing subdiv are given a subdiv of their own.
At the next level down, each of the above subdivs will required splitting to fit within the addressing limits. The logic that did this used the subdiv bounds and split this into a grid. Then every element in the outer MapArea is processed as above (ie split, safely placed, placed with overlap or own subdiv)
The problem is that the splitting algorithm simply goes through the child subdiv, clips the polygon to this size and saves the bits that are within the area. Polygon parts that are outside the defined outer level never get noticed!
There are various possible solutions:
Method 1: use the rigorous polygon splitting into subdivs that - -order -by-decreasing-area uses for levels above level 0. This is simple to implement, safe, mergeShapes might recombine more cut fragments as they are all together. Disadvantages are that, for a normal map, more polygons might be split, leading to larger RGN size (but not for bad -map-split.osm.pbf). The overall size is still less that with --order -by...
Method 2: When the child subdiv grid is created, use any expanded size of the parent subdiv. This stops overhanging bits of polygons being lost. Again, simple to implement. It results in overlapping subdivs at lower levels and I don't know this causes other problems, but probably not; this used to be done and still does for some sizes of polygons and lines. Some shape-merging won't happen because the joining bits are in a different subdiv.
Method 3: Allocated oversize polygons to their own subdiv. Again, simple to implement, but I see no advantage over Method 2. Even more shape-merging might not happen.
Method 4: Detect when an object will have bits missed and semi-cut rather than clip them to continue having an oversize part in the child subdiv. This is more complicated to implement but, if done, could replace the clipping code and be more efficient. If a parent subDiv is divided into 2 children, it already happens like this.
Although I prefer Method 1, I suspect Method 2 is what should be done in the short-term and so I've attached a patch that is configured for Method 2, but, with a couple of edits to change some flag handling, does Method 1.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev