TS_Transform macht Schwierigkeiten

Hallochen,

ich versuche eben meine Daten mal in einer anderen Projektion aus der DB zu holen, was jedoch zu eigenartigen Ergebnissen führt.

Hier mal eine Testabfrage:

Hier das Ergebnis:

Hier mal die Abfrage als SVG-Koordinatensatz (wird von mir benötigt):

Hier das unschöne Ergebnis:

Die normalen, untransformierten Datensätze sind vollkommen in Ordnung, aber sobald ich TS_Transform anwenden will, kommen eigenartige, bis hin zu leeren Ergebnisfeldern!?

Weiß jemand, was da schief geht?

Vielen Dank und viele Grüße an alle hier! :smiley:

Zeigst du das in PGAdmin an? Wenn ja, der macht ab und zu Blödsinn beim Anzeigen, die Daten an sich sollte in Ordnung sein. Wie sieht denn die Ausgabe in der Konsole aus? Mit SVG kenn ich mich allerdings nicht aus.

Gruß Uwe

Hallo, nein, ich benutze dafür Navicat, weils etwas übersichtlicher ist (kann zwar mit PostGIS nicht umgehen, aber wenns um reine Abfragen und Daten geht ist das ok).
Der gleiche Quark kommt auch in den normalen Ergebnissen in meinem PHP-Script an. Die Anzeige oben stimmt also leider wirklich.
Ja, wegen SVG das ist nur mal noch so angefügt. Aber oben in der normalen Abfrage sieht man ja auch schon, dass da ziemlicher Unfug kommt (koord_4 z.B.).
Das sollte nach einem einfachen simplify auf jeden Fall nicht so aussehen!? Weswegen ich da schon davon ausgehe, dass mit den Ergebnissen was nicht stimmt.
Bei jeglicher umarbeitung der Ergebnisse, sei es durch simplify oder assvg verschärft sich das Problem dann anscheinend durch die Unstimmigkeiten in den gelieferten Daten.
Ich tippe also mal darauf, dass hier auf jeden Fall bei TS_Transform was schief geht, nur was und warum?
Die Funktion habe ich bisher noch nie benutzt und bin deshalb etwas ratlos.

Hab jetzt mal an eine andere Verschachtelung gedacht und das mal versucht, aber sobald assvg ins Spiel kommt wirds Müll.
Als “nur” transformiertes und vereinfachtes Ergebnis wirkte es nach dieser Methode garnicht so schlecht:
assvg(ST_Transform(simplify(the_geom,30),4326),1,0) …

Ergebnis:
0106000020E610000001000000010300000001000000B70000008AE318E34CFB2A40681DF0ECCD534A40A3DEFEF… usw. also auf den ersten Blick ganz ok.

Nach folgender SVG-Umwandlung:
assvg(ST_Transform(simplify(the_geom,30),4326),1,0)

… dann aber wieder sowas hier:
M 13 -53 l 0 0 0 -0 0 0 -0 0 -0 0 -0 0 -0 0 -0 0 0 0 0 -0 0 0 0 0 0 0 0 0 0 0 0 0 -0 0 0 0 0 0 -0 0 0 … und noch viel mehr Nullen… hmpf!

Sorry, die erste SQL-Zeile im Beitrag hier drüber sollte ohne umschließendes assvg() sein.

Wie sieht das Ergebnis aus wenn du astext verwendest? Steht da drin, was du an Koordinaten erwartest? Wie sehen denn die Eingabe-Koordinaten aus?

Gruß Uwe

Danke für diese Frage!!!
Mit astext ging es wunderbar und dann habe ich mal geschaut was anders ist.
Ich hatte doch von Gauß-Krüger noch die Null Nachkommastellen drin stehen und das hat dann natürlich das Ergebnis geplättet, da sich bei Lambert das meiste hinter dem Komma abspielt.
Da mussten ja, im Zusammenhang mit den relativen Positionen, Differenzen im Null-Bereich entstehen… :wink:

Danke, auch Fragen helfen manchmal aus einer Denksackgasse heraus. :smiley:

Nachtrag: Es war außerdem noch ein falscher EPSG-Code, was die Koordinaten noch verrückter werden ließ.
Falls jemand mit INSPIRE kämpfen muss, hier ein paar Eckdaten der verwendeten Projektionen:

derzeitigem Stand der Entwürfe sind dies:

  • Lambert Azimuthal Equal Area (ETRS-LAEA, EPSG-Code = 3035). Geeignet für statistische Zwecke und andere Anwendungen, bei denen die Flächentreue eine Rolle spielt.
  • Lambert Conformal Conic (ETRS-LCC, EPSG-Code = 3034).
    Diese Projektion ist weitgehend längen- und winkeltreu und für Präsentationen im Maßstab 1:500.000 und kleiner gedacht. Es handelt sich um eine Lambertsche Schnittkegelprojektion mit den beiden Standardparallelen 35°N und 65°N.
  • Transverse Mercator (ETRS-TMzn, EPSG-Codes = 3038 – 3051).
    Entspricht dem UTM-System mit Lagerung in ETRS89. Für Europa sind die UTM-Zonen 26N bis 39N relevant, für Deutschland sind es die Zonen 32N und 33N. Diese CRS sind für die Präsentation im größeren Maßstab (größer 1:500.000) gedacht. Für die Zonen 28N bis 38N werden auch die EPSG-Codes 25828 – 25838 verwendet, so dass z.B. für die Zone 32N sowohl der EPSG-Code 3044 als auch 25832 gilt.