Mein Problem: ich habe eine große Anzahl von Ortspunkten, die mit metrischen Koordinaten vorliegen und im SRID 31467 dargestellt werden. Soweit so gut. Nun geht es darum, diese Daten mit Verwaltungseinheiten (Bundesländer etc.) zu verschneiden (ST_CONTAINS usw.). Shapefiles mit Informationen zu den Verwaltungseinheiten gibt es massig im www - allerdings verwenden sie alle Winkelkoordinaten, die ich als Anfänger nicht sinnvoll in das SRID der Ortspunkte übertragen kann (ST_TRANSFORM). Kann mir hier jemand weiterhelfen?
Wieso sollte das nicht gehen? Entweder du machst das on the Fly bei der Abfrage mit (z.B. st_within(st_transform(punkte.the_geom, 4326), grenzen.the_geom), oder du projizierest dein Shapefile mit einem Desktop-GIS um und liest es dann in die DB ein, oder du machst die ganze Auswertung im DesktopGIS z.B. QGis und erledigst die Umprojektion mit der eingestellten Kartenprojektion. Du könntest auch eine neue Geometrie-Spalte anlegen und mittels st_transform, die Geometrie dort in der gewünschten SR ablegen. Möglichkeiten zuhauf also
Danke für Deine Antwort.
Du hast natürlich Recht. Mein Problem hatte ich allerdings auch unzureichend beschrieben, weil ich mir nun einmal die Geometry-Daten in der DB angesehen habe. Und siehe da: die Schwierigkeiten liegen nicht in der Umprojektion, sondern in den Koordinaten an sich, die um erhebliche Beträge nach N und E verschoben sind. Deswegen fruchtete auch die Anwendung von ST_TRANSFORM nicht. Wie es aussieht, muss ich mit meinen Daten zunächst einmal ein TRANSLATE durchführen - um welchen Betrag auch immer - , bevor ich überhaupt an eine Verschneidung denken kann. Das Problem ist also auf gewisse Weise “gelöst”.
Hallo,
ich habe ein ähnliches Problem. Ich habe eine Datenbank mit Punkten, die mit SimpleMercator projeziert wurden. Nun möchte ich alle Punkte bekommen, die innerhalb einer bestimmten Fläche (Bounding Box) liegen. Die Punkte, die die Fläche begrenzen habe ich jedoch nur in Geokoordinaten. Ich habe mal
SELECT ST_Transform(ST_SetSRID(ST_MakePoint(50.1, 8.7), 900913), 900913)
ausprobiert, das liefert auch etwas zurück (900913 ist die SRID (btw, wofür steht das?) meiner Projektion).
Wenn ich
SELECT ST_X(ST_Transform(ST_SetSRID(ST_MakePoint(50.1, 8.7), 900913), 900913))
verwende, bekomme ich allerdings wieder ca. 50.1 (mit kleiner Floating Point-Abweichung). Ich hatte gehofft, einen projezierten Wert zu bekommen. Die Werte in der DB liegen für X etwa im Bereich 600000000.
Wie kann ich die Projektion anwenden?
PS: Meine Daten kommen von OpenStreetMap
900913 ist die Spatial Reference ID mit der OSM und Google arbeiten.
Was machen deine SQL-Statements:
Punkt erzeugen, 900913 als SRID zuweisen, und das ganze nochmal nach 900913 projizieren. Das zweite Statement liest noch die x-Koordinate aus. Damit da was anderes rauskommt als du reingeschrieben hast, mußt du beim ST-Transform eine andere SRID angeben als im Orginalpunkt, z.B. 4326 (WGS84).
Ok, hab jetzt verstanden, dass ST_Transform von der SRID der Geometry in die neue, angegebene umwandelt. Die spatial_ref_sys Tabelle hat bei mir nur den Eintrag mit der SRID 900913. Was muss ich denn angeben für Geokoordinaten? Wenn ich die ST_SetSRID-Anweisung weglasse, bekomme ich die Fehlermeldung “Input geometry has unknown (-1) SRID”
Naja PostGIS bezieht seine Informationen zur Umproektion aus dieser Tabelle. Wenn da nix drin steht, kann es auch nicht umprojizieren. In der Sorce-Edition ist aber das SQL dabei, das die Tabelle füllt, dorft könntest du die entsprechenden Informationen finden.
Vielen Dank erstmal! Ich gehe mal davon aus, dass 4326 die SRID ist, die ich für Geokoordinaten verwenden muss. Irgendwie bekomme ich trotzdem noch falsche Werte. In meiner Datenbank steht z.B. ein Eintrag 2;646985238;92409686;"{place,village,name,Wiesbaden-Naurod}" Wiesbaden-Naurod hat die Geokoordinaten 50.13472 / 8.301388. Wenn ich die Anweisung
SELECT ST_X(ST_Transform(ST_SetSRID(ST_MakePoint(50.13472,8.301388), 4326), 900913))
erhalte ich leider die Werte 5580971.501463349 927356.51419300877, die irgendwie nicht ganz im Bereich des Wertes in der Datenbank liegen. Kann es sein, dass PostGis/OSM da noch einen Faktor drin hat (100? 110?)
Viele Grüße