Problem mit Koordinatentransformationen

Upps, Edit-Konflikt. War gerade dabei, das in LaTeX zu machen (und hab’s jetzt auch gemacht). Die alte Schreibweise war schon halbwegs richtig, aber eher wie man es in Matlab/Mathematica nutzt. Habe übrigens \times durch \cdot ersetzt, weil man für Matrixmultiplikation entweder gar kein Operatorzeichen oder einen Punkt verwendet.

Zu deinem Problem: Eigentlich ganz simpel. Für jeden Pixel deines Bildes (oder für die Eckpunkte oder was auch immer) musst du den Vektor berechnen (Achtung, hier wird mit homogenen Koordinaten gerechnet, deswegen die zusätzliche Komponente). Du fängst von rechts an und multiplizierst Stück für Stück, das ist alles.

Jo, so sieht es schon besser aus - bringt mich aber auch nicht viel weiter.

“Ganz simple” ist gut gesagt, wenn man Matrix-Rechnung gehabt hat. Aber ich werde schon irgendwo eine Anleitung oder ne Formelsammlung finden.

@mhohmann: das Ergebnis lag einige 100 Km daneben, aber zumindest auf dem richtigen Kontinent :wink:

Gruss
walter

EDIT: Hab was in Java gefunden, auf dem ich aufbauen kann :slight_smile:

Python und NumPy.

http://docs.scipy.org/doc/numpy/reference/generated/numpy.dot.html

Seltsam, dabei sollte meine Berechnung genau der Formel im Wiki entsprechen. Hast du einen Ansatzpunkt, welche Koordinaten ungefähr rauskommen sollten? Vielleicht stimmt etwas mit der Projektion nicht, oder mit der Formel im Wiki, oder in meiner Berechnung.

ja, aber wirklich ganz grob:

nordwest: 3215600/9481550
südost: 3168370/9514770

sollte wohl hinhauen.

Gruss
walter

Jo, schau auch gut aus, gerade weil man da mit matritzen rechnen kann.
Hab ich gerade installiert und arbeite mich ein.

Gruss
walter

Irgendwie komme ich mit den Zahlen auf keinen grünen Zweig… Zum einen hatte ich offenbar PX und PY vertauscht, aber auch wenn ich die passend habe, bringt das nicht viel. Der Punkt ist, dass ich mit den angegebenen Skalenfaktoren grob auf 3,8 * 148 = 562 Einheiten (in der gewählten Projektion) pro Pixel komme, mit deinen Koordinaten der Eckpunkte aber nur auf ganz grob 20 Einheiten pro Pixel. Da kommt irgendwas nicht richtig hin.

meine ich auch, dass da was faul sein muß. Hab hoch ein paar neue Kalibrierungen vesucht und komme immer falsch hin.
Hier nochmals ein CAL-File aber zum selben Image. Hab es halt nochmals kalibriert und jetzt die dynamische Methode mit den 3 Referenzpunkten verwendet.


#JOSM PicLayer plugin calibration data
#Wed Feb 18 23:40:41 CET 2015
POSITION_Y=3144843.921914018
POSITION_X=9519879.519414948
M12=-50.87634699525655
M11=0.022148575397414223
M10=6.719567798201829E-5
M02=-23.772573686878683
INITIAL_SCALE=81985.45583742265
M01=-0.0010414742927757161
M00=0.022211044268432425

W = 1668
H = 2338

PX = POSITION_X
PY = POSITION_Y
S  = INITIAL_SCALE/100
print PX,PY,S

X1 = [-W/2,-H/2, 1]
X1 = [0,0,1]
print X1

X2 = [[S, 0, 0],
      [0, S, 0],
      [0, 0, 1]]
print X2

np.dot(X2,X1)

X3 = [[M00, M01, M02],
      [M10, M11,-M12],
      [  0,   0,   1]
     ]

print X3

X4 = [[ 1, 0, PX], 
      [ 0, 1, PY],
      [ 0, 0,  1]
     ]
print X4

np.dot(np.dot(np.dot(X4,X3),X2),X1)


damit krieg in in Python das raus: array([ 9.51985575e+06, 3.14489480e+06, 1.00000000e+00])
und das ist fast POSITION_Y/POSITION_X: 9519879. 3144843.9
alles sehr merkwürdig.

Ich mach mal damit Schluss für heute. Dreh mich eh im Kreis.

Gruss
walter

Nahmd,

ich würde vor Installation von Libraries zuerst die Formeln prüfen.

Gruß Wolf

hab zwar keine Lib installiert sondern nur ein interaktives math programm, aber dass da irgendwo 'ne Formel oder die Matrix faul sein muss, war mir inzwischen schon klar - nur wo?

Danke für dein Beispiel. Ich werde es am DO mal in aller Ruhe analysieren und meine Auswertung daran anpassen.

Gruss
walter

EDT: wow, hab es mal überflogen und bin beeindruckt.

Wenn die Formeln im Wiki so falsch sind, ist es kein Wunder, wenn da Murks rauskommt :sunglasses:

Grundsätzlich müsste die Formel aber stimmen. In welcher Reihenfolge man Rotation oder Skalierung durchführt, spielt keine Rolle. Wichtig ist, dass man die Translation zuletzt ausführt, weil man ansonsten nicht um das Zentrum des Bildes drehen würde.

Vertauscht? Wie wählen die bitte ihren Index?! Vorzeichen… das mache ich meistens durch ausprobieren (je nachdem, wie rum man projiziert).

Das wiederum macht Sinn.

Gut zu wissen. Hätte ja auch auf irgendeine Art rechtwinklig sein können. :wink:

Ich werde den Teil im Wiki mal aktualisieren.

PS: Weiß jemand, wie man schnell an ein LaTeX-Plugin im Wiki kommen kann?

PPS: So besser?

Aber sicher! Soooo verstehe ich das natürlich sofort :wink:

Ich mach mich nachher dran, die Sache umzusetzten und dann sehen wir weiter.

Gruss
walter

Wer ist denn für das Wiki zuständig? Wäre wirklich super, wenn dort das (ein) LaTeX-Plugin hinzugefügt werden könnte. Mit den Bildern ist das nervig.

Matrixmultiplikation ist einfach:

Edit: Unfug getilgt.

Ich bin von dir immer wieder überrascht. Gibs zu, du hast schon längst eine Zeitmaschine gebaut, damit du das alles schaffst und immer noch Zeit für solche Spielereien hast. :smiley:

Leider immer noch daneben - wenn ich nicht völlig schief liege:

zuerst mal die Lage in Josm - ja, es ist Nepal:


Das Image habe ich mit dem PicLayer-Pluging referenziert. Leider hat es keinen transparenten Hintergrund, aber ich hab Josm so eingestellt, dass man hoffentlich die nach diesen Image erfasste Außengrenze von Lalitpur einigermaßen erkennen kann.

Danach hab ich das Programm von Netzwolf um eine weitere Ausgabe erweitert und bekomme jetzt das:


Bildmitte   :   x:  9513536   y:  3179064     lon:  85.461555  lat: 27.444086
Oben  links :   x:  9496946   y:  3202516     lon:  85.312518  lat: 27.630889
Oben  rechts:   x:  9530127   y:  3202516     lon:  85.610592  lat: 27.630889
Unten links :   x:  9496946   y:  3155613     lon:  85.312518  lat: 27.256967
Unten rechts:   x:  9530127   y:  3155613     lon:  85.610592  lat: 27.256967

insert into refnodes values(ST_SetSRID(ST_MakePoint( 9513536,  3179064),3857),'Bildmitte   ');
insert into refnodes values(ST_SetSRID(ST_MakePoint( 9496946,  3202516),3857),'Oben  links ');
insert into refnodes values(ST_SetSRID(ST_MakePoint( 9530127,  3202516),3857),'Oben  rechts');
insert into refnodes values(ST_SetSRID(ST_MakePoint( 9496946,  3155613),3857),'Unten links ');
insert into refnodes values(ST_SetSRID(ST_MakePoint( 9530127,  3155613),3857),'Unten rechts');

Den zweiten Block konnte ich mit Cut&Paste in Postgresql/PostGIS eingeben. Zudem hab ich mit den Werten 9496946,3202516 (Oben links) “meine” Daten in Postgis umgerechnet und danach beides (also die Rohdaten vom Script als auch mein in PostGIS umgerechtete Image) mittels QGIS dargestellt:

Und ja: Qgis ist auf 3857 eingestellt.

Wie man leicht erkennt liegt das Bild noch ein wenig falsch, deckt sich aber total mit den vom Script errechneten Basiswerten. Daher können die Basiswerte auch nicht ok sein. Es müsste alles noch (um die halbe Bildgröße?) nach Nordwest verschoben werden.

Grübelnde Grüsse
walter

ps: so nah waren wir bisher nicht dran :slight_smile:

Ich weiß nicht, ob das noch was mit dem aktuellen Workflow zu tun hat, aber da wird der Wert der ersten Zeile (Pixelkoordinaten Bildmitte) in der nächsten Zeile durch die Koordinaten der Ecke (0,0) überschrieben.

Nö, das ist mausetot. Ich nehme nur noch den Script von Netzwolf.

Nur nochmals zur Sicherheit:

./josmPiclayerCalDecoder.pl 1654 2338 nepal_01_Admin.jpg-move.cal

mit


#JOSM PicLayer plugin calibration data
#Wed Feb 18 02:01:41 CET 2015
POSITION_Y=3132393.459019553
POSITION_X=9534742.422238246
M12=-50.68955846622368
M11=0.021788490422173075
M10=0.0
M02=-23.031323884902726
INITIAL_SCALE=81985.45583742265
M01=0.0
M00=0.021788490422173075

ergibt obiges Ergebnis.