New Grib Presentation

[rgleason]

Pavel and Gerard I do hope you will see the humor in this, it really is quite funny, and I do hope you both will continue to spar in non destructive ways so that we learn and move forward.

I still did not get an answer about how wx - rte gets grib data - through opencpn? I thought that might help, but I do look forward to testing a new version that works for wx - Rte and regular grib use!

Let's keep it simple, should I test it again? What I do is git the current beta. Is that the way you want me do do it? Previous git did not seem to fix it.

Thanks Jean Pierre. Pavel I do hope you'll keep us on track. Gerard you seem to be able to create instantaneous response by Pavel. I might suggest using this ability rather less than more, as it may improve your friendship foster a greater community. Thanks to all, including Gerhart, for the suggestions interest and concern. It is a strong community.



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

[rgleason]

Sean I will post a moving grib on opencpn beta file thing. It will be in the same dir as above. Give me a minute.

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

[rgleason]

Here it is, a moving or walking grib. Only 14kb, but take off the doc please. Sean and Jean Pierre thanks for helping with this, it is much appreciated.

[rgleason]

Jean Pierre, I just tried a new git fetch and nothing, up to date. Then tried git pull also nothing up to date. So then I went in and checked Opencpn Debug version, it was 3.3.1710 that I downloaded and tested above (I used the opencpn 3.3.1618.exe, but updated the grib_pi.dll (which was from the morning's compile 3.3.1710).

Sorry for any confusion, the testing I did above was with the new grib_pi compiled with my fresh git fetch and git pull this morning (3.3.1710).. That is to confirm that that change does NOT make the fix intended.

[rgleason]

Jean Pierre
I can confirm that using a release version of the grib_pi (3.3.1710) compiled this morning with the above walking or moving grib results in:
1. A warning that it will not be interpolated.
2. Showing the first frame, but not showing the majority of the frames.
3.Use with the current Weather_Routing_pi results in "Grib Failed" message, so it does not work.

Hope that helps. If I use an earlier grib plugin (from Opencpn v 3.3.1418) it does work, and it has fewer data types (basically only 4 data types). Has some data type descriptor or table not been extended for the new data types? Sean would probably know more about this subject too.

[Ptizef]

Originally Posted by boat_alexandra

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.



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 eitheHir way the end result is the same. Could you give a counter example? Maybe post a moving grib I can try?

Hi Sean
I have always do my best for the plugin. So I will keep me apart from the controversy about
the responsabilities to concentrate on solving the problem.
Sorry, I have no connection for a few days except my small phone so I can't enter into details.About the patch: don't forget if you use a moving grib or if there is a change in resolution, i and im1 will have data with different position. The result is of course wtrong. The patch prevent to interpolape when it is not necessary. Test with a moving grib file and you will see
But are you sure it's the probleme? Rick's last test would say no
I am sure the best is to colaborate and every body knows what are the need of the other
plugin

Jean pierre

[Ptizef]

Sean
If curtime = time you are sure to be on a record boundary
so you are sure that no interpolation is needed.
Puting im1=i will ensure the interpolation will not create
any problem
I don't see how this could destroy wr computation but you are the only
one who knows
Jean Pierre

[seandepagnier]

Originally Posted by Ptizef

Sean
If curtime = time you are sure to be on a record boundary
so you are sure that no interpolation is needed.
Puting im1=i will ensure the interpolation will not create
any problem
I don't see how this could destroy wr computation but you are the only
one who knows
Jean Pierre

I agree, I think this solution works for now. Weather routing works for non-moving gribs in this way, and moving gribs without interpolation also work.

I think maybe we uncovered a new bug where using interpolation with a moving grib the result is (and never was) correct, so this quick fix is maybe not the best one.

[rgleason]

the Ptizef github shows

Suppress useless test to ensure correct compatibility with weather ro…uting plugin
https://github.com/Ptizef/OpenCPN/co...5dd0924a89adb6

plugins/grib_pi/src/GribUIDialog.cpp
@@ -1030,8 +1030,6 @@ GribTimelineRecordSet*
GRIBUIDialog::GetTimeLineRecordSet(wxDateTime time)
if(i == 0)                                                                               im1 = 0;
-    if(!m_InterpolateMode) im1 = i;
- 
wxDateTime mintime = MinTime();
double minute2 = (curtime - mintime).GetMinutes();
curtime = rsa->Item(im1).m_Reference_Time;

Isn't this the one I tested v3.3.1710? I don't believe this works, ...so what should change?

[rgleason]

Just git pulled and compiled 3.3.1712 and ran the grib_pi from that. I first tried it on the moving grib and exactly two frames are shown, the rest are not. This is not working properly....I believe.

- I think I'm going to stick with grib_pi 3.3.1418 for now, wish it would work.

[rgleason]

Here are two similar gribs, one is a walking grib and the other is not. The request was for a 3 hour interval at first and then I believe it was 6 hours after several days. (Edit Later: I believe these are only 3hr intervals now! But the new grib is not showing the 3 hr intervals!!)
The dropdown for both gribs shows only 3 hour increments, before I thought it would show the actual intervals requested, without interpolation (am I inccorrect?)
--Note I am just working with grib_pi right now, not using wx-rte.

GFS20140430180105184.grb.doc
GFS20140430170904875.grb.doc

both files exceed 400kb so you'll have to go to Opencpn Beta File Thing
rguser rgpass

Look under
Home /3.3.1712 Plugins-Win-Opencpn

[rgleason]

From Post #351 this thread:
http://www.cruisersforum.com/forums/...ml#post1527685

(I note that there is an incorrect blank in the quotes that results in a shorter grib request, it should read 168 at the end)

GFS:42N,38N,070W,076W|0.5,0.5|6,9..18,24..72,84..168|WIND|4.5,079

This is a 3 tiered time interval request with a moving/walking grib at 4.5 knots bearing 079 degrees. The intervals are
3 hours for 18 hours
6 hours up to 72 hours
12 hours up to 168 hours (or a total of 7 days)
It results in very small grib files. This one is

The resultant grib is below, take of the doc.

[rgleason]

In testing grib_pi version 3.3.1712 I used the following gribs:

Saildocs Request:query@saildocs.com

GFS:42N,35N,070W,077W|0.5,0.5|6,9..168|
Simple 3 hr grib interval.

GFS:42N,35N,070W,077W|0.5,0.5|6,9..168|WIND,PRESS| 4.5,079|
Simple 3 hr interval with moving grib.

GFS:42N,35N,070W,077W|0.5,0.5|6,9..18,24..72,84..1 68|
for 3, 6, 12 hr grib

GFS:42N,35N,070W,077W|0.5,0.5|6,9..18,24..72,84..1 68|WIND,PRESS|4.5,079|
for 3, 6, 12 hr moving grib (note |WIND,PRESS| is required for moving grib.

They are attached below, named appropriately. For weather_routing started at Norfolk, VA and end at Newport,RI. I used the ForMatt.XML and ForMatt.csv files above. (I note that ForMatt.csv does not seem to save out properly, because when I bring it in, it fails with no polars, so something isn't working here I think. Anyway I resorted to "Compute" which does create polars for the set boat parameters.

I have not had much luck computing a route using the compiled "release" version of grib_pi from 3.3.1712 using the compiled "release" of opencpn.exe 3.3.1712 it always shows "grib failure".

[rgleason]

With the simplest Grib file from above
GFS20140513161004424-3hr.grb.doc (59.8 KB, 0 views)
Saildocs Request:query@saildocs.com
GFS:42N,35N,070W,077W|0.5,0.5|6,9..168|
Simple 3 hr grib interval.

Using the weather_routing_p from about v3.3.1618 and grib_pi from v3.3.1418
and setting up four different routings in wx-rte with 3hr, 4hr, 6hr and 12 hr intervals with same boat specs & polars, and start and finish.

The 4 hr routing did not work and failed, but the others did complete.

[rgleason]

Then I tried
GFS20140513161204438-3hr-moviing.grb.doc (58.6 KB, 0 views)

using the same
weather_routing_p from about v3.3.1618 and grib_pi from v3.3.1418
and setting up four different routings in wx-rte with 3hr, 4hr, 6hr and 12 hr intervals with same boat specs & polars, and start and finish.

I reset the computations, and picked compute all. The result was opencpn crashdump and I sent two reports. Then I tried it one calc at a time. Same crash dump.

Note that this is while using the older version of grib_pi from v3.3.1418 with MOVING gribs. So something is not working here with interpolation I think.

Also it seems to wipe out my weatherrouting xml file so I no longer have the route and 4 settings for 12hr, 6hr, 4hr and 3hr intervals.