Gastbeitrag: Wenn eine Karte mehr als eine Karte ist

Heute wieder mal ein Gastbeitrag, diesmal von meinem Fachkollegen Clemens Schenke-Hildebrandt, Geograph, GIS-Consultant und passionierter Rennradfahrer. Danke Clemens!

Wenn eine Karte mehr als eine Karte ist

Beim Fahrradverein Veloclub Asphaltrauschen e.V. (VCA) tragen die Vereinsmitglieder ein Trikot, auf dem Linien und Höhen zu erkennen sind, die eine abstrakte Landschaft auf einer Karte zu bilden scheinen. Dabei handelt es sich aber nicht um einen Stadtplan von Halle (Saale), sondern einen Joyplot der Saalestadt. Wer Halle kennt, erkennt darin nicht sofort jede Straße, aber etwas anderes Markantes: die Saaleaue, die Hochflächen, die Kanten der Stadt – das Gefühl eines Ortes.

Abbildung 1: Joyplot von Halle (Saale) auf schwarzem Hintergrund. Weiße, horizontal versetzte Höhenprofil-Linien bilden die Topografie der Stadt ab

Für mich ist dieses Trikot deshalb ein guter Einstieg in die Geschichte von Geodaten beim VCA.

Die Grafik, der Joyplot, war nicht als klassischer Vereinsaufdruck gedacht. Sie war der Versuch, Halle aus Daten heraus sichtbar zu machen und daraus ein Motiv zu entwickeln, das zum Verein passt und die tiefe Verbundenheit zur Saalestadt widerspiegelt. Die Fahrrad-Community bewegt sich ständig durch die Stadt und das Umland. Warum sollte ihre visuelle Sprache dann nicht aus genau diesem Raum entstehen?

Die ausführlichere Geschichte zum Trikotmotiv steht auf asphaltrauschen.cc: „Unknown Places“ – das Veloclub Asphaltrauschen Trikot. Die Höheninformationen für den Joyplot stammen aus dem Digitalen Geländemodell DGM11 Sachsen-Anhalt.

Angefangen hat diese Verbindung aber einfacher.

Im ersten Corona-Jahr fehlte der lokalen Fahrrad-Community das, was sonst fast selbstverständlich war: gemeinsame Ausfahrten, Training, Treffen, Events und kleine Wettkämpfe. Aus dieser Lücke entstand mit dem Spring Break ein Event mit einer einfachen Idee: Strava-Segmente2 wurden zu kleinen Etappen und jede Woche kam eine neue Herausforderung dazu. Die Ergebnisse wurden manuell zusammengetragen.

Aus heutiger Sicht war das technisch noch ziemlich bodenständig. Keine Datenbank, keine API-Automatisierung, keine große Webanwendung. Ich kopierte Ranglisten aus Strava, pflegte Ergebnisse in Excel und baute eine einfache Übersichtskarte. Aber genau dort begann etwas, das später wichtig wurde: Bewegungsdaten waren nicht nur private Trainingsaufzeichnungen, sie wurden zu Material für ein gemeinsames Spiel.

Der nächste größere Schritt war ein Alleycat.

Das klassische Alleycat kommt aus der Fahrradkurierkultur: Checkpoints, Orientierung, Tempo, eigene Routenwahl – vergleichbar mit einer Schnitzeljagd. Für unseren Kontext wurde daraus ein kontaktloses 24-Stunden-Rennen, bei dem Städte, Orte und markante Punkte zu Checkpoints wurden. OpenStreetMap lieferte die Grundlage. Um diese Checkpoints wurden unterschiedliche Radien definiert und wer mit seinem GPX-Track durch diese Bereiche fuhr, sammelte Punkte.

Animation 1: Die Animation zeigt Halle (Saale) auf einer hellen Basemap und entwickelt schrittweise die Checkpoint-Zonen und Checkpoints des Alleycat

Das war für mich der erste Augenblick, in dem GIS beim VCA nicht mehr nur eine begleitende Karte war, sondern wesentlicher Teil der Spielmechanik wurde.

Die Auswertung lief damals noch in QGIS: Checkpoints puffern, GPX-Tracks schneiden, Treffer prüfen, Punkte zusammenrechnen. Ein gutes Bild dafür ist ein Screenshot aus dem QGIS Model Builder: GPX-Dateien und Checkpoints laufen dort als einzelne Verarbeitungsschritte zusammen. Für mich fühlte sich das damals wie Magie an, weil nicht mehr jeder Schritt einzeln nacheinander angeklickt werden musste, sondern der Ablauf als Modell sichtbar und wiederholbar wurde.

Abbildung 2: QGIS Model Builder im dunklen Theme mit dem Modell „Auswertung_SBA“. Zu sehen sind die Eingaben „GPX“ und „Checkpoints“ sowie Verarbeitungsschritte wie „Nach Position selektieren“, „Gewählte Objekte exportieren“ und „Attribute nach Position verknüpfen (Zusammenfassung)“. Das Modell zeigt, wie GPX-Tracks und Checkpoints zu exportierten Treffern und einer Summenwertung verarbeitet werden

Nichts davon war als großes Produkt gebaut. Aber es zeigte, wie stark sich Radfahren, offene Geodaten und einfache räumliche Regeln verbinden lassen. Der Joyplot von Halle kam später aus einer anderen Richtung. Nicht mehr: Wer fährt wo entlang? Sondern: Wie kann eine Stadt als Datenbild aussehen?

Ein Joyplot besteht aus vielen versetzten Profilen und für Halle bedeutete das: Höhendaten abtasten, Linien erzeugen, die Topografie abstrahieren. So wurden die Saaleaue, die nördlichen Felskanten, die Dölauer Heide und die Hochflächen der Stadt nicht als exakte Karte gezeigt, sondern als Rhythmus.

Animation 2: Entstehungsprozess des Joyplots von Halle (Saale). Die Animation beginnt mit der Stadtgrenze und einer Markierung in Halle und entwickelt schrittweise die abstrahierten Höhenlinien, aus denen der Joyplot entsteht.

Als daraus die Idee für ein Trikotmotiv entstand, veränderte sich die Rolle der Geodaten noch einmal: Sie waren nicht mehr nur Werkzeug für Auswertung oder Orientierung, sie wurden Teil einer Vereinsidentität.

Diese Entwicklung finde ich bis heute spannend.
Geodaten wirken durch Koordinaten, Layer, Projektionen, Attribute und Formate oft technisch. Im Alltag eines Fahrradvereins zählt aber etwas Anderes: In der Nutzung muss eine Karte nicht nur korrekt, sie muss anschlussfähig sein. Sie muss einen Anlass tragen können, eine Ausfahrt erklären, eine Erinnerung festhalten oder ein Gefühl für einen Ort transportieren.

Beim VCA ist daraus nach und nach ein kleiner Werkzeugkasten entstanden.
Mal geht es um Strava-Segmente und Rankings, dann um Checkpoints und GPX-Tracks oder um Höhendaten, OSM-Daten oder reduzierte Routengrafiken. Später kamen Python, eigene Skripte und automatisierte Workflows dazu. Aber der Ausgangspunkt war nicht Technik um der Technik willen. Der Ausgangspunkt war immer eine konkrete Frage aus der Community:

  • Wie halten wir Verbindung, wenn wir nicht gemeinsam fahren können?
  • Wie machen wir aus einer Route ein Spiel?
  • Wie macht man eine Stadt zur Vereinsidentität, zu einem Trikotmotiv?
  • Wie zeigen wir, was unsere Ausfahrten unterscheidet?
  • Genau an dieser Stelle treffen sich für mich Radkultur und GIS.

Geodaten sind beim Veloclub Asphaltrauschen keine neutrale Hintergrundkarte. Sie sind ein Mittel, um Bewegung, Ort, Gemeinschaft und Gestaltung zusammenzubringen.

Aus diesem Werkzeugkasten sind später vier sehr unterschiedliche Kartenlinien entstanden: Social Ride, FLINTA*-Ride, Schotterbande und Temporunde. Jede dieser Runden hat ihren eigenen Charakter, und jede Karte versucht, diesen Charakter sichtbar zu machen. Aber das ist eigentlich schon die nächste Geschichte.

Abbildung 3: Foto vom VCA-Flohmarkt: Mehrere großformatige VCA-Grafiken hängen an einer hellen Holzwand. Im Mittelpunkt ist eine grün-beige Kartengrafik mit weißen Routenlinien zu sehen; links und rechts hängen weitere farbige Kartenmotive. Foto: Friederike Schöppe

Zum Autor:
Clemens Schenke-Hildebrandt ist Geograph, GIS-Consultant und Product Owner mit Schwerpunkt auf Geodaten, WebGIS, Kartenanwendungen und produktnaher Softwareentwicklung. Beim VCA verbindet er Radkultur, Community-Projekte und Geodatenarbeit, unter anderem in Karten, Visualisierungen und GPS-basierten Challenges.
Kontakt: https://linktr.ee/clemensschenke

  1. DGM1 steht für Digitales Geländemodell mit einer Rasterweite von 1 m. Für Sachsen-Anhalt stellt das Landesamt für Vermessung und Geoinformation Sachsen-Anhalt das DGM1 kostenfrei bereit: https://www.lvermgeo.sachsen-anhalt.de/de/gdp-dgm1.html. ↩︎
  2. Ein Strava-Segment ist ein festgelegter Abschnitt auf einer Straße, einem Weg oder einer Strecke, für den Strava automatisch Zeiten aus aufgezeichneten Aktivitäten vergleicht. Wer eine Fahrt oder einen Lauf hochlädt und durch dieses Segment kommt, erscheint mit der eigenen Zeit in einer Rangliste. Für den Spring Break konnten solche Segmente deshalb wie digitale Etappen genutzt werden: Die Strecke war klar definiert, die Zeitmessung kam aus den GPS-Aufzeichnungen, und die Ergebnisse mussten anschließend nur noch ausgewertet werden. ↩︎

PyQgis: Neues Youtube-Video zu NDVI & Co

Über die Berechnung des NDVI (Normalized Difference Vegetation Index) habe ich erst neulich in „NDVI: Realisierung mit QGIS, Standard & Grenzen“ [1] geschrieben. Nun hat Ivo Partschefeld alias PyQGIS (@PyQgis) ein neues interessantes Video mit einer wunderbaren Anleitung auf Youtube „Vegetationsindizes aus Orthophoto (DOP) mit QGIS Rasterrechner berechnen“ [2] veröffentlicht. Es zeigt dort z.B. NVDI und SAVI/BBVI, jeder Schritt wird gut erklärt und ist einfach nachzuvollziehen. Einfach mal anschauen, es lohnt sich, Danke Ivo!

[1] … https://geoobserver.de/2026/03/16/ndvi-realisierung-mit-qgis-standard-grenzen/
[2] … https://www.youtube.com/watch?v=DN25va7ORhQ

QGIS-Tipp: „Cluster Generator“ am Beispiel von Postleitzahlen

Mitunter kann man viel Zeit benötigen, um Daten zu prüfen. Eine häufig verwendete Methode ist dabei, die Objekte mit demselben Attributwert zu ermitteln und deren räumlichem Zusammenhang zu berechnen und zu visualisieren. Das kann dann u. U. wieder viel Zeit sparen. Man erstellt dazu s. g. Clusterflächen. Eine wirklich praktikable Lösung dafür liefert das neue QGIS-Plugin „Cluster Generator“ [1]

Screenshot 1: Mein Test, 34098 Punkte mit „plz“-Attribut geclustert

Ich habe das Plugin mal kurz angetestet, die Bedienung ist einfach und selbsterklärend. Genutzt habe ich dazu unseren Postleitzahlen- (PLZ-) Datenbestand. Der automatisch einmal pro Nacht generierte Datenbestand hat vfür Halle (Saale) momentan 34098 Punkte mit PLZen. Die Clusterfunktion darauf angewendet liefert recht schnell die Clusterflächen mit den PLZ-Bereichen und färbt und beschriftet diese automatisch nach dem ausgewählten Attributfeld, hier also „plz“. Das Formular und die Ergebnisse findet Ihr in Screenshot 1.

Ein wunderbarer, positiver Nebeneffekt. Man findet so auch ganz schnell, quasi nebenbei die fehlerhaften Objekte, bei meinem Test die Punkte mit dem Eintrag „plz=NULL“. Ich habe diese NULL-Flächen mal etwas hervorgehoben. Für die Punkte in diesen Flächen sind die PLZ-Attributwerte also zeitnah zu aktualisieren, von „NULL“ auf die tatsächliche PLZ oder die Punkte an sich sind zu überprüfen.

Screenshot 2: Fehlerhafte Punkte mit „plz=NULL“ in Extra-Clusterinseln

[1] … https://plugins.qgis.org/plugins/cluster_generator/
[2] … https://www.linkedin.com/posts/senolbaskaya_qgis-gis-plugin-activity-7447516085979136000-CzPq

NDVI: Realisierung mit QGIS, Standard & Grenzen

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:

NVDI = NIR-Kanal - Rot-Kanal / NIR-Kanal + Rot-Kanal


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)
  • starker Schattenwurf
  • unterschiedliche Kamera-Sensoren
  • vergleichbare Fotos? unterschiedliche Überfliegungssituationen (anderes Überfliegungsdatum, anderer Sonnenstand, …), Normierung 0.7 vs. 0.7
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 wird
Screenshot 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].

[1] … https://de.wikipedia.org/wiki/Normalized_Difference_Vegetation_Index
[2] … https://www.lvermgeo.sachsen-anhalt.de/de/gdp-open-data.html
[5] … https://doi.org/10.5281/zenodo.11102543
[4] … https://x.com/mashfordmahute/status/2030910298459193528
[5] … https://www.indexdatabase.de/

Update: Vereinfachung bereits in der Geo-Datenbank

In meinem vorgestrigen Beitrag [1] gab es wohl einige Fragen [2] bzgl. meiner Ausführungen bei der gemeinsamen Nutzung der vereinfachten Daten in einer Datenbank. Da vermutlich nicht alle die Diskussion verfolgen, versuche ich jetzt noch einmal zu präzisieren. Per SELECT wird die Vereinfachung natürlich nur einmalig für den Anfragenden berechnet, nur ihm/ihr steht das Ergebnis zur Verfügung. Nutzt man die Funktionen hingegen, um die Daten innerhalb der Datenbank zu vereinfachen und das Ergebnis in diese zurück zuschreiben, z. B. mit CREATE, stehen die Ergebnisse dann allen berechtigten Nutzern zur Verfügung.
Hier ein Beispiel, die Eingangsdaten werden mit einer Toleranz von 10m mit der CLEAN-Funktion (ST_CoverageClean) [3] vereinfacht:

-- Clean the coverage, merging gaps with width <= 1
CREATE TABLE test.test_1_poly_10 as SELECT id, ST_CoverageClean(geom, 10) over() AS GEOM FROM test.test_1_poly;

Screenshot 1: Der Eingangsdatenbestand „test_1_poly“ mit typischen Geometriefehlern wie Lücken und Überschneidungen
Screenshot 2: Der Ergebnisdatenbestand „test_1_poly_10“ mit CLEAN (ST_CoverageClean) bearbeitet ohne die typischen Geometriefehlern wie Lücken und Überschneidungen in perfekter Topologie
Screenshot 3: Eingangs- und Ausgangs-Datenbestand inkl. SQL-Statement

[1] … https://geoobserver.de/2026/01/13/vereinfachung-bereits-in-der-geo-datenbank/
[2] … https://geoobserver.de/2026/01/13/vereinfachung-bereits-in-der-geo-datenbank/#comment-30646
[3] … https://postgis.net/docs/manual-3.7/de/ST_CoverageClean.html

Vereinfachung bereits in der Geo-Datenbank

Bitte beachtet auch das Update vom 15.01.2026.

Screenshot (Bildquelle [1])

Wer mit Geodaten zu tun hat, kommt oft in die Situation, diese Daten mit geeigneten Werkzeuge zu vereinfachen. Oft wird dazu der lokale GIS-Client mit Funktionen wie Clean oder Simplify genutzt. Das heißt aber auch, dass die Clienten auch bei Nutzung einer Datenbank jeweils nur für sich selbst diese Arbeiten ausführen und ggf. kein Anderer davon partizipiert. Die Datenbank selbst mit ihren spatialen Erweiterungen bietet heutzutage jede Menge leistungsfähiger Funktionen für diese Aufgaben an. Was spricht also dagegen, diese auch gleich dort zu nutzen, z. B. um Abfragen performanter zu machen oder Datenbestände zentral zu vereinfachen? Einen lesenswerten Beitrag dazu „PostGIS Performance: Simplification“ [1] von Paul Ramsey habe ich via X (ehemals Twitter) [2] im crunchydata-Blog [3] gefunden. Dort werden eine Vielzahl nützlicher Vereinfachungs-Funktionen direkt in der Datenbank, aber auch ihre Grenzen vorgestellt:

[1] … https://www.crunchydata.com/blog/postgis-performance-simplification
[2] … https://x.com/crunchydata/status/1998497697993498791?s=20
[3] … https://www.crunchydata.com/blog

Geoprocessing: Donut-Polygone mit ERASE erzeugen

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 – Prinzipdarstellung
Screenshot 2: Ausgangssituation – Die Flurstücke im Bearbeitungsgebiet
Screenshot 3: Schritt 1 – Erfassen des Aussenpolygons
Screenshot 4: Schritt 2 – Erfassen des Insel/Lochpolygons
Screenshot 5: Schritt 3 – Geoprozessing mit ERASE – Löschen des Loches aus dem Aussenpolygon – Ergebnis ist das Donut-Polygon
Screenshot 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

GDAL: Rasterzonale Statistiken berechnen

GDAL [1] als ultimative Geo-Konvertierungs-Bibliothek dürften die meisten ganz sicher kennen und nicht umsonst ist GDAL wesentlicher Bestandteil vieler GI-Systeme. Aber wusstet Ihr, dass man mit GDAL auch geoprozessieren kann. Neulich las ich dazu auf LinkedIn einen Beitrag zur Berechnung von Rasterzonalen Statistiken [2] von Krzysztof Dyba [3]. Man nehme also Rasterdaten und einen Vektordatenbestand, z. B. Stadtteile und kann mit GDAL beispielsweise den Mittelwert aller Pixel des Rasters in den Stadtteilgrenzen berechnen lassen. Wunderbar für automatisierte Prozesse. Alle Details findet Ihr in der GDAL-Dokumentation [4].

Screenshot: Der LinkedIn-Beitrag [2] von von Krzysztof Dyba [3].

[1] … https://gdal.org/
[2] … https://www.linkedin.com/posts/krzysztof-dyba_gis-geospatial-gdal-activity-7385355582204956673-wXwE/
[3] … https://www.linkedin.com/in/krzysztof-dyba/
[4] … https://gdal.org/en/latest/programs/gdal_raster_zonal_stats.html

QGIS-Tipp: Farbiger Stadtplan grau maskiert?

Neulich am GIS-Helpdesk: „Wie kann man im QGIS einen Ausschnitt im farbigen Stadtplan in der Farbe belassen und den Rest des gleichen Stadtplanes grau einfärben?“

Screenshot 1: Das Ziel, in einem farbigen Stadtplan ein Stadtviertel farbig hervor gehoben, der Rest in Graustufen umgewandelt
Screenshot 1: Das Ziel, in einem farbigen Stadtplan ein Stadtviertel farbig hervor gehoben, der Rest in Graustufen umgewandelt

Variante 0: Farbigen Ausschnitt in Extra-Raster-Datei exportieren, georeferenzieren, Transparenzen für Rand aktivieren und als neuen Layer einfügen

Variante 1: Farbigen Ausschnitt via QGIS-Rasterfunktion „Raster / Extraktion / Raster auf Layermaske zuschneiden“ erzeugen und als neuen Layer einfügen

Beides war nicht so recht zufriedenstellend, zu aufwändig, ggf. viel fehleranfällige Handarbeit, zu viele Extradaten, mitunter sogar Qualitätsverluste, … so dass ich die FOSSGIS-Liste [1] dazu befragt habe. Ergebnis:

Variante 2: Dynamischste, etwas gewöhnungsbedürftige aber elegante Lösung ohne Extra-Daten. Der Vorteil: Jede Änderung an den Daten, also Stadtplan und/oder Maske ist sofort on the fly sichtbar. Der entscheidende Tipp kam aus dem Schwarmwissen der FOSSGIS-Liste, vgl. [2]. Hier (m)ein „Kochbuch“

Schritt 1: Laden der Datenbestände: a) die Topografische Karte, hier der freie WMS „TopPlusOpen farbig (WMS)“ und b) der Stadtviertelgrenze, hier „Stadtviertel Doelau“
Schritt 2: Anlegen einer Kopie der Topografische Karte, hier „TopPlusOpen farbig (WMS )“ zu „TopPlusOpen farbig (WMS ) Kopie“
Schritt 3: Anlegen einer Kopie der Stadtviertelgrenze, hier „Stadtviertel Doelau“ zu „Stadtviertel Doelau Kopie“
Schritt 4: Gruppieren von „Stadtviertel Doelau“ und „TopPlusOpen farbig (WMS ) Kopie“, hier „group1“

Screenshot 2: Schritte 1 … 4
Screenshot 2: Schritte 1 … 4

Schritt 5: „TopPlusOpen farbig (WMS ) Kopie“ grau einfärben

Screenshot 3: Schritt 5
Screenshot 3: Schritt 5

Schritt 6: In den Eigenschaften der „group1“ die Option „Layer als Gruppe zeichnen“ aktivieren

Screenshot 4: Schritt 6
Screenshot 4: Schritt 6

Schritt 7: In den Eigenschaften von „Stadtviertel Doelau“ „Invertiertes Polygon“ wählen und im Mischmodus bei Layer „Darunter maskieren“ einstellen

Screenshot 5: Schritt 7
Screenshot 5: Schritt 7

Schritt 8: „Stadtviertel Doelau Kopie“ entsprechend eigener Vorstellungen symbolisieren, hier mit einer einfachen etwas dickeren schwarzen Linie

Screenshot 6: Schritt 8
Screenshot 6: Schritt 8

[1] … https://lists.fossgis.de/pipermail/fossgis-talk-liste/2025-September/013446.html
[2] … https://lists.fossgis.de/pipermail/fossgis-talk-liste/2025-September/013448.html

Buchtipp: „Introduction to GIS Programming“ – jetzt auch in Deutsch

Screenshots: Die Cover „Introduction to GIS Programming – A Practical Python Guide to Open Source Geospatial Tools [1] im Original und der deutschen Version

Für alle, die sich mit GIS-Programmierung im Open Source Umfeld beschäftigen, ist das neue Buch „Introduction to GIS Programming – A Practical Python Guide to Open Source Geospatial Tools von Professor Dr. Qiusheng Wu [1] vielleicht ein Tipp. Eine Vorschau auf die Inhalte findet Ihr im Table of Contents [2], [3]. Schaut mal rein, es lohnt sich! Und trotz guter Erfahrungen mit der KI ist es für mich ein gute Sache, auch mal (wieder) ein richtiges Buch zu benutzen 😉
Übrigens, gestern kam die Nachricht [5], dass die Publikation jetzt auch in deutscher Sprache verfügbar ist.

[1] … https://gispro.gishub.org/
[2] … https://gispro.gishub.org/#table-of-contents
[3] … https://gispro.gishub.org/book-toc.pdf
[4] … https://x.com/giswqs/status/1938753720621109432
[5] … https://x.com/giswqs/status/1944407455632376100