Forum

Hi, I found in SeaDAS OCSSW sources that in the share/viirs/l2bin_defaults_PIC.par file the flaguse parameter does not contain the ATMWARN flag, is this normal? because it is present for modis and seawifs and also enabled on https://oceancolor.gsfc.nasa.gov/atbd/ocl2flags/ "L3 Mask Default"...

On my side I still get the 404 error.

Hi, We observe the same pb, and we suspect that the API now returns an error if none product is found by the search, example: this one fails because VIIRSN was down on this specific day and there is no products: wget --no-check-certificate --post-data="sensor=viirs&sdate=2022-08-01&edat...

Thanks Tommy this is clear now.

Hi, Sorry to bother you again about products start time, but I found these cases which seem suspect to me: AQUA_MODIS.20220606T1855 03 .L2.OC.nc which is ~3 seconds after its time_coverage_start = "2022-06-06T18:55: 00 .545Z" and also the corresponding NRT products was AQUA_MODIS.20220606T...

Hi,

For information I found in your archive one suspect file which does not follow the new file naming convention (it ends with *.SNPP_OC.NRT.nc):
https://oceandata.sci.gsfc.nasa.gov/ob/getfile/SNPP_VIIRS.20220928T223000.L2.SNPP_OC.NRT.nc

Best,
Julien

Hi, Is there another HTTP backup/redundant server for https://oceandata.sci.gsfc.nasa.gov which could be used in case of server failure or temporary IP blacklisting? Sorry for the question but we are exploring possibilities to improve our robustness in case of issue, so if a redundant server exists ...

Hi,

It seems that the full MODIS-Aqua archive has just been reprocessed again at the beginning of September?
What are the changes compared to the previous MODIS-Aqua R2022 release?

Thanks,
Julien

Hi, Since 3 weeks we successfully got back to search requests by 30-days periods, but the same problem came back since 01 September 4:00pm UTC, the searchs timeout after 5 minutes and you can see on the log of this morning below that some requests are successful but are very long, more than 3-4 minu...

Hi, We found that with R2022 the granule start time in the new filenaming convention is not consistent with R2018: with R2018 seconds were always set to 00, but with R2022 there is a mix of 00 and 01, is it normal? Example: R2018: A2003001004500.L2_LAC_OC.nc A2003001005000.L2_LAC_OC.nc A200300100550...