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

I have tested too
From Saildocs, it runs.
In O it 'almost' works although there are some minor problems to solve.
Also needs to add the possibility in the request dialog.
That is included in my to do list but I'm far from my tools at the moment.
I'll seeit mid February
Jean Pierre

I have tested too
From Saildocs, it runs.
In O it 'almost' works although there are some minor problems to solve.
Also needs to add the possibility in the request dialog.
That is included in my to do list but I'm far from my tools at the moment.
I'll seeit mid February
Jean Pierre

... as requested by rgleason, I included in my mail the Saildocs request - repeat it here:

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

To get rid of the error mail just skip "send" in the beginning of the sentence.

This is a pretty nice feature. I don't quite get what the 2014012718 does to make it smaller. It does not seem to make much of a difference in these files. How does it work and how do you know that is what it is for??

However, there are quite a few features of the SailDocs server that, when using email to access it—by far the most efficient method over sat phone—are only available by writing the email request directly, so that’s what I do.

Quote:

Let’s assume that we are about a third of the way from Bermuda to the Azores in Morgan’s Cloud at position 33°58’ North and 054°42’ West.
Every day I would email the following script to query@saildocs.com
send GFS:36N,32N,052W,058W|0.5,0.5|6,9,12,15,18,24..72, 84..168|WIND|7.0,080
This looks intimidating, but with a bit of practice and reference to the instructions, you can easily decode it to mean:

for two degrees of latitude to the north and south and three degrees of longitude to the west and east of our position;

advance that area assuming that our boat will travel at 7 knots on a heading of 80 degrees true;

provide data on a half a degree grid (the most detail that the GFS model provides);

starting six hours after the model run time and then for every three hours to 18 hours and then every six hours out to three days and then every 12 hours for seven days.

Quote:

This script seems to yield the maximum amount of useful information about the wind over the next week for the minimum amount of satellitephone time. I start at six hours because the models are usually delayed by that much anyway, and reduce the forecast frequency over time since GRIB accuracy drops substantially after 72 hours, so there is not a lot of point in getting the data for every three hours after the first day. Having said that, I look out seven days because it’s good to get a warning if the model thinks my ears are going to get blown off, even if it does not happen.
.

... yes, I believe, they definitely will stay around, as they will limit the amount of data significantly for such long period. This is especially useful, when you are requesting this via HF with limited bandwidth.

Let me "dream" for a moment:

OpenCPN "knows" the current ships position. What, if Open CPN could build such a request, by "asking" the user how many miles "around" the current position you are interested in the GRIB data and then estimating course and speed (to be entered by the user) and the wanted weather data and then "builds" this request, which then can simply be copied and pasted into the request message to be sent to Saildocs?? In a later version OpenCPN could directly send this via the apporopriate method to Saildocs?

The latter is not so necessary, as I believe there is a lot of coding effort necessary, and building a request and copying into an request message is sufficient in my opinion.

With the "Airmail" program you have three possibilities to send such request 1. Via Telnet (when you have an internet connection, 2. via HF (using e.g. Pactor or Winmor etc. ...) or via Satphone (Airmail povides for appropriate configuration).

If, however, an interface to "Airmail" could be built, this would even be more convenient (the transmission method then is to be selected by the "Airmail" user).

On the other hand, "Airmail" provides a graphical interface, where you can draw a square around your position (which "Airmail" knows as it can interface to the GPS and the position is shown in the graphics window) and then just enter your request data. The only disadvantage is, that you have to stop OpenCPN, wen you want to use "Airmail" as both are "competing" for the GPS usage....

However, this is probably a loooong way ahead and it would be most sufficient already, to just be able to display these "stepped" GRIBs in OpenCPN (which worked in former releases...).

Email: query@saildocs.com
Subject: gribauto
First Line:
Code:
GFS:42N,37N,030W,022W|0.5,0.5|0,6..144|WIND,WAVES, RAIN|7.0,58,2014012718
Here is the grib that was received if you want to try, take the .doc off please.

|0,6..144
Interval & Time range
From S/V Morgan's Cloud request,
Start 6 hrs after the model run time
then every 3 hrs to 18 hrs
then every 6 hrs to for 3 days
then every 12 hrs for 7 days.
How to do this?

.... of course, I would vote for this feature but do not have any means to do so, I am afraid.

However, coming back to the above post(s). Why not asking the user on which diameter or radius in nautical miles he/she wants the grib to be created and then "moved" by (user entered) estimates of ship's speed and course. OpenCPN would know the proper logitude and latitude (the longitudes would differ the nearer you get to the poles) by simple calculation and could build the "square" by the uprounded proper longitude and latitude?!