[mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon
From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Jun 15 13:11:37 BST 2021
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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at 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
- Previous message: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon
- Next message: [mkgmap-dev] Commit r4763: - fix bug in Coord.distToLineSegment(Coord a, Coord b), it returned Double.NaN when a and b are the same
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list