If you want a transportation app built for locals I highly recommend Transit. When you open the app it shows you the transit options closest to you, where they’re heading, and when the next one arrives. Never have to put in a destination.

Super cool. I did the same kind of thing with my tidbyt display:

https://github.com/pkulak/tidbyt

My local transit agency (Trimet) is _really_ good with their api. It's public, and a single HTTP GET to get the ETA on every bus that serves a given stop, so it wasn't event that much work.

R.I.P. Pebble:

https://developer.rebble.io/developer.pebble.com/community/a...

""" Caltrain is a Pebble app that displays upcoming trains at a station, and where those trains will stop along the remainder of each of their routes.

Finally, it uses PebbleKit JS to retrieve your location on launch. If it gets a response before you manually choose a station, it will automatically show the station closest to you. """

...you could literally map that "applet" to long-press on a button, and get the info in like 5 seconds.

For extra "dick tracy" spice, call an uber from your wristwatch with 3-4 clicks (long-press, ok, next, ok => "your uber will arrive in __ minutes"). Actually, reviewing the app docs, it looks like it was only two long-presses to request $LAST_USED_CAR to $CURRENT_LOCATION.

https://www.uber.com/blog/pebble-smartwatch/

https://pebble-help-legacy.rebble.io/help.getpebble.com/cust...

Buttons, people! Buttons!

When realtime information was first available from my public transit system, it was via an SMS system that was widely advertised at every bus stop and train station, wherein each received a five-digit ID code. So you'd text that code to a special number, and it'd reply with the "NextRide" timings.

Unfortunately, it was wildly inaccurate. Every time I queried it, it said the bus had already left (I'd been standing there 10 minutes) or it didn't take into account active detours, or something. The only thing it was good for was determining the headways between buses (15, 20, 30 minutes?) and then you could at least calculate your longest wait at that stop.

The next iteration involved installing the bespoke and quite buggy app provided by the transit authority themselves. Now this theoretically depended on the same GPS trackers in the coaches as the SMS system had. But I had major troubles with the app, and I didn't like it, and it barely did anything else, and so I uninstalled it. And I did without it for a while longer.

Now the app is improved, and it's got QR pass technology included, so I reinstalled it, and I use it more. But, for tracking the buses, I prefer Google Maps.

Our transit authority graciously shares 100% real-time tracking info with Google, and you can track any bus in Maps, including crowdsourced info, such as "How crowded? Is security aboard?"

It works really well, and really accurate; displays every delay and updates by-the-minute as buses or trains pass each stop. Sometimes I pass the time just sitting there and watching my bus make its way down the street.

I love the premise and I felt that a lot in SF. The transport system is not really a complex enough network that I need to be shown routing options. Just wanted to know when to leave the house and not stand at the stop for 20 minutes :’(

(In a highly networked place like London, seeing all options is helpful)

I made a (free and ad free) app for BART that tells you if you need to run to catch your train or not. Instantly upon opening the app, without needing to tap anything, it automatically figures out which train you want and helps you hurry, just a little bit, to make the next one rather than wait.

Feedback appreciated!

https://apps.apple.com/us/app/should-i-run/id933717076

Wow what a cool writeup. Two things stuck out for me (I'm only halfway so forgive me if you address these issues). I have two comments on processing the 511.org data. First, you generally want to use a streaming parser rather than one that allocates memory to the entire response. Second, you should filter out the most data first (in this case, dropping the stops you don't care about) and then filter the least data second (dropping the fields you don't care about). This idea is similar to how, in SQL, you want to order your WHERE clauses such that the most impactful comes first.

This may not be strictly required by your use-case at this scale - 27MB of data is not a lot, after all. And the filter ordering performance is probably trivial given its all in memory (I'd be curious to see a benchmark!) However, a) efficiency is always good, especially on a Pi, and b) if you make the code more efficient it makes it easier to scale later if you want to.

Also, regarding the BOM problem you had, wouldn't it be nice if all APIs had a "developer feedback" mode built into it? That is, you can send feedback to the ppl who own the API endpoint by...posting to the endpoint. In this case you could send "Please remove the BOM. k thanks."

I love how they blamed the flake on node and Javascript, then switched to Rust and also changed the whole approach, which had a hundred times more effect than changing the language did.

Not to diminish OP’s project, but the stated goal of “know when each transit line has an upcoming train/tram/bus” is probably already achieved by https://transitapp.com/ - the default view when you open the app is a list of nearby transit lines, sorted by distance and showing the next departure for each.

It ought to be easier to get a blank slate of a small device with some compute power and a screen, like the Kindle here, without having to jailbreak something.