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. ↩︎

Open Data: Kommunale Wärmeplanung in Halle (Saale)

„Wie weit ist die kommunale Wärmeplanung in Deutschland?“ fragt Johann Heller auf LinkedIn [1] und wenn man sich die dort veröffentlichte Karte anschaut, erfährt man, in derzeit 11% der deutschen Kommunen wird diese Wärmeplanung bereits jetzt als abgeschlossen ausgewiesen. Halle (Saale) gehört zu diesen 11%. Die Daten stammen aus dem KWW-Wärmewendeatlas [2].

Screenshot 1: Stand der Kommunalen Wärmeplanung in Deutschland lt. einem Beitrag auf LinkedIn [1]
Screenshot 2: Halle (Saale) im KWW-Wärmewendeatlas [2].

Aber wo eigentlich kann man die Daten zur kommunalen Wärmeplanung in Halle nun öffentlich einsehen?

Die Stadt Halle (Saale) und der städtische Energieversorger EVH haben die Daten in den letzten Wochen auf zwei Plattformen veröffentlicht, zum Einen im HALgis [3] als Extra-Kapitel „Kommunaler Wärmeplan“ und zum Anderen im Open Data Portal der Stadt Halle (Saale) [4], [5]. In diesem Portal stehen die Rohdaten als Downloads in verschiedenen Formaten und als WMS-Dienste zur einfachen Einbindung in jedem modernen GIS zur Verfügung. Und, quasi selbstverständlich, wurden die Daten auch im QGIS-Plugin GeoBasis_Loader [6] unter dem Katalog 5 (Halle) eingearbeitet.

Screenshot 3: Themen zum „Kommunalen Wärmeplan“ im HALgis [2] mit einem Beispiel für die Abfrage von Sachdaten
Screenshot 4: Themen zum „Kommunalen Wärmeplan“ im Open Data Portal der Stadt Halle (Saale) [4], [5]
Animation 1: 30 Themen in Echtzeit mit einem Klick – Laden der Daten der KWP mit dem QGIS-Plugin GeoBasis_Loader [5] unter dem Katalog 5 (Halle)

[1] … https://www.linkedin.com/posts/johann-heller-785aab9a_waeurmeplanung-energiewende-geoai-activity-7453359277332664320-xvcM
[2] … https://experience.arcgis.com/experience/480e8a1a8b564fd8b389e30aaeae4565
[3] … http://geodienste.halle.de/halgis
[4] … http://opendata.halle.de/
[5] … https://webapp.halle.de/opendata.hal/
[6] … https://geobasisloader.de/

GDAL Released: v3.13.0 „Iowa City“

Am Freitag, den 08.05.2026 gab GDAL-Maintainer Even Rouault per Mail [1] bekannt, dass eine neue Version der universellen GDAL-Bibliothek [2] zur Verfügung steht, aktuell ist nun GDAL v3.13.0 „Iowa City“. GDAL steht für Geospatial Data Abstraction Library und ist vor allem als Kommandozeilen-Tool, aber auch als wesentlicher Bestandteil von QGIS bekannt. Mich erfreuen besonders die neuen Möglichkeiten auf der Kommandozeile für automatisierte Prozesse, z. B. gdal vector combine, concave-hull, convex-hull, dissolve und check. Die komplette Liste der Vector-Kommandos findet Ihr in der Dokumentation [3], alle Neuerungen auf GitHub [4].

[1] … https://lists.osgeo.org/pipermail/gdal-dev/2026-May/061612.html
[2] … https://gdal.org/
[3] … https://gdal.org/en/latest/programs/index.html#vector-commands
[4] … https://github.com/OSGeo/gdal/blob/v3.13.0/NEWS.md

QGIS-Tipp: v3.44.10 “Solothurn” (LTR) und 4.0.2 „Norrköping“ für Win, Linux & Mac verfügbar!

Laut Informationen von Jürgen E. Fischer [1] stehen seit vorgestern, dem 06.05.2026 die Pakete für Linux, Windows und Mac die QGIS-Releases 3.44.10 “Solothurn” (LTR) und 4.0.2 „Norrköping“ auf https://qgis.org. [2] zum Download [3] bereit.

Ich habe es vorgestern auf den Mac installiert, alles lief problemlos 🙂

Screenshot 2: Meine QGIS 4.0.2-Installation auf Mac via Homebrew
Screenshot 3: Meine QGIS 4.0.2-Installation auf Mac

[1] … https://norden.social/@jef/116528533968512579
[2] … https://qgis.org
[3] … https://qgis.org/download/

Heute das Webinar: QGIS-Kartenerstellung & der GeoBasis_Loader

Letzte Erinnerung! Heute, 10:00 Uhr findet das Webinar „Geobasisdaten & Kartenerstellung“ [1] der Firma NTI zusammen mit dem #geoObserver statt. Dort zeige ich im ersten Teil das QGIS-Plugin „GeoBasis_Loader“ [2] in Funktion. Außerdem werde ich auch einige neue und geplante Funktionen als Prototyp vorstellen. Im zweiten Teil zeigt ein NTI-Fachkollege, wie im QGIS mit den wunderbaren freien und nun auch via GeoBasis_Loader einfach geladenen Daten eine Karte erstellt werden kann. Das Webinar ist kostenlos, eine Anmeldung ist auch heute noch unter [1] ist möglich.

In meinem Teil dürft Ihr Euch konkret auf folgende Informationen zum GeoBasis_Loader in der aktuellen Version freuen:

  • Vorführung ausgewählter typischer Funktionen
  • Zweck und Anspruch
  • Historie und Team
  • Kataloge und Datenhaltung
  • Nutzungsbedingungen
  • Status, Meldungen, FAQs und Videos auf der Webseite geobasisloader.de [2]
  • Newsletter, Sponsoring und Möglichkeiten zur Mitwirkung
  • Ausblick und quasi „Weltpremiere“ 😉 Vorschau auf den Prototypen für v2.2
  • Installation
Screenshot: Vorschau auf den Prototypen für v2.2 mit Panel für Kataloge, Favoriten, Presets und Einstellungen

[1] … https://www.nti-group.com/de/events/webinare/geobasisdaten-kartenerstellung/
[2] … https://geobasisloader.de

QGIS-Plugin: „GeoPackage Exporter“

Screenshot: Mein Test mit dem „GeoPackage Exporter“ [1] und drei Datensätzen aus dem Open Data Portal der Stadt Halle (Saale) [4]

Einmal in einem QGIS-Projekt eingebettete Themen inkl. der Projektinfomation weiterzugeben ist eine häufig vorkommende, quasi wiederkehrende Aufgabe, vermutlich kennt sie jeder QGIS-Nutzer. Lösungen gab es da schon etliche, nun ist ein neues Plugin aufgetaucht, welches mir recht gut gefällt, der „GeoPackage Exporter“ [1] von Karl Stephan Steinbach. Einfach zu bedienen und alles, also die Daten und deren Präsentation in einem GeoPackage vereint, quasi das Rundum-Sorglos-Paket zur Datenweitergabe 😉 Danke Karl!

Die Liste der Funktionen ist auf GitHub [2] nachzulesen, ich zitiere hier mal:

  • „Drei Speichermodi
    – Einzeldatei: alle ausgewählten Layer in eine einzige .gpkg
    – Multi-Datei: jeder Layer in eine eigene .gpkg
    – Automatische Auflösung von Namensdubletten (StraßenStraßen_2, …)
  • Warnung vor dem Überschreiben bestehender Dateien oder Tabellen
  • Optionales Ersetzen der Quell-Layer im Projekt durch die neuen GeoPackage-Layer (Stil, Name und Position im Layer-Baum bleiben erhalten)
  • Fortschrittsanzeige mit Abbrechen-Knopf bei längeren Exporten
  • Unterstützt Memory-Layer und (optional) alle weiteren Vektor-Layer, inklusive WFS- und OGC-API-Features-Layer mit pro-Layer wählbarer Export-Strategie (Bildschirmausschnitt / Nur Auswahl / Vollständig)“

Ich habe das Plugin für Euch getestet, alles klappt prima. Beim ersten Test gab es noch ein Problem in QGIS 4, ich habe es via GitHub [3] gemeldet und nach dem Wochenende war es gefixt. Als Testdaten nutzte ich übrigens drei Datensätze aus dem Open Data Portal der Stadt Halle (Saale) [4].

[1] … https://plugins.qgis.org/plugins/GeoPackage_Export/
[2] … https://github.com/KSSteinbach/GeoPackage-Export
[3] … https://github.com/KSSteinbach/GeoPackage-Export/issues/1
[4] … https://webapp.halle.de/opendata.hal/

GBL: Der GeoBasis_Loader mit 55 neuen Themen

Screenshot: GeoBasis_Loader – Live-Status [3].

Seit der letzten GBL-Meldung [1] sind weitere 55 neue Themen in den Katalogen des QGIS-Plugins „GeoBasis_Loader“ (GBL) [2] hinzu gekommen. Dabei handelt es sich um:

  • 30 Themen der Kommunalen Wärmeplanung Halle (Saale) als WMS
  • 6 Themen Verwaltungsgrenzen 1:25000 (WFS)
  • 15 Themen zu sächsischen Höhendaten (WFS)
  • 2 Themen zur Flurbereinigung in BW
  • 2 Themen für BRW 2026 in ST (WFS)

Aktualisiert wurden gleichzeitig:

  • ALKIS, BRW in BE
  • AP 10 in NI (WFS)

Damit stehen mit Stand heute 835 Themen im GeoBasis_Loader zur Verfügung. Den aktuellen Stand findet Ihr übrigens immer live im Status [3] und bei der Meldungen [4]..
Danke allen Zuarbeitenden 🙂

[1] … https://geoobserver.de/2026/03/04/geobasis_loader-gbl-update-fuer-die-bkg-pois/
[2] … https://geobasisloader.de
[3] … https://geoobserver.de/qgis-plugin-geobasis-loader/#jsonstatus
[4] … https://geoobserver.de/gbl-aktuelle-meldungen-stoerungen/

Dāvis Viļums: 5 Jahre Radfahrerei gemappt und visualisiert

Via X (ehemals Twitter) [1] bin ich auf einen interessanten Beitrag auf Brilliantmaps [2]. Stell Dir vor, Du fährst dauernd durch Deine Stadt und irgendwann willst Du alle Straßen erfahren haben. Du zeichnest natürlich alles auf und nach fünf Jahren bist Du fertig und lässt uns über Youtube teilhaben. So hat es der in London geborenen Lette Dāvis Viļums getan und in „Cycling through ALL THE STREETS in central London“ [3] beschrieben.

Na, wäre das mal ein Challenge für Hallenser? Wer traut es sich zu? Vielleicht die CyclistInnen vom Asphaltrauschen oder für Laufstrecken die LäuferInnen vom Cierpinski Lauftreff und/oder Social Run? Ich bin gespannt, ob jemand die Herausforderung annimmt 😉

Hier der Original-Tweet [1]:

[1] … https://x.com/BrilliantMaps/status/2048673817036242982
[2] … https://brilliantmaps.com/londons-street-grid-revealed/
[3] … https://davis.vilums.lv/all-the-streets/
[4] … https://www.youtube.com/watch?v=GhTDY1XMNx4
[5] … https://www.youtube.com/watch?v=YLHynbDNsAk

Open Data Berlin: Wirklich zwei WMS-Layer für ein Thema?

ALKIS Berlin: Ein Darstellungslayer vs. 5 Sachdatenlayer in einem WMS, warum?

Also eigentlich dachte ich, ich kenne mich mit OGC-konformen Geodiensten ganz gut aus. Nun bin ich aber in Berlin (IMHO ein echter Open Data Vorreiter!) auf einen im März 2026 aktualisierten ALKIS-WMS [1] gestoßen, den ich in dieser Form noch nicht erlebt habe und eigentlich so auch nicht verstehe. Warum betreibt man einen WMS anders als vom Standard vorgesehen?

Ein WMS zeichnet sich lt. Wikipedia durch folgenden Eigenschaften aus:

„Im Sinne eines verteilten Geoinformationssystems (GIS) besitzt ein WMS nur die Fähigkeit zur Auskunft der notwendigen Metainformation, zur Visualisierung dieser Geodaten und für eine allgemeine Abfrage der zugrundeliegenden Sachdaten.“ [2]

Bekanntermaßen liefert mir ein WMS eine Karte mit GetMap (ein georeferenziertes Bild als PNG, GIF, JPG, TIFF, …) und gleichzeitig auf Anfrage die Sachdaten eines Objektes über einen abgefragten Punkt (Koordinate) in diesem Dienst mit GetFeatureInfo. Des Weiteren können noch die Legende mit GetLegendGraphic und die Eigenschaften mit GetCapabilities abgefragt werden.

In Berlin macht man es nun aber plötzlich anders. Hier werden die Inhalte zur Visualisierung für die Flurstücke, Gebäude, Bauwerke, … in einem Layer gemischt und die Sachdaten getrennt in weiteren fünf Layern, immerhin alles in einem Dienst vorgehalten, einer für die gemischte Karte (GetMap) und die fünf für die Sachdaten (GetFeatureInfo). Aber warum? Das heißt ja für den Nutzer in seinem GI-System immer mindestens zwei Layer laden, einen mit der Karte ohne Sachdaten, um die Geodaten überhaupt zu sehen und den zweiten, eben mit leerer Karte, nur, um die Sachdaten via Identifikation abfragen zu können. Das bringt

  • die Nutzer durcheinander,
  • erhört den Aufwand,
  • senkt die Transparenz,
  • konterkariert IMHO die WMS-Philosophie und
  • ist doch eigentlich total unnötig, oder?

Ich hätte je einen Layer für Flurstücke, einen für Gebäude, Bauwerk, Nutzung, etc. erwartet, jeweils mit Karte und Sachdaten, so wie üblich und in allen anderen Bundesländern auch realisiert, üblicherweise getrennt nach Flurstücken, Gebäuden und tatsächlicher Nutzung. Für GIS-Insider ist das vielleicht gewöhnungsbedürftig, aber machbar, für „normale“ Endkunden ohne spezielle GIS-Kenntnisse im WebGIS wie OpenLayers, Leaflet oder MapLibre eine Zumutung.

Hier die Problematik für das Thema „Flurstücke“ mal bebildert:

Screenshot 1: Die zwei verschiedenen Layer für die gemischte „Darstellung“ und die Flurstücks-„Sachdaten“ im QGIS
Screenshot 2: Nur der Layer für „Darstellung“ leider ohne Identifikationsmöglichkeit
Screenshot 3: Nur der Flurstücks-Layer für „Sachdaten“ leider ohne Karte
Screenshot 4: Nur der Flurstücks-Layer für „Sachdaten“ identifizierbar aber leider ohne Karte
Screenshot 5: Beide Layer für gemischte „Darstellung“ und Flurstücks „Sachdaten“ und nur bei richtiger Aktivierung (blau) auch mit Identifikationsergebnis

Ich habe mich mit einigen Fachkollegen dazu ausgetauscht, keiner hatte eine Idee oder plausible Erklärung. Und was macht man heute, man befragt die KI, meinen Chat dazu findet Ihr in [3]. Aber auch dort bin ich nicht wirklich fündig geworden. Der noch plausibelste Grund für verschiedene Toleranzen sollte bei Flurstücken, Gebäuden, … eher keine Rolle spielen, diese Objekte trifft man per Mausklick im Allgemeinen immer sicher.

Vielleicht können uns die Berliner Kollegen mal auf die Sprünge helfen, warum sie das so (ungewöhnlich) gelöst haben, gern in den Kommentaren. Ich jedenfalls bin gespannt und lerne gern dazu!

Übrigens, über den für mich unverständlichen, weil unterschiedlichen Umgang mit inhaltlich gleichen Themen in den einzelnen Bundesländern habe ich in meinem Vortrag „Open Data in D: Perfekte Idee, halbherzige Umsetzung? Ein Erfahrungsbericht.“ auf der FOSSGIS 2025 in München [4], [5] das erste Mal berichtet, dann immer mal wieder.

[1] … https://gdi.berlin.de/services/wms/alkis?SERVICE=WMS&REQUEST=GetCapabilities
[2] … https://de.wikipedia.org/wiki/Web_Map_Service
[3] … https://geoobserver.de/download/KI_ALKIS_WMS_Berlin_ChatGPT52_20260428.pdf
[4] … https://www.youtube.com/watch?v=bVLV-df5O6I
[5] … https://geoobserver.4lima.de/downloads/myPresentations/FOSSGIS_2025_ OpenDataGermany_Erfahrungsbericht_Elstermann_v02.pdf

TerraInk: Coole DIY-Poster und Wallpaper mit OSM-Daten

Abbildung 1: Screenshot meiner TerraInk [1] Testsitzung – eine HALLE-Karte mit Standardeinstellungen und eine hinzugefügten Symbol (Marker)

Wer schon immer mal attraktive Poster oder Bildschirmhintergründe mit freien Geodaten kreieren wollte, hat es jetzt wirklich einfach, mit TerraInk [1] ist das schnell und unkompliziert getan. Einfach die Lokation eingeben, Thema, Layout und Stile festlegen und dann die Wunschkarte mit Inhalten anreichern, also mit Markern, Layern und Routen. Aber auch ohne eigene Anpassungen trefft Ihr schon mit den Grundeinstellungen eine richtige Wahl und es kommen coole Karten dabei heraus. Genutzt werden die bekannten freien OpenStreetMap-Daten.

Abbildung 2: Das Ergebnis meiner TerraInk [1] Testsitzung als PNG
Abbildung 3: Screenshot einer Teams-Sitzung mit dem Ergebnis meiner TerraInk [1] Testsitzung als Hintergrund

[1] … https://terraink.app/