Never Missing the Train Again
lilymara.xyz
lilymara.xyz
If you live in a city that already has a OneBusAway server[1], you can use one of our brand new SDKs to build your own custom app experience: https://github.com/onebusAway/?q=sdk&type=all&language=&sort...
If you live in a city that DOES NOT have a OneBusAway server, we've spent a ton of time and energy this year building Docker images and OpenTofu configurations[2], which will allow you to take GTFS and GTFS-RT feeds and turn them into an easy to use REST API.
I know that BART provides GTFS and GTFS-RT feeds: https://mobilitydatabase.org/feeds/mdb-53. Similarly, every other transit agency in the United States should now be publicly sharing at least their static schedule data as GTFS due to a newish federal rule.
Also, if you're interested in hacking on software like what I described above, or on our end user-focused software, we always need more developers to pitch in—all skill levels and essentially any language.
In particular, we desperately need an iOS developer to help our 250,000 daily users get some much needed improvements.
My email address is aaron@onebusaway.org. Reach out!
----
[1] New York, Seattle, Washington, D.C., San Diego, Alexandria, Victoria, Adelaide, Buenos Aires, etc.
[2] Docker: https://github.com/OneBusAway/onebusaway-docker and OpenTofu: https://github.com/OneBusAway/onebusaway-deployment
How do you find a list of places it's deployed. I tried Googling "onebusaway cities" which got me this page https://onebusaway.org/onebusaway-deployments/ but that doesn't list cities like Adelaide that you mention.
[1] New York, Seattle, Washington, D.C., San Diego, Alexandria, Victoria, Adelaide, Buenos Aires, etc.
I was trying to figure out what "etc." meant.
Having said that, I'd add my city if it were straightforward. It looks like you've spent a lot of engineering time in library and SDK support lately - I suggest investing in the DX happy path to encourage new folks to invest their time.
For example, this document is rather complicated https://github.com/OneBusAway/onebusaway/wiki/Multi-Region
No one can predict the traffic but in my daily experience it is reliable to the minute
> Or “delayed by 5 min” and it’s early by 2, etc.
This, in particular, you can never really trust, especially for buses, no matter who's telling you it. If a bus is delayed 5 minutes, and has the opportunity to make up the time, it will. If a bus is delayed by five minutes, but there's no-one at the next five stops and no-one wants to get off there, it may well be on time by the time it gets to the next stop. In many bus systems, buses will sometimes just stop to avoid getting too far _ahead_ of schedule, though.
In my experience in NYC, the subway data is extremely accurate in terms of the minimum time until the next train. The subway virtually never arrives "early".
Buses seem to have a problem where their location transmission sometimes fails for a few minutes. The system always assumes the bus is still stuck at its last reported location rather than moving. That's why you get a bus arriving when the feed says it's 4 minutes away.
A good rule of thumb is that if you see the minutes away change, e.g. from 7 to 6 minutes, it's accurate. If it's not changing (e.g. just sits at 7), it might be because it's genuinely stuck in traffic, or because it's stopped transmitting. (Which explains the "delayed by" situation you describe.)
For example, I walked my son to school before heading to work, and sometimes I got breakfast after dropoff. Having the "next departure" view let me have a more fluid experience that handled the non-deterministic nature of walking with a 4 year old in a very interesting place, or deciding whether to hustle to get the train because missing it hit a schedule gap, etc.
So much better than the official app, it directly shows exactly what is most needed, closest bus-stop with live times for next busses.
https://ukdepartureboards.co.uk/store/product/desktop-depart...
LOL, this must happen quite a lot to them.
I'm working on some hardware in this space (I've been up to my eyeballs in GTFS lately) and I can tell just how much went into parsing and presenting the transit data.
If you're willing, I would love to chat about some of the UX decisions you made - specifically in summarizing and grouping the trips available at each stop, and your backend!
You can just point its web browser at any webpage you design, and disable the Kindle's "screensaver" (its ads or sleep screen) with debug commands [1, 2].
You'll be stuck with a browser bar along some edge of the Kindle (you can rotate the device orientation to put it at the bottom or right edge), but it's a small price to pay for being able to write your weather/transit/news screen in easy HTML/CSS/JS and whatever backend language you want, and run it on a cheap DigitalOcean $4 instance or whatever.
[1] https://blog.notfaqs.com/2018/06/kindle-e-reader-disable-scr...
[2] https://www.mobileread.com/forums/showthread.php?t=198334
;debugOn
~disableScreensaver
;debugOff
~ds
But last I checked was a couple of years ago. I'd be very curious if anyone can report it not working. (Also note the command doesn't survive reboot, you have to re-disable after rebooting.)
Older models still support ~disableScreensaver -- at some point Amazon just stopped issuing firmware updates for them, I have to assume.
[0] https://old.reddit.com/r/kindle/comments/u8u7up/disable_auto...
That's often the case, things going from good to worse. Cf. the removal of Manifest 2 on Chrome for instance.
As a kiosk-like display, though, they do have that keyboard taking up space.
I only use my Kindle to read outside (at the beach or pool); in the house, my iPad is faster and has a bigger screen. But in the sun, it’s useless. eInk is far superior for that. For the week or two a year that I need one, my 15-ish-year-old Kindle is fine. I travel with a laptop and tons of cables anyway; sideloading just means a few minutes of work after dinner to make sure there’s enough on there to read tomorrow and isn’t much slower than using the internal interface to get books was.
I do miss the free 3G. Obligatory XKCD: https://xkcd.com/548/
Like I totally understand why they wouldn't for new Kindles, since I assume part of their ebook sales help subsidize the hardware, but if they enabled it once a device hit 5 years old or something, I don't see what they'd have to lose.
If there is a cost or liability, then most businesses will avoid doing it.
There usually has to be a clear financial benefit: businesses should make profits - they are not social services or hobbies.
Fortunately businesses contain people and people often do altruistic things for non-financial reasons.
Alternatives are especially important in other cities. In Tokyo if I want to go from Shibuya to Azabujuban I can take
* Ginza Line->Namboku line - advantages, (1) Ginza line starts at Shibuya so guaranteed a seat if I wait for the next train - though only for 4 stops where I have to switch (2) both lines are same train company so $1 cheaper
* Hanzomon Line->Oedo line - advantages, fastest
* Yamanoto line->Namboku line
* #6 bus - advantages: no changes, disadvantage, slowest
* taxi - advantage: fastest if there's no line for taxis or if I'm confident I can find one quickly
Extra considerations. Each line's station and the bus stop are 3 to 8 minutes walk from each other so if I'm closest to one that would weigh on my choice. Speed matters too, if I'm late. If I have large or heavy packages I'd be more likely to take the cab. Etc....
The use case is routine. A lot of people, most of the time, do indeed want to "take the train". Heroic feats of real-time planning have their place, and it's great to have tools that help you with that, but routine can be covered with much simpler tools just as well.
Even in the Tokyo scenario you gave (which is fascinating -- thank you!) Google gives 30-40 min. for most public transit options, so for rough planning they're all equivalent. Taxi is faster, and bicycle is almost at par.
you're out drinking - which mode is last. you're on the east side of X, which route is closest. you're tired, does any route guauntee a seat. etc....
Berlin, London, Paris, Tokyo, Singapore, Kyoto, Osaka. All this way . there is no "one train"
Hello! Now you have.
In many cities certain parts of the transit network follow a star / hub-and-spoke layout. The station nearest to my house is on a spoke, and has trains going south and those going north. So for me, an in-home train display only really needs to show the next train in each direction.
And a lot of transit decisions are conditional on things the planning app doesn't know. Am I comfortable riding a hire bike, appropriately dressed, and carrying a helmet? Do I already have a return ticket for the light rail making it the obvious choice? Am I the kind of person who enjoys a brisk 20 minute walk?
Combine that with the fact that the multimodal transit apps don't understand fares, and I find it's simpler to just start the taxi app if you need a taxi.
Kakao Maps will give you exact timing and fares for every mode except air
> In many cities certain parts of the transit network follow a star / hub-and-spoke layout
Yeah those who live on a spoke and mostly go back and forth that spoke are a minority because the farthter away from the center the more space between the spokes:)
- bus/train/tram crosses my stop 5 times a day - its trivial to learn the 5 times
- bus/train/tram crosses my stop more than 5 times a day - i just show up at the stop and wait
Perhaps my point of view is like this because I'm in Europe, I can't tell really.
One thing I find is that Google Maps really, really assumes that walking is very very bad and no-one wants to do it. So for instance, if I'm going to a particular place I will get a 39 bus and then walk 15 minutes. If I ask Google how to get there, I'll get a route with two transfers; if the stars align it'll take about as long as one-bus plus walk. So if I want Google to tell me when the 39 bus is coming, I'll have to lie about where I'm going.
(Also, at least where I am Google's realtime data is questionable, with the data from the operator and some other third parties being more reliable.)
Indeed, they assume all kinds of things - with no option to customize. For example, they assume that a 1 or 2 minute transfer will happen. Which you might want to override, but can't. You have your reasons to want to route through Caltrain instead of BART... and you can't. This is a characteristic of the brand really: Google people know what's good for you. I mean, them.
If the train is broken or the workers are on strike, that will be reflected in the unexpected absence of live trains listed.
I pull up Google Maps and plug in my destination when I'm running around the city. I don't pull it up when I'm leaving my home to go somewhere I've been 500 times before.
Lots of features but I'm not sure how many are available in Tokyo to be fair. In London I can ask it to take me home and get presented with a list of methods that optimise for cost, walking distance, speed, changes, accessibility, etc.
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.
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!
Totally understand how some loved the ability to compose/respond to messages, but that never made sense to me.
Garmin, Amazfit, and BangleJS comes close, but #buttons, #battery, and #b&w (well, always on, transflective, sunlight readable)
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.
(In a highly networked place like London, seeing all options is helpful)
Feedback appreciated!
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."
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
> Next, since we’re not relying on a browser engine to render the display, we will be using a 2D graphics library to render a PNG directly. This should have a much lower resource cost than using an entire browser engine, at the cost of some decreased flexibility.
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
So then figuring they had to effectively redo it from scratch with a new solution, they then switched over to a language and stack they enjoyed, which seems completely reasonable.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
edit: Just beaten and directly from the author it seems. :)
A 4.37inch E-Paper in 3 colors is $24, problem is need you to program yourself (they have code sample in python, for raspberry pi), and you need a raspberry pi, case, cables, etc.
Also, these cheap epaper displays are, of course, of lower quality (slower, lower resolution) than an kindle display.
> like most truly useful things we need to build it ourselves
but I was surprised that the author insists on displaying an image on the Kindle. The last third of the post is dedicated to building that PNG file. Is it possible to send text? It would be easier but maybe it's not possible...?
Instead of a specific schedule, there is a bus/train every "n" minutes.
I plotted bus locations in matplotlib, which was what I knew at the time.
The busses would clump up where I lived, so it was helpful to know if I should rush breakfast to catch a burst of busses or just wait for the next wave.
I also didn't know that skia had rust bindings and it seemed pretty easy to setup.
It's been a nightmare to try setup in c++.
If anything goes wrong with a train journey I find it useful to have as much information as possible.
When I was involved with the Green Party we were thinking of “just doing” the things the local government wasn’t doing and I think we set a fire under the bus company’s butt to fix a large number of usability problems that we were going to fix for them (and stick our logo everywhere.)
The bus company was very negative on us extracting schedules from their web site because they wanted to see what people were searching for — hypothetically they could have added new service somewhere if there was demand for it but (1) it seemed hard to believe they’d really do it because changes are so infrequent and (2) they never showed any sign of caring what people thought, why would they start now?
I wrote something similar on a smaller scale for the keihin-kyuukou line in japan: https://rail.esrh.me. Now I live in tokyo and there's several transit options closeby so I would love to have some always on display like this in my room.
Unfortunately, while public transit in the US and Europe seem to be tracked by services with developer friendly APIs, this is not the case in Japan as far as i know -- not that much of a problem back then, i just needed to do some light web scraping.
I wrote all of the scraping/data and processing/frontend code in clojure and clojurescript, and wrote a small blog post about it here: https://esrh.me/posts/2023-03-23-clojure
Transit App (https://transitapp.com/) is one of them and I freaking love their interface overall. This app's default view shows you the next bus (in either directions) at the 3-4 transit stops closest to your current location. And you can customize/add favs too. It's a beautiful app, also allows for multi/mixed-modal route planning (part walking, part bike, part bus).
i would kill for the transit app experience, with an eink display, and battery measured in weeks
B. Super cool article! I've an old Nook somewhere being neglected which I am now moving up my list of devices to do some messing with and find a use for. Excellent stuff.
"When the regular buses aren't running, he busses people around in the minivan."
-- https://www.merriam-webster.com/grammar/plural-of-bus
Went ahead and used Google Ngram viewer to show the popularity difference, with some context-words to ensure it's comparing cases where a plural noun is being used:
https://books.google.com/ngrams/graph?content=the+busses%2C+...
https://books.google.com/ngrams/graph?content=multiple+busse...
https://books.google.com/ngrams/graph?content=took+buses%2C+...
Of course, if USA-based anglophones want to continue using a particular spelling or pronunciation, we know we don't have the power to stop them. I bow out of this one.
The point I believe the parent post is making is that you cannot assume that buses would rhyme with fuses, because English orthography is so inconsistent.
Which is partially true - I haven’t seen any research to the effect, but I’d guess you can still predict the pronunciation of an English word with better than a fifty percent chance of success.
The fact you think "busses" is a preferable spelling to "buses" because it might help you pronounce "buses" differently to "fuses" is only relevant to you yourself. I would have thought this was tautological, myself.
In summary, we could avoid all these fusses with a bit of effort to adhere to accepted usage.