0xrsydn/research
1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
research/comuline-krl-data/analysis.md
hermes 77b0a55c41 Add comuline-krl-data topic + jakarta-public-transport-data umbrella 
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.
2026-10-12 12:17:01 +00:00

3 KiB
Raw Blame History

Analysis — how comuline works

Pipeline

  1. Sync (daily cron, as designed): comuline/api/src/sync/station.ts fetches {KRL_ENDPOINT_BASE_URL}/krl-station; schedule.ts then iterates all stations in batches of 5 (5 s sleep between) — CORS OPTIONS preflight, then GET /schedule?stationid={id}&timefrom=00:00&timeto=23:00. Requests carry browser-like headers plus a hardcoded bearer token, because the upstream is an authenticated partner API.
  2. Transform: stations → st_krl_<id> records (upstream WIL entries filtered; airport station BST manually added); schedules → sc_krl_<station>_<train> rows with origin/destination station IDs resolved by name, departs_at/arrives_at timestamps, and line color; upserted into Postgres.
  3. Serve: Hono API on Cloudflare Workers (Neon Postgres + Upstash Redis per-station read cache) exposes clean JSON with an OpenAPI spec; web/native apps consume it.

KRL_ENDPOINT_BASE_URL = https://api-partner.krl.co.id/krl-webs/v1 (from the repo's .dev.example.vars).

Data model (public API)

  • Station: { uid, id (e.g. MRI), name, type (KRL|LOCAL), metadata.origin.{daop,fg_enable}, active }
  • Schedule row: { id, station_id, station_origin_id, station_destination_id, train_id (e.g. 1448B), line ("COMMUTER LINE BOGOR"), route ("JAKARTAKOTA-DEPOK"), departs_at, arrives_at, metadata.origin.color }
  • Route view (/v1/route/{train_id}): ordered stop sequence (station name + departure time) for one train.

Observed state (2026-10-12)

  • API live; 113 stations served. Row counts sampled: MRI 1,045 · DP 730 · CLT 683 · JAKK 367 · BOO 341 · TNG 84 · BEK 0 (station present, no schedule rows).
  • Freshness: the newest updated_at values are bulk 2024-11-13 and partial re-sync 2025-03-30; nothing newer. Repo activity stops the same month (api last push 2025-03-30). Conclusion: the daily cron is not currently running; the data is a frozen snapshot (~18 months old as of this audit).
  • No realtime tracking: no position/GPS data in the bundle or API. The product is schedule lookup with locally saved stations.

Boundaries respected (deliberate limits)

  • Upstream api-partner.krl.co.id was probed once without credentials (returned 404) to characterize the auth wall.
  • No calls were made using the token published in the public repo. The token is not reproduced in this vault.
  • No attempts to bypass auth, rate limits, or access controls.

Confidence

  • Established: pipeline structure and architecture (public source + live API); coverage counts; staleness timestamps; absence of live tracking; upstream URL and auth wall.
  • Inferred: why the sync stopped (project dormancy vs token expiry vs upstream change — not observable from outside); whether the upstream data model changed since.

Artifacts

  • Evidence archive: workspace/comuline-captures/ — page HTML + headers, web bundle, live API samples (stations.json, sched_MRI.json, openapi.json), sync sources (bearer token REDACTED in the archive copy), dev.example.vars.