
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