I built my own CityMapper | Hacker News Reader

I built my own CityMapper

asherfalcon.com

155 pointsashfn21 comments

I am involved with the OpenTripPlanner project, which is a Java trip planning application that also uses the RAPTOR algorithm! It’s used in cities all over the world, with the biggest deployment being ENTUR’s in Norway, which covers the entire country. I believe all trip planning apps in Norway use this deployment.

It supports many features and has a very active developer community.

OTP is such a wonderful project! It's my go-to example of open source in government and it's so much more than a trip planning engine. For the country-wide transit app I'm working on (ok, it's a small country, but still), we use it as the database as well. We convert everything into GTFS(-RT), throw it into OTP, then have a fairly thin API layer that queries it via GraphQL and returns JSON for our app [0].

I also have to say the code is far more elegant and readable than what I expected from a 15 year old Java project. I had to fix a bug once and I figured it would take me at least a few hours to get my bearings in a codebase that size, but I managed to wrap my head around the core routing logic and fix the bug in an hour or so. The A* implementation for non-transit routing is such a good example of "enterprise code" done right.

[0] a shitty diagram: https://gitlab.com/derp-si/ojpp-docs/-/wikis/oJPP-infra/diag...

During university, we've built OptiTravel (https://github.com/denysvitali/optitravel) to do something similar. We couldn't use Google Maps APIs (project requirement), so we wrote a custom routing algorithm based on A* and I've created a Rust server to host GTFS data (https://github.com/denysvitali/gtfs-server) à la Transitland (https://transit.land/).

Performance wasn't great since everything had to run locally and do network roundtrips, but it found routes in my hometown that Google Maps didn't show. Pretty cool discovering hidden connections in the transit network and being able to customize your own params (https://github.com/denysvitali/optitravel/blob/master/src/ma...)

Before Citymapper existed, there was OneBusAway, a Ph.D. student project at the University of Washington.

It still exists and powers millions of transit rider trips every day all around the world in Seattle, Washington DC, New York City, Poznan Poland, Buenos Aires Argentina, Adelaide Australia, and who knows where else.

If you’re interested in hacking on something like Citymapper, or setting up an OBA server for your own city, you can find everything you need on our GitHub organization: https://github.com/OneBusAway

That includes docker images, an iOS app and a trip planner framework, android app, Sveltekit web app, and even a next generation OBA server written in Go.

As far as the data to power this, you can get GTFS for every US transit agency from https://mobilitydatabase.org/

(nb I’ve been involved in the OBA project since 2012)

and if you want to get involved, join our Slack https://join.slack.com/t/onebusaway/shared_invite/zt-32w08cz... or just shoot me an email! aaron@onebusaway.org

Thanks for your great work on one bus away. This is such a fantastic app for people riding the bus. It uses info from the bus system to tell you how far the bus is away from your stop. It deals pretty well with the messy dynamic reality that traffic can slowdown or speed up, or even a bus has to stop for some reason and so the next one will come.

Check it out if you are in one of their cities.

Thanks!

Citymapper et al are excellent. The big issue I find is that half the time TFL seems to completely ignore its own bus schedule (at least in my area). You rush for a bus and it leaves 2mins before schedule (and the next one also turns up early). I would rather longer waits and better predictability.

Im thinking it might be better to revisit the project and analyse long term patterns in bus arrivals

What would be the source of truth for verifying that the bus made it to the location on-time/late/early?

Potentially using the live arrivals APIs and seeing when its right now, not 100% it would work but might be worth a shot

In my previous town I had a bus so unreliable I'd rather walk 20 minutes in the sub zero temperatures - was supposed to run every ten minutes, but in reality there was no bus for an hour and then 5 in quick succession.

Very nice! I've also used the Rail Data Marketplace (terrible name) to build an app that uses the live departure board data (https://apps.apple.com/gb/app/traintrack-uk/id6504205950), and it's great the data is freely available.

Whilst HN is on the case, does anyone know of an API (inside Rail Data Marketplace or elsewhere) that acts as a journey planner for UK national rail, i.e. you can input source + destination stations and it will output journey options?

It looks like TFL's journey planner API has the ability to do some of these national rail trips, only tested a few though

Unfortunately, I believe it's limited to TfL stations only (e.g. Overground) rather than National Rail.

Oh, and I should have mentioned that I'm also aware of this, but it's not free so automatically outside of my app development budget. :/

https://www.nationalrail.co.uk/developers/online-journey-pla...

I tried a route from a London tube station to Newcastle train station and it found one on the frontend for the tool so I think it may support national rail

Comaps is also working on it, using public GTFS data : https://codeberg.org/comaps/comaps/issues/299

Check out api.tfl.gov.uk which should have everything you need for London in a more structured format.

I used this exact API extensively for both buses and tubes :)

Why are the table and the description of the RAPTOR algorithm in the article images rather than text?

Surprised not to find Motis and Transitous cited in the article.

Reply on news.ycombinator.com