At the link below, please find the current (beta) version of the MTA New York City Transit GTFS-RT spec (in pdf), and NYCT proto file (in txt). The revisions to these specifications were in response this discussion thread and one on the GTFS-realtime Google Group.
This is the version we plan
to develop, test and make available later this year. During
our beta phase we would make additional changes as necessary (hopefully no major changes will be needed, if any at all).
Thank you to all who helped us arrive at this document, for your insight and support. Everyone on our team feels this approach worked very well and helped us reach what we expect will be a very useful spec.
Attached please find the latest revised GTFS-RT specification and associated test data. The significant enhancements with this release include the inclusion of Vehicle Positioning data which can be used to determine a “stalled train” condition. We also expanded track information to include both schedule and actual track. This can be used to determine when a train is not operating according to it scheduled plan.
-Aaron
Great to see progress on the reporting schema!
Any updates on gathering real-time information for Division B? (ie: the rest of the subway system, beyond the numbered trains)
Thanks..
On the A, B, C, D, E, F, G, J, M, N, Q, R and Z lines (collectively, the majority of the B Division, or the former IND. and B.M.T. systems), we use a fixed-block signaling system that uses technology that essentially dates back to the dawn of the subways. While we maintain the system continuously and regularly upgrade its components, the underlying technology has remained little changed since the nineteenth century. It is a time-tested, fail-safe system that allows our dispatchers to know a train's general position within fixed blocks of track, but it does not allow our dispatchers to see a train's precise position in real time. We have long-term plans in place to upgrade these lines to modern, computerized train control, pending availability of funding in future five-year capital programs. Our current five-year capital program runs through 2014.
Finally,
the L line is controlled by our most sophisticated train dispatching system,
Communications-Based Train Control (CBTC). Countdown clocks on the 24 stations
of the L line are powered by CBTC. MTA New York City Transit is currently
installing CBTC on the 7 line.
-Aaron
Sunny,
The problem is that that information is not hooked into anything resembling a computer (just the model boards in the towers); that's precisely what the IRT ATS does.
-Kurt
Sunny,
Do you know if they Jay Street announcements are on the IND level or the R line and if they are automated? The automated version examples are on the A division (male) and Canarsie (female). I know sometimes the signal towers make manual arrival anmoucements through the PA system.
Sent from my Android Thunderbolt.
Hi Aaron,I'd first like to thank you helping coordinate this effort among developers.I'd like to suggest something I haven't really seen here regarding what the API could offer which would be both simpler and more flexible.Instead of having an API provide just countdown clock information for a few lines which, given it's inherent imprecision, isn't that flexible, why not provide...--> the times that trains arrive and then leave each station along with an ID number of said train along
Having this corpus of data available both real-time and historical would provide third parties the ability to accurately forecast when trains will arrive where as well as the impact of delays. Further, developers/statisticians could then use this mined data to inform customers as to the nature of whether a train is running "slow" or not. One could even impute crowd levels on trains with the length of time spent at a stop. Ultimately, this far simpler API would allow no shortage of value for end users as compared to a predigested imprecise feed of data.Best,DJ
Hi Aaron,I have checked out this data and tried to correlate it with the MTA static data from http://httqa.mta.info/developers/ as a comparison between realtime train status and planned service. However I found that many trip instances in the realtime data cannot find a match in the planned service. What I'm doing is as follows:For a trip_id, e.g. 079005_1..S03R, I know that in static data trip_id looks like A20120610WKD_0790000_1..S03R, so I check the week day of the start date of a realtime trip, add a prefix (WKD) to the time (079005) and get WKD_079005_1..S03R. Then I round up the second field as the static plan is scheduled on a 30 second interval, which means that the second digits can only be 00 or 50. I'm not sure if I shall round up or down so I try every possibilities, yielding WKD_079000_1..S03R, WKD_079050_1..S03R, WKD_079100_1..S03R, WKD_078950_1..S03R, etc. Finally I use these trip_id as keys to search in the MTA static data. What I can get are partial matches between realtime trips and planned service.I wonder if I'm doing anything wrong here? or the static and realtime trips simply has certain amount of mismatches?Thanks!
在 2012年9月10日星期一UTC-4上午11时28分45秒,Aaron Donovan写道:
Folks who are interested should drop a line to outr...@transitup.comCheers!