Shapely: MultiPoint.difference(Point) behält die ursprüngliche Reihenfolge nicht bei

Erstellt am 1. Apr. 2019  ·  3Kommentare  ·  Quelle: Toblerity/Shapely

Einfaches Beispiel:

>>> from shapely.geometry import MultiPoint, Point
>>> points = MultiPoint([Point(0, 0), Point(1, 0), Point(1, 1), Point(0, 1)])
>>> points.wkt
'MULTIPOINT (0 0, 1 0, 1 1, 0 1)'
>>> bad_point = Point(1, 0)
>>> points.difference(bad_point).wkt
'MULTIPOINT (0 0, 0 1, 1 1)'

Wie Sie sehen können, bricht das Entfernen eines Point von einem MultiPoint mit difference die anfängliche Reihenfolge. Erwartete Ausgabe wäre:

'MULTIPOINT (0 0, 1 1, 0 1)'

Ist das ein Bug oder so gewollt? Docs sagen nichts zu diesem Verhalten.

Formschöne Version: 1.6.4.post1, installiert von conda.

documentation geos wontfix

Hilfreichster Kommentar

Siehe OGC 06-103r4 für einfachen Funktionszugriff , §6.1.5 für MultiPoint:

Die Punkte sind nicht in semantisch wichtiger Weise verbunden oder geordnet (siehe Diskussion bei GeometryCollection).

Dies weist also darauf hin, dass das Verhalten beabsichtigt ist. Es ist auch das gleiche Verhalten in JTS .

Ein ähnliches Objekt, das die Reihenfolge beibehält, ist ein [Multi]LineString , aber das Beispiel müsste anders verarbeitet werden.

Alle 3 Kommentare

Dies ist ein Verhalten, das von GEOS geerbt wird, der Bibliothek, die Shapely umhüllt.

Ich glaube nicht, dass das per se ein Bug ist. Es ist einfach nicht so, wie der Algorithmus funktioniert, der die Differenz berechnet. Die beiden Ausgänge sind geometrisch äquivalent. Ich glaube nicht, dass das einfache Feature-Modell der Reihenfolge der Teile in einer Sammlung Bedeutung beimisst.

Etwas, das dies erklärt, könnte der Dokumentation hinzugefügt werden. Ich bin mir nicht sicher, wo der beste Ort wäre, um es hinzuzufügen, da dies nichts Spezifisches für die Differenzmethode ist.

Siehe OGC 06-103r4 für einfachen Funktionszugriff , §6.1.5 für MultiPoint:

Die Punkte sind nicht in semantisch wichtiger Weise verbunden oder geordnet (siehe Diskussion bei GeometryCollection).

Dies weist also darauf hin, dass das Verhalten beabsichtigt ist. Es ist auch das gleiche Verhalten in JTS .

Ein ähnliches Objekt, das die Reihenfolge beibehält, ist ein [Multi]LineString , aber das Beispiel müsste anders verarbeitet werden.

OK, ich verstehe. Ich denke, ein warnendes Wort, dass man sich nicht darauf verlassen sollte, dass die Reihenfolge erhalten bleibt, könnte am Ende des Abschnitts _Collections_ hinzugefügt werden.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen