Aerowest: WMS-Bilder aufräumen

hi !

es ist etwas Zeit inzwischen vergangen und der eine oder andere hat schon Bilder in größeren Mengen gezogen.

Trotz aller Bemühungen kann man nicht blattschnittlos herunterziehen und so kommt es zu Überlagerungen in den lokalen Bildern was wiederum irgendwann zu lasen des Speichers geht. Ich habe zwischenzeitlich ca. 1500 Bilder gezogen und würde diese gerne etwas aufräumen.

Hat einer von Euch soetwas schon einmal gemacht - mir schwebt vor mit GDAL oder ähnlichem irgendwie die Bilder zu verschmelzen und dann “sauberere” Kacheln für den lokalen Server zu schneiden.

Gibt es schon fertige Scriptzeilen (Windows ?) oder andere Ansätze dafür ???

Gruß Jan :slight_smile:

hallo,

ich weiß jetzt nicht genau, ob es das ist was du suchdst, aber schau dir mal

gdaltindex und gdal2tiles.py

an.

grüße von lutz

Siehe hier (#149) http://forum.openstreetmap.org/viewtopic.php?pid=181866#p181866
und hier (#163) http://forum.openstreetmap.org/viewtopic.php?pid=181972#p181972

Kurz:

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

epsg:3146x und Pfade wie üblich anpassen.
Für Windows muss das eben etwas angepasst werden.

Das erstellt dir aus den georeferenzierten JPEG-Dateien eine gekachelte und JPEG-komprimierte TIF-Datei.
Die Auflösungspyramide (gdaladdo) kannst du evtl. weglassen, es ist allerdings fraglich, ob das in jedem Fall sinnvoll ist.

Bzgl. der Dateigröße der entstehenden JPEG-komprimierten TIF-Datei kann ich dir zurzeit nichts sagen.

Zu den BeTA 2007 Korrekturdaten brauche ich hoffentlich nichts mehr zu sagen…

Gruß,
Mondschein

Hallo Jan,

was meinst Du genau mit “lokalem Server” und was hast Du genau vor damit, sprich wie arbeitest Du heute mit den Bildern? Soll es ein einfacher Web-Server sein, der Bilder als JPG/PNG anbietet oder hast Du einen lokalen WMS-Server am Laufen?

Für den WMS-Server wie im Wiki beschrieben spielt es eigentlich keine Rolle, wenn sich die einzelnen Bilder überlappen.

Oder: Willst Du wieder neue (überlappungsfreie) JPG Bilder erzeugen und die mit PicLayer Plugin bearbeiten?

Oder: das schon angesprochene gdal2tiles.py kann aus ganz vielen .tif Bildern eine fertige Ordnerstruktur mit Bildern generieren - über den Web Server freigegeben wird daraus http://localhost/mein_verzeichnis_mit_tiles/6/33/21.png. Unter JOSM lässt sich das über TMS einbinden: tms:http://localhost/mein_verzeichnis_mit_tiles/{zoom}/{x}/{y}.jpg

Gruß,

hi !

“Für den WMS-Server wie im Wiki beschrieben spielt es eigentlich keine Rolle, wenn sich die einzelnen Bilder überlappen.” - da hast Du sicherlich recht aber da der Download über die Webseite von Aerowest nicht ganz sauber blattschnittlos funktioniert kommt es zu mehr oder weniger Überlappungen. Das macht technisch nichts.

Mein Gedanke war nur wenn die Bilder sauberer geschnitten sind könnte die Performance für den lokal betriebenen WMS-Server gesteigert werden.

Das mit dem gdal2tiles habe ich bisher aus zeitlichen Gründen noch nicht ausprobieren können.

Gruß Jan :slight_smile:

Hi,

performancemäßig bin ich von meinem lokalen WMS-Server auch nicht gerade begeistert. Mein Server läuft in einer Virtual Machine auf einer lahmen Laptop-Festplatte. Bis Level 20 oder 21 ist die Performance zwar noch ok, weiter rauszoomen wird aber mit heftigem Festplatten-Gerödele und Time Outs bestraft. Hab mir als Kompromiss einen TileCache dazwischengeschaltet - wenn der WMS-Server schon ewig für die Bilder rödelt, sollen die Ergebnisse wenigstens beim nächsten Mal direkt im Cache verfügbar sein.

Da ich immer wieder neue Bilder herunterlade, war mit die Lösung mit gdal_merge oder gdal2tiles zu unflexibel. Jedes Mal wieder alle Bilder zu verarbeiten dauert mit bei der Menge an Bildern einfach zu lange. Jetzt müsste ich dem TileCache nur noch irgendwie beibringen können, einzelne Tiles wegzuwerfen, sobald neue Bilder verfügbar sind.

Gruß,

hi !

wenn wir die Fragen noch etwas besser formuliert bekämen, dann kann ich vielleicht nächste Woche noch jemanden Fragen - bekomme ein GDAL-Schulung. Dann würde ich das mal einwerfen oder in der Pause ansprechen.

Gruß Jan :slight_smile:

Dann verwendest du vermutlich keine Auflösungspyramide.

Gruß,
Mondschein

Genau. Zunächst alle Bilder mit gdal_merge zu einem Bild zusammenfügen und dann die Auflösungspyramide mit gdaladdo ermitteln dauert bei 1500+ Bildern einfach zu lange. Beide Programme arbeiten auch nur mit einer CPU, so dass die Verarbeitung unnötig lange dauert. Und nochmal die ganze Orgie durchspielen, nur weil ich mal wieder ein paar neue Bilder heruntergeladen habe, hat mir auch nicht sonderlich gefallen :slight_smile:

Daher versuchen wir mal einen anderen Ansatz. Tante Google hat zum Thema gdal und performance optimization folgenden interessanten Post herausgespuckt: http://lists.osgeo.org/pipermail/gdal-dev/2010-November/026839.html. Punkt 1 habe ich gerade ausprobiert. Grundsätzlich ist die Idee, nicht für ein großes GeoTIFF die Auflösungspyramide zu berechnen, sondern für jedes einzelne (kleine) TIFF. Das Ergebnis wird dann als “external overview” in einer .tif.ovr Datei abgelegt.

Kombiniert man das ganze mit GNU Parallel (zum Parallelisieren der gdaladdo-Aufrufe), lassen sich 1500+ TIFF-Dateien bequem in <20 Minuten auf einem 4-Core Laptop verarbeiten.


parallel -i -j 5 gdaladdo --config GDAL_CACHEMAX 200 --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 80 -ro {} 2 4 6 8 16 32 64 128 256 -- *.tif

(Hint: im Gegensatz zum Wiki wandele ich meine JPG Dateien zunächst in TIF um. Ich denke, gdaladdo sollte auch mit einzelnen JPG-Dateien als Eingabe klar kommen, hab’s aber nicht ausprobiert)

MapServ sollte die neuen .ovr Dateien automatisch finden (evtl. gdaltindex nochmal anstoßen?) und daraus die Vorschau erzeugen können.

Klar, das Verfahren hat den Nachteil, dass u.U. viele .ovr Dateien gelesen werden müssen, aber dafür schlägt sich das ganze doch noch ganz gut. Und vor allem kann ich so neue Bilder in wenigen Minuten neu einbinden.

Was sind eure Erfahrungen?

Gruß,

Stimmt.

Hört sich interessant an.

Bei der 25 fehlt etwas: 256 :slight_smile:

Scheint zu funktionieren, mein Rechner arbeitet jedenfalls gerade fleißig die JPEG-Dateien ab.

Hm, das werde ich noch ausprobieren.

Finde ich sehr gut.

Ich bin noch beim Sammeln. :slight_smile:

Gruß,
Mondschein

Funktioniert sehr gut.

Das Herauszoomen ist jetzt deutlich schneller und ohne Zeitüberschreitungen. :slight_smile:
Das ist ein guter Kompromiss zwischen einfacher Benutzbarkeit und Geschwindigkeit (für den Heimgebrauch).

Gruß,
Mondschein

Hinweis:
Ich habe soeben bemerkt, dass gdaladdo beim Erzeugen der Auflösungspyramide für ein Bild, dessen ovr-Datei schon existiert, die vorhandene ovr-Datei nicht löscht und neu erstellt oder unverändert lässt, sondern die Auflösungspyramide an die vorhandene ovr-Datei anhängt. :frowning:
Dies hat zur Folge, dass nach mehrmaliger Ausführung von gdaladdo für ein Bild die zugehörige ovr-Datei immer größer wird.
Ich hatte neue Bilder hinzugefügt und gdaladdo für alle Bilder neu aufgerufen und dann festgestellt, dass die ovr-Dateien der alten Bilder größer waren, als die alten Originalbilder. :open_mouth:

Ich habe mein Skript jetzt angepasst, so dass gdaladdo nur für die neuen Bilder (bzw. die Bilder, für welche es noch keine ovr-Dateien gibt) ausgeführt wird:

for i in *.jpg; do
if ! [ -e "$i.ovr" ]; then
gdaladdo --config GDAL_CACHEMAX 200 --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL --config JPEG_QUALITY_OVERVIEW 80 -ro "$i" 2 4 6 8 16 32 64 128 256
else echo "$i.ovr existiert schon"
fi
done

Im Wiki habe ich das auch angepasst:
http://wiki.openstreetmap.org/wiki/DE:Installation_und_Verwendung_von_MapServer_für_Aerowest_Luftbilder

Gruß,
Mondschein

Guter Punkt. Ich habe mich gerade gefragt, warum das Problem bei mir nie aufgetreten war. Die Lösung ist aber recht einfach: ich arbeite mit einem getrennten Download-Verzeichnis, wandele dort die jpgs um und lasse auch gdaladdo dort laufen. Erst danach wandern die *.tif + *.ovr Dateien in das mapserver-Verzeichnis. So wurden tifs nie mehrfach von gdaladdo bearbeitet. Hätte ich vielleicht mal dazu schreiben können … :slight_smile:

Gruß,
mmd