logo separator

[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


More information about the mkgmap-dev mailing list