Skip to main content

Blog

Make them trip patterns bendy instead of spiky

von Stefan Kaufmann · 17. Januar 2020

Once you deploy digitransit with your GTFS feeds, you might encounter spiky trip shapes that don’t follow street geometry. Here is how to fix this.

Fellow developer Vlatko from the City of Osijek sent us this screenshot. The bus appears to just bulldoze through buildings, not following any street geometries at all.

What happens here is the following. GTFS has a separate file called shapes.txt that defines shape geometries for trip patterns. Within trips.txt, individual trips can reference a shape_id they adhere to.

If this shapes.txt is not defined within your GTFS feed (and many feeds do not provide shapes right now), digitransit/OpenTripPlanner will only display the linear distance between individual stop points – regardless of the actual route the trip should take.

How to mitigate this

There are several approaches to retroactively add shapes to your existing GTFS feed. We have tried two variants and can recommend them both:

Conveyal Transit Data Tools

This is a complete software suite you can access through your browser in order to edit, reconfigure or even build your GTFS feed from scratch. Good for getting a first feel for your feeds and analyzing them.

pfaedle

pfaedle is a command line tool by Patrick Brosi that matches GTFS feeds to OpenStreetMap relations very precisely. This might take a bit longer to set up initially and adapt to your needs, but once it runs it should save you time in the long run.

Wie funktioniert eigentlich das mit den Fahrradtrackern?

von Stefan Kaufmann · 13. Januar 2020

Auf dem 36. Chaos Communication Congress des CCC zwischen Weihnachten und Neujahr gab es einige Ulmer Beteiligung – und unter anderem auch einen Vortrag von unseren Stadtverwaltungs-Fellows Consti und Max, der es auch bis Heise Online geschafft hat.

Nebenan auf radforschung.org gibt es einen begleitenden Artikel samt allen Quellen, den Vortrag selber gibt es natürlich auf media.ccc.de in ganzer Länge und auch mit englischer Übersetzung anzusehen.

Einschub: Der Vortrag erwähnt die Stadt als Fellowship-Geberin eher subtil – das ist Absicht und so gewollt, denn die Regeln des Congress sagen ganz klar, dass dies eine nicht-kommerzielle Bühne ist, auf der Marketing für ArbeitgeberInnen nicht akzeptiert ist.

Im Nachgang gab es daraufhin viel viel Feedback, Tipps und Fragen. Und eine der meist gestellten Fragen war, wie denn die Positionsübermittlung der Fahrräder derzeit funktioniert. Deswegen hier mal ein Aufschrieb dazu.

Wie die Daten überhaupt übertragen werden

Eine grundlegende Annahme für uns ist derzeit, dass wir uns nicht auf klassische SIM-Kartenbasierte M2M-Kommunikationsstrukturen verlassen wollen – also irgendwas, was klassische Mobilfunkbetreiber anbieten.

In Ulm gibt es bereits seit Ende 2016 ein gut ausgebautes LoRaWAN-Netzwerk auf Basis des freien The Things Network. Das ermöglicht uns, ohne laufende Subskriptionskosten kleine Datenmengen zu übertragen und zu experimentieren. Ein Nachteil muss aber erwähnt werden: Das Grundprinzip des Netzwerks ist, dass vorwiegend Daten von den Endgeräten zu den fest installierten Gateways übertragen werden. Die Rückrichtung von der Infrastruktur zu den Endgeräten ist eigentlich mehr die Ausnahme, und sie funktioniert auch nur unter gewissen Voraussetzungen.

Das ist aber im derzeitigen Projektstadium nur mäßig projektkritisch – und es spricht auch nichts dagegen, gegebenenfalls in einem anderen Setting auch M2M-SIM-basierte Geräte einzusetzen.

Vom MVP zur eigenen Hardware – oder, alles mal probieren

Der aktuelle Stand ist, überhaupt Positionierungsdaten ins Backend zu übertragen. Beim Feldversuch auf dem Chaos Communication Camp im Sommer 2019 passierte das mit TTGO T-Beam Development Boards. Das sind für ca. 20 EUR pro Stück aus Fernost bestellbare Entwicklungsplatinen, auf denen ein programmierbarer ESP32-Controller, ein halbwegs passables GPS-Modul und ein LoRaWAN-Modem (RFM95W) gemeinsam verbaut sind. Und weil auf der Platine auch gleich eine Lade- und Entladeregelung sowie eine Halterung für eine 18650-Akkuzelle dabei sind, ist das praktisch eine alles-in-einem-Lösung, die wir einfach so an die Fahrräder binden und benutzen konnten.

Naja, jedenfalls fast: Selbst wenn das Gerät nur alle 10 Minuten aufwacht, um die Position zu bestimmen, brauchen die Platinen auch im Deep-Sleep-Modus vergleichsweise sehr viel Energie. Die Akkus waren indes meist nach gut 30 Stunden komplett leer und mussten regelmäßig getauscht werden. Für den Praxiseinsatz ist das natürlich so gar nicht tauglich.

Der Quellcode, den wir auf dem Camp im Einsatz hatten, ist selbstverständlich auf Github verfügbar. Wie man dort erkennen kann, hatten wir auch mit günstigen Beschleunigungssensoren MPU9250 experimentiert, die das System aufwecken, wenn am abgestellten Fahrrad gewackelt wird.

Positionierung auf WLAN-Basis

Consti hatte eine andere Idee, wie man lange Betriebszeiten mit wenig Energie hinbekommt. Er hat einen eigenen Aufbau auf Basis eines ESP8266 getestet, der intervallbasiert die BSSIDs umliegender WLAN-Netzwerke erkennt und diese dann ins Backend schickt. Über den offenen Mozilla Location Service ist dann eine grobe Rückpositionierung möglich – falls genügend Menschen für diesen Ort Positionierungsdaten angelegt haben. Für eine grobe Positionsbestimmung reicht das allemal – denkbar ist natürlich, genau wie bei allen anderen Methoden, die Positionierung über passende Beacon-Verfahren an den festen Abstellstationen noch zu präzisieren, wenn man dafür geeignete Hardware einsetzt.

Kommerziell erhältliche Tracker

Um schnell Räder auf die Straße zu bringen und Tests fahren zu können, hatten wir zudem einige kommerziell erhältliche GPS-Tracker mit LoRa-Modem gekauft und getestet. Das war hier vor allem der Dragino LGT92 – der witzigerweise ein ähnliches Feature Set hat wie unser Eigenaufbau aus T-Beams mit Beschleunigungssensor, und dessen Erfassungszyklus auch ähnlich gedacht ist wie das, auf das wir mit den T-Beams kamen.

Zum Testen reichen die Geräte ganz passabel aus; an den Fahrrädern haben wir sie in Feuchtraum-Abzweigdosen mit Schellen aus dem Baumarkt befestigt. Ein Tracker kostet bei den üblichen Einkaufsplattformen rund 40 €.

Unsere geplante eigene Lösung

…ist eigentlich grob eine Mischung zwischen dem T-Beam und den Dragino-Trackern: Eine eigene Plattform auf ESP32-Basis mit verbundenem MPU9250-Gyroskop und abschaltbarer Spannungsversorgung für die allzu energiehungrige Sensorik, v.A. das GPS. So kann der Tracker die meiste Zeit im Tiefstschlafmodus verbringen und dabei kaum Energie aufnehmen – und in periodischen Abständen, bzw. wenn die IMU Bewegung erkennt, wacht die Platine auf und ermittelt ggf. die Position.

Langfristig möchten wir diese Plattform auch mal testweise mit den Rahmenschlössern verbinden, die Consti und Max bereits analysiert hatten, um damit Entsperrvorgänge anzustoßen. Für den Anfang freuen wir uns aber auch schon um eine sehr energiesparsame Variante, die im Idealfall bei Benutzung des Rads auch über den Nabendynamo erhaltungsgeladen werden kann, so dass die Wartungsintervalle möglichst ausgedehnt werden können.

Im Testaufbau hat das alles auch schon sehr gut funktioniert. Im Tiefschlaf braucht das System weniger als ein halbes Milliampere, und trotzdem funktioniert die Positionierung vor allem draußen schnell und zuverlässig. Auch hier können Beacon-Systeme an ausgewiesenen Abstellpunkten zur Präzision der Erkennung beitragen.

Selber mitentwickeln

Wir möchten als Freie Soft- und Hardware entwickeln – und dazu gehört auf jeden Fall, auch anderen den Einstieg in die Mitentwicklung zu erleichtern. Sobald wir die ersten prototypenfähigen PCB-Designs haben, landen die natürlich auf Github. Und wir möchten interessierte Hackspaces auch gerne Platinen aus der ersten Serie zum selbst belöten zuschicken, sobald sie gefertigt sind. Mehr dazu folgt hier, sobald es soweit ist!

Vernetzungstreffen beim FORUM Offene Stadt und dem Code-for-Germany-Summit in Hamburg

von Stefan Kaufmann · 13. November 2019

Sowohl OpenBike als auch digitransit sind Freie/Open-Source-Softwareprojekte – und das heißt auch, sie brauchen beide unbedingt eine aktive Community von Menschen, die an den Systemen weiterentwickeln, neue Features entwickeln, und vor allem auch die Dokumentation so ausbauen, dass die Systeme für andere nachnutzbar sind. Deswegen hat es uns sehr gefreut, vergangenes Wochenende beim FORUM Offene Stadt bei der Körber-Stiftung in Hamburg und danach beim Code-for-Germany-Communitysummit von den beiden Projekten zu erzählen und uns mit Gleichgesinnten zu vernetzen.

Beim Barcamp-Format im Kubus der Körber-Stiftung konnte Maxi einer ganzen Traube von Menschen den digitransit-Stack vorstellen, und es ergaben sich auch gleich sehr schnell Ideen für neue Features oder andere Orte, an denen das System auch einmal getestet werden könnte.

(Nebenbei: Es sind tatsächlich genau diese Formate, die Menschen sowohl aus der Verwaltung, als auch aus digitalem Ehrenamt, Wirtschaft und Forschung zusammenbringen, die am meisten Inspiration und Austausch mit sich bringen. Das ist jetzt eine alles andere als revolutionäre Erkenntnis, aber in der Praxis lässt sich doch immer wieder feststellen, dass die meisten Konferenzen immer nur in der eigenen Suppe schwimmen.)

Beim anschließenden Code-for-Germany-Summit konnten diese Ideen dann auch gleich weiter vertieft werden. Die vor über fünf Jahren ins Leben gerufene Community aus dezentralen OK Labs ist ein wertvolles Netzwerk von motivierten und kompetenten Leuten, die im wahrsten Sinne des Wortes mit Code die Welt verbessern wollen. Oder zumindest ihre eigene Stadt. Und so gab es gleich eine ganze Reihe an Nachfragen, Verbesserungsvorschlägen und Ideen sowohl für OpenBike als auch für digitransit.

Wer auf dieser Ebene mitwirken will, sei hier ausdrücklich auf die weite Community der weit über 1000 Menschen im Slack der Open Knowledge Foundation hingewiesen. Dort gibt es auch eigene Kanäle sowohl für Open-Source-Bikesharing als auch für die Entwicklung an digitransit. Wer dort mitlesen und -schreiben möchte, kontaktiere uns gerne jederzeit.

Dankeschön an dieser Stelle an das Team von Code for Hamburg, das dieses Wochenende großartig organisiert hat!