[mkgmap-dev] Problems with sea in overview map

Tue May 25 09:55:30 BST 2021

Hi Ticker,

I think self-intersection is not the (only) root cause for the problems of empty sea areas. At least the Garmin software doesn't seem to have problem with that.
I learned that we really should avoid to split in PolygonSplitterFilter with resolution < 24.
The split process can create small fragments which collaps to a single point or line when rounding and thus are not added to the map.  Maybe the code could be changed to merge the small fragments again when the goal of the splitting is the reduction of points. That also means that my idea of "merging all shapes before splitting into subdivs" doesn't work well when this means that the merged polygon is split again.

I'd also prefer to merge only those shapes which share at least one segment but the cutting of multipolygons often produces two shapes which only seem to have a common segment but in fact do not, probably a possible common node is removed when converting to java area.
I've not yet found out why this happens so often, I would have expected that this is rare. My suspect is the CutPoint.compareTo() method.

There are various ways to merge n shapes even when you only merge when shapes have a common segment, so I think that it is OK to get different results as the algorithmn doesn't even try to avoid self-intersections. Whenever shapes are merged so that they enclose a hole you have self-intersection.
It could be avoided to do such a merge, I'll try if this helps. The current code just tries to merge the longer sequence of common segments.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 25. Mai 2021 10:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

I think we need to step back and consider the various stages towards a
good overview map which I see as:

0/ MultiPolygons spliting (just added this after I wrote the rest)
1/ subDiv shapeMerge
2/ filter chain into the ovm_ img
3/ loading all the ovm_ img into the combiner
4/ any special global merging (per overview level?)
5/ standard-ish map generation into the overview map
   ie subdivs as necessary, shape allocation into them with possible
   splitting, subdiv shapeMerge, filtering & output

Just considering subDiv shapeMerge, because, while this is producing
self-intersection and/or other errors, looking to solve problems in the
following stages is futile.

For stress-testing, it should be allowed to merge without a point limit
at res24; ShapeSpitter will deal it or report errors. Verification
should be done by looking at the ovm_ img rather than the final
overview map.

It must be wrong that its behaviour depends on the processing order.

You say it just uses identity of coord points to make all decisions; ie
it doesn't try and test if a point in one shape is on a line in another
shape. Assuming this:

To merge 2 shapes, they must have a LineSegment in common (ie each has
2 identical adjacent points in the correct direction (determinable from
the sign of the area). From finding a common LineSegment, adjacent
common LineSegments are included. Then the 2 shapes are joined without
these LineSegments (after any necessary direction correction). Any
other common LineSegments between these polygons must be ignored,
otherwise holes will get closed up.

The process is repeated until all shapes in the candidate pool have
been considered.

Sharing a single point is not good enough to consider a merge - I see
figure-of-8 problems emerging from trying this.

Ticker

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev