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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@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-boun...@lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkg...@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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
o_hp.gpx
Description: o_hp.gpx
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
