OpenCPN 4.6.1 - Weather routing and Land Detection not working

[seandepagnier]

Use the WP and routing functions (including formatting of coordinates, dates and time ) already available in ocpn.

Great idea, has been mentioned before but there are some issues:

1) So many waypoints in the list. Should only waypoints with weather routing attribute to listed? How to do this? Make "weather routing" somewhere in the waypoint description?

2) How to load other weather routing configurations? Does this create new waypoints? Should it leave existing weather routing waypoints?

3) How to delete all weather routing waypoints? Should plugin provide this option?
well exactly as already implemented in ocpn!

1st show which grib, polar are used and where the calculation started to fail.

The grib used is in the grib plugin. The polar used is in the configuration.

It does show where the calculation failed. This is the edge of the map it produced.

Screen 1 shows a unsuccessful attenmpt

I don't know what other error message it should show you from what it did.

Screen 2 is ok but would be nice to have a possibility to make 'intermediate WP's which should be added to the route within a range - so in my example I could add a wp at Otranto with range 100nm and algorithm would not even start to explore options towards Genua

Good idea. So should the weather routing be tied to routes then?

Currently you can create many weather routes for each route segment, but it might be nice to force it to sail to each waypoint along a route and combine the statistics.

Screen 2 took several minutes to calculate - it would be good when on start of calculation:
- 1st minimise wr-pi dialog
- 2nd zoom so that start and end WP are shown
- 3rd see progress of calculation

1) I don't think it does this, but it could be an option
2) Another option, not sure it's always desirable
3) There is a progress bar for total configurations, and otherwise, the route map is rendered which shows the progress.

Hope this feedback helps to make this wr_pi more popular

Yes, keep making feedback it helps.

[skipperearly]

[QUOTE=boat_alexandra;2770719]Great idea, has been mentioned before but there are some issues:

1) So many waypoints in the list. Should only waypoints with weather routing attribute to listed? How to do this? Make "weather routing" somewhere in the waypoint description?
[UNQUOTE]
In principle the number of WPs is no problem as long as the pulldown control resorts the list by character entered. Maybe a even better solution will be following the same logic as with tide info in routes (@~~tidal station name) and have e.g. a @wr~whatevername as the identifyer.

[QUOTE]
2) How to load other weather routing configurations? Does this create new waypoints? Should it leave existing weather routing waypoints?
[UNQUOTE]
Sorry I got misunderstood. I just mean import/export of WP's is already implemented in route/WP manager so no more work needed in wr_pi

[QUOTE]
3) How to delete all weather routing waypoints? Should plugin provide this option?
well exactly as already implemented in ocpn!
[QUOTE]
As long as the wp_pi allows all created WP's to be labeled with some prefix no more functions are needed, as the rest is a function of the route/WP manager.



[QUOTE]
The grib used is in the grib plugin. The polar used is in the configuration.
[UNQUOTE]

I know that, but may have forgotten which e.g. grib I had loaded. Why not showing the file names in the dialog header for ease of remembering.
Happened to me several times that I compare different vessels and get distracted. Polar (I believe) is remembered after restart of wr_pi but grib not.

[QUOTE]
It does show where the calculation failed. This is the edge of the map it produced.I don't know what other error message it should show you from what it did.
[UNQUOTE]

'polar/land/boundary failed' - so what do I do now in the Gibraltar > Cascais example. Change the starting point to Cadiz to avoid the difficult routing through the straight? But its excactly for this tidal/wind situations with the TSS limitations that a wr_pi should be helpful. Had tried various settings (even 0nm distance from land) without success.

Good idea. So should the weather routing be tied to routes then?

Currently you can create many weather routes for each route segment, but it might be nice to force it to sail to each waypoint along a route and combine the statistics.
1) I don't think it does this, but it could be an option
2) Another option, not sure it's always desirable
3) There is a progress bar for total configurations, and otherwise, the route map is rendered which shows the progress.
Yes, keep making feedback it helps.

By definition WP's on planned routes are fixed and when the route is activated after arrival within a distance to the WP the next WP is targeted.
For the wr_pi I thought more about another "class" of a WP, like a pass-point meaning this passpoint defines an area around a wp (Range) through which the weather route will have to pass. For the calculation this may help to seek into the right direction.

ref 3 - only if "calculation area" is already visible on the screen, otherwise user doesn't know and can only guess.

[mikedefieslife]

I have had problems with the weather routing plugin too but trying to get better at configuring it.

last summer I was more likely to have a route made in fastseas.com then download it to OpenCPN. I'd like to use weather routing more though in the coming seasons, so thanks to the author for the plugin.

I think one feature that could be added is the ability to set minimum speed and have the algorithm work on motoring speed should the predicted sail speed fall below this.

Yes some purist sailors will happily sit there at 1.7knts and you may have no choice on long routes, but in med the distances aren't usually that massive, and the weather very changeable. So it would be good if I could for example, tell it that I will motor if sailing speed (based on wind and polars) falls below say 4knts. The algorithm could then work out a route and show the expected time under sail, and time under motor.

[seandepagnier]

Originally Posted by skipperearly

In principle the number of WPs is no problem as long as the pulldown control resorts the list by character entered. Maybe a even better solution will be following the same logic as with tide info in routes (@~~tidal station name) and have e.g. a @wr~whatevername as the identifyer.

Ok good point.

I can try it, and I agree it is better that opencpn handle the waypoints. The real issue now is that the core program needs some changes to really facilitate this integration.

2) How to load other weather routing configurations? Does this create new waypoints? Should it leave existing weather routing waypoints?


Sorry I got misunderstood. I just mean import/export of WP's is already implemented in route/WP manager so no more work needed in wr_pi

No, I mean if someone posts a weather routing configuration xml file and I want to try it (to see why they had problems). This file currently includes all the needed waypoints. So it would be nice if the weather routing configuration could still include any waypoints used by any configurations so that they could be created if they don't exist.

As long as the wp_pi allows all created WP's to be labeled with some prefix no more functions are needed, as the rest is a function of the route/WP manager.

I agree. I think some sort of prefix would be desirable.

I know that, but may have forgotten which e.g. grib I had loaded. Why not showing the file names in the dialog header for ease of remembering.
Happened to me several times that I compare different vessels and get distracted. Polar (I believe) is remembered after restart of wr_pi but grib not.

The grib file is in the dialog header of the grib plugin.. You want it in the dialog of weather routing as well?

It does show where the calculation failed. This is the edge of the map it produced.I don't know what other error message it should show you from what it did.

'polar/land/boundary failed' - so what do I do now in the Gibraltar > Cascais example. Change the starting point to Cadiz to avoid the difficult routing through the straight? But its excactly for this tidal/wind situations with the TSS limitations that a wr_pi should be helpful. Had tried various settings (even 0nm distance from land) without success.

Most likely you need a smaller step size to route through narrow areas. I cannot say for sure unless you post your weatherroutingconfiguration.xml, the grib file used, and the boat and polar files so that I can reproduce the result you got exactly.

So it's very difficult for the program to know why it is failing, and although it could make better suggestions in many cases, I could come up with a counter example where the suggestions it made are the wrong thing to change.

By definition WP's on planned routes are fixed and when the route is activated after arrival within a distance to the WP the next WP is targeted.
For the wr_pi I thought more about another "class" of a WP, like a pass-point meaning this passpoint defines an area around a wp (Range) through which the weather route will have to pass. For the calculation this may help to seek into the right direction.

I think it should just do the normal routing and route from the first point to the second, then route from second the third etc... Not sure about a passpoint range needed since this is actually more difficult and confusing. Would it try to get at the very edge of the passpoint area since this would give a better routing?


If you truly want this behavior you would do better to just use boundaries to force the route through the "passpoint" area.

Originally Posted by mikedefieslife

I think one feature that could be added is the ability to set minimum speed and have the algorithm work on motoring speed should the predicted sail speed fall below this.

This is already supported if you define a motoring polar. After all, motoring isn't the same in all winds. This is already handled in the same way as a "sail change" The plugin will show when the polar used changes, and what percent of time for each polar using the fastest polar.

But keep in mind the author of the plugin (me) does not and never did use an engine and I think it's the wrong way to go about doing things. I managed to sail all over the world just fine, and had I used an engine I don't see how it would have improved my experience. I am sure glad I never used one, having it would have been a mistake.

The diesel fumes I sometimes wake up to because someone nearby is only proving my point.

[skipperearly]

Most likely you need a smaller step size to route through narrow areas. I cannot say for sure unless you post your weatherroutingconfiguration.xml, the grib file used, and the boat and polar files so that I can reproduce the result you got exactly.

So it's very difficult for the program to know why it is failing, and although it could make better suggestions in many cases, I could come up with a counter example where the suggestions it made are the wrong thing to change.

Indeed with a 20min step size routing worked but e.g. 30min again no result. So very difficult for the user to decide what to use. Maybe to make a "pre-calculation anaysis" of distance between start/end coordinates and decide/suggest from there the step size, then if no result try again with smaller step size until a route is found.
My earlier comment to first zoom in to show start/end point and minimize (during calculation) the wr_dialog is thereby essential helpful to give the user a progress feedback.

[rgleason]

Skipperearly, your discussion is good.

Re wr waypoints, perhaps being able to import from route manager would be an easier improvement?

It would be useful to make dragging the wr wp a possibility.

Sometimes if you zoom right in you can identify the the landmass-wind direction-interval-etc issue. Didier was working on an algorythm that would dynamically adjust interval, course max etc.

Sean has a strong ethical and practical aversion to fossel fuels and ice which i understand and respect. You can make a power polar file yourself, but he encourages us all to sail!

Thanks skipearly and sean!

[skipperearly]

Quote:

I know that, but may have forgotten which e.g. grib I had loaded. Why not showing the file names in the dialog header for ease of remembering.
Happened to me several times that I compare different vessels and get distracted. Polar (I believe) is remembered after restart of wr_pi but grib not.

The grib file is in the dialog header of the grib plugin.. You want it in the dialog of weather routing as well?
[UNQUOTE]

This is true but why should a user keep the grib_pi open when doing weatherrouting? screen real estate is valuable! - and the wr_pi is anyhow using the latest grib loaded in the grib_pi - both grib info and polar info would be nice reminders in the dialogue header.

further comment on the "integration with the route manager": currently a calculated wr is shown under tracks - I find this confusing, as tracks are something real and from the past but a wr is something planned. Would be more logical to me to have it under routes and with a more helpful name. ("weather routing + starttime " is not enough, either make it userdefinable or add at least the route name to it and store calculation time and grid reference under the advanced tab)
Would also like to have planned TWA,TWS AWA AWS COG SOG and maybe other paramters stored to each wr position so that this could be printed out and be kept as backup.

[seandepagnier]

Originally Posted by skipperearly

Quote:

I know that, but may have forgotten which e.g. grib I had loaded. Why not showing the file names in the dialog header for ease of remembering.

Do you think it makes sense to assign a grib to a configuration? So you could compare configurations from different weather models or?

Selecting the configuration would instruct the grib plugin to load that grib file. Not sure how multiple selection would work.

I would add a configuration check to use the current grib (normal behavior), or to specify a grib file

This is true but why should a user keep the grib_pi open when doing weatherrouting? screen real estate is valuable! - and the wr_pi is anyhow using the latest grib loaded in the grib_pi - both grib info and polar info would be nice reminders in the dialogue header.

Maybe a nice optional feature. I like the idea of showing the polar, but keep in mind that the polar can change along a route since multiple polars are supported.

further comment on the "integration with the route manager": currently a calculated wr is shown under tracks - I find this confusing, as tracks are something real and from the past but a wr is something planned. Would be more logical to me to have it under routes and with a more helpful name. ("weather routing + starttime " is not enough, either make it userdefinable or add at least the route name to it and store calculation time and grid reference under the advanced tab)

It exports to track because tracks can store the boat speed, and other data for further analysis that is not in a route. You can convert a track to a route.

Now, maybe it should export to route, or have the option. I need a route sometimes if I am going to follow this with the autopilot... but in practice I tweak the route along the way anyway.

Would also like to have planned TWA,TWS AWA AWS COG SOG and maybe other paramters stored to each wr position so that this could be printed out and be kept as backup.

I think it has all of these already using the route position dialog..

So it seems the next big step to weather routing is integration with main program routes and waypoints. I agree that dragging the starting point would seem nice.

Maybe it should export all the waypoints used in any configuration into the weatherrouteingconfiguration.xml, and create these waypoints if they don't exist when loading the configuration??

The normal act of dropping a waypoint does not name it. This makes it difficult to find.

So you can either edit the waypoint and add a name then search for it. Or maybe I could have a button to press in the configuration next to start or end, and once pressed, you could right click the waypoint and set as "weather routing position" and it would select it..

If you have any other ideas let me know.

[skipperearly]

[QUOTE=boat_alexandra;2771795]Do you think it makes sense to assign a grib to a configuration? So you could compare configurations from different weather models or?
[UNQUOTE]

assign - NO, show which ones have been used YES! once a wr has been calculated enable a userdefinabel name for this route, then user may change grib, calc again and store with different name. Having then a facility to compair different route calculations for the same start/end coordinates makes great user value. What and how to compair is a different discussion.

[QUOTE]
Maybe a nice optional feature. I like the idea of showing the polar, but keep in mind that the polar can change along a route since multiple polars are supported.
[UNQUOTE]

I was sloppy with my language, not polar but Boat name:
eg you have one set of polars for e.g Wauquiez40 - Racing crew (different sail changes, different time periods for sail changes, etc) or Wauquiez40 - Single handed (few sails to change. possibly motoring polar (sorry ) and long delays between sail changes) - this boat config name should then be inherited into the suggested route naming.

[QUOTE]
It exports to track because tracks can store the boat speed, and other data for further analysis that is not in a route. You can convert a track to a route.

Now, maybe it should export to route, or have the option. I need a route sometimes if I am going to follow this with the autopilot... but in practice I tweak the route along the way anyway.
[UNQUOTE]
speed column does already exist in the route details, it is currently only used as SOG, no sophistication. All the other valuable values (AWS, TWS, AWA, TWA, maxWavehight etc ) are not shown in the route manager. Maybe this deserves to remain stored in wr_pi for analysis/printing/exporting as csv etc

I think it has all of these already using the route position dialog..
[UNQUOTE]

to my knowledge unfortunately not.

[QUOTE
So it seems the next big step to weather routing is integration with main program routes and waypoints. I agree that dragging the starting point would seem nice.

Maybe it should export all the waypoints used in any configuration into the weatherrouteingconfiguration.xml, and create these waypoints if they don't exist when loading the configuration??

The normal act of dropping a waypoint does not name it. This makes it difficult to find.

So you can either edit the waypoint and add a name then search for it. Or maybe I could have a button to press in the configuration next to start or end, and once pressed, you could right click the waypoint and set as "weather routing position" and it would select it..

If you have any other ideas let me know.

I agree, alignment of WP handling should have the highest priority.

[rgleason]

I have a different point of view about wx waypoints. They are not a subset of opencpn waypoints due to the information needed and desired. They are more like a track, but should perhaps have their own type. A wxp weather_routing point needs to have similar but more extensive finctionality than the waypoint manager.
There have also been ideas and requests for better single line routing calcs for current.

Having multiple types of information using the waypoint manager gets confusing. I give you the example of squiddio.
Indeed Jon Gough has redesigned Squiddio to use a new entity type in ODraw specifically geared to this information. I believe it uses layers and solves the issue that at times we need certain info without distractiom by extraneous info. This is the problem with using wp manager.

I believe wxp should be its own entity type (a super set of wp, track and grib plus calculated values with a wxp manager similar to wp manager. Import and export to wp manager should be possible.

In addition I place a very high priority on showing the results of the optimal routing track wx conditions, wind, and boat data in a condensed tabular format that can be viewed and adjusted by the user.

The third very important improvement would be somehow solving the failed routing problems when close to land to make it easier on users.
Didiers work on dynamic adjustment of intervals, max course, etc might help.

[skipperearly]

@rgleason : don't see the great difference in opinion. for a user a wp is a pair of coordinates to which certain information can get attached. But there is one familiar way to create, move, delete or manipulate wp's. So if wp's are used for specific tasks - like start of wr or end of wr - then its just a matter of getting them in/out to the wr_pi. same for others pi's like Squiddo (which I dont use so I cannot comment). So to have different classes of wp's is ok but invites an enhancement of the routing/wp manager and not a reinvention of the user interface of wp handling. - the @~~ naming convention seemed to me as being a pragmatic way to enable parallel developments of routingmngr and xx_pi's - thats why I suggested @wr~anyname.

To treat wr routes as tracks I find confusing, I would rather encourage a new entity : w_route which is the result of a calculation. Having then the option to compare different w_routes should be an essential benefit of any wr_pi. Here the user may then select his favorite w_route and import it to the route manager.

[did-g]

You can try:
https://ci.appveyor.com/api/buildjob...1129_setup.exe

On linux you have to compile it yourself from
https://github.com/did-g/OpenCPN.git

It's opencpn with a bunch of plugins, it's incompatible with

For weather routing you can add O waypoint with the WP right click menu when WR dialog box is open. Link is dynamic if you move the WP, WR is updated.

You can also add an O route and compute it, again with right click route menu. The UI is awful but you can :

- compute the best route with WR.
- export as track
- convert to route
- import it ('Weather route analysis')
- compute it with a different grib , climatology, and so on.

You need a boat polar with 360° speed or it fail often (it's a POC and actual computation is rough, it's only compute speed and route's WP).

Optimize tacking should work downwind too.

[Moo]

Originally Posted by skipperearly

@rgleason : don't see the great difference in opinion. for a user a wp is a pair of coordinates to which certain information can get attached. But there is one familiar way to create, move, delete or manipulate wp's. So if wp's are used for specific tasks - like start of wr or end of wr - then its just a matter of getting them in/out to the wr_pi. same for others pi's like Squiddo (which I dont use so I cannot comment). So to have different classes of wp's is ok but invites an enhancement of the routing/wp manager and not a reinvention of the user interface of wp handling. - the @~~ naming convention seemed to me as being a pragmatic way to enable parallel developments of routingmngr and xx_pi's - thats why I suggested @wr~anyname.

To treat wr routes as tracks I find confusing, I would rather encourage a new entity : w_route which is the result of a calculation. Having then the option to compare different w_routes should be an essential benefit of any wr_pi. Here the user may then select his favorite w_route and import it to the route manager.

I'm with you on this. Weather routes are "routes" it is after all in the name. Other software creates routes and saves them as such, often with a unique naming style.

The advantage of routes is that:
You can tweak them by dragging the waypoints to match what you are actually doing or want to do on the water.

Routes can be saved shared, compared, deleted, etc..

Users coming from other software will find it more intuitive.

[rgleason]

Thanks Moo, for the vote.
Perhaps we should recognize skipperearly's observation:
1. Start and End WP have the same data as regular waypoints (and certainly can be handled by WP Manager but with some type of sort or filter to focus the WP's to whatever is being done "Routing" or "Weather_routing" (in this case)
2. The Optimal Route has important additional data including time, and could contain other data, such as wind, wave, pressure and other data. These data points could then provide tabular data for user review and understanding. I think this data does not fit well with WP Manager, but should be some other type of entity.

[rgleason]

If there is ever a WxPoint entity type with an extended data set including certain aspects of the predicted weather at that location and time, then it would be logical to have the Start WxP, End WxP and any (future) intermediate WxP remain in the WxP entity format.

Then there would be an import/export feature that would strip out excess data on export to route manager. or add the extended fields on import to WxRouting. WxRouting would have its own WxP entity type and database and use that exclusively.

Of course Sean is going to do what is best.


Right now I am wondering if there is a better way to get/store the needed weather data at a given WxP, such as perhaps use the Grib file that was used in the routing? But what happens if that is deleted, as it eventually is deleted. Then the informative Tabular view of the Optimal Route willl not have all the information needed.