Now, nitpicking: When the badges move, the speed is not realistic. Of course, that's only natural, because it's just an update to its new position, it's not actual motion. But it's still jarring to see buses zooming across 3 blocks in 5 seconds. :)
Would it be possible to visualize the position update in a different way, to better suggest it's just a position update, not actual motion? I'm thinking, leave the badge in its old place temporarily, make a new badge that moves quickly to the new place, and leave a faint low-contrast or transparent "trail" connecting the two. Once the new badge is in the updated position, remove the old badge and the trail.
Basically, the whole transition should be much quicker, and clearly indicate it's an update, not actual motion.
Related weirdness--if you leave the tab running in the background and then return to it, all the icons drift from their position when the tab was backgrounded to their latest locations. Kind of reminds me of turning on the light in the kitchen and seeing cockroaches running for cover.
It can take 10-30 seconds for the map to catch up, and in the meantime the map is not very useful.
Maybe test for how out-of-date the map is and do a 'hard refresh' of position.
This is called dead reckoning[1]. Given the previous two locations you can tell the speed. Since you know the route the bus will take, you just plot it where it would be if it never stopped moving since the last update. It's pretty close 90% of the time.
This map would be more useful if instead of each bus being represented by a nondescript MUNI logo, that it was an icon that contained the route number. As it stands it appears the only way to get useful information is to hover over each logo to work out what it represents.
I guess this gives nice visualization to the deplorable state of Muni. Right now I see nine L trains clustered basically on top of each other in the Sunset.
Maybe one between market and West Portal and one on market near Embarcadero. I take the J and as usual I see independent cars running outbound right next to each other with unusually large and sporadic gaps between them.
Hard to believe $820 million for such a shitty service.
This is possible because of the NextBus API, where apparently NextBus is a private contractor used by many cities solely to provide this info.
If you click on "Select your transit system" on the NextBus website and scroll down for NYC, you'll see that the MTA's Brooklyn, Staten Island, and Brox services are covered (as well as the private "Downtown Connection" bus service in lower Manhattn) but that the normal MTA Manhattan service isn't covered. Does anyone know why? Maybe it's just in the process of being rolled out?
NextBus was an east bay startup in the first dot com boom, actually, and my second job out of college. Muni was one of the launch installations. We were watching stuff like this (albeit with a decidedly clunkier hand-cooked map instead of Google integration) way back in 2000. I left in 2003, and they were acquired (without profit -- only investor shares were converted) a few years later.
Still, we didn't fail spectacularly, which says something. And going on 15 years later it's fun to see a bunch of my old code still running and doing useful things for society.
MTA has "bus time" which is not like nextbus in three important ways:
1: it is not a scam run by money grubbing jackasses to keep public data for private profit.
2: it is built entirely from open source software, and all the data is accessible with an open api.
No idea, it's a similar issue with the busses in LA, all of those that cooperate with the LA metro system are on nextbus, but the few that don't (santa monica) aren't on nextbus at all. I suspect it has something to do with cost of the hardware that the busses have.
Yup. Two car trains for some reason are a hack into pretty much every part of MUNI's systems. Thats why in the underground stations you used to hear "N N in 3 minutes." The audible announcements have since been updated, but the old arrival displays that show the screenshot of the control center computer (the squares on the teal lines) still show two car trains the same as two different trains very close together.
Love this, to chime in with suggestions, something with color indicating inbound/outbound would be awesome for seeing through some of the noise. Love the line selection idea as well.
No not yet—the actual route/path information is currently decoupled from the views and animations. Probably shouldn't be too difficult pull the information for published routes as well as do some processing on historic movement. Pull requests gladly accepted :)
I just downloaded the iOS app, and you aren't really missing much. It looks like a proof-of-concept for using Firebase SDK, not a real intended for users app.
Crashed twice within the first few minutes, just a bunch of pins floating around SF with no indication of route, etc.
MUNI buses, except perhaps first thing in the morning, are essentially never on time. You can't go by any published schedule (which I assume is why Google Maps predictions are essentially random numbers)--you have to go by the NextBus real-time data.
I don't think the concept of "on time" even exists for MUNI. The route may have a defined start and stop time, but that's it. Throughout the day you can get estimates of the average time between two busses on the same route, and I have to assume that data is used to manufacture published schedules, but the schedules don't actually represent anything real.
You are correct. MUNI schedules are defined by bus frequency, not a timetable. Trains/Buses come every 10 min from 7-9am (for example), every 15 min. from 9-11am, etc.
So what data is Google Maps using for its predictions then? It's definitely not the same as nextmuni (at least last time I checked), and in fact seems much worse. I had always assumed there was a schedule and that Google was using it.
In some of the older bus stops there are approximate schedules. Before the stop near my apartment was removed it seemed to match the data on Google maps.
Google maps is much worse than nextmuni. It's one of the first things I was warned about when I moved here.
Now, nitpicking: When the badges move, the speed is not realistic. Of course, that's only natural, because it's just an update to its new position, it's not actual motion. But it's still jarring to see buses zooming across 3 blocks in 5 seconds. :)
Would it be possible to visualize the position update in a different way, to better suggest it's just a position update, not actual motion? I'm thinking, leave the badge in its old place temporarily, make a new badge that moves quickly to the new place, and leave a faint low-contrast or transparent "trail" connecting the two. Once the new badge is in the updated position, remove the old badge and the trail.
Basically, the whole transition should be much quicker, and clearly indicate it's an update, not actual motion.