search

Unidata / thredds

THREDDS Data Server v4.6
https://www.unidata.ucar.edu/software/tds/v4.6/index.html
265 stars 179 forks source link

Grib GDS hashcodes not done correctly #308

Closed JohnLCaron closed 8 years ago

JohnLCaron commented 8 years ago

Tried to make GDS hashcode use fuzzy compare, but this is not possible to do correctly, and satisfy HashMap.

Examination of GRIB indexes shows no dependencies on the GDS hashcode. In gbx9 writing, only unique GDS are stored, based on CRC, not hashcodes.

However, the GDS hashcode is used in GribConfig in combining and renaming groups.

Underlying problem remains that there are sometimes slight miscodings that create spurious groups. Possible we should just use special compare for this, not hashCode.

Is GDS used in a hashmap?

JohnLCaron commented 8 years ago

All Grib1Gds have this problem.

All Grib2Gds have this problem.

JohnLCaron commented 8 years ago

The ncx files should maintain the seperate GDS. The Groups may be merged when they are "close enough". Related to #309.

JohnLCaron commented 8 years ago

Grib1Variable and Grib1CollectionBuilder are using gds.hashcode. Grib2Variable and Grib2CollectionBuilder are using gds.hashcode.

Used in GdsHashObject: "approximate equality with GribGds, but allow overriding".

eventually used in cdmHash to decide on variable identity. Looks messy should be cleaned up.

JohnLCaron commented 8 years ago

Im going to leave this for now, this is an internal issue not affecting the API, nor stored in the ncx or gbx.

Only real exposure is "the GDS hashcode is used in GribConfig in combining and renaming groups", and also would affect the variable groping through the cdmHash.

Seems to work, i might change equals and hashCode to approxEquals and approxHashCode for clarity, and to be sure these arent used naively in a HashMap.