Inverted GRIB display

[Moo]

FWIW the offending file displays correctly in Viewfax.

[Moo]

Originally Posted by hoolie

I know the physics! Three of your images show 40kn north north west wind off the NE coast of NZ NI. The ECM OCPN you're complaining about shows 10kn south easterly

Are you sure?

Take a look at the attached. What way should the wind be circulating at the yellow circle?

[hoolie]

Originally Posted by did-g

There's various way you can read grib grid data, left to right, right to left, top to bottom, bottom to to top and so on. If ECM files are using an order we've never seen before OCPN could be 'confused'.

I don't think it's a simple as that. There is no image inversion/mirroring. It's different data that's being imaged - for a start I'm suggesting OCPN takes the wrong date within the file.

If the OP can get the GRIB file to upload we can see whether the OCPN view is of an earlier or later time

[hoolie]

Originally Posted by Moo

Are you sure?

Take a look at the attached. What way should the wind be circulating at the yellow circle?

I agree that looks a bit dodgy, but have you compared the wind off NZ for the other three images you've posted? That one is completely different

[Moo]

Originally Posted by hoolie

I agree that looks a bit dodgy, but have you compared the wind off NZ for the other three images you've posted? That one is completely different

It is the first image I posted with the yellow circle added

[hoolie]

Originally Posted by Moo

It is the first image I posted with the yellow circle added

It is indeed.

Now shut your eyes and just imagine that mirrors don't exist. How do the two images you have from the two files in OCPN compare?

The wind barbs generally point the same way. The low pressure zone is moving south. The winds around NZ are changing as the LP zone approaches the coast.
The winds strengthen as the depression develops.

The first image is from 1-2 days before

[Moo]

Originally Posted by hoolie

It is indeed.

Now shut your eyes and just imagine that mirrors don't exist. How do the two images you have from the two files in OCPN compare?

The wind barbs generally point the same way. The low pressure zone is moving south. The winds around NZ are changing as the LP zone approaches the coast.
The winds strengthen as the depression develops.

The first image is from 1/2 days before

I can only assume that you are tolling me, or just plain stubborn

In any given hemisphere the direction of circulation is always the same around a low pressure system it does not reverse ever!! This system is not magically crossing the equator in to the northern hemisphere

Same time. The low is near the northern top of NZ and moving East and South. Think about the physics!

unfortunately the forum will not let me post the file with any file name.. PM me your email address and I'll send you the files as well.

[hoolie]

No I'm not trolling you. I'm not bothered about the rotation of LP systems north or south of the equator, I'm merely comparing the imagery of the GRIB files you, personally, have posted. Look at them.

Maybe I am stubborn but I don't think it helps to ignore ALL the possible explanations why there may be a possible defect with OCPN.

I admit, initially I was sceptical, but now I think there really is a problem with OCPN for gribs of this file type

[Moo]

Originally Posted by hoolie

No I'm not trolling you. I'm not bothered about the rotation of LP systems north or south of the equator, I'm merely comparing the imagery of the GRIB files you, personally, have posted. Look at them.

Maybe I am stubborn but I don't think it helps to ignore ALL the possible explanations why there may be a possible defect with OCPN.

OK cheers

[did-g]

Originally Posted by Moo

FWIW the offending file displays correctly in Viewfax.

What about this way:

What OS are you using? It's a one line patch but in need more testing.

[Moo]

Originally Posted by did-g

What about this way:

What OS are you using? It's a one line patch but in need more testing.

I'm using W10 here. Looks correct in your img. Can you build for windows and give me link to download? I don't have a build environment here sorry.

[hoolie]

Originally Posted by did-g

What about this way:

What OS are you using? It's a one line patch but in need more testing.

That looks about right on Windows 10 Pro for the current GRIB situation from what I can see

[did-g]

Originally Posted by Moo

I'm using W10 here. Looks correct in your img. Can you build for windows and give me link to download? I don't have a build environment here sorry.

I don't have a working window build environment, appveyor stuff 100% untested, I can't guarantee this installer or ocpn work at all:

https://ci.appveyor.com/api/buildjob....8.0_setup.exe

source is in https://github.com/did-g/OpenCPN/tree/gribv1_jneg

--- a/plugins/grib_pi/src/GribV1Record.cpp
+++ b/plugins/grib_pi/src/GribV1Record.cpp
@@ -570,6 +570,8 @@ bool GribV1Record::readGribSection4_BDS(ZUFILE* file) {
                 else {
                     ind = j*Ni+i;
                 }
+                // XXX FIXME
+                ind = j*Ni+i;
                 if (hasValue(i,j)) {
                     x = readPackedBits(buf, startbit, nbBitsInPack);
                     data[ind] = (refValue + x*scaleFactorEpow2)/decimalFactorD;

There's another issue with rain, shouldn't be always zero.

[Moo]

Originally Posted by did-g

I don't have a working window build environment, appveyor stuff 100% untested, I can't guarantee this installer or ocpn work at all:

https://ci.appveyor.com/api/buildjob....8.0_setup.exe

source is in https://github.com/did-g/OpenCPN/tree/gribv1_jneg

--- a/plugins/grib_pi/src/GribV1Record.cpp
+++ b/plugins/grib_pi/src/GribV1Record.cpp
@@ -570,6 +570,8 @@ bool GribV1Record::readGribSection4_BDS(ZUFILE* file) {
                 else {
                     ind = j*Ni+i;
                 }
+                // XXX FIXME
+                ind = j*Ni+i;
                 if (hasValue(i,j)) {
                     x = readPackedBits(buf, startbit, nbBitsInPack);
                     data[ind] = (refValue + x*scaleFactorEpow2)/decimalFactorD;

There's another issue with rain, shouldn't be always zero.

Yes that's got it. As you say it is not displaying rain, or 500mB height.

[did-g]

Originally Posted by Moo

Yes that's got it. As you say it is not displaying rain, or 500mB height.

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:

// Try to detect ambiguous header from bad grib file providers
// Malformed Maxsea grib file ?

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.