DAP2 unsigned int handling

[lesserwhirls]

OS: MacOS Tahoe 26.5.2
netCDF-C 4.10.1 via Homebrew (previous versions exhibit this behavior as well).

It appears as though the netCDF-C DAP2 code is trying to map DAP2 unsigned ints netCDF-C ints. An example dataset demonstrating the issue can be found on the Unidata TDS test server.

If we look as the at the DAP2 dds response:

$ curl https://thredds-test.unidata.ucar.edu/thredds/dodsC/dev/d4icomp/uint_crossover.nc.dds
Dataset {
    UInt32 uint_crossing_int_limit[index = 3];
} dev/d4icomp/uint_crossover.nc;

we can see the variable uint_crossing_int_limit is a DAP2 UInt32 variable. The expected values can be seen from the .ascii response of the DAP2 server:

$ curl https://thredds-test.unidata.ucar.edu/thredds/dodsC/dev/d4icomp/uint_crossover.nc.ascii\?uint_crossing_int_limit%5B0:1:2%5D
Dataset {
    UInt32 uint_crossing_int_limit[index = 3];
} dev/d4icomp/uint_crossover.nc;
---------------------------------------------
uint_crossing_int_limit[3]
2147483646, 2147483647, 2147483648

If we use ncdump on the DAP2 endpoint, we get the following:

$ ncdump https://thredds-test.unidata.ucar.edu/thredds/dodsC/dev/d4icomp/uint_crossover.nc
netcdf uint_crossover {
dimensions:
	index = 3 ;
variables:
	int uint_crossing_int_limit(index) ;
data:

 uint_crossing_int_limit = 2147483646, 2147483647, -2147483648 ;
}

Here we see that the uint_crossing_int_limit has been mapped to an int variable, and the last value is incorrect (without any indication that the data type has been changed).

Interestingly enough, the response looks correct when going through the DAP4 service:

$ ncdump dap4://thredds-test.unidata.ucar.edu/thredds/dap4/dev/d4icomp/uint_crossover.nc
netcdf uint_crossover {
dimensions:
	index = 3 ;
variables:
	uint uint_crossing_int_limit(index) ;
data:

 uint_crossing_int_limit = 2147483646, 2147483647, 2147483648 ;
}

The netCDF-C DAP2 docs state that:

The netCDF library DAP2 support code translate the DAP2 data model into the netCDF classic (netCDF-3) data model.

One question at this point could be "is it time to update the DAP2 mapping to use the Enhanced Data Model?". However, DAP2 support was added in netCDF-C v4.1, so there might be a good reason why it wasn't developed to do so out of the gate.

[WardF]

Approach 1: Add metadata (hidden attribute) for variables that were unsigned, indicating unsigned DAP2 values that cannot be represented natively in the netCDF-3 data model.