Luftbilder von Aerowest

Mondschein · August 1, 2011, 7:30pm

Wobei ich Bing nicht unbedingt als Referenz verwenden würde.

Bin auf den Vergleich gespannt.

Mondschein · August 1, 2011, 7:36pm

Aber mapserver verwendet doch dafür wiederum die gdal-Lib, oder nicht?

Ich werde das gleich nochmal Testen.
Gibst du deinem Mapserver direkt die original Aerowest-Bilder (jpg und jgw) oder gibst du ihm ein EPSG 3146x GeoTiff?

SunCobalt · August 1, 2011, 7:40pm

Mapserver nimmt die epsg File. Bei gdal steht “A list of EPSG coordinate systems can be found in the GDAL data files gcs.csv and pcs.csv.”

kellerma · August 1, 2011, 7:49pm

Einigen wir uns auf ein Unentschieden?

ldd /usr/lib/cgi-bin/mapserv

…
libproj.so.0 => /usr/lib/libproj.so.0 (0x00007fecc36d7000)
libgdal1.6.0.so.1 => /usr/lib/libgdal1.6.0.so.1 (0x00007fecc2d64000)
…

gdal_translate -a_srs epsg:31468 -of GTiff exportimg2011729249507856.jpg nbg4.tif

also als GeoTiff

Ciao,
Frank

Mondschein · August 1, 2011, 9:03pm

Gut, mit den verbesserten Koordinateninformationen ist der Versatz jetzt max. 1 m.

Ok.

Achso, auch gut.
Weißt du zufällig auch, wie ich GDAL die verbesserten Koordinateninformation übergeben kann, das mit dem epsg-Datei funktioniert in diesem Fall, wie soeben schmerzhaft festgestellt, nicht.
Denn eine on-the-fly-Umwandlung durch den Mapserver von EPSG 3146x nach EPSG 4326 ist mir zu langsam, ich hätte die Bilder gerne direkt als EPSG 4326 vorliegen, genau das möchte JOSM nämlich haben.

Ich fasse kurz zusammen:

JOSM fragt den WMS-Server nach EPSG 4326 (WGS84 Geografisch) Tiles

Wir möchten in JOSM gerne mit EPSG 3857 (Merkator) arbeiten, wegen Winkeln, Kreisen u.s.w.

Wir möchten einen möglichst geringen Versatz

Folglich

stellen wir dem Mapserver die Daten in der Originalprojektion von Aerowest (EPSG 3146x, …) z.B. als GTiff oder HFA zur Verfügung und lassen ihn EPSG 4326 Tiles ausliefern.

verbessern wir die Projektionsdaten in der epsg-Datei (z.B. /usr/share/proj/epsg), z.B.

# DHDN / 3-degree Gauss-Kruger zone 3
<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  <>

Das Mapfile sieht z.B. so aus:

MAP
    NAME    OSM-WMS
    STATUS    ON
    UNITS    METERS

        PROJECTION
            "init=epsg:31467"
        END

    WEB
        METADATA
            "wms_title"    "WMS-Server"
            "wms_onlineresource"    "http://127.0.0.1/cgi-bin/mapserv?"
            "wms_srs"    "EPSG:4326"
        END
    END
 
    LAYER
        STATUS    ON
        NAME    "AerowestOSM"

        DATA    "/mapserver/data/epsg-31467.tif"

        METADATA
            "wms_title"    "Luftbilder"
            "wms_srs"    "EPSG:4326"
        END

        TILEITEM "location"
        TYPE RASTER
    END
END

An der Geschwindigkeit muss noch gearbeitet werden, Vorverarbeitung, Index u.s.w.

Gruß,
Mondschein

kellerma · August 1, 2011, 9:49pm

Hab mich schon gewundert, dass dies bei Dir nicht funktioniert, aber Du benutzt ja gdal 1.6
Nimm die 1.8er Version und mit
gdalwarp -s_srs epsg:31468 -t_srs epsg:4326 -of GTiff 31468.tif 4326.tif
wird Dir so geliefert, als würde der mapserver mit Potsdam-korrektur die 31468.tif direkt ausliefern.

Ciao,
Frank

kellerma · August 1, 2011, 9:59pm

Hi,

Da Du GK2 benutzt, kommst Du evtl. aus der Aachener Gegend, Du könntest noch
potsdam “towgs84=584.8,67.0,400.3,0.105,0.013,-2.378,10.29” “Germany (West - Middle - 50d20’N to
52d20’N)” “Accuracy <1m”
testen, ob das vielleicht noch etwas bringt.

Evtl. die hier schon erwähnten die Post #113 erwähnten Beta2007, aber der Effekt wird wohl noch geringer sein.

Ciao,
Frank

Mondschein · August 2, 2011, 12:06am

So geht es:


PROJECTION
    "init=epsg:31467"

    #"Germany (Whole Country)" "Accuracy 3m"
    "towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70"

    #"Germany (Sachsen)" "Accuracy <1m"
    #"towgs84=612.4,77.0,440.2,-0.054,0.057,-2.797,2.55"

    #"Germany (Thüringen)" "Accuracy <1m"
    #"towgs84=599.4,72.4,419.2,-0.063,-0.022,-2.723,6.46"

    #"Germany (West - North - 52d20'N to 55d00'N)" "Accuracy <1m"
    #"towgs84=590.5,69.5,411.6,-0.796,-0.052,-3.601,8.30"

    #"Germany (West - Middle - 50d20'N to 52d20'N)" "Accuracy <1m"
    #"towgs84=584.8,67.0,400.3,0.105,0.013,-2.378,10.29"

    #"Germany (West - South - 47d00N to 50d20'N)" "Accuracy <1m"
    #"towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58"
END

Gruß,
Mondschein

kellerma · August 2, 2011, 6:39am

So,

die spannende Frage ist noch, woher die ~ 1m Diskrepanz zwischen Mapserver (incl. Potsdam-Korrektur)
und dem ImportImagePlugin stammen?

Muessen wir neben der Potsdam (evtl. Beta2007) noch eime weitere Korrektur [die wir
noch nicht bedacht haben] hinzufuegen oder “verhaut” sich das ImportImagePlugin nur?

In Rostock gibt es ja Daten vom Vermessungsamt als Import, wenn ich das aber richtig gelesen habe,
sind die zum Teil um 1 m kuenstlich verschlechert worden.
Leider reichen die Aerowestbilder von Nuernberg nicht bis nach Neunkirchen am Sand., denn dort haetten wir
auch Haeuser aus einem Katasterimport

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

Ciao,
Frank

viw · August 2, 2011, 6:51am

Du kannst ja spaßeshalber einfach mal in Sachsen rumprobieren und dann mit den Luftbildern des LVA vergleichen. www.mittelsachsen-atlas.de ist eine OSM Karte mit amtlichen Luftbildern im Hintergrund. Allerdings solltest du vorher schauen welche Objekte sich zum vergleichen eignen, denn die Bilder in Dresden sind doch schon etwas älter. Wie es in Chemnitz oder Leipzig aussieht kann ich nicht sagen.

Lübeck · August 2, 2011, 6:55am

hi !

ich wollte nochmal nachfragen - die Frage hatte ich zwar schon mal gestellt aber wenn ich nichts übersehe keine Antwort gefunden.

Wenn ich das Bild in GeoTiff konvertiere mit GDAL dann bekomme ich unter JOSM 4279 und Image… 26413 die Meldung

Error while creating Image Layer: null

unabhängig ob in JOSM Mercator oder WGS eingestellt ist.

Kann mir einer weiterhelfen - möchte doch auch zeichnen !

Gruß Jan

DD1GJ · August 2, 2011, 7:14am

Ich habe bei mir in der Gegend ein paar Kanaldeckel mit dem aktuellen amtlichen Luftbild (ATKIS-DOP25, EPSG:31467) mittels QGIS verglichen. Die Abweichung ist kleiner als die Pixelgröße.

Bei dem ImportImagePlugin scheint irgendwas nicht zu stimmen. Vergangenen Mittwoch funktionierte es (4 m Abweichung) und nach einem Update zwei Tage später stimmt überhaupt nichts mehr.

Anstatt überall dezentrale WMS-Server aufzustellen, sollte man sich über ein Plugin ähnlich dem für das französische Kataster Gedanken machen.

ajoessen · August 2, 2011, 9:06am

Falls es dich tröstet: Bei mir kommen die Bilder in JOSM auch nur allenfalls hochkant gequetscht
Musst halt warten, bis das plugin mal richtig funktioniert. Vielleicht tuts nur unter Linux-Systemen, weil irgendwas im Windows java anders ist?

Gruß,
ajoessen

Lübeck · August 2, 2011, 10:07am

hi !

danke - dann muss ich mal meine linux-partition heute abend anwerfen !

bin schon gepannt !

gruß Jan

viw · August 2, 2011, 10:17am

Also ich denke das der Fehler woanders liegt. Denn ich hatte auch unter XP schon das Glück mit diesem Plugin zu arbeiten. Im Moment funktioniert es aber leider nicht mehr. Warum weiß ich auch nicht.

Mondschein · August 2, 2011, 10:26am

Diese Meldung bekomme ich, wenn das TIF den falschen EPSG-Wert hat.

Hast du es denn mit meiner Anleitung (#69) probiert?
http://forum.openstreetmap.org/viewtopic.php?pid=181065#p181065

Hast du die Aerowest-Bilder vorher irgendwie behandelt, wenn ja, wie?

Ich habe mir den Quellcode des Plugins angesehen, das verwendet aber zur Projektion nur wieder irgendwelche jar-Dateien.
Habe deshalb noch nicht herausgefunden, was das genau macht.

Ich werde das vermutlich heute Abend überprüfen, ich habe hier Referenzdaten.

Gruß,
Mondschein

ajoessen · August 2, 2011, 10:26am

Weiter vorne gabs ja den Hinweis auf eine frühere Plugin-Version. Stehen die in irgendeinem svn noch?

Gruß,
ajoessen

Mondschein · August 2, 2011, 10:36am

Wenn ich mich richtig erinnere, dann konnte ich mit dem alten Plugin, direkt die jpg- und jgw-Dateien einlesen, allerdings funktioniert das nicht mit Mercator, weshalb hier jemand die Methode mit der Umwandlung in ein GeoTiff entwickelt hat, mit dem das dann auch mit Mercator geht (mit dem neuen Plugin).
Habe hier ein Backup des Plugins, das ist oft hilfreich.

md5sum
8d7c626404367155c10df5a7fcb2c593 ImportImagePlugin.jar

Gruß,
Mondschein

ajoessen · August 2, 2011, 10:37am

Also egal ob ich aus dem 31466-jpg erst ein Geotiff mache oder nicht: Erstmal erscheint das Bild prinzipiell bei 7°Nord und 51°Ost; unabhängig davon, was in der properties-Datei voreingestellt ist. Setze ich den Haken bei Easting manuell, wird das Bild gequetscht an der richtigen Position gesetzt.

Den Error bekomme ich nicht, die Umprojezierung mache ich in Quantum GIS (was sein eigenes GDAL dabei hat).
Dort sieht das Bild hinterher ordentlich aus.

Gruß,
ajoessen

Mondschein · August 2, 2011, 11:23am

mmd:

gdal_merge.py -o output.tif -co TILED=YES -co COMPRESS=JPEG -n 0 -of GTIFF export*.jpg
gdalwarp -s_srs '+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  <>' -t_srs epsg:3857 output.tif result.tif -co COMPRESS=JPEG -co TILED=YES

Wobei dir die Umwandlung in EPSG 3857 für den Mapserver wenig bringt, da JOSM grundsätzlich immer nur EPSG 4326 Tiles vom Server holt, unabhängig davon, ob der Server andere EPSG anbietet oder welche Projektionsmethode in JOSM eingestellt wurde, JOSM probiert sogar EPSG 4326 Tiles herunterzuladen, wenn der Server diese gar nicht anbietet.

Hier mein bisheriges Vorgehen.
Später werde ich die Dateien direkt in EPSG 4326 umwandeln (wenn ich mein GDAL-Problem mit den verbesserten Koordinateninformationen gelöst habe), damit der Mapserver keine Umprojektion mehr vornehmen muss:

for i in /data/jpg/*.jpg; do filename=$(basename $i); gdal_translate -of GTiff -co COMPRESS=JPEG -a_srs epsg:31467 $i /data/tif/${filename%.*}.tif; done;
gdal_merge.py -v -of GTiff -co COMPRESS=JPEG -co TILED=YES -o /data/epsg-31467_tiled.tif /data/tif/*.tif
gdaladdo --config COMPRESS_OVERVIEW JPEG /data/epsg-31467_tiled.tif 2 4 8 16 32 64 128 256

Zusätzlich gebe ich dem Mapserver die verbesserten Koordinateninformationen mit, siehe:
http://forum.openstreetmap.org/viewtopic.php?pid=181728#p181728
Das wird nicht mehr nötig sein, wenn ich mein GDAL-Problem gelöst habe.

Gruß,
Mondschein