allow vector read of NetCDF NASA ocean color L3Bin files

[mdsumner]

NASA's ocean color L3bin files are now stored as compound types within grouped NetCDF4 files. An example (obtained below and attached) contains group "level-3_binned_data" with two compound types "binListType" and "binDataType" that have matching dimension (2 in this small example), and another "binIndexDim" (dimension 2160 in this example).

Could the vector support in GDAL add a feature to limit to specific user-specified types? For example, I'd like to be able to limit interpretation of only "binListType" variables. Could it make sense that a compound type presents as a layer?

I see this as a non-geometric table and having the ability to read it with GDAL would be very helpful. There are geometric interpretations as well but I'd leave that for another ticket.

The current behaviour (GDAL 2.10) reports

ogrinfo S2008001.L3b_DAY_CHL.nc
Warning 1: The dataset has several variables that could be identified as vector fields, but not all share the same primary dimension. Consequently they will be ignored.
INFO: Open of `S2008001.L3b_DAY_CHL.nc'
      using driver `netCDF' successful.
Metadata:
  NC_GLOBAL#binning_scheme=Integerized Sinusoidal Grid

Relevant snippet of ncdump -h output:

group: level-3_binned_data {
  types:
    compound binListType {
      uint bin_num ;
      short nobs ;
      short nscenes ;
      float weights ;
      float time_rec ;
    }; // binListType
    compound binDataType {
      float sum ;
      float sum_squared ;
    }; // binDataType
    compound binIndexType {
      uint start_num ;
      uint begin ;
      uint extent ;
      uint max ;
    }; // binIndexType
  dimensions:
  	binListDim = UNLIMITED ; // (2 currently)
  	binDataDim = UNLIMITED ; // (2 currently)
  	binIndexDim = UNLIMITED ; // (2160 currently)
  variables:
  	binListType BinList(binListDim) ;
  	binDataType chlor_a(binDataDim) ;
  	binDataType chl_ocx(binDataDim) ;
  	binIndexType BinIndex(binIndexDim) ;
  } // group level-3_binned_data

Full ncdump -h output (attached).

## bash to obtain small example file and dump header
wget http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S2008001.L3b_DAY_CHL.nc
ncdump S2008001.L3b_DAY_CHL.nc -h > S2008001.L3b_DAY_CHL.nc_dump

Other example data are available from here, anything with "*L3b*.nc" in the name

​http://oceandata.sci.gsfc.nasa.gov/VIIRS/L3BIN

​http://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/L3BIN

[mdsumner]

ncdump of example L3bin file

[Even Rouault]

I don't think that restriction of what is recognized should be done in the driver (apart avoiding presenting 2D or more variables that are matrix/raster and handled by the raster side of the driver, or 1D variables that are "support" variables of raster varaibles). All what could be read should be presented as separate layers. The restriction is a later user action when displaying / converting / etc...

Here the "challenges" are handling netCDF 4 groups and compound types.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.