Method 6: Rail Incidents

Description: Returns rail incidents as they appear on the the Public Information Displays throughout the transit system.

Examples

url (REST) : http://api.wmata.com/Incidents.svc/Incidents?api_key=YOUR_API_KEY

url (JSON): http://api.wmata.com/Incidents.svc/json/Incidents?api_key=YOUR_API_KEY

Response example (REST):

<IncidentsResp xmlns="http://www.wmata.com" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
   <Incidents>
     <Incident>
      <DateUpdated>2010-07-29T14:21:18</DateUpdated>
      <DelaySeverity>NA</DelaySeverity>
      <Description>Friendship Heights station has been closed due to a power problem. Shuttle service has been requested.</Description>
      <EmergencyText i:nil="true" />
      <EndLocationFullName i:nil="true" />
      <IncidentID>72081</IncidentID>
      <IncidentType>Station Incident</IncidentType>
      <LinesAffected>RD;</LinesAffected>
      <PassengerDelay>0</PassengerDelay>
      <StartLocationFullName>Friendship Heights</StartLocationFullName>
    </Incident>
  </Incidents>
</IncidentsResp>

Description of response fields:

  • IncidentID - ID of the nicident
  • IncidentType - Type of the nicident
  • DateUpdated - Date and time where informatino was updated.
  • DelaySeverity - Severity of delay (if any). Can be "Minor", "Major", "Medium".
  • Description - Description what happened.
  • EmergencyText - Some text for emergency (if any).
  • StartLocationFullName - Station where delay starts.
  • EndLocationFullName - Station where delay ends. If null, then incident belongs only to StartLocationFullName station.
  • LinesAffected - List of lines affected by the incident. Separated by ";" Example: "RD; YL; BL;"
  • PassengerDelay - Delay in minutes.

version 12 as of 2 years ago by Wmata Admin

16 Comments

  1. Agile Media Ventures – 2 years ago

    Right now, the REST and JSON methods are returning different data. The REST version returns three incidents, (Incident IDs 72521, 72522 and 72523) while the JSON version returns zero incidents.

  2. Wmata Admin – 2 years ago

    Agile - You are absolutely right - we see the same issue with the JSON version. We are looking at it now and will fix.

  3. Peter Shashkin – 2 years ago

    This is caching issue, should be resolved by now

  4. Agile Media Ventures – 2 years ago

    How long will an incident be returned by this method call? Once the incident is over and/or resolved, does it no longer appear in the results?

  5. Peter Shashkin – 2 years ago

    Thats correct, when its over its gone.

  6. Agile Media Ventures – 2 years ago

    Are all "incidents" returned by this method call? If so, should the IncidentIDs be sequential with no breaks?

    Thanks!

  7. Peter Shashkin – 2 years ago

    Yes, they're not sequential, but we have no knowledge regarding how these IDs are issued. I suspect that system-like alerts filtered out, which are not considered an incident.

  8. Bold, Inc. – 2 years ago

    This method is no longer returning any results for me (JSON and REST). Is there a problem with the API or are there actually no incidents? Thanks!

  9. Peter Shashkin – 2 years ago

    Rail incident is a relatively rare event. Most of the time this feed is empty.

  10. Bold, Inc. – 2 years ago

    Previous days there were numerous events (up to 5 or 6 at a time) and the WMATA Twitter account sends out lots of incidents (including multiple today - http://twitter.com/metroopensdoors/). I just wanted to double check that this is still working correctly. Thanks for the update.

  11. Peter Shashkin – 2 years ago

    Last one was 4 hours ago (on twitter) and nothing on wmata.com currently. So, so far seems to work as expected

  12. Agile Media Ventures – 2 years ago

    It would be helpful to understand the differences between a rail incident (as returned by this API), an incident that http://twitter.com/MetroOpensDoors provides, and a service disruption as shown at this URL (http://wmata.com/rail/disruption_reports/yesterdays_service_report.cfm). They all appear to be different.

    I'm working on expanding my automatic Twitter updates with additional info, such as location info via Rail Stations method, and it would be very helpful to understand what information is being populated. For instance:

    How long an incident will be returned via the API?
    Once an incident is resolved, will the API continue to return it?
    What about incident history?

    Thanks!

  13. Peter Shashkin – 2 years ago

    We show only currently active incidents. I suspect this would answer all your 3 questions.

    I dont have any knowledge regarding what exactly is used in other places - we're showing what we were given. If you feel that our feed is missing some active incident you saw in other systems, please let me know - we would like to investigate. Thanks

  14. Jason Hanley – 2 years ago

    This method is currently returning 2 entries advising about upcoming service disruptions. As far as I can tell, there is no way to distinguish between these and active incidents. The only difference I see is that there are no lines affected listed. Is there anyway to distinguish these entries from active ones?

  15. Peter Shashkin – 2 years ago

    We dont have a formal way to distinguish these. "No lines" criteria sounds good, but I am not 100% sure it covers all situations

  16. Jason Hanley – 2 years ago

    I took a look at your twitter feed for the last month and there were a few "no line" events that seem to be real disruptions. They all seem to concern the station itself, and not any train issue. Like escalator problems or a suspicious package.

Please sign in to post a comment.