ECC-2336: Fix ijDirectionIncrementGiven values in grib_util_set_spec

[tweska]

Setting: SET_LONG_VALUE("ijDirectionIncrementGiven", 0); is not allowed since value 0 is ambiguous.

In some cases Di is given, but not Dj. This should be reflected by the flags.

[sawom666]

Note that in GRIB edition 1 there is only one boolean called ijDirectionIncrementGiven. In GRIB2 they fixed this and created two separate booleans
iDirectionIncrementGiven
jDirectionIncrementGiven

Setting ijDirectionIncrementGiven=0 for GRIB2 sets both the above to 0
This can be seen if you enable the debug output:

% ECCODES_DEBUG=-1 grib_set -s ijDirectionIncrementGiven=0 samples/GRIB2.tmpl x
ECCODES DEBUG about to set key/value pair: ijDirectionIncrementGiven=0 (type=long)
ECCODES DEBUG grib_set_long h=0x8a1028000 ijDirectionIncrementGiven=0
ECCODES DEBUG about to set key/value pair: iDirectionIncrementGiven=0 (type=long)
ECCODES DEBUG about to set key/value pair: jDirectionIncrementGiven=0 (type=long)
ECCODES DEBUG grib_set_long h=0x8a1028000 iDirectionIncrementGiven=0
ECCODES DEBUG Setting bit 3 in resolutionAndComponentFlags to 0
ECCODES DEBUG grib_set_long h=0x8a1028000 jDirectionIncrementGiven=0
ECCODES DEBUG Setting bit 4 in resolutionAndComponentFlags to 0

But I agree it is better to be explicit and set the keys individually in grib-util-set-spec
:)

[tweska]

Hi @sawom666, I also observed this behavior but @joobog pointed out to me that setting it to zero is ambiguous since it can have 3 meanings:

17 concept ijDirectionIncrementGiven {
18   '1' = {
19     iDirectionIncrementGiven = 1;
20     jDirectionIncrementGiven = 1;
21   }
22   '0' = {
23     iDirectionIncrementGiven = 1;
24     jDirectionIncrementGiven = 0;
25   }
26   '0' = {
27     iDirectionIncrementGiven = 0;
28     jDirectionIncrementGiven = 1;
29   }
30   '0' = {
31     iDirectionIncrementGiven = 0;
32     jDirectionIncrementGiven = 0;
33   }
34 }

[joobog]

Some GRIB samples in the repository appear invalid, as the new tests show. It looks like a minor issue and should be easy to fix, but the impact of changing them is difficult to predict.

[pmaciel]

I only have that comment, to avoid edition-dependant logic

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.99%. Comparing base (ca08942) to head (18146f9).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #559      +/-   ##
===========================================
- Coverage    88.14%   87.99%   -0.15%     
===========================================
  Files          855      855              
  Lines        63643    63666      +23     
  Branches     11306    11315       +9     
===========================================
- Hits         56095    56021      -74     
- Misses        7548     7645      +97     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sawom666]

No need to check the edition here; HEALPix doesn't exist in GRIB1
Also when GRIB3 comes along, it is very likely that it will also have HEALPix.
So just check the gridType string and not the edition