research/jabodetabek-cctv-live-data/next-steps.md

1.9 KiB

Next steps

Re-verify (access is undocumented and can change)

  • Re-run the per-host probe (script pattern in methodology.md; archive has probe.sh) — catalogue the current live/dead state with a fresh timestamp.
  • Watch for CORS/Referer/token introduction by any operator (any host switching from Access-Control-Allow-Origin: * breaks the hotlink pattern).
  • Track oyenza's catalog hash (/assets/asset-cctv-<hash>.json) — a change signals a re-check/redeploy; the checkedAt value gives the cadence.

Gaps to close

  • Verify from an Indonesian vantage: bsw.kotabogor.go.id and cctv.balitower.co.id TCP-timeout from our network (likely geo/IP filtering). Confirm both are alive and that BSW's detail pages are the only listing for Bogor cams (we verified via reader proxy).
  • Confirm the DKI portal's full camera count trend (52 at capture) and whether oyenza adds future DKI cams beyond its current 14 roads.
  • Jasa Marga exclusion: check jmlive.jasamarga.com from an Indonesian vantage — if the manifest serves there, its absence from oyenza implies a deliberate policy/coverage choice, not a dead feed.

Candidate sources to verify next (leads, not yet re-verified)

  • atcs-jakarta.com (Dishub ATCS map), atcs-bptj.dephub.go.id (BPTJ/BKJT streaming), smartcity.jakarta.go.id CCTV layer, lewatmana.com/cam (DKI re-embedder), cctv.balitower.co.id (Balitower public portal).
  • Non-Jabodetabek: BPJT page carries cams nationwide (Makassar, Sumatra) — same scrape pattern applies if ever needed.

Ideas

  • Small prober tool: check all 310 catalog URLs (or any list of HLS URLs), report live/dead + segment cadence — reusable for any future "is this feed up?" question.
  • Snapshot tool for one camera (grab a few segments' worth of playlist + segment list) mirroring transjakarta-live-data/scripts/tj-snapshot.mjs style.