3a518be39f
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.
1.4 KiB
1.4 KiB
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.