Hi Ticker, okay, no problem, I'll work on the faster-mp branch in the mean time Maybe I'll merge it first into the low-res-opt branch. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 7. Juni 2021 11:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon Hi Gerd The shape I'm getting in my build has a major problem with a twist between the 2 parts. I'm having trouble reconciling it with the OSM map. I've attached the original shape trace. I agree that some of the messages do need tweaking, but, in this cases there is a significant problem. I'll consider the types of messages etc in the new version I'm working on. I'm away for a few days and won't be able to do much remotely. Ticker On Mon, 2021-06-07 at 07:22 +0000, Gerd Petermann wrote:

Hi Ticker,

please check https://files.mkgmap.org.uk/download/512/63240024.o5m with (unpatched) r4756 and these options --generate -sea=multipolygon,floodblocker --preserve-element-order --order-by -decreasing-area --allow-reverse-merge

Produces an error message SCHWERWIEGEND (ShapeSplitter): e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split 36691968 failed on shape at http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 P ossibly a self-intersecting polygon for this invalid multipolygon : https://www.openstreetmap.org/relation/5294624

The result doesn't look wrong, so I think there should either be no error message or we need code to remove those self-intersections or ignore invalid MP like that?

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

Hi Ticker, my understanding is that Garmin software has no problems with this kind of self-intersection. In this particular case the problem could be solved in method MultipolygonRelation.joinWays(), as 4 ways are connected at the same point, but self-intersecting shapes are also possible as simple ways. While they are wrong for OSM they should be allowed for MapShape since Garmin allows them, too. A possible way to fix those shapes is something like this: Path2D.Double path = Java2DConverter.createPath2D(polygonPoints); path.setWindingRule(Path2D.WIND_EVEN_ODD); List<List<Coord>> shapes = Java2DConverter.areaToShapes(new java.awt.geom.Area(path)); So, maybe ShapeSplitter could do this with the input shape in case of error and try again with shapes? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagIT.co.uk> Gesendet: Dienstag, 8. Juni 2021 08:54 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon Hi Gerd The shape is a figure-of-8 so shapesSplitter needs to give some error. If this isn't an original OSM shape, it points to some problem with earlier processing, probably shape-merging. Although it might render (could be device dependent), further processing (eg overview merging) could come to grief. Ticker On 07/06/2021 10:24, Gerd Petermann wrote:

Hi Ticker,

okay, no problem, I'll work on the faster-mp branch in the mean time Maybe I'll merge it first into the low-res-opt branch.

Gerd

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

Hi Gerd

The shape I'm getting in my build has a major problem with a twist between the 2 parts. I'm having trouble reconciling it with the OSM map. I've attached the original shape trace.

I agree that some of the messages do need tweaking, but, in this cases there is a significant problem.

I'll consider the types of messages etc in the new version I'm working on.

I'm away for a few days and won't be able to do much remotely.

Ticker

On Mon, 2021-06-07 at 07:22 +0000, Gerd Petermann wrote:

...

Hi Ticker,

please check https://files.mkgmap.org.uk/download/512/63240024.o5m with (unpatched) r4756 and these options --generate -sea=multipolygon,floodblocker --preserve-element-order --order-by -decreasing-area --allow-reverse-merge

Produces an error message SCHWERWIEGEND (ShapeSplitter): e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split 36691968 failed on shape at http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 P ossibly a self-intersecting polygon for this invalid multipolygon : https://www.openstreetmap.org/relation/5294624

The result doesn't look wrong, so I think there should either be no error message or we need code to remove those self-intersections or ignore invalid MP like that?

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

---

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

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

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

Hi Ticker, your patch seems to introduce a new bug. It returns an empty list of shapes when I call ShapeSplitter.clipToBounds(largest.getPoints(), src.getBounds(), null) with largest equal to Planet for the attached (empty) tile. Compile attached tile with --precomp-sea=sea.zip --improve-overview Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon 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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd Any form of self-intersection might cause problems to ShapeSplitter. Not sure what you mean by "connected hole visited.." - I presume something like the outer edge of the shape is clockwise, with a cut leading to a hole that is also clockwise; for this to happen the in/out lines from the edge to the hole conceptually cross. I'm just running low-res-opt on BritishIsles with ShapeMergeFilter maxPoints=65535 to see if I can get a problem to work on. What is your test area? Also, the latest development versions of the suspect code areas are in different branches. Should I attempt to have a composite with the faster-mp bits of MP handling and low-res-opt version of ShapeMergeFilter? Your attached example looks OK and I wouldn't have expected it to cause any difficulties for the later versions of ShapeSplitter. A possible difficulty might be an almost horizontal line close to the in/out lines to the lower shape. I hope my attempt to allow a bit of tolerance where calculated points on the cut-line end up 1/2 HP units the wrong way round isn't causing other problems. Do you have this as an example I can test? Ticker On Sun, 2021-06-13 at 14:17 +0000, Gerd Petermann wrote:

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

Hi Gerd Made some progress! I needed to disable the EPS_HP=2 tolerance along the cut line otherwise there were correct cases that could be interpreted incorrectly. I also needed not to chuck away very small areas otherwise your test complained. The major problem was valid shapes that had parts with zero area when cut and passed through the same point on the cut-line as another line. The main tiles in xxx.zip now build without error with order-by and no -order-by, even with ShapeMergeFilter maxPoints = 65535. However, the overview builder, when --no-order-by and --improve -overview, fails splitting. The shape presented to ShapeSplitter has obvious self-intersections (with --order-by, shape merge is disabled in the overview builder) Ticker On Mon, 2021-06-14 at 08:28 +0000, Gerd Petermann wrote:

Hi Ticker,

I am still testing with the files in https://files.mkgmap.org.uk/download/507/xxx.zip

I applied the attached patch to enable massive merging and simulating possible splits and your splitShapeFix_10_lowRes.patch and I see several error messages. The previously attached example comes from xxx\63240004.osm.pbf

My options: --output-dir=e:\ld --gmapi --generate-sea=multipolygon,floodblocker --preserve-element-order --order-by-decreasing-area --allow-reverse-merge --improve-overview --min-size-polygon=2 -c e:\xxx\template.args

Gerd

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

Hi Gerd

Any form of self-intersection might cause problems to ShapeSplitter. Not sure what you mean by "connected hole visited.." - I presume something like the outer edge of the shape is clockwise, with a cut leading to a hole that is also clockwise; for this to happen the in/out lines from the edge to the hole conceptually cross.

I'm just running low-res-opt on BritishIsles with ShapeMergeFilter maxPoints=65535 to see if I can get a problem to work on. What is your test area?

Also, the latest development versions of the suspect code areas are in different branches. Should I attempt to have a composite with the faster-mp bits of MP handling and low-res-opt version of ShapeMergeFilter?

Your attached example looks OK and I wouldn't have expected it to cause any difficulties for the later versions of ShapeSplitter. A possible difficulty might be an almost horizontal line close to the in/out lines to the lower shape. I hope my attempt to allow a bit of tolerance where calculated points on the cut-line end up 1/2 HP units the wrong way round isn't causing other problems. Do you have this as an example I can test?

Ticker

On Sun, 2021-06-13 at 14:17 +0000, Gerd Petermann wrote:

...

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

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

Hi Ticker, reg. my test which compares area sizes: It is normal that the size of the area changes a bit when the cut adds points in the middle of long segments. You can see the difference in JOSM when you zoom in. Besides that I think that ShapeSplitter should not drop anything that is visible. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 14. Juni 2021 18:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon But going back to running GBR, I'm getting more errors - I'll have to see if there is a compromise. Ticker On Mon, 2021-06-14 at 16:39 +0100, Ticker Berkin wrote:

Hi Gerd

Made some progress! I needed to disable the EPS_HP=2 tolerance along the cut line otherwise there were correct cases that could be interpreted incorrectly. I also needed not to chuck away very small areas otherwise your test complained. The major problem was valid shapes that had parts with zero area when cut and passed through the same point on the cut-line as another line.

The main tiles in xxx.zip now build without error with order-by and no -order-by, even with ShapeMergeFilter maxPoints = 65535.

However, the overview builder, when --no-order-by and --improve -overview, fails splitting. The shape presented to ShapeSplitter has obvious self-intersections (with --order-by, shape merge is disabled in the overview builder)

Ticker

On Mon, 2021-06-14 at 08:28 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I am still testing with the files in https://files.mkgmap.org.uk/download/507/xxx.zip

I applied the attached patch to enable massive merging and simulating possible splits and your splitShapeFix_10_lowRes.patch and I see several error messages. The previously attached example comes from xxx\63240004.osm.pbf

My options: --output-dir=e:\ld --gmapi --generate -sea=multipolygon,floodblocker --preserve-element-order --order-by-decreasing-area --allow-reverse-merge --improve-overview --min-size-polygon=2 -c e:\xxx\template.args

Gerd

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

Hi Gerd

Any form of self-intersection might cause problems to ShapeSplitter. Not sure what you mean by "connected hole visited.." - I presume something like the outer edge of the shape is clockwise, with a cut leading to a hole that is also clockwise; for this to happen the in/out lines from the edge to the hole conceptually cross.

I'm just running low-res-opt on BritishIsles with ShapeMergeFilter maxPoints=65535 to see if I can get a problem to work on. What is your test area?

Also, the latest development versions of the suspect code areas are in different branches. Should I attempt to have a composite with the faster-mp bits of MP handling and low-res-opt version of ShapeMergeFilter?

Your attached example looks OK and I wouldn't have expected it to cause any difficulties for the later versions of ShapeSplitter. A possible difficulty might be an almost horizontal line close to the in/out lines to the lower shape. I hope my attempt to allow a bit of tolerance where calculated points on the cut-line end up 1/2 HP units the wrong way round isn't causing other problems. Do you have this as an example I can test?

Ticker

On Sun, 2021-06-13 at 14:17 +0000, Gerd Petermann wrote:

...

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

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

---

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

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

Hi Ticker, yes, looks better. I think we can / must disable massive merging when isOverviewCombined is true. I found no way to make sure that shape merger doesn't "jump around". It might be a problem of the sorting for "byCenter". I guess it can happen when several small bits are glued to the same side of one shape. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 14. Juni 2021 19:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon Hi Gerd Looking at the first few GBR problems, it is shapeMergeFilter trying to merge lots of adjacent, irregular, fields. They are all simple polygons. It seems to be generating backward and forward lines all over the place that don't make much sense, mostly not having a hole at the end of them. So I think ShapeSplitter_11 hasn't been proved faulty yet. I'll look at shapeMerge. Ticker On Mon, 2021-06-14 at 17:14 +0100, Ticker Berkin wrote:

But going back to running GBR, I'm getting more errors - I'll have to see if there is a compromise.

Ticker

On Mon, 2021-06-14 at 16:39 +0100, Ticker Berkin wrote:

...

Hi Gerd

Made some progress! I needed to disable the EPS_HP=2 tolerance along the cut line otherwise there were correct cases that could be interpreted incorrectly. I also needed not to chuck away very small areas otherwise your test complained. The major problem was valid shapes that had parts with zero area when cut and passed through the same point on the cut-line as another line.

The main tiles in xxx.zip now build without error with order-by and no -order-by, even with ShapeMergeFilter maxPoints = 65535.

However, the overview builder, when --no-order-by and --improve -overview, fails splitting. The shape presented to ShapeSplitter has obvious self-intersections (with --order-by, shape merge is disabled in the overview builder)

Ticker

On Mon, 2021-06-14 at 08:28 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I am still testing with the files in https://files.mkgmap.org.uk/download/507/xxx.zip

I applied the attached patch to enable massive merging and simulating possible splits and your splitShapeFix_10_lowRes.patch and I see several error messages. The previously attached example comes from xxx\63240004.osm.pbf

My options: --output-dir=e:\ld --gmapi --generate -sea=multipolygon,floodblocker --preserve-element-order --order-by-decreasing-area --allow-reverse-merge --improve-overview --min-size-polygon=2 -c e:\xxx\template.args

Gerd

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

Hi Gerd

Any form of self-intersection might cause problems to ShapeSplitter. Not sure what you mean by "connected hole visited.." - I presume something like the outer edge of the shape is clockwise, with a cut leading to a hole that is also clockwise; for this to happen the in/out lines from the edge to the hole conceptually cross.

I'm just running low-res-opt on BritishIsles with ShapeMergeFilter maxPoints=65535 to see if I can get a problem to work on. What is your test area?

Also, the latest development versions of the suspect code areas are in different branches. Should I attempt to have a composite with the faster-mp bits of MP handling and low-res-opt version of ShapeMergeFilter?

Your attached example looks OK and I wouldn't have expected it to cause any difficulties for the later versions of ShapeSplitter. A possible difficulty might be an almost horizontal line close to the in/out lines to the lower shape. I hope my attempt to allow a bit of tolerance where calculated points on the cut-line end up 1/2 HP units the wrong way round isn't causing other problems. Do you have this as an example I can test?

Ticker

On Sun, 2021-06-13 at 14:17 +0000, Gerd Petermann wrote:

...

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

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

---

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

---

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

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

Hi Ticker, thanks for the example. In fact I didn't even think about such really overlapping shapes yet. The basic shape merger simply tries to find common sequences of nodes and merges them. It never computes areas, and that's what makes it fast (I think). I'll try a different implementation which might be slower but producing better results using the method which I implemented in SeaGenerator with r4777. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 15. Juni 2021 13:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon Hi Gerd An example I'm looking at where shapeSplitter detects a self -intersection is 3 landuse=farmland polygons, 2 sharing corners, the other an edge: https://www.openstreetmap.org/way/678511630 https://www.openstreetmap.org/way/678511631 https://www.openstreetmap.org/way/677666500 They correctly share the corner node: https://www.openstreetmap.org/node/6353263807 which is also the open/closing node for 678511631 They then share a few nodes going away from the corner except that way 677666500 has an extra node between the nodes shared with 678511630 The merged shape, I presume, takes this extra node as an indication of a hole, but then traverses it the wrong way round (segments 16,17,18). A more obvious self-intersection is at 54.72854,-7.36444, but this is a fault in the OSM mapping (segments 51,58&59) Also segments 106,107&114 and possibly others are incorrect OSM data. I'm having trouble understanding the logic of shapeMerger, but maybe the first case could be fixable (but not by me). With all these real OSM data problems in a small area, I'm coming to the conclusion (as you already have, I think) that, except for merging the results of MP cutting, nothing should be merged that then might require splitting again. This is a bit of a shame, because at lower resolutions it is very likely that the final RNG line length will be much less than the limit and splitting wouldn't happen. Ticker