I have an application, linked with the HDF4 libraries, which sometimes is
fed HDF and sometimes netCDF files.
After building it recently with HDF4.2r4 (we had been using e.g. 4.2r0 before),
it misbehaved when fed a netCDF file with a 3-D geographic grid and
lat/lon/altitude scale variables. The app calls SDdiminfo() for each dimension,
and was being given a non-useful response (datatype nt = NC_UNSPECIFIED (0))
even though the corresponding dimension existed and had an associated
set of double-precision (NC_DOUBLE) scale values.
The problem seems to be in mfhdf/libsrc/mfsd.c, in code like
(in SDIgetcoordvar and elsewhere):
3208 if((*dp)->assoc->count == 1)
3209 if( len == (*dp)->name->len
3210 && HDstrncmp(name->values, (*dp)->name->values, (size_t)len) == 0)
3211 /* only proceed if this variable is a coordinate var or when
3212 the status is unknown due to its being created prior to
3213 the fix of bugzilla 624 - BMR 05/14/2007 */
3214 if ((*dp)->var_type == IS_CRDVAR || (*dp)->var_type == UNKNOWN)
3215 {
...
But the useful LAT/LON/altitude coordinate vars, from this netCDF file,
had been tagged as var_type == IS_SDSVAR at this point,
so the above test skipped them, and no coordinate var was detected.
I don't understand exactly what this new IS_CRDVAR / UNKNOWN test is
supposed to do, but am guessing that it is needed for HDF files,
but isn't for netCDF files. Sound right?
It might be best to fix this at the point where the netcdf reader
is looking through the variables, and choosing the proper var_type there,
but I wasn't sure how. Instead, I added a convenience function to mfsd.c
to do what seems like the right test, based on the file type.
The resulting library does allow my application to read these netCDF files,
just as it could do with HDF4.2r0, so I'm submitting this patch (attached)
as a possible fix.
Stuart Levy in sunny(!) Champaign, IL
slevy@ncsa.uiuc.edu
mfsd.patch (2.7 KB)