Skip to main content

Syncing to the Map

Operators don't work in a database — they work on a map. Every camera, its live position, nearby incidents, and the geographic boundaries that define alert areas all have to appear as layers in ESRI/ArcGIS. The Admin API is one of the places that pushes the platform's data out to that map.

The one idea to hold on to​

Map sync is feature-layer plumbing: authenticate with an ESRI token, convert platform data to ArcGIS geometry, then reconcile the layer — query what's there, delete what's gone, upload what's new. EsriMapSync exposes exactly those steps:

full-sync runs the whole reconcile in one call; the individual endpoints (convert-to-arcgis, query-object-ids, delete-features, upload-features) let you drive or debug a single stage. The geometry conversion leans on the Infrastructure geometry service — the same WKT/GeoJSON machinery behind alerts.

Gotcha: ESRI is a separate store, written from more than one place

The map layer isn't the source of truth — it's a projection, and it can drift from Cosmos/SQL if an upload or delete fails. full-sync is the reconciler that heals that drift. Also note the Admin API isn't the only writer: the engine submits live camera online/offline and PTZ status to ESRI on its own, and AI detections reach ESRI Velocity through the notification path. When map data looks wrong, the first question is which writer last touched that layer.

Wrapping up​

Syncing to the map is ArcGIS feature-layer reconciliation: token auth, convert platform data to ArcGIS geometry, then query/delete/upload — with full-sync as the one-shot reconciler that heals drift. Per-camera locations, the PulsePoint incident feed, and GeoJSON boundary imports round out what reaches the map. Remember the layer is a projection with several writers, not a source of truth.

Every change so far leaves a trail. Next, the system that records them all: Auditing.