[mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

Sun Jun 13 15:17:57 BST 2021

Hi Ticker,

OK, my current understanding is that ShapeSplitter may fail to split 8-like shapes or shapes where the connected hole is visited in the "wrong" direction. Those problem cases are possibly created by
1) MultipolygonRelation.joinways()
2) MultipolygonCutter
3) ShapeMergeFilter (maybe)

Do you see a way to avoid them in those routines? Attached is another example that doesn't work.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Sonntag, 13. Juni 2021 07:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

Hi Gerd

The last 2 patches (9 & 10) might seem more complex with having another
level of structure for sorting, but are logically simpler and more
robust.

The warning messages are there for when ShapeSplitter might not keep
the integrity of non-self-intersection when faced with cuts across many
lines (at least 4), of certain configurations, at the same point. If
ShapeMerge generates these and follow-on processing after ShapeSplitter
has problems, it saves a lot of debugging time to know that this has
happened. I haven't yet seen cases relating to this class of splitter
warnings and it might be that they will never get generated.

Max shapeMerging has generated much more complex cases where a shape
runs along the same line multiple times. The original code could cope
with 2 always and more of some configurations. The unit tests had a
geographic shape much more complex than anything expected in OSM and a
typical shape after the old shapeMerge had re-merged MP with holes.

When the problems with MP cutting generating self-intersection has been
fixed I hope there will be no more problems with ShapeSplitter. Then
there might be no reason not to take shapeMerge to the max.

Ticker

On Sat, 2021-06-12 at 08:56 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> the code is getting more complex with each patch and I don't fully
> understand why because the unit tests never changed.
>
> I doubt that a warning message like "Possible ambiguous balloon
> allocation at ..." will help anyone except you ;)
>
> I am not sure if you are wasting your time here. I've almost dropped
> the idea that ShapeMergeFilter could merge to the max, so I wonder in
> what situation you face those degenerated polygons?
> If the only "normal" source is the joinWays() algo in
> MultipolygonRelation I fully agree that we should change that first.
> We just have to decide which version we use: trunk or the faster-mp
> branch or the low-res-opt branch.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Freitag, 11. Juni 2021 16:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from
> ShapeSplitter for self-intersecting multipolygon
>
> Hi Gerd
>
> I've improved ShapeSplitter so it can cope with more cases when there
> are multiple lines at the same point on the cut-line. Any problems
> will
> generate a single log.error, with reasons as log.warn and more
> information as log.info and gpx traces if log.debugEnabled()
>
> Ticker
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o_hp.gpx
Type: application/octet-stream
Size: 18549 bytes
Desc: o_hp.gpx
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210613/8c2938ed/attachment-0001.obj>