Sound Transit recently hired an employee to deal with incident response and provide passengers with service status alerts from the Link Control Center. The rider alerts are better than nothing but sometimes you can have days like this or this when the number of rider alerts becomes overwhelming.
Scott Gutierrez at the PI reports on the recent proliferation of Link rider alerts notifying passengers of train delays. Sound Transit spokesman Bruce Gray explains in Gutierrez’s article:
The agency still is setting protocols on when mass alerts are necessary and when updating electronic signs at boarding platforms is enough to get the word out. A few times recently, alerts were issued about problems that were handled quickly and had minimal effect on service, he said.
On Monday morning, for example, an alert was issued about a mechanical problem that caused delays of six minutes to one train and three minutes to the other.
“That’s why we’re seeing a little more frequent rider alerts. We’re working out some of the kinks as to what rises to the level of needing a rider alert,” Gray said. “We probably don’t need an alert if it only means a five-minute delay.”
The problem is not Sound Transit providing too much information; it is Sound Transit providing the information in the wrong format. Having real-time train arrival information at stations (and elsewhere) solves the problem of issuing too many alerts for minor delays. Instead of posting an alert that trains are delayed 6 minutes, the delay is simply reflected in the predicted arrival times at each station for each affected train trip. If the delay gets severe, then broadcast an alert. While some might want to know why their train is being delayed, what everyone wants to know is how long the wait will be, which is useful information even under normal conditions.
Man, I didn’t see that the picture was a mock-up at first and got me excited! Dare to dream.
Same! If it were up to me, I’d knock off the NB/SB designations.
Completely agree on the status points — mass e-mail is only necessary with delays >20 min or service-stopping incidents. The signs will take care of the rest.
Also, open data please! :D
Amen, Brother! Why can’t we get these signs here?
Speaking of delays, does anyone how how many inches of snow or how severe the ice in order to cause a shutdown of Link? The Seattle Streetcar was shut down for several days after one storm in the winter of 2008-2009 due to thick ice on the tracks. Obviously Link is a different ballgame, but can we expect it down during “severe” wintertime conditions?
Martin on Link vs snowpocalypse: “The switch heaters that went in this spring, combined with running trains all night to prevent accumulation, should keep the trains running in the event of another snowpocalypse.”
Given the low clearance how do they deal with a foot plus of snow? I’d pay good money to see a Link car with a plow hooked up to the front coupler :)
Keep running the trains so snow doesn’t build up so high.
And how much do I get for this?
The plan for snow is to continuously run the trains during a snow event. (Like the ice trains we used last year, perhaps running 2 for the “down time” 2am-4:30am.)
We are working on criteria for running ice and snow trains.
It would be nice if the all night ice & snow trains were also in service and carrying passengers, like how TriMet does.
MAX and the Portland Streetcar ran throughout the Snopocolypse, so I heard at Rail~Volution.
The SLUT had to be closed down because cars and buses were packing snow and ice into the flangways. This could potentially derail the train.
The bright side is even a crazy snowfall of 4 inches/hour, a train every 15 minutes will push the 1″ accumulation out of the way w/o any issues. But the Link will run into problems at the embedded crossings along MLK. I would expect Link to have issues the first couple of major snowfalls until ST figures out its head from its own butt. Street and embedded running is always an issue for railroads in the winter. It’ll be interesting to see how Sound Transit handles it. They need a good ol’ fashion flanger and plow!
C’mon, Mike, you know better: Regardless of its name, a flanger won’t do anything for ice packed into the flangeways. (For those that don’t know, these pieces of equipment clear snow out from the area between the rails, down to 1″ to 2″ below the railhead; they don’t have any provision for digging into the narrow flangeway provided in embedded track ssections.)
I’d be interested in hearing how other cities in northern climates with street-running operations — such as Minneapolis-St. Paul or Toronto — handle winter conditions, and their “lessons learned” that we could apply here.
“I would expect Link to have issues the first couple of major snowfalls until ST figures out its head from its own butt.”
Actually, I think that would be Metro, since they are the operator.
So how did Tacoma Link fare during the last snow event?
There was no fare :D
I completely agree with the suggestion of real time arrival information. Implementing this should be a priority of ST/Metro (as I say in nearly every comment I make here!), and the signs are needed both on the platform level as well as the mezzanines. Please! Soon!
Oran, are you teasing us or is this a possibility? Did you present this wonderful picture to ST? I know a lot of ST folks are in this forum (maybe that recently hired employee should join). Is your mock-up actually do-able?
The signs can be programmed to display whatever they want to (you’ve seen that sign test video I shot) if they have the information, which they do. If they could run 2 minute and train arriving messages and this train to Seattle signs, they very well can extend it to a static continuous display.
Well then, what are they waiting for?
There’s a whole post about it. The big problem is that their contract with GE Transportation Systems doesn’t cover making this work, which is a horrible oversight. I disagree with the conclusion that it’s not feasible without more equipment, though. OneBusAway works off of AVL data, which I believe is analogous to track circuits in that the exact location of the vehicle is not known, just the time at which it passed a certain point. I think that applying the OneBusAway algorithms to the problem would provide a fair estimate of arrival time, especially considering that unlike buses, Link trains don’t operate in mixed traffic with cars.
I don’t know but of the reasons I’ve heard so far, I don’t buy them. They may have a good reason but so far I haven’t heard it, aside from lack of money.
Honestly, we are trying to get GE’s SCADA system running RIGHT before we can integrate this kind of signage into it. (Watch the “Next Train” signs at Seatac when there is any kind of service interruption.) I for one would love to see this work, if it was reliable and automatic. The system would have to know the schedules (including holiday changes.) or read the “Route Code” in the trains code box (assuming the operator has the correct code, not always true.)
Wasn’t one of the reasons unpredictability because of sharing the tunnel with buses? Then again, if they can make this work they can make it work vis-a-vis buses…
SJ, if your people are working on it, I applaud the effort. What Bruce Gray said in the post Matt linked to was disappointing, that “We do not have plans for continuous count down arrival clock.”
Buses are tracked in the tunnel. Look at the big white squares at the entrances and exits to the tubes–those are RFID readers. The buses have RFID tags to the left of the destination sign; usually underneath the wheelchair symbol.
Sound Transit acts like they’re the first agency to ever operate a light rail system. It’s mind boggling to me how badly they’ve screwed this stuff up. Over a YEAR and still no real-time arrival information. (Yeah yeah I know about the DSTT issues, but that should make it EASIER to figure out. Its a TUNNEL; what goes in must come out.)
They need to spend a week as *normal passengers* on the Max, Muni, SkyTrain, San Diego Trolley, and/or LA Metro to learn some lessons on usability and passenger notifications. Seriously, it’s almost like the guys in Link Ops have never seen another light rail system in action.
Mike, are you applying mass balance equations to real life again? :)
Jokes aside, I agree: The real-time status available on BART and SF Muni (either at the platform or via my smart phone) makes the travel process much smoother; when train frequency is cut during off-peak hours, I know ahead of time whether I need to rush to catch a train or can calmly stroll to the platform.
I love the Muni Metro next train announcements, they are so reassuring and pleasant to hear.
In Boston they’re currently implementing LCD’s in dozens of heavy-rail stations which show the real-time location of all trains on the line. The graphics are pretty horrendous, though the information is great for passengers. If other cities (such as SF and Boston) can figure out how to locate a train in a tunnel then you would think that Seattle would be able to as well?
Why does Muni say “Two-car train, M-M, in 10 minutes”. Of course both cars are going to be the same line. It sounds like a software limitation.
Not necessarily. Muni used to combine cars from multiple lines into a single consist for traveling through the subway and the reverse outbound. They don’t do that anymore.
Central Link Light rail has the nickname “VTA North.” Many of the startup outside hires are from San Jose’s rail system, so, on the operations side, we know how it is supposed to work. (I am from Metro, but I have visited the VTA control center.)
Oddly enough, VTA also doesn’t have real-time next train info at stations.
Wow that’s totally undeserved. VTA light rail is almost all in the middle of street with no discernible signal priority, and with very frequent stops that you have to pull a cord to get off at. It’s extraordinarily slow and it’s routing tends to be bad. And because of this, it has very low ridership. Link already has over twice as many riders per mile as VTA light rail (732 vs. 1571)
I’m glad Link was not built like VTA (or MAX).
This is especially an important point considering no one cares what the scheduled times are, as they’re mostly internal; they just know the headways.
Disagree – I want to know when the train is supposed to come at my stop, so that I can plan to be there at the right time. Luckily I saved my old timetable since the times haven’t changed. But it’s insulting that ST won’t publish their schedule any longer, especially during periods when the train runs less than every 10 minutes. But even during the 10-minute frequency it is very useful to know that the train is scheduled to arrive on the 6’s. I can plan my walk to be there on the 4’s and most of the time have a 1-2 minute wait. I don’t care if it is a minute or two early or late, and every couple of weeks there is an incident, if the rest of the time I waited 1-3 minutes instead of 9 or 14.
I would welcome such signs. But really, having overnight 30-minute service, and getting physical barriers (i.e. crossing gates) to protect Link from the illegal-left-turn dunderheads seem to me to be more urgent priorities.
Whatever everyone’s priorities, now is the time to write to ST and express your priorities. They promise to make the public’s input part of the SIP proposal to the board. It’s a much more input-welcome agency than Metro. (Are you listening, County Council?)
Those things likely cost much more money than getting these signs to work which will have an immediate benefit to all users at all times. This is a relatively low cost but high impact item.
Remember though that OBA works off AVL data, which is either acquired through GPS or wayside transponder. Someone pointed out somewhere that the Rapid Rides were not delivering AVL data as well, and thats probally because of the new INIT radio not talking to the old METS system, which is what OBA is based from. In order to add full AVL capability to LINK you’d have to piggyback onto the INIT system, and update OBA to read that data. Of course you’d still loose contact with it in the tunnels, where you might have to tie into the signallying system to get a location and for the equipment use odom readings to trigger the AVA.
Notice how the security guards carry radios in the tunnels (DSTT and Bacon)? There’s an 800 MHz radio system in both tunnels. There is NO reason why you couldn’t shove data over that. In fact, the Port of Seattle does just that with their STS trains.
You would not have to tie Link’s prediction system into METS–ST could just push a new service with Link real time info. Currently OBA uses (at least) two data sources–Metro and Pierce Transit. No reason you couldn’t add a third (or fourth).
data over radio is no problem. its getting GPS data in the tunnels that is the problem. you could use wayside transponders like the old mets system, but that would be some extra work. LA and NYC have such a system though that gives real time information, i wonder how their system figures out the locations of the trains.
They likely use data from their signaling system i.e. track circuits, which Link also uses for the 2-minute and arrival notifications. If it’s good enough for that then why can’t they extend it? I guess they are not confident enough in the accuracy but I’ll take something that’s ±2 minutes over nothing at all.
For crying out loud, it’s a fixed guideway in an exclusive right-of-way. Buses in mixed traffic put Link to shame.
Nice mockups. However, I’d prefer not to see Northbound and Southbound information mixed on the same display, as you have in the first example. The signs should apply to the tracks. Would there really be conditions when the same tracks would be used for NB and SB trains?
Additionally, if these can be kept separate, then repeating “NB” or “SB” just takes up room unnecessarily.
The combined displays were intended for mezzanine and entrance areas where you could glance at the sign and figure out whether you had time to grab a coffee before heading to the platform. For combined display, I’d change the large first train to small text to fit 2 next trains instead of one, for a total of 4 next trains. That might have caused the confusion.
I would drop the NB/SB if I redid it and if ST changed the announcements to say “next Airport (or SODO) train” instead of “next train SB” and “next Westlake (or Mt Baker) train” instead of “next train NB”.
Speaking of which, do people unfamiliar with Seattle really know their “northbound” from their “southbound”? “Inbound” and “outbound” make more sense in a way, or “Downtown” and “Airport”.
I prefer terminal names over directions. I only used them in my mock up because that’s what ST uses in their announcements. Inbound and outbound are nonsensical when you have a line that goes through downtown instead of terminating there. Is a train from the Airport to Northgate an inbound or outbound train or both?
Well we don’t quite have a train to Northgate yet.
LINK needs to abbreviate as little as possible.
The display under the “headline” has plenty of space for the word “NorthBound” or SouthBound” and these should be used, not a repeat of “NB” or “SB”. This would also further clarify to visitors (and new users) what “NB” and “SB” stand for.
Of course, someday soon we’ll have a “X-Color” line to Federal Way and a “Y-Color” line to Redmond, etc., the Kemper Klatch-nonwithstanding.