Your First Weather Route
A complete step-by-step walkthrough from GRIB data to optimized route
Stage 1 — Create a Routing
Everything starts with two points on the chart and a loaded GRIB file. Right-click on the chart where you want your departure to be and select Mark > Create a POI from the context menu. Name it something obvious — 'Start' works fine. Do the same at your destination. These two POIs are the anchors the routing algorithm uses; without them, it has nothing to compute between.
Now right-click on your start POI and choose Routing > Create a Routing. The routing creation dialog opens with several important settings. First, uncheck "Routing from boat" — this option forces the routing to begin from your boat's current GPS position, which is useless if you are planning days or weeks ahead from a computer on shore. Next, enable "Keep Starting Date" so qtVlm uses the exact date and time you specify rather than recalculating from the current moment every time you recompute.
Set your start date and time to coincide with the beginning of your GRIB data. If your GRIB starts at 00:00 UTC on March 20th, set that as your departure time. Slide the "Automatic parameters" slider all the way to "Best accuracy" — this uses the smallest time steps and the densest isochrone grid the algorithm supports, giving you the most precise result at the cost of slightly longer computation time. Finally, click Compute. The algorithm will grind through the GRIB data, your polar diagram, and the chart geometry, then paint a fan of isochrones radiating outward from your start POI.
If the computation completes successfully, you will see colored isochrone lines spreading across the chart from the start point toward the destination. The result panel shows the estimated time of arrival (ETA) and total passage duration. If nothing appears — no isochrones, no route line — something is wrong. Check that your GRIB file covers the entire geographic area and time span, that a valid polar file is loaded, and that the start time falls within the GRIB's temporal range.
Always confirm your GRIB file is loaded and covers both the geographic area and the time window of your planned passage before clicking Compute. The most common reason a routing fails silently is a GRIB that expires before the boat would arrive.
Why should you disable 'Routing from boat' when planning a future passage?
Stage 2 — Convert to Route
After the routing computes, you have a set of isochrones and a suggested fastest path shown as a line through them — but this is not yet a navigable route. It is the algorithm's raw output: a dense set of waypoints placed at every isochrone intersection. To turn it into something you can actually follow, you need to convert it to a route.
Right-click on the routing result (the colored line or the routing name in the routing list) and select Convert to Route. qtVlm generates a route object with waypoints corresponding to each isochrone step the algorithm computed. At this stage the route may contain dozens — sometimes hundreds — of waypoints, many of them only fractions of a degree apart. It is technically correct but impractical to hand-steer or even feed into an autopilot as-is.
Before moving on, read the ETA and duration displayed in the routing results panel. This is your baseline: the theoretical fastest passage given the GRIB forecast and your boat's polar data. Write it down or take a screenshot — you will compare later stages against this number to see how much time simplification and optimization cost or save.
The converted route now appears in your route list alongside any other routes you have created. You can toggle its visibility, rename it, or export it. But do not sail it yet — the next two stages clean it up into something genuinely useful.
The ETA shown after computation assumes perfect execution — no sail changes, no course deviations, no sleep. Treat it as a best-case benchmark, not a promise.
Why does the raw converted route contain so many waypoints?
Stage 3 — Simplify the Route
A route with a hundred waypoints is theoretically optimal but impossible to sail in practice. No crew hand-steers a course change every hour for a week. Simplification reduces the waypoint count while preserving the route's overall shape and timing as closely as possible. In qtVlm, right-click the converted route and choose Simplify.
You will be offered two methods: Maximum and Optimum. Maximum simplification removes as many waypoints as possible, leaving you with the fewest course changes — sometimes as few as 3 or 4 legs on a multi-day passage. The resulting route is easy to sail but may deviate meaningfully from the algorithm's optimal path, potentially adding hours. Optimum simplification strikes a balance: it removes redundant waypoints where the heading barely changes but keeps enough to track the shifting wind pattern. Most sailors should start with Optimum.
After simplifying, compare the new ETA against the original routing result. A well-simplified route typically adds only 1–3% to the total passage time while cutting waypoint count by 80% or more. If simplification added significantly more time, the wind pattern may have sharp shifts that require more course changes to exploit — in that case, Maximum simplification sacrificed too much. Try Optimum instead, or accept more waypoints.
Think of simplification as the translation step between what the computer thinks is optimal and what a human crew can actually execute. The goal is not the shortest possible time on paper — it is the shortest realistic time given that someone has to steer the boat, manage sails, and sleep.
If you are sailing shorthanded or singlehanded, lean toward Maximum simplification. The small time penalty is worth the reduction in course changes when you are the only one on watch.
What is the main trade-off when choosing Maximum simplification over Optimum?
Stage 4 — Optimize the Route
Simplification cleaned up the waypoints, but it worked backward — removing points from an existing path. Optimization works forward: it takes the simplified route's waypoint positions and re-runs the routing algorithm between each pair of waypoints, refining the departure time and heading for each leg based on the GRIB data. The result is a route that is both practical to sail and as fast as possible given the waypoint constraints.
To optimize, right-click the simplified route and select Optimize. qtVlm will recompute each leg individually, adjusting timing to exploit the best wind windows between waypoints. This often shaves time back off what simplification added — sometimes the optimized route is faster than the original isochrone result because the optimizer can fine-tune departure timing at each waypoint in ways the initial full-passage computation could not.
After optimization, review the final ETA and compare it against both the original routing result and the simplified version. You should see the optimized time fall between the two, or occasionally beat the original. If the optimized time is significantly worse than the original, the simplified route may have too few waypoints to capture the wind pattern — go back and try Optimum simplification instead of Maximum.
This four-stage workflow — Create > Convert > Simplify > Optimize — is the core of practical weather routing in qtVlm. Run it every time you get a new GRIB update, and compare the new optimized route against your previous one. Weather routing is not a one-time event; it is a continuous process of refinement as the forecast evolves.
Re-run the full four-stage workflow every time you download a fresh GRIB file. Weather changes constantly, and yesterday's optimal route may be today's slow one.
How does optimization differ from the initial routing computation?
Common Beginner Mistakes
The most frequent mistake is starting a routing with no GRIB file loaded — or with a GRIB that does not cover the full passage area and time window. qtVlm will either fail silently or produce a routing that dead-ends partway across the chart. Before you click Compute, verify that the GRIB covers the entire geographic extent of your planned route and extends far enough in time that the boat could arrive. A good rule of thumb: download a GRIB that covers at least 150% of the estimated passage duration.
The second classic error is leaving 'Routing from boat' enabled when you are planning from shore. The algorithm places the start at your computer's last known GPS position (or a default location), and the result is nonsensical. Always uncheck this box for advance planning. Similarly, forgetting to enable "Keep Starting Date" means qtVlm resets your departure time to now every time you recompute — which quietly invalidates your carefully chosen weather window.
No polar file loaded is another silent killer. Without polar data, the algorithm does not know how fast your boat sails at different wind angles and speeds. Some versions of qtVlm will still compute a routing using a default generic polar, but the result will be wildly inaccurate for your specific boat. Always load the correct polar file for your boat and sail configuration before routing. If you do not have a polar, many sailmakers and design offices publish them for common production boats.
Finally, setting the start time outside the GRIB's time range produces either an error or a routing that uses the first available GRIB step regardless of what you entered. Always cross-check your chosen departure date and time against the GRIB file's start and end timestamps. qtVlm shows the GRIB's time range in the GRIB manager window — get in the habit of checking it before every routing run.
Create a pre-routing checklist and tape it to your nav station. Four items: GRIB loaded? Polar loaded? Routing from boat off? Start time in GRIB range? Check all four before every compute.
A routing computes but the isochrones stop halfway across the chart. What is the most likely cause?
Summary
The qtVlm weather routing workflow has four stages: Create a Routing, Convert to Route, Simplify, and Optimize.
Disable 'Routing from boat' and enable 'Keep Starting Date' when planning future passages from shore.
Set the Automatic parameters slider to Best accuracy and ensure your start time falls within the GRIB's time range.
Simplify using Optimum for a balance of practical waypoint count and routing efficiency; use Maximum only when shorthanded.
Optimization re-routes leg by leg between simplified waypoints, often recovering time lost during simplification.
Re-run the full workflow with every new GRIB download — weather routing is a continuous process, not a one-time calculation.
Key Terms
- POI (Point of Interest)
- A user-placed marker on the qtVlm chart used to define routing start and end positions
- Isochrone
- A contour line connecting all points a boat could reach in the same elapsed time from the start, used by the routing algorithm to find the optimal path
- Routing from boat
- A qtVlm option that forces the routing start to the boat's current GPS position — disable this for advance planning
- Keep Starting Date
- A qtVlm option that preserves your chosen departure date and time across recomputes instead of resetting to the current time
- Simplification
- The process of reducing a dense isochrone-based route to a practical number of waypoints using Maximum or Optimum methods
- Optimization
- A refinement pass that re-routes between simplified waypoints to recover time and exploit wind windows more precisely