Open pp-mo opened 8 years ago
Strategy ideas ...
We have a few grib1 files in the iris-test-data :
$ cd ...git/iris-test-data/test_data/GRIB
$ find . -iname "*.grib1"
./lambert/lambert.grib1
./rotated_uk/uk_wrongparam.grib1
./reduced/reduced_ll_missing.grib1
./reduced/reduced_ll.grib1
./shape_of_earth/global.grib1
./time_processed/time_bound.grib1
./gaussian/regular_gg.grib1
( N.B. all those contain only a single message )
We can inspect, from existing code, what types of data the existing grib load rules can support
we have some local test-case data + users to draw on ?
The GRIB1 load translation code (here) is still using
GribWrapper
s, which is the only thing preventing us throwing all the old loader code away, including the GribWrapper class.Technical Debt summary :
[ In fact this is still the bulk of code in
iris_grib.__init__.py
, though no longer publicly exported.CENTRE_TITLES
,TIME_RANGE_INDICATORS
,PROCESSING_TYPES
,TIME_CODES_EDITION1
andunknown_string
_longitude_is_cyclic
and_message_values
]There is still a slippery kludge that means when you load a GRIB1 message the 'field' argument in a callback becomes a GribWrapper instead of a GribMessage (here).
So, this is now the only thing that GribWrapper is still used for, and the only remaining occasion that a user might possibly be concerned about what a GribWrapper looks like.
We haven't addressed this yet because GRIB1 usage is very low.
We should rewrite the Grib1 loader to use the modern message object + throw away all the old GribWrapper-based processing.