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.
Screenshot 1: “Map Search” für Halle (Saale), Suche über Box (Quelle [2])Screenshot 2: Gefundene EPSG-Codes für Halle (Saale) auch mit unserem aktuellen 2398 (Quelle [2])Screenshot 3: Die Beschreibung der EPSG:2398 (Quelle [2])
Ein weiteres EPSG-Code-Verzeichnis findet Ihr bei spatialreference.org [3], Stand heute 13439 Einträgen inkl. Beschreibungen.
Screenshot 3: Die Beschreibung der EPSG:2398 (Quelle [3])
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:
Screenshot 1: Die Qualitätseinbußen rechts (bei unterschiedlichen Projektion von Lieferant und Konsument) sind deutlich
Und noch stärker vergrößert:
Screenshot 2: Die Qualitätseinbußen rechts (bei unterschiedlichen Projektion von Lieferant und Konsument) sind nun noch deutlicher, beachte die Artefakte in der Beschriftung rechts
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.
Our AI image segmentation has learned a lot this year and is now able to map almost all types of buildings very accurately, reliably and quickly. 🛩️📷🤖🏠🗺️
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]!
To help you navigate the expanding universe of cloud-native geospatial technologies, we’re excited to introduce the Cloud-Optimized Geospatial Formats Guide. Visit the guide to get started https://t.co/Svit4xXkpUpic.twitter.com/UpwLtQx5vN
— Cloud-Native Geospatial Foundation (@cloudnativegeo) October 23, 2023
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:
Screenshot 1: GetMap auf den FNP-WMS [3]Screenshot 2: GetCapabilities auf den FNP-WMS [3]Screenshot 3: GetLegendGraphic auf den FNP-WMS [3]
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.
Screenshot: Beitrag „lon lat lon lat“ [1], hier mittels Browser-Funktion auf deutsch übersetzt
Die Frage, in welcher Reihenfolge Koordinaten angegeben werden, ist so alt wie Geodaten und GIS. Man kann aber auch durcheinander kommen!
Eigentlich kennen wir aus der Mathematik X/Y, irgendwann haben die Geodäten das dann auch mal vertauscht, die Folge: Mathematisches und geodätisches Koordinatensystem “widersprechen” sich und haben auch gleich noch unterschiedlichen Einheiten (Grad und Gon), vgl. [2].
Screenshot: Ausschnitt aus dem Kapitel Koordinatensystems in [2]
Die Bezeichnungen HW/RW (Hochwert/Rechtswert), neuerdings sogar Ost- und Nordwert [3] machten dieses Ärgernis dann wieder etwas ertragbarer, aber welche Reihenfolge ist nun richtig? Tom MacWright hat es in seinem Beitrag “lon lat lon lat” [1], versucht zu beantworten. Spoiler:
“Dies ist eine Meinung, auf die es keine richtige Antwort gibt”
Diese Aussage war ja zu befürchten. Interessant ist jedenfalls die Liste der Verwendung von Lat und Lon in verschiedenen Geodatenformaten und APIs, also: wie wird es wo benutzt?
… die jeder GIS-Analyst kennen sollte. In meinen Schulungen hören die Teilnehmer oft den Satz von mir: “GIS fängt eigentlich erst bei Geoprocessing an, vorher ist nur Gucken” 😉 In diesem Sinne leite ich Euch heute mal den Artikel “7 Geoprocessing Tools Every GIS Analyst Should Know” [1], [2] von GISGeography weiter. Danke & 100% Zustimmung! Man muss kein GIS-Guru sein oder werden wollen, es ist grundlegendes Handwerkszeug: Buffer, Clip, Merge, Dissolve, Intersect, Union, Erase. Ich habe genau mit diesen Tools auch 1991 im GIS begonnen, es hat sich quasi an diesem GIS-Fundament nichts geändert.
Auch in unserem KomGIS+ [3] findet Ihr die typischen, grundlegenden Geoprocessing-Funktionen:
Screenshot 2: Geoprocessing-Werkzeuge im KomGIS [3] Screenshot 3: Ausschnitt aus meiner Schulung zum Thema Geoprocessing
Seit QGIS 3 gibt es die “Topologische Einfärbung”, eine sinnvolle Funktion, um Polygone so einzufärben, dass niemals benachbarte Polygone die gleiche Farbe haben. In der QGIS-Hilfe heißt es dazu:
“Dieser Algorithmus weißt Polygonen einen Farbindex dergestalt zu, dass keine benachbarte Polygonen den gleichen Index haben. Dabei wird die Farbanzahl minimiert.”
Per Default ist die Anzahl der zu verwendenden Farben auf “4” gesetzt, aus gutem Grund?! Es geht um den “Vier-Farben-Satz” [1]. Wenn Ihr die wunderbare Story dazu lesen wollt, empfehle ich Euch den in Spektrum der Wissenschaft erschienenen Artikel “Die ganze Welt in vier Farben” [2] von Manon Bischoff über den “124 Jahre” dauernden “wohl umstrittenste(n) Beweis der Mathematikgeschichte”.
Screenshot: Ausschnitt aus meinen QGIS3-News-Vortrag von 2018 und der “Die ganze Welt in vier Farben“-Story (Quelle [2])
Ergänzung (07.08.2023, 11:22 Uhr): QGIS scheint jedoch in seinem Algorithmus nicht immer mit vier Farben auszukommen, bei meinen Tests schwankte es je nach Thema (z. B. Österreich und die Baublöcke von Halle) und Optionen zwischen 5 und 8 Farben, vgl. Tweet [4].
