Skip to content

Real Time Data Configuration Guide

Jump to bottom Edit New page
Sean Barbeau edited this page Jan 28, 2015 · 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" />
  <property name="vehiclePositionsUrl" value="http://url/to/gtfs-realtime/vehicle-positions" />
  <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 data -->
  <property name="agencyId" value="SomeAgencyId" />
  <!-- Optionally configure multiple agency ids we use to match incoming data -->
  <property name="agencyIds>
    <list>
      <value>SomeAgencyIdA</value>
      <value>SomeAgencyIdB</value>
    </list>
  </property>
  <!-- Optionally remap multiple agency ids in the GTFS-rt Service Alerts feed -->
  <property name="alertAgencyIdMap">
    <map>
      <entry key="agencyIdInFeed" value="remappedAgencyId" />
    </map>
  </property>
</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.

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>

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:

  • 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.
Add a custom footer
Add a custom sidebar
Clone this wiki locally