Vermutlich kennt Ihr etliche Arten von Karten, z. B. Choroplethen, Heat Maps, Isochrone, Contour oder Topografische. Aber wie viele kriegt Ihr wirklich zusammen? Auf GISGeography findet man im Beitrag “25 Map Types for Building Unbeatable Maps” [1] fünfundzwanzig (*staunen*) davon. Interessant, Lesetipp!
Über die Shademap.app hatte ich in [1] und [2] schon berichtet, jetzt ist ein neues Feature dazu gekommen, die Bäume [3]. Während die Shademap.app kostenfrei ist, können die Bäume derzeit mit 2,49$/km² hinzu gekauft werden. Auf Youtube steht eine Demo [4] bereit. Wie die hochauflösenden Karten der Baumkronenhöhe aus RGB-Bildern generiert werden, könnt Ihr in “Very high resolution canopy height maps from RGB imagery using self-supervised vision transformer and convolutional decoder trained on aerial lidar” [5] erfahren.
Hier der Original-Tweet [3]:
[1] … https://geoobserver.de/2022/01/19/shademap-der-lauf-der-sonne/
[2] … https://geoobserver.de/2023/01/10/shademap-app-schattensimulation-mit-osm-daten/
[3] … https://x.com/shademap/status/1792007440227074300
[4] … https://www.youtube.com/watch?v=CN7lQhNOv4I
[5] … https://www.sciencedirect.com/science/article/pii/S003442572300439X
Sicherlich wusstet Ihr, das man LAT/LON in verschiedenen Formen angeben kann, so sind Dezimalgrad oder Grad, Minute, Sekunde üblich und bekannt. Nun habe ich eine interessante (ältere) Quelle gefunden, die uns acht(!) gültige Schreibweisen präsentiert, schaut mal bei “Koordinatenformate, Koordinaten Darstellung und Schreibweise WGS84 – Schweizer Gitter” [1] auf c-dev.ch. Wie Ihr das Ganze in PostGIS wandeln könnt, erfahrt Ihr in “Converting DMS to PostGIS Point Geometry” [2]
[1] … http://www.c-dev.ch/2012/10/26/koordinatenformate/
[2] … https://www.crunchydata.com/blog/converting-dms-to-postgis-point-geometry?utm_source=dlvr.it&utm_medium=twitter
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!
Hier der Original-Tweet [3]:
[1]… https://geoobserver.de/?s=cog&submit=Suchen
[2] … https://www.youtube.com/watch?v=vHrT9pKmQgQ
[3] … https://x.com/spatialthoughts/status/1786409903487168868
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!
[1] … https://www.youtube.com/playlist?list=PLppGmFLhQ1HLVaHVf4TsnJ4HXZBSfxLOK
[2] … https://x.com/spatialthoughts/status/1782481695029318009
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!
[1] … https://de.wikipedia.org/wiki/European_Petroleum_Survey_Group_Geodesy
[2] … https://epsg.org
[3] … https://spatialreference.org
[4] … https://mapstodon.space/@jjimenezshaw/112144149776141947
[4] … https://crs-explorer.proj.org/
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.
Update 18.01.2024, 14:15 Uhr: Die Daten im GeoJSON-Format (72,0 MB) [6] wurden heute aktualisiert (vgl. auf 1. Kommentar von Jonas)
Hier der Original-Tweet [2]:
Noch mehr auf Youtube [5] in 4K:
[1] … https://geoobserver.de/2023/02/16/lgln-news-basemap-de-demnachst-mit-ki-in-der-luftbildauswertung/
[2] … https://x.com/JonasBostelmann/status/1737508840852070782
[3] … https://zenodo.org/records/10401144
[4] … https://zenodo.org/records/10401144/files/building_footprints_Oldenburg.geojson?download=1
[5] … https://www.youtube.com/watch?v=ZPhvUIjvfbQ&t=60s
[6] … https://zenodo.org/records/10526811
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:
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.
[1] … https://twitter.com/tobwen/status/1743544081605611537
[2] … https://de.wikipedia.org/wiki/Mittelpunkte_Deutschlands
[3] … https://de.wikipedia.org/wiki/Mittelpunkte_Deutschlands#%C3%9Cbersichtskarte
[4] … https://aktuell.nationalatlas.de/mittelpunkte-7_07-2012-0-html/
[5] … https://d-nb.info/1025568648/34
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.
[1] … https://en.wikipedia.org/wiki/Geohash
[2] … https://www.movable-type.co.uk/scripts/geohash.html
[3] … https://geohash.softeng.co/u30sbkh7y
[4] … https://plugins.qgis.org/plugins/geohash_expressions/