Luftbilder von Aerowest

Communities Deutschland (Germany)
107

Hi Mondschein,

Ja, weiss ich inzwischen :wink:

Ich hab’ mir mal nach /usr/local/bin die gdal-1.8.1 installiert:
Das (debian-)gdalinfo ist (irgendwie) buggy, denn ein gdalinfo (der 1.8.1) liefert tatsÀchlich


$ gdalinfo ergebnis1.tif 
Driver: GTiff/GeoTIFF
Files: ergebnis1.tif
Size is 2985, 2144
Coordinate System is:
PROJCS["WGS 84 / Pseudo-Mercator",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
<etc etc>

eines mit einem gdalwarp (von gdal-1.6) erstelten Tiffs,

Auch ich hab’ noch einen Versatz, einmal ca. 4 m und einmal 1 m (zu den original jpegs per ImportImagePlugin),
je nach “shp-” oder "mmd-"Methode :wink:

Ciao,
Frank

PS
Iiih, “libapache2-mod-fastcgi” ist ja aus non-free, lĂ€sst sich das durch “libapache2-mod-wsgi” (oder so) ersetzen?

108

Fast identisch mit meinen Ergebnissen.

Die vollstĂ€ndige “Bilddienst-URL”, welche JOSM (ĂŒber Klick auf “Ebenen abfragen” 
) durch die GetCapabilities-Abfrage von meinem WMS-Server erhĂ€lt ist:

http://127.0.0.1/cgi-bin/mapserv?map=/mapserver/data/osm.map&FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=AerowestOSM&

Gruß,
Mondschein

109

Huh, ich sehe gleich mal nach.

Edit:
Funktioniert auch mit “libapache2-mod-fcgid” aus main, anstatt “libapache2-mod-fastcgi” aus non-free.

110

So,

bin fast geneigt, dass die ca. 4 m -Unterschied zwischen
Methode "TILEINDEX “/mapserver/data/tile.shp”
und
Methode "DATA “/mapserver/data/tile.tif”
daher kommen, dass mapserver proj.4 fĂŒr die Projektion verwendet (statt gdal_translate), denn wenn ich
“init=epsg:3857”
statt
“init=epsg:31468”
im mapfile verwende, ergibt sich kein (sichtbarer) Unterschied mehr.

Hab’ aber immer noch ca. 1,5 m zur “ImportImagePlugin-Projektion”.

Egal, schluss fĂŒr heut :wink:

Ciao,
Frank

PS
Der Dienst von Aerowest steht wieder zur VerfĂŒgung :slight_smile:

111

Bei mir ist das WMS-Bild gegenĂŒber dem ImportImagePlugin-Bild um ca. 3 m nach Osten und 4,6 m nach SĂŒden verschoben.
Ich hatte zuerst gehofft, dass der Fehler beim ImportImagePlugin liegt und nicht beim WMS-Server, aber ich habe das mit Bing und anderen Quellen verglichen und diese stimmen mit dem ImportImagePlugin genau ĂŒberein.

Selbst wenn ich meinem WMS-Server nur die original JPEG-Bilder von Aerowest gebe und einen mit gdaltindex erstellten Index gebe, sind die Bilder verschoben.

Übrigens ist es JOSM etwas weniger trĂ€ge, wenn man dem ImportImagePlugin ein JPEG komprimiertes TIF (kleinere DateigrĂ¶ĂŸe) anstatt eines unkomprimierten TIF ĂŒbergibt (nur fĂŒr Merkator, sonst muss man den Umweg ĂŒber das TIF nicht machen).

Gruß,
Mondschein

112

liegt vielleicht an der Definition von 3857. Zumindest gibts im Web Àhnliche Meldungen. Man kann ja mal versuchen ob es mit 900913 besser lÀuft.

in
/usr/share/proj/epsg
sollte das stehen
#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 <>

113

Da wir mit der Ausflösung der Bilder in den Submeterbereich vorstoßen, sind 4 Meter Abweichung (auch bei mir) mit der “normalen” Transformation nicht hinnehmbar. Man sollte noch die amtliche Korrekturdatei BeTA2007 verwenden:

http://www.adv-online.de/icc/extdeu/broker.jsp?uMen=9ae594bb-a094-311a-3b21-718a438ad1b2
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php
http://www.fossgis.de/konferenz/2010/attachments/71_osm-datenaufbereitung-fossgis-2010.pdf

114

Nunja, so langsam grenzt das ja an Haarspalterei. FĂŒr eine korrekte Koordinatentransformation ist auch die Höhe ĂŒber dem jeweiligen Bezugsellipsoid von Bedeutung. Die liegt uns aber bei 2D-Orthophotos sowieso nicht vor.

Gruß,
ajoessen

115

Hilft leider auch nicht, die Verschiebung bleibt exakt gleich.

Auch mit der Datei BETA2007.gsb bleibt die Verschiebung exakt gleich, egal ob ich nach 4326, 3857 oder 900913 transformiere und egal ob ich fĂŒr Quelle und/oder Ziel die Datei BETA2007.gsb verwende oder nicht.
Ich habe alle Kombinationen getestet.

:frowning:

Gruß,
Mondschein

116

das hier hab ich gefunden “EPSG:3857 didn’t exist when 1.6.1 was released, afaik, so it definitely wouldn’t be supported.”
Wenn Du mit Mapserver arbeitest, brauchst Du die Bilder eigentlich gar nicht in 3857 umzuwandeln. JOSM holt sich die in 4326.

117

Ja, leider ist es bei mir aber völlig egal, ob ich die Bilder direkt von Aerowest herunterlade und die JPEG-Dateien zusammen mit den JGW-Dateien unverĂ€ndert dem WMS-Server gebe und den auf der Aerowest-Seite fĂŒr diese konkreten Bilder angegebenen EPSG-Wert “31467” im Mapfile angebe oder ob ich die JPEG- und JGW-Dateien vorher in ein anderes Format bzw. andere Projektion umwandle.
Die Verschiebung bleibt immer exakt gleich.

Gibt es denn hier jemanden, der keine Probleme mit der Verschiebung der Aerowest-Bilder bei Verwendung eines WMS-Servers in JOSM hat?

Gruß,
Mondschein

118

Hi,

Nur dass zwischen 3857 und 4326 nicht so wirklich groß der Unterschied ist :wink:

Vermute, dass “+datum=potsdam” mit reingspielen könnte. Jenes ist unter “proj” immer noch mit dem alten 1950er 3-parametrigen
Wert fest einkompiliert, evtl. benutzt gdal 1.8/ImportImagePlugin hierfĂŒr schon die 7-parametrische Helmert-Trafo (?)

Heute abend mal gucken.

Ciao,
Frank

PS


JOSMs WMS-Plugin behandelt 3857 momentan, als ob es 4326 wÀre. Aufgrund 
der normalerweise angeforderten kleinen KachelgrĂ¶ĂŸen und hohen Zoomstufen 
können wir mit den entstehenden Verzerrungen leben. Sinnvoller wÀre 
natĂŒrlich ein Capabilities-Request im WMS-Plugin und dann entsprechende 
angepasste Anfragen. Aber es gibt so viel, was zu tun ist...

Das ist Dirk Stöcker 2009, weiss aber nicht, ob es immer noch so ist 


119

Wo finde ich den den Quellcode?

Edit:
Gefunden:
http://svn.openstreetmap.org/applications/editors/josm/plugins/ImportImagePlugin/

120

Wenn das mit unserem Versatz zusammenhĂ€ngt, dann mĂŒsste das doch auch Bing-WMS betreffen? Edit: Falsch, Bing ist nicht WMS.
Doch wenn ich die Bing-WMS-Bilder mit den ImportImagePlugin-Bildern vergleiche, so kann ich hier keinen Versatz feststellen.

Gruß,
Mondschein

121

Um auszuschließen, dass das Problem bei JOSM liegt, habe ich meinen WMS-Layer in Quantum GIS geladen und die Position mit Hilfen von OSM-Testdaten verglichen.
Das Ergebnis:
Quantum GIS zeigt die Bilder exakt an der gleichen Stelle an, wie JOSM, also mit dem gleichen Versatz.

Vermutlich liegt das Problem also bei GDAL, weshalb ich mir das nochmals genauer angesehen habe:

Zuerst habe ich das JPEG-Bild von Aerowest in ein GeoTiff umgewandelt, ohne dabei die Projektion zu verÀndern:

gdal_translate -a_srs epsg:31467 -of GTiff exportimg_direkt_von_aerowest.jpg epsg_31467.tif

Das schreibt die Koordinaten aus der zugehörigen jgw-Datei in den Header des GeoTiff.
Diese Koordinaten habe ich dann mit

gdalinfo epsg_31467.tif

ausgelesen.

“Pixel Size” ist hier mit der PixelgrĂ¶ĂŸe aus der jgw-Datei (1. und 4. Zeile) identisch.
“Origin” weicht hingegen leicht vom Ursprung aus der jgw-Datei (5. und 6. Zeile) ab und zwar um etwa die HĂ€lfte der GrĂ¶ĂŸe eines Pixels.
Vermutlich nimmt GDAL hier an, dass die Koordinaten aus der jgw-Datei am linken oberen Rand eines Pixels beginnen, und rechnet das auf die Mitte des Pixels um.
Ich weiß nicht, ob das so spezifiziert ist, aber selbst wenn das ein Fehler sein sollte, so wĂ€re dieser zu klein, um die Abweichungen im Meter-Bereich zu erklĂ€ren.

Daraufhin habe ich das soeben erstellte GeoTiff in EPSG 4326 umgewandelt:

gdalwarp -s_srs epsg:31467 -t_srs epsg:4326 -of GTiff epsg_31467.tif epsg_4326.tif

Dann habe ich das epsg_4326.tif mit dem “ImportImagePlugin” in JOSM geladen und festgestellt, dass es den bekannten Versatz aufweist.
Also hab ich mit dem Mauszeiger die Koordinaten der linken oberen Ecke des Bildes (die Koordinaten des Mauszeigers werden bei JOSM links unten angezeigt) ausgelesen und festgestellt, dass diese mit der Ausgabe von

gdalinfo epsg_4326.tif

(siehe “Origin”) ĂŒbereinstimmen.

Also berechnet GDAL hier definitiv beim der Umprojektion falsche Koordinaten!

Weiß jemand, ob das bei der neuesten GDAL-Version (1.8) auch so ist bzw. das Problem bekannt ist?

Ist dieses Problem bei den Betreibern von WMS-Servern (welche GDAL verwenden) noch nicht aufgetreten oder hat das nur keiner bemerkt?

Gruß,
Mondschein

122

Hallo Mondschein,

kannst Du bitte mal bei Dir testen?

Im mapfile:
“init=epsg:31466”

und dann im /usr/share/proj/epsg
statt


  <31466> +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs  <>

nun


  <31466> +proj=tmerc +lat_0=0 +lon_0=6 +k=1 +x_0=2500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70 +units=m +no_defs  <>

Danke schön.

Ciao,
Frank

123

Hm, dazu brauche ich dann aber ein EPSG 31466 Bild, oder?
Das habe ich aber z.Zt. nicht.
Welche Orte bei Aerowest haben denn diesen EPSG-Wert, damit ich mir das ggfs. besorgen kann.

Gruß,
Mondschein

124

Ach so, dachte, Du wÀrst ein Aachener :wink:

Dann nimm halt


<31467> +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs  <>

das


<31467> +proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70 +units=m +no_defs  <>

Ciao,
Frank

PS
gdal-1.8.1 zu kompilieren auf Debian 6 ist pretty easy:
$ cd gdal-1.8.1/
$ ./configure
$ make

make install

echo “/usr/local/lib” >> /etc/ld.so.conf

ldconfig

Hat aber auf meinen kleinen netbook ca. 1 h gebraucht :wink:

125

Das hat keinerlei VerÀnderung bewirkt, Versatz identisch.
Deshalb habe ich ein Bild mit verÀndertem 31467 Eintrag und eines mit unverÀndertem 31467 Eintrag erzeugt (beide aus gleicher JPEG-Datei) und dann die beiden Ausgaben von gdalinfo mit diff verglichen und das zeigt, bis auf den Dateinamen, keine Unterschiede an.
Ich habe den Verdacht, GDAL verwendet die Info gar nicht.

Und hat es geholfen?

127

Hi,

ne ne ne, “proj” wird vom mapserver verwendet wenn er die “init=epsg:31467”-Dateien
umprojeziert muss um dem client (JOSM) epsg:4326-Bilder zu liefern. Das hat bei mir einen Versatz von ca. 3-4 m.
Mit der verbesserten “postdam”-Defintion mache ich das wieder weg.
FĂŒr SĂŒddeutschland gĂ€be es sogar noch ein
potsdam “towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58” “Germany (West - South - 47d00N to
50d20’N)” “Accuracy <1m”

Debian 6 eigenes gdal (1.6) ist bei mir total daneben: “gdalinfo” geht bei 3857-proj. gar nicht und der Versatz
im JOSM ca. 150 m !
Vielleicht hab’ ich sie auch beim “Rumspielen mit libgeotiff” zerschossen :wink:

Ciao,
Frank