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.
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.
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.
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.
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.
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.
Ich werde den Teil im Wiki mal aktualisieren.
PS: Weiß jemand, wie man schnell an ein LaTeX-Plugin im Wiki kommen kann?
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.
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:
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.
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.