Skip to content

Real Time Data Configuration Guide

Sean Barbeau edited this page May 17, 2016 · 26 revisions

While OneBusAway can work with just static schedule data, all the most interesting features require real-time transit information. Below is information about the various real-time data formats that OneBusAway supports.

GTFS-realtime

We support GTFS-realtime out of the box, including support for trip updates, vehicle positions, and alerts. To add support, create a GtfsRealtimeSource bean in your data-sources.xml file for your onebusaway-transit-data-federation-webapp. Then specify URLs for the three different types of GTFS-realtime data as properties of the bean.

You can use GTFS-realtime data from MBTA as an example of trip updates and vehicle positions. Just be sure that you use a transit data bundle with MBTA's GTFS data, so they match.

Here is a full example:

<bean class="org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource">
  <property name="tripUpdatesUrl" value="http://url/to/gtfs-realtime/trip-updates" />
  <!-- Optionally set the Vehicle Positions endpoint -->  
  <property name="vehiclePositionsUrl" value="http://url/to/gtfs-realtime/vehicle-positions" />
  <!-- Optionally set the Service Alerts endpoint -->  
  <property name="alertsUrl" value="http://url/to/gtfs-realtime/alerts" />
  <!-- Optionally set the refresh interval - how often we query the URLs, in seconds (default=30) -->
  <property name="refreshInterval" value="30"/>
  <!-- Optionally configure the agency id we use to match incoming real-time data to your GTFS data -->
  <property name="agencyId" value="SomeAgencyId" />
  <!-- Optionally configure multiple agency ids we use to match incoming real-time data to your GTFS data -->
  <property name="agencyIds>
    <list>
      <value>SomeAgencyIdA</value>
      <value>SomeAgencyIdB</value>
    </list>
  </property>
  <!-- Optionally remap one or more agency ids in the GTFS-rt Service Alerts feed - see https://github.com/OneBusAway/onebusaway-application-modules/issues/114 for details -->
  <property name="alertAgencyIdMap">
    <map>
      <entry key="agencyIdInFeed" value="remappedAgencyId" />
    </map>
  </property>
  <!-- Optionally hide negative scheduled arrival times for this agency via "showNegativeScheduledArrivals" (only add this property if you have the problem explained in https://github.com/OneBusAway/onebusaway-application-modules/issues/162.  See https://github.com/OneBusAway/onebusaway-application-modules/pull/160 for the full property XML)
</bean>

You can additionally specify a refreshInterval that controls how often we query the URLs, in seconds. If you are deploying a multi-agency instance of OneBusAway, you may also need to specify the agencyId or agencyIds of the transit agency to associate the incoming GTFS-realtime data with. This allows you to define multiple incoming GTFS-realtime data-sources from different agencies in the same system.

If you're remapping agencyIds in your GTFS data, you may need to remap any agencyIds that appear in your GTFS-rt Service Alerts feed contents. You can do this by specifying the original and new agencyIds in the alertAgencyIdMap property. For example, if you wanted to remap the agencyId of 1 to PSTA, you would use the entry <entry key="1" value="PSTA" />. See this issue for details.

If you have problems with the GTFS-realtime feed dropping predictions right as the bus passes a stop, and scheduled arrival times appearing, you'll need to hide negative scheduled arrival times for this agency via the showNegativeScheduledArrivals property. This problem is further explained in this issue and this onebusaway-developers group discussion. See this pull request for the full property XML.

SIRI VM

We support SIRI out of the box, including support for vehicle monitoring (VM) and situation exchange (SX). To add support, create a SiriController bean in your data-sources.xml file. Then specify /onebusaway-siri/${onebusaway-siri-version}/cli-request-spec.html}SIRI endpoint requests indicating your SIRI data-source.

Here is a full example:

<!-- The "name" parameter controls which URL the SIRI client listens for pub-sub data.  See "clientUrl" below. -->
<bean name="/siri.action" class="org.onebusaway.transit_data_federation_webapp.siri.SiriController">
  <!-- Specify the SIRI endpoint -->
  <property name="endpoint" value="Url=http://host/siri-endpoing.xml,ModuleType=VEHICLE_MONITORING" />
  <!-- Or you can specify a series of endpoints -->
  <property name="endpoints">
    <list>
      <value>...</value>
      <value>...</value>
    </list>
  </property>
  <!-- Control the URL your SIRI client publically broadcasts to endpoints for pub-sub data exchange -->
  <property name="clientUrl" value="http://localhost:8080/onebusaway-transit-data-federation-webapp/remoting/siri.action" />  
  <!-- Want to see what's going on behind the scenes with SIRI XML messages? -->
  <property name="logRawXmlType" value="CONTROL"/>
</bean>

ACS Orbital - OrbCAD

A number of agencies have ACS Orbital - Orbcad AVL systems. Some agencies have configured the data-export option of these systems to spit out a CSV file of vehicle locations and schedule deviations for all the vehicles in their fleet, which is then shared through a webserver. OneBusAway supports data of this form. To add support, create a OrbcadRecordHttpSource bean in your data-sources.xml file. Then specify the URL for your real-time data file.

Here is a full example:

<bean class="org.onebusaway.transit_data_federation.impl.realtime.orbcad.OrbcadRecordHttpSource">
  <property name="url" value="http://host/busdata.txt" />
  <!-- Optionally configure the agency id we use to match incoming data -->
  <property name="agencyIds">
    <list>
      <value>SomeAgencyId</value>
    </list>
  </property>
</bean>

Also note that in the Data Processing Tools section below there is an open-source standalone OrbCAD SQL Server to GTFS-realtime Converter that you could also use in place of direct integration with OneBusAway.

MyBus

Back in the day, OneBusAway supported just one kind of real-time data: the legacy MyBus system used by King County Metro. If you want to relive the glory days (and the MyBus servers are still up), you can enable the MyBus real-time feed by adding the following bean to your data-sources.xml file:

<bean id="king_county_metro_avl" class="org.onebusaway.transit_data_federation.impl.realtime.mybus.TimepointPredictionServiceImpl" />

Custom Implementation

Interested in adapting your own real-time system to OneBusAway? The best option is to create an adapter between your system and an existing specification like GTFS-realtime or SIRI and then use OneBusAways native support for those formats.

However, if thats not going to cut it, you can create your own custom real-time data-source plugin to OneBusAway. This might be a good solution if you need direct access to OneBusAway data-structures and service interfaces to process your real-time data.

Creating a custom implementation typically involves the following steps:

Create a Java class that implements your real-time data-source. Add your class to the OneBusAway application server class path. Create an instance of your class in your data-source.xml file. Have your implementation periodically notify OneBusAway of new real-time data using the VehicleLocationListener interface.

Here is a quick example to get you started:

public MyRealTimeSource {

  private VehicleLocationListener _listener

  @Autowired
  public void setVehicleLocationListener(VehicleLocationListener listener) {
    _listener = listener;
  }
  
  @PostConstruct
  public void start() {
    // Span a thread that periodically poll your data-source, or some other method of receiving data
  }
  
  @PreDestroy {
  public void stop() {
    // Shut-down any threads you started
  }
  
  public void processRealTimeData(...) {
    VehicleLocationRecord record = createRercordFromRealTimeData(...);
    _listener.handleVehicleLocationRecord(record);
  }
}

Data Processing Tools

Need to modify data? OneBusAway also provides many tools to process various types of data sources: * GTFS - A Java-based library for reading, writing, and transforming GTFS data, including database support. Check out the onebusaway-gtfs-modules project for more info.

There are also a number of third-party open-source converters for other real-time data sources - be sure to check our Kurt Raschke's article "Legacy AVL system? It's okay, join the club" for more details.

Also, check out the awesome-transit list to see a number of open-source conversion tools.

We've listed just some of these tools below:

  • OrbCAD SQL Server to GTFS-realtime Converter - USF created an open-source utility to convert from an OrbCAD SQL Server database format to GTFS-realtime for trip updates and vehicles positions, which is being used in production for OneBusAway Tampa. Check out HART-GTFS-realtimeGenerator wiki for more info.
  • Syncromatics API to GTFS-realtime Converter - In progress - USF is creating a utility to convert from the Syncromatics API to GTFS-realtime for trip updates and vehicles positions. This feed will be used to power a mobile app for the USF campus, so students can see BullRunner shuttle information. Check out bullrunner-gtfs-realtime-generator wiki for more info.
  • Bliksem Integration Realtime - Implements the OneBusAway GTFS-Realtime exporter for the available Dutch realtime datastream's. It uses the data from the database of the integration project to match incoming vehicle-messages and make a prognosis based on the punctuality in those messages. The messages are somewhat comparable to SIRI-VM, sending a message at each arrival/departure or after 60 seconds. Each message has a arrival punctuality for the next stop. To build the GTFS-RT tripupdates estimates are made on which stage a delay is neutralized, for example a negative delay is neutralized after the departure at a timingpoint. Positive delay's are decayed using distance, estimating the best-case scenario using theoretical minimum link-times between stops. See bliksemintegration-realtime for more info. There is also a partner project for GTFS data, bliksemintegration. This project imports and syncs (Transmodel) BISON Koppelvlak1 (about 12 Dutch agencies). It also imports IFF (a format written by HP/EDS), somewhat similiar to ATCO CIF, to import timetables of the railway networks. The internal pseudo-NETeX datastructure allows to export to GTFS and there are proof-of-concepts to export to other formats such as NETeX, GTFS and IFF. To import data of neighbouring countries we've also written import-plugins for DINO (AVV/ Germany) and BLTAC (TEC / Belgium). The latter importer is not yet opensource as of June 13, 2014.
  • Open-Transport SYNTHESE Convertors - Converts French-Transmodel, SIRI, NETeX, HAFAS, HASTUS, VDV452, and more. See the Open Transport SYNTHESE wiki for more info.
  • Chouette - Converts French-Transmodel, SIRI, NETeX. See Chouette.mobi website for more info.