New Grib Presentation

[rgleason]

Thomas,
I agree that "Data Type" tabs would be clearer, showing only applicable settings, but wouldn't they get too long?
Air Temp, Wind, Current, etc

Also I'd really like to have a transparency slider, like the Climatology plugin.

[rgleason]

Stevead, can you enter your request in Tracker please under pi_grib project? With details?

Wondering if it is possible to support downloading of grib files from a web service from the plug-in?

This is not meant to be an endorsement of grib.us however they expose access to their services via a set of XML Web Services. From what I can tell they are simply slicing and dicing NOAA grib data

[Baikal]

Not enough points on the display table Beaufort.
Let's add a field with the mapping of the ball, and the wave height of the table Beaufort. It will be useful for those areas where there is no data on the wave. such as lakes and reservoirs of inland waterways.

[cagney]

With the inclusion of Ptizef's latest pull request in the Git code, I can see a major improvement in the "Grib Settings" dialog. It does look good.

One minor point. For "Wind" settings, isotach's are on by default, and the setting is missing in the dialog, so it's not possible to deactivate the lines.

Thomas

[rgleason]

Posted in the other Grib Enhancements thread
http://www.cruisersforum.com/forums/...ml#post1398731

TRACKER = pi_Grib Project
We would like bring this Project current. ....

[rgleason]

The grib plugin has come a very long way thanks to the efforts of Jean Pierre, Dave, Sean and others. I believe it has very flexible and appropriate controls for display, which we should keep, but there is always room for improvement. In fact, I had ignored this...

Jean Pierre wrote:

Numbers spacing refers in fact to 'minimum spacing'
That means when you zoom in , the spacing become equal to the grib data resolution.(for example 0.5° x 0.5 °) So the result of a change in spacing value is only visible when you zoom out and ovoid a cluttered screen and the "numbers" to be over-written (try with a low value to see that)
It would be possible to have a fixed spacing but that means interpolation and in this case, at the moment, I stumble over a big performance problem.
Jean Pierre

The "Range" for wind barbed arrows parameter in fact is not active and does nothing . The initial idea of this parameter is not relevant. It's why when you change the value, it return to 100.

In fact there are two parameters without any action:
- "Range" for wind barbed arrows we are speaking about
- "Size" for waves and current direction arrows for waves and current

What would be a useful parameter to replace these ?

I thought about "minimum spacing" , or "colors", or "size" ? but no one seems very useful except may be "minimum spacing" to ovoid cluttered screen with low zoomed view? Any idea ?

Interesting:
-Does the "Range" parameter function (is active) for all of the other data types? - Range is indeed reset to 100 under Wind. Maybe it should be greyed out and show 100? -Don't know if it is difficult to do this override.
-So are barbed arrows scaled automatically? It appears so.

Regarding- Direction Arrows "Size" for [data-type] waves and current.
-It appears that these arrows scale nicely with zooming in and out. What appears to have happened is there is now a scaling factor built into the "size" and the "size" number is no longer accessible. Perhaps we just call the parameter "Relative size" or "Scaled size" and expose it to the user again? -Or would that be too complex or confusing?

I have tried zooming in and in fact the spacing gets further apart because the grib spacing is reached and there is no interpolation between (this is with 1 degree gribs). In this case a "Minimum Spacing" parameter would not be useful. Would it be useful for .5 degree gribs, I don't think so, but I be interested what others think. When you zoom out a lot the arrows seem to drop off, but size is relatively larger. I would find it helpful if there was some additional interpolation for the zoomed in condition if possible to finer gribs as long as it does not get too dense. [Maybe a checkbox for that?]

I thought about "minimum spacing" , or "colors", or "size" ?

Minimum spacing - I haven't found a condition where this would be useful.
Colors - Would changing the arrow colors be useful? -Maybe if you had different data-types you wanted to display.
Size - I have suggested "relative size" or "scaled size" as a alternative to allow a user some control while keeping the arrows dynamically scaled. I don't know if users would want this kind of control or if it would be too complicated.
Adding interpolation when zoomed in past the grid size? - An idea that I had when testing.

Jean Pierre thankyou for the improvements... including the email selections etc. Any chance for direct downloads sometime, too?

Also would love to have ability to combine gribs as discussed elsewhere [also in tracker]

Thanks again.

See extended discussion about gribs here:
http://www.cruisersforum.com/forums/...ml#post1399293

[rgleason]

Two other thoughts I had about the grib_pi.
1. Sometimes I load a small grib file and I cannot "Find" it. I have to search all over the globe! Maybe there should be a "Locate" button that brings it centered? ..or maybe that should happen when we load it? Then we have to zoom in?
2. Also it would be helpful to have a grib area selector which allows picking the grib area (1. click two diagonal points. 2. Click polygon points-if supported 3. Request successive gribs of a certain size or area along a predetermined path) because my screen is not always the shape I need, and when using SSB grib size is critical.

[Ptizef]

Originally Posted by rgleason

Two other thoughts I had about the grib_pi.
1. Sometimes I load a small grib file and I cannot "Find" it. I have to search all over the globe! Maybe there should be a "Locate" button that brings it centered? ..or maybe that should happen when we load it? Then we have to zoom in?
2. Also it would be helpful to have a grib area selector which allows picking the grib area (1. click two diagonal points. 2. Click polygon points-if supported 3. Request successive gribs of a certain size or area along a predetermined path) because my screen is not always the shape I need, and when using SSB grib size is critical.

Hi rgleason
Good ideas
may be it could be entered in flyspray ?

Also a question : in flyspray there are several tasks with an answer in the current beta:
FS#1204,1087,187,1217,1201,986
Only the writer can say if he is satisfied but at least this tasks could have their status modified and noted "implemented in current beta" as it is done for main project tasks ?
thanks
Jean Pierre

[Gilletarom]

Hello Jean-Pierre, Hello all,

First, happy new year ....

Second, I tested version grib plugin that you provided me with a precompiled version of OCPN 3.3.1220.

1 I proposed an updated french language file plugin.

2 I observed that missing item in the English language file. Therefore, they are not translated in my translation.

These items not presents are:

"Grib data table", "Data at cursor position" Cloud " and" Air temperature. ". I see these items in the weather table.

And, also "Zoom to center." This item is on the button in grib window.

Best regards.

Gilletarom

[rgleason]

Great job Ptizef, it gets better and better. Really like the documentation too? Who took to time to do that so well? Learned even more. Thanks.
Grib Weather Plugin | Official OpenCPN Homepage

[rgleason]

GRIB requests - Moving or Stepped.
FS#1087 - Retrieval: Support Airmail's Stepped "Moving" Grib towards a destination, to reduce data transfer

In trying to check Tracker entries completed, I can across a problem I have not been able to resolve. Where have the directions for "Moving" or "Stepped" gribs gone in Sailmail? Have they been dropped by the server?

It used to be you would define a box with lat lon opposing corners, state the data-types and then define a direction and distance for the box to move
EG:

send GFS:42N,34N,030W,022W|0.5,0.5|0,6..144|PRMSL,WIND, SFCTMP,WAVES,RAIN|7.0,100,2013062110

This has to be in one line, just one blank after the "send"

What is the meaning: We start at a square between 42°N 34°N 030°W 022°W. The resolution is 0.5° and the data should be for every 6 hours for 6 days (so from 0 hours to 144 hours. Next section in the request shows the data we are interested in (wind, rain, etc. ...). Following this you see, that the original square (42N 34N 030W 022W) should be moved east (100°) at 7 knots, which means that the square moves every 6 hours by 42 nautical miles ESE.

These seem to have disappeared from the saildoc instructions. What happened?

Also Is there any other service that provides this type of reduced data stepped GRIB?

If this has been dropped there is no use in implementing it, but that would be too bad because its use would reduce data transmit size significantly.

[cagney]

Rick
GRIB requests - Moving or Stepped.

The request works. I don't know if this has ever been documented at Saildocs.

A line like

send GFS:42N,34N,030W,022W|0.5,0.5|0,6..144|PRMSL,WIND,SFCTMP,WAVES,RAIN|7.0,100,2014012618

returns a working grib, even though i get a separate mail with a warning that

There was an error in the following command line:
send
("" is not a valid command or document code).

The returned grib moves forward as expected as long as I manually click forward. When I try to run through "Play" no grib at all is shown in the new plugin.

PS. I doesn't work with a line-break at all, not even the "=" work around returns a "moving" grib.

Thomas

[rgleason]

Thomas thank you for checking. I get the same returns, and same grib, but I don't think it is "Stepped" or a box that moves in a certain direction as intended.

Can you confirm this?

[cagney]

Originally Posted by rgleason

Thomas thank you for checking. I get the same returns, and same grib, but I don't think it is "Stepped" or a box that moves in a certain direction as intended.

Can you confirm this?

I get a box that moves in 25 steps from the Azores to Gibraltar, as intended.
Box1

Box12

Box 25


Thomas

[rgleason]

Awesome.
Humm, I changed the lat lon and got a box that did not move. I must have done it wrong and will try again.
It would be nice to eliminate that email that says there is an error. I wonder if I should test this further then contact saildocs somehow about their server requirements?

Do you think this is worthwhile implementing as a grib request in grib_pi? --Provided the feature is going to stick around?

Thanks, Rick