Wenn man mal ganz schnell einen Plan braucht und vielleicht das gewohnte GI-System gerade nicht verfügbar ist, dann lohnt es sich, mal bei der Plantaube [1] von Julian Lindner [2] vorbei zu schauen. Mit wirklich wenigen Klicks und Eingaben könnt Ihr einen Plan erstellen und in verschiedenen Formaten exportieren. Ich habe es mal ausprobiert und es funktioniert absolut problemlos. Aus meiner Sicht sind vor allem die einfache Bedienung und die sehenswerte Plangrafik hervorzuheben. Mein Ergebnis-PDF findet Ihr unter [3]. IMHO: Coole Lösung! Genutzt werden selbstverständlich die OpenStreetMap-Daten.
Das Projekt ist noch im Entstehen, um Feedback wird ausdrücklich gebeten. Ich würde mir noch bessere Beschriftungsmöglichkeiten, den verpflichtenden Hinweis auf OSM-Daten im PDF und vielleicht die Einbindung eigener Daten wünschen, aber ich bin mir sicher, dass kommt bestimmt noch, ich habe schon angefragt.
Screenshot 1: Die Adresse suchen, hier Halle, Ankerstraße 3b, Maßstab, Papierformat und -Orientierung sowie Himmelsrichtung wählenScreenshot 2: Opetionen Einstellen, hier z. B. die Schatten für Gebäude und BäumScreenshot 3: PDF generieren lassen
Es ist tatsächlich faszinierend, mit Weather Replay [1] von Copernicus ECMWF [2] könnt Ihr das Wetter der Vergangenheit, beginnend ab 1940 an jedem Ort der Welt stundenweise online nachvollziehen. Ich habe es gerade für Halle (Saale) zum Jahrtausendwechsel [3], also vom 31.12.1999, 0:00 Uhr bis 01.01.2000, 23:59 Uhr berechnen lassen, hier das Ergebnis in einer stark herunter gerechneten Variante:
Animation: Das Wetter in für Halle (Saale) zum Jahrtausendwechsel auf 640 Pixel herunter skaliert
Herramienta fascinante para explorar el clima del pasado: Weather Replay, la nueva app de @CopernicusECMWF, permite reconstruir las condiciones meteorológicas de cualquier lugar del mundo hora a hora desde 1940 hasta hoy.
Wenn Du mal ganz schnell ein 3D-Modell eines Planungsgebietes brauchst, kann Dir ganz sicher Map3D[2], [3] weiterhelfen. Dort heißt es:
„Dies ist ein 3D-Gebäudekartierungsdienst, der mit React-Three-Fiber implementiert wurde. Er ermöglicht den Export als GLB-Datei und alle Funktionen sind kostenlos nutzbar. Auf diesem Projekt aufbauend lassen sich verschiedene Funktionalitäten wie digitale Zwillinge, Drohnenvermessungen und GPS-Markierungen realisieren.
Die Kartendateien basieren auf OpenStreetMap-Daten.“ [2]
Auf der Webseite des Projektes [2] kann man die Funktionsweise testen, ich habe es mal probiert, es funktioniert wunderbar. Noch nie bin ich einfacher zu (m)einem 3D-Modell gekommen. Man braucht nur folgende fünf Schritte auszuführen:
Schritt 1: In das gewünschte Gebiete bewegen/zoomenSchritt 2: Zu berechnenden Ausschnitt markierenSchritt 3: kurz rechnen lassenSchritt 4: Ergebnis der Berechnung Schritt 5: Das fertige 3D-Modell
Momentan sind realisiert: 3D-Gebäude erstellen, Straßen bauen und GLB exportieren. In Zukunft soll es noch mehr geben: Gebäudestruktur, Höhenanpassung, Material und Höhenkarte. Ihr findet den Quellcode und noch weitere Details auf GitHub [2].
Hier der Original-Tweet [1]:
Someone open sourced a tool that generates a full 3D model of any city on Earth in seconds real buildings, roads, elevations, exportable as GLB for Unity, Blender, AR, or drones.
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
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. ↩︎
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. ↩︎
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 😉
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 PNGAbbildung 3: Screenshot einer Teams-Sitzung mit dem Ergebnis meiner TerraInk[1] Testsitzung als Hintergrund
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)
What if you could draw ANY image using real city streets?
latest experiment: Upload any picture → the app detects its edges → then autonomous agent trace and fill the image using actual roads from OpenStreetMap.
Agents draws the outlines and fills the interior in green.
Screenshot: Halle (Saale) mit Strado analysiert (Bildquelle [2])
In der gestrigen Wochennotiz 820 [1] habe ich Interessantes zur Auswertung von OpenStreetMap-Daten mit einem neuen Tool Strado [2] im Blog von L_J_R [3] gelesen. Dort heißt es:
Funktionsweise
Strado analysiert 22 Kategorien von POIs aus OSM – Restaurants, Gesundheitseinrichtungen, Haltestellen, Parks, Schulen, Nachtleben, Lebensmittelgeschäfte und mehr – und berechnet anhand eines H3-Hexagonrasters (Auflösung 9, Kantenlänge ca. 174 m) Lebensqualitätswerte auf Straßenebene.
Die Idee ist einfach: Wenn du in eine neue Stadt ziehst, solltest du Stadtteile danach vergleichen können, was tatsächlich zu Fuß erreichbar ist. Keine Meinungen, keine gesponserten Einträge – nur Daten. [3] Übersetzt mit DeepL.com (kostenlose Version)
Und das ist wichtig: „Keine Meinungen, keine gesponserten Einträge – nur Daten.“ – das findet man Netzt tatsächlich nicht so oft, damit wird die Auskunft deutlich neutraler, allerdings ist sie eben auch vom Erfassungsgrad anhängig. In OSM-gesättigten Gegenden [4] sollte dann also eine wirklich gute, neutrale Bewertung als Ergebnis heraus kommen.
Mögen sich die Stadt-, Landschafts- und Sozialplaner ein Fachurteil bilden und uns hier teilhaben lassen, gern in den Kommentaren. Wie gut bildet ein solches Modell mit dem Schwarmwissen die Sozialfaktoren ab, was ist gut, was weniger? Ich bin gespannt.
Über die niederländischen, nach Baujahren klassifizierten Häuser hatte ich bereits 2013 im Beitrag „9.866.539 Gebäude, historisch gesehen …“ [1] berichtet. Nun, nach 12,5 Jahren gibt es ein Update von Bert Spaan „All 11.333.878 buildings in the Netherlands“. Zum Einen mit mehr Daten, nämlich 1.467.339 weiteren Gebäuden und zum Anderen mit mehr Funktionalität in der interaktiven Karte. Zu den technischen Hintergründen ist in [3] Folgendes zu erfahren:
Screenshot 1: Hier das wohl älteste Haus von Amsterdam [4] (Bildquelle [2])
„Die neue Karte nutzt eine Kombination aus Raster- und Vektorkacheln, um sicherzustellen, dass alle Gebäude stets sichtbar sind. Mit reinen Vektorkacheln ist dies nicht möglich: Eine einzelne Vektorkachel würde bei geringer Vergrößerung mehrere zehn Megabyte groß sein. Rasterkacheln bei geringer Vergrößerung und Vektorkacheln bei hoher Vergrößerung lösen dieses Problem!“ [3]
Übrigens, nach „Begijnhof in Amsterdam“ [4] ist Amsterdams ältestes noch erhaltenes Haus das „Het Houten Huis“ (Nr. 34) im Begijnhof aus der Zeit um 1420. Ich hab’s gefunden, lt. Karte 1455, vgl. Screenshoot 1. Aber ich habe auch ein noch Älteres gefunden, vgl. Screenshot 2, möglicherweise ein Datenfehler? Ich frage nach.
In jedem Fall wieder eine großartige Daten in einer wunderschönen Karte, eine meiner Lieblingskarten bzgl. DataViz und SUPERSCHNELL. Danke Bert!
Screenshot 2: Ein noch älteres Gebäude oder ein Datenfehler? (Bildquelle [2])
Screenshot: Erfolgreich, mein erster ST_Letters – Test.
Also gleich mal die Auflösung: Ich kannte es noch nicht. Umso dankbarer bin ich für den Tipp von Astrid Emde bei der FOSSGIS 2026, den ich hier gern weiter gebe. Dort hat sie in ihrem Lightning Talk „PostGIS ST_Letters – Worte sagen manchmal mehr“ [1], [3], also in nur 5 min vorgestellt, wie man mal ganz auf die Schnelle Geodaten erzeugt, nämlich einfach mit einem Text (zzgl. der PostGIS-Funktion ;-). Es ist quasi eine Funktion Text2Multipolygon. Wer also mal wieder ganz schnell ein paar Testdaten braucht, ST_Letters könnte das richtige Werkzeug sein. Danke Astrid!
Ich hab’s mal angetestet, hier das SQL-Statement, mein Ergebnis siehe Screenshot.
