Neues QGIS-Plugin: Deutschlandweite Flurstückssuche!

Screenshot: Mit der  „Flurstückssuche DE“ [1], [2] ein Flurstück gesucht und gefunden, mit dem „GeoBasis_Loader“ ** [3] die Karteninfhalte ergänzt, einfacher geht es nicht 😉

Am 23.07.2026 wurde in das QGIS Plugin Repository ein bemerkenswertes Plugin eingestellt. Das QGIS-Plugin „Flurstückssuche DE“ [1], [2] von David Koster unterstützt die Suche von Flurstücken auf Basis amtlicher Geodaten direkt im QGIS über das Gebiet der Bundesrepublik*. Erstmals ist es in einem Plugin möglich, bundesweit zu suchen, bisher gab es diese Funktionalität nur für ausgewählte Bundesländer. Damit ist das Plugin eine ideale Ergänzung zum „GeoBasis_Loader“ [3], welcher hier die deutschlandweiten* offenen Liegenschaftsdaten (ALKIS) leicht zugänglich machen kann. Die Flurstückssuche DE basiert auf den von (fast*) allen Bundesländern frei zur Verfügung gestellten ALKIS-WFS. Die Bedienung ist denkbar einfach, man kann über drei Varianten die Flurstücks-Nr. eingeben und suchen:

  • Gemarkungsnummer / Flur / Flurstück
  • Gemarkungsname / Flur / Flurstück
  • Flurstückskennzeichen (20-stellig) – Beispiel: "036518007001790027__"

Selbstverständlich ist auch der umgekehrte Fall vorgesehen, die „Inverse Suche“, quasi die Identifikations-Funktion, einfach in die Karte auf das interessierende Flurstück klicken und die Flurstücksdaten erfahren.

Das Plugin läuft unter QGIS3/Qt5 und QGIS4/Qt6. Details zur Flurstückssuche DE findet Ihr auch im FOSSGIS 2026-Vortrag von David als Folien [4] oder Video-Mitschnitt [5], das Plugin ist natürlich Open Source, der Code ist auf GitHub [6] einsehbar. Übrigens, ich durfte das Plugin schon frühzeitig mit testen, nun ist Euer Feedback gefragt. IMHO großartiges Plugin, Danke David!

* … nur Bayern blockiert hier immer noch entgegen den geltenden Regeln
** … der Geobasis_Loader hier als Preview auf die Version 2.2
[1] … https://www.flurstueckssuche.de/
[2] … https://plugins.qgis.org/plugins/Flurstuecksuche_de/
[3] … https://geobasisloader.de
[4] … https://www.flurstueckssuche.de/files/Flurstückssuche_in_QGIS_FOSSGIS.pdf
[5] … https://www.youtube.com/watch?v=Ycrb4q1YrHk
[6] … https://github.com/ladexyz/flurstueckssucheDE

QGIS: KI-Objektkennung aus Luftbildern mit „AI Segmentation“

In letzter Zeit habe ich immer wieder über die KI-gestützte Objekterkennung aus Luftbildern gelesen. Jetzt ist ein neues QGIS-Plugin „AI Segmentation“ [1] von TerraLab im QGIS Plugin Repository [2] erschienen und ich habe es am Wochenende mal getestet. Ich habe vorher noch nie selbst eine KI zur Objekterkennung aus Luftbildern verwendet, es war sozusagen mein erstes Mal 😉

Installation und Anmeldung waren unkompliziert und funktionierten tadellos. Wie beschrieben können Rasterdaten aller Art genutzt werden, ich habe mich für die DOP 20 auf dem Open Data Portal Sachsen-Anhalt entschieden, natürlich mit den GeoBasis_Loader [3] ins QGIS geladen. Dann noch schnell ein Rechteck für den interessierenden Bereich markiert und die Erkennung gestartet, in meinem Fall für Gebäude und Bäume. Die Ergebnisse werden in einem GeoPackage gespreichert und sind so schnell weiter ver- und bearbeitbar.

Screenshot 1: Mein Test bei den Identifikation von Gebäuden Bäumen im Pauslusviertel in Halle (Saale).

Hier meine Test-Ergebnisse:

  • Auf den ersten Blick plausible Ergebnisse und erstes Staunen, unscharf Ersterfassung möglich, Verfeinerung wünschenswert
  • Auf den zweiten und kritischen Blick: einige Unschärfen, z. B. bei Gebäuden (nicht exakte Geometrien und fehlende Erkennung von Innenhöfen) und bei Bäumen (teilweise werden Baumschatten als Bäume interpretiert). Bei der manuellen Segmentierung kann man ja einige Fehler quasi händisch ausschließen
  • Interssant wäre, wie sich das Modell weiter entwickelt und auf welche Ergebnisse andere Verfahren kommen. Wer Lust hat, hier ist das GeoPackage [4], vielleicht könnt Ihr ja mal mit Euern Modellen testen und uns die Ergebnisse mitteilen. Gerade Niedersachsen [5] scheint man da besonders weit zu sein. Danke!
Screenshot 2: (1) … Innenhöfe unberücksichtigt, (2) … falsche Gebäude-Geometrie, (3) … Baumschatten als Bäume interpretiert

[1] … https://terra-lab.ai/de/ai-segmentation
[2] … https://plugins.qgis.org/plugins/AI_Segmentation/
[3] … https://geobasisloader.de
[4] … http://geoobserver.4lima.de/downloads/ai_segmentation.gpkg.zip
[5] … https://geoobserver.de/2024/04/02/deep-learning-ki-gebaudeerkennung-am-lgln/

GeoBasis_Loader: 23 neue Themen verfügbar

Im QGIS-Plugin „GeoBasis_Loader“ [1] sind seit der letzten Meldung einige neue Themen hinzu gekommen, z. B. die Hochwasserdaten für Sachsen, Feldblockdaten für Brandenburg und Sachsen-Anhalt und Themen des DWD. Damit sind jetzt 856 Themen verfügbar, die aktuellen Änderungen findet Ihr wie immer unter Meldungen & Störungen [2] und Status [3]. 

[1] … https://geobasisloader.de/
[2] … https://geoobserver.de/gbl-aktuelle-meldungen-stoerungen/
[3] … https://geoobserver.de/qgis-plugin-geobasis-loader/#jsonstatus

Aufruf: Hochwasser-Daten für den Geobasis_Loader gesucht!

Symbolfoto (Bildquelle: Chris Gallagher auf Unsplash)

Das Hochwasser im Ahrtal ist nun genau fünf Jahre her und wir werden durch entsprechende Beiträge in der Medien wieder mal daran erinnert. Auch daran, sich mehr um die Hochwasser- und Katastrophenschutz-Problematik zu kümmern, am besten jeder in seinem Bereich, zeitnah. Der gestrige Beitrag in der ARD „Allein in der Flut“ [1] hat da was mit mir gemacht, schwer verdaulicher, sehr persönlicher Stoff, der uns auch vor Augen führt, dass vieles vermeidbar war. Und es stellt sich sofort wieder die Frage: Sind wir heute auch genügend vorbereitet?

Für mich der Anlass, gleich mal zu schauen, welche Daten zu Hochwasser-Gefährdung derzeit im Geobasis_Loader [2] verfügbar sind. Und, es sind tatsächlich nicht sehr viele. Neben den HQ200, HQ100 und HQ10 in Sachsen-Anhalt steht nur noch die Starkregenkarte zur Verfügung, eigentlich bundesweit, aber leider sind noch nicht alle Bundesländer mit ihren Daten integriert.

Und weil der Status Quo nun mal so ist, bitte ich Euch heute hiermit, falls Ihr im Open Data Sinne freie Geodienste zum Thema Hochwasser, sendet sie mir zu, ich werde sie zeitnah in den GeoBasis_Loader integrieren. Die Vorgehensweise ist unter „Mitmachen & Helfen“ [3] auf der GeoBasis_Loader-Webseite [2] beschrieben. Ich danke Euch!

[1] … https://www.ardmediathek.de/video/Y3JpZDovL3dkci5kZS9CZWl0cmFnLXNvcGhvc mEtZDliMDgxMzctZmM0Mi00YjRhLTgwNjctNmQzYTRjYWIzOTBk
[2[ … https://geobasisloader.de
[3] … https://geoobserver.de/qgis-plugin-geobasis-loader/#mitmachen

Energieinfrastrukur mit OpenGridWorks

Screenshot 1: OpenGridWorks [1] in Europa (Bildquelle [1])

Einen Überblick über weltweit vorhandene öffentliche Daten aus dem Energiesektor, kreiert von Brian Bartholomew findet Ihr bei OpenGridWorks [1]. Genießt die Datenfülle und die Datenvisualisierung und entdeckt die Energiewelt noch mal mit anderen Augen. Die Daten stammen aus OpenStreetMap, der PeeringDB [2], EpochAI [3] und dem Global Energy Monitor [4].

Screenshot 2: OpenGridWorks [1] USA, Europa und die Atlantikkabel (Bildquelle [1])
Screenshot 3: OpenGridWorks [1] in und um Halle (Saale), mit der Identifikation auf der Kraftwerk Schkopau (Bildquelle [1])

[1] … https://opengridworks.com/power-plants
[2] … https://www.peeringdb.com/
[3] … https://epoch.ai/data/data-centers?view=graph&tab=power
[4] … https://globalenergymonitor.org/

QGIS-Tipp: Plugin „GeoBasis_Loader“ BugFix, v2.1.1

Seit Freitag, dem 05.06.2026, ist eine neue Version des QGIS-Plugins „GeoBasis_Loader“ [1] verfügbar: v2.1.1 [2]. Diese Version ist ein Bugfix-Release für v2.1 [3]. Was wurde behoben?

  • Installationsproblem bei Neuinstallationen: In Einzelfällen konnten nach einer komplett neuen QGIS-Installation die Kataloge nicht gelesen werden (bei rund 1750 Downloads wurde das Problem nur zweimal gemeldet – aber eben zweimal zu viel).
  • Protokollierungs-Problem: Eine fehlerhafte Logging-Ausgabe bei Netzwerkfehlern wurde korrigiert.

Bitte aktualisiert in Eurem QGIS das Plugin zeitnah auf den neuen GeoBasis_Loader v2.1.1, damit Ihr von den Fixes profitieren könnt. Vielen Dank an die User, die den Fehler gemeldet haben und ein Dankeschön an Anton & Thomas für das schnelle Beheben!

[1] … https://geobasisloader.de
[2] … https://plugins.qgis.org/plugins/GeoBasis_Loader/version/2.1.1/
[3] … https://plugins.qgis.org/plugins/GeoBasis_Loader/version/2.1.0/

QGIS-Tipp: QGIS-Plugin „GeoBasis_Loader“ aktualisiert, v2.1

Seit Freitag, dem 29.05.2026, um 12:05 Uhr ist eine neue Version des QGIS-Plugins „GeoBasis_Loader“ [1], aktuell v2.1. Was ist neu? 1. Zuwachs im GBL-Team: Nachdem bislang Anton May die Programmierung verantwortet hat und ich das Projekt als Maintainer sowie als Erfasser der inzwischen 846 Geodienste betreue, freuen wir uns, seit März mit Thomas Wölk einen weiteren Entwickler im GBL-Team begrüßen zu dürfen. Und natürlich 2. Neue Features: Neben umfangreichem Code-Refactoring bringt die neue Version vor allem inhaltlich einige Neuerungen mit sich – konkret wurden folgende Funktionen ergänzt:

1. Werkzeug/Button
Neben der Steuerung über das Erweiterungs-Menü gibt es den „GeoBasis_Loader“ jetzt auch mit einem Werkzeug/Button, an dem das gleiche Menü angehängt ist

Screenshot 1: Der neue Button des GBL in der Werkzeugleiste

2. Favoriten
Unter Favoriten kann der Nutzer jetzt seine persönlich bevorzugten Themen einstellen und so jederzeit ganz schnell auf diese zugreifen.

Screenshot 2: Die neuen GBL-Favoriten

3. Presets (Zusammenstellungen)
Mit den Zusammenstellungen können persönliche Gruppen von Themen gespeichert und verwaltet werden, z. B. Alle Schutzgebietsdaten (NSG, LSG, P30-Biotpe, GLB, FND) oder alle Daten der Flüsse (Bundeswasserstraßen, PegelOnline-Daten), …

Screenshot 3: Die neuen GBL-Presets, der Tooltip zeigt auch gleich die enthaltenen Themen an

Bei Bedarf kann zur jedem Preset auch auch ein räumliches Lesezeichen gespeichert und genutzt werden. Diese Lesezeichen steht dann auch im QGIS-Browser als Benutzerlesezeichen in der Rubrik „GeoBasis_Loader“ zur Verfügung.

Screenshot 3b: Die räumlichen Lesezeichen für GBL-Presets

4. Kontextmenü
für alle Themen zum Handling der Favoriten, Presets, Ein- und Ausblenden, Aktivieren und Deaktivieren

Screenshot 4: Das neue GBL-Kontextmenü – rechte Maustaste auf jedem Thema

[1] … https://geobasisloader.de

LIDAR: fast schon Kunst 3, ein Youtube-Tutorial

Screenshot (Bildquelle [3])

Das Geo-Wochenende ist gerettet 😉 Ich hatte über das Thema, wie aus LIDAR-Daten wunderschöne Karten, fast schon Kunst werden, bereits zweimal berichtet, vgl. [1] und [2]. Faszinierend sind diese Karten für mich immer noch. Nun bin ich auf ein Youtube-Tutorial [3] gestoßen, was die Erstellung von REM-Karten mit Lidar-Daten in R beschreibt, hochinteressant, quasi DataViz par excellence! Übrigens, den vollständigen Code gibt’s auf GitHub [5], die LIDAR-Daten bei der USGS [6].

Hier der Original-Tweet [4]:

[1] … https://geoobserver.de/2016/03/08/lidar-fast-schon-kunst/
[2] … https://geoobserver.de/2020/04/23/lidar-fast-schon-kunst-2/
[3] … https://www.youtube.com/watch?v=x8is770F7Og
[4] … https://x.com/milos_gis/status/2056248858062065989
[5] … https://github.com/milos-agathon/relative-elevation-model-maps
[6] … https://apps.nationalmap.gov/lidar-explorer/#/

QGIS- & GeoBasis_Loader-Webinar: Mitschnitt online!

Screenshot: GeoBasis_Loader-Preview v2.2

Am 7. Mai 2026 fand das Webinar „Geobasisdaten & Kartenerstellung“ [1] der Firma NTI zusammen mit dem #geoObserver statt. Seit einigen Tagen ist die Webinar-Aufzeichnung auf Youtube [2] online. Wer also nicht mit den mehr als 180 Teilnehmern live dabei sein konnte, kann sich ggf. noch einmal via diesem Mitschnitt informieren.

Neben der aktuellen Version v2.0.0 des GeoBasis_Loaders [3] stellte ich auch erstmalig neue und geplante Funktionen für v2.1 und 2.2 als Prototyp vor. Im zweiten Teil zeigte NTI-Fachkollege Jakob Wilhelm, wie im QGIS mit den wunderbaren freien und nun auch via GeoBasis_Loader einfach geladenen Daten eine Karte erstellt werden kann.

Video: QGIS- & GeoBasis_Loader-Webinar – Der Mitschnitt

[1] … https://geoobserver.de/2026/05/07/heute-das-webinar-qgis-kartenerstellung-der-geobasis_loader/
[2] … https://www.youtube.com/watch?v=aMSbxvOCZck
[3] … https://geobasisloader.de

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