Why a camera you can see isn't always on the map

You passed a reader on a pole and the app showed nothing. That is not a bug — it is the honest edge of an open dataset, and there is a way to close it.

It happens often enough to be worth explaining: you drive past an unmistakable license-plate reader, check the map, and there is no dot. Nothing has gone wrong. You have found the edge of what open data covers.

The dataset maps documentation, not reality

FlockDetour's ALPR layer is built from OpenStreetMap nodes tagged as surveillance. A camera appears on our map only after somebody has seen it, identified it, and recorded it there. Between installation and documentation there is a gap, and the gap has no fixed length — some readers are mapped within days, some are still unmapped years later.

So the map answers a narrower question than it appears to. Not where are the cameras, but where have cameras been documented. Those overlap heavily in well-mapped cities and much less in places with few active mappers.

The four common reasons for a gap

  1. Nobody has mapped it yet. The overwhelmingly common case, especially for recent installations and for rural corridors.
  2. It is mapped without the right tags. A node tagged only man_made=surveillance with no surveillance:type may be a generic CCTV camera rather than a plate reader, and we will not claim it is an ALPR on a guess.
  3. It is not the kind of camera you think. Plenty of roadside hardware is a traffic-flow sensor, a weather station, or a DOT monitoring camera that records no plates at all. Mapping those as readers would make the map worse.
  4. It moved. Trailer-mounted and vehicle-mounted readers are real and are not fixed infrastructure. A dataset of fixed locations cannot represent them, and we would rather show nothing than show a stale dot as if it were current.

Closing the gap properly

The durable fix is an edit in OpenStreetMap. A reader documented there flows into FlockDetour on the next dataset refresh — and into every other project reading the same tags, which is the entire point of doing it upstream instead of in a private database.

A useful node carries the position, man_made=surveillance, surveillance:type=ALPR, and where you can identify it, the operator. Direction helps. A short note about where exactly it is mounted helps the next person verify it.

Correcting the shared dataset helps everyone reading it. Correcting ours would only help us.

What this means for a route

Treat a zero-camera route as zero known cameras, and treat the map as a floor on coverage rather than a complete picture. That is why the app compares routes instead of certifying them, and why every surface carries the same caveat: FlockDetour reduces exposure to documented cameras. It cannot identify every camera or guarantee avoidance, and it is never a reason to stop watching the road.