Weather Routing

[seandepagnier]

I am not worn out with these. Actually the windows bugs are trivial, I just have no way of knowing about them unless reported. Should be fixed in git now.

[rgleason]

boat_Alexandra

Tried a compile, significantly fewer, hope you can fix them. Thanks!

[George64]

Very nice!

Read the whole thread. Is there a download available for those not famililar with compiling etc.? Would like to give it a try, however I don't have development envorinment setup....

[seandepagnier]

Originally Posted by rgleason

boat_Alexandra

Tried a compile, significantly fewer, hope you can fix them. Thanks!

looks like problems because I am on wx-2.9 and this doesn't work on 2.8.. gah... ok I'm fixing these as well. Thanks for the feedback.

[rgleason]

Is there a download available for those not familiar with compiling etc.? Would like to give it a try, however I don't have development environment setup....

George64 Look at the Development Environment Thread (for Windows) Post #114 also the Developer Manual -Compiling Windows. It's a process but Hakan just did it successfully.

[rgleason]

Boat_alexandra Please let me know when to git clone... Thanks.

[seandepagnier]

You could try now, it should be closer

[cagney]

I get this error when running Cmake. I just this minute pulled git.

-- Writing spec file...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GCOV_LIBRARY
linked by target "weather_routing_pi" in directory /home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi

-- Configuring incomplete, errors occurred!

[rgleason]

Boat_alexandra - please see attached... almost!

cagney - are you on sean's branch? It a separate branch for special grib_enhancements. (...git clone ...git checkout) look at post above. Then you git clone the weather_routing_pi Thanks for helping.

[cagney]

Originally Posted by cagney

I get this error when running Cmake. I just this minute pulled git.

My Ubuntu amd 64 12.10 is a bit differen. Problem solved by changing line 129 in the routing plugins CmakeList.txt

#    /usr/local/lib/gcc/i686-pc-linux-gnu/4.7.0
    /usr/lib/gcc/x86_64-linux-gnu/4.7.2/

Compiling I got as far as this

[ 59%] Building CXX object plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/src/BoatDialog.cpp.o       
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp: In member function ‘virtual void BoatDialog::OnOpen(wxCommandEvent&)’:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:325:74: error: no matching function for call to ‘Boat::OpenXML(const wxCharBuffer)’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:325:74: note: candidate is:
In file included from /home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:37:0:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:35:14: note: wxString Boat::OpenXML(wxString)
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:35:14: note:   no known conversion for argument 1 from ‘const wxCharBuffer’ to ‘wxString’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp: In member function ‘virtual void BoatDialog::OnSave(wxCommandEvent&)’:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:369:74: error: no matching function for call to ‘Boat::SaveXML(const wxCharBuffer)’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:369:74: note: candidate is:
In file included from /home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:37:0:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:36:14: note: wxString Boat::SaveXML(wxString)
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:36:14: note:   no known conversion for argument 1 from ‘const wxCharBuffer’ to ‘wxString’
make[2]: *** [plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/src/BoatDialog.cpp.o] Error 1
make[1]: *** [plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/all] Error 2
make: *** [all] Error 2

[George64]

Originally Posted by cagney

My Ubuntu amd 64 12.10 is a bit differen. Problem solved by changing line 129 in the routing plugins CmakeList.txt

#    /usr/local/lib/gcc/i686-pc-linux-gnu/4.7.0
    /usr/lib/gcc/x86_64-linux-gnu/4.7.2/

Compiling I got as far as this

[ 59%] Building CXX object plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/src/BoatDialog.cpp.o       
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp: In member function ‘virtual void BoatDialog::OnOpen(wxCommandEvent&)’:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:325:74: error: no matching function for call to ‘Boat::OpenXML(const wxCharBuffer)’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:325:74: note: candidate is:
In file included from /home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:37:0:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:35:14: note: wxString Boat::OpenXML(wxString)
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:35:14: note:   no known conversion for argument 1 from ‘const wxCharBuffer’ to ‘wxString’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp: In member function ‘virtual void BoatDialog::OnSave(wxCommandEvent&)’:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:369:74: error: no matching function for call to ‘Boat::SaveXML(const wxCharBuffer)’
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:369:74: note: candidate is:
In file included from /home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/BoatDialog.cpp:37:0:
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:36:14: note: wxString Boat::SaveXML(wxString)
/home/thomas/Testing/GitHub/Grib-dev/OpenCPN/plugins/weather_routing_pi/src/Boat.h:36:14: note:   no known conversion for argument 1 from ‘const wxCharBuffer’ to ‘wxString’
make[2]: *** [plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/src/BoatDialog.cpp.o] Error 1
make[1]: *** [plugins/weather_routing_pi/CMakeFiles/weather_routing_pi.dir/all] Error 2
make: *** [all] Error 2

And you want to put a non-programmer into this Rather hope there will be an exe or dll available

[PjotrC]

In the past 12 months I had sailed 15000 miles, coming online usually for minutes only, so I am not up to date with current development, specifically not with with the plugins discussed here. However, most of the time I was solving some kind of weather routing problems, often interesting ones, using OpenCPN. Maybe my experience can be relevant to this nice work in the future... As I keep all my GRIBS and tracks I sometimes play with the idea of writing up a relaxed post-analysis, but this is still a little distant. So, for now just some cruiser's notes. For planning I was using my custom OCPN 2.5.1318 and - when I had time - QtVlm and sometimes BlueWater Racing. Two observations here:

1. Before sailing out of the harbour (and out of the Internet range) the question almost always was not what route to take, but when to leave. The planned route was invariably defined by many aspects, but never directly by local speed under sail. The local speed uder sail along the otherwise defined route was indeed a factor for deciding whether to go now or to wait.

2. I made practically no use of the polar diagram for my boat and no use at all of the isochrone-driven planning. Although these obvious capabilities are hard to drop from specifications, they should not heavily influence the user interface and overall footprint. I was quite happy with with just a daily estimate of miles sailed.

I was surprised to see how little time we had for decisions when leaving the ports before several hundred mile passage. Originally, I imagined that loose integration with tools like QtVlm by exporting/importing waypoints and routes would be sufficient for planning, but in reality we often were so hard pressed by various activities and timetables, practicalities of Internet access etc. that every mouseclick and every data item to enter was a real pain. We often needed decisions in minutes after getting back to the anchorage with the newest GRIB brought from shore on a portable drive...

Today, I think the key issues are the following:

- What I use most is the GRIB-based simulation of weather expected along a defined route, so just a couple of extra columns in the Route Properties dialog, showing the GRIB values for wind/precipitation is quite sufficient. The isochrones are a useful extra comment, but the real route seldom does follow them.

- What I miss most is the global currents model. Although my 2.5.1318 does handle sea currents in GRIB format (if included in the same GRIB with wind data), I do not have the GRIBs for sea currents in general. Such GRIBs exist and are included as monthly files e.g. in the Raymarine Raytech Navigator, but I do not know if similar data is available in the public domain. Also, I would not know how to combine the fixed sea currents data GRIB with the momentary wind forecast GRIB (Bluewater Racing can use simultaneously many separate GRIB files, a very neat feature)

- The manipulation of Departure Time for a given route plan should be as simple as viewing the next GRIB record in most GRIB viewers. Therefore the "Now", "+1 Day" and "+3 Hours" buttons in 2.5.1318. I miss sometimes the "-1 Day" and "-3 Hours", but there was no space in the dialog panel for these.

The GRIB-based route planning (wind, currents, precipitation) is extremely useful for practical cruising. I look forward to using this.

Fair winds,

Piotr

[cagney]

Piotr
Nice to see you back again.......
Ocean currents are available, but far from straight forward to use as they different models don't agree....
More here David Burch Navigation Blog: A Comparision of Ocean Current Models

Thomas

[rgleason]

Very interesting comparison of current gribs.

The idea of being able to either merge grib data or to load and show two gribs would be very useful because Current and Sea Temp tend to be separate.

I respect PjotrC's perspective of keeping it very simple or having that opportunity due to other distractions while sailing. I believe Sean has experienced use of his plugins around NZ, so I am sure he has a good sense of this aspect.

[seandepagnier]

Originally Posted by cagney

I get this error when running Cmake. I just this minute pulled git.

Yes.. oops I forgot I was using gcov for profiling and kind of hacked it in. I should switch the cflags back before committing. Then the other errors are due to me using wx-2.9 (which gives me much better data on asserts) and also handles strings easier.. but to make it work with 2.8 I need to deal with these issues again. I should just compile with 2.8 I suppose.

Originally Posted by George64

And you want to put a non-programmer into this Rather hope there will be an exe or dll available

eventually...

Originally Posted by PjotrC

... Two observations here:

1. Before sailing out of the harbour (and out of the Internet range) the question almost always was not what route to take, but when to leave. The planned route was invariably defined by many aspects, but never directly by local speed under sail. The local speed uder sail along the otherwise defined route was indeed a factor for deciding whether to go now or to wait.

Yes, I agree completely with this. I didn't really think about it much though. Currently this is not well supported, but you could run the algorithm, then try again at a different start time and compare the results.

Maybe eventually I could have you select a time span and step to compute, and then give you results for various departure times.

2. I made practically no use of the polar diagram for my boat and no use at all of the isochrone-driven planning. Although these obvious capabilities are hard to drop from specifications, they should not heavily influence the user interface and overall footprint. I was quite happy with with just a daily estimate of miles sailed.

I can see what you mean for most sailing directions, but for beating it is different. The polar diagram can basically take care of this.

I was surprised to see how little time we had for decisions when leaving the ports before several hundred mile passage. Originally, I imagined that loose integration with tools like QtVlm by exporting/importing waypoints and routes would be sufficient for planning, but in reality we often were so hard pressed by various activities and timetables, practicalities of Internet access etc. that every mouseclick and every data item to enter was a real pain. We often needed decisions in minutes after getting back to the anchorage with the newest GRIB brought from shore on a portable drive...

Right well.. I am still not even on step one, but eventually reducing user interaction is a key goal.

Today, I think the key issues are the following:

- What I use most is the GRIB-based simulation of weather expected along a defined route, so just a couple of extra columns in the Route Properties dialog, showing the GRIB values for wind/precipitation is quite sufficient. The isochrones are a useful extra comment, but the real route seldom does follow them.

Well in that case, it should be possible to just have the program use a defined route, at different times and give results (like wave height and winds along the way.. how much is beating.. how long it takes). This would be much faster to compute as well.

- What I miss most is the global currents model. Although my 2.5.1318 does handle sea currents in GRIB format (if included in the same GRIB with wind data), I do not have the GRIBs for sea currents in general. Such GRIBs exist and are included as monthly files e.g. in the Raymarine Raytech Navigator, but I do not know if similar data is available in the public domain. Also, I would not know how to combine the fixed sea currents data GRIB with the momentary wind forecast GRIB (Bluewater Racing can use simultaneously many separate GRIB files, a very neat feature)

I have the oscar satellite current data in netcdf format I was going to integrate with the climatology plugin and eventually then be able to use with weather routing. The resolution is not great, and localized currents are not well described. The new grib plugin should be able to use different grib files for current and wind.

Another thing to note, is sea currents are changeable, and if you have information like water temperature and other data, you can predict this to some extent. If anyone has interest in this area, it would be great to work on.

Another key thing is to look at past weather patterns, and with a database, given 3 days of gribs, it would be possible to extrapolate and give some idea of what the future week may be like.

- The manipulation of Departure Time for a given route plan should be as simple as viewing the next GRIB record in most GRIB viewers. Therefore the "Now", "+1 Day" and "+3 Hours" buttons in 2.5.1318. I miss sometimes the "-1 Day" and "-3 Hours", but there was no space in the dialog panel for these.

The GRIB-based route planning (wind, currents, precipitation) is extremely useful for practical cruising. I look forward to using this.

Fair winds,

Piotr

How do you suggest I use precipitation? You want it to fill up water tanks?