How UFO Intel Maps 60,000 Sightings in Real Time

It's easy to make a map with a few dozen pins. It's harder to make one that holds tens of thousands of sightings, updates the moment someone files a report, and still loads smoothly on a phone with one bar of signal. This piece is a plain-English look under the hood of UFO Intel's UFO sighting database — not a sales pitch, just how the thing actually works, and why we made the choices we did.

The data pipeline: seed, then grow

The map didn't start empty. It's seeded with roughly 60,000 historical reports from the National UFO Reporting Center, cleaned and geocoded, plus curated public-domain cases — including the officially released Navy videos discussed in our piece on the Pentagon's UAP files. That seed gives every new sighting context on day one. From there the dataset grows organically: each approved report is appended to the same store, so historical and live data share one coherent map rather than living in separate silos.

Ingesting messy public data is its own small discipline — normalizing dates, salvaging coordinates, collapsing a hundred spellings of the same shape into a clean set of categories. The unglamorous data cleaning is what makes the shape and date filters trustworthy later.

A spatial database, not a list of points

The core is a SQL Server database using proper geographic types, so every sighting is a real point on a sphere rather than a pair of loose numbers. That matters the moment you ask a spatial question — “what sightings fall inside this map viewport?” or “how many reports are within this alert radius?” With a spatial index behind it, those queries stay fast even as the table grows, which is what lets the map answer a “near me” request or evaluate an area alert without scanning everything.

On top of that sits a small API that returns only what the current viewport needs, as compact GeoJSON. The map never downloads the whole dataset; it asks for the slice you're looking at and clusters the rest server-side. That's the trick behind staying quick on mobile — you're moving kilobytes, not megabytes.

Rendering: clustering on the client, honesty in the counts

The front end uses a self-hosted vector map library so there's no dependency on a third-party tile service that could rate-limit or disappear. Clustering happens as you zoom, the numbers on each cluster are exact rather than estimated, and switching to the heatmap is just a different way of drawing the same honest data. Media — photos and short videos — is optimized on upload (images to WebP, video to web-friendly MP4) and streamed with range requests so a clip starts playing without downloading in full.

The studio behind it

UFO Intel is a project of ProjectThunder, a .NET studio whose day job is exactly this kind of data-heavy application. The same team builds an open-core .NET 10 commerce engine with agent-ready APIs and audit logging — the same ingredients as this map: fast spatial queries, clean read APIs, and a front end that stays quick on a phone. UFO Intel is what happens when that toolkit gets pointed at the night sky instead of a storefront.

Built to be read by humans and machines

Finally, the site is designed to be legible to more than just browsers. There's a machine-readable feed of recent sightings, a viewport GeoJSON API, and a plain-text site map for language models, all so the open record is genuinely open — queryable by researchers, agents, and anyone building on top of it. A crowd-sourced dataset is only as valuable as it is accessible, and accessibility here means both a clean mobile map and a clean API.

None of this makes any single sighting more or less true — reports remain user-submitted and unverified. What the engineering buys is trust in the plumbing: that the counts are real, the map is current, and the record is there for anyone to examine. The rest is up to what people choose to report.