Connector support
Separate supported local paths from future integration candidates.
Open Transit RT uses explicit adapters for vehicle telemetry, prediction, validation, monitoring, and discovery workflows. Review the current path before connecting real systems.
Works Today For Local Or Self-Hosted Evaluation
| Area | Supported path | Where to review |
|---|---|---|
| Vehicle data | CSV replay, HTTP polling, webhook sidecar, generic JSON transform, authenticated telemetry POST. | /admin/operations/connectors |
| Prediction | Deterministic built-in predictor and external HTTP predictor adapter with shadow mode. | /admin/operations/prediction-lab |
| Validation | MobilityData static GTFS and GTFS Realtime validator wrappers when tooling is installed. | /admin/operations/validation-health |
| Monitoring and export | Local monitoring/export helper and private summaries. | /admin/operations/maintenance |
| Discovery | /public/feeds.json plus schedule and realtime feed URLs. | /admin/operations/feed-health |
Planned Or Candidate Work
Prediction engines
TheTransitClock and other predictors are candidates behind the prediction adapter. They are not bundled runtime dependencies or ETA-quality proof.
Vendor AVL and SIRI-shaped systems
Real vendor payloads and SIRI bridges need explicit adapters, redaction, credential handling, and deployment-owner review.
GTFS QA extensions
GTFS-Flex, GTFS-ride, GTFS-Pathways, and GTFS-Fares v2 are future QA areas, not current dispatch, booking, fare-payment, or analytics features.
Aggregator and consumer preparation
Transitland, Mobility Database, OpenTripPlanner, and OneBusAway checks remain preparation or investigation until implemented and tested.
Limits
Connector documentation does not prove compatibility with named vendors, certified hardware support, production AVL reliability, consumer acceptance, compliance, hosted service availability, production readiness, SLA coverage, or ETA quality.