Improving stac-map for HOT OAM

[gadomski]

stac-map was inspired by a prototype frontend for the Humanitarian OpenStreetMap Team's (HOT) OpenAerialMap (OAM). If possible, we'd like to extend stac-map in a way that it could be used by the HOT OAM team.

Here's some ideas and thoughts, gathered from existing tickets and a synchronous discussion on 03 December, 2025:

• White-label support, including:
  • Predefined config at first load #136
  • Loading of additional map layers via config #137
  • Option to add very basic style customisation #138
• Display imagery and/or footprints from multiple collections, to compare overlap. Collection bounding boxes aren't enough, because sometimes the imagery might not be useful and we need to render (e.g. to inspect cloud cover).
• Filter by "presets" (maybe keywords for collections)
• Preset datetime filter (last week, last month, last year)
• Generate a TMS/WMTS link that can be plugged in to a GIS
• Download several assets (not just STAC metadata) from the interface (we can download singles now, but not many)
• Render lots of assets at once

[cgiovando]

Thanks for capturing those requirements we discussed! I'll try to expand a bit on the use case scenarios and offer some specific ideas on implementation:

• Since the beginning of HOT, reviewing, comparing, and accessing available satellite imagery has been a major challenge. While OAM addressed this in part, it hasn't allowed users to add external layers or multiple image sources. The goal would be to index multiple providers and display their imagery simultaneously. While footprints/bboxes are a good first step, the key requirement is visualizing multiple actual images at once, with the ability to filter, sort, and toggle these seamlessly.

• Once a user configures their view, we need to allow accessing the data in external tools. Assuming sources are mostly COGs, we use TiTiler on a VRT-like mechanism to dynamically generate TMS/WMTS links. The workflow would be: the user filters for specific providers, dates, or cloud cover, sorts the display order, toggles images on/off, and then receives a single dynamic tile service link for that specific composition.

• Indexing multiple STACs introduces metadata inconsistency, so we need a strategy for providers (or OAM managers) to map distinct attributes to a common reference schema. This schema would enable standard filtering and sorting across all the sources. The OIN metadata spec is a good candidate, though we should expand it to include satellite specifics (e.g. cloud cover %) and drone specifics (e.g. GCP correction).

• Finding imagery for disaster response many times follows the same pattern. A typical query is: "Show me imagery in this area, collected in the last week, with <20% cloud cover, and at least 50cm resolution." These common parameters should be available as one-click presets for rapid access, while still allowing advanced users to dig into more detailed filters.

Finally, to avoid UX regression from the current OAM Browser, we should ensure these features are also included in a similar way to how they are available now:

• Simple metadata display panel (no STAC technical lingo).
• Direct links to iD/JOSM/download.
• Visual footprints and previews from at least Z10.
• Permalinks for sharing specific images/views.
• (Search/Zoom via gazetteer).