Page 1 of 1

SeaWiFS L1a and L2 Filename Datetime Discrepancy

Posted: Wed May 10, 2023 11:22 am America/New_York
by bigelowtek

There appears to be a discrepancy in the datetimes listed in SeaWiFS L1a file names and SeaWiFS L2 file names on Direct Data Access, and between Direct Data Access and the Common Metadata Repository (CMR). I am trying to find the cause behind the discrepancy, or if there is a pattern to it, in order to be able to edit some satellite processing scripts accordingly.

Here is an example:
L2 url:

L1a url:

Specifically, refer to the timestamps: 165336 vs 165214.

I work with a field-satellite matchup workflow, that finds matchups within a given time window from the CMR. The workflow scans the repository for matchups and creates a list of matchup L2 urls. We then edit the extensions and convert the datetimes from YYYYMMDDThhmmss to YYYYDoYhhmmss, and use these L1a filenames to download L1a files from Direct Data Access.

The workflow is successful for aqua, terra, and viirs files. However, it is breaking on seawifs files. It appears as if the CMR L2 urls and timestamps match the Direct Data Access L2 urls and timestamps, but that the Direct Data Access L1a urls do not match due to a discrepancy in the timestamps between the L1a and L2 urls. (This discrepancy only occurs for seawifs files, not for aqua, modis, or viirs.)

Is there a reason for this discrepancy, or a pattern behind it?

Thank you.

Re: SeaWiFS L1a and L2 Filename Datetime Discrepancy

Posted: Mon May 15, 2023 1:23 pm America/New_York
by OB.DAAC - SeanBailey
The issue stems from how the filenames are defined, and for SeaWiFS this most impacts the MLAC data. MLAC are merged files with all of the HRPT (direct broadcast) and on board recorded LAC (local area coverage) data. When the MLAC files were developed, we needed a way to ensure we didn't have duplicate data as new HRPT data were made available. To accomplish this, we named the L1A MLAC files to match the start time of the corresponding GAC (global area coverage) filename for the orbit. With the R2022 reprocessing, the SeaWiFS L2 files follow the same logic used for source data, namely the time element is the time of the first valid scan line in the file. For MLAC, this means that just about every L2 file will not match the input L1A filename time element.

We plan to regenerate the L1A files to change the format from HDF4 to netCDF4, and at that time will apply the same file naming logic. ...but it will be a while before we do that...

If you desire the L1A files, you should be able to use CMR to do the spatial/temporal matching based on the L1A collection, instead of the L2 collection, so you wouldn't need to do a name translation.


Re: SeaWiFS L1a and L2 Filename Datetime Discrepancy

Posted: Tue May 16, 2023 10:15 am America/New_York
by bigelowtek
Hi Sean,

Thank you for your detailed answer. That makes sense. Unfortunately it means that the workflow I have been using will need to be re-written for seawifs matchups. I appreciate your suggestion to use CMR to find matchups based on the L1A collection. However, I am unsure of how to implement this.

I have been using a heavily edited version of (included in the OCSSW install). The edited script I have been using generates a matchup search url formatted like the following:,43.6425&instrument=SeaWiFS&platform=OrbView-2&short_name=SeaWiFS_L2_MLAC_oc&options[short_name][pattern]=true&temporal=2003-08-28T17:06:59Z,2003-08-28T23:06:59Z&sort_key=short_name

If a matchup is found, it outputs the download url:

Do you know how to edit the search url to scan for L1a matchups rather than L2 matchups? Or can you point me to a resource providing the info with which to construct a newly formatted search url?

Thank you.