Add transjakarta-live-data research topic

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.

transjakarta-live-data/next-steps.md

@@ -0,0 +1,23 @@
+# 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.