Meine Leseempfehlung zum Thema: Wirkt der „Dark Mode“ in der Kartographie anders herum oder wie werden die Farben im immer mehr genutzten Dunkelmodus wahrgenommen? Während im Hellmodus dunklere Farben mit einer größeren Wertigkeit assoziiert werden, stellt sich die folgende Frage: Ist das im Dunkelmodus genau so oder, wie vielleicht zu erwarten, genau umgekehrt? Prof. Dr. Jochen Schiewe, Präsident der DGfK [1] hat es in einer mit 214 Personen durchgeführten Online-Studie untersucht. In seinem KN-Beitrag „Dark‑is‑More Bias Also in Dark Mode? Perception of Colours in Choropleth Maps in Dark Mode“ [2], als PDF downloadbar unter [3], sind die Ergebnisse veröffentlicht, also, wie die Farben im Hell- und Dunkelmodus auf die Probanden wirken. Ich spoilere mal nicht, lest selbst 😉 es lohnt sich. Nur eins dazu:
„Die Studienergebnisse erlauben auch generelle Gestaltungsempfehlungen für künftige Dunkelmodus-Farbschemata für Karten.“ [2]
NDVI (Normalized Difference Vegetation Index) [1] ist lt. Wikipedia „der am häufigsten angewandte Vegetationsindex“ und ist seit Jahren ein Standardwerkzeug bei der Beurteilung von Fernerkundungsdaten. In vielen GI-Systemen ist er einfach zu berechnen mit der vergleichbar simplen Formel:
In QGIS kann diese Berechnung unkompliziert mit dem Rasterrechner realisiert werden. Ich habe das mit den vom LVermGeo LSA als freie DOP20-Luftbilder [2] angebotenen Daten getestet. Die Besonderheit hier: die DOP20 repräsentieren im Kanal 4 den benötigten NIR-Kanal. Folgender Screenshot zeigt die Vorgehensweise im QGIS-Rasterrechner mit den LSA-DOPs.
Screenshot 1: Umsetzung der NDVI-Berechnung im QGIS mit dem Ratserrechner
Um das Ergebnis der Berechnung, ein Graustufen-Bild, noch deutlicher zu visualisieren, kann das entstandene Raster z. B. als „Einkanalpseudofarbe“ eingefärbt werden. Die Klassen und Unterschiede im NVDI werden damit deutlich sichtbarer.
Screenshot 2: Einfärben des Graustufen-Ergebnisses als „Einkanalpseudofarbe“ im QGIS
Grenzen und Gefahren bei Fehlinterpretation:
vertrocknete pflanzliche Strukturen (z. B. vertrocknete Rasenfläche)
Screenshot 3: Gefahr der Fehlinterpretation durch Verschattung (hier Verschattung von Dächern)Screenshot 4: Verschattung von Dächern kann dazu führen, dass das Dach teilweise als „Grün“ interpretiert wirdScreenshot 5: Gefahr der Fehlinterpretation durch vertrocknete pflanzliche Strukturen (hier vertrocknete Rasenfläche)Screenshot 6: Die vertrocknete Rasenfläche kann dazu führen, dass sie teilweise als „versiegelt“ interpretiert wird
Danke für den fachlichen Input und das Coaching von M. Sc. Matthias Henning von der Hochschule Anhalt. So muss Netzwerken! Hier noch ein paar wichtige Bemerkungen und Ergänzungen von Matthias bzgl. der Grenzen und Gefahren bei Fehlinterpretation:
„So gerne und häufig der NDVI auch eingesetzt wird, sollten die Grenzen der jeweiligen Methode immer berücksichtigt werden. Beim NDVI sind diese vor allem bei den Sensoren (Kamera) und den aufgenommenen Lichtspektren zu finden. Einfache Kameras nehmen den NIR-Bereich lediglich als den Bereich wahr, der auf den roten Bereich folgt. Die Intensität der Lichtaufnahme ist bei jedem Kamerasensor unterschiedlich und gleicht einer Kurve. Etwas hochwertigere Kameras steuern die auf den Sensor treffenden Wellenlängenbereiche über einzelne schmalbandigere Filter. Im Bild unten sind die Bereiche der Multispektralkamera der im Einstiegs-UAV-Bereich häufig verwendeten DJI Mavic 3 zu sehen (CC-BY-4.0, Jon Atherton). Diese ordnet die Bereiche des roten und nah-infraroten Spektrums deutlich schmaler zu als z.B. den Rotbereich einer RGB-Kamera. Im Bereich der professionellen Fernerkundung werden diese Wellenlängenbereiche noch viel detaillierter und feiner erfasst. Daher können die NDVI-Werte unterschiedlicher Kamerasysteme nicht ohne weiteres verglichen werden. Ebenso spielen der Sonnenstand, Schattenwürfe, Zentrum der Bildaufnahme, Wuchsrhytmus der Pflanzen, Feuchtigkeit, die Temperaturen und atmosphärische Verzerrungen eine Rolle. Das Licht der Sonne musste immerhin bereits viele Kilometer durch die Atmosphäre zurücklegen, bevor es reflektiert wurde und zum Sensor gelangte. Selbst der Vergleich zweier Aufnahmen desselben Sensors ist daher nicht immer einfach, zumal jedes Sensorsystem teilweise eigene Korrekturen dafür vorsieht. Entweder wird daher der NDVI in jeder Aufnahme kalibriert, indem beispielsweise auf die Werte des vitalsten Baumes normalisiert wird. Oder aber es wird nicht der NDVI, sondern dessen Klassifikation je Aufnahme in verschiedene Vitalitätsklassen, miteinander verglichen.“
Bildquelle: Atherton, J., Alonso Chorda, L., Suomalainen, J., Miettinen, I., Kuurasuo, J., & Hakala, T. (2024). DJI Mavic 3 Multispectral Edition spectral response [Data set]. Zenodo. [3]
Neben NDVI findet Ihr weitere Indizes in folgendem Tweet [4] und der Index DataBase [5].
NDVI, EVI & SAVI are powerful tools in remote sensing, offering insights into vegetation health, density, & distribution.
This infographic highlights their differences in formula, sensitivity, strengths, weaknesses, computational requirements, and ideal use cases. pic.twitter.com/d5lqSjcx1t
Zum Wochenende meine Leseempfehlung. Einen wunderbaren Artikel über Flächenberechnung in GI-Systemen habe ich die Tage auf LinkedIn [1] gefunden. Im Artikel „Why your GIS polygons might be lying to you: The Zero-Area Paradox“ [2] zeigt Ahmad Zaenun Faiz, wie ein GIS die Flächeninhalte ermittelt und welche Besonderheiten und Fallen es dabei gibt. Selbstüberschneidene Polygone (self-intersecting polygons) haben danach „selbstverständlich“ eine falschen Flächeninhalt. Ich habe das Ganze mal im QGIS nachgestellt, siehe die folgende Animation. Übrigens, mein QGIS-Plugin QuickPolygonRepair [3] repariert via GEOS-Methode solche Polygone ;.)
Annimation: Falschen Flächeninhalt, nämlich 0,00 m² bei einem selbstüberschneidenen Polygon
Abbildung: Die alte und die neue Welt (Bildquellen [2], [3])
Seit 1991 arbeite ich mit GI-Systemen, angefangen habe ich mit ARC/INFO 4.0. Und damals, als Topologie noch eine heilige Kuh war, hatten wir leistungsstarke Funktionen für die Topologiebildung und das Geoprozessing. CLEAN & BUILD dienten der Qualitätssicherung und der korrekten Topologie, sie waren nach jeder Editiersitzung Pflicht. UNION, IDENTITY, CLIP, ERASE und Co. wurden für das Geoprozessing genutzt. Leider wurden später in der Geodatenwelt die Pflicht zur Topologie und auch diese einfachen und nützlichen Kommandozeile-Befehle aufgegeben. Ich jedenfalls hab sie mir immer mal wieder gewünscht.
Befragt man eine KI zum Thema „Indizierung von Datenbanken“, bekommt man z. B. folgende Antwort:
„Datenbankindizierung beschleunigt Suchanfragen durch das Erstellen von separaten Datenstrukturen (Indizes), die wie ein Inhaltsverzeichnis funktionieren und schnellen Zugriff auf bestimmte Datensätze ermöglichen, indem sie die Notwendigkeit des sequenziellen Durchsuchens großer Tabellen reduzieren; dies erhöht die Performance bei Suchen, erfordert aber zusätzlichen Speicher und Pflege bei Schreibvorgängen (INSERT, UPDATE, DELETE).“ [hier Google-KI-Antwort vom 26.01.2026, 20:00 Uhr]
Aber wusstet Ihr, wie viele verschiedene Arten der Indizierung in einer PostgreSQL möglich sind? Mir waren in meiner Praxis bisher im Wesentlichen nur B-Tree und speziell für Geodaten der GIST unter gekommen. Aber es gibt deutlich mehr. Durch einen LinkedIn-Beitrag [1] und einen Tweet [2] von Crunchy Data bin ich angepingt worden, dort kommen sie auf 10 verschiedene Arten von Indizes, andere Quellen [3] weisen 9 Typen aus.
Einen coolen Beitrag zum Einstieg für GIS-Neulinge und als Auffrischung für gestandene GIS-Nutzer (Profis und Nerds) habe ich bei GISGeography in „25 Must-Know GIS Editing Tools“ [1] gefunden. Trace, Move, Rotate, Buffer, Scale, Reshape, Simplify, … die meisten Funktionen kennt Ihr vermutlich, aber hättet Ihr auch alle zusammen gekriegt? 😉
Einen interessanten Beitrag von Rashid Jaafar zum Thema „GPS & Co“ [1] habe ich neulich auf LinkedIn gefunden und möchte ihn hier für Euch weiter leiten, direkt als Übernahme, da Nicht-LinkedIn-Nutzer ohne Anmeldung momentan dort auch nicht mitlesen können. Danke Rashid Jaafar für die Aufklärung und Zusammenfassung bzgl. der verschiedenen Systeme und Bezeichnungen. Gut, mal wieder dran erinnert zu werden 😉
„📡 GPS vs. GNSS:
Warum viele den Begriff falsch verwenden und warum es in der Vermessung richtig teuer werden kann.
Im Alltag sagen die meisten einfach „GPS“. Auf der Baustelle, im Auto, sogar in Fachgesprächen.
Aber als Vermesser weißt du: GPS ist nur EIN System. GNSS ist die ganze Welt.
Und genau dieser Unterschied entscheidet darüber, wie schnell dein Fix kommt – wie stabil deine Lösung ist – und wie präzise deine Arbeit am Ende wird.
🇺🇸 GPS (USA)
Global Positioning System Das amerikanische System. Der „Vater“ aller Navigationssatelliten. Start: 1978 Für viele Jahre das Einzige, was es gab.
🇪🇺 Galileo (Europa)
Das modernste zivile System der Welt. Extrem stabil. Extrem präzise. Start: 2016 Für Vermesser heute fast unverzichtbar.
🇷🇺 GLONASS (Russland)
Start: 1982 Robustes System, hilfreich bei schlechten Sichtbedingungen. In Kombination mit GPS/Galileo sehr wertvoll.
🇨🇳 BeiDou (China)
Start: 2000 / global seit 2020 Sehr schnelle Signale, moderne Satelliten – und in vielen Receivern längst Standard.
🔍 Der echte Unterschied?
GPS = ein System GNSS = alle Systeme zusammen.
In der Praxis bedeutet das:
🔸 Mehr Satelliten 🔸 Weniger Signalabbrüche 🔸 Bessere Genauigkeit 🔸 Schnellere Fix-Lösung 🔸 Stabiler unter Bäumen, Brücken, Gebäuden 🔸 Verlässlicher bei Maschinensteuerung & Drohnen
Kurz gesagt:
Wer heute noch „GPS“ sagt, misst eigentlich mit GNSS. Und wer nur GPS nutzt, verschenkt Präzision.
💬 Eure Erfahrung zählt:
Welche Genauigkeit erreicht ihr aktuell mit eurem System?
RTK? NRTK? SAPOS? VRS Now?
👇 Schreibt eure Werte in die Kommentare – ich vergleiche gern!
🔸 Teile den Beitrag, damit mehr Leute den Unterschied verstehen.
Animation: Donut-Polygon-Generierung mit KomGIS+ via ERASE
Donut-Polygone, mitunter auch als Kreisringlöcher oder Inselpolygone bezeichnet, werden im GIS immer wieder gebraucht, z. B. dann, wenn eine Fläche ein Gebiet nicht vollständig, sondern auch eine Insel oder ein Loch enthält. In einigen GI-Systemen gibt es dafür spezielle Werkzeuge, in manchen, z. B. unserem KomGIS+ nicht. Aber es braucht sie auch nicht zwangsläufig, da man auch mit den ganz normalen Geoprocessing-Funktionen solche Polygone erzeugen kann. Praxisbeispiel war ein Nutzeranfrage: „Ich brauche alle Flurstücke einer Gemarkung, aber ohne die darin liegende Dorflage“. Wie es gelöst werden, wird in den folgenden drei Schritten gezeigt:
Schritt 1: Erzeugen/Beschaffen des Aussenpolygons (z. B. die Gemarkung)
Schritt 2: Erzeugen/Beschaffen des Insel- oder Lochpolygons (z. B. die Dorflage)
Schritt 3: Ermittlung des Donut-Polygons durch Geoprozessing mit der ERASE-Funktion (Gemarkung minus Dorflage)
Schritt 4: Berechnung der Zielflurstücke mittels Geoprozessing via CLIP-Funktion (Flurstücke gegen Donut-Polygon)
Screenshot 1: Geoprozessing mit ERASE – PrinzipdarstellungScreenshot 2: Ausgangssituation – Die Flurstücke im BearbeitungsgebietScreenshot 3: Schritt 1 – Erfassen des AussenpolygonsScreenshot 4: Schritt 2 – Erfassen des Insel/LochpolygonsScreenshot 5: Schritt 3 – Geoprozessing mit ERASE – Löschen des Loches aus dem Aussenpolygon – Ergebnis ist das Donut-PolygonScreenshot 6: Schritt 4 – Geoprozessing mit CLIP – „Ausstanzen“ der Flurstücke mit dem Donut-Polygon als „Maske“Screenshot 7: Ansicht des finalen Ergebnisses Flurstücke mit Insel/Loch ohne weitere Layer
DGGS – Diskrete Globale GitterSysteme – sind Mosaike, die die gesamte Erdoberfläche abdecken und in diskrete Zellen unterteilen (vgl. [1]). Sie dienen der weltweiten Geokodierung, mit ihnen kann man jeden Punkt der Erde referenzieren, neutral und ohne (teilweise nicht vorhandene, fehlerhafte oder missverständliche) Adressdaten. Je feiner eine solches Netz ist, desto genauer wird die Ortsangabe. Im Laufe der Zeit der wurde eine Vielzahl solcher Systeme geschaffen. Das neue QGISL-Plugin „Vgrid“ [3] stellt Euch einen einfachen Zugang zu den verschiedenen DGGS UND jede Menge DGGS Tools zur Verfügung, z. B. die Umwandlung von Polygonen in die Geometrien eines DGGS. Der Code findet Ihr unter GitHub [4].
Animation (Bildquelle [2], [7])
Den Tipp habe ich bei Matt Forrest im LinkedIn [7] gefunden. Bei mir hat die Installation momentan weder auf dem Mac noch unter Windows geklappt, aber das liegt vielleicht auch an mir 😉 Ihr habt vielleicht mehr Erfolg und könnt mir ggf. einen Tipp geben, ich suche weiter …
Und, wie stehst Du zum Shapefile? (Bildquellen: [2], [3])
Aus aktuellen Anlässen habe ich den Beitrag „ESRI-Shape-File: Typische Fehler im Handling“ [1] aktualisiert. Bitte beachtet beim Umgang mit Shapefiles alle dort aufgeführten Fehlerquellen und versucht in jedem Fall, diese zu vermeiden, auch wenn Euer derzeitiges GIS einige dieser typischen Fehler toleriert. Spätestens bei der Weitergabe der Daten oder dem Import in eine GeoDB werden sie Euch einholen 😉