MERIS processing issue

Please enter here to ask a question about any NASA Science related topics!
Post Reply
bbbarnes
Posts: 23
Joined: Tue Feb 04, 2014 12:57 pm America/New_York

MERIS processing issue

by bbbarnes » Mon Feb 24, 2020 1:25 pm America/New_York

I've found a really large number of MERIS FRS granules for which data in the northern Gulf of Mexico appear to be missing, or for some reason L2GEN can't process correctly from L1B. An example: M2010113155108.

The first screenshot below is of the oceancolor website for this granule. The chlorophyll image looks right (i.e., similar in geographic extent to that on the maps on the right side, as well as the extent shown on the initial granule selector /search page). The RGB image, however, looks to show a different extent.

If I download the L1B and process to L2 (all default parameters in L2GEN), the output appears to be only part of the full granule (only 641 lines appearing to be the northernmost ones). The second screenshot is the chlor_a field in the SeaDAS GUI, with just the LAND l2flag applied (the Outer Banks are clearly recognizable to the right). If I squint, I can see that the RGB image on the ocean color site is just this region, stretched vertically.

So, it looks like both my local processing and that which created the RGB image on the ocean color site produce the same result, while whatever created the chlor_a image on the ocean color site has a different extent. Thoughts?


Tags:

OB.DAAC - SeanBailey
User Services
User Services
Posts: 1167
Joined: Wed Sep 18, 2019 6:15 pm America/New_York

MERIS processing issue

by OB.DAAC - SeanBailey » Tue Feb 25, 2020 12:13 pm America/New_York

Brian,

Some time ago ESA reprocessed MERIS Level 1B data.  When they did that, we pulled the data over.  To avoid a duplication of data in the spatial metadata used by the browser, we associated the reprocessed data with existing records. Unfortunately, the reprocessing resulted quite a number of these files having file times (included as an element in the filename) that were not the same as the files they replaced.  In addition, we received a number of duplicate data (or partial data duplicates).   The combination of these to factors resulted in a bit of confusion for the L1/2 browser.  Add to tat the fact that we have not (yet) processed these "new" Level 1B files to  Level 2. and a modification made to the browser to support the new filename convention (currently only implemented for SST data), the situation you identified is revealed in it's full glory :grin:

For the example file you show, the source L1 that best matches the existing L2 file is not the file identified by the browser:
MER_FRS_1PPEPA20100423_155042_000000282088_00455_42593_0765.N1  (white outlined scene below)

It's this one: 
MER_FRS_1PPEPA20100423_155109_000002052088_00455_42593_0766.N1 (red outlined scene below)

This will be resolved when we reprocess the MERIS data later this year.  Until then, you could use the file_search API to query for files that are close temporally to the L2 scene name to identify the appropriate L1 filename.

Sean

Post Reply