Verified TransJakarta realtime stack: anonymous MQTT bus feed (wss://mqtt.tj.co.id:8084/mqtt), guest REST API (tijeapi.transjakarta.co.id), official GTFS. Cross-capture verification vs third-party tracker, connection recipes, snapshot tool.
23 lines
1.4 KiB
Markdown
23 lines
1.4 KiB
Markdown
# Next steps / open questions
|
||
|
||
## Open questions
|
||
|
||
- Exact ingest path from vehicle GPS hardware into the broker — not observable from outside.
|
||
- oyenza's exact subscription method (whole-tree subscribe vs per-cell sweep) — unresolved; the served data is identical to the broker's either way.
|
||
- Full REST surface: ~105 endpoints per open-tj (routes, stops, schedules, fares, facilities, Tara chatbot). Worth enumerating if a project needs them.
|
||
- bustrack.transjakarta.co.id auth model (Traccar) — session probe returned 404; likely internal, but could be explored further.
|
||
- Whether anonymous MQTT access is intentional or an oversight — affects long-term viability.
|
||
|
||
## Risks
|
||
|
||
- Access policy can change without notice; all third-party trackers depend on the same two entry points.
|
||
- Per-bus refresh observed ~8–75 s; apps showing 1–3 s updates re-batch/interpolate the same data — plan for the real cadence.
|
||
- No API versioning or deprecation contract exists for third-party consumers.
|
||
|
||
## Ideas for future use
|
||
|
||
- Personal realtime dashboard / alerts ("bus X is N stops from my stop").
|
||
- Fleet analytics from archived captures: headway estimation, bus-bunching detection, corridor coverage over time.
|
||
- Continuous capture into a time-series store → historic delay/performance analysis.
|
||
- Combine feed positions with GTFS schedules for ETA modeling.
|
||
- Cross-validate against the bustrack/Traccar system if access ever opens.
|