Weather Routing

[scud]

Originally Posted by rgleason

Scud, sorry I forgot about that, too many PI to keep up with. I will dig into this when next at my laptop and try to make it happen on my machine. Have you provided all necessary instructions in post below, to repeat the problem? Thanks for your patience with me.

No sweat! you have been doing alot already and can't honestly ask for more.
Since then I have upgraded to OCPN 5.8.4 and I'm now @ 1.14.1.0 of WR. More info may be needed at your end to replicate the issue and I will try to post the new log file. As I mentioned, lately I have erased the OCPN installation on my Dell notebook and re-installed from scratch (erased the ini file as well), but the problem is still there. The other 2 PC's are fanless PC's but all running on WIN10 64bits. Didn't dare to erase those as well 'cause I use them on my boat (4 NMEA COM ports/connections configured) and I have some ocharts installed that I have purchased. Not quite sure I can successfully recover those if I erase and re-install OCPN.

[hasse_A]

Rick,
I think this is what scud is refering to.
https://www.dropbox.com/s/5i0ckswrfd...9_REC.mp4?dl=0
I am runing WIn10 64 bit, OpenCPN 5.8.0-0, WR 1.14.0.0
/Hans

[scud]

Originally Posted by hasse_A

Rick,
I think this is what scud is refering to.
https://www.dropbox.com/s/5i0ckswrfd...9_REC.mp4?dl=0
I am runing WIn10 64 bit, OpenCPN 5.8.0-0, WR 1.14.0.0
/Hans

Correct! the refresh late may change from notebook to notebook and freezes sometime if I move the mouse somewhere in the dyagram and left-click on it but just till I release the click

[rgleason]

Yes, i iinderstand now. Thanks.

[Gilletarom]

Originally Posted by scud

....
and I have some ocharts installed that I have purchased. Not quite sure I can successfully recover those if I erase and re-install OCPN.

Scud, penso che tu possa riavere gli o-chart. È certo che con le carte nautiche che hanno meno di un anno, sarà sufficiente reinstallarle. Per quelli più vecchi, puoi farlo se prima esegui il backup.

Gilletarom.

[Gilletarom]

Hello Sean, Dave.

Here is the analysis of a test using WeatherRouting and OpenCPN.

01° Create a route with OpenCPN. In this test this route is called "Essai". In this test this route has 9 waypoints from its beginning to its end.
02° Open the Grib plugin, load a grib file relating to the area occupied by the "Essai" route.
03° Open WeatherRouting
04° Place the mouse on the "Essai" route
05° In the main contextual menu of OpenCPN, use the item "Weather Route Analysis" (item introduced in the contextual menu by WR).
06° At this point, WR has created a "Research Setup" that exactly follows the path of the "Essait" route. For this, WR has created two "route weather" points numbered 001 and 009.
07° I edited the "Search Configuration" and chose the parameters I want.
08° I click on "Calculate"
09° A "meteo-trace" is calculated by WR.
10° At this stage everything is fine.
11° I export this "Weather-trace" in OpenCPN.
12° This weather-trace is called "Weather route". It appears in the track window of the Route/Trace/Waypoint and Layers manager of OpenCPN.

At this stage, the travel speed and travel time data for each segment of the track are still present in the display of this track by OpenCPN. This is a good thing.

But, then, this track must be transformed into a route with the "Trace --> Route" tool. Unfortunately, and this becomes absurd, the speed data and the travel times are replaced by a single speed: The one present in the global "Speed" zone for the entire route.

And similarly, the travel times of the different segments are recalculated using this single speed. It is absurd. What is the point of being able to study a route defined manually with WR if it is to throw the results of the study into the trash. This absolutely needs to be resolved.

This must go through a re-writing a partial re-writing of the route manager program of OpoenCPN.

And similarly, it would also be necessary to reprogram the calculation function of the expected travel time of the route so that the duration displayed when a route is activated takes into account the analysis carried out thanks to WR.

I also point out a bug present in the weather-route obtained from the weather-trace of WR. In my test, the "Essai" manual route has 9 points. It therefore comprises 8 segments. For OpenCPN, it actually has 9 segments because, for some reason that I never understood, and which dates from 10 or 12 years ago, the first segment starts from the actual position of the boat and not from the point start of the road. Even for example, if it is still at the bottom of a port.

Let's look at the properties of the weather-route obtained by opening this weather-route in the OpenCPN route manager. It can be seen that only 7 segments are listed. And there are probably 8 for OpenCPN if we start from the real position of the boat. And the last waypoint used is not the 009 but the 008. So, this is not normal.

Therefore, the numbers of segments are aberrant.

Personally, I have long wanted the first point of a route to be the first point created with the mouse when creating a route. If by making a change in OpenCPN, then the fantastic tools that are openCPN and WeatherRouting would be a big step towards each other....

I have dreamed of it for a long time.

Please Sean and Dave do something.... And thank you by advance ....

[rgleason]

Gille, I kind of doubt Sean is doing much on Wxroute these days, but of course we would always welcome his help!

[Gilletarom]

Originally Posted by rgleason

Gille, I kind of doubt Sean is doing much on Wxroute these days, but of course we would always welcome his help!

So, someone else has to take charge of the necessary evolution of this plugin. Even if it means changing the name so that Sean can continue to work on his side on his version.


Gilletarom.

[rgleason]

More easily said than done. What we need is some user who is also a programmer to help with further development. Dave has been wonderfully helpful and available when he can and he has fixed some serious issues. No need to rename the plugin. It does not work that way.

[scud]

Originally Posted by Gilletarom

Scud, penso che tu possa riavere gli o-chart. È certo che con le carte nautiche che hanno meno di un anno, sarà sufficiente reinstallarle. Per quelli più vecchi, puoi farlo se prima esegui il backup.

Gilletarom.

Thanks. Let's stay with English if you don't mind (for everybody's understanding). I'm pretty sure I can recover my o-charts but ... I learned my way that if ain't broken then don't fix it.
Just trying to avoid mishaps on my boat computer. It is already messy due to the interleaving of different metworks (NMEA, SEATalk, SeaTalkNT, NMEA2000) and I'd rather go sailing than tinkering with software patches and websites.

[Thonglor]

Originally Posted by Gilletarom

Hello Sean, Dave.

Here is the analysis of a test using WeatherRouting and OpenCPN.

01° Create a route with OpenCPN. In this test this route is called "Essai". In this test this route has 9 waypoints from its beginning to its end.
02° Open the Grib plugin, load a grib file relating to the area occupied by the "Essai" route.
03° Open WeatherRouting
04° Place the mouse on the "Essai" route
05° In the main contextual menu of OpenCPN, use the item "Weather Route Analysis" (item introduced in the contextual menu by WR).
06° At this point, WR has created a "Research Setup" that exactly follows the path of the "Essait" route. For this, WR has created two "route weather" points numbered 001 and 009.
07° I edited the "Search Configuration" and chose the parameters I want.
08° I click on "Calculate"
09° A "meteo-trace" is calculated by WR.
10° At this stage everything is fine.
11° I export this "Weather-trace" in OpenCPN.
12° This weather-trace is called "Weather route". It appears in the track window of the Route/Trace/Waypoint and Layers manager of OpenCPN.

At this stage, the travel speed and travel time data for each segment of the track are still present in the display of this track by OpenCPN. This is a good thing.

But, then, this track must be transformed into a route with the "Trace --> Route" tool. Unfortunately, and this becomes absurd, the speed data and the travel times are replaced by a single speed: The one present in the global "Speed" zone for the entire route.

And similarly, the travel times of the different segments are recalculated using this single speed. It is absurd. What is the point of being able to study a route defined manually with WR if it is to throw the results of the study into the trash. This absolutely needs to be resolved.

This must go through a re-writing a partial re-writing of the route manager program of OpoenCPN.

And similarly, it would also be necessary to reprogram the calculation function of the expected travel time of the route so that the duration displayed when a route is activated takes into account the analysis carried out thanks to WR.

I also point out a bug present in the weather-route obtained from the weather-trace of WR. In my test, the "Essai" manual route has 9 points. It therefore comprises 8 segments. For OpenCPN, it actually has 9 segments because, for some reason that I never understood, and which dates from 10 or 12 years ago, the first segment starts from the actual position of the boat and not from the point start of the road. Even for example, if it is still at the bottom of a port.

Let's look at the properties of the weather-route obtained by opening this weather-route in the OpenCPN route manager. It can be seen that only 7 segments are listed. And there are probably 8 for OpenCPN if we start from the real position of the boat. And the last waypoint used is not the 009 but the 008. So, this is not normal.

Therefore, the numbers of segments are aberrant.

Personally, I have long wanted the first point of a route to be the first point created with the mouse when creating a route. If by making a change in OpenCPN, then the fantastic tools that are openCPN and WeatherRouting would be a big step towards each other....

I have dreamed of it for a long time.

Please Sean and Dave do something.... And thank you by advance ....

Hello Gilletarom,

I've been playing around with this plugin in recent days. Before starting with using it I had a look at the manual. And there is a section "Purpose of Weather Routing (WR)" stating "Luckygrib has superb introductory documentation for WeatherRouting.", which I also read, almost studied.

I see the point in your post that technically it doesn't make sense to overwrite good values (the WR-calculated speeds) with bad values (i.e. the average). But honestly I don't understand the concept of laying a weather routing "layer" over a pre-defined route. The only benefit of doing that (which I'm able to see) is to get a meteogram of the route, i.e. the program calculating what kind of weather you'll get at a certain point in time along your route. But the purpose of weather routing is a different one: it is to calculate an optimal way from A to B, given the polar of your boat and the wind data over time (encoded in GRIB).

Defining a route and then doing a weather routing is contradictory to me. Maybe you want to define restrictions for your route, due to islands, hazards, whatever, but then I personally could think of one or two waypoints, not eight or nine. As mentioned in the beginning, the LuckGrib side is incredibly good for the big and the small picture of WR, and here is what it says about restrictions: https://routing.luckgrib.com/start/boundaries.html
https://routing.luckgrib.com/start/constraints.html

No offense intended, just trying to understand your intentions and the realisation in OpenCPN & WR!
For a free tool I think it's already fantastic what has been implemented!

BR Tibor

[wholybee]

Originally Posted by Thonglor

Hello Gilletarom,

I've been playing around with this plugin in recent days. Before starting with using it I had a look at the manual. And there is a section "Purpose of Weather Routing (WR)" stating "Luckygrib has superb introductory documentation for WeatherRouting.", which I also read, almost studied.

I see the point in your post that technically it doesn't make sense to overwrite good values (the WR-calculated speeds) with bad values (i.e. the average). But honestly I don't understand the concept of laying a weather routing "layer" over a pre-defined route. The only benefit of doing that (which I'm able to see) is to get a meteogram of the route, i.e. the program calculating what kind of weather you'll get at a certain point in time along your route. But the purpose of weather routing is a different one: it is to calculate an optimal way from A to B, given the polar of your boat and the wind data over time (encoded in GRIB).

Defining a route and then doing a weather routing is contradictory to me. Maybe you want to define restrictions for your route, due to islands, hazards, whatever, but then I personally could think of one or two waypoints, not eight or nine. As mentioned in the beginning, the LuckGrib side is incredibly good for the big and the small picture of WR, and here is what it says about restrictions: https://routing.luckgrib.com/start/boundaries.html
https://routing.luckgrib.com/start/constraints.html

No offense intended, just trying to understand your intentions and the realisation in OpenCPN & WR!
For a free tool I think it's already fantastic what has been implemented!

BR Tibor

The reality is that for most cruising boats on most passages, there is little difference in time between a straight line and following an "optimal" course. Case in point, when I sailed from SF to Hawaii in 2018. The predicted time difference between the straight line course, and an optimal course that added 500 miles, was 45 minutes over 14 days.

Plus, given the errors in grib files, the errors in polars (even if you work really hard to make them "perfect" and the effect of waves that are not modeled in the route, the optimal route isn't going to be nearly correct anyway.

Consider that the best race teams with all the money to spend on all the tools, hire a navigator instead of following a predicted route.

I have found that weather routing (and I gave up on the plugin and now use Predictwind) is an indispensable tool for planning, but I never follow the route suggested. I may follow a near straight-line, I may follow local knowledge to avoid an area, or I may just follow the wind. That is why it is worth it to calculate along a given route.

[Thonglor]

I have taken your example route with the start waypoint N48° 35.700' W002° 44.700' and target waypoint N48° 47'200 W002° 44.300. This is a distance of 12nm (great circle route). I've taken polars from two very different boats: (1) catamaran Fountaine Pajot Helia and (2) monohull X-Yachts XP-44 (from OpenCPN polar templates). Now I WR-ed from WP(a) to WP(B) and what the WR can do on this short distance is to develop and show optimal routes given the boat characteristics:



Any pre-defined route on this short distance does restrict the WR algorithm to develop a WR-ed route, in my personal view.

[Thonglor]

Originally Posted by Gilletarom

Hello Sean, Dave.

Here is the analysis of a test using WeatherRouting and OpenCPN.

01° Create a route with OpenCPN. In this test this route is called "Essai". In this test this route has 9 waypoints from its beginning to its end.
02° Open the Grib plugin, load a grib file relating to the area occupied by the "Essai" route.
03° Open WeatherRouting
04° Place the mouse on the "Essai" route
05° In the main contextual menu of OpenCPN, use the item "Weather Route Analysis" (item introduced in the contextual menu by WR).
06° At this point, WR has created a "Research Setup" that exactly follows the path of the "Essait" route. For this, WR has created two "route weather" points numbered 001 and 009.
07° I edited the "Search Configuration" and chose the parameters I want.
08° I click on "Calculate"
09° A "meteo-trace" is calculated by WR.
10° At this stage everything is fine.
11° I export this "Weather-trace" in OpenCPN.
12° This weather-trace is called "Weather route". It appears in the track window of the Route/Trace/Waypoint and Layers manager of OpenCPN.

At this stage, the travel speed and travel time data for each segment of the track are still present in the display of this track by OpenCPN. This is a good thing.

But, then, this track must be transformed into a route with the "Trace --> Route" tool. Unfortunately, and this becomes absurd, the speed data and the travel times are replaced by a single speed: The one present in the global "Speed" zone for the entire route.

And similarly, the travel times of the different segments are recalculated using this single speed. It is absurd. What is the point of being able to study a route defined manually with WR if it is to throw the results of the study into the trash. This absolutely needs to be resolved.

This must go through a re-writing a partial re-writing of the route manager program of OpoenCPN.

And similarly, it would also be necessary to reprogram the calculation function of the expected travel time of the route so that the duration displayed when a route is activated takes into account the analysis carried out thanks to WR.

I also point out a bug present in the weather-route obtained from the weather-trace of WR. In my test, the "Essai" manual route has 9 points. It therefore comprises 8 segments. For OpenCPN, it actually has 9 segments because, for some reason that I never understood, and which dates from 10 or 12 years ago, the first segment starts from the actual position of the boat and not from the point start of the road. Even for example, if it is still at the bottom of a port.

Let's look at the properties of the weather-route obtained by opening this weather-route in the OpenCPN route manager. It can be seen that only 7 segments are listed. And there are probably 8 for OpenCPN if we start from the real position of the boat. And the last waypoint used is not the 009 but the 008. So, this is not normal.

Therefore, the numbers of segments are aberrant.

Personally, I have long wanted the first point of a route to be the first point created with the mouse when creating a route. If by making a change in OpenCPN, then the fantastic tools that are openCPN and WeatherRouting would be a big step towards each other....

I have dreamed of it for a long time.

Please Sean and Dave do something.... And thank you by advance ....

Originally Posted by wholybee

The reality is that for most cruising boats on most passages, there is little difference in time between a straight line and following an "optimal" course. Case in point, when I sailed from SF to Hawaii in 2018. The predicted time difference between the straight line course, and an optimal course that added 500 miles, was 45 minutes over 14 days.

Plus, given the errors in grib files, the errors in polars (even if you work really hard to make them "perfect" and the effect of waves that are not modeled in the route, the optimal route isn't going to be nearly correct anyway.

Consider that the best race teams with all the money to spend on all the tools, hire a navigator instead of following a predicted route.

I have found that weather routing (and I gave up on the plugin and now use Predictwind) is an indispensable tool for planning, but I never follow the route suggested. I may follow a near straight-line, I may follow local knowledge to avoid an area, or I may just follow the wind. That is why it is worth it to calculate along a given route.

Yes, but SF to Hawaii is 2,000nm, not 12nm. And reliable weather forecasts go three days into the future, so maybe your first 360nm. So a typical case of different strokes for different folks.

I really like LuckGrib on all the philosophical background on the topic of WR.

[wholybee]

Originally Posted by Thonglor

Yes, but SF to Hawaii is 2,000nm, not 12nm. And reliable weather forecasts go three days into the future, so maybe your first 360nm. So a typical case of different strokes for different folks.

I really like LuckGrib on all the philosophical background on the topic of WR.

The GPS model has a resolution of about 11nm and one hour. So, the model internally is going to have a constant wind speed and direction over the whole route for the whole time you sail(maybe a change at the 1 hour point). Grib viewers will interpolate what the wind does at a higher resolution, but that is going to be radically different from the puffs and lulls you will experience in real life.

It is pointless to try a weather route such a short distance. It will work, and you can sail the route, but you will not have any gains over just sailing the course. You would do better to just sail the conditions and follow the wind. Look for tells on the water and other boats to see where the wind is.

It is also a bit naive to believe a general statement "weather forecasts are reliable 3 days in the future." They can change very quickly, being wrong 1 or 2 days in the future, and can also have very important information 10 days out, even knowing that the forecast will change before then. On my trip to Hawaii, I downloaded a new grib 4 times daily. Often the suggested route in the afternoon was radically different from that suggested in the morning.

In other passages, I would choose a slower more comfortable route instead of beating into a swell for the best passage time. One of the reasons I switched from the plugin to Predictwind is that Predictwind has better tools for making that kind of decision.

This all supports my position that WR is an important tool, but doesn't provide the route you should follow. A quick look at Luckgrib(which I have not looked at before now) seems to follow that as well:

"The goal of the LuckGrib weather routing system is to increase your understanding of weather systems. It is not simply to provide you with a path to follow. You may choose to follow a path the system generates, however the goal is for you to make more informed decisions, not tell you what to do."