Glad to see so much interest! The last commit to the github repo was in April: https://github.com/BetaNYC/service-alerts
@jimjshields I'd love to touch base with you on what you've been working on and what ideas you have. I'll be at the next few hacknights.
One of the devs on this project reached out to the MTA about improving their feed in the following ways but, to my knowledge, we haven't seen any changes.
Request for static lists of information
The official MTA service alert feed we’ve been using uses an internally consistent syntax to refer to station names and line directions (e.g., “Times Square-42 St” is always “Times Square-42 St” and never “42 St/Times Square”). Unfortunately these names often have subtle variations from the GTFS names which are found in stops.txt (e.g., “Broadway Junction” (feed) vs “Broadway Jct” (GTFS)).
It would be extremely helpful to have a canononical list of all the station names and their GTFS stop_ids used to generate the service status feed. As it stands, we have to wait for an issue to happen at a station in order to find out the “official” name, and then write an exception for it.
Similarly, while most trains are referred to as being “southbound” or “northbound”, some are station bound. Once again, these names are internally consistent, but sometimes difficult to predict (e.g., An [M] bound for “Forest Hills-71 Av” is said to be “71 Av-bound”). A list of the station-bound train directions would be very useful.
Potential changes to the feed
The service status feed works by over-writing a publically accessible xml document approximately once a minute with all currently active alerts. We easily can track alerts of type “Planned Work” across this refresh because they expose their internal MTA id. Unfortunately, alerts of type “Delays” lack this alert which forces us to compare the body text of the alerts from the current minute with those of the last minute to maintain continuity.
If “Delay”-type alerts have a unique identifier that is used internally at the MTA, it would be extremely helpful if it were to be exposed in the feed, similar to the “Planned Work”-type alerts.
The lack of a unique identifier can be particularly troublesome for long-lasting delays which, for some reason update their “Posted” approximately every two hours. This change causes our system to identify them as two distinct alerts.