Thursday, April 23, 2026

Wind on the Water: A Sailor's Perspective

For sailors, wind speed is given in knots, and the direction of the wind is the direction it comes from. A north wind is blowing from the north toward the south. A sea breeze is blowing from the sea toward the land.  A land breeze is from the land toward the sea.

On the boat, we typically read the wind speed from an anemometer located at the mast head. Its spinning cups measure the speed, and an associated wind vane aligns with the direction of the wind, with the fin downwind, with the arrow pointing in the direction the wind comes from. The data are then transmitted digitally to instruments at the nav station and on deck.

The wind vane is calibrated to be oriented along the centerline of the boat, so the "wind direction" measured is not an actual direction on the horizon, but rather it is a wind angle relative to the heading (HDG) of the boat, called the apparent wind angle (AWA), which can vary from 0º for wind dead ahead, or 90º for wind on the beam, on around to 180º for wind on the stern. Wind dials or meters will then label the direction to be port or starboard, with the starboard side considered positive, if signs are given. Likewise, the wind speed we measure is called the apparent wind speed (AWS).

This measured wind from the masthead of a sailboat is called "apparent wind," because that boat can be moving, and when it starts to move, it creates its own wind.  For example, if there were no wind from nature at all at the moment (dead calm), and the boat took off at 6 kts headed due west, the AWS would read 6 kts and the AWA would read 000º, wind dead ahead. We are making this wind with our own motion. 


Figure 1. A boat creating its own wind, as it might appear in nav app meters.

Now if an actual meteorological wind from the north started to blow across the  water at 8 kts, the anemometer would then feel two winds: 6 kts from the west created by the boat's motion and 8 kts from the north created by a local weather pattern. The anemometer would then reflect the combination of these two winds, which leads us immediately to the concept of vectors, which we cannot avoid when discussing wind on the water.

The speed (of anything) is just a number, called a scalar, but the velocity (of anything) is a vector, it has both a speed and a direction. When we combine two winds, we are adding two velocity vectors to obtain a resultant third vector. Vector addition can be solved mathematically or depicted and solved purely graphically, as shown in Figure 2. When depicted graphically by arrows, the length of the arrow is proportional to the speed, and the direction of the arrow is direction of motion. 

With wind velocity vectors, we must distinguish between the direction the wind is flowing, or being created, as in the case of the boat motion wind (BW), and the name of that wind, which is the opposite of the direction it flows. A true wind (TW) from the north flows toward the south (its vector points toward south), but the name of the wind displayed on a meter (true wind direction, TWD) is the opposite. This is illustrated below and can be important for understanding such diagrams.

Figure 2. Basic wind vectors on the left with arrows indicating wind flow, compared to the same triangle with arrows indicating named wind directions, plus sample meter displays.

In the top left we see how vector addition is presented graphically. The TW vector plus the  BW vector is equal to (gets you to the same point as) the AW vector. You can draw these on paper and get the right answer: 8 units down, 6 units to the right, then measure what the AW is using a ruler on the same scale and a protractor.

Here we have added three more meters (true wind angle, speed, and direction) to reflect what we have determined ourselves about this from the moving boat, even though all we had to measure was the apparent wind we actually felt. This is done by mathematically solving the vector triangle on the right, which is based on the measured AWS and AWA, along with the measured boat speed (knotmeter) and measured heading from a digital heading sensor. This is carried out either by the wind instrumentation itself, or, maybe more often, from within the nav app we are using to compile and analyze the instrument data.

We can learn a couple general wind rules from looking at these vector drawings. First,  the true wind is always aft of the apparent wind. If we have wind coming over the beam in a moving vessel, we know the true wind on the water is coming from more toward the quarter. Apparent wind on the bow, means the true wind is more toward the beam. 

Second, the faster we go in the same true wind the more the apparent wind moves forward.  In the extreme case where the true wind is very small compared to our speed, then the apparent wind will be essentially dead ahead, as in Figure 1.

Figure 3. Apparent wind moves forward as our speed increases in the same true wind, and vice versa if we slow down.

We also learn very quickly that for these computations to be useful, all of the instruments involved must be carefully calibrated and checked on all points of sail: AWS, AWA, HDG, and BSP. The vector solutions can be very sensitive to small errors in any one of them. This is a big task for the navigator.

So big, in fact, that it is fair to ask, why should we go to all of this trouble, and indeed expense,  in getting and calibrating quality instruments? You could say that we sail by the apparent wind and that is all we need to know; why do we care so much about the true wind?

The answer is, from the navigator's and tactician's point of view, the true wind is everything!  

The sail trimmers and helmsmen live by and respond immediately to every change in the apparent wind, but the desired heading, determined by the navigator, and when it should change, is all based on the true wind. Plus, the evaluation of the present performance of the boat is based on the true wind, i.e., for the present TWS and TWA are we going as fast as we should be?

When we tack, our heading will change by twice the TWA, centered on the TWD. When we jibe, our stern crosses the TWD and our heading changes by twice (180 - TWA). 

Figure 4. How TWD and TWA relate to our sailing tracks and laylines.

We will come back later to how the TWA enters into the important task of evaluating sailing performance using polar diagrams, which is also the basis of computing optimum routes across a varying wind forecast. 

_________

In the above basic description, we determined the TWS, TWA, and TWD from AWS and AWA corrected for boat speed BSP and HDG through the water. Thus we were talking there about true wind relative to the water, and we have assumed that the water itself is not moving, meaning no current. 

Once we are sailing in water with current, we have to be more aware of our terminology. It does not matter for sailing analysis what the cause of the wind might be, but in the presence of current, we have to be aware that the wind we are calling the "true wind" is not the same as what meteorologists, forecasts, and buoy reports call "true wind." These official wind forecasts are relative to the fixed ground. 

If the local buoy reads 10 kts from the north (the meteorologist's true wind), and I hop in my boat headed due north in a current that flows 2 kts toward the north, and I am not yet moving through the water (BSP = 0; underway, but not making way), then I will read AWS = 12 kts with AWA = 00 (10 kts from the wind + 2 kts from the current). Then as a sailor I will interpret this a true wind of 12 kts, and indeed my sails would respond accordingly. 

Once I start moving through the water, the AWS and AWA will change, but once I correct for HDG and BSP I will come back to a sailor's TWS = 12 and TWD = 360.

The way sailors distinguish these two true wind values is to call the meteorological true wind the ground wind. Thus we call wind relative to the water true wind and wind relative to the fixed earth ground wind.  (It has been proposed that the sailor's true wind should be called the water wind, but this never did catch on, in part because sailors have used the term true wind for a long time, plus the polar diagrams use the term true wind as well.)

Figure 5. Finding sailor's true wind in the presence of current. The sailor has no knowledge of the presence of current with just this information. It will take GPS measurements to reveal the presence of current.

The distinction between how we compute true wind vs ground wind is very direct once we have GPS data. True wind is the measured apparent wind corrected for a boat wind determined by (BSP, HDG), whereas the ground wind is found by correcting the same apparent wind for a boat wind determined by (SOG, COG), which will be different if there is current and or leeway, as shown in the figure below.

Figure 6. Computing true wind vs ground wind. The true wind using HDG and BSP assume there is no leeway taking place. Later when we introduce leeway, these will change to CTW and STW for course and speed through the water.

__________________

The above is the background to wind on the water for sailors, but we are not done if we want to do our very best with navigation and routing. We have dealt with idealized measurements and have not accounted for the important factors of heel and leeway, which have separate and related influences.

Heel has a basic geometric effect on the wind vane, in that when it is tilted the wind vane does not feel the full force of the wind, because the component perpendicular to the centerline is diminished. The net effect is the AWA and AWS we measure when heeled over are slightly too small, so we have to correct them. This in turn will affect the all important TWA and TWS.

 The heel in turn is usually associated with a leeway that will further affect the most accurate values of TWA, TWS, and TWD, as well as GWS and GWD

The AW corrections, derived below, are sometimes corrected within the wind instruments (such as B&G 5000 or newer) or more commonly, within the nav app reading the apparent wind and computing the true wind. Here AWAm and AWSm are the measured values from the anemometer, and AWAc and AWSc are the corrected values that are used to compute the true wind. It is up to the nav app to decide which of these it chooses to display.

AWAc = atan [ tan(AWAm)/cos(heel) ]


AWSc = AWSm x cos(AWAm)/cos(AWAc)


Suppose wind instruments measure AWAm (34.3º) and AWSm (14.5 kt), and our digital inclinometer measures a heel angle (23º). 


AWAc = atan [ tan(AWAm)/cos(heel) ] 

            = atan [ tan(34.3)/cos(23) ] = 36.5


AWSc = AWSm x cos(AWAm)/cos(AWAc)

            = 14.5 x cos(34.3)/cos(36.5) = 14.5 x 1.03 = 14.9


These are both small changes, but they all add up, and these are the values that should be used in the final true wind computations. (For quick estimates, heel narrows the correct apparent wind angle by just under a factor of cos(heel), which at 20º heel is 0.94 or 6%.)


Figure 7. Overview of heel angle errors on AWA. For AWA = 30º with a heel of 25º, the uncorrected AWA will be too small by 2.5º. Diagram adapted from Ref 8



The derivation of the AWA and AWS corrections are shown below.



Figure 8. AWA and AWS corrections due to heel. When heeled over, the AWA and AWS we measure are slightly too small by the amounts indicated. We start with an apparent wind vector (AWSx, AWSy, 0), which means we assume the air flow over the meter is parallel to the water, without notable upwash from the sails. We are also neglecting the effect of mast twist. This is a common assumption, but it overlooks what could be an important correction. We look into how to incorporate that later on. When the boat heels, the y component (athwartship) of the apparent wind narrows, but the x component along the centerline does not change.

__________________

Now that we have corrected AWA and AWS for heel (putting off for now the upwash correction), we can look into finding an improved true wind. The presence of heel is often a reminder that the boat could be slipping to leeward to some degree, called the leeway angle (LWY), but it is important to note that heel does not cause leeway. A boat can stand essentially straight up and slip to leeward, especially in light air. 

With leeway, the track of the boat through the water (CTW) is not the same as the heading of the boat. Instead, we have:

CTW = HDG + LWY.

When the boat is slipping to leeward,  the proper reference for the true wind over the sails is not the centerline (HDG), but rather the track line (CTW). Leeway can, with some effort, be measured from the angle the wake of the boat leans to windward, or with sophisticated instruments (rare) that measure both translational (sideways) speed as well as the standard longitudinal (fore and aft) speed. Some wind instruments suggest dropping a series of markers off the stern and then taking a bearing to the line they make to compare with your heading. 

It has been found, however, that a workable approximation to the leeway can be made from the theoretical balancing of the force on the sails and the lifting force of the water flow over the keel. This leads to the commonly used expression for LWY in degrees:

LWY = k x Heel / STW^2, 

where k is called the leeway coefficient, which is typically 9 to 16 for sailboats, Heel is in degrees and STW^2 is the square of the boat speed through the water in kts. With a measured heel, we can compute the LWY and from that get CTW and then relate the heel-corrected apparent wind to the CTW for an improve value of the true wind and ground wind. We also get a better value for the current speed (CS) and current direction (C) correcting for leeway in this manner.

The geometry to be solved is shown in Figure 9.


Figure 9. Correcting apparent wind for heel and leeway. The bottom image is adapted from Ref. 1. In this image, the apparent wind and boat speed are assumed to be the values corrected for heel, thus: AWA=AWAc, AWS=AWSc, and STW=STWc. 

We can solve for TWS as: TWS^2 = TWSy^2 + TWSx^2, where TWSy =AWSxSin(AWA+LWY) and TWSx=AWSxCos(AWA+LWY)-STW] and AWA = ATan(TWSy/TWSx).

Alternatively, define the AW vector as (AWS, AWD) with AWD=CTW+LWY+AWA, and the BW vector as (STW, CTW) and solve for the vector difference between them. For ground wind, use the same AW vector corrected for BW vector relative to ground,(COG, SOG).

__________________

To help understand the wind corrections that your favorite nav app is making, we created an app (WindCor) that computes the winds with No corrections, Corrections for heel only, and Corrections for heel and leeway. Below is the use of the app comparing to the outputs from the popular navigation and tactics app Expedition, to which we sent these simulated NMEA sentences for HDG, STW, AWS, AWA, COG, SOG, and Heel by UDP:

$GPGGA,040000.000,3813.55991,N,6848.559458,W,1,10,1.8,1,M,,,,,*28
$GPMWV,48.9,R,19.09,N,A*1E
$GPRMC,040000.000,A,3813.55991,N,6848.559458,W,10.788,145.1,230624,14.1,W*64
$GPVHW,161.2,T,,M,8.833,N,,K*46
$GPXDR,A,-25.61,D,HEEL,P,101789,P,PRESSURE*58


Figure 10. Meters (Number Boxes) in Expedition from expeditionmarine.com. Top has no Heel nor LWY input; middle data adds Heel input, but has k=0 to rule out LWY corrections; and bottom  shows all inputs and all corrections. Data on the right are computed with WindCor using the formalism describe above. This GWS sample has the wind cups at 10m. The same example below shows results at 15m.

The agreement is not exact, but close enough to conclude that Expedition is making these standard corrections, with the convention of displaying the measured AWS and AWA, even though the corrected values are used for the true wind data.

The WindCor app can be used to check these results. The app is stored in our starpath.com/calc index to various computers.  Below is a sample output.


Figure 11. Sample screen from WindCor


The importance of true wind for navigation is outlined above, but we also need the best value of TWS an TWA to evaluate sailing performance relative to the polar diagram for the boat.  The original forms of these diagrams made by a VPP (velocity prediction program) or yacht designer assume the TWS and TWA are the actual values the sails are seeing, which means they are relative to the water not the boat.

The ORC VPP is a physics simulation that solves equilibrium equations for the boat as a body moving through the water. In that model, the boat experiences hydrodynamic forces along (and perpendicular to) its actual direction of motion through the water — i.e., its track through the water, not its centerline. 

So in principle the best TW values to use when evaluating performance or building a better polar would be the TW value corrected for both heel and leeway.

Our accurate measurement of ground wind is used to evaluate model forecasts that predict the wind at 10 meters above the water, whereas anemometers at the mast head are typically higher than that. The wind speed increases with height above the water as it becomes less slowed by friction, so we must typically reduce the measured GWS  to get the 10m values. This can be computed several ways, but a common one we use in WindCor is GWS10 = GWSc x (10/h)^0.11. This power can vary from 0.10 to 0.15.


References

1. Yacht Performance with Computers by David R Pedrick and Richard S. McCurdy, Chesapeake Sailing Yacht Symposium, January, 1981. (McCurdy was a co-founder of Ockam Instruments.)


"When polar curves are created by VPP programs, all TWA are measured from the wind to the boat’s course, NOT to its centerline..."

4. Introduction to Polar Diagrams and Optimum VMC davidburchnavigation.blogspot.com/2022/02/VMC.html


6. orc.org/uploads/files/ORCsy/2025/2025-VPP-Documentation.pdf
Figure 3.2 states explicitly that the forces are balance about the "track axis."

7. These nuances of true wind determination are discussed in Appendix 9 of Modern Marine Weather. This book includes extensive discussion of the practice and value of using measured ground wind and pressure to evaluate model forecasts.













Thursday, April 16, 2026

New Tidal Current Resource for Swiftsure and R2AK Sailors

The excellent (free for Mac and PC)  navigation app qtVlm has just added a new optional feature that is free for testing until May 15, 2026—after which it becomes a subscription option. Namely they have added an internal GRIB server that now includes the Operational Forecast System (OFC) model for tide and current forecasts, as well as other models. 

This means we are no longer limited to the NOAA harmonic predictions of the currents at spot locations, at just a few specific times, but now we have currents at all locations at all times. Plus the OFS model takes into account local wind and pressure as well as river run off, which makes the forecasts more accurate than the harmonic predictions, which do not account for local environmental conditions. (We still need to use the harmonics for specific data at narrow passes where NOAA has metered stations.)




Sample of OFS currents in San Francisco

The OFS updated four times a day, with forecasts every hour out to 2 days in most cases, but 3 days in the Pacific NW, which is covered by Salish Sea and Columbia River region (SSC-OFS). This region takes us to the north end of Vancouver Island, where we would switch to the West Coast region (WC-OFS) — but the Canadian harmonic data would still be valuable along the Canadian waters of the Inside Passage.

Likewise, Randy Washburne's book Southeast Alaska Current Atlas remains a leading reference for those waters.


For all of Swiftsure and for any racing in Puget Sound or the San Juans, the OFS SSC data are certainly the most important source, which now can be loaded with a button click into qtVlm, which also has state of the art presentation of NOAA charts.

We can now, for example, add the OFS currents to the HRRR winds and do realistic optimum sailboat routing on inland waters. The new qtVlm GRIB server lets you load both of these at once into one of three Grib slots.

OFS currents are described in detail in Modern Marine Weather, 4th ed


To learn how we use qtVlm in our online training courses, see this note on Getting Started with qtVlm. The Training Mode discussed there expedites learning qtVlm that has so many features, plus it adds charts, harmonics, and other resources.  qtVlm is among the top of the line in weather analysis and routing, and it is in fact the top of the line in electronic navigational chart (ENC) presentation.

Here is a short video showing how to access these OFS current data, which starts with downloading and installing the latest version: https://www.meltemus.com/index.php/en/download (which you can do from the Getting Started page, with video examples.)



Video demo of viewing OFS currents. See our qtVlm playlist for more info on qtVlm

Once the free intro period is over (May 15, 2026), the main app remains free, but the convenient GRIB service will be come a subscription add-on.

Below are the regions West Coast and Pac NW regions covered by the OFS. The workhorse is the Salish Sea and Columbia River (SSC-OFS). The WC data along route to Ketchikan (north of the SSC limit) is not as precise, but should supplement the US and Canadian harmonic predictions.




Wednesday, March 4, 2026

Grib Offsets for Routing in qtVlm

When we compute the optimum sailing route in a nav app like qtVlm, we use the polar diagram of the boat to provide its performance expectations in various wind conditions, and we rely on a numerical weather model forecast of the wind, such as the GFS global model for ocean routes and the HRRR regional model for the inland and coastal routes leading to the ocean.

Once underway, the route always starts from our present position and present time, using the forecasted wind for that time and place. It is indeed always a forecast we are using, because even if we download the forecast when first available it will be based on the most recent synoptic time (00, 06, 12, 18z), which will be some 5 hr in the past when we get it.

It could be, for example, that the model's surface analysis, valid at the synoptic time, was very close to the actual winds we had then, but now, at the time of the route computation, 5 or 6 hours later, the wind could differ from what the model forecasted.

Here is an example. At the start time and place, the forecast for the wind is 8.6 kts from 219, but when we determine the true wind from our own (calibrated) instruments it is 12.5 kts from 248. It would not make sense at all, to compute a route starting with this wrong wind. The result could be significantly wrong, and difficult to correct.

Luckily, most sophisticated routing routines give us the option to account for this wind difference, and here we look at how qtVlm does this.  The function is accessed from the Grib Config page under Corrections (windsock icon in the toolbar).


Here we force the wind to be the right speed and direction observed, and then choose how long you want it to take to linearly blend back into the forecasted value. When doing this underway, there is a button to read the wind instruments values, and to set the start time to now.

qtVlm has an excellent way to learn what the average offset is for wind speed and direction in the Voyage Data Recorder (VDR) option. We can graph the model wind and the measured wind and compare the two.

This sample shows two model winds and the gusts from one compared to the measured wind at the masthead corrected to 10 meters of the model wind (discussed below). Here we have to decrease the model wind by 10.3/11.5 = 0.90 = 90%. A similar plot gives the direction offset.

The VDR data can be exported as a CSV and loaded into Excel for more accurate averages.

The masthead offset is entered in the VDR settings page.

In the example below we choose to blend our forced wind back to the grib value in 3 hr. Then we would have to compare again the forecast with the wind instruments. If the wind is steady in the forecast and instruments, we could extend this longer, if not, we reset the wind, and run the route computation (called a routing in qtVlm) again. A running VDR plot of the two winds helps us choose how and when to blend back to pure model wind.

_____________

To see how this works, you can load a grib wind forecast, then create a 4 or 5 hour route across the wind, and to simplify the analysis, turn the engine on at a fixed speed of say 6.0 kts.  

Then we can set the route's logbook display to a 60-minute interval. This lets us see what the app thinks the wind is for routing at each hour along the route. Below are sample outputs.  At the end there is a link to a video that shows more specifically how this can be set up for testing. 


In the above, the set up screen is on the right, and top left is the model forecasted wind at each hour with the forced wind turned off.  Next to it is the wind at each hour with the forced start time wind turned on and set to return to the grib in 3 hr.

This is an easy to use tool, and indeed required operation for any routing underway. It is the navigators job to monitor the forecasts with the observations to know when to re-tweak the winds and run the route again.

_____________

Now we need to say (or at least mention) the often unspoken part: for this to work, we need to have accurate (calibrated) instruments. We measure the apparent wind (AW), typically at the masthead, and then we convert that to true wind (TW) at 10 meters (33 ft) above the surface, which is what the forecasts tell us.  Some sophisticated wind instruments do all this for us, but with basic  instruments, we count on qtVlm to make the vector conversion from measured AW to derived TW based on the COG and SOG from the GPS.  

The anemometer height correction for the speed is explained in Appendix 9 of our textbook Modern Marine Weather in a steady wind, the wind speed increases with height above the water, because the surface friction slowing it down decreases as we get farther from the water.

Since the anemometers of boats over 25 ft or so in length are higher than 10 m above the water level, the wind they read will be greater than the wind at 1o m. For a 70 ft (21 m) mast, the correction would be about +10%; taller masts have larger corrections. 

In other words, with a 10% height correction, a model forecast of 8.6 kts means you should read 1.10 x 8.6 = 9.5 kts TWS for exact agreement. In the example above, we read 12.5 kts, so the actual correction we want is 12.5/9.5 = 1.32, which is an improvement over the 1.46 we used above. 

In other words, when you press the "Wind from instruments" button mentioned above, it reads the wind from the masthead (12.5 kt), but we would want the forecast at 10 m to be 10% less, so we should reduce that to 12.5/1.10 = 11.4, then we are making the right scaling 11.4/8.6 = 1.32.

Which, granted is a small correction. Indeed, the accuracy of the wind forecasts and actual official wind measurements from buoys, stations, and ASCAT is something like ±2 kts, and we should be happy if our own measurements are that accurate, but that does not mean we should throw out or ignore corrections of that magnitude that we know exist. The force of the wind is proportional to the square of the wind speed, so we don't want to lose any accuracy we do not have to. There are enough other uncertainties in the routing process to deal with.

_____________

qtVlm also has an option for simply shifting the wind to desired values and leaving it at those values till it is changed. But this is more for just creating a wind without any grib input for practice with simulated routes and routing. This is illustrated below. 


Here we see the wind throughout the forecast (top right) is increased by 146% and shifted by 29º relative to the underlying grib wind (top left). However, we would get this same wind if we just shut off the grib forecast completely. In other words, this function is not presented as an underway routing aid, it is more a simulation and training aid.

_______________

The treatment of currents in routing is another crucial factor in many cases. When we do a routing computation we load at least two grib files. One for the wind and one for the currents. Global wind models extend out 10 to 16 day, but ocean current forecasts often do not extend out over the full duration of an ocean route (see table below), but routing apps usually have the option to extend the last currents forecast to the end of the route. In qtVlm this is done at menu Config/Gribs and Harmonics/Grib and turn on "Automatically extend Current grib last date."

Generally this is not a problem because most ocean currents do not change rapidly with time. In some cases, it could mean that the ends of longer routes into areas with notable current may not be right on early route computations, but this is often the case, even without currents. We will be running the routing computation multiple times a day, so this takes care of itself.

Current data from Modern Marine Weather.

In some ocean popular races, Newport to Bermuda and Sydney to Hobart come to mind, currents can be a key factor in optimum routing, and navigators usually spend a long time trying to figure what the best data will be. But the current, like the wind, is something we can measure underway, and then correct the  current forecasts accordingly. 

The measurement is similar to measuring wind for wind corrections in that we need well calibrated instruments: in this case a heading sensor, to get course through the water (CTW), and a knotmeter, to get speed through the water (STW). Then, like the wind, we need qtVm to do the vector math to get the current, which is the vector difference between [CTW, STW] from your instruments and [COG, SOG] from the GPS.

This is not an instantaneous measurement. The vector solution will bounce around, but we can get a useful average with time to compare with the forecasts.  We can, for example,  view a plot of the current speed (CS) and direction (CD) in the histogram tab in the route log, and this way find good values to use for the present current. 

Once we know the current we have two options in qtVlm for corrections.



(1) With no current model to work with, we can just force the current to be what we measure and use that for short term routing.  This is also the control we use to just simulate current for practice with current sailings and routing.

(2) If we have a model forecast, we can figure the percent correction in speed and direction, and enter it, but even with a model forecast we have to monitor this. In some areas we have steady currents over large areas and time, but in others we have to deal with meanders and eddies. In some cases the eddies in the middle of the ocean can be just some several hundreds of miles in diameter.  

We might run across vagabond rivers (sides of an eddy) of over a knot in the middle of the ocean, that could be a goldmine or lead balloon, depending on what side we are on.  Knowing this and careful monitoring is key.  You will know from the forecasts if such eddies are likely, but they are not likely to be precisely where forecasted.

An important use of the current offsets comes with the use of the OSCAR current data for ocean routing. See starpath.com/OSCAR. In many cases we have found that the flow pattern of the OSCAR data are the best guideline for ocean routing, but you may find that the OSCAR speeds are too low by 20 or 30%, because they are an average over 24 hr. So you can download the OSCAR data (it will be for one day alone, 3 days ago) and then extend it as noted above to the end of your wind grib data, and then enhance the speed at the start of the routing by say 125%, but leave the direction unchanged. Then once you get some reliable current measurements you can adjust the corrections.

Note this is for ocean routing. In US waters, we would start off with the Operational Forecast System (OFS) tidal currents till we get some distance off shore. They account for local tides, winds, and pressures. 

We have more general notes on currents at starpath.com/currents.







Saturday, January 10, 2026

Access Historic OSCAR Currents in GRIB Format

We have long suggested that the satellite based measurements of ocean currents called OSCAR (Ocean Surface Current Analyses Real-time) are often the best guide for optimum sailboat routing. See this video note on the 2025 Sydney-Hobart race.

The present form of the NRT (near real time) data (0.25º resolution; avg depth 15m, 24-hr averages, run daily, but with a 3-day latency) are available since 2020, but the raw data are in NetCDF format, which is not compatible with most navigation applications (electronic charting systems, ECS).

Recently we have outlined how to get archived yacht race routes into various ECS along with how to get the historic winds and waves in GRIB format (reanalyzed ECMWF) for the same time of the race.

Now we want to show how you can also get the historic OSCAR currents for these past races, so when you practice with your own routing to compare with the historic tracks you have all the data needed. 

For direct access to the OSCAR data, you will need to set up a free account at the NASA Earth Data site. This takes just seconds and is totally non-invasive, plus offers other features as well.


Step 1. Get a subsetted copy of the data in NetCFD format from this link:

OSCAR by Lat, Lon, and Date


Step 2. Convert that file to GRIB format with this link:

Convert OSCAR from NetCDF to GRIB


Notes:

(1) If no one has used our conversion service recently, then it will have gone to sleep, and we have to wait about a minute for it to wake up, and then it will complete the task. The next conversion will happen quickly.  This is a fair price we pay for using the free mode of a powerful app server. In the wait we learn about what they offer.

(2) You can also get the most recent OSCAR currents this way, but that is more convenient from LuckGrib or SVSarana, as discussed at starpath.com/currents.  The latest data will always be three days old, regardless of where you get it, but doing as outlined above, you would have to enter a date three days ago.

(3) Here is an 8-min video example.

Let us know if you have any questions about this at helpdesk@starpath.com

(4) OSCAR data locations are moving around in 20226. Here are the latest links we have on data access:  Latest Near Real Time (NRT) data and Historic Final versions back to 1993.