T Alerts Developers Feed v2.0
24 views
Skip to first unread message
Chris Dempsey - MassDOT
Dec 8, 2009, 3:16:52 PM12/8/09
to MassDOTDevelopers
Hello, all,
As promised at the Developers Conference, one of our immediate goals
is to make improvements to the T-Alerts RSS feed to make it more
useful to the developer community.
With that in mind, we are working on an update that we are tentatively
calling "T Alerts Developers Feed v2.0".
I've pasted a Q+A below that should provide a sense of where we are
headed with these changes. We've tried to address many of the
questions raised in a previous thread in the Google Group, which you
can find here: http://bit.ly/1Im9se
We would appreciate your input on these changes. Are we on the right
track? What additional changes would you suggest? What are we
missing that would be helpful as you integrate T-Alerts into
applications?
Thanks.
- Chris from MassDOT
1. Q. What fields will T-Alerts Developers Feed 1.5 include?
A. RSS fields will include:
• Unique Message ID
• Mode (Bus/Subway/Rail/Boat/Silver)
• Timestamp
• Line/Route
• Service/Train ID (for commuter rail only)
• Trip time (for commuter rail only)
• Direction
• Delay time
• Delay category
• Additional message
2. Q. Will it be possible to identify, from what's in the rss feed,
the actual amount of time a delay occurs (e.g. 20 minutes late)? Will
the text we see within an alert description be consistent so that we
can match it?
A. Yes. The new feed will include a field with the following delay
options:
10-15 min, 15-20 min, 20-25 min, 25-30 min, 30-45 min, 45-60 min, over
60 min, diverted, cancelled.
This field will be distinct and consistent, so it should be much more
developer-friendly than the current system.
3. Q. It would be useful (for applications such as T-Tweet, where
timeliness is critical) if the RSS feeds were available in a "push"
fashion -- that is, your application would be contacted as a new alert
is posted, rather than your application having to continually poll the
server hosting the RSS asking for updates.
A. Unfortunately, we are unable to support this request at this
time. We will keep the recommendation under consideration for future
updates.
4. Q. Because developers are already building apps using the existing
feed, any changes will need to be very slow and well published. If you
do make changes, I suggest only adding - not changing or deleting any
existing fields. Be sure to let everyone know if/when you do - as
people's apps could break unexpectedly.
A. We will make every effort to continue the existing feed and give
plenty of notice on changes. However, because we are making changes
to the interface used by the MBTA operator, it may be necessary for us
to eliminate the existing feed. If this turns out to be the case, we
will provide sufficient lead time for developers to make changes to
existing apps.
5. Q. The red signs we see at the commuter rail stops... I have
found these quite reliable. Is this data driven from the same data as
the RSS feed, or is there another data source "out there" which drives
those signs?
A. These signs are updated through a different process. We are
working to consolidate these processes where possible.
6. Q. I see the individual lines and routes, which are very
necessary, and I see all (999) but I think a little more scoping would
also be helpful, i.e. # for all red, # for all green, # for all buses.
A. The new “Mode” and “Line/Route” fields should satisfy this
request.
7. Q. In the new feed, is "Line Route" distinct for each branch of a
line?
A. This is currently planned for commuter rail lines. We may be able
to add this for rapid-transit branches also.
8. Q. What is the list of options for "Delay Category"?
A.
signal problem
roadway problem
switch problem
track problem
power problem
police action
medical emergency
weather related problem
disabled train
disabled bus
mechanical failure
accident
freight train interference
Amtrak
9. Q. If possible, each stop should have an ID too (maybe the one
from GTFS) and I get get stuff related to that stop. For any
particular line, you want to know in which direction and between which
stations/stops, in a machine-readable format.
A. Unfortunately, service alerts by station are not possible at this
time. We will take this under consideration for future updates.
10. Q. The #99 (All Lines/Routes) Query isn’t working!
A. We plan on fixing that query in this update.
11. Q. What would be useful is if I could query by bus line or train
line, and get all the alerts related to that line, including elevator
and platform alerts.
A. The update will allow developers to query by line, but we are not
able to cross-reference elevator and platform alerts in this
update.
12. Q. The IDs would be easier to use if they corresponded with the
line IDs in the GTFS. Is it possible to change these ID numbers?
A. This is TBD on our end. We will let you know if it is possible to
make these changes in this update.
As promised at the Developers Conference, one of our immediate goals
is to make improvements to the T-Alerts RSS feed to make it more
useful to the developer community.
With that in mind, we are working on an update that we are tentatively
calling "T Alerts Developers Feed v2.0".
I've pasted a Q+A below that should provide a sense of where we are
headed with these changes. We've tried to address many of the
questions raised in a previous thread in the Google Group, which you
can find here: http://bit.ly/1Im9se
We would appreciate your input on these changes. Are we on the right
track? What additional changes would you suggest? What are we
missing that would be helpful as you integrate T-Alerts into
applications?
Thanks.
- Chris from MassDOT
1. Q. What fields will T-Alerts Developers Feed 1.5 include?
A. RSS fields will include:
• Unique Message ID
• Mode (Bus/Subway/Rail/Boat/Silver)
• Timestamp
• Line/Route
• Service/Train ID (for commuter rail only)
• Trip time (for commuter rail only)
• Direction
• Delay time
• Delay category
• Additional message
2. Q. Will it be possible to identify, from what's in the rss feed,
the actual amount of time a delay occurs (e.g. 20 minutes late)? Will
the text we see within an alert description be consistent so that we
can match it?
A. Yes. The new feed will include a field with the following delay
options:
10-15 min, 15-20 min, 20-25 min, 25-30 min, 30-45 min, 45-60 min, over
60 min, diverted, cancelled.
This field will be distinct and consistent, so it should be much more
developer-friendly than the current system.
3. Q. It would be useful (for applications such as T-Tweet, where
timeliness is critical) if the RSS feeds were available in a "push"
fashion -- that is, your application would be contacted as a new alert
is posted, rather than your application having to continually poll the
server hosting the RSS asking for updates.
A. Unfortunately, we are unable to support this request at this
time. We will keep the recommendation under consideration for future
updates.
4. Q. Because developers are already building apps using the existing
feed, any changes will need to be very slow and well published. If you
do make changes, I suggest only adding - not changing or deleting any
existing fields. Be sure to let everyone know if/when you do - as
people's apps could break unexpectedly.
A. We will make every effort to continue the existing feed and give
plenty of notice on changes. However, because we are making changes
to the interface used by the MBTA operator, it may be necessary for us
to eliminate the existing feed. If this turns out to be the case, we
will provide sufficient lead time for developers to make changes to
existing apps.
5. Q. The red signs we see at the commuter rail stops... I have
found these quite reliable. Is this data driven from the same data as
the RSS feed, or is there another data source "out there" which drives
those signs?
A. These signs are updated through a different process. We are
working to consolidate these processes where possible.
6. Q. I see the individual lines and routes, which are very
necessary, and I see all (999) but I think a little more scoping would
also be helpful, i.e. # for all red, # for all green, # for all buses.
A. The new “Mode” and “Line/Route” fields should satisfy this
request.
7. Q. In the new feed, is "Line Route" distinct for each branch of a
line?
A. This is currently planned for commuter rail lines. We may be able
to add this for rapid-transit branches also.
8. Q. What is the list of options for "Delay Category"?
A.
signal problem
roadway problem
switch problem
track problem
power problem
police action
medical emergency
weather related problem
disabled train
disabled bus
mechanical failure
accident
freight train interference
Amtrak
9. Q. If possible, each stop should have an ID too (maybe the one
from GTFS) and I get get stuff related to that stop. For any
particular line, you want to know in which direction and between which
stations/stops, in a machine-readable format.
A. Unfortunately, service alerts by station are not possible at this
time. We will take this under consideration for future updates.
10. Q. The #99 (All Lines/Routes) Query isn’t working!
A. We plan on fixing that query in this update.
11. Q. What would be useful is if I could query by bus line or train
line, and get all the alerts related to that line, including elevator
and platform alerts.
A. The update will allow developers to query by line, but we are not
able to cross-reference elevator and platform alerts in this
update.
12. Q. The IDs would be easier to use if they corresponded with the
line IDs in the GTFS. Is it possible to change these ID numbers?
A. This is TBD on our end. We will let you know if it is possible to
make these changes in this update.
fredleblanc
Dec 8, 2009, 4:03:11 PM12/8/09
to MassDOTDevelopers
For the most part, these look pretty good to me. A couple of things
crossed my mind:
I'd push to create a completely separate new feed rather than slowly
morph the old one. (If I read the Q/A correctly that seems to be what
is proposed.) Once the new one is ready, post that as the publicly
accessible and posted RSS feed, with the other feed still there and
working just unlinked.
In terms of naming, I'd say "Delay Category" is more "Delay Reason."
Or it could just be called "Excuse." ;)
For my use (I made the @mbta_alerts account on Twitter), the most
helpful thing would be to know about the delays ASAP. Right now, most
of the notices come through like this:
Some Rail (6:00p) delays 15-20 min.
(Message posted at 6:35p)
So the feed is only really helpful to those that are going to be
picking someone up rather than those waiting. It's better than
nothing, and that part is the huge hurdle. Just pointing out the
elephant in the room I guess.
Anyway, the rest seems golden. It will be great to not have to parse
in "creative" ways to get the information to the people in our own
way.
- Fred of @mbta_alerts
On Dec 8, 3:16 pm, Chris Dempsey - MassDOT
crossed my mind:
I'd push to create a completely separate new feed rather than slowly
morph the old one. (If I read the Q/A correctly that seems to be what
is proposed.) Once the new one is ready, post that as the publicly
accessible and posted RSS feed, with the other feed still there and
working just unlinked.
In terms of naming, I'd say "Delay Category" is more "Delay Reason."
Or it could just be called "Excuse." ;)
For my use (I made the @mbta_alerts account on Twitter), the most
helpful thing would be to know about the delays ASAP. Right now, most
of the notices come through like this:
Some Rail (6:00p) delays 15-20 min.
(Message posted at 6:35p)
So the feed is only really helpful to those that are going to be
picking someone up rather than those waiting. It's better than
nothing, and that part is the huge hurdle. Just pointing out the
elephant in the room I guess.
Anyway, the rest seems golden. It will be great to not have to parse
in "creative" ways to get the information to the people in our own
way.
- Fred of @mbta_alerts
On Dec 8, 3:16 pm, Chris Dempsey - MassDOT
Chris Dempsey - MassDOT
Dec 17, 2009, 4:49:12 PM12/17/09
to MassDOTDevelopers
All,
Any other comments/suggestions on this T-Alerts 2.0 proposal? If not,
we will move ahead with the new feed as outlined in the Q & A.
Any other comments/suggestions on this T-Alerts 2.0 proposal? If not,
we will move ahead with the new feed as outlined in the Q & A.
Thanks for your comments, Fred.
Best,
Chris from MassDOT
Atticus Gifford
Dec 18, 2009, 2:25:27 AM12/18/09
to MassDOTDevelopers
It looks really good, especially calling out the train IDs for
commuter rail. Will there be a mechanism to indicate when a message
has been invalidated? That is, when the problem is resolved will the
story just be pulled from the feed, or will there be a field that
indicates whether the alert is still valid, or a time when it was
resolved? That may be helpful, although simply pulling it is just as
good since we'll be polling it anyway. The only consideration would be
to try and be as prompt as possible about pulling old alerts in
addition to trying to post them as quickly as is feasible.
commuter rail. Will there be a mechanism to indicate when a message
has been invalidated? That is, when the problem is resolved will the
story just be pulled from the feed, or will there be a field that
indicates whether the alert is still valid, or a time when it was
resolved? That may be helpful, although simply pulling it is just as
good since we'll be polling it anyway. The only consideration would be
to try and be as prompt as possible about pulling old alerts in
addition to trying to post them as quickly as is feasible.
Thanks,
Atticus
On Dec 17, 4:49 pm, Chris Dempsey - MassDOT
fredleblanc
Dec 18, 2009, 10:05:00 AM12/18/09
to MassDOTDevelopers
Well, I suppose it's worth keeping in mind that there are two target
users of MBTA alert apps: those that are getting on public
transportation to go somewhere, and those that are picking someone up
from public transportation — the majority of this second group
probably being the commuter rail people.
users of MBTA alert apps: those that are getting on public
transportation to go somewhere, and those that are picking someone up
from public transportation — the majority of this second group
probably being the commuter rail people.
I don't think you'd want to actually "pull" an alert. However, as you
mentioned, it would be nice to have a "resolved" flag or date or
indicator.
Fred
On Dec 18, 2:25 am, Atticus Gifford <atti...@sparkfishcreative.com>
wrote:
Reply all
Reply to author
Forward
0 new messages