# 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.