Skip to content

2015 Google Summer of Code Ideas

Jump to bottom Edit New page
Sean Barbeau edited this page Mar 11, 2015 · 31 revisions

This page hosts ideas for the 2015 Google Summer of Code program, as discussed on the mailing list.

GTFS-realtime validation tool

GTFS and GTFS-realtime have become dominant formats for open data in the transit industry. While the GTFS format has a GTFS Feed Validator, no such open-source tool currently exists for GTFS-rt. Due to the implementation details of the GTFS-rt specification, the GTFS-rt spec itself does not provide strong guidance for what data fields should be populated for particular use cases of the data.

This project would implement a tool that takes a GTFS and GTFS-rt feed as input, and examines the GTFS-rt feed to determine if it properly meets GTFS-rt best practices, both those explicitly listed in the spec and those based on the needs of consuming applications. The validator should be able to evaluate feeds implemented both via websockets and as protobuf-encoded responses/files that are retrieved via a polling mechanism. Our preference is that the tool is implemented in Java or Python.

Sample execution steps:

  1. Load the corresponding GTFS (i.e., schedule data)
  2. Monitor the GTFS-rt feed over a certain amount of time (potentially days or more if needed)
  3. Log any warnings and failures in an easy-to-read format

Some errors will be instantly visible (e.g., timestamps in the wrong format), while other more subtle issues may take longer monitoring. We would want to write to a log as the validator is running so the output could be monitored before the validator finishes running, if the testing time is an extended period.

Sample rules to validate include:

  • stop_time_updates for a given trip_id must be sorted by increasing stop_sequence (this should always be enforced whether or not the feed contains the stop_sequence field) (failure)
  • Frequency-based trip_updates must contain trip_id and start_time (failure)
  • Timestamps should be populated for all elements (warning)
  • All timestamps must be in POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC) (failure)
  • vehicle_id should be populated in trip_update (warning)
  • If both vehicle positions and trip updates are provided, VehicleDescriptor or TripDescriptor values should match between the two feeds (warning)
  • If only delay is provided in a stop_time_update (and not a time), then the GTFS stop_times.txt must contain arrival_times and/or departure_times for all stops referenced in the GTFS-rt feed (i.e., not just timepoints) (failure)

Sample GTFS-rt feeds:

Possible projects that could be leveraged for this:

Sample open-source GTFS-rt feed producer projects (to better understand how GTFS-rt is produced):

OpenTripPlanner for Android

Many new enhancements could be implemented for the OpenTripPlanner for Android open-source app, including:

  • Implement real-time turn-by-turn navigation for transit, as discussed in issue 297
  • Add support for the Open Source Routing Machine (OSRM) as a new trip planning engine, as discussed in issue 409
  • Add weather information for destination, as discussed in issue 448
  • Update the app to the new Android Material Design concepts, as discussed in issue 449
  • Update the app to work with the newest OTP server master branch REST API (I'm not sure if this is currently working or broken)
  • Integrate with OneBusAway Android for better shortcuts to real-time transit information, as discussed in issue 21-comment
Add a custom footer

The documentation on this wiki is outdated and should not be used

unless you are intentionally working with legacy versions of OpenTripPlanner. Please consult the current documentation at readthedocs

Clone this wiki locally