Viewing ASCAT Wind Measurements in OpenCPN

This article outlines the value of ASCAT wind data, and shows how work we have done at Starpath to make these files available on Google Earth can be transcribed to the format needed to be viewed in OpenCPN.  This is effectively a request to OpenCPN developers to automate this conversion process and make the full set of ASCAT data files and then incorporate them into the standard weatherfax plugin.

_______

ASCAT is the name of the scatterometer on two EUMETSAT satellites, Metop-B and Metop-C. They circle the earth in sun-synchronous polar orbits every 1h 41m (101.3m) measuring ocean surface wind speed and direction. They are in the same orbit, but on opposite sides, so they are about 50 min apart, during which the earth rotates 50 min x (15º lon/60 min), or 12.5º of Lon.  Thus the data from C is about 50 min later and  covers a swath of the earth that is 12.5º of Lon farther west—or vice versa, thinking of B following C. We  have extended background on ASCAT at starpath.com/ascat.

These direct wind measurements are the key information needed for weather routing, with a primary use being to evaluate the numerical weather model forecasts. The data are like having thousands of buoys at sea measuring the wind speed and direction, and if a model is to be dependable it should closely match what we see in the buoy measurements.  Also we will periodically see real holes in the wind, or wind shear lines in the ASCAT measurements that are not forecasted in any model. The resolution of the ASCAT data (25 km) is about the same as that of the GFS model (27 km). The expected accuracy of the satellite measurements and that of the model forecasts is about the same, so very roughly ± 2 kts in wind speed and ± 20º in wind direction has to be considered in agreement. 

Remember that the final goal of any numerical weather model is not to reproduce all of the specific observations that went into the computation, but rather to create the best overall forecast at all levels of the atmosphere, which almost always involves some compromise in matching the surface data. Thus, even though the ASCAT measurements are key data assimilated into any global model computation, we should not be surprised that we can learn real and significant discrepancies in the model forecast by looking at the same ASCAT data it was looking at, and when these do disagree, it is the measurements that are of course the correct answer.

ASCAT wind data are available in grib format, but only from two commercial sources, LuckGrib and Expedition, and their data cannot be viewed in other nav programs. This important data, however, are also readily available in graphic format, and OpenCPN is well suite to displaying this data using the powerful WeatherFax plugin—and the process of setting that up is the topic at hand.

We have an important background article on this process Updating Internet File Source for OpenCPN WeatherFax Plugin, which pretty much describes the process in general, but here we need to be more specific on how we generalize the ASCAT data.

We have created two graphic indexes of the files available, one for adjacent US waters the other for adjacent European waters. 

Each of these regions that we have named have four ASCAT files, ascending (satellite moving north, data swaths tilt to the east and descending (satellite moving south, data swaths tilt to the west), one for Metop-B and one for Metop-C.

Here are the 4 examples for what we call the San Francisco region.

San Francisco ASCAT B - Ascending.kml 

San Francisco ASCAT B - Descending.kml

San Francisco ASCAT C - Ascending.kml 

San Francisco ASCAT C - Descending.kml 

You can download anyone or all and drag onto Google Earth (desktop version) to see the latest ASCAT data in that region, defined above. Samples are below (click it, then right-click, open in new tab, and zoom for detailed view).

The times shown in our indexes tell us when new data are expected, which will come in pairs about 50 min apart, with the pairs separated aby about 13 hr.  The times are the valid times of satellite passage, ± 1 hr, but we must wait about 2 hr for the data to be analyzed and made available.  Thus in Biscay, we would expect see new data at about 1230 and 2320 UTC, adding say 30 min to save on air time by asking too early.  Once you have this set up in OpenCPN or Google Earth you will quickly learn how it works. Video examples are listed at starpath.com/ascat.

With that background, we now get to the process of how to convert what we have provided to work with OpenCPN using the weatherfax plugin, which has one of the most convenient displays of graphic weather data of any navigation program.

We have videos on how images are displayed in the weathefax plugin, and as the link above explains OpenCPN stores the data needed for quick display of any image in two files. One provides the link info stating where the data is online and the other specifies the georeferencing coordinate data so the images are displayed in the right place.

The data links are provided in a series of about a dozen XML files called, for example, 

WeatherFaxInternetRetrieval_NAVY.xml, which looks like

<?xml version="1.0" encoding="utf-8" ?>

<OCPNWeatherFaxInternetRetrieval>

  <Server Name="NAVY" Url="https://www.ncei.noaa.gov/jag/navy/data/satellite_analysis/">

      <Region Name="Gulf Stream">

        <!-- Gulf Stream charts -->

        <Map Url="gsncofa.gif" Contents="North Altantic" Area="GS1" />

        <Map Url="gsscofa.gif" Contents="Golf of Mexico" Area="GS2" />

        <Map Url="gsneofa.gif" Contents="Coast Guard North Atlantic" Area="GS3" />

        <Area Name="GS1" lat1="30N" lat2="53N" lon1="80W" lon2="45W" />

        <Area Name="GS2" lat1="17N" lat2="40N" lon1="98W" lon2="65W" />

        <Area Name="GS3" lat1="30N" lat2="60N" lon1="80W" lon2="35W" />

      </Region>

  </Server>

 </OCPNWeatherFaxInternetRetrieval>

These files are located on a PC in:

C:\Users\username\AppData\Local\opencpn\plugins\weatherfax_pi\data

on a Mac, they are located in:

HD\Users\username\Library\Application Support\OpenCPN\Contents\SharedSupport\plugins\weatherfax_pi\data\

We also need to work on the coordinates file which has to include an element for each "server name."

This file is called CoordinateSets.xml  Below we see the section that covers the NAVY server.

   <Coordinate Name="NAVY - Gulf Stream - GS3" X1="304" Y1="60" Lat1="59.00000" Lon1="-76.00000" X2="2122" Y2="1285" Lat2="32.00000" Lon2="-40.00000" Mapping="FixedFlat" InputPoleY="-1515" InputEquator="3031.00000" InputTrueRatio="1.0000" MappingMultiplier="1.0000" MappingRatio="1.0000" />

    <Coordinate Name="NAVY - Gulf Stream - GS1" X1="101" Y1="28" Lat1="53.00000" Lon1="-80.00000" X2="2375" Y2="927" Lat2="32.00000" Lon2="-45.00000" Mapping="FixedFlat" InputPoleY="-2365" InputEquator="3475.00000" InputTrueRatio="1.0000" MappingMultiplier="1.0000" MappingRatio="1.0000" />

    <Coordinate Name="NAVY - Gulf Stream - GS2" X1="376" Y1="82" Lat1="38.00000" Lon1="-94.00000" X2="2236" Y2="746" Lat2="20.00000" Lon2="-67.00000" Mapping="FixedFlat" InputPoleY="-3444" InputEquator="2755.00000" InputTrueRatio="1.0000" MappingMultiplier="1.0000" MappingRatio="1.0000" />

So what we need for OpenCPN is a new set of Retrieval servers and we need new Coordinate Name entries for each of the custom regions we have defined, and these are likely best duplicated, one for Metop-B and one for Metop-C, which makes access to the data a bit easier. 

The new WeatherFaxInternetRetrieval servers would look something like this which covers just two regions. The other 46 would have to be entered into 

<?xml version="1.0" encoding="utf-8" ?>

<OCPNWeatherFaxInternetRetrieval>

<Server Name="ASCAT B" Url="https://manati.star.nesdis.noaa.gov/ascat_images/cur_25km_METB/zooms/">

    <Region Name="Cape Cod ASCAT B">

  <Map Url="WMBas85.png" Contents="Metop-B ascending" Area="85" />

  <Map Url="WMBds85.png" Contents="Metop-B descending" Area="85" />

      <Area Name="85" lat1="38.889N" lat2="51.082N" lon1="75.183W" lon2="59.822W" />

    </Region>

    <Region Name="Bermuda ASCAT B">

      <Map Url="WMBas86.png" Contents="Metop-B ascending" Area="86" />

      <Map Url="WMBds86.png" Contents="Metop-B descending" Area="86" />

      <Area Name="86" lat1="28.9871N" lat2="40.810N" lon1="75.1843W" lon2="59.8349W" />

    </Region>

  </Server>

  <Server Name="ASCAT C" Url="https://manati.star.nesdis.noaa.gov/ascat_images/cur_25km_METC/zooms/">

    <Region Name="Cape Cod ASCAT C">

      <Map Url="WMBas85.png" Contents="Metop-C ascending" Area="85" />

      <Map Url="WMBds85.png" Contents="Metop-C descending" Area="85" />

      <Area Name="85" lat1="38.889N" lat2="51.082N" lon1="75.183W" lon2="59.822W" />

    </Region>

    <Region Name="Bermuda ASCAT C">

      <Map Url="WMBas86.png" Contents="Metop-C ascending" Area="86" />

      <Map Url="WMBds86.png" Contents="Metop-C descending" Area="86" />

      <Area Name="86" lat1="28.9871N" lat2="40.810N" lon1="75.1843W" lon2="59.8349W" />

    </Region>

  </Server>

</OCPNWeatherFaxInternetRetrieval>

and here are the coordinates we need to add to the coordinates file:

<Coordinate Name="ASCAT B - Cape Cod ASCAT B - 85" X1="0" Y1="650" Lat1="38.889" Lon1="-75.183" X2="740" Y2="0" Lat2="51.083" Lon2="-59.822" Mapping="Mercator" MappingMultiplier="1.0000" MappingRatio="1.000" />

<Coordinate Name="ASCAT B - Bermuda ASCAT B - 86" X1="0" Y1="650" Lat1="28.987" Lon1="-75.184" X2="740" Y2="0" Lat2="40.810" Lon2="-59.835" Mapping="Mercator" MappingMultiplier="1.0000" MappingRatio="1.0000" />

<Coordinate Name="ASCAT C - Cape Cod ASCAT C - 85" X1="0" Y1="650" Lat1="38.889" Lon1="-75.183" X2="740" Y2="0" Lat2="51.082" Lon2="-59.822" Mapping="Mercator" MappingMultiplier="1.0000" MappingRatio="1.000" />

<Coordinate Name="ASCAT C - Bermuda ASCAT C - 86" X1="0" Y1="650" Lat1="28.987" Lon1="-75.184" X2="740" Y2="0" Lat2="40.810" Lon2="-59.835" Mapping="Mercator" MappingMultiplier="1.0000" MappingRatio="1.0000" />

The programmer can get these values from the dimensions of our file size, which is always the same at 640 height and 740 width, using the data we provide in our KML files, which in these two cases are: 

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">

<GroundOverlay>

<name>Bermuda ASCAT B Ascending</name>

<color>7affffff</color>

<Icon>

<href>https://manati.star.nesdis.noaa.gov/ascat_images/cur_25km_METB/zooms/WMBas86.png?</href>

<viewBoundScale>0.75</viewBoundScale>

</Icon>

<LatLonBox>

<north>40.81048097146506</north>

<south>28.98713385708333</south>

<east>-59.83499451605183</east>

<west>-75.184380929696</west>

</LatLonBox>

</GroundOverlay>

</kml>

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">

<GroundOverlay>

<name>Cape Cod ASCAT B Ascending</name>

<color>7affffff</color>

<Icon>

<href>https://manati.star.nesdis.noaa.gov/ascat_images/cur_25km_METB/zooms/WMBas85.png?</href>

<viewBoundScale>0.75</viewBoundScale>

</Icon>

<LatLonBox>

<north>51.08285287270985</north>

<south>38.88930541210142</south>

<east>-59.82222792454112</east>

<west>-75.18387376026712</west>

<rotation>-0.5009419918060303</rotation>

</LatLonBox>

</GroundOverlay>

</kml>

Note that ascending and descending for both B and C are the same dimensions, although the files have different, systematic names. The file number changes, here 85 vs 86, and the term METB changes to METC, plus the ascending vs descending changes from WMBas85 to WMBds85.

Here is what we see when we append the new ASCAT servers into the NAVY retrieval file and also append into the stock coordinates file the four listed above:

Viewing ASCAT winds in OpenCPN

My guess is that one of the talented developers that contribute to OpenCPN could download all 48 of our ASCAT regions and then write custom code to open each one and generate the right retrieval and coordinate statements to make it work for all of this data.  I also guess that this would not take too long. We have spent a large amount of time  in creating what we have, with the hopes that the rest will go very fast.

In the meantime, if someone could benefit from this data before that happens, the process can be created manually as we have done here.