When a magnitude 7.5 earthquake struck Venezuela in June 2026, responders faced the question that follows every disaster: which buildings are damaged, and where should help go first? Within days, fresh high-resolution satellite imagery flowed through OpenAerialMap to the OSM community for mapping the impacted areas and to open AI models that flagged damaged structures. Weeks earlier, the same pipeline had served Hurricane Melissa in Jamaica and catastrophic floods in Mozambique. The imagery is the hinge the whole response turns on, and getting it to the people who need it, fast and openly licensed, is harder than it sounds.

OpenAerialMap has been the open catalog for openly-licensed aerial and satellite imagery for more than a decade. Humanitarian mappers, OSM editors, damage-assessment models, and QGIS users all pull from it. Under the hood, though, it had become a fragile Node.js and MongoDB system that only a couple of people knew how to keep running. That is exactly the kind of single point of failure you do not want between a disaster and a usable map, so in 2025 we rebuilt it.

The new stack will look familiar to anyone in this room. Imagery lives as Cloud Optimized GeoTIFFs, the catalog is a STAC API on pgSTAC and stac-fastapi, TiTiler handles dynamic tiling, PMTiles carry the vector footprints, and the whole thing runs on Kubernetes. Migration jobs keep syncing the legacy database and partner open-data collections into the new catalog. The catalog has grown about 65 percent this year to roughly 57,000 searchable images, and it stayed online through every disaster of the year.

On top of that sits a rebuilt front end on a familiar MapLibre and PMTiles stack, talking to the same STAC API and TiTiler. It lets anyone browse a global footprint mosaic at any zoom, filter to what they need, inspect image metadata, and open imagery straight into iD or JOSM, paired with new resumable upload functionalities for the multi-gigabyte scenes disaster imagery produces. Building it surfaced a trade-off every open-source team knows well: how far to build on an existing community project, with the reach and shared maintenance that brings, versus a custom client that fits exactly but is yours to maintain. The talk digs into how to weigh that, since it is a decision most projects face and few discuss honestly.

Much of this was built by a small team leaning on AI coding agents, with human review to confirm the functionality works as intended. That is what made an ambitious rebuild feasible on a nonprofit budget, and it pushed HOT to write a responsible-AI policy for how the tools are used. The honest trade-offs, what the agents accelerated, where they fell short, and the old craft-versus-automation tension familiar from OSM's import debates, matter more to this community than the hype.

Attendees leave with a working reference architecture for an open imagery pipeline that holds up under real disaster load, the build-versus-adopt math for reusing open geospatial components, and a grounded read on where AI-assisted development helps a small open-source team and where it does not. Everything shown is open source and running today.

OpenAerialMap Phase 2 is funded by the Cisco Foundation and built by HOT with Development Seed, with a large-file uploader contributed by student volunteers at UC Berkeley. The code lives at hotosm/openaerialmap and related repositories.