John Caron

Hi Carl; The test is on a branch not yet checked in, but here is the code: ```` @Test public void testCoordinateVariables() throws IOException { String tstFile = TestDir.cdmLocalTestDataDir +...

There's a test file: core/src/test/data/dataset/SimpleGeos/huc_helper_test.nc ```` // global attributes: :Conventions = "CF-1.8"; :featureType = "timeSeries"; :cdm_data_type = "Station"; :standard_name_vocabulary = "CF-1.7"; :DODS.strlen = 12; // int :DODS.dimName = "name_strlen"; ````...

All deprecated in favor of ucar.array.StructureData in > 5. Which is also insufficiently documented. Your decision on documenting ver5, I know this will remain Unidata's version for the foreseeable future.

It appears that variables primary_cloud and secondary_cloud should be using typedef cloud_class_t instead of creating their own typedefs. Current CDM ncdump on ~netcdf-java/dap4/d4tests/src/test/data/resources/testfiles/test_atomic_types.nc: ```` netcdf c:/dev/github/netcdf-java/dap4/d4tests/src/test/data/resources/testfiles/test_atomic_types.nc { types: byte enum...

At the moment Im not seeing the error. The Data Object "primary_cloud" has a Datatype Message inside of it that duplicates cloud_class_t, complete with duplicated enumValue/enumName map . I dont...

Note ```` opaque(8) o_t ; o_t vo ; ```` which cdm doesnt reproduce: ```` opaque vo; ```` I think that was a conscious decision on my part to have opaque...

Do you have any insight into why the enum variables in test_atomic_types.nc duplicate the typedef ( including the value/name maps) inside of itself, instead of referencing a common datatype?

I see the same thing with ```` opaque(8) o_t ; o_t vo ; ```` That is, the variable vo has its own data type, and im not seeing the reference...

Added TestEnumTypedef disabled until we have a fix so Travis doesnt fail.

> Is it the case that the CDM objects lack the necessary data and metadata to compare with what the C library provides? CDM has the correct semantics, but it...