Second audit under the Jakarta public transport umbrella: comuline.com replicates KAI Commuter's official partner API (api-partner.krl.co.id); its data has been frozen since ~2025-03-30. Adds the umbrella hub, the comuline topic (sources/analysis/recipes/next-steps), and links the existing transjakarta-live-data topic under the umbrella.
1.5 KiB
1.5 KiB
Next steps / open questions
Open questions
- Why did comuline's sync stop (~2025-03-30)? Project dormancy, token expiry, or upstream change — not observable from outside. (Author is reachable via the links in comuline-krl-data/sources.)
- Current shape of the upstream partner API's data model (
krl-station,schedule) — unverified; no credentialed call was made. - Live KRL tracking sources: community trackers claim ~30 s updates (trackmycommuter, krljakarta.com, botkita). Where do their positions come from? A dedicated audit would be its own subtopic (KRL realtime — likely a different upstream than schedules).
- MRT Jakarta / LRT Jabodebek data sources (
jakartamrt.co.idAPI was referenced by one community project) — candidates for umbrella subtopics.
Risks
- Comuline API: frozen data; treat as reference only. Add freshness checks; do not build a "current timetable" product on it without another source.
- Upstream partner API: authenticated; using the repo-published token is not acceptable use. Legitimate access = partner agreement.
- Both are informal dependencies that can change or disappear without notice.
Ideas
- Freshness monitor for the comuline API (alert when data updates — would signal the project waking up or a re-sync).
- Multi-modal view: join transjakarta-live-data/index + KRL schedules to prototype Jabodetabek trip planning.
- If current KRL timetables are needed long-term: evaluate official channels (KAI Commuter app/website) or pursue partner access properly.