Support Image feature type in NCSS

[lesserwhirls]

The GOES-R test products (ABI L1b Sample Continuous Full Disk - mode 4 - Data) have cdm_data_type = Image, which NCSS currently does not understand. Note that this is the case for both the CONUS and Full Disk datasets. While these data appear to be gridded, NCSS does not work with them even if NcML is used to change cdm_data_type to Grid. By "not work", I mean that a successful subset request, which has to be made by hand, as the form does not provide times for temporal subsetting, returns a netCDF file containing only metadata with no data for the request variables

NCSS will likely need to be extended to handle this case. This may also involve working at the netCDF-Java level to make sure the needed methods are available to NCSS.

[ethanrd]

@lesserwhirls As far as I know, there is no implementation of an "Image" FeatureType. In the FeatureType enum "IMAGE" is marked experimental. There have been many conversations about what an "Image" feature type might look like, how it would be different than a grid. But not much beyond that.

Also, the "cdm_data_type" attribute was introduced by ACDD but was dropped in version 1.1. (Version 1.0 was developed here in Unidata, all other version were developed by the ESIP Documentation cluster (formerly known as the ESIP CF cluster). So, I think we should be discouraging the use of the "cdm_data_type" attribute whenever possible.

[lesserwhirls]

Good info to have! I thought cdm_data_type was introduced as part of the netCDF-Java stack, much like the "underscore" conventions, but as a precursor to FeatureType. GOES-R is using cdm_feature_type in their products - who should we contact about possibly removing it (and why they should)?

[vsavovski]

I don't know is this going to be much of a help, so I apologize in advance. Eventually, I succeeded in subsetting the files using NetCDF-Java library and specifying custom requested bounding box, but success was only partial.

double startLat = 25.00;
double startLon = -100.00;

double deltaLat = 50.00 - startLat;
double deltaLon = -70.00 - startLon;

LatLonPoint llpt = new LatLonPointImpl(startLat, startLon);
LatLonRect requestedBB = new LatLonRect(llpt, deltaLat, deltaLon);

NetcdfFileWriter writer = NetcdfFileWriter.createNew(NetcdfFileWriter.Version.netcdf4, resultFIle.getPath(), null);
CFGridWriter2.writeFile(gds, null, requestedBB, null, 1, null, null, 1, true, writer);

Then I realized that I can't get bounding box from original NOAA file.

gds.getBoundingBox(); --> ll: NaNS NaNW+ ur: NaNS NaNW

Getting deeper into the code and debugging NetCDF-Java library, although the file format is recognized and all the variables and data structures are read correctly, problem starts when it tries to calculate the defaultMapArea, because both values for projection x-coordinate and projection y-coordinate are the same (x=10848, y=10848, unit is rad).

[lesserwhirls]

Related to Unidata/thredds#766 - given the issues cropping up with the coordinate systems, my guess is that things will start working once the CoordSysBuilder issue is fixed.