Extend eo:common_name vocabulary with center wavelength variants

[romulogoncalves]

Currently the EO extension defines eo:common_name as a fixed controlled vocabulary (e.g., rededge071, nir08, swir22). While this works well for Landsat and Sentinel-2 and some other well known missions, it is limiting for newer constellations and sensors with bands that don’t exactly match these predefined bins.

Motivation

The spec states:

Common band names should be uniquely assigned, i.e. there should never be two bands that share the same common name in an Item or Collection.

With the current fixed vocabulary:

• Sensors with multiple red-edge bands (at ~0.70, 0.71, 0.75, 0.78 µm, etc.) cannot all be expressed uniquely.
• NIR, SWIR, and LWIR bands on different sensors may be close to, but not exactly at the Landsat/Sentinel definitions, leading to ambiguity.
• Thermal bands (TIR), and in particular some longwave infrared (LWIR) bands, don’t yet have coverage in the current vocabulary.

This forces catalog creators either to leave out eo:common_name or to reuse an existing one incorrectly, reducing interoperability.

Proposal

Allow eo:common_name values to be extended with center wavelength identifiers, e.g.:

• rededge070, rededge071, rededge075, rededge078
• nir105 (1.05 µm)
• swir1650 (1.65 µm)
• lwir10900 (10.9 µm)

This keeps the spectral family (rededge, nir, swir, lwir) while ensuring unique and unambiguous assignment.

Example

"eo:bands": [
  {
    "name": "TIR01",
    "description": "Thermal infrared band",
    "eo:common_name": "lwir10900",
    "center_wavelength": 10.9,
    "full_width_half_max": 0.6
  }
]

Benefits

• Preserves backwards compatibility (existing names still valid).
• Ensures uniqueness across bands in a collection.
• Makes eo:common_name usable for new sensors without ambiguity.
• Improves filtering/discovery across diverse missions.

Question

Would the community be open to extending the eo:common_name vocabulary (or adopting a wavelength-based naming scheme) to improve support for sensors beyond Landsat/Sentinel?

[m-mohr]

This was discussed various times in the issue tracker, I think at this point the existing definitions are set in stone, but open for well-justified additions that are covered by multiple sensors.

[emmanuelmathot]

• New common band name mwir38 radiantearth/stac-spec#1054
• Add rededge1,2,3 to common names #19

@romulogoncalves I would recommend starting a document where we can list as many sensorss possible and their respective wavelengths to identify the common band names that could be added

[pmembari]

Hi, I have a small suggestion regarding the definition of the rededge075 band.

According to the STAC EO extension, the eo:center_wavelength is defined as the midpoint between the minimum and maximum wavelengths:

center_wavelength = (min_wavelength + max_wavelength) / 2

For the Sentinel-2 B06 band, the range is 0.73–0.76 µm, which gives:

center_wavelength = (0.73 + 0.76) / 2 = 0.745 µm

Following the naming pattern used in other red-edge bands (where the suffix reflects the center wavelength), it would be more consistent to use rededge074 instead of rededge075.This would make the naming convention uniform and directly aligned with the definition of eo:center_wavelength.

[malapert]

Hello,

I understand that the current vocabulary is considered stable and that additions require strong justification and coverage across multiple sensors. However, I would like to emphasize a practical limitation we are currently facing.

At the moment, we cannot properly use the EO extension for some datasets because of the limited number of predefined eo:common_name values. Many real-world sensors – especially hyperspectral instruments, rely on filter definitions that are not represented in the current controlled vocabulary.

For example, there are extensive and well-documented filter databases such as the SVO Filter Profile Service (FPS):
https://svo2.cab.inta-csic.es/theory/fps/index.php/

This database alone represents a very large number of filters across many instruments and spectral domains. It illustrates how diverse real filter definitions are compared to the relatively small enumerated list currently supported by eo:common_name.

Because of this constraint, data providers are forced to:

• Omit eo:common_name, reducing discoverability and interoperability.
• Reuse an approximate existing value, way I do not like at all for scientific reasons
• Avoid the EO extension entirely for certain sensors.

This limits the practical adoption of the extension outside of Landsat/Sentinel-like missions.

If extending the vocabulary with many new fixed entries is not desirable, I would like to suggest a few alternative approaches:

• Relax the strict enumeration constraint : Introduce a best practices document
• Allow a vendor- or mission-specific extension mechanism
• Another possibility would be to: Keep the current enum as-is. Allow additional names through a namespaced extension or via a secondary field (e.g. eo:common_name_ext), clearly marked as non-core but interoperable.

If extensibility is not possible within the current EO extension, what would be the recommended approach for data providers who need to describe additional, well-defined spectral bands?

Would the expectation be to:

• Propose additions case by case ?
• Or define a separate extension to support a more flexible naming scheme?

Ideally, it would be preferable to avoid fragmentation (e.g., creating a parallel eo_ext extension) and instead clarify how this use case should be handled within the existing framework.

Thanks

[m-mohr]

As eo:common_name is not required, you can use the EO extension as-is, without using eo:common_name for those bands where there are currently no suitable common names defined.

eo:common_name is only really interoperable if a common set of names exist. If we don't provide an enum, people provide whatever (even if suggested otherwise) because that's just how people are. That is not interoperable despite a common field name.. So the proposal is to create PRs for names that are actually common across multiple satellites. If they are not common, then obviously they don't apply for common names yet and you can simply use the name property in bands.

Can you clarify why you have to avoid the EO extension completely for some sensors? Is that for hyperspectral?