Koordinatentransformation

mo1985 · 2012-07-22 12:20:14

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ß

moenk · 2012-07-22 12:51:47

Moin mo1985,

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

LG,

-moenk

mo1985 · 2012-07-22 12:59:31

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!

mo1985 · 2012-07-22 19:04:24

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ß

maxbe · 2012-07-22 20:42:41

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.

mmd · 2012-07-22 20:57:25

.

Last edited by mmd (2012-10-19 17:53:07)

maxbe · 2012-07-22 23:08:49

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)

wambacher · 2012-07-22 23:53:40

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

moenk · 2012-07-23 09:30:10

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

mo1985 · 2012-07-23 10:01:57

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

wambacher · 2012-07-23 11:03:44

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.

Last edited by wambacher (2012-07-23 11:44:28)

mo1985 · 2012-07-23 11:16:07

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ß

maxbe · 2012-07-23 11:21:27

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

wambacher · 2012-07-23 11:52:39

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

Last edited by wambacher (2012-07-23 12:57:53)

mo1985 · 2012-07-23 12:00:50

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

wambacher · 2012-07-23 12:30:38

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.

Last edited by wambacher (2012-07-23 12:49:46)

mo1985 · 2012-07-23 12:47:43

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ß

wambacher · 2012-07-23 12:56:44

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

SunCobalt · 2012-07-25 06:16:33

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"?

# 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 <>
.....
# 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 <>

wambacher · 2012-07-25 07:34:58

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"?
# 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 <>
.....
# 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

maxbe · 2012-07-25 08:16:04

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

Last edited by maxbe (2012-07-25 08:16:29)

Announcement

#1 2012-07-22 12:20:14

Koordinatentransformation

#2 2012-07-22 12:51:47

Re: Koordinatentransformation

#3 2012-07-22 12:59:31

Re: Koordinatentransformation

#4 2012-07-22 19:04:24

Re: Koordinatentransformation

#5 2012-07-22 20:42:41

Re: Koordinatentransformation

#6 2012-07-22 20:57:25

Re: Koordinatentransformation

#7 2012-07-22 23:08:49

Re: Koordinatentransformation

#8 2012-07-22 23:53:40

Re: Koordinatentransformation

#9 2012-07-23 09:30:10

Re: Koordinatentransformation

#10 2012-07-23 10:01:57

Re: Koordinatentransformation

#11 2012-07-23 11:03:44

Re: Koordinatentransformation

#12 2012-07-23 11:16:07

Re: Koordinatentransformation

#13 2012-07-23 11:21:27

Re: Koordinatentransformation

#14 2012-07-23 11:52:39

Re: Koordinatentransformation

#15 2012-07-23 12:00:50

Re: Koordinatentransformation

#16 2012-07-23 12:30:38

Re: Koordinatentransformation

#17 2012-07-23 12:47:43

Re: Koordinatentransformation

#18 2012-07-23 12:56:44

Re: Koordinatentransformation

#19 2012-07-25 06:16:33

Re: Koordinatentransformation

#20 2012-07-25 07:34:58

Re: Koordinatentransformation

#21 2012-07-25 08:16:04

Re: Koordinatentransformation

Board footer