Last month, I discussed some issues with the MBTA's transit alerts feed—an RSS 2.0 feed with little metadata and narratives which are too verbose to be useful for many applications. I also mentioned the CTA's web service for transit alerts, which uses a custom XML format.

One of the points which I have returned to countless times on this site is that there is absolutely no reason to build something from scratch for every city with a transit system. There is no need for every transit system to invent its own format for communicating alerts, an approach which makes developers' lives needlessly harder and which stunts the development of generic software which provides value for transit riders around the world.

In fact, there may not even be good cause to develop a generic format for transit alerts, if there are other standards for public alerting which are suitable. One standard to give close consideration in this case is the Common Alerting Protocol, an XML-based format for disseminating public alerts and emergency information.
CAP is an OASIS standard which will, as technologies develop, become an integral part of the Emergency Alert System in the US, as well as other emergency notification systems. Yet CAP is designed to be entirely generic; there's nothing in the CAP specification which ties it to the EAS—there are public CAP feeds which are live on the Web now that have been produced by governments around the world, universities, and other bodies.

One of the aspects of CAP that makes it advantageous for transit applications is the fact that a CAP alert can contain any number of links to external resources. This makes it easy to disseminate alert information in a wide range of formats: PDF files for posters to be physically posted at affected stations or stops, images with maps showing service diversions, audio for in-station announcements, etc. The core elements of a CAP alert, including urgency, severity, and certainty, can also be put to good use to make it easier for commuters to understand how to respond to an alert. An alert with low certainty (meaning the planned disruption is unlikely to occur) or low severity (meaning the impact will be small) may not garner much of a response from commuters, whereas an urgent alert with high severity (such as an immediate, network-wide disruption) probably will.

Just as there is a Canadian Profile for CAP, we can envision the development of a Transit Profile for CAP which would address certain issues in using CAP for transit alerts and emergency messages. What issues might a Transit Profile address?

  • The CAP standard generally expects that alerts will be defined in terms of a geographic area (a radius around a point, or a polygon) which is affected by the alert. For transit applications, though, it may be easier (and, ultimately, more accurate) to define the affected area in terms of known identifiers like GTFS stop and route IDs. This can be done by using the CAP <geocode> element: 
    
<alert>
  <!--alert body omitted-->
  <area>
  <!--Using MTA NYCT route IDs, define an alert for
      the Lexington Avenue Line-->
    <geocode>
      <valueName>route_id</valueName>
      <value>4</value>
    </geocode>
    <geocode>
      <valueName>route_id</valueName>
      <value>5</value>
    </geocode>
    <geocode>
      <valueName>route_id</valueName>
      <value>6</value>
    </geocode>
    <geocode>
      <valueName>route_id</valueName>
      <value>6X</value>
    </geocode>
  </area>
</alert>
  • The CAP <eventCode> element is used to supply a domain-specific code indicating the type of the event. The Transit Profile could define a set of codes for transit-related events, like station closures, route diversions, elevator outages, etc.

There's another advantage to building a transit alert system around CAP: integration with national alert systems. Suppose that a theoretical transit agency has designed a system where alerts are published in a CAP feed, and electronic passenger information systems in stations, and onboard railcars and buses use information from the CAP feed to presents alerts to passengers. Because those passenger information systems are designed to consume CAP feeds, they can be used to display information from not only the transit agency's CAP feed, but also those published by emergency management authorities.

In the unfortunate event of a national emergency, information from national or local authorities can be fed directly into the passenger information system, giving passengers direct, immediate information. The passenger information system can take advantage of CAP's ability to include links to external resources to play audio or video messages from emergency management authorities in stations and onboard trains and buses. If such resources are unavailable, the text of the alert can be displayed, and also rendered through a text-to-speech engine. Getting clear and correct information to passengers directly from emergency managers helps to reduce passenger panic and confusion, hopefully improving outcomes. The transit agency can then follow with its own alert, if necessary, prescribing specific actions for passenger (for example, evacuating or sheltering-in-place at an underground station, or awaiting decontamination).

The reverse will also hold true—as CAP becomes more widely adopted for disseminating emergency information to the public, we may start to see apps designed to deliver alerts from CAP feeds directly to mobile devices or desktop widgets. Providing transit alerts in a CAP feed makes it possible for users of those apps to receive public transit alerts without needing yet another app—a positive outcome for all concerned.