Weather Routing

[rgleason]

Yes that is right:

WR uses a virtual boat. If the calculations "complete", the result is a virtual track. We can export this virtual track and we get a real track in the OpenCPN Route Manager (RM) -Track TAB.

In RM track tab, select the new track, and select "Route from Track" to transform it into a route

=====
Problem,

The end-point in WR and the end-point in the route manager are different. This is not the same point.

Explanation:
When exporting the virtual track, the real track that appears in the track manager does not end at the end-point entered in WR. It ends at the last waypoint just before WR's End-point. In other words, the end of the virtual track miraculously disappears .....

This seems to me to be a BUG.

Very observant!

[rgleason]

Here is a new Beta Release
https://github.com/rgleason/weather_...tag/1.1103beta

Incorporates all Sean's, Stelian's FR.PO and Rick's Polar file changes, but not Hakan's PR which has two files that conflict.

[Gilletarom]

Hello,

Originally Posted by rgleason

Here is a new Beta Release
https://github.com/rgleason/weather_...tag/1.1103beta
.....

So this evening, I uninstall OCPN, clean correctly the PC and re-install all, using the WR release that is here juste before.

After that, I did some tests.

1 ° For example, I went from French to English and OCPN crash.
likewise, going back from English to French.
I note that this does not usually happen with NMSO. One of the plugins installed, must be involved.

2 ° In my tests, for several days, I made sure to adjust OCPN and its plugins in UTC time, wherever possible. Idem this evening.

I used a file with Wind and current from Skyron. Then, with the same starting and ending points that I used in my previous tests, I created a virtual track. Then I exported the virtual track, so a real track appeared in the route and track manager.

See screenshots to understand some settings.

The departure time in WR is 19.50 hours, ie 19h 30 minutes. The hourly step of the isochrones of 30 minutes.

I will have to see appear 19h 30, then 20 pm, then 20h 30 in the present hours in the real track of the track manager. Observe that the schedules that appear are totally different. It starts at 9 pm, then 9.30 pm and 10 pm, etc.

In other words, despite all my settings for everything to be in UTC, the schedules here are in UTC +1.

This is certainly a bug that I observed during all my tests with this version of WR and with previous versions.

[rgleason]

Gille,
1. Fr --> English ---> Fr Crashes ... One of the plugins installed, must be involved.
I think it is Weather_Routing because we are not setup to use Hakan's new naming system, in particular FR.po and ENG.po. This should resolve once we get the Hakan's PO and POT changes merged, but there are two confilcts FR.PO and POT.

2. I think Stelian or Sean would be very interested in this problem. Thank you.

[Gilletarom]

Hello Sean, Hello All,

In this post, it's not about reporting a bug. I wish to express a request for improvement.

I specify in advance that I do not know if this improvement depends on WR, so Sean and developers working around WR like RGleason, Stelian and Didier.
It is possible that this improvement depends on OCPN and Bdbcat. But perhaps, RGleason, Stelian or Didier can work about this.

WR Creates a virtual track. We can export this track and we get in the Track manager a real track.

In the real track, for each track segment, there is the supposed speed of the boat. For example 6.5 knots in the first segment, then 4 knots in the second segment, etc.

We can then transform this real track into a real route in the Routes and tracks manager.

But, when you do that, you lose the supposed speed of the boat on each segment of the route.

Would it be possible to keep, for each segment of the real route, the expected speed on the segment in question, a speed that is available in the real track. So, for example, 6.5 knots in the first segment of the route, 4 knots in the second segment of the route, etc.

??????

[Gilletarom]

Hello RGleason,

Originally Posted by rgleason

Gille,
1. Fr --> English ---> Fr Crashes ... One of the plugins installed, must be involved.
I think it is Weather_Routing because .....
.....

I uninstalled Draw and reinstalled the latest version of Draw that you compiled. Now I have no more crashes when changing language. It was probably the last tests with Draw who put "the bazaar".

[rgleason]

There is a new BETA update for Weather_Routing

https://github.com/rgleason/weather_...tag/1.1104beta

Please follow the instructions carefully to install into a fully "Clean" environment with no "Weather_routing" or "weatherrouting" references

New FR.po and Pot from Stelian.
Improved TWS polar files for the example.


@Gillatarom Did you mean Ocpn_Draw or WxRte below?

[Gilletarom]

RGleason,

Originally Posted by rgleason

.....

@Gillatarom Did you mean Ocpn_Draw or WxRte below?

Sorry, this best to read for you :
http://www.cruisersforum.com/forums/...ml#post2541690

[rgleason]

Thanks Gille. Will look.

I just realized the fr.po update is from Stelians PR 3 days ago. We still have the next step which is to resolve the conflicts with Hakan's files. See this comparison.
My repos is the same as Sean's now.

https://github.com/rgleason/weather_...ansv:po_update
We need a little instruction from someone....

@Hakan Do we just have to rename the Fr.po to mimic the others and then upload to Crowdin?
I assume you've updated the new POT on crowdin and that is current. Does it matter if it is not current? Should we upload the newly renamed Fr.po anyway?

[stelian]

Ignore the PR from Hakan.

Now that the pot file is up-to-date in Sean's github, I have asked Hakan to pull again and put the new pot file into Crowdin.

[stelian]

Hakan has canceled his PR and updated the pot file (master file containing the strings to be translated).

Everything is set up in Crowdin for translators to work !

As for the french translations, everything is done in Crowdin, there are just 3 or 4 strings modified wrt Sean's repo, they will get pulled when Hakan will make a PR later.

Merry Christmas to everyone !

Stelian.

[rgleason]

Gille, very good summary. I'll use some of it in wiki.

Would it be possible to keep, for each segment of the real route, the expected speed on the segment in question, a speed that is available in the real track. So, for example, 6.5 knots in the first segment of the route, 4 knots in the second segment of the route, etc.

I am not sure the Route/Leg database record includes average time on a given leg or even average speed. It it does, then perhaps something can be done. Of course the Route/leg db could be expanded but that is a bigger job. I think the way to really find out is to look carefully at navobj.xml and actually see what parameters are available in the record.
I don't have time now. Perhaps you can?

I am afraid the role of a route is as a future plan, but so far we can enter and average speed to get ETA and see ETA Planning Now, ETA Planning Now from Intermediate WP, During Passage
https://opencpn.org/wiki/dokuwiki/do...mark_manager&s[]=route&s[]=eta

[rgleason]

It looks like there is a Time field in the Route - Leg record, so it is possible Gillatarom, I think.
By adjusting Date time for each leg, you essentially have speed for each leg (with some calcs).

Navobj.xml Database

Typical Waypoint header and record
<wpt lat="42.652376279" lon="-70.156319036">
<time>2017-07-09T15:15:40Z</time>
<name>002</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>74f0ffff-0bac-47b0-a016-36186d30ffff</opencpn:guid>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
</extensions>
</wpt>


Typical Track header and record]

<trk>
<name>MHOR rtofs+coamps</name>
<extensions>
<opencpn:guid></opencpn:guid>
<opencpn:viz>0</opencpn:viz>
<opencpn:style width="3" style="103" />
<gpxx:TrackExtension>
<gpxxisplayColor>Green</gpxxisplayColor>
</gpxx:TrackExtension>
</extensions>
<trkseg>
<trkpt lat="42.496200000" lon="-70.795870000">
<time>2017-06-12T13:00:00Z</time>
</trkpt>
</trkseg>
<trkseg>


Typical Route Header and Record

<rte>
<name>MHOR RTOFS+GFS-6-11-1200newrtofs</name>
<extensions>
<opencpn:guid>38250000-4114-4536-88f3-1d5809c50000</opencpn:guid>
<opencpn:viz>0</opencpn:viz>
<opencpnlanned_speed>6.00</opencpnlanned_speed>
<opencpn:time_display>PC</opencpn:time_display>
<opencpn:style width="3" style="102" />
<gpxx:RouteExtension>
<gpxxisplayColor>DarkBlue</gpxxisplayColor>
</gpxx:RouteExtension>
</extensions>
<rtept lat="42.496200000" lon="-70.795870000">
<time>2017-06-12T09:03:35Z</time>
<name>001</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>1f6c0000-ef1d-441d-9e82-7f822c5e0000</opencpn:guid>
<opencpn:auto_name>1</opencpn:auto_name>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
</extensions>
</rtept>
<rtept lat="42.537111274" lon="-70.694663812">
<time>2017-06-12T09:03:35Z</time>
<name>002</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>7deaffff-238e-412e-9227-391e37670000</opencpn:guid>
<opencpn:auto_name>1</opencpn:auto_name>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
</extensions>
</rtept>
<rtept lat="42.586632130" lon="-70.591983799">
<time>2017-06-12T09:03:35Z</time>
<name>003</name>
<sym>diamond</sym>
<type>WPT</type>
<extensions>
<opencpn:guid>5a8cffff-38f8-426a-9b97-e16d053e0000</opencpn:guid>
<opencpn:auto_name>1</opencpn:auto_name>
<opencpn:arrival_radius>0.050</opencpn:arrival_radius>
<opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
</extensions>
</rtept>

[rgleason]

Sean, Stelian42, Did-g,

Compiled a new version and tested (PR#4 & PR#5) but not Did-g Grib change because it requires a change in PI API. (Did-g can I merge it?)

I found the Export now works properly. And I am attaching two shots for Stelian to see where my screen resolution needs a little adjstment to layout.

Merge pull request #4 from stelian42/fix-dialog-layout
Fix configuration dialog layout

Basic TAB Time Interval needs more space for Text.



(This does not show the second layout change.)

[rgleason]

Beta 1.1105 is availale
https://github.com/rgleason/weather_...tag/1.1105beta