How WorldEye builds its camera network

Regional collections, collected on the server. The catalogue is assembled server-side from regional collections — 77 of them in the October 2026 snapshot — each maintained by a loader for a country, a US state network, or a source family. A loader polls the publisher's own list endpoint or public API (Finland's loader, for example, reads Fintraffic's official Digitraffic station list — one request per refresh, not one per station) and maps what it publishes into catalogue records. The globe never queries publishers directly; it serves the assembled catalogue, which is what makes a single, checkable population possible.

Three intake paths. Most cameras arrive through direct integrations with the publishing agency or network. A second path is the OpenCCTV harvest: an offline generation process that imports records from the OpenCCTV dataset — but only from source families whose licensing has been reviewed and cleared. Families are registered as cleared, conditional (held out unless spot-checked and explicitly enabled for a run) or excluded (never imported, and not force-enableable); feeds hosted by Windy are refused under any family, because its catalogue terms do not clear. A third path collects webcams their operators broadcast publicly — resorts, harbours, beaches and similar — as their own collections.

What a record carries. Each record keeps the publisher's camera id (namespaced by provider, so regenerating a source reproduces the same ids), its name, city and country as published, its coordinates, at least one way to view it — a snapshot feed, a stream, or a link to the publisher's own page — and its source label. The source label is the attribution: it names the publisher on the camera and in the datasets, and registry entries map sources to their required attribution and terms (Fintraffic's data, for instance, is CC BY 4.0 and is labelled accordingly).

Inclusion is not a redistribution licence. A separate rights gate decides, camera by camera, whether a record may be carried on the surfaces that hand cameras to third parties — the enterprise feed and embed. The verdict is computed from the source label: a harvested camera passes only when its family's registry verdict is “clear” (conditional families are held out, excluded families never pass); a direct agency source passes only where a clearance basis is on file; and any source with no basis on file is excluded by default, with the reason recorded. Windy-sourced cameras are excluded whatever label they arrive under, because Windy's terms grant no commercial redistribution. Where a camera does pass, the payload attributes it to its operating agency.

What never gets in. Records are skipped — with the reason recorded, not silently dropped — when they are inactive or missing an id, lack a usable feed address, use a non-web pseudo-URL, carry an unknown feed type, point at a known offline-placeholder path, or have invalid coordinates. A snapshot source that records that adding a refresh parameter breaks its URLs is also refused, because its stills would break on first refresh.

Coordinates are the publisher's own. A camera sits where its publishing source says it sits: loaders map the latitude and longitude from the publisher's data, and WorldEye does not geocode addresses into camera positions. (Finland's integration states the rule in terms: coordinates are the API's own geometry, never geocoded.)

Validation, not correction. Incoming coordinates must be finite numbers inside the valid ranges (latitude −90 to 90, longitude −180 to 180); the null-island point (0, 0) is rejected outright. Some loaders additionally apply the source's own geographic bounding box to drop stray or placeholder coordinates a feed may carry. WorldEye validates coordinates — it does not move cameras to where they look better, so a publisher's misplaced record stays misplaced until the publisher fixes it; that is one of the limitations listed below, and one reason corrections are solicited.

Country names are canonicalised. Publishers label countries inconsistently — codes and variants (US, UK, JP…) alongside full names. A normalisation table maps these to canonical country names. The table is not a single shared file — the runtime catalogue, the country-page generator and the Live Camera Index each carry a copy, and the copies are kept in agreement, so the three measure the same countries. Values that name no country are counted as unattributed — 3 records in the current index — rather than force-assigned to a plausible-looking country.

One record per view. Where a single physical station publishes several views, each view is its own record with its own still — Fintraffic stations carry 1–7 presets. Counts on this site are therefore counts of camera views as published, which is the unit a visitor can actually open.

The same physical camera reaches the catalogue by several roads: two regional collections can overlap, two publishers can carry the same feed, and one camera can be reported under spelling- or punctuation-variant names. Deduplication runs at three levels.

By ID, everywhere. Whenever collections are combined — the union that builds the country index, the snapshot that measures the served count, and the map client's own merge — records are keyed by camera ID and the same ID is kept once. This is why raw record counts exceed unique cameras: the October 2026 snapshot's 84,455 records merged to 83,795 served cameras.

Near-duplicates at build time. The country index runs a second pass: the same normalised name at effectively the same spot — within about 100 metres — is the same camera reported twice, and the later record is dropped. Dropped near-duplicates are counted (798 in the current build) and enter the index's reconciliation, so a page's stated count is exactly the number of cameras its grid can show.

Harvest matching, in order. A harvested record is classified against the served catalogue and against everything already accepted from the harvest, using matchers in a fixed order: identical catalogue ID; identical feed URL (full form, then host-and-path with query differences forgiven); same location — within 10 metres, whatever the names say; and geographic-plus-name — within 120 metres with name-token containment of at least 0.5. A record within 120 metres whose name does not match is classified near-distinct: an intersection legitimately has several cameras, and it is kept as the distinct camera it is — reported separately, never merged into its neighbour.

A probe before a harvested camera gets in. Verification for the harvest happens at generation time, because probing tens of thousands of feeds cannot run inside a web request. The probe fingerprints each feed with a small range request — roughly the first 2 KB, not a full frame. A snapshot feed passes only with an HTTP 200/206 response and an image content type or image file signature; a stream passes only if its playlist begins with the HLS marker #EXTM3U and lists segments or variants; a publisher page passes on reachability. Identical first bytes served by three or more different cameras mark the feed a placeholder — one standby image, not three working cameras — and placeholders do not enter the verified set. Probes time out at 8 seconds, verdicts are cached, dead verdicts are re-probed after 24 hours, and live verdicts after 7 days. A "dead" verdict is a floor, not a certainty: some hosts refuse datacenter requests while serving browsers fine, and the harvest reports say so.

Continuous re-collection at runtime. The live catalogue is not a static list: each regional collection is cached for 30 minutes and then re-collected from its publisher, so additions, moves and retirements flow in continuously. When you open a camera, its frame is fetched from the publisher at view time — WorldEye keeps no archive of frames to re-serve as live.

Failures are absorbed, then flagged. If a publisher fetch fails, the catalogue keeps serving that source's last good index rather than dropping its cameras to zero; a source that times out or answers empty is rested for 5 minutes before the next attempt so a down upstream cannot stall the refresh for everyone else. Behind the scenes, every fetch outcome is recorded, and a health rollup classifies each source — healthy, degraded, down, or not yet observed. Its sharpest rule is the silent-absence rule: a source known to publish cameras that currently serves zero is treated as down — never as "healthy at zero" — because that is exactly how a broken sub-source once hid inside a green region for months.

Retirement flows from the publisher. Because the live catalogue is re-collected from publishers on the refresh cycle, a camera a publisher retires leaves the catalogue at the next refresh — nothing is pinned forever. Publishers also mark cameras out of service in their own data, and loaders honour those marks at collection time: Fintraffic stations the API marks removed, and presets it marks out of collection, are skipped rather than served.

Generated sources change only on a reviewed sync. The OpenCCTV harvest is regenerated offline and committed, and the sync is gated: a run whose accounting does not reconcile writes nothing; a run that would shrink the regenerated set by more than 5% is refused unless a human explicitly allows the shrink, so a probing outage can never wipe the harvest; a run that grows it by more than 50% is refused the same way. Within the harvest, a dead-feed verdict is not permanent: it is re-probed after 24 hours, and a record leaves the harvest when a generation is built on a current dead verdict — and returns if a later re-probe finds the feed alive again.

Snapshots keep their dates. The country index and the Live Camera Index are not silently rewritten: each is a dated snapshot (currently October 20, 2026 and October 23, 2026), re-issued when the catalogue changes, with its dataset kept available so any figure can be checked against the edition that published it.

WorldEye publishes three numbers that are easy to confuse, because they are three different instruments. These are the definitions the site uses; the Live Camera Index is the dated measurement of record, and the country directory renders the indexed catalogue.

Read together: the indexed catalogue (77,376 unique records) is the fullest picture of what the loaders index, built as a union across assemblies. A single live assembly rarely carries all of it at once — some collections are always mid-refresh — while the served snapshot (83,795 unique cameras on October 23, 2026) reflects what the globe actually held that day, drawn from 113 countries. The headline 74,229 is the published figure for the network. None of the three is "the real number" in isolation; each is the answer to a different, stated question.

Every camera in the catalogue names its publishing source, which makes errors checkable: a wrong name, place or coordinate can be compared against the publisher's own data, and a dead feed against the publisher's current list. If you find a camera that is misplaced, mislabelled, no longer operating, or listed where it should not be, report it through the contact page — the team replies within 1–2 business days. Reports are reviewed against the source: where the publisher's data is wrong, the record follows the publisher; where our assembly is wrong, we fix the assembly — a duplicate rule, a normalisation gap, a loader's mapping — rather than hiding a single record. Publishers and camera operators who want a listing corrected, attributed differently, or removed are welcome to use the same route.