---
layout: tech
title: tech/transit
---

# Transportation Routing

The state of transit software, particularly open-source transit software, is *atrocious*. It is a mess of mostly scattered, abandoned, half-completed projects. This is extremely weird, because a lot of people into open source are also into transit: so maybe transit apps are just hard to write and thankless to maintain? In any case, it is a bummer.

I've collected some notes on transit information sources and transit data, for anyone looking to find a decent transit app, or looking to build one themselves. This does not include projects that I consider dead (no activity in ~2 years: API churn means these will almost certainly not function) or too specific (tooling for making maps, region-specific transit apps, etc). If you're reading this and notice any major omissions - of which there certainly are - feel free to shoot me an email.

## Transit Data

The *de facto* standard for transit data is [**GTFS**][gtfs]: the General/Google Transit Feed Specification. You can read more about it on [Wikipedia][gtfs-wikipedia]. There are two components: GTFS Schedule (or just GTFS, sometimes GTFS Static), and GTFS RealTime (sometimes GTFS-RT). GTFS Schedule contains *static* transit information. This is information like routes, stops, schedules, fares... information that could be feasibly found on a physical transit map. GTFS RealTime contains real-time information about the locations of all transit vehicles. As transit arrivals/departures do not always match their posted times: this allows for applications to provide *accurate* transit data and time estimates.

GTFS data is typically found directly from transit agencies: for example, Vancouver's TransLink agency has [a page for GTFS][translink-gtfs], and [a page for GTFS-RT][translink-gtfs-rt]. Generally this data is easily accessible from [a publicly-available API][translink-gtfs-api]. Sometimes transit agencies shoot themselves in the foot and impose a rate limit: this is, unfortunately, the case for TransLink's GTFS-RT, as requests need an API key and are limited to 1000/day. (I've been told a much better model would be Pub/Sub over WebSockets...)

These GTFS feeds are scattered around the Internet and typically found on individual transit providers' own websites. This is inconvenient, and several projects have popped up to collect feeds: formerly GFTS Data Exchange and [Open Transit Feeds][opentransitfeeds], and presently the [**Mobility Database**][mobilitydatabase]. The latter two were/are stewarded by the non-profit organization [Mobility Data][mobilitydata], which helps maintain GTFS and also develops [GBFS][gbfs] - a General Bike Feed Specification, for rideshare services.

There are other, commercial providers for transit data. [Navitia][navita] is a/the major player in this domain, and uses its own transit feed specification, NTFS (an extension of GTFS). It is unclear to me what the benefits of using an intermediary provider are. Perhaps it avoids needing to interface with each GTFS provider separately, though that seems like not too complex of a task? Perhaps (hopefully not) there are some transit agencies that do not provide their GTFS feeds openly? The downsides are apparent: Navita does not have support for a large number of regions, and has dropped support for regions in the past, breaking transit apps that relied upon it.

## Mapping Data

[**OpenStreetMap**][osm] is *the* place for open source mapping data. It's essentially Wikipedia for maps: being not all too much younger, and having [a similar history of user contribution][osm-wikipedia]. It is incredibly good for geography and buildings, and is actively used, contributed to, and supported by major corporate entities. Unfortunately, it never gained broad adoption from the public in the same way Wikipedia has - and so it is extremely bad for businesses, as locations and information (opening hours etc) change rapidly, and business owners only have a financial incentive to keep the most popular map updated - which, of course, is Google Maps.

## Mobile

[**Organic Maps**][organic-maps] and [**OSMAnd**][osmand] are two open-source offline maps apps, both available on both iOS and Android. I find **Organic Maps** to be significantly more usable, and I would genuinely recommend it to anybody who wants an offline maps app, particularly for hiking. I cannot say the same about OSMAnd. OSMAnd is extremely slow, buggy, and unintuitive, in my experience.

Neither are very good at transit. Organic Maps only does train lines, and not very well. [There is an open issue for adding transit support.][organic-maps-gtfs-tracking] There's not really any good options for open source transit apps, on any platform. [**OneBusAway**][onebusaway] appears reasonably decent [if your region is supported][onebusaway-regions], which it probably isn't. On Android, [**Transportr**][transportr] technically exists, but is in a state of disrepair and lacks support for most regions outside of Europe.

If you are looking for an alternative to Google Maps: it is closed-source, but the [**Transit**][transit] app is likely your best bet. I consider their business model somewhat unpleasant. It blocks future trips, alternate routes, and transit schedules for less-used lines behind a monthly subscription - kneecapping the app, and making the free plan significantly worse than Google Maps. However - they've used this as an incentive to partner with transit agencies, so if you ride in a supported area you'll get it for free. And they offer free subscriptions to anyone who can't afford it. I'm more concerned about them being a corporation - with a closed-source product from a corporate entity, there is always a major risk of enshittification - but right now it appears very usable.

If you're using an iPhone, you might as well just use Apple's stuff anyway. Presumably you do not mind feeding data to Apple as a corporation: whether you trust their marketing or find the convenience worth it. In any case, they do have a strong incentive to make Apple Maps as good as it can get.

If you're interested in contributing to OpenStreetMap, the [**StreetComplete**][streetcomplete] app gamifies data entry into ARG-like side quests. It is only available for Android. A fork called [**SCEE**][scee] adding advanced features is also available, and seems to be actively maintained.

## Web

...

## Desktop

...

## Libraries

...


[gtfs]: https://gtfs.org/
[gtfs-wikipedia]: https://en.wikipedia.org/wiki/GTFS
[translink-gtfs]: https://www.translink.ca/about-us/doing-business-with-translink/app-developer-resources/gtfs/gtfs-data
[translink-gtfs-rt]: https://www.translink.ca/about-us/doing-business-with-translink/app-developer-resources/gtfs/gtfs-realtime
[translink-gtfs-api]: http://gtfs.translink.ca/
[opentransitfeeds]: https://transitfeeds.com/
[mobilitydatabase]: https://mobilitydatabase.org/
[mobilitydata]: https://mobilitydata.org/
[navita]: https://navitia.io/en/
[gbfs]: https://gbfs.org/
[organic-maps]: https://organicmaps.app/
[organic-maps-source]: https://github.com/organicmaps/
[organic-maps-gtfs-tracking]: https://github.com/organicmaps/organicmaps/issues/5331
[osmand]: https://osmand.net/
[osmand-source]: https://github.com/osmandapp/
[transito]: https://git.sr.ht/~mil/transito
[onebusaway]: https://onebusaway.org/
[onebusaway-regions]: https://onebusaway.org/onebusaway-deployments/
[transportr]: https://github.com/grote/Transportr
[transit]: https://transitapp.com/
[streetcomplete]: https://streetcomplete.app/
[scee]: https://github.com/Helium314/SCEE
[osm]: https://www.openstreetmap.org/
[osm-wikipedia]: https://en.wikipedia.org/wiki/OpenStreetMap
[mepo]: https://sr.ht/~mil/mepo/
[mobroute]: https://sr.ht/~mil/mobroute/