Elevating Chicago

« Train Tracker Beta is Running An Open Letter to Gabe Klein »

Train Tracker Thoughts

Ted Rosenbaum

Former athlete, full-time engineer. I'd tell you more but I'd have to kill you.

As you've probably heard by now, the CTA will introduce a Train Tracker pilot program in the next month or so.  This is, undoubtedly, terrific news.  But until we get further details about the system and can play around with it, I'd like to present some ideas/potential pratfalls for the new system.

traintracker screen shot.gif

--Location, location, location.  How the CTA places these screens at stations is vital to their usefulness.  Obviously one at platform level is vital--always good to know how much longer you'll be standing in the cold.  The question is, where should the street-level screen go?

I'd say there are really only two locations to choose from.  One, facing the fare gates (or just outside them) and clearly visible before you pay your fare.  The second is physically outside the station.  For elevated stations, the station entrance is usually directly below the tracks, so a screen that is visible as you approach on the sidewalk would be protected from the elements (and could be protected from birds easily enough).  Similarly, at subway stations, a screen visible before going below ground would be best--though since most stations have multiple entrances, the cost of placing a display at every one may not be worth it.

--Online.  Since this is only a pilot and there won't be displays at every station, making Train Tracker easily available online is the only way most riders will interact with the system.  And most of those people will be checking the site on their mobile phone, so it's even more crucial that the interface be top notch.  Washington, DC does a fantastic job in this regard.  Here's their mobile site.  It's easy to navigate and almost entirely text, so it loads quickly, even on a slow network. The only thing I'd add would be an auto-refresh option--if the arrival times will update every 25 seconds, set the refresh period to 30.

--Open Source.  Considering the success of 3rd party applications (not to mention the manifold uses for the Bus Tracker API), there's no reason not to release the QuickTrak/Train Tracker data similarly.

--Depth of Information.  Looking at the mockup screenshots the CTA includes in their press release, it looks like we'll get 6 pieces of information: time of the last update, current temperature, line, direction, run number, and estimated time of arrival.

I'd push for 2 more pieces of information: one, give the update time down to the second.  I know the ETA isn't necessarily going to be accurate down to the second, but keep in mind: if the "as of" time is only accurate to the minute, and ETAs are accurate to within 30-45 seconds, you're looking at almost a 2 minute margin of error.  The CTA says the displays will update every 20-30 seconds, so why not tell us exactly when it last queried the system, and cut the margin of error in half?

Second, the displays should include the number of cars in the train that's about to arrive.  It may seem like a small thing, but if you know the length of the train, you can figure out whether or not you can spread out from everyone else along the platform, without having to catch up to the final door as it slides by you.  I actually asked the CTA about this over the summer, and here's the crux of their response:

"One of the purposes of the pilot would be to test the different capabilities of the program. At this time there are no plans to display the number of rail cars on an approaching train - some of the LED signs used for the program  pose character limitations for the additional information and adjustments are often made based on special events or circumstances on a particular day on a particular line that requires rail operations to deviate from what is normally put into service."

Ok, some of the signs can't hold that much information.  (Again, I think DC is instructive here: the displays have all the screen resolution of a game of pong, but they still manage to fit the number of cars.)  But why not make sure the system is at least disseminating this data, and then program each display based on its capabilities? The CTA could still include this information online, which is the only way people will get the info anyway if they're not at a pilot station.  Additionally, the CTA wrote:

"We have a schedule that designates how many cars are in each consist on any train based on ridership demands [sic].  However, this plan is subject to change - adjustments are often made based on special events or circumstances on a particular day on a particular line that requires rail operations to deviate from what is normally put into service.  This is not something that we would be able to provide."

Well, that's a relief--the CTA has a schedule, but are willing to deviate from it depending on the day's circumstances.  And when they deviate, they no doubt know the new trainset's length.  So as that train makes its way through the system, this shouldn't be a hard piece of data to include, right?

Additionally, it'll be interesting to see how Train Tracker handles arrivals.  In Washington, DC, there's both an "ARR" notation just before the train enters the station, and then a "BRD" as the train stops and opens its doors.  Whether or not the CTA can give that kind of granularity depends on whether or not there's a sensor at the entrance to the station, but we'll see.

Finally, a bonus for any programmers out there: if and when the API is released, it's screaming for an animation of Tower 18's operations (that's the intersection of Wells & Lake).  I'll take a stab at this, but if you write it, I will pimp the hell out of it here, on twitter, and anywhere else people will listen.



Recent Posts


No Comments

Leave a Comment?

Some HTML is permitted: a, strong, em

What your comment will look like:


what will you say?

Most Active Pages Right Now

ChicagoNow.com on Facebook