New Grib Presentation

[Ptizef]

The patch above fixes the resolution change but I am
waiting to know if it fixes also the weather routing problem
Otherwise we will have to find another solution. (may be
my first proposal above)
Jean pierre

[rgleason]

Suppress useless test to ensure correct compatibility with weather routing plugin
https://github.com/Ptizef/OpenCPN/co...95058d22bL1034

I see this has also been merged with opencpn beta now. I'll git and test it. Many THANKS to Sean and Jean Pierre for their expert collaboration!

[Ptizef]

No The problem is not solved !
As is it the moving Grib and change in resolution inside a single file do not work any more!
That's why I ask to Sean if the patch above is OK for Weather Routing !!!
Jean Pierre

[CarCode]

I guess it is not a good idea at all when one plugin depends on another.
That is not the way plugins should work.

Gerhard

[AISEAG]

Originally Posted by CarCode

...not a good idea at all when one plugin depends on another.
.....

Gerhard

Hello,

I do agree with you Gerhard, Plugins should be independant from each other.

Serge

[nohal]

Guys...
The plugin interoperability is there by design and is plain good. What you propose will just bring code duplication, more problems and less progress. Taken to the extreme, we will end up with one single plugin doing absolutely everything. Do you really think that this would be better?

Pavel

[rgleason]

Using
grib_win32_pi_v22_ov331618_compiled-5-11-14_pi.dll.doc
weather_routing_win32_pi_v_ov331618_pi.dll
GFS20140506185705018.grb
Result: Grib Failure

Using
grib_win32_pi17_v220_ov331419_pi.dll
weather_routing_win32_pi_v_ov331618_pi.dll
GFS20140506185705018.grb
Result: Success Computed

With weather_routing > Boat > Edit I used ForMatt.xml and ForMatt.csv files.

These files can be found in Opencpn Beta File Thing, goto folder Test-Wx-Rte-Grib Opencpn Beta File Thing rguser rgpass

It would help if there were a sub version number on grib_pi. They are all version 2.2 or if the file name showed in Options > Plugins > Grib so we could select the correct version.

[rgleason]

So what are we to do? Just be left in dark ages using grib_pi 3.3.1418 with weather_routing? This would be ridiculous.

There is plugin dependency...interoperability...whatever. wx_rte depends on grib_pi and it should work! or should Sean or someone include a static grib_pi inside of wx_rte?? I think that would be a bloat too.

I am not technical enough to understand this, but there must be a sensible answer. It has to do with the database and records, and adding the new fields. Weather_routing needs access too those records and apparently the ability to interpolate! I ask again... Can Grib_pi sense if a User is calling or if Weather_Routing is calling?

[rgleason]

Also I ask Sean, What is wx routing checking to present "grib failure", are you preventing the grib from running arbitarily, because the newly compiled grib I believe is allowing interpolation....maybe the problem is something else like the additional records or data types.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[rgleason]

Is there some passive way to allow wx - Rte to interpolate?
How does wx - Rte get access to the grib data? -through opencpn? Therefore grib - pi would only know when a user poked a button... and use or access by wx - Rte through opencpn of a grib would be unfettered and permit interpolalation?

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[Ptizef]

please let's do not complicate things:
Originally, grib-pi interpolated always even if it was not necessary ( when "interpolation is not set or when using next and previous buttons).
Off course if it was not necessary, the interpolation had no effect.
But with the 'moving grib" files and with files with no constant resolution, this not needed interpolation is not accepted. So a test was added in the function to eliminate it)
Unfortunately, Sean said that this test destroyed the weather routing activity and proposed to eliminate it.
I did it, sorry without sufficient thinking, so the current Git (3.3.1710) should allow weather routing to work.
But the result is that moving gribs and no constant resulution grib no longer work.

Has any body tested weather routing with current Git ? It should confirm Sean's statement.

To fix the problem in both plugins I proposed another patch above.
Could Sean answer if it suits weather routing? in this case we can close the case

Or could someone post a weather routing.dll compiled on current Git I can test myself (sorry I have no time to search how to compile it )

Jean Pierre

[CarCode]

Jean Pierre,

once again I guess the majority wants to have a plugin or add-on and not a network of plugins which depends on each other.
Looking for the term plugin in wikipedia it is an extension for a host application only and nothing else.
So when a programmer is forced to alter his plugin because another plugin does not work anymore there is something wrong with the other plugin.
Hopefully others will encourage you to enhance the grib plugin further without looking left and right. The main application is still OpenCPN.

Gerhard

[nohal]

Gerhard...
The amount of FUD you spread all over the place due to something that needs a one line fix in a development, unreleased, version to reestablish the interoperability and make everybody happy is as usually remarkable...

Congratulations

Pavel

[CarCode]

Pavel
I can't remember to have you asked something...

Gerhard

[seandepagnier]

To clear things up about plugin dependencies: It is the responsibility of the grib plugin to provide grib data for other plugins to use. If the nature of the data changes, the other plugins will stop working. This change is not weather routing specific, it is just at this moment the only plugin which uses grib data. In the future there will likely be others.

Originally Posted by Ptizef

Unfortunatly !
It creates a regression for "moving gribs" and when there is a change in the resolution (for example in more than 8 days saildocs's files who can have 0.5°x0.5° then 2.5°x2.5°)
These files don't accept interpolation even on the record boundary
Sean : Could this patch be accepted by Weather routing ?

@@ -1030,6 +1030,8 @@ GribTimelineRecordSet* GRIBUIDialog::GetTimeLineRecordSet(wxDateTime time)
if(i == 0)
im1 = 0;

+ if(curtime == time) im1 = i;
+
wxDateTime mintime = MinTime();
double minute2 = (curtime - mintime).GetMinutes();
curtime = rsa->Item(im1).m_Reference_Time;


thanks
Jean Pierre

Jean,

I don't understand this patch. From what I can tell it has no effect, but maybe you can explain to me.

If curtime==time, then the value of im1 is irrelevant because nminute is always the same as minute2, and interp_const is always 1. In your case setting im1 = i, now interp_const will instead be 0 in all cases, but either way the end result is the same. Could you give a counter example? Maybe post a moving grib I can try?