Weather Routing

[did-g]

Originally Posted by skipperearly

Maybe others also want to vote for this : https://opencpn.org/flyspray/index.p...s&task_id=2340

I cannot get used to this unorthodox coordinate formatting/handling.

I'll look at formatting.

With the latest WR you can select O waypoint.

Open WR then right click on an OpenCPN waypoint there's a new menu line:
'Weather Route Position', the link is live if you move the WP it move in WR an invalidate computed route. If you delete it, it still in WR.


Same for a route, select a route and you can compute speed along it. Currently it computes only on route's WP, I want it to compute either with user time step or on grib time step.

It still a WIP and the UI is not great.

[rgleason]

Originally Posted by did-g

I'll look at formatting.

With the latest WR you can select O waypoint.

Open WR then right click on an OpenCPN waypoint there's a new menu line:
'Weather Route Position', the link is live if you move the WP it move in WR an invalidate computed route. If you delete it, it still in WR.

Same for a route, select a route and you can compute speed along it. Currently it computes only on route's WP, I want it to compute either with user time step or on grib time step.

It still a WIP and the UI is not great.

Didier, these two problems are somewhat related, but different, and it might help to consider these too, for the bigger context. Look at this post in Tracker please: http://www.cruisersforum.com/forums/...ml#post2893982


We need a good way to copy and paste lat / long without formatting problems. IE: keep the format issues at the background, maybe always copy and paste in a single format? IE: Use decimal degrees always throughout the program???!! Otherwise user errors can occur! Then just show the lat long as the user has selected? --or is this too limiting? Maybe even have Degree + Decimal min and D+M+S entries that automatically convert to Decimal Degrees?

What is the native format for lat long that OpenCPN uses? My bet is it is decimal degrees, and if it is, why not use that for all copy and paste of lat long?

Unfortunately these things affect the entire program and many plugins.
Would really appreciate your thoughts on this problem.

[.Paul.]

Originally Posted by rgleason

. . .

We need a good way to copy and paste lat / long without formatting problems. IE: keep the format issues at the background, maybe always copy and paste in a single format? IE: Use decimal degrees always throughout the program???!! Otherwise user errors can occur! Then just show the lat long as the user has selected? --or is this too limiting? Maybe even have Degree + Decimal min and D+M+S entries that automatically convert to Decimal Degrees?

Weather Routing pi does restrict Lat and Lon entries to degrees with a decimal fraction.

Many (probably most) of the OpenCPN dialogs accept Degrees with a decimal fraction, or Degrees and Minutes with a decimal fraction (of minute), or Degrees and Minutes and Seconds (this probably takes a decimal fraction). The Lat and Lon may be entered with a minus sign for South or West (or use N, S, E, W).

The (right click) "Center View" dialog takes all of the variations in the previous paragraph, and it can fill in its Lat and Lon fields with text from the clipboard.

These input capabilities should not be "simplified" to a single format.

The OpenCPN's output formats are mostly Degrees and Seconds with a decimal fraction. The WR_pi does use Degrees with a decimal fraction, but it has used the right click menu to "read" the Lat and Lon for the cursor position for a long time.

Did-g just added the capability of using the right click menu to import an existing waypoint's Lat and Lon into WR. Very nice!

Paul

[rgleason]

.Paul


This is news to me. I have not seen any PR's related to this. It would be wonderful if there are consistent known results for this, but we have a critical SAR_pi plugin that is actually dangerous due to possible user error related to lat/long format.

Have you possibly tested these features extensively with Opencpn alone and with plugins such that we know that lat/long is always represented properly?

I find that your writing seems to indicate somewhat anecdotal experience while using the program. No problem with that, but the consistency of these operations is critical.

Additionally I have not seen a detailed summary of how lat/long in all formats is handled when copying and pasting in all the situation needed. So I have no schema or standard to know if it is working or not. Previously, I have suggested and asked for a strategy (and programming) to deal with this problem, but heard nothing about it in reponse. Therefore I doubt that a "system" is actually working.

Also, what is "Degrees and Seconds with a decimal fraction" ?

[.Paul.]

Originally Posted by rgleason

. . .

Also, what is "Degrees and Seconds with a decimal fraction" ?

That "Degrees and Seconds with a decimal fraction" is my error. I should have typed "Degrees and Minutes with a decimal fraction (of minutes)."

I have not looked into the SAR plugin.

Paul

[rgleason]

Originally Posted by .Paul.

That "Degrees and Seconds with a decimal fraction" is my error. I should have typed "Degrees and Minutes with a decimal fraction (of minutes)."
I have not looked into the SAR plugin.
Paul

Thanks, thought so. This is a complex subject.

I would really like to know exactly how [what format] lat/long is transferred to and from when using "copy" and "paste".

1. Is there an input routine, which infallibly anticipates exactly what format is being used?
2. Is there always a single format being use IE "Decimal Degrees" when using copy, so that whenever there is a "Paste" the plugin or receiving app or component automatically "knows" it is in "Decimal degrees"?
3. Is there an interpretive routine which uses the underlying "Decimal Degrees" to always show the Lat / Lon in the format desired?
4. For manual entry of coordinates is their adequate range checking, etc?
5. What is the system being used now?
6. For whatever system that is being used, is this system universally used and enforced such that we always get consistent results and users don''t screw up!
7. What plugins, components and transfers of lat/long information do not follow this "system"? - so they can be fixed.

The most simple "system"

D.dddddd -----> D.dddddd

D M.mmmmm -----> D M.mmmmm

D M S ----> D M S

Another System that may not show all cases needed

D.dddddd -----|

D M.mmmmm -|----->D.dddddd ----->| Input : Then convert back to the format needed.

D M S --------|




Once the "system" is exposed, there should be some standard routines (code) that all plugin authors can use so that we are assured the operations work correctly.

[rgleason]

Sean has merged a large improvement in Route Analysis and display from Didier.
I will be getting that into the opencpn page download, shortly, but you can try it out here in Appveyor Artifacts tab:

https://ci.appveyor.com/project/sean...6357/artifacts

The discussion is here in Didier's github PR for those interested.

https://github.com/seandepagnier/wea...ng_pi/pull/249


Once again, Thank you Didier!

[did-g]

Originally Posted by rgleason

Thanks, thought so. This is a complex subject.

I would really like to know exactly how [what format] lat/long is transferred to and from when using "copy" and "paste".

1. Is there an input routine, which infallibly anticipates exactly what format is being used?
2. Is there always a single format being use IE "Decimal Degrees" when using copy, so that whenever there is a "Paste" the plugin or receiving app or component automatically "knows" it is in "Decimal degrees"?
3. Is there an interpretive routine which uses the underlying "Decimal Degrees" to always show the Lat / Lon in the format desired?
4. For manual entry of coordinates is their adequate range checking, etc?
5. What is the system being used now?
6. For whatever system that is being used, is this system universally used and enforced such that we always get consistent results and users don''t screw up!
7. What plugins, components and transfers of lat/long information do not follow this "system"? - so they can be fixed.

The most simple "system"

D.dddddd -----> D.dddddd

D M.mmmmm -----> D M.mmmmm

D M S ----> D M S

Another System that may not show all cases needed

D.dddddd -----|

D M.mmmmm -|----->D.dddddd ----->| Input : Then convert back to the format needed.

D M S --------|



Once the "system" is exposed, there should be some standard routines (code) that all plugin authors can use so that we are assured the operations work correctly.

Copy and paste uses whatever you've copied and heuristics. Of course trying to be smart it can fail badly.



I made a PoC and chain sawed code from O in WR, now it's using user choice for displaying position and use the same logic than waypoint and center view dialog


https://ci.appveyor.com/project/did-...uild/artifacts

[rgleason]

Didier, I see you are stilll working on it. Will try later. Thank you!

[rgleason]

Windows ov50 version for Weather_Routing has been updated and incremented based on Didier's many changes and improvements to routing. See the downloads page.

[scud]

Am i the only one that has the graph plot for weather-routing flickering and glitching ? I can see the same problem on 2 different notebooks WIN10 and W-R updated to the latest release too. Same issues with the 1.31 anyway.

[AedanC]

Originally Posted by scud

Am i the only one that has the graph plot for weather-routing flickering and glitching ? I can see the same problem on 2 different notebooks WIN10 and W-R updated to the latest release too. Same issues with the 1.31 anyway.

I see that too, also on two systems.

[rgleason]

This isn't going to help much, just get you worked up, but no flicker.
Here is yet another routing.
Questions: OS, Computer, O version, Wx-R version, opengl on?

Provide: all the stuff in the top of the FAQ, screenshots, ini, log, etc. I am serious about that. Also graphics card, when your drivers were updated.
https://opencpn.org/wiki/dokuwiki/do...s_listed_above


Sorry, but that is what the team needs to help.

[scud]

Originally Posted by rgleason

This isn't going to help much, just get you worked up, but no flicker.
Here is yet another routing.
Questions: OS, Computer, O version, Wx-R version, opengl on?

Provide: all the stuff in the top of the FAQ, screenshots, ini, log, etc. I am serious about that. Also graphics card, when your drivers were updated.
https://opencpn.org/wiki/dokuwiki/do...s_listed_above


Sorry, but that is what the team needs to help.

OS-> WIN 10

Computer -> it occurred in two separate ones
an HP notebook " HP G62-144DX Notebook PC"
and then
2COM RS232 FANLESS MINI PC CON 4 USB3.0, INTEL CORE I3 I5 I7 CPU DUAL CORE

WIN10 had been updated fresh in both cases

the WR was in both cases the latest release 1.13.1-ov5.0 bat also the former release had hte same issue.

regarding the log file I can only do that later from home

[scud]

Anyhow it occurs also on my office notebook with WIN-7 and OPENCPN 5.0
forgot to mention that OPENGL is on in all cases.
Here I can attach the log file but I dunno' how to