CMR STAC: OB_CLOUD Sentinel-3 OLCI L2 EFR collections return ERR (Reduced Resolution) granules

[tisham_csiro]

**Summary**

When querying the OB_CLOUD STAC API for Sentinel-3A OLCI Level-2 **EFR** (Full Resolution, 300m) collections, the results include **ERR** (Reduced Resolution, 1.2km) granules. This appears to be a cataloguing issue in CMR where ERR products are incorrectly indexed under EFR collection IDs.

**Affected Collections**

- `OLCIS3A_L2_EFR_OC_NRT_2022.0` (Sentinel-3A OLCI L2 EFR Ocean Color NRT)
- `OLCIS3A_L2_EFR_IOP_NRT_2022.0` (Sentinel-3A OLCI L2 EFR Inherent Optical Properties NRT)

We have not yet checked the Sentinel-3B equivalents (`OLCIS3B_L2_EFR_*`) but they may be similarly affected.

**Reproducible Example**

The following Python script queries the `OLCIS3A_L2_EFR_OC_NRT_2022.0` collection over Australia for a 5-day window and identifies the misclassified ERR granules:

```python
import urllib.request
import json

url = "https://cmr.earthdata.nasa.gov/stac/OB_CLOUD/search"
payload = json.dumps({
"collections": ["OLCIS3A_L2_EFR_OC_NRT_2022.0"],
"bbox": [110, -45, 155, -10],
"datetime": "2026-03-20T00:00:00Z/2026-03-25T23:59:59Z",
"limit": 100,
}).encode()

req = urllib.request.Request(
url, data=payload, headers={"Content-Type": "application/json"}
)
with urllib.request.urlopen(req) as resp:
data = json.loads(resp.read())

print(f"Total results: {data['numberReturned']}\n")
for feature in data["features"]:
item_id = feature["id"]
bbox = feature.get("bbox", [])
lat_span = abs(bbox[3] - bbox[1]) if len(bbox) >= 4 else 0
label = "ERR ←" if "_ERR" in item_id else "EFR"
print(f" {label:6s} | lat_span={lat_span:6.1f}° | {item_id}")
```

**Output (2026-04-13)**

```
Total results: 15

EFR | lat_span= 30.2° | S3A_OLCI_EFRNT.20260320T004935.L2.OC.NRT.nc
EFR | lat_span= 30.2° | S3A_OLCI_EFRNT.20260321T004418.L2.OC.NRT.nc
EFR | lat_span= 30.2° | S3A_OLCI_EFRNT.20260321T005018.L2.OC.NRT.nc
...
ERR ← | lat_span= 156.6° | S3A_OLCI_OLCIS3B_L1_ERR.20260324T215317.L2.OC.NRT.nc
ERR ← | lat_span= 156.5° | S3A_OLCI_OLCIS3A_L1_ERR.20260325T001258.L2.OC.NRT.nc
ERR ← | lat_span= 156.5° | S3A_OLCI_OLCIS3A_L1_ERR.20260325T015356.L2.OC.NRT.nc
```

**Observations**

1. Approximately 20% of results from the EFR collection are actually ERR granules.
2. The ERR granules are identifiable by `_ERR` in their filenames (e.g., `OLCIS3A_L1_ERR` vs `EFRNT`).
3. ERR granules are full-orbit swaths with latitude spans of ~156° (pole-to-pole), whereas legitimate EFR granules cover regional extents of ~30°.
4. The ERR granules also have anomalous filenames referencing `OLCIS3B_L1_ERR` (Sentinel-3B L1) within a Sentinel-3A L2 EFR collection.

**Impact**

Downstream processing pipelines that query EFR collections and process all returned granules encounter out-of-memory failures when attempting to regrid the full-orbit ERR swaths at EFR resolution (300m / 0.0027°). The ERR granules require significantly more memory due to their much larger spatial extent.

We have implemented client-side filtering as a workaround, but it would be preferable for the CMR catalogue to correctly separate EFR and ERR products.

**Questions**

1. Is this a known cataloguing issue with the OB_CLOUD Sentinel-3 OLCI L2 NRT collections?
2. Are there plans to correct the collection assignments for these ERR granules?
3. Are the Sentinel-3B EFR collections (`OLCIS3B_L2_EFR_OC_NRT_2022.0`, `OLCIS3B_L2_EFR_IOP_NRT_2022.0`) similarly affected?

Thank you for your assistance.

[OB.DAAC-EDL - amscott]

Thank you for reporting this! I was able to confirm the same issue.

**Answers**
1) No it is not a known/expected issue
2) The information has been passed along to the data producer for correction
3) It does not appear that S3B collections are affected