Hallo, ist es möglich mit dem transformations Befehl in PostGIS die planet_osm_nodes zu transformieren? Oder ist der Befehl nur für Geometrien händelbar.
Gruß
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)
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
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ß
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
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
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ß
also ST_NPoints(way) liefert dir die Anzahl und ST_PointN(way,n) den Punkt. der Rest ist normales sql.
Gruss
walter
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”?
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 <>
…
<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
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