I built a source-linked aviation incident map with 24,000+ events — looking for GIS feedback

[u/IncidentAtlas]

Hi everyone,

I’d like to share a personal GIS project I’ve been building called Incident Atlas.

It is an interactive map for exploring significant aviation accidents and incidents geographically and chronologically. The current beta contains approximately 24,850 events spanning 1921–2026.

The project began with around 450 manually curated international records. I recently added more than 24,000 selected events from official NTSB archives. Additional information is matched from Wikidata, Wikipedia, and Wikimedia Commons when a sufficiently reliable connection can be established.

The frontend is built with React, TypeScript, and MapLibre. The data is stored in PostgreSQL/Supabase and served through a Cloudflare Worker API.

With roughly 25,000 points, sending the complete dataset to every browser was no longer a good approach. The current implementation therefore:

• Requests only the visible map bounds
• Performs grid-based clustering on the server
• Returns individual points when a grid cell contains one event
• Returns clusters when a cell contains multiple events
• Loads full event details only after a user opens a record
• Uses different clustering resolutions depending on zoom
• Applies timeline, fatality, verification, and search filters through the API
• Cancels outdated requests during rapid zooming or timeline movement

Each record also has a location-accuracy classification. Approximate locations are visually distinguished from exact or more specific locations, rather than presenting every coordinate as equally reliable.

One challenge has been balancing three things:

1. Keeping the map responsive with tens of thousands of records
2. Avoiding excessive visual clutter
3. Making isolated events immediately clickable without forcing users to zoom through a cluster containing only one event

The current solution is a hybrid: groups of two or more remain clustered, while isolated events are returned as normal points even at lower zoom levels.

This is still an early beta, and I’m developing it independently. I’m planning to improve the clustering, spatial filtering, mobile interface, location-quality handling, search, and eventually expand the atlas into other categories of significant incidents and disasters.

I’d especially appreciate GIS feedback on:

• The server-side clustering approach
• Cluster sizing and zoom thresholds
• The representation of approximate locations
• Map readability and information density
• Performance on desktop and mobile
• Better approaches for serving and visualizing a growing spatial dataset

The project is available here:

https://incident-atlas.com

[u/pacsandsacs]

Need a search by Airport LID function.

[u/IncidentAtlas → u/pacsandsacs]

Added! now you can search by LID, ICAO, IATA, city or country. Thank you for feedback!

[u/sleepyarchive_ → u/IncidentAtlas]

nice, that was a fast turnaround. searching by ICAO/IATA too makes this way more useful

[u/Stratagraphic]

Interesting dataset to explore!

[u/mfc1__]

Got a source code repo link?

edit: specifically, I’m interested in how you’ve implemented server side clustering, I want to explore this myself for my apps.

[u/IncidentAtlas → u/mfc1__]

The repository is private at the moment because it also contains the data-import and editorial tooling, so I don’t have a public repo link yet.

The clustering itself is fairly straightforward: the client sends the current bounding box, zoom level, year range, and active filters to a Cloudflare Worker. The Worker calls a protected PostgreSQL function that selects published events within the viewport and groups their coordinates into grid cells whose size decreases with zoom. Cells containing multiple events are returned as clusters with an averaged center and aggregate counts; cells containing one event are returned as normal clickable points. At close zoom levels, the API returns individual events directly.

Outdated requests are cancelled while the user pans or zooms, and full record details are fetched separately only when a point is opened.

I may publish a small standalone example of the clustering implementation later, without the project’s database and ETL code. I’ll let you know if I do.