derzeit bin ich auf Erkundungstour zur Suche nach einem neuen RDBMS. Dabei steht unter anderem die Frage, ob es möglich ist mit PostGIS folgendes zu tun:
Finden aller Linestrings welche die Fläche um einen Punkt begrenzen. Ich habe ein Bild gemacht, bin aber zu dumm es hochzuladen. Darum der Versuch einer verbalen Erklärung.
Man stelle sich den Grundriss eines Hauses vor. Alle Kanten sind als Linestrings (so mache ich es zumindest in MySQL) gespeichert. Nun wird eine Koordinate, also ein Point, innerhalb des Grundrisses gegeben und PostGIS soll mir die ID’s aller Linestrings finden, welche die Fläche um den Punkt begrenzen. So zumindest der Wunsch.
Alles 2D alles in einem SRID. Die Bereitstellung von Plygonen ist nicht möglich. Geht sowas mit PostGIS?
Ja, das habe ich mir in der Doc schon mal angesehen. Theoretisch wäre das genau, was ich suchen, würde aber Polygone oder ähnlich geschlossene Geometrien voraussetzen. Genau die habe ich aber nicht, sondern will sie gerade erzeugen. Vielleicht war mein Beispiel auch etwas ungeschickt gewählt.
Nehmen wir statt des Hausgrundrisses also eine Katasterkarte. Alle Grenzen sind einzelne Linienelemente. Das ist schlicht so geregelt und ich glaube kaum, dass sich dort in den nächsten Jahren etwas ändern wird. In den einzelnen Flurstücken stehen die Flurstücks-Nummern (Punkte). Ich vernachlässige an dieser Stelle bewußt Sonderfälle. Z.B. eine Flurstücksnummer außerhalb des Grundstücks wenn die Fläche zu klein ist. Sonderfälle wird es immer geben.
Zu finden sind alle Grenzlinien um die Flurstücksnummern herum. So, wie ich die Beschreibung der ST_Contains-Funktion verstehe, setzt diese voraus, dass es sich um geschlossene Objekte um den Punkt herum handelt. ODER???
Über die Within-Funktionen habe ich ebenfalls nachgedacht. Das wäre der umgekehrte Weg. Hier gehe ich von den einzelnen Grenzen aus und suche in einem bestimmten Radius die Flurstücksnummern. Hört sich nicht schlecht an. Allerdings nur in Idealfällen. Das mit dem Hochladen hier habe ich immer noch nicht verstanden,
Nur mal am Beispiel der roten Linie würde die Funktion die Punkte A und/oder B, auf jeden Fall auch C finden, je nach Radius. Wobei C definitiv falsch wäre. ODER???
Ich weiß, probieren geht über studieren und ich will mich auch nicht vor der Arbeit drücken, aber vielleicht hat jemand von Euch ja schon mal Erfahrungen mit diesem Thema gesammelt.
Danke im Voraus - Peter - der sich über alle Hinweise freuen würde.
Das Polygon kannst du die dynamisch aus den Linien anhand der Flurstücksnummern erzeugen, in etwa so (Pseudocode!):
select linie.linie_id
from linientabelle linie,
(select make_polygonfromlines(linie) as polygon from linientabelle group by flurstücksnummer) poly
where st_within(Punkt, poly.polygon)
Damit bekommst du alle Linienids, die zu zu enem Flurstück gehören, in dem der Punkt liegt.
Gruß Uwe
EDIT: Ok., deine Linien haben keine Flurstücksnummer. Dann müsstest du von dem gewünschten Punkt aus einen Fächer an Linien mit genügender Länge und Winkelabstand ziehen. Diese schneidest du mit deinem Linien-Thema, erzeugst daraus jeweils den ersten Schnittpunkt entweder mit st_distance oder eleganter mit linearer Referenzierung und gruppierst über die Linien-id. Hat den NAchteil, das kurze Linien und Linien paralell der Strahlen nur durch Zufall getroffen werden. Du könntest aber auch aus allen Linien ein temporäres Polygonthema erzeugen, das alle Polygone enthält und die Linien ID als Attribute enthält, und darauf deine Abfrage starten.
Was auch immer du tust, du wirst früher oder später über deine Sonderfälle stolpern. Bist du denn an der Quelle der Daten und kannst jemand fragen oder nur Nutzer? Sind das ALK-Daten? Was sit das Ausgangsformat CAD, Shape, Annotations o.ä)? Meiner Erfahrung nach gibt es immer eine Verbindung zwischen den Themen, auch wenn diese manchmal nicht sichtbar, absichtlich versteckt und gelegentlich falsch ist…
Vielleicht hilft ja Paul Ramsey: Snapping Points in PostGIS schon weiter. Ich lese grad ‘Postgis in Action’, bin aber noch nicht soweit, daß ich sagen könnte, ich käme damit zurecht …
Braucht er dazu nicht eine Zuordnung der Flurstücksnummer zur Linie? (Für das innere Select) Ich hab es so verstanden, daß diese Zuordnung eben NICHT da ist. Außerdem dürften Linien mind. 2 Grundstücksnummern haben, quasi rechtes und linkes Grundstück von der Linie aus gesehen, und wenn auf der Linie noch eine weitere Linie steht auch 3 Grundstücke und so weiter.
Du könntest aber auch aus allen Linien ein temporäres Polygonthema erzeugen, das alle Polygone enthält und die Linien ID als Attribute enthält, und darauf deine Abfrage starten.
Das hört sich spannend an! Gibt es dafür eine Funktion?
Bist du denn an der Quelle der Daten und kannst jemand fragen oder nur Nutzer? Sind das ALK-Daten? Was sit das Ausgangsformat CAD, Shape, Annotations o.ä)?
Die Quelle sind in der Regel dumme DXF- bzw. Bricscad-Daten.
Ich lese grad ‘Postgis in Action’, bin aber noch nicht soweit, daß ich sagen könnte, ich käme damit zurecht …
Danke für den Tip. Taugt das was? Ich habe gerade in 2 PostgreSQL-Bücher fehlinvestriert und bin daher ein wenig schaumgebremst. PG für Windows (oder so ähnlich) war nicht gerade der Bringer, zumindest nicht für einen Einsteiger. Und von Datenbankentwicklung mit PG bin ich auch enttäuscht. So banale Dinge, bzw. PG-Spezifika, wie das Escapen in einer SQL-Abfrage oder auch das mir bis dato unbekannte ILIKE von PG waren darin unter anderem nicht zu finden.
PostGIS in Action stand eigentlich auch auf meiner Wunschliste. Allerdings kann ich nicht sagen, dass English zu meinen Stärken gehört.
Also ich finde das Postgis in Action recht gut gemacht. Der Aufbau ist sauber strukturiert, es gibt einen klaren ‘roten Faden’ durch das Buch. Jedes Kapitel behandelt ein Thema, es gibt je eine klare Einführung, Beispiele, Zusammenfassung. Ich brauche PostGIS nicht wirklich, will aber es grundlegend verstehen, da wir als Hoster zunehmend Kunden haben, die es einsetzen. Und das sind dann auch die Anwender, die richtig viel Daten haben. Da sind äußerst interessante Anwendungen dabei, sehr spannend. Unsere stärkste Kundenmaschine, die wir haben, ist ein dedizierter PG-Server mit PostGIS.
Zu PG-Büchern: es gibt einige gute, aber man muß wissen, was man sucht. Ich hab die auf Arbeit liegen, daher kann ich jetzt keine Titel nennen. Das Buch von ads (A. Scherbaum) gibt IMHO eine recht gute Grundübersicht, das von Bernd Helmle / peter Eisentraut ist eher für den Admin.
Wenn Du eine Referenz der einzelnen Befehle suchst: lies die originale Doku, die ist meiner Meinung nach sehr, sehr gut! Einfach mal die Kapitel da querlesen, dann findest Du bei Bedarf ALLES, was Du suchst.
Hallo!
Die Bücher, die Andreas empfohlen hat habe ich neben der Doku selbst in Gebrauch und kann sie nur empfehlen. PostGIS in Action ist wirklich gut, weil es recht aktuell ist (PostGIS 2.0) und viele Anwendungsbeispiele bringt.
Zu den Daten: Kannst du die dxf-Daten per Autocad bearbeiten? Hier könnten die Zusammenhänge sichtbarer werden. Eventuell könnte man das Problem damit einfacher lösen (Autocad kann im Übrigen ebenfalls über FDO lesend und schreibend auf PostGIS-Daten zugreifen).
Andernfalls gibt es einen PostGIS-Befehl, der aus Linien mögliche Polygone formt. Oder man sucht einen Ansatz über eine Liste der verwendeten Knoten oder analysiert, welche Linien Ringe bilden. Ich werd mich damit aber am Montag auseinandersetzen.
select st_astext((st_dump(st_polygonize(the_geom))).geom) from linientabelle
Dies hat bei mir in einem Testdatensatz eines Tin gut funktioniert. Allerdings waren das nur wenige Dreiecke, ich kann also wenig über komplexere Polygone und die Performance bei großen Datensätzen sagen.
ST_POLYGONIZE liefert eine Collection, die habe ich mit ST_DUMP in Einzelpolygone aufgelöst, die dann weiterverarbeitet werden können.
Einzubauen wäre das vielleicht so:
select p.punkt_id, p.flurstücksnummer, l.the_geom
from punkte p
join (select (st_dump(st_polygonize(the_geom))).geom as the_geom from linientabelle) l on st_within(p.the_geom, l.the_geom))
Code ohne Kaffee und Gwähr
Allerdings liefert dir das auch doppelte EInträge wenn die Beschriftung ausserhalb des zugehörigen Polygons liegt. Hier müsstest du z.B. in AutoCad oder ArcGIS prüfen, ob da eine Verbindung hergestellt werden kann (Stichwort Annotation-Layer).
vielen Dank für Deine Mühen. Zunächst ging es mir ja um die grundsätzlichen Möglichkeiten. So, wie Du es hier aufgebaut hast, scheinen die vorhanden zu sein. Danke. Sobald ich Luft habe, werde ich das angehen.
Momentan bin ich beim Testen der Basics und das sieht so gut aus, dass wir mittlerweile ernsthaft über einen Umstieg auf PG nachdenken.
Thema FDO … ja kenne ich. Mit PostgreSQL 9.1 und PostGIS 1.5 habe ich am WE eine Verbindung zu MapGuide Open Source (MGOS) hinbekommen. Wobei meines Wissens eine FDO für PostGIS 2.x in scheinbar unendlicher Ferne liegt. Das ist kein generelles Problem, denn momentan arbeiten wir mit MySQL zur Speicherung der Spatial-Daten für MGOS. Und nach erstem Anschein deckt PostGIS das allemal ab. Wenn wir allerdings migrieren, dann wünschen wir uns hier einen Mehrwert. Darum auch mein Bohren hier im Forum.
Im eigenen Hause steht uns AutoCAD zur Verfügung, wobei ich denke, dass FDO’s nur von MAP und ähnlichen Produkten unterstützt wird, nicht vom reinen AutoCAD. Unsere Kunden steigen allerdings immer mehr zu Bricscad um. DWG ist da das native Format und DXF wird mindestens ebenso gut verwaltet wie in ACAD. Das, und noch viel mehr, zu einem Bruchteil des ACAD-Preises. Natürlich könnten wir unter Bricscad die Topologiefunktionen von MAP nachprogrammieren. Aber mein Denkansatz ist, diese Funktionen aus dem CAD soweit wie möglich rauszunehmen und in die Datenbank zu verlagern. Die Haltung der Sachdaten erfolgt momentan mit SQL Anywhere. Seit Version 12 können dort auch Spatial-Daten verwaltet werden. Übrigens sogar mit einem GUI, dass Abfrageergebnisse graphisch darstellt. Ist insich eine wirklich elegante Lösung. Nur hat Sybase NULL Interesse an einer FDO. Vermutlich weil die seit einigen Jahren SAP gehören. Damit also für MGOS nicht wirklich verwendbar.
Wenn unsere Test erfolgreich verlaufen kann es also sein, dass nicht nur MySQL sondern auch Sybase durch PostgreSQL abgelöst wird.
Code ohne Kaffee und Gwähr > >
gbg … sollten wir uns mal persönlich begegnen gebe ich Dir den Kaffe gerne selbst aus.
>