Web Hosting

Free Ads




Our World 2.0







Routing 5 of 7 : Algorithms

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!

MaxSea - route1 MaxSea - route2
Fig1 Fig2
b) Fine tuning of instrument or other inputs
Racing crews will be used to making adjustments to the various inputs being read by the software and will know their boat; their sails and the performance required. The fine tuning capabilities are very strong on the Table A and Table B systems listed – but very likely of little use for the amateur sailor except in terms of experimentation. This is where the “education” part comes in rather than the really useful functionality.
As with many technical systems – its nice to have dozens of switches and adjustments but it may take years before you really understand what they do! It should also be noted that the quality of instruments and their state of repair on the average cruising yacht will be far more of a factor than fine tuning the software. Still its all good stuff and we probably all like to twiddle with the knobs and see what they do 🙂
c) Quality of data being input e.g. weather; weather plus tidal streams; weather plus tidal streams plus seat state
This has already been discussed in a previous post on data inputs. I would think that this is an area where data quality and accessibility – for example of GRIB file data – will improve by leaps and bounds over the years – until the data is can be received by all sailing vessels as easily (or not) as radio – without you having to be aware of where it is coming from. There is some effort being put into a set of standards for this type of data so that we can be sure that data being supplied meets certain international standards.
d) Obstacle avoidance
Another critical issue is obstacle avoidance. With Coastal Explorer although it doesn’t calculate otimal routing as you insert waypoints, the system highlights rocks, shallows, or buoys near or under your route legs, and can also warn you of dangers ahead even if you’re not on a route. All of the systems in Table A and B allow for the insertion of waypoints that the route must comply with and “exclusion zones” that the user can define for the route to avoid – this is the most common method of coping things like drying land, exposed rocks and wrecks and so on.


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.


Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>