In the first post in this series, we looked at why open licensing is essential to humanitarian mapping. The next challenge is operational: turning large, heterogeneous archives into imagery people can actually find and use. This is the role that OpenAerialMap (OAM) is designed to play.

From Imagery Archive to Searchable Catalog

OAM is a commons of openly licensed aerial and satellite imagery from drone teams, governments, commercial providers, local mappers, and other organizations. The newest version of the OAM website and uploader recently launched is part of a broader shift towards cloud-native standards that make it easier to bring different imagery sources into a common discovery experience.

At the center of that architecture is STAC, the SpatioTemporal Asset Catalog specification, to describe geospatial assets in a common way: where an image is located, when it was collected, who provided it, what it contains, and how it can be accessed. That shared structure means OAM doesn't need a custom integration for every new imagery archive.

If a provider already hosts imagery at stable, publicly accessible locations and maintains a STAC catalog, OAM can ingest and index its metadata while the imagery itself stays in the provider's infrastructure without the need to transfer its imagery into OAM storage. OAM then displays, filters, and visualizes those assets through its own catalog.

Discovery is only half of the equation. The imagery also needs to be efficient to access, which is why OAM works with Cloud Optimized GeoTIFFs (COGs). COGs allow applications to stream only the portions of a large file they need rather than downloading the entire image first.

In simple terms:

• STAC tells applications what imagery exists and where to find it.
• COGs make that imagery easy to access and visualize once it is found.

The OAM Readiness Checklist

When HOT evaluates a new external imagery catalog for potential ingestion into OAM, the technical conversation begins with six core questions:

1. Is the imagery publicly accessible? OAM needs a reliable way for users and applications to reach the underlying imagery without credentials.
2. Is the spatial resolution fit for mapping? OAM is for imagery detailed enough to trace buildings and roads, which in practice means sub-metre: drone imagery at a few centimetres per pixel, and very-high-resolution satellite imagery at 30 to 50 cm.
3. Is the imagery available as a Cloud Optimized GeoTIFF? A COG lets a map read the part of an image it needs rather than the whole file, which is what makes streaming large scenes practical.
4. Are the imagery locations stable? URLs in the catalog need to keep pointing to the same imagery over time, ideally from stable cloud storage such as S3 or a comparable system. If locations change often, OAM has to keep updating or re-ingesting the records.
5. Is a basic set of metadata published alongside the imagery? Acquisition date, sensor or platform, provider, and license, per image. A STAC catalog is the preferred way to do this and lets OAM read the metadata as-is, but it isn't required: OAM's metadata model defines a minimum field set, and existing fields can be mapped onto it rather than recreated.
6. Is the license clear about permitted uses? OAM needs to understand what users can do with the imagery, including whether it can be traced into OpenStreetMap, analyzed, used in other workflows such as GeoAI or ML, or incorporated into derived datasets. Some licenses may require additional permissions or carve-outs for particular uses. See "Degrees of Open Imagery” below.

The Ingestion Pipeline

Once those questions are understood, OAM and the provider can determine how the imagery should be ingested into the catalog. The route comes down to whether that storage is organized as a STAC catalog:

• A STAC catalog that already follows the spec. The simplest case: hand OAM the catalog URL. OAM reads the metadata as-is and re-ingests on a regular cycle to stay in sync, pulling in metadata, not the imagery itself. No work required on the provider's side.
• A STAC catalog with its own field names. Just as common. OAM maps the provider's fields onto its schema once (a provider's acquired_on field to STAC's properties.datetime, for example) and re-ingests from there the same way.
• Public cloud storage with no catalog at all. A provider may already publish Cloud-Optimized GeoTIFFs to a bucket without having built a STAC catalog for them. OAM can generate that catalog on the provider's behalf once a metadata set is agreed on. This route is still in development.

Depending on technical capacity, either OAM builds that ingestion job, or a provider or technical contributor builds one directly in the OAM codebase and contributes it back to the project. The ingestion method is separate from a provider's broader contribution model. A provider may be technically ready to connect an entire STAC catalog, for example, but choose to begin with only a defined subset of imagery.

Degrees of Open Imagery

Everything above covers how imagery technically moves into OAM. A separate question underneath it all is how much of an archive a provider is ready to open and under what conditions.

OAM indexes CC-BY 4.0, CC-BY-SA 4.0, and CC-BY-NC 4.0 today, with support for CC0, ODbL, and other standard open licenses on the way. A provider using a custom open data license can also be added as long as it maps onto one of these standard terms so OAM can still filter and publish it consistently alongside everything else in the catalog.

A standing open license

A provider that's ready to release a defined portion of its archive, a full catalog, or a clearly bounded subset, under an open license connects it once through the ingestion paths above, and it stays discoverable through OAM going forward. This is the most accessible and desirable option from a humanitarian mapping perspective, and also the lowest maintenance once it's set up because there is no case-by-case review or negotiation.

Esri set a precedent for this kind of standing access just outside OAM's own catalog. Since 2017, it has made its World Imagery basemap available to OSM under a standing permitted-use grant with no per-request approval needed from HOT or any other mapper who wants to trace from it.

A disaster activation

Some providers would rather release imagery only when a major disaster occurs rather than maintain a continuously open archive. The value comes from providers setting the legal pathway up before the emergency and releasing imagery under a Creative Commons license (CC-BY-NC-4.0) so it can be ingested directly into OAM, rather than negotiating those terms from scratch during an active response, when speed matters most.

For example, when an earthquake struck Venezuela in June 2026, Vantor released 49 images total of both post-event satellite imagery and pre-event baseline imagery stretching back to November 2025, with Planet contributing post-event imagery alongside it. Two months later, when flash floods hit Nepal's Bhote Koshi and Trishuli corridor on August 26, the same two providers released 70 satellite images total the very next day (31 from Vantor's very-high-resolution constellations and 39 from Planet's Pelican, PlanetScope, and SkySat fleets), with new coverage still arriving two weeks later. Combined with Esri World Imagery and Sentinel, the imagery has already helped volunteers map 1,251 buildings and 29 km of road in the activation area. That kind of satellite imagery accessibility, and the mapping it makes possible, only happens when the open licensing is agreed to ahead of time.

A scoped pilot

A provider doesn't have to start by opening an entire archive or only releasing imagery during a disaster activation. A pilot can focus on a defined geography, time period, imagery collection, or use case, giving HOT and the provider room to work through licensing, metadata mapping, attribution, and user feedback together before committing to something larger.

Reducing Barriers with a New OAM Uploader

Everything above assumes a provider already has, or is building toward, a STAC catalog. Not every contributor does. Drone teams, local organizations, researchers, and smaller imagery producers often just have imagery they want to share with no catalog infrastructure behind it. For them, the most direct route is the OAM uploader.

In the past, the OAM uploader struggled with very large files. The Freetown drone mapping project is a good example: the standard uploader couldn't complete the transfer of large drone imagery files, and the team had to fall back on a manual workaround.

The new uploader fixes that with resumable multipart uploads: large files transfer in smaller chunks, and if the browser closes or connection drops, the upload resumes from where it left off instead of starting over. It also extracts richer metadata for the STAC catalog automatically at upload time, improving catalog quality along with the upload experience itself.

The new uploader makes it easier to move imagery between HOT tools as well. A workflow with Drone Tasking Manager, for example, can open the OAM upload form with relevant information already populated and pass along details that may not be recoverable from a finished mosaic, such as the sensor used to capture the imagery.

Beyond the new uploader, OAM has a new browser that shows imagery from more than one provider side by side and works to package imagery for offline field use. These improvements address both sides of the same challenge: contributing imagery needs to be manageable for providers, and accessing it needs to work in the conditions responders actually face, including limited connectivity.

None of this happened in isolation. HOT built the new uploader with contributions from UC Berkeley's Code for Good program, on top of a STAC-based backend architecture developed by Development Seed that helped establish the ingestion model.

From Open to Operational Imagery

Making imagery open is the foundation. Making it operational requires durable infrastructure that is consistently described, reliably hosted, technically accessible, discoverable across catalogs, and accompanied by clear licensing. STAC, COGs, consistent metadata, and a more resilient uploader help reduce that friction.

Providers don't all need to participate in the same way, but the goal is the same: create a repeatable pathway from imagery that exists to imagery that can be discovered and used for humanitarian mapping.

Interested in contributing imagery? The Contribute webpage walks through the different routes for getting imagery into OAM, what OAM checks before indexing a catalog, and how to register one. Organizations with questions or interested in discussing further can reach out at info@openaerialmap.org.

Looking for OAM imagery? Explore the OpenAerialMap catalog.

Interested in the OAM technical architecture? Explore the OAM project code and documentation on GitHub.

About the author