Inverted GRIB display

[did-g]

A workaround is to convert these gribs back to V2.

Only test on Linux but with ECMWF grib tools:
grib_set -s editionNumber=2 2017xxx.grb 2017xxx.grb2


And grib_tool are available on windows cf:
https://chocolatey.org/packages/grib-tools

It seems to be a full distribution system, but you may find it elsewhere at least it compiles on Windows.

AFAIK grib V2 produced is correctly read by O.

[Moo]

Originally Posted by did-g

Hi,

I'm not sure there's an OpenCPN version which displays 500 mB height if it's the only data available (O v4.0 didn't), it only uses them if there's at least wind (it's what you get with zygrib and O saildoc requests)

Missing rain is and obvious one line patch, tuple (center, model, grid) is unknown and data weren't multiplied by 3600 (aka rain/hour rather than rain/second).

Anyway I'm reluctant with this stuff.

Grib data are scientific data with all that means, ie if you don't use whatever encoder/decoder producer is using you have to be very, very careful, moreover it's unlikely EMCWF is today disseminating grib version 1 data masqueraded as NOAA so your vendor is adding another layer of 'beep'.

This issue is old in O code base, as a matter of fact it could be in from day one. O grib v1 decoder roots are in ZyGrib code and ZyGrib 8.0.1 I have can't read your file even if it has some code for dealing with:
I'm not sure these files are actually malformed and it's not a ZyGrib bug (my gut feeling is it's a zygrib bug).

But here we are reaching O development limits, until now O could do without a proper test suite, test suite is time consuming, it's a grueling job and writing a useful one is hard, very hard. But without guarantees provided by a good test suite this change could introduce nasty regressions.

Thanks for your efforts.

I think the ZyGrib test for malformed MaxSea data is an old one something to do with d-lat d-lon needing to be inverted. I don't know the details but that was back in the old MaxSea v10 days and before.

Nobeltec TZ WX data is supposed to be ECMWF data I think (it is definitely not GFS). Doesn't worry me too much as generally I use Saildocs via Sailmail to get my Wx data but as I can get the TZ data via email too I occasionally get it to do a basic ensemble analysis especially when looking out past 48 hours or so.

It's no big deal for me because I can read the GFS data from Saildocs in TZ too. It just so happens that this time around I decided to give it a try in OCPN and discovered the anomaly and wanted to bring it to your (the developers attention).

Thanks for looking at it so quickly.!