March 5, 2007
I Wish...
Let's just say, for the sake of argument, that we caught wind of a rumor that the NextMuni website is headed for an upgrade in the very near future. Ooh, that would be lovely news, wouldn't it? It sure would be swell if all of the electric lines suddenly became available on the site. What a dandy state of affairs. Huzzah.
However. That's not to say that NextMuni's work would be done. Oh hell no. There's still a boatload of fixer-upperring to be done on that site. (The graphic design alone looks like something we cobbled together with Frontpage in 1997. Compare that to the shiny web-2.0ey goodness of Boston's MBTA.)
So, readers. If this strictly hypothetical upgrade were to happen in the next few days, and you were in charge of getting the word out, designing methods for presenting the new NextMuni data to riders, and generally sprucing up the website, what would you do? What's on your NextMuni wish list? Here's ours:
- Communication. Feedback. Not a form that gobbles up messages and never responds, but a forum for riders to communicate back-and-forth with the NextMuni team. An engineering blog would be ideal.
- A map of where all the LED prediction signs are, and a schedule of when each stop is going to be getting its prediction sign.
- A text-message-based predictor, allowing riders to get arrival predictions for any stop without needing an LED display. At each Muni stop, there'd be a note on the Muni map that says, "For this stop's arrival predictions, text '18th & Castro, East' to 415-Next-MTA." That way, you can get predictions for stops that don't have an LED sign, and you can get a prediction if you're at a store or a bar down the street from a stop.
- It's been said that the arrival times may be "stale" by up to five minutes. If that's the case, the website should let riders know. The NextMuni page has a note below the times that says "Valid as of 4:27 PM Monday, March 5" ... it would be great if the arrival estimates on the map had a similar time stamp, so users know how old the numbers are.
After the jump: Invisible buses, XML-scraping for home brew hacks, and a secret list!
- An engineer asks that Muni provide API-like information for developers. He writes, "I'd like to know how links like this work: 'http://www.nextbus.com/s/COM.NextBus.Servlets.XMLFeed?
command=vehicleLocations&a=sf-muni&r=22&t=0&key=1947645158130' and how to go about getting XML data for routes and bus predictions. ... I think there is something similar to nextbus in Seattle, but they allow anyone to make a SOAP call to get bus predictions. There is a cool site called busmonster.com that makes use of this. And interestingly, looking through code from nextbus.com, it looks like they use code from the guy who runs busmonster.com!"
- There should be prediction signs at the entrance to underground stations, not on the platform. With the signs on the platform, you have to go all the way down to see if there's a train coming. But if they were at the entrance, riders would know whether or not it's worth their time to enter the station.
- The LED signs in the Metro stations should have arrival times on them more frequently. Currently, arrival times only appear on those platform LEDs about 10% of the time. The rest of the time, they've got lengthy messages about proofs of purchase, about giving up seats for the disabled, and even promises that the signs will offer up arrival info ... but you've got to stare at them for five minutes if you want to catch the fleeting prediction message."
- The Nextbus display in the subway windows (the Javascript-based map) is very hard for riders to understand. You have to study it to figure out how long you'll be waiting. The maps should be zoomed in closer to the individual station, so that the trains don't all look like they're on top of each other. And there should be a big "NEXT TRAIN" indicator that doesn't care about which line it is -- many riders are just traveling between Church and Embarcadero, and don't care whether it's an N or a J. They just want to know when the next train is coming. Currently, they have to sift through about six different numbers to figure it out.
- NextBus suffers from "invisible" buses now and then: buses that don't show up on the map, but are in fact out doing their runs. That needs to stop. When riders call the information line to get a prediction, the person on the other end usually compensates for "invisibles" by manually checking a list of which buses are out doing their runs. That list exists independently of NextMuni, and though it isn't able to track the current location of the buses, it does verify that a bus is in fact out driving around. The existence of that list is not widely known among riders. And even though the "secret" list doesn't offer arrival estimates, it is still useful for riders to know that when the GPS system is predicting a 30 minute wait, the wait might actually be more like 15. It's hard to say how that information could be presented on the NextMuni site, but it's useful and valuable, so a way should be found to make it available to riders.
- The NextMuni website should have a "report bunching" button that sends an alert to the Dispatch office, so that the drivers can be radioed and told to space themselves out more evenly. Currently, bunching is habitual and chronic, and it seems as though nobody is monitoring the GPS maps to correct it. Dispatch can coordinate evening-out; for example, if the gap is ahead of the bunching, Dispatch can tell the first bus to unload all of its passengers onto the second bus and drive ahead to fill in a gap; or if the gap is behind the bunching, Dispatch could tell the first bus to wait for the second bus, accept the second bus' passengers, and the second bus to wait for a few minutes to close the trailing gap. Thinking about this is so complicated that it makes most folks' heads hurt, but the bunching is even more painful.
|
I (VERY RELUCTANTLY) have linked to the half-assed not yet ready for primte time MUNI/Nextbus page that Rescue MUNI put out as a "service" just because people kept asking me about it. But there's a reason it's not public - it is WRONG on some lines more often than not. Hence, the reason for the slow rollout.
How about an online betting site?
I wrote some Python code last year to grab and parse the Nextbus XML. They changed some things around and it doesn't work anymore for the non-public trolley lines (it used to), and I don't have time to maintain it. Still works for the lines where the data's public. Anyway, I posted the code
here">http://www.joegratz.net/archives/2007/03/05/nextbus-python-script/">here
.BART has the same damn problem with the signs. You have to stand there almost until your train comes staring at a sign telling you all sorts of useless and well-known information in the hope of catching a brief glimpse of expected arrival times. The signs should always show the current arrival time along with the current time.
Very interesting post, Matt.
Last night, I was taking the 33 from Castro to 16th and Bryant. The one I was on made all of us get off at Mission and board another bus that had caught up to it. The first bus went to Bryant without any passengers and then stopped. The driver of the second bus was PO'ed about something and it seemed like they were about to argue, but I had to get where I was going.
On the way back, I caught a gap in service as there was no 33 for over 24 minutes and no 22 for over 30 minutes. I had checked the times earlier and a 33 had been predicted but the prediction changed while I was finishing up. Weird.
Here's the Rescue Muni page:
www.rescuemuni.org/nextbus-pda.html
Yes, there are occasional errors, but I find that these work pretty well. Close enough for government work, right?
i rely on the 33 for my commute, and while it's usually reliable enough in the mornings, in the evenings a half-hour wait or more is all too common. i usually just end up taking another route altogether out of frustration.
and i've tried several times to use NextBus to gauge the 33's arrival and it has *never once* been remotely accurate.
I live just above Market street so I was able to test out NextMuni for the F line and I have to say for that line it was pretty much right on time. Later on when they add more lines to the system I could check into it more.Yeah I lead a pretty exciting life I know.
First you say, "There should be prediction signs at the entrance to underground stations, not on the platform." Then you go on to mention the "Nextbus display in the subway windows," being hard to understand... but those are the predictions at the entrance you wanted! They may be more difficult to decipher, but there isn't a need to enter the station to see predictions; they're there in the agent booth, before going through the turnstiles.
You can already use the RescueMuni PDA NextBus page and a service called TextMarks to accomplish what you were talking about. In 2 minutes I created a JCHURCH24IN and a JCHURCH24OUT that work great... er, as well as NextBus works great.
Simply text "jchurch24in" or "jchurch24out" to the number 41411. You get the current information back. If you want other routes/locations, you'll need to get up off your ass and do it yourself.
If riders demanded that SFMTA give them SMS access to NextBus data then maybe they'd set aside some money to do it. Otherwise they may be researching more cost effective methods (ESP, using carrier pigeons, or smoke signals, etc.) to get that information to the rider.
I think that it is probably better to have a working transit agency than web 2.xxxx gadgetland. Remember, you can always send a comment or suggestion to sfmta.com
The prediction signs should be at the street level. Nobody wants to have to walk all the way downstairs just to find out whether they should've stayed up on the street. Especially at Church St, where the walk from escalator to arrival sign is rather lengthy.
I'd be relatively satisfied if Muni directed people to TextMarks, since that service seems to do the job rather well. Part of having a "working transit agency" is having info where riders need it, and web-2.0-ness, done right, is a good way to accomplish that. But don't even bother telling people to submit suggestions to SFMTA -- I have never, not once, ever seen that accomplish anything.
In regards to the "engineer" who posted the
if you look at the link and can't figure it out.. you're not a very good engineer.
vehicle (Bus) 5474 is on route 22 at lat=37.. long=-122.... The last GPS report was received 8 seconds ago. It has a heading (for map display) of 165 geographic degrees.
So, why not go to the source? Easy. NextBus is using Java servlets on their side to send information to your computers where the NextBus Java applet is running. Unfortunately because they're using the built-in serialization shit, you're pretty much SOL as far as trying to decipher the information being sent to your computer. That is, of course, unless you write something in Java. Something that makes use of NextBus's own Java classes (see also the text message thing on SFist).
So, one could, in theory, write a small Java application that uses the NextBus applet to send requests to the server (you don't really need Java for this part), and is then able to decode the response (this is where you need Java), and then use one of the many freely available classes that will dump Java objects into something more easily understood like XML.
Or, you could change the NextBus HTML around a bit, put it on a web server somewhere (or fiddle with endless Java security settings) along with a copy of the NextBus Java applet. Bam. You've got their "administrative" map. You know, the one that shows all the "hidden" routes.
That's the easy part. Getting accurate predictions, that's the hard part.
For the record, I loathe Java, and I think that NextBus (while a good idea) is pretty horrid in its implementation. Security through obscurity is never a good idea.
That said, SOAP? No no no. No. NO. The most straight forward thing to do, IMO, would be to just provide URLs where one could download periodically updated info on everything. If you want buzzwords to keep you warm at night: REST. If you really need the complexity that SOAP brings, settle for XML-RPC. XML-RPC is way lighter weight, and for the purposes of NextBus queries, it would do just fine.
Hell, I'd even endorse SOAP if it meant that there was a semblance of interoperability between the various transit agencies around the globe providing live information. Cause... really.. that's what's needed more than anything else.
Oh, my wish list? Fix the damn subway station signs so that they don't go bezerk (or blank) when a J rolls thru. Fix them so that if the train is really not heading to the end of the line (say Balboa Park), the overhead sign indicates that. Fix the overhead signs at Montgomery so that they work, period. Sheesh.
there is the 511 service that lets you get stop info from your cell phone but last i checked was only for the trains. Otherwise since most cell phones now have internet access useing the internet is a lot easier than trying to text for time. I have made my own web sites /bookmarks for the stops i use the most and otherwise navagate thru the next bus menu, it works great. (most of the time)