Skip to content
transitdata publishes GTFS Realtime interfaces
Shell
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
bin
transition-plan Simplify step 1 Oct 1, 2018
DOCKER_SERVICE_RESTART.md
LICENSE Added license Sep 20, 2018
README.md
transitdata_data_flow_drawio.png Update transitdata diagram Oct 28, 2019
transitdata_data_flow_drawio.xml Update transitdata diagram Oct 28, 2019
transitlog_hfp_data_flow_drawio.png
transitlog_hfp_data_flow_drawio.xml Update transitlog diagram Oct 28, 2019

README.md

General

This system will poll updates to Pubtrans database (regarding departures and arrivals) and convert those to GTFS real-time messages using a pipeline created with Apache Pulsar. The final step will output the messages via MQTT broker.

General usage pattern is to build Docker images and then run them with docker-compose. Services are separated to subfolders, each containing the source code and the Dockerfile.

/bin-folder contains scripts to launch Docker images for Pulsar and Redis which are requirements for some of the services.

Requirements

Overall system requirements for running the system are:

  • Docker
  • Redis
  • Pulsar
  • Connection to a Pubtrans SQL Server database
  • Connection to an MQTT broker

System Architecture & Components

Alt text Alt text

Components are stored in their own Github Repositories:

Common dependencies

Transitdata components

Transitlog HFP components

Versioning

All the components in this project use semver, but the output conforms always to the GTFS Realtime standard. Some vendor-specific extensions might be added, which require incrementing the major version. Otherwise, new features should only increment the minor version, but some exceptions might arise. TripUpdate and ServiceAlert APIs are versioned independently.

Implementation notes

Pulsar seems to cause approximately 5ms of latency for each message, which is consistent with their promise. The latency is not a problem in itself, and is well within acceptable bounds. However, the latency means that a single-threaded consumer-producer loop can only process 200 messages per second.

You can’t perform that action at this time.