Forum

The products were reprocessed with the latest chlor_a algorithm, so changes of that scale would not be unexpected.

Tommy

The CHL files were reprocessed in 2022.

Details of the file name changes:
https://oceancolor.gsfc.nasa.gov/resources/docs/filenaming-convention/

Can you be more specific about the value changes you are seeing?

Tommy

If a fuzzy match on filenames doesn't work for you, you could download the L2 file first, and read the "ifile:" from the L2 metadata to ascertain the parent.
e.g.:
:ifile = "PACE_OCI.20250207T001005.L1B.V3.nc" ;
:ofile = "PACE_OCI.20250207T001009.L2.CLD.V3_0.nc" ;

Tommy

The L1B have the scheduled time of the granule in the name. The L2 names reflect the actual start time of usable data, which may differ from the scheduled time of the granule.

Tommy

The Ocean Color archive has migrated to the NASA Cloud so some search terms have changed provider is now "OB_CLOUD" instrument=SeaWiFS short_name like "SeaWiFS_ L1 file names like: SEASTAR_SEAWIFS_GAC.19980504T123211.L1A.nc wget "cmr.earthdata.nasa.gov/search/granules.csv?page_si...

No, the MODIS and VIIRS SST that we produce are not moving to the Cloud archive - they will continue to be archived locally and those collections will not change.

The R2022.0 collection is the original CMR collection that points to the OB_DAAC servers at GSFC, and the 2022.0 is the new Earthdata Cloud hosted OB_CLOUD collection that points to AWS. The R2022.0 CMR collections will be deprecated shortly, so you should point your code development at the Cloud ve...

The L2 granules are each "regional". They combine to give global coverage.

Tommy

The time period you are referencing should have refined CHL data, not NRT. Remove NRT from your datatype and retry your query.

Tommy

Yes, when we adopted the new 2020 naming convention, we renamed the existing L1A.
They are the same files.

Tommy