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

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

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/

DrawonMaps: OSM & picture@map

Abbildung 1: Screenshot – Mein Test mit DrawonMaps [1] – die Brille [2] und die OSM-Daten von Halle (Saale)

Was man doch so alles mit Geodaten machen kann, heute eine Idee, auf die man selbst vielleicht so nicht gekommen wäre? Man nehme OSM-Daten und ein am besten kontrastreiches Bild und erzeuge mit den Kontoren des Bildes eine OSM-Straßenkarte. Über den praktischen Nutzen kann man sich ggf. mal austauschen, aber technologisch für mich jedenfalls: eindeutig faszinierend. Im Tweet auf X (ehem. Twitter) [1] liest man Folgendes zum Map Tracer DrawonMaps [3]

„Was wäre, wenn man JEDES beliebige Bild mit echten Stadtstraßen zeichnen könnte?
Neuestes Experiment: Lade ein beliebiges Bild hoch → die App erkennt dessen Ränder → dann zeichnet ein autonomer Agent die Konturen nach und füllt das Bild mit tatsächlichen Straßen aus OpenStreetMap aus.
Der Agent zeichnet die Umrisse und füllt den Innenbereich grün aus.
Die Stadt selbst wird zu deiner Leinwand.
Entwickelt mit React 19 + DeckGL + MapLibre + Overpass API“
[1]

Ich habe es mal kurz für Euch getestet: Mein Testbild eine Warsteiner-Retro-Brille [2], meine Testumgebung die OSM-Daten, natürlich von Halle (Saale).

Abbildung 1: Mein Testbild – die Brille [2]
Animation: Mein Test mit DrawonMaps [1] – die Brille [2] und die OSM-Daten von Halle (Saale)

[1] … https://x.com/AhmedShahnab/status/2048371517692452974
[2] … https://barmeister24.de/media/image/product/13727/lg/warsteiner-bier-retro-brille-partybrille-sunglasses-sonnenbrille-uv-400~2.webp
[3] … https://shahnab.github.io/DrawonMaps/

Cool: Dein Name aus Satellitenbildern

Screenshot: „geoObserver“ in der Anwendung „Your Name In Landsat“ [1].

Zum Wochenende mal was Schönes. Deinen Namen kannst Du a) mit vielen Buchstaben in verschiedenen Schriften und b) durch das Zusammensetzen von Bildern schreiben. Aber wie wäre es dann, ihn mal wie in b) aus echten Satellitenbildern zu kreieren? Das NASA’s Kennedy Space Center zeigt auf X (ehem. Twitter) eine Lösung, die Anwendung „Your Name In Landsat“ [1]. Gib einfach mal Deinen Namen oder irgendeine andere gewünschte Zeichenkette ein und freu Dich über die generierten Bilder. Übrigens, wenn Du es mehrmals startest, kommen auch verschiedene Lösungen raus. Ich habe meine ersten fünf „geoObserver“-Varianten mal animiert:

Animation: Meine „geoObserver“-Varianten animiert

Mehr Information zum Landsat-Programm findet Ihr auf Wikipedia [2] und bei der NASA [3] selbst. Hier der Original-Tweet [4]:

[1] … https://science.nasa.gov/specials/your-name-in-landsat/
[2] … https://de.wikipedia.org/wiki/Landsat
[3] … https://science.nasa.gov/mission/landsat/
[4] … https://x.com/nasakennedy/status/2047037100894147066

Webinar: QGIS-Kartenerstellung & der GeoBasis_Loader

Heute mal wieder ein Veranstaltungstipp, diesmal quasi in eigener Sache: Zusammen mit der Firma NTI führen wir ein Webinar „Geobasisdaten & Kartenerstellung“ [1] durch. 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 via GeoBasis_Loader einfach geladenen Daten eine Karte erstellt werden kann. Das Webinar ist kostenlos, eine Anmeldung unter [1] ist erforderlich.

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