OB_CLOUD STAC API is missing CORS Headers

[tisham_csiro]

Hi All,

I have just discovered the OB_CLOUD STAC API - https://cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections/ and I am interrogating it to locate collections of interest for me, particularly VIIRS OC/IOP NRT and Definitive collections. However my preferred tool for trawling through STAC Catalogs - https://radiantearth.github.io/stac-browser/#/external/cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections/ is unable to read the STAC API due to missing CORS headers. Could this please be rectified at your end.

I would also like to know the time line for making VIIRS streams mentioned above via OB_CLOUD.

Cheers,

Tisham.

[OB.DAAC - itcarroll]

Hi Tishim,

I am only able to reproduce the CORS warning in the Radiant Earth browser when using the "Up" button to navigate. Is that what you are experiencing? Otherwise, I can browse through the OB_CLOUD collection without errors.

For instance, this link does not give me any error:
https://radiantearth.github.io/stac-browser/#/external/cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections/VIIRSJ1_L2_IOP_NRT_2022.0

The "Up" arrow on that page points to this data URL, which also does not give me any error:
https://cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections

But clicking the "Up" button gives the CORS error. If that's what you are experiencing, it may be a problem on the Radiant Earth side. Let me know if you're seeing different behavior, and if so what browser and operating system.

Take care,
Ian

[tisham_csiro]

Yes, looks like the CORS header is missing at the root level of the STAC catalog. Could it please be added there. Looks like the radiantearth browser can run an internal proxy and inject the headers, so I can access it like this : https://radiantearth.github.io/stac-browser/#/external/cmr.earthdata.nasa.gov/stac/OB_CLOUD , just leaving this here in case it is useful to someone else.

Also the VIIRS collections are missing assets, is there plan to add them to OB_CLOUD in the future.

Regards,

Tisham.

[OB.DAAC - amscott]

Hello,

VIIRS data has just started being migrated to the cloud. Over the next few weeks you will see increasingly more VIIRS data available under the provider name OB_CLOUD.

A team has created a ticket for correcting the issue with the CORS headers.

[tisham_csiro]

Hi,

Thanks for the update. I can also see that the OB_CLOUD and OB_DAAC STAC endpoints are lagging quiet a bit behind the actual NRT data holdings here : https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-2/NOAA20-VIIRS/2025/22-May-2025/ . What sort of latency can I expect from these ? Is there a more upto date non-STAC endpoint I should be using to query the NRT data ?

Regards,

Tisham.

[OB.DAAC - amscott]

We are in the process of moving data to the cloud, so you should use OB_CLOUD for most of your data discovery needs. Only Level-1 for MODIS, VIIRS & OLCI, In situ and SST data will remain under the OB_DAAC data provider name.

[tisham_csiro]

Hi,

Thanks for the response, I am migrating and testing my code against the OB_CLOUD STAC API. The STAC Search function does not seem to be compatible with previous OB_DAAC implementation.

This query returns non-zero results count in OB_DAAC :

https://cmr.earthdata.nasa.gov/stac/OB_DAAC/search?limit=1&bbox=152.7%2C-28.072%2C153.92%2C-26.617&datetime=2024-01-01T00%3A00%3A00Z%2F2025-03-31T23%3A59%3A59Z&collections=VIIRSJ2_L2_IOP_NRT_R2022.0

A similar query returns zero results in OB_CLOUD (with slightly changed collection name):

https://cmr.earthdata.nasa.gov/stac/OB_CLOUD/search?limit=1&bbox=152.7%2C-28.072%2C153.92%2C-26.617&datetime=2024-01-01T00%3A00%3A00Z%2F2025-03-31T23%3A59%3A59Z&collections=VIIRSJ2_L2_IOP_NRT_2022.0

Are there plans to have a compliant STAC search implementation as part of the OB_CLOUD migration ? I can confirm that items queries work fine. I am interested in spatial filtering across collections hence the search query.

https://cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections/VIIRSJ2_L2_IOP_NRT_2022.0/items?datetime=2025-05-01T00%3A00%3A00.000Z%2F2025-05-22T00%3A00%3A00.000Z&bbox=152.7%2C-28.072%2C153.92%2C-26.617&limit=12

Regards,

Tisham.

[tisham_csiro]

Also checking on the update for JPSS2 - cmr.earthdata.nasa.gov/stac/OB_CLOUD/collections/VIIRSJ2_L2_IOP_2022.0?.language=en

When attempting to download other granules via S3 and the temporary credentials obtained , we get this error from S3 .

```
<Error>
<Code>AccessDenied</Code>
<Message>User: arn:aws:sts::211041762479:assumed-role/ob-cumulus-prod-thin-egress-app-DownloadRoleInRegion/tisham_csiro@1748842116 is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::ob-cumulus-prod-public/SNPP_VIIRS.20250501T030601.L2.OC.NRT.nc" because no identity-based policy allows the s3:GetObject action</Message>
<RequestId>HNP8FMASK0XZXCPS</RequestId>
<HostId>XdKvkcnmj2+/OSu3YGJsK2fbqjt+GzrWoW9ZqB06mkhzFk0DZUJzjj5Rp5cio0niPBc4LI1+uRbYuTE7oqcBWA==</HostId>
</Error>
```

Please confirm the S3 policies are configured correctly at your end for OB_CLOUD.

[tisham_csiro]

Upon further investigation it seems like this is affecting only workloads accessing OB_CLOUD from Oregon using S3 VPC endpoint for same region access. We have successfully downloaded content from the bucket using local network and from AWS Sydney. We could bypass VPC and fetch via public S3 endpoint, however, to minimize transfer costs we would much prefer to fetch via the same region endpoint.

The other option is using S3 transfer with s3credentials minted using something similar to this for POCLOUD : https://archive.podaac.earthdata.nasa.gov/s3credentials , not sure there is a similar in OBCLOUD.