Which means the MTA has unintentionally developed an API: http://advisory.mtanyct.info/Test/gtfs/scraper.php?line=1...
“The existence of this sleek digital interface barely hints at the investment that had to be made in terms of hardware and infrastructure to make this enormous public benefit a reality,”
Why is this literally the worst app I've ever used? A weird old pixellated icon, non-retina bitmapped user interface elements, scrolling that doesn't continue and decelerate once you let go... not even any clear indication of which trains are uptown or downtown, no map to more easily pick a station, etc...
If they've been spending millions on the infrastructure to make this possible, couldn't they have spent more than what I would guess to be about $500 producing this app? It's like a third-grader wrote it. A bad third-grader.
Someone out there will make something amazing with this data, it's practically inevitable.
Speaking of, if you live in NYC you should come to this Reinvent Payphones Hackathon - same sentiment (full disclosure, my startup is helping to organize): http://reinventpayphones.prototypehackday.com/
Also, iPhone development is more difficult in real life than in your imagination. It should be easy to wrap a nice interface around a protobuf, but it's actually a rather tedious process.
I've used apps that have worse interfaces and don't do anything useful.
* MBTA App Showcase: http://www.mbta.com/rider_tools/apps/
* MassDOT Developer Page: http://www.eot.state.ma.us/default.asp?pgid=content/develope...
Additionally, cellular service has been added to most subway lines and stations for at least the orange line (so you have decent signal while riding and in stations), plus WiFi available on most commuter rail trains.
The breathlessness of the coverage of this app makes me wonder how much money was spent on it? First of all, the main problem for New Yorkers is the lack of this data for all the other train lines (i.e A-Z). Second, the MTA has, to their credit, made this data easy to get as others have posted. And apparently Android maps already use this information...so why build an app except for getting some public goodwill. Not that public gestures are bad, but it depends on the cost (puts 'file information request for app dev contract' on things to do sometime)
Unfortunately this is not going to be fixed any time soon. BMT/IND trains have a distributed command and control system. Multiple signal towers control train movement within their own sectors of the system - and each signal tower has no information about the rest of the system.
This was necessary in the early days, before electronics existed.
So to this day there is no centralized snapshot of the entire system state, unlike the numbered lines, and thus no ability to provide an API.
This is a great step forward. I look forward to the day we can have a big jumbotron with real time locations of trains.
The control systems of the MTA are purely electromechanical. It goes way beyond what one would normally call a "legacy system".
You can't record the position of trains because there is no way to snapshot the whole system. Only the signal tower local to that section of the system is aware of what's going on in its zone. This is a vestige of the design where there was no reasonable way to centralize that amount of signaling over such great distances.
To get a snapshot of the whole system you'd have to simultaneously snapshot the state of every signal tower in the system and find some way to collect this information centrally. This sounds reasonable until you realize that the control system, being 50 years pre-computer, is unaware of individual trains. It doesn't detect trains, only presence of at least one car on a section of track (detected by the third rail making contact with the train).
To ascertain which train is where you'd have to either have dispatchers identify the train by communicating with operators (hard to poll), or infer the identity of a train by monitoring state. Both are quite difficult when all of your data is spread all over the entirety of NYC in isolated distributed control centers.
The IRT trains spent billions centralizing all command and control into a single building in Manhattan, and thus snapshotting state is trivially easy. The BMT/IND segments of the system are substantially bigger, with more stations, than even that. A full modernization to electronic control is necessary, which will cost many billions.
I mean, are you telling me for a 100 million dollars this couldn't be done?
In cases where delays are more substantial and you need to hold trains further upstream, this is communicated manually between towers.
Much of the control here is not based on semantic data, but rather verbal. The actual control system itself isn't capable of much more than indicating which piece of track is occupied.
It is fairly easy to hook up a "'low resistance between the rails aka 'wheels on the rails' aka 'there is a train here'" detector to a 'do not enter' signal a few hundred meters up, and to a 'drive slowly' signal some distance before that (http://en.wikipedia.org/wiki/Automatic_Block_Signal)
(1) Developer key: http://datamine.mta.info/user/register
(2) The data is in Protocol Buffer format, so get that: http://code.google.com/p/protobuf/downloads/list
(3) The proto definition of the GTFS-realtime feed:
(4) Some static data (which has IDs for each station, etc).
(5) You can just curl the URL for all the current data (with your developer key):
curl http://datamine.mta.info/mta_esi.php?key=<developerkey> -o /tmp/mtafeed
cat /tmp/mtafeed | /usr/bin/protoc -I /tmp /tmp/gtfs-realtime.proto --decode=transit_realtime.FeedMessage > /tmp/decodedmtafeed
1: "04 1306 WDL/UTI"
[ some data removed ]
[ some data removed ]
In the "entity"
- trip_id: "078600_4..S44R"
* 078600 is a train id or something
* _4.. means it's a 4 train (this is also available on the route_id field)
* S means it's heading south
* 44R describes the stops this train will make. I'm not entirely sure how to parse this.
In the stop_time_update:
- stop_id: "635S"
* you can find the stop codes in stops.txt from (4). This one is "635S,,14 St - Union Sq,,40.734673,-73.989951,,,0,635"
- arrival / time: 1356720373
$ date -d @1356720373
Fri Dec 28 13:46:13 EST 2012
So, I guess there was a Downtown 4 train, scheduled to stop at union square at 1:46:13. (I downloaded this about about 1:30 Eastern, so that seems right).
It's all a part of Chicago's OpenGov work and its incredible how much data and work is out there. Here's a list of apps that people made in a city-sponsored competition:
And here's a link to one of the meetups that try to do something cool with all that open data from the City:
"New York City challenged software developers to create apps that use city data to make NYC better."
If you're on the platform, you'll be able to see the time even if your phone isn't working. So the mobile app will be useful if you're en route to the station and need to know how many minutes you have left.
I'll stop complaining the next time the L is a few minutes late. Yeesh.