COGs, also Cloud Optimized GeoTIFFs waren hier im #geoObserver [1] schon mehrmals ein Thema. Nun zeigt uns Ujaval Gandhi (@spatialthoughts) in seinem Youtube-Video “Writing Cloud Optimized GeoTIFFs (COGs) – Mastering GDAL Tools” [2], was für ein Konzept hinter diesem Format steckt und wie man COGs mit GDAL erstellen kann. Außerdem seht Ihr, wie Ihr mit QGIS ein 8 GB großes Rasters streamen und zuschneiden könnt, ohne es herunterzuladen. Perfekt, Danke Ujaval Gandhi!
GDAL steht für Geospatial Data Abstraction Library und ist eine Open-Source-Bibliothek für Raster- und Vektor-Geodatenformate. Die Bibliothek verfügt über eine umfangreiche Sammlung von Dienstprogrammen, mit welcher viele Geoverarbeitungsaufgaben ausgeführt werden können. Sie ist vor allem als Kommandozeilen-Tool, aber auch als wesentlicher Bestandteil von QGIS bekannt. Wie Ihr mit GDAL auf der Kommandozeile zaubern könnt, bringen Euch die SpatialThoughts-Spezialisten um Ujaval Gandhi im Videokurs Mastering GDAL Tools [1] bei. Meine Empfehlung!
Wer ständig mit Projektionen, also EPSG-Codes [1] zu tun hat, sollte den Überblick nicht verlieren. Eine gute Hilfe findet Ihr ganz sicher auf epsg.org [2] und spatialreference.org [3].
Auf epsg.org [2] sind alle derzeit aktuellen EPSG-Codes, Stand heute 13022 Einträge, mit Ihren ausführlichen Beschreibungen eingetragen. Besonders hilfreich, wenn man in einem unbekannten Gebiet die gültigen Projektionen sucht, ist die Suche über die Karte “Map Search”, siehe folgende Screenshots. Um auf dem aktuellen Stand zu bleiben, könnt Ihr den den Newsletter abonnieren, aktuell ist momentan das EPSG-Dataset v11.007.
Ein weiteres EPSG-Code-Verzeichnis findet Ihr bei spatialreference.org [3], Stand heute 13439 Einträgen inkl. Beschreibungen.
Update 25.03.2024: Und noch ein weiterer Tipp [4], EPSG-Codes via crs-explorer [5]. Danke Javier Jimenez Shaw!
Das Problem gibt es seit es WMS als Geodienst gibt. Der WMS-Dienstanbieter rendert auf seinem WMS-Server die Vektordaten und liefert ein georeferenziertes Bild zurück, welches dann im GIS-Klienten lagerichtig eingebunden wird. Problematisch wird es immer dann, wenn der Dienste-Anbieter nur von ihm bestimmte Projektionen (EPSG-Codes) anbietet. Will das konsumierende GIS in einer nicht angebotenen Projektion arbeiten, sollte das Bild in einer möglichst naheliegenden Projektion angefordert werden und dann im Klienten on the fly in die Zielprojektion projeziert werden. Das jedoch würde nur verlustfrei funktionieren, wenn diese Umprojektion eine reine Translation (Verschiebung) bedingt. In der Realtität treten aber Skalierung, Drehung und ggf. auch Verzerrung auf, diese haben immer eine Verschlechterung der Bildqualität zur Folge, Ihr kennt das sicher auch jedem Bildbearbeitungsprogramm oder von der Georeferenzierung gescannter Karten im GIS. Man kann das quasi nicht verhindern, es ist technologisch bedingt. Manche Klienten können auch noch das empfangene Bild behandeln, aber das ist kein wirklicher Ersatz eines guten Bildes in der Original-Projektion.
Das einzige 100% wirksame Gegenmittel ist, der Anbieter unterstützt auch den von Euch gewünschten EPSG-Code, fragt ggf. beim Anbieter nach. Ich habe es mal versucht [1], mal sehen, was passiert.
Ich habe das Ganze mal getestet, im QGIS habe ich die basemap.de eingebunden, abgerufen als WMS im EPSG-Code 25832. Dabei wird das View einmal im gleichen EPSG:25832 betrieben und das andere Mal im EPSG:2398. Wegen der o. g. Einschränkungen wird dieses Bild dann qualitativ schlechter dargestellt. Vergrößert mal im Browser mit <Strg><+> oder <command><+> die Ansicht es folgenden Bildvergleichers, Ihr werdet den Unterschied sehen:
Hier noch einmal stark vergrößert:
Und noch stärker vergrößert:
Wer Tipps und Ideen zur Verbesserung hat, gern in den Kommentaren.
Über den Einsatz von KI für die Luftbildauswertung beim Landesamt für Geoinformation und Landesvermessung Niedersachsen (LGLN) hatte ich bereits in “LGLN-News: basemap.de demnächst mit KI in der Luftbildauswertung” [1] berichtet. Nun gab es im Dezember ein Update vom LGLN “Building footprints Oldenburg derived from aerial imagery” [2], [3]. Die kompletten Gebäude der Stadt Oldenburg wurden “durch eine Deep-Learning-basierte Bildsegmentierung” berechnet, als Ergebnisdaten stehen 78038 georeferenzierte Gebäude- Polygone unter der CC0-Lizenz frei downloadbar zur Verfügung. Ich habe mir die Daten im GeoJSON-Format (59.1 MB) [4] geladen und dann im QGIS visualisiert und … Hut ab, es ist schon erstaunlich, mit welch hoher Trefferquote und Präzision die Kollegen um Dr. Jonas Bostelmann KI-automatisiert die Gebäude generieren. Urteilt selbst, hier ein paar Screenshots meines QGIS-Projektes. Die Gebäude wurden über das Item „Confidience“ als Maß für die Genauigkeit der Erkennung klassifiziert.
Am Wochenende kam bei X (ehem. Twitter) eine kleine Diskussion zum Thema Mittelpunkt(e) Deutschlands [1] auf. Interessant genug, um sich mal einzulesen und erwartungsgemäß ist das Thema gar nicht so einfach. Aber warum? Eine ganze Sammlung von Umständen beeinflussen die exakte Bestimmung des Mittelpunktes, so zum Beispiel:
nicht exakte und/oder fehlende Grenzlinien
Einberechnung von Inseln und Halbinseln
Projektion
Wer es genauer wissen möchte, kann sich in den unten genannten Quellen vertiefter zum Thema belesen und falls Ihr noch andere Quellen habt oder findet, zeigt uns diese gern in den Kommentaren, ich jedenfalls bin gespannt.
Den “geohash” kennt Ihr schon? Im Wikipedia [1] (hier mit Deepl übersetzt) heißt es dazu:
“Geohash ist ein gemeinfreies Geocodesystem, das 2008 von Gustavo Niemeyer[1] erfunden wurde und einen geografischen Standort in einer kurzen Zeichenfolge aus Buchstaben und Ziffern kodiert. Ähnliche Ideen wurden 1966 von G.M. Morton eingeführt[2]. Es handelt sich um eine hierarchische räumliche Datenstruktur, die den Raum in gitterförmige Bereiche unterteilt, was eine der vielen Anwendungen der so genannten Z-Kurve und allgemein raumfüllender Kurven ist.” [1]
Mit diesem geohash kann man also ziemlich präzise jeden Punkt dieser Welt in einer einfachen , kurzen Zeichenfolge abbilden, bei 12 Stellen erreicht man eine Genauigkeit von immerhin “37.2mm×18.6mm” [2]. Mit dem Geohash-Explorer [3] habe ich mal das Händeldenkmal auf dem halleschen Markplatz gesucht, Ergebnis “u30sbkh7y”.
Für QGIS-Nutzer gibt es vorgestern (12.12.2023) ein neues Plugin, das “Geohash Expressions Plugin” [4]. Die geohash-Funktionen findet Ihr dann im Feldrechner. Ich hab’s getestet, es funktioniert perfekt, siehe Beispiel von oben, das Händeldenkmal auf dem halleschen Markplatz.
Datenhaltung in der Cloud nimmt auch für Geodaten immer mehr an Bedeutung zu. Dementsprechend werden auch immer neue Datenformate entstehen, welche auf die speziellen Anforderungen wie Reduzierte Latenz, Skalierbarkeit, Flexibilität und Kosteneffizienz in der Cloud optimiert sind, eben Cloud Optimized! Per Tweet [1] bin ich auf den “Cloud-Optimized Geospatial Formats Guide” [2], also den “Leitfaden für Cloud-optimierte Geodatenformate” aufmerksam geworden und gebe das als Tipp gern weiter. Interessanter Überblick zum aktuellen Status der cloudoptimierten Datenformate. Danke @cloudnativegeo [3]!
Ihr habt einen eigenen WMS/WFS erstellt und wollt ihn prüfen? Oder Ihr wollt ein solchen Dienst im eigen GIS nutzen und es klappt vielleicht nicht? Dann schaut Euch mal den Open Web Services Inspector [1] auf MapServerStudio an. Ein kleines hilfreiches und wirksames Tools, um OGC-konformer Geodienste zu prüfen und vorab zu beurteilen. Unterstützt werden z. B. für WMS:
Hilfreich, dass die aktuellen Einstellungen auch immer gleich als Kommandozeile (unten) ausgegeben werden. Natürlich kann man die Dienste auch ohne dieses Tool via selbst geschriebener Kommandozeile testen, aber so geht es viel komfortabler und schneller! Noch eine Hinweise: Die Dienste-URLs werden nur als https akzeptiert.