Hi,
I am quite new to this software but have been told to download and open my files like this, so I can use the data from them, but an error message keeps coming up so I’m not sure what I am doing wrong. All I can find about this issue is .XML files not .nc . Any suggestions would be helpful, thanks!
You should mention the SNAP version. Your file is level-3 binned data from a very recent reprocessing. SNAP is built around grid data (e.g., matrices) but binned data (ESA and NASA both use binning, but the storage formats differ). I generate level-4 binned products from level-3 binned data and use NASA OCSSW command-line processing system on linux. OCSSW software also runs on Intel macOS. On Windows I use Python to read .L3b.MO.CHL, but I have not yet tried the new reprocessing as I have been using VIIRS SNPP data.
NASA has SeaDAS 8, which is based on SNAP but adds OCSSW support to the GUI.
You may find IOCCG Report 4 (2004). Guide to the creation and use of ocean-colour, Level-3, binned data products. Edited by David Antoine, pp. 88 useful.
This version of L3 binned data is not supported. There is a L3 Binned data reader provided by SeaDAS but it expects different metadata in the file.
@gnwiii do you if the format has changed recently?
I get the “no appropriate reader” message with NASA SeaDAS 8.2.0. The initial SeaDAS L3b reader did not match the OCSSW bin number calculation so it appears that the SeaDAS L3b reader has been abandoned.
NASA now supports higher resolutions which requires a long int for the bin numbers. ESA
binning numbers the bins at each latitude starting from 1 to N_lat. NASA numbering is 1 to sum(N_lat). I haven’t yet checked any new reprocessings to see if long int is used for lower
resolutions.
The way NASA assigns bin numbers is fragile, as it relies on converting the length (in bin width units) of a parallel at each latitude to the nearest integer. When the length is close to N+0.5, small differences in the calculation may give N or N+1 as the integerized number of bins. The calculation is sensitive to the earth’s figure and implementation of the calculation of the length of a parallel. Attempts to read NASA L3b data using pure Java or Matlab have difficulties getting the same assignment. With higher resolution the number of integerizations increases, so the chances of an off-by one difference increase. With NASA’s format, an off-by-one difference assigns different positions to all bin numbers starting with the latitude where the difference occurred.
For ocean colour data you can steal bin numbers stolen from a PAR climatology file because PAR can be calculated for ocean bins with cloud or sun glint, so other products are never found without PAR. The OBPG software includes l3bindump, which exports an ASCII file for a given ROI (rectangle or circle) or point.
It would not be hard to adapt NASA’s C++ code to produce global bin number lists that could be stored for use with other languages. Another numerical issue with NASA’s binning is the use of the sum and sum-of-squares to compute variances. For variables with unfortunate scaling this can produce nonsense, requiring rescaling and/or centering the values.
The SNAP and SeaDAS software does not currently support opening in the Product/File Manager a NASA level-3 bin file (which is the file you are having trouble opening). The NASA level-3 bin file is not a raster file, however there is a tool within the SeaDAS Toolbox (which can be installed in SNAP) called l3mapgen. This tool can convert the level-3 bin file into a raster mapped file in a variety of projections (including the raw bin mapping of the level-3 binned file. This resultant level-3 map file can be loaded directly into SNAP and SeaDAS.
Note in the file naming convention that within the name “L3b” signifies a level-3 bin file and “L3m” signifies a level-3 map file.
Thank you for the responses, it has helped me solve the issue
