Das sollte mit ST_Intersection() oder ST_Difference() funktionieren. Die Funktionen liefern dir die jeweilige Schnittmengen alsGeometrien. Die kannst du dann weiterverarbeiten. Die jeweilligen IDs aus der Ausgangsgeometrie dürften dabei allerding wohl nicht erhaltenbleiben, die müsstest du dir in einem anderen Konstrukt besorgen.
Doch was genau oder wie funktioniert st_intersection.
Aus dem Manual werde geht das leider nicht so hervor.
Legt st_intersection eine Box um die Werte oder einen eigenen Buffer oder oder. Sprich wie vergleicht es die beiden Geometryn.
Also mit intersection bekommt man die Schnitmenge das ist an sich auch super.
Doch was ist wenn man an die Punkte der einzelnen Tracks bekommen möchte weil sie mehr Informationen besitzen.
[CENTER]
[LEFT]Mit Intersection bekommt man die Schnittpunkte jeweils in den blauen Kreisen wieder. Ok Super.
Wie bekommt man aber die Original Punkte die sich annähernd berühren. Klar man muss ein Buffer um beide legen oder nur um einen.
Idee 1:
Geht das nur in dem ich jeden einzelnen Punk mit dem anderem Track vergleiche.
z.B Über Abstands Berechnung, der ganzen Punkte.
Punkt 1 von Rot zu Punkt 1 von Blau => Abstand < Wert X
dann Speicher Punkt 1 rot und Punkt 1 blau ab.
Oder gibt es eine Methode die dieses erledigt.
Idee 2:
Es gibt da ja auch Within aber die antwortet ja leider nur mit True oder Fals. Also muss man dann wieder Einzelne Punkte untersuchen.
Idee 3:
Suche gerade das gegenteil von difference!
Noch am überlegen bzw Suchen.
Also eine Methode, die dir die Schnittpunkte zweier Polygone zurückgibt existiert soweit ich weiß nicht. Wenn du die genauen Schnittpunkte möchtest, dann könnte es so funktionieren:
Polygon mit ST_ExteriorRing(geometry) zu Linie konvertieren. Wobei ich mir nicht ganz sicher bin ob die Funktion auch wirklich das macht.
Eine Intersektion durchführen. Dann bekommst du die Schnittpunkte.
Wenn du die annähernd gleichen Punkte haben möchtest kommst du glaube ich nicht darum herum die Punkte der beiden Polygone gegeneinander zu vergleichen.
Du kannst das ganze höchstens noch folgendermaßen einschränken:
Buffer (Größe je nach Schwellenwert) um beide Polygone legen und Intersection ausführen.
Alle Punkte der ursprünglichen Polygone die in der Schnittmenge liegen gegeneinander vergleichen.
Mit diesem Hilfskonstrukt verhinderst du, dass du die Punkte, die sowieso nicht in Frage kommen unnötig bearbeiten musst. Das ganze dürfte sich vor allem bei “punktreichen” Polygonen auf die Geschwindigkeit auswirken.
Danke erst mal für die Antworten.
Ich habe einiges ausprobiert und getestet mit Beispielen die sehr simpel sind.
Dabei habe ich festgestellt das intersection neue Schnittpunkte zurück gibt ist für manches gut aber das kann ich leider nicht gebrauchen.
Difference ist an sich super, aber ich brauch genau das gegenteil von dieser Methode.
Meine Lösung geht jetzt mit within. Mein Problem ist jetzt die Laufzeit.
Die liegt momentan leider bei 750’000ms.
Obwohl ich schon einige Abfragen vorher Stelle wo durch ich einige Punkte Ausschließe.
select g.id,g.messung_id
from gps_messwerte g,
track x inner join messung y on (x.id=y.track_id),
track t inner join messung m on (t.id=m.track_id)
where
t.id=6
and x.id != t.id
and box2d(x.geom) && box2d(t.geom) = True
and g.messung_id != m.id
and g.messung_id = y.id
and box2d(g.geom) @ box2d(t.geom) = True
and within(transform(g.geom,31467),buffer(transform(t.geom,31467),2) )
order by id
limit 10;
Ohne within liegt die Abfrage bei 1313 ms.
Und liefert 9300 Punkte wenn man das limit nicht Berücksichtigt.
Meine Frage wie kann man das schneller machen oder vereinfachen.
Desweiteren habe ich noch eine Frage wie geht Postgres bzw Postgis die Bedingungen durch.
Ich habe mal explain vor meine Abfrage gesetzt und habe folgendes erhalten.
Ich kenne PostGIS/within() nicht, aber PostgreSQL kann funktionale Indexe. Möglicherweise könnte dies Dir hier massiv helfen.
Desweiteren habe ich noch eine Frage wie geht Postgres bzw Postgis die Bedingungen durch.
Ich habe mal > explain > vor meine Abfrage gesetzt und habe folgendes erhalten.
Ein EXPLAIN ANALYSE ist hilfreicher.
Ansonsten: das, was am tiefsten in der Verschachtelung da ist, wird zuerst gemacht.
Vielleicht kommt ja der Gisman gleich um die Ecke und kann noch a bissl mehr sagen…
Jo, da bin ich, leider auch etwas ratlos. Meiner Erfahrung nach sind Funktionen wie within ziemlich teuer, je nach dem wie komplex die Geometrien sind, ich bin auch oft damit beschäftigt. Ich kann auch nicht abschätzen, welchen Effekt die verschachtelten Funktionen im within-Statement haben. Haben die Geometrien denn einen Index?
Über funktionale Indexe kann ich leider nichts berichte, da ich das noch nicht gehört habe. Aber es hört sich mal gut an und ich werde nachher gleich mal danach suchen…
Jo, Danke für das Beispiel. Ich hatte es gerade gelesen und es scheint bereits ein Problem zu lösen, bevor es aufgetaucht ist In der Theorie zumindest…
@Wolf: Das stimmt schon alles, wenn ich mich nicht verkuckt hab. Warum transformst du eigentlich jede Geometrie nach GK3? Sind die aus der Track-Tabelle nicht auch 4326/lat-lon? Wenn das nicht nötig ist, könnte das auch ein bissle was einsparen.
Also, an der Transformation liegt es nicht, die brauch 500 ms für 20 Lienestrings rund 30’000 Points.
Es liegt er an dem Buffer der brauch zu lange. Da aus einem Linestring ein Polygon erstellt wird. Mit Radius 2 oder x.
Ich werde jetzt eine zusätzliche Spalte erstellen und diese dann mit dem fertigen Buffer, vom Linestring in GK Koordinaten, fühlen. Das ganze wird einmal über SQL oder über einen Trigger passieren mal sehen was schneller und besser ist.