[TASK] Model upstream data sources as STAC providers

Type

Task

Scope

Multi-theme or Platform

Skillset

engineering

Description

What

Collections now declare Overture Maps Foundation as a provider with the licensor,
processor, and host roles (#122). They deliberately do not declare a producer.
Decide how to represent the upstream sources that actually produced the data, and add them.

Terminology, since the STAC naming is confusing

providers is a field: a list of organizations involved with the data. Each entry
carries a roles array. producer is one of the four role values an entry can hold —
not a separate field, and not a competing concept.

"providers": [
  {
    "name": "Overture Maps Foundation",
    "roles": ["licensor", "processor", "host"]
  }
]

The four roles STAC defines:

Role	Means
producer	originally captured the data
processor	derived a product from someone else's data
licensor	licenses it under the stated terms
host	serves the bytes

One organization can hold several roles, as OMF does above. Several organizations can also
appear as separate entries holding different roles — which is what this issue proposes.

So the question is not "providers or producers". OMF is unambiguously a provider. The
question is whether producer is one of its roles, and the answer is no: it did not
capture this data.

An analogy: for an anthology of short stories, the publisher, printer, and editor are all
providers of the book, but author is a specific role the publisher does not get to
claim just because it assembled the volume. OMF is the editor and publisher here. The
upstream sources are the authors.

Why

STAC defines producer as the party that initially captured and processed the source
data — the spec's own example is ESA for Sentinel-2. For Overture that is the upstream
sources: OpenStreetMap contributors, Esri Community Maps, Google Open Buildings, Microsoft
ML Building Footprints, and others depending on theme. It is not the foundation, which
assembles and conflates what those parties captured.

Naming OMF as producer would have been the easy way to satisfy validators that expect
one, but it would credit OMF for capture work it did not do, and it would leave the
catalog silent about the organizations whose data it actually redistributes. That seemed
worth getting right rather than getting quickly.

So the field is currently absent rather than wrong. This issue is about making it present
and correct.

Why it needs a decision rather than a patch

The source mix differs per theme. Buildings draws on Google Open Buildings and
Microsoft ML Building Footprints; places does not. A single hardcoded provider list cannot
express that, so this needs a per-theme (possibly per-type) mapping that somebody at
Overture verifies.

The precise answer already exists at row level. The sources column records
dataset, record_id, license, and update_time per feature. The question is how to
summarize that faithfully at collection level — and whether a collection-level summary can
be accurate when the source mix varies across the rows within it.

Attribution has legal weight. Several upstream licenses carry attribution
requirements. Listing providers is partly a licensing statement, not just metadata, so it
warrants review by whoever owns attribution rather than an engineering judgement call.

Questions to settle

• Does a collection-level provider list credit sources accurately, given that the mix
  varies row to row? Or is sources the only honest place for it?
• Per-theme or per-type granularity?
• Which sources are named — every contributing dataset, or those above some threshold?
• Does the existing attribution page
  already define the canonical list to mirror here?
• Should OMF also carry producer for themes where it genuinely produces rather than
  conflates, if any?

Related

• #122 — added the OMF provider entry and deliberately left out producer
• #119 — the Rust port declares no providers at all; whichever implementation this lands
  in, the other needs it too