At last we come to the heart of the issue at hand, the optimal routing algorithm.
This is where the software must now manipulate:
- The planning criteria such as waypoints, arrival time, departure times and so on
- Real time instrument data, and any fine tuning parameters stored by the user eg. True wind adjustments
- Boat characteristics and polars either general or specific to the boat
- Tidal stream data both general from charts and specific based on local knowledge or higher quality data from the supplier
- Weather data both actual and forecast
- Collision avoidance such as AIS, MARPA, charted obstacles, user defined areas.
Not to mention the job of outputing data to instruments and to the user via a suitable user interface that makes understanding as well as user response easy and relevant.
Quite a feat of programming !
As far as I could see there appear to be two types of calculation and each with a number of proprietary “fine tuning” adjustments.
The systems listed will deal with the following dimensions of the problem to varying degrees:
a) Method of calculating the optimal route
b) Fine tuning of instrument or other inputs
c) Quality of data being input eg. weather; weather plus tidal streams; weather plus tidal streams plus seat state
d) Obstacle avoidance
a) Method of calculating the optimal route
There appear to be two methods of calculating the optimal route – the “Isochron Method” as advocated by Brice Pryszo (MaxSea), and the “Local Knowledge” method -advocated by Dave Brayshaw (Advantage)
A must read is the the Seahorse article published by David Brayshaw. It is a rather poor reproduction but it is still worth reading carefully.
Dave is the author of the Advantage Racing Software, so he is not a disinterested party, but he does try to explain the difference between his LK approach and the “Isochron” approach best represented by Brice. I cannot reproduce his article here, but is well worth reading – if only to see that there are completely different ways to calculate an optimal route. The Isochron approach is used by Deckman, MaxSea, SeaPro and Expedition amongst others.
With the MaxSea version of the isochron approach you are asked to set an isochron interval e.g. 1hour. This interval determines the distance between points (later to be converted to waypoints) along an optimal course. When MaxSea calculates a route, it starts by taking this interval and determines where your boat could be based upon the wind/current forecast at that point in time and the performance characteristics of your boat, using the polar diagram for your boat.
In other words, if you specify for example, a one-hour isochron interval, then MaxSea does the following:
1. Analyzes the weather forecast and sea state conditions at that point in time
2. Analyzes the performance characteristics of your boat using its polar diagram
3. Calculates the answer to the following mathematical problem:
“Given the strength and direction of the current, and speed and angle of the wind as well as this boat’s ability to sail at various wind angles and speeds, where can I be one hour from now.”4. It does this for every one-hour interval.
For each interval, MaxSea calculates all possible combinations using each theoretical point as the next starting point
Of course, the route calculated may not necessarily be one that can actually be sailed – see fig1. below. You will have to figure out how to sail it. The route shown is for an isochron interval of 3 hours and shows that the route calculated is only 3 degrees off the wind, so clearly you have to tack to follow it.
By shortening the isochron interval then the route will show more detail as in fig2. This together with the layline display mentioned before, would give a sailable route. Racing software (TableA) and sophisticated systems like MaxSea and SeaPro go further and will also calculate recommended port and starboard tacks duration of tack and so on – you still have to sail it however – the marine environment has am annoying habit of not doing what it was expected to do!
The output from SeaPro is shown above. This screen shot shows that alternate routes are given; an exclusion zone is taken account of; and a general wind indicator is shown for each leg of the voyage.
It should also be noted that the available bathymetric data, while looking really good on the latest 3D displays, is not actually precise enough in some supplier’s opinions, for accurate and automatic obstacle avoidance. In other words the software can automatically avoid charted obstacles or dangers but over reliance on this level of automation may well be a step too far at the moment. Bathymetric data needs to get more up to date and position accurate – not to mention methods of accurately marking moving obstacles like sand bars!
The sharing of bathymetric data by the US Navy with Google (amongst others) – as previously mentioned on this blog – will improve matters over the coming years I am sure. As will the emergence and use of functions like the PBG (Personal Bathymetric Generator) as demonstrated in the MaxSea software.