// Abstract

Das Projekt visualisiert Ergebnisse aus der Studie der Daten des ÖPNV. Durch klein-skalierte Modelle mit RFID-Chip kann ein Nutzer diese in einem dafür vorgesehenen Sockel platzieren und mehr Informationen dazu bekommen. Diese Informationen sind abhängig von den verschiedenen Tageszeiten und zeigen auf, wo und wann in Deutschland der ÖPNV schwächer oder stärker vertreten ist. Durch die Interaktion mit der Maus können dann mehr Informationen angezeigt werden.

Zukünftig kann das Modell um andere Länder erweitert werden um auch hier eine bessere Vergleichsbasis zu schaffen.

// Filmische Dokumentation

https://u.feba.me/uni/ss22/documentation.mp4

// Pitch Deck

// Userflow

// Entwurf

https://www.figma.com/proto/FSgVZXD5rdTwRpUobs0aYO/%C3%96PNV-Tageszeiten?node-id=3%3A2&scaling=contain&page-id=0%3A1&starting-point-node-id=3%3A2

// Umsetzung

↓Export aus keplar.gl nach Datenbereinigung durch eigenes Python Script

↓ Erstellung der 3D-Daten durch https://imagetostl.com/

↓ Erstellung der Modelle in TinkerCAD

↓ Erstellung des Sockels mit RFID-Empfänger in Solid Edge

↓ 3D-Druck der Komponenten

↓ Zusammenführung aller Komponenten

10 // Image to STL

Durch das Online-Tool imagetostl.com konnte aus der PNG erfolgreich eine STL-Datei generiert werden.

09 // 3D-Druck Fehlschläge

Das näheste an einer 3D-druckfähigen Datei, was ich erzeugen konnte, sind folgende Screenshots. Die Vorgehensweise war das Ergebnis von kepler.gl als möglichst hochauflösendes Bild in Graustufen abzuspeichern und versuchen als GEOTiff interpretieren zu lassen.

08 // Entwurf kepler.gl

Um schneller die erhaltenen Daten in eine visuelle Form zu bekommen, habe ich einen Import in Mapbox und kepler.gl versucht. Da es bei Mapbox oft scheiterte, ging ich bald auf auf kepler.gl und teste erste Datensätze:

Die eigens erstellte Datenbank habe ich per verschiedener SQL-Abfragen nach möglichen interessanten Statistiken durchsucht und diese auch in kepler.gl visualisiert. Im Folgenden die Visualisierung der Haltestellen nach Höhe der Frequenz:

07 // Entwurf p5js mit node.js backend

Zuerst habe ich im Zuge der Perfomance-Optimierung Mapbox als Alternative zu Leaflet getestet. Leider performen Mapbox und MapboxGL nicht besser als Leaflet, MapboxGL habe ich nur mit Anzeigefehlern zum Laufen gebracht.

Um die vielen Daten nicht gleichzeitig in p5js laden zu müssen - was nicht funktioniert, da Browser abstürzt - habe ich ein Backend per node.js gebaut und die Daten in eine SQLite Datenbankdatei importiert. Trotz nachtäglichem Setzen eines Index, dauert eine Abfrage über zwei Sekunden. Um ein abspielbares Szenario zu visualisieren wären 60 Abfragen pro Sekunde wünschenswert, daher musste die Performance noch weiter verbessert werden. Als möglicher Lösungsansatz diente die bereits vorab generierte JSON-Datei. Für alle Uhrzeiten habe ich JSON-Dateien generieren lassen, die dynamisch vom Backend gesendet werden oder direkt von p5js interpretiert werden können.

Um 13:30 Uhr sind in Deutschland an über 50.000 ÖPVN-Haltestellen gleichzeitig zusteigbare Verkehrmittel.

06 // Entwurf p5js & leaflet

Für erste Test habe ich alle ÖPNV-Haltestellen der deutschen GTFS-Daten in Leaflet per p5js eingezeichnet.

Die schwarzen Punkte sind die Haltestellen, im zweiten Bild sind die roten Punkte die Positionen aller ÖPNV um 12:00 Uhr.

05 // Einarbeitung & Entwurf

Mapbox akzeptiert gelieferte GTFS-Daten nicht, Dateien zu groß und falls sie getrimmt geliefert werden passt angeblich das Dateiformat an sich nicht.

Die Daten mussten teilweise neu aufbereitet werden. Das vorliegende Format der GTFS-Daten besteht als CSV in TXT-Dateien. Um diese einfach bearbeiten zu können habe ich das CLI Tool trdsql genutzt. Damit ist es möglich per SQL-Befehlen neue Dateien individuell zu generieren.

Aufbau in QGIS:

Die Daten liegen in einer QGZ-Datei im „Coordinate Reference System“ „WGS 84“ (EPSG:4326) vor, was ich bald zu „WGS 84 / World Mercator“ ändern musste, da es sich zuvor um ein „Geographic Coordinate System“ statt einem „Projected Coordinate System“. Aus folgenden Ebenen besteht eine Datei:

• Schriftzug Uni an festgelegten Koordinaten
• Kleine Kreise als ÖPNV Haltestellen

• Grüne Konturen aus GPKG-Datei über GDAL aus HGT-Datei im Abstand von 5 Metern generiert

• GeoTIFF als Basis zur 3D-Visualisierung aus HGT-Datei der NASA generiert

Ansicht QGIS: ÖPNV & Müb

Ansicht QGIS 3D: Heightmap, GDAL contours (5m), ÖPNV & uni

04 // Pitch Deck

03 // Recherche zum Spinoff-Projekt Penplot

Als Teil des Gesamtprojekts soll ein Auszug visualisiert werden. Mit dem Axidraw möchte ich einen experimentellen Penplot von Münchberg anhand der Höhenmeter erstellen.

03.01 // Mapbox

Mit Mapbox habe ich versucht die Höhenmeter einzeichnen zu lassen. Dies klappte nur eingeschränkt gut, da Mapbox den Abstand der Höhen selbst festlegt. Das resultierende Problem ist, dass Karten mit wenig Höhen nur wenige Linien eingezeichnet haben.

Hier der Vergleich von Zugspitze zu Münchberg.

03.02 // GDAL

Mit dem Commandline-Tool GDAL soll die gewünschte Individualisierung möglich werden.

Manual: https://gdal.org/programs/gdal_contour.html#gdal-contour
Tutorial: https://courses.spatialthoughts.com/gdal-tools.html#creating-contours

Die benötigten DEM Daten der SRTM können über opendem.info benutzerfreundlich heruntergeladen werden.

gdal_contour merged.tif contours-10.gpkg -i 10

02 // Recherche zum Projekt

GTFS

Die General Transit Feed Specification (GTFS) ist ein Austauschformat für Fahrpläne des öffentlichen Personenverkehrs und dazugehörige geografische Daten.

GTFS Daten werden zum Beispiel von DELFI zum herunterladen bereitgestellt (ca. 21,4 GB): https://www.opendata-oepnv.de/ht/de/organisation/delfi/startseite?tx_vrrkit_view%5Bdataset_name%5D=deutschlandweite-sollfahrplandaten-gtfs&tx_vrrkit_view%5Baction%5D=details&tx_vrrkit_view%5Bcontroller%5D=View

Es existieren auch API-Schnittstellen von transitfeeds.com (voraussichtlich bald deprecated) und transit.land (international).

Analyse der GTFS-Daten von DELFI

Verkehrsmittel: Bahn (Nah- und Fernverkehr), U-Bahn, Stadtbahn, Straßenbahn, Bus, Fernbus, O-Bus, Schiffsverkehr, teilweise Bedarfsverkehr
= ca. 28.900 Linien
= ca. 12.000.000 Haltestellen
= über 32.700.000 Haltezeiten

Analyse der transit.land API

Die Ergebnisse sind nicht ausreichend, wenn man nach z.B. Haltestellen in Bayern sucht. Umlaute werden nicht akzeptiert, was die Suche nach deutschen Städtenamen teilweise nicht möglich macht. Selbst die Ergebnisse für München oder Nürnberg (Munich, Nuremberg) sind schwach, da wenige Bahnhaltestellen und noch weniger Bushaltestellen gefunden werden. Ausnahme davon ist allerdings der Flix-Bus, hier werden zahlreiche Haltestellen übermittelt.

01 // Projektideen

✅ Tool / Visualisierung zur Vermittlung der Daten von öffentlichen Verkehrsmitteln

Eine Studie zur Analyse von Daten der öffentlichen Verkehrsmittel.

Die Datengewinnung ist über DELFI oder transit.land möglich und erlaubt den Zugriff auf statische Daten, sowie Echtzeitdaten.

Probleme:

- Analyse sehr vieler Daten, Fokus muss gesetzt werden

❌ Interaktives 3D-Modell via Projection Mapping

Durch Drohnenaufnahmen können Bilddaten gewonnen werden. Durch Agisoft Metashape oder WebODM kann aus diesen Daten ein 3D-Modell generiert werden.

Auf ein 3D-Modell aus weißem Filament können die verarbeiteten Bilddaten durch einen Beamer dem Modell eine Textur verleihen.

Statt der Drohnenbilder können auch andere Daten visualisiert werden, z.B.:
- Wege der Wasseranschlüsse, Stomnetze
- Nutzung der Flächen: Wohn-, Gewerbe-, landwirtschaftliche Gebiete
- Straßenverkehr, Ampelschaltungen
- Echtzeit GPS-Daten anzeigen

http://uploads.felixbaumgaertner.de/uni/ss22/webodm.mp4

Probleme:

- Berechtigung mit einer Drohne Münchberg „abzuscannen“ (Google Maps?)
- Umwandlung der Daten zu 3D-Druck-konformen Dateiformat
- Fehldrucke können teuer werden

Google:
„Grundsätzlich ist es erlaubt, Luftbilder von privaten Grundstücken zu veröffentlichen, da diese explizit nicht die Persönlichkeitsrechte von Personen verletzen, solange die Personen oder persönliche Gegenstände nicht erkennbar sind. [...] Soweit die gültige Rechtslage.“

❌ Analyse des Straßenverkehrs durch stationierte Kameras

Um eine Studie zum Münchberger Straßenverkehr zu erstellen, werten intelligente Kameras die Fortbewegungsmittel aus.

Als Hardware können M5Stacks mit Kameras und Powerbanks als Stromversorgung in einem dafür entwickeltem Gehäuse dienen. Mit OpenPifPaf und NuScenes können die Fortbewegungsmittel durch maschinellem Lernen ausgewertet werden (mögliche Werte: 'car', 'truck', 'trailer', 'bus', 'construction_vehicle', 'bicycle', 'motorcycle', 'pedestrian', 'traffic_cone', 'barrier'). Per WLAN oder mobile Daten können die ausgewerteten Daten an einen Server gesendet und weiterverarbeitet werden.

Dadurch gewinnt man Erkenntnisse über z.B.:
- Hauptverkehrszeiten
- Varianz der Fortbewegungsmittel
- Vergleich der Wochentage
- Wahl des Fahrzeugtyps nach Wetterlage

Probleme:

- Berechtigung die öffentliche Straße zu filmen
- Evtl. zu wenig Rechenpower, muss getestet werden
- Falls mobile Lösung zutrifft: Kann beschädigt werden oder verloren gehen
- Hoher Aufwand zur Erstellung einer intelligenter Kamera, ggfs. wenig Zeit um Daten zu sammeln

Übersicht der Strecke am ersten Tag in QMapShack