Skip to content

Transitous Hack Weekend Berlin, July 2025

Jump to bottom
Volker Krause edited this page Jul 18, 2025 · 26 revisions

Transitous Hack Weekend Berlin, July 11-13 2025

When

Start: Friday, 2025-07-11, ca. 15:00, following the DELFI Family & Friends Day, which is supposed to end at around 14:30 and is about a 15 min walk way.

End: Sunday, 2025-07-13, ca. 14:30. We have a hard limit there as there's another event in the same venue starting at 15:00.

Where

WikiBär

Köpenicker Straße 45

Berlin

OSM

How to get there?

Come on, you all work on routing software...

Participating

Anyone interested in or contributing to Transitous and related/adjacent topics is welcome to join. There's room for about 15 people.

Please indicate whether you want to participate though, in the Transitous Matrix channel or by adding yourself to the list here, so we can contact you e.g. in case of changes.

Attendees

  • Felix
  • Jonah
  • Robin
  • Volker (@vkrause)
  • Max (@1Maxnet1) (partially)
  • Frank
  • Michael
  • Lars (partially)
  • kat
  • lach-anonym
  • Jannis (@derhuerst)
  • Theo
  • Holger
  • Amélie

Timeline

  • Friday: start at 15:00, dinner tbd
  • Saturday: start at 09:00, lunch tbd, dinner tbd
  • Sunday: start at 09:00, lunch tbd, end at 14:30

Topics

Add topics you want to discuss/work on here:

Notes

France feed automation

https://github.com/public-transport/transitous/pull/1170

Transitous infrastructure/hosting/deployment, monitoring

Robin and Jonah have set up load balancing between the Berlin and Darmstadt servers.

Legal setup

Use cases:

  • privacy policy needs a legal contract
  • we need to be able to handle money, including international money income
  • we don't want single point of failures for e.g. domain ownership

Other examples:

  • chaos.social: own e.V. optimized for minimal work

Existing organizations we could attach to?

  • FOSSGIS eV - already operates Valhalla, Nominatim
  • Mobility Data?
  • OKF?

Verein as a Service

Comercial operations

  • we don't want that

Legal advice:

Further considerations:

  • Is project governenace tied to the organization or separate?
  • Licensing of the data we use might be a problem for some of the existing organizations
  • own eV would need a yearly budget of 600-1000€ per year just for operations

Action items:

  • we talk to Mobility Data, FOSSGIS eV and OKF

Python or R client library/package, python CLI tool

A Python client can easily be created by openapi-python-client:

openapi-python-client generate --path openapi.yaml --output-path motis\_api\_client --meta none

https://github.com/motis-project/motis/pull/932

Documentation/onboarding, setup documentation

The (data) contribution docs jump directly to JSON syntax details and assume GTFS and Git(hub) knowledge.

For the developer documentation:

  • the redoc OpenAPI geneartion does not allow to execute command in-place, like e.g. Swagger UI does

For the setup documentation:

  • prebuilt gtfsclean only exists for Linux, while Motis also exists for macOS/Windows
  • add python argparse help for fetch.py, for more useful feedback on passing wrong parameters (done: https://github.com/public-transport/transitous/pull/1348))
  • generate-motis-config.py should default to full mode
  • generate-motis-config.py should fill in Motis paths
  • maybe: separate command for local use that does motis import and motis server in one go

For MOTIS documentation:

Siri/NeTEx integration

https://github.com/motis-project/motis/pull/937

Usage policy

Open questions:

  • Should we require a User-Agent header or similar?
  • Use by proprietary apps
  • Listing proprietaty apps on the website

Notes:

  • Require User-Agent or equivalent, with the goal to have a communication channel
    • Use from within browser JS might require another header
  • Document our focus on FOSS apps
  • Proprietary/commercial users who stay under the radar e.g. while doing some testing or development don't matter, we wont attempt to hard-block that
  • We do not want to promote proprietary apps on the website
  • We want to avoid defined rate limits as long as people behave reasonably
  • Document that self-hosting the full Transitous data set, as an alternative option
  • Discourage bulk queries
  • Should we suggest proprietary users to contact commercial suppliers instead?
  • How strongly should we discourage proprietary users?
  • Edge cases: embedded web use (technically FOSS software) by organisations e.g. for events. Ok for e.g. non-profits/NGOs/people working on "good" causes, not ok for primarily commercial activities. Not easy to cover by above rules.
  • As we do now: encourgage people to get in touch for discussing their use case

Implemented in https://github.com/public-transport/transitous/pull/1345

Citybikes

Open questions:

  • deduplication, in particular with aggregate feeds like the NVBW or CH ones
  • all vehicle types covered?
  • scalability of hundreds of separate GBFS feeds, on their and on Transitous' side

Notes:

  • citybikes has predominantly bikes currently, but also historic data(!)
  • citybikes currently doesn't have the same kind of monitoring/feed error reporting as Transitous, but seemed to be interested in implementing something like that
  • best case scenario: citybikes becomes the canonical source for GBFS feeds, and we only consume that in Transitous, if anything from the current Transitous set is missing we contribute it there
  • possible middle ground sceneario: Transitous uses citybikes as yet another GBFS feed catalog with hand-picked feeds from there
  • worst case scenario: citybikes explicitly wants to only focus on bikes, not other vehicle types covered by GBFS, that would make integration very messy for feeds covering multiple modes (Transitous wants/needs everything)
  • we need to check if Motis scales good enough with the several hundred GBFS feeds from citybikes, but that would need to be resolved either way
  • citybikes hold a bunch of non-public API keys, possible impediment for self-hosting
  • need to check with citybikes whether using their 700+ feeds continuously from Transitous is ok load-wise and cost-wise for them. If that's a problem, self-hosting a citybikes instance might be an option.

Data portal showcases

Max is working on a template.

Motis binary data introspection tooling

Coverage visualization

Social Media

Mastodon account, possible content (should be min. 50 posts per year):

  • Service alerts about downtimes or updates
  • Weekly summaries about data coverage changes (possibly auto-generated by diffing the feed files)
  • Motis features/changelogs
  • Funny/bizarre data failures like the Zeitschleife von Aachen or the Wurmloch von Köln
  • Events (relevant OTM presentations, OTCC, hack weekend, etc)
  • Share content from apps using Transitous, Open Transport related events, etc

Blog aggregator: (should be at least a post every 3 months or so):

  • Motis feature posts
  • Some of Volker's posts

Passibly short update block after OpenTransportMeetup?

Where to set up a Mastodon account? who gets access?

  • Must be something that allows English content, which might excludes some on-topic instances like zug.network (verify this actually doesn't allow English content) or verkehrswende.social
  • Options:
    • generic FOSS instances (fosstodon, floss.social)
    • osm.town
    • kde.social
  • Done, and documented here: https://github.com/public-transport/transitous/wiki/Social-Media Setting up a blog aggregator on the website?

Crowd-sourcing realtime data

  • Public transport apps know which vehicle the user is in
  • phone sends (trip_id, coordinates) to a server
  • server exposes VehiclePositions
  • MOTIS is gaining support for predicting based on VehiclePositions
  • MOTIS will be able to expose TripUpdates as gtfs-rt

"Other sources" for realtime data

Adding STA (South Tyrol) to transport-apis

Multi-lingual GTFS/RT data support in MOTIS

  • Service Alerts have translation support already inside MOTIS' data model, this is just not yet provided to the outside.
  • translations.txt support does not yet exist, but at least the data model work is necessary for the NeTEx support.
  • Options to expose this:
    • additional API parameter
    • HTTP Accept-Language header (same as OTP)
    • In either case: we'd like an ordered list of preferred languages, a single language is not ideal.

Network Line Maps

Something like that would be nice, both as infrastructure for enduser UIs, as well as for diagnostics.

Normalizing/augmenting GTFS data, including representing train trip names in GTFS

  • Generally preferred approach: get things fixed upstream, by standard proposals and working with data providers
  • There will still be cases where we temporarily (in public transport time dimensions, ie. possibly for decades) need to fix or extend the date
  • Examples:
    • Normalize route/trip names: reordering fields, regex/text manipulation
    • Align mode of transport values: filters on other columns or possibly ohter tables (e.g. agency)
    • Augment line colors/logos, agency contact information/logos: Inject data from other (non-GTFS) tables
    • Compute missing paths: road and rail routing
  • Maintainability:
    • As little as possible of this should be done in code, some form of (declarative) rules next to the feed data would be much easier accessible for most contributors
  • Should this be in MOTIS or gtfsclean (or something else):
    • Performance is a concern, could generally be optimized by not re-zipping GTFS files multiple times, all tools can also work with unpacked GTFS
    • For seamless static GTFS feed switchover MOTIS might need to update and reload GTFS feeds during runtime, lengthy and separate processing steps could be a challenge for this

Ride sharing

  • MOTIS does not have an appropriate mode enum for this yet, but that's being worked on
  • there's GTRS as a GTFS extension for additionally needed information such as booking deep links or driver information

QA schedule data

  • MOTIS could expose the number of imported trips, transports, stops etc. https://github.com/motis-project/motis/issues/935
  • Make it possible to specify test queries that must find a connection
  • For huge feed collections like France, we need basically every feed however broken it might be to imported without errors, but we need to mark important feeds as "must-produce-transports" to still notice fundamental issues

Future Events

  • organize a FOSDEM fringe event?

Misc

Pad with notes: https://padlite.spline.de/p/transitous-hack-weekend

Photos

CC0-1.0

17875

17876

17877

Clone this wiki locally