See "Finding a Single Source of Truth" for some back-story.

I'm planning routes. And working with OpenCPN's planning capability. And my own NavTools planner.

I've found that we have some (minor) differences of opinion here.

Or.

I've been doing it wrong. (This is much, much more likely. Aircraft pilots and the FAA seem to have some specific regulations for this.)

Here's the concern.

Going from P0 to P1 to P2. The three waypoints are spanned by two legs: P0-P1, and P1-P2.

This isn't surprising: n waypoints have n-1 legs.

So far, so good? Here's a picture with some waypoints and legs.

When we print out the plan for a voyage, the convention is to list all the points once in the plan. That way, we don't repeat points among legs. In our example with two legs, P0-P1 and P1-P2, the P1 is repeated. Undesirable.

When we do the computation, of course, we're computing range, bearing, and estimated time enroute (ETE) for each LEG. Each point is used twice (once as departure and once as arrival) but only shown once.

This leads to an awkward "ugh" when we create a the schedule table.

One of the points in the table doesn't have any actual distance or time enroute (or bearing for that matter.)

My Approach (This May Be Bad)

My preference was to list each point with the range and bearing to the next point.

The final point didn't have a useful range or bearing because you'd arrived.

The OpenCPN Approach (This May Be A Standard)

I just noticed that OpenCPN includes a "fake" leg to the first point. This leg is from your current location. (This is expressly unhelpful when I'm here, planning a voyage that departs from Beaufort; the 600 mile first leg is wrong and misleading.)

For their planning table, each point is listed with the range and bearing to that point from either the previous point, or from the assumed starting point.

Ah.

This is a tiny algorithmic change. And a revision of a bunch of test cases.

Forward and Reverse Scheduling

While I'm fixing things, the other thing I need to do is to change how ETA's are computed.

Currently, I pick a departure time and add up the times enroute to compute ETA's at each waypoint.

It turns out, I sometimes need to pick an arrival time and work backwards through the times enroute to compute a planned time of departure (PTD) that will give me the desired ETA.

This surfaced when I started planning our Beaufort-to-Charleston run this fall.

The goal is to arrive at the entrance Charleston at 06:00.

When do we have to leave Beaufort? At 6 knots we need 32½ hours. That could mean leaving at 21:30, motoring until dawn and then sailing the next day and night.

While we can go faster than 6 knots, we're unlikely to beat this speed. We'd put a reef in if we had the kind of wind that could push us much past 7 knots. It's much more likely that we'll go slower, arriving later in the day, which is good.

This plan has to be computed backwards from the desired ETA. I don't have software for that. Yet.

We don't want to be too ignorant about this. We need to iterate a few times to work out a sensible combination of planned departures and estimated arrivals. This is a kind of spreadsheet where I need software that lets me plug in a number of assumptions and tweak the results until they look sensible.

In this case we might want to leave Beaufort at 18:00. While this could lead to a pre-dawn arrival in Charleston, we have several choices. One is to slow down a bit along the way. Or we can loiter outside Charleston waiting for sunrise. Another is to try to anchor by the Coast Guard station in the dark.

What's important is having the choices laid out in advance; that saves trying to think when I'm tired. Instead, we can look at one of the other pages of the plan for a bailout location.