Koordinatentransformation

Moin mo1985,

ja, dafür ist der gedacht! Ich mach das auch damit.

LG,

-moenk

Das ist schonmal gut 🙂 Wäre es möglich eine kurze "Anleitung" zu bekommen? die planet_osm_nodes hat ja stadardmässig die spalten id, lat,lon,tags...Muss ich da noch eine Spalte srid (900913) hinzufügen? Und wie wäre dann der Befehl die ganze Tabelle zu Transformieren?

Danke!

Ich hab mal ein bisschen rumprobiert und habe jetzt folgendes Ergebnis mit dem ich noch nichts anfangen kann 😄
Ausgangsdaten:
679871024;83932145 in lat/lon, daraus habe ich eine geometryspalte erstellt mit dem Befehl

select␣addgeometrycolumn('tabelle','geom',900913,'POINT',2);

update␣tabelle␣set␣geom␣=␣setsrid(makepoint(lon,lat),900913);

"010100002031BF0D00000000C4CF029441000000180143C441"

SELECT␣AsText(Transform(geom,4326))␣FROM␣tabelle;

"POINT(33.9752868243586 90)"

Ich kann da keinen Zusammenhang zwischen den Eingangskoordinaten und den Endkoordinaten finden 😄 hat da jemand eine Idee?
Gruß

Mir kommt es vor, als wären die Werte in osm_nodes um den Faktor 100 zu hoch? Also auf einen cm genau? "Echte" Mercatorkoordinaten in unserer Gegend liegen jedenfals so um 6100000. Probiers doch mal mit lon/100 und lat/100.

.

Ich hab mal einen beliebigen Node genommen. Mit lonlat/100 haut das hin:

osm=>␣select␣*␣from␣osm_nodes␣where␣id=2039745;
id␣␣␣␣|␣␣␣␣lat␣␣␣␣|␣␣␣␣lon␣␣␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣tags
---------+-----------+-----------+-----------------------------------------
2039745␣|␣614296289␣|␣129821738␣|␣{traffic_sign,city_limit,name,Ismaning}

osm=>␣select␣st_astext(st_transform(st_geomfromtext('POINT␣(1298217.38␣6142962.89)',900913),4326));
-----------------------------------------
POINT(11.662085145636␣48.2165855626533)

maxbe wrote:

osm=> select st_astext(st_transform(st_geomfromtext('POINT (1298217.38 6142962.89)',900913),4326));

Kleiner Hinweis am Rande: 900913 ist out. man sollte möglichst 3857 nehmen. Das ist der offizielle Wert und löst die Google-spezifische SRID 900913 ab. PostGIS 2.0 kennt 900913 schon gar nicht mehr. Man kann das zwar nachladen (*) , aber bei neuen Sachen sollte man gleich den neuen Wert nehmen.

Gruss
walter

• ) osm2pgsql hat 900913 noch hardcoded drin 🙁
  

Moin,

und wenn man es nicht mit PostGIS machen will, kann man das auch eben selber umrechnen:

var␣PI␣=␣3.14159265358979323846;
mlon␣=␣lon␣*␣20037508.34␣/␣180;
mlat␣=␣Math.log␣(Math.tan␣((90␣+␣lat)␣*␣PI␣/␣360))␣/␣(PI␣/␣180);
mlat␣=␣mlat␣*␣20037508.34␣/␣180;

Für den hier gefragten Rückweg finde ich die umgestellte Formel grad nicht wieder.

LG,

-moenk

Hallo zusammen, Danke, ihr habt mir schonmal viel weitergeholfen und unterschiedliche Lösungswege aufgezeigt, auch wenn ich nicht alle verstanden habe 😉
Ich hab es jetzt so gelöst:

select␣addgeometrycolumn('tabelle','geom',900913,'POINT',2);
update␣tabelle␣set␣geom␣=␣setsrid(makepoint(lon/100,lat/100),900913);
SELECT␣AsText(Transform(geom,4326))␣FROM␣tabelle;

Als Ergebnis bekomme ich dann folgende Geometrie geliefert
"POINT(6.1507737335192 50.7993300473197)"
Koordinaten sind verdreht, liegen aber an "Ort und Stelle"

habe dennoch einige Fragen: Wie bekomme ich die Geometrie wieder getrennt in "lat,lon"?
Und was hat es mit den unterschiedlichen SRIDs auf sich, unterschiedliche Bezugssysteme?
Zu guter letzt, gibt es eine Funktion die Punkte auf einer way ermittelt? Ich finde da keine Passende. Habe es mit Intersection probiert, das läuft zwar liefert mir aber kein Ergebnis (Abbruch nach 12 Stunden) 😉 Hat da jemand noch eine Idee?

Vielen Gruß und Danke 🙂

mo1985 wrote:

Koordinaten sind verdreht, liegen aber an "Ort und Stelle"

habe dennoch einige Fragen: Wie bekomme ich die Geometrie wieder getrennt in "lat,lon"?
Und was hat es mit den unterschiedlichen SRIDs auf sich, unterschiedliche Bezugssysteme?
Zu guter letzt, gibt es eine Funktion die Punkte auf einer way ermittelt? Ich finde da keine Passende. Habe es mit Intersection probiert, das läuft zwar liefert mir aber kein Ergebnis (Abbruch nach 12 Stunden) 😉 Hat da jemand noch eine Idee?

Vielen Gruß und Danke 🙂

wie wäre es denn hiermit? Version 1.5 dürfte wohl noch am verbreitesten sein.
Ansonsten für die "Mutigen"

Gruss
walter

Bitte ALLE Postgis-Funktionen mit ST_ anfangen, auch wenn es nicht so zwingend erscheint. Die Brüder von PostGIS werden immer pingeliger und ohne ST_ läuft demnächst einiges nicht mehr.
osm2pgsql muss z.B. noch an PostGIS 2.0 angepasst werden - osmosis ist schon sauber.

900913 sprech ich hier nicht nochmal an - du hast es auf jeden Fall ignoriert.

edit: Link korrigiert.

Danke, den ersten Link kenne ich, nur hab ich dort keine passende Funktion gefunden. Daher oben meine Frage. Der zweiten Link läuft ins Leere 😉
Gruß

mo1985 wrote:

Wie bekomme ich die Geometrie wieder getrennt in "lat,lon"?

Wenn Du nur die einzelnen Teile der Koodinaten meinst:

select␣st_x(way),st_y(way)␣␣from␣osm_point␣limit␣2;
st_x␣␣␣␣␣␣␣|␣␣␣␣␣␣␣st_y
------------------+------------------
1291364.34651175␣|␣6041355.15895812
1335171.20440473␣|␣5950120.22770464

Falls Du wieder von Mercator nach Längen und Breitengrad umwandeln müöchtest, hilft Dir "st_transform".

Grüße, Max

mo1985 wrote:

Danke, den ersten Link kenne ich, nur hab ich dort keine passende Funktion gefunden. Daher oben meine Frage. Der zweiten Link läuft ins Leere 😉
Gruß

uiiii1: sorry, link war wirklich daneben.
uiiii2: wenn dir die Übersicht nichts bringt (was ich wirklich nicht nachvollziehen kann), bringt dir link2 auch nix.

aber bitte: http://postgis.refractions.net/docs/ST_X.html aus dem Unterkapitel 7.4 Geometry Accessors der Referenz.

Gruss
walter

Danke 🙂 da hatte ich mich wohl missverständlich ausgedrückt. Die Funktion zum "trennen" der Punkte habe ich gefunden, u.a. dank deines Vorredners 😉
Was ich noch suche und verschiedene probiert, bisher aber noch nichts passendes gefunden habe, ist eine Funktion die einen Punkt auf einer Linie ermittel. Logisch wäre ST_PointOnLine, gibt es aber nicht 😄
z.B. ST_Contains habe ich probiert aber das klappt nicht. Zugegeben bin ich da auch nicht so bewandert als das ich nicht ausschließen möchte evtl. den Befehl falsch angewendet zu haben 😉

VG

mo1985 wrote:

Was ich noch suche und verschiedene probiert, bisher aber noch nichts passendes gefunden habe, ist eine Funktion die einen Punkt auf einer Linie ermittel. Logisch wäre ST_PointOnLine, gibt es aber nicht 😄
z.B. ST_Contains habe ich probiert aber das klappt nicht. Zugegeben bin ich da auch nicht so bewandert als das ich nicht ausschließen möchte evtl. den Befehl falsch angewendet zu haben 😉

Jo, war wohl ein Mistverständnis.

suchst du einen Punkt der Line, der bereits existiert? Oder einen Punkt auf der Linie, der erst berechnet werden soll (z.b. das Lot auf eine Linie oder einen Schnittpunkt zweier Linien)?
a ist relativ einfach und b ist prinzipiell möglich.

ich hoffe mal a, sonst komm ich in Erklärungsnöte.

Gruss
walter

p.s. ich spreche auch nicht fliessend "PostGissisch", hab mich aber mit der Referenz ganz gut durchgewurstelt. Pele hat sich riesig drüber gefreut.

dann nehme ich erstmal Variante a und hoffe das sie ausreicht. Normalerweise sollten alle Punkte auf der Linie liegen. Ansonsten könnte ich aber auch noch einen Buffer bilden und die Punkte innerhalb des Buffers suche. Sie müssen also nicht zwingend auf der Linie liegen, vermute aber das es alle tun 😉
Gruß

mo1985 wrote:

dann nehme ich erstmal Variante a und hoffe das sie ausreicht. Normalerweise sollten alle Punkte auf der Linie liegen. Ansonsten könnte ich aber auch noch einen Buffer bilden und die Punkte innerhalb des Buffers suche. Sie müssen also nicht zwingend auf der Linie liegen, vermute aber das es alle tun 😉
Gruß

also ST_NPoints(way) liefert dir die Anzahl und ST_PointN(way,n) den Punkt. der Rest ist normales sql.

Gruss
walter

wambacher wrote:

Kleiner Hinweis am Rande: 900913 ist out. man sollte möglichst 3857 nehmen. Das ist der offizielle Wert und löst die Google-spezifische SRID 900913 ab. PostGIS 2.0 kennt 900913 schon gar nicht mehr.

Die Definitionen in der epsg unterschieden sich. Bei 3857 steht noch zusätzlich "+nadgrids=@null +wktext' drin. Ich habe rausgefunden, dass dieses "nadgrids" Shifts/Verschiebungen sein sollen. Da steht was mit null, soweit scheint es ja zu 900913 passen, wo nichts davon steht. Aber was ist dieses "wktext"?

1. WGS 84 / Pseudo-Mercator
   

<3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs <>
.....

1. Google
   

<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs <>

SunCobalt wrote:

Die Definitionen in der epsg unterschieden sich. Bei 3857 steht noch zusätzlich "+nadgrids=@null +wktext' drin. Ich habe rausgefunden, dass dieses "nadgrids" Shifts/Verschiebungen sein sollen. Da steht was mit null, soweit scheint es ja zu 900913 passen, wo nichts davon steht. Aber was ist dieses "wktext"?

1. WGS 84 / Pseudo-Mercator
   

<3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs <>
.....

1. Google
   

<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs <>

Moin Moin, Thomas

das ist zwar absolut nicht meine Baustelle - ganz im Gegenteil eher ein Horror für mich - aber eventuell hilft das hier weiter.
Für mich als "Koordinaten-Transformations-Blinder" war einzig entscheidend, dass PostGIS 900913 rausgeschmissen hat.

Gruss
Walter

SunCobalt wrote:

Aber was ist dieses "wktext"?

Es könnte Programme in der weiteren Verarbeitungskette geben, die an der Projektion ruminterpretieren. Ich kenne das nur von den GDAL-Tools, die "over" fressen, aber anscheinend passiert das auch mit "nadgrids" (steht da im letzten Absatz). Mit diesem "wktext" gibt proj.4 denen weiter, dass sie bitte nicht an der Projektion rumbasteln sollen, sondern eben diesen "well known text" nehmen und ggf. weitergeben sollen.

Grüße, Max