A good route plan is thinking done in advance so it does not have to be done at the wheel-over, in the dark, with a tide setting you down onto a buoy. This is the real value of planning a passage on ECDIS: every decision you make calmly at the chart table is handed back to you, at the moment you need it, when the bridge is busy and there is no time to work it out. The plan is where the navigation actually happens. The execution is just following it.
But ECDIS route planning carries a seduction that paper never did. Run the automatic route check, see the reassuring message that no dangers were found, and it is tempting to believe the work is done. It is not. That green light is only as honest as the parameters behind it — and a reef lying just outside your cross-track corridor will not appear on the list, because the system was never asked to look there. What follows is the process done properly, step by step, so the check is telling you something true. It assumes you are working within the wider four stages of passage planning; this is the ECDIS mechanics of the planning stage itself.
Step 1: Set Up Before You Draw a Line
The most common planning error happens before a single waypoint is placed. The route check measures your route against the safety settings — the safety contour, safety depth, and the rest — so those values must be calculated for this voyage’s draught and entered first. A route checked against last voyage’s settings, or against the factory defaults, has been checked against the wrong ship.
Two other things belong to this setup. The correct Electronic Navigational Charts must be loaded and updated, with the right usage band for each phase of the passage — harbour and approach charts for pilotage, coastal and general for the open legs — because the route check interrogates the largest-scale data the system holds, and a missing large-scale cell is a blind spot. Only once the settings are right and the charts are in place does it make sense to start building the route, a relationship covered further in ENC vs RNC: Electronic Chart Types Explained.
Step 2: Build the Route — Waypoints and Legs
With the groundwork laid, you create the route itself. There are two ways to lay down waypoints, and most navigators use both: clicking positions directly onto the chart for speed and a feel for the geography, then opening the table editor to fine-tune each one to a precise latitude and longitude. The table is where a waypoint dropped at 38° 57.999′ becomes a clean 39° 00.000′, and where you catch a point placed a cable off where you meant it.
Each leg between waypoints then needs its parameters. The sailing type is set per leg — rhumb line for most coastal work, great circle where the saving on a long ocean passage justifies it, a choice explained in Great Circle vs Rhumb Line Sailing. Just as important is the planned speed for each leg, because that is what drives the estimated time of arrival at every waypoint, and those times are what let you plan a tidal window for a bar, a gate, or a berth. A route without considered leg speeds is a line on a chart; a route with them is a timetable you can navigate to.
Step 3: Shape the Turns
A line on a chart turns instantly at a waypoint. A ship does not. The next step is to set a turn radius, or wheel-over, for each course alteration so that the turn is actually achievable at the planned speed and a sensible rate of turn. ECDIS will calculate the wheel-over point from the radius you enter and display it as the turn approaches.
This is one of the places the system genuinely earns its keep, but it demands a check rather than blind trust. The calculated turn assumes nothing about the wind on your bow, the current under your stern, or how the ship handles in her loaded condition — and all three change where the turn really begins. Setting realistic turn radii during planning means that, at the alteration itself, the officer is handed a wheel-over point they can rely on instead of one they have to second-guess in the moment. That transfer of effort, from the busy bridge to the quiet chart table, is the whole point of planning the turns properly.
Step 4: Set the Cross-Track Corridor
Now comes the setting that most directly governs what the route check can see: the cross-track distance, or XTD — the width of the corridor either side of the planned track. The guiding principle is as wide as possible, as narrow as necessary. Too narrow and you will fight nuisance alarms every time the ship yaws; too wide and the corridor sweeps across hazards you never intended to go near.
The critical point — and the one that grounds ships — is that the route check only examines dangers inside this corridor. A charted reef fifty metres beyond your XTD is invisible to the check, however clearly it is drawn on the chart. This is why the XTD must be set per leg rather than once for the whole route: pilotage waters need a tight corridor matched to the channel, while open water can take a generous one, and using a single value for the lot either chokes the open legs or dangerously widens the confined ones. It is also why the corridor should account for the horizontal accuracy of the chart data itself — the CATZOC value — so that on poorly surveyed charts the corridor is wide enough to catch a danger whose charted position may be tens of metres adrift from the truth.
Step 5: Run the Route Check
With waypoints, legs, turns, and corridor in place, you run the automatic route check — sometimes labelled the safety check. The system scans the corridor along the entire route and lists everywhere your track or its margins cross the safety contour, enter a prohibited or cautionary area, pass an isolated danger, or cut a traffic separation scheme. Many systems go further and flag construction faults too, such as two waypoints in the same place or a turn that cannot be made at the planned speed.
Two habits separate a real check from a box-ticking one. First, set the display to show all layers — the ‘all other’ display category — because on some systems a danger detected by the check will not be drawn unless its layer is switched on, and an unseen danger is no better than an undetected one. Second, and more important, work through every alert individually. Each one is either a genuine hazard that forces you to amend the route, or a flag you can consciously accept with a reason — but it is a decision, not a notification to be cleared. The navigator who acknowledges the whole list with one keystroke has not checked the route; they have only silenced it.
Step 6: Add the Human Layer
The route check validates the line against the chart. It does not add the judgement that turns a safe line into a usable passage plan, and that judgement is the next step. This is where you mark the no-go areas, clearing bearings, and parallel-index lines that give you independent ways to monitor position; where you note abort points and contingency anchorages for the legs that have them; and where the under-keel clearance plan and the tidal gates are tied to specific waypoints and times.
None of this is generated for you, and none of it is optional on a well-found bridge. The ECDIS makes the mechanical parts of planning faster, but the contingency thinking — what I will do if the engine fails here, where I can turn around, the latest time I can pass this gate — is still the navigator’s to supply. The habits that prevent the most common planning oversights are collected in Common ECDIS Errors and How to Avoid Them.
Step 7: Validate, Save, and Get It Approved
The final step closes the loop. The route is validated, saved, and submitted for the master’s approval — because a passage plan is a berth-to-berth document the master signs off, not a private working file. Once approved, it is transferred to monitoring as the active route, ready to watch over the ship through the voyage.
It is worth knowing that most systems keep the planned route and the monitored route as distinct objects, so an edit made on passage does not silently rewrite the approved plan. From here the work shifts from building the route to watching the ship hold it, which is where the alarms, the look-ahead, and the cross-track monitoring take over — covered in ECDIS Route Monitoring and Alarms. Plan it well here, and monitoring becomes the calm confirmation it is meant to be rather than a scramble to catch what the plan missed.
Frequently Asked Questions
What are the steps of route planning on ECDIS? In order: set the safety settings and load the correct updated charts; build the route with waypoints and leg types; set achievable turn radii; set the cross-track distance corridor per leg; run the automatic route check and resolve every alert; add no-go areas, clearing bearings and contingencies; then validate, save, and obtain the master’s approval before transferring the route to monitoring.
What does the ECDIS route check actually check? It scans the cross-track corridor along the whole route against your safety settings and flags crossings of the safety contour, prohibited and cautionary areas, isolated dangers and traffic separation schemes. Many systems also detect construction errors and unachievable turns. It only checks within the XTD corridor, so dangers outside it are not detected.
What is cross-track distance (XTD) in ECDIS? The XTD is the width of the safety corridor either side of the planned track. It defines both how far the ship may deviate before an alarm and the area the route check interrogates. It should be set per leg — tight in pilotage waters, wider in open water — following the principle of as wide as possible, as narrow as necessary.
Why does the route check sometimes miss a charted danger? Because the check only examines hazards inside the cross-track corridor. A danger lying just outside the XTD, or on a large-scale chart not loaded in the system, will not appear on the list even though it is clearly charted. Setting the corridor to account for chart accuracy (CATZOC) reduces this risk.
Do I need to set safety settings before planning a route? Yes. The route check measures the route against the safety contour and related settings, so they must be calculated for the voyage’s draught and entered before the check is meaningful. A route checked against default or previous settings has been checked against the wrong parameters.