Feature Request - Generate a SailDocs request

[Botnic]

It would be nice to be able to generate the code needed to request a GRIB file on SailDocs. We use Pat and Winlink/Pactor to communicate. Therefor a simple Textbox showing the code to be copied and sent would be enough.

My idea: I would add this function to the "DialogLoadGRIB".

The simplest way (maybe not the nicest) would be to add a button to show the Code. An other way would be to add in the "DialogProxy" a function "Mail" and then the normal Download button would show the code.

Has somebody better ideas to implement such a function? Thank you for your inputs.

[Botnic]

Another very simple solution would be to have a text field included into DialogLoadGRIB (when activated in the settings) showing the code for the actual settings.

[norulz]

Thanks for the suggestions.

It is quite clear that there is a need for perhaps an entire set of low bandwidth features in XyGrib. Generating saildocs request syntax being only one of them. I hope that this thread will lead to some open discussion on the issue which will help focus on the best solutions

David

[dominiquehausser]

For offshore sailing, specially in areas where the GFS model (nearly the only one easy to get) is not very useful (I had some not very nice experiences, this is certainly a huge improvement). The service provided by the association Sailmail.com to get data by mail through SSB transceiver and sat low broadband connexion allow to request data of different format (image, pdf, grib files) from different websites (request in the URL is also accepted by number of websites). This already bring a lot of possibilities to avoid bad weather that could put people in huge difficulties.

We certainly have to open the discussion on the minimal/maximal number of need variables, the precision of the model in surface and time. Not very easy. I'll try to write down a couple of ideas, nothing technical, but more functional from the user side to estimate which variables should be made available.

What bring XyGrib is the variety of models and that's something more than useful. According to the area, the model choice will be important to improve the quality of the prediction.

In most situations,

• a picture with a synoptic situation and
• a text file for expertised forecast and
• a grib file with surface pressure wind direction and speed 0.5°*0.5°, step 3 hours for the next 4 days will help to avoid a potential risk for the zone of sailing for the next 4 days (the fastest the boat is, the larger the surface will be).
• a grib file with currents (step 24h for 4 days, already available via saildocs.com) are also useful according the area of sailing.

Then for weather routing, the data used are wind speed and direction, gusts, currents, waves sometime CAPE as a barrier for an area not to go if the value is greater than Precision is important the first 24 hours (36), then it is more to have an idea of the evolution.

The smallest the files the best it is for SSB, for sat low broadband, up to 500KB it is more or less OK, more that is possible, but not with saildocs (mail size including attached files is limited to 500kb).

For info, when producing its paper about weather routing as a safety measure for offshore sailing, a survey among members of the association Sail the World (stw.fr) showed than 2/3 of offshore sailors were still using SSB transceivers for request.

I have no idea if this is technically complicated, but this can be add to the todo list in priority 2 or 3, after being able to compare 2 files.

[Botnic]

Thank you for your interest in this topic.

Most of these low bandwidth technologies use E-Mail a primary communication channel. This is true for Iridium Sat and HAM Pactor. Both frequently used by sailors all over the world. There are several clients used to send and receive mails. A direct communication to the Email clients could be difficult and is not needed. Copy/Paste of the code to a mail is simple to use.

Where to send the mail to? 1) The simplest approach is to use the SailDoc service. A GRIB file can be requested by a simple command but I have no idea what model is used or where the data comes from.

2) If there were a API to request GRIB files by URL from the opengribs servers, the SailDoc service could be used to grab a file from there.

3) Or the opengrib servers could also reply to e-mail requests them self ;-)

I coded a simple interface (quick and dirty) to generate the code for SailDoc (Shown in the picture above). It does not support all functions of SailDoc. I don't think this is the solution yet, but it allows me to use SailDocs easy at the moment. ;-) saildoc.zip If in Options -> Show SailDoc Code is activated, a textfield with the code appears in the Download Dialog.

[dominiquehausser]

Hello, The model that you are requesting is GFS, the only one provided by NOAA through this command line via saildocs. When you send the mail to query@saildocs.com then the grib file is prepared somewhere organised by Sailmail, but not by the XyGrib server. If you are sailing in Mediterranean Sea, you can get other models that are much better for this area : http://openskiron.org/en/minimal-gribs-instructions. So clearly the improvment with opengribs will be to access data from other models than GFS for the atmospheric model or RTOFS for the currents. Automaticaly generating the command line to be inserted in the mail is not the most complicated problem, but how to receive the instruction on opengribs server, to interprete the request, to generate the file with the requested data need some reflexion on how to do it without overloading the server, being sure about security questions and probably some other elements I have not in mind right now. The need is there so I am sure something will happen and be available in one of the next version (I do not know how much time it could take). Have a nice day

[norulz]

Hi @Botnic,

If we take the route of providing and/or displaying low bandwidth data, I would prefer to have a comprehensive set of features based on existing external low bandwidth data sources and possibly adding certain elements of our own grib server.

We are currently testing an API that uses saildocs to transport data from our grib server. It is not yet clear what the benefits may be as their own server using GFS sources provides more options and also smaller files.

Regarding your very neat solution to display Saildocs request syntax: I'm reluctant to include it now as a sole low bandwidth element and not really a core feature. More ever, it is not doing Saildocs justice as it cannot offer the full range of options that Saildocs offers in preparing GFS gribs (resolution and time steps). I will, however, keep the suggested patch to be included in a possible future "Low Bandwidth Request Dialog" that will include a package of low bandwidth features.

[Botnic]

Hi @norulz I hope you did not understand me wrong: The shown patch was never written to be included into the project tree. It was build for my usage primarily nor is it finished. I would very appreciate to see some low bandwidth features in the future.

[norulz]

Hi @Botnic

I also hope that I'm not misunderstood. I'm all for low bandwidth features and your inputs are indeed valuable as part of the ongoing discussion on the matter.

I feel that we need to explore and discuss what the package of features needs to be. The solution needs to be comprehensive addressing all 3 aspects of a complete solution

• The data sources
• The transport methods
• The data display

Should data be only in grib format but perhaps also weather fax tiff files. Is there anything to be gained by providing low bandwidth gribs on our opengribs.org server?

Is POP3 still the best solution for low bandwidth and low latency? Should we use XyGrib to directly pull data via a http link? Should we use saildocs? If so - loosely (as you suggested) or tightly integrated? (I think that we should assume that users can download email attachments on their own).

If data also includes weather fax files, how do we display it. Do we adopt the paradigm of the "Weather Fax" plugin for openCPN or perhaps something else?

I'm sure we will get to a solution in the end. David

[rgleason]

Use of walking gribs to reduce the payload? OpenCPN grib_pi does this. Perhaps Xygrib does too/