Forum

If you are running l1bgen_modisa directly, you'd need to populate the required environment variables and create the appropriate PCF file. It's quite tedious This is why there is a script called modis_L1B.

try: Sean

The geolocation product produced by the OBPG is used to support processing through the l2gen program. l2gen performs an internal terrain correction, so we disable terrain correction in the generation of the geolocation files. This is the reason for the differences you are seeing. For the ocean at me...

I can pretty much guarantee that ERRDAP does not support our binned format. It is a rather peculiar one, great for storing sparse data and combining with other similarly stored data, but not so much for ease of reading. If you want your data to be supported by an ERRDAP server, it will likely need t...

We have identified the root cause of this issue. On January 4th, a bug in our subscription manager was identified and corrected. This bug allowed expired subscriptions to have data staged for them if another, non-expired subscription would have those data staged (this only affected non-extracted sub...

Vardis, SNPP-VIIRS was in safehold from sometime mid-day the 26th of July through mid-day the 10th of August. No data was collected, so no directories created for those days. Some longer temporal data (e.g. 8D, R32, etc.) do exist, and directories for the first day those periods exist. For example, ...

I'll reiterate that it is not a bug in SeaDAS. The HDF file is incorrectly written. Even the HDF4 user guide states the assumption that the fillValue should be of the same type as the data set: "SDgetfillvalue reads the fill value which has been set for the data set specified by the parameter s...

To be clear, the code issue was not technically a bug, rather the _FillValue defined in the MOD11 product is not appropriate when using the netCDF API to read the file. A proper netCDF file requires the fill value to be the same data type as the data set. "NA" is not an unsigned short, so ...

Nothing jumps out, although you are binning at 1km, while our standard processing does so at 4km - so more values go into any given bin, thus minimizing the impact of a spuriously high (or low) value affecting the mean. If you have spurious values in the L3, they came from the L2. Since you have the...

It is not different (well, we've dropped the 'preliminary quicklook' and only have a 'quicklook' - NRT - now) and yes, the old naming convention did not distinguish NRT from refined. You can subscribe to refined data (when creating the subscription, there is an option "Wait for refined processi...

For Landsat8/OLI, yes: grep ^gain $OCDATAROOT/oli/l8/msl12_defaults.par gain=[1.0111,1.0101,1.0070,1.0098,1.00,1.00,1.00] The configuration for L9 was just copied from L8, so by default it has the same gains...probably shouldn't though. If you want the values "as is", when running l2gen, s...