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: https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-2/SeaWiFS/1998/260/SEASTAR_SEAWIFS_MLAC.19980917T165336.L2.OC.nc
L1a url: https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-1A/SeaWiFS/1998/260/S1998260165214.L1A_MLAC.bz2
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?
- User Services
- Posts: 1428
- Joined: Wed Sep 18, 2019 6:15 pm America/New_York
- Been thanked: 1 time
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.
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 find_matchup.py (included in the OCSSW install). The edited script I have been using generates a matchup search url formatted like the following:
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?