Polar Wave Spectra

 

This is a place holder for soon to follow instructions on the use of polar wave spectra plots for understanding the seaway and for setting up optimum routing corrections for waves, including how to generate the plots with our new, free 

 Polar Wave Spectrum Plotter app

Notes on S-100 and the Eventual S-101 ENC Display Standard

Background

At present all ENC content and structure (internationally) are based on the IHO S-57 standard, and how these ENC should be displayed is determined by the IHO S-52 standard. ECDIS systems are required to follow the S-52 standard precisely, which does include a few display options, whereas most ECS strive to follow those standards, but they are not required to. Some apps are far from the standard, others, like qtVlm, are remarkably close to the standard.

The change from S-57 to S-101 ENC will be part of a huge change in overall electronic navigation, described as S-100, the Universal Hydrographic Data Model, which includes: 

S-101: Electronic Navigational Charts (ENCs)

S-102: Bathymetric Surface

S-104: Water Level Information

S-111: Surface Currents

S-412: Weather Overlay

Note that the S-100 based product specifications include more parameters than listed here, and indeed their item numbers do not all start S-1xx, as noted in this weather data component. Indeed, the system is intended to encompass all aspects of coastal navigation and hydrography.

 

The new system is much more GIS oriented with various new overlays. Except for the S-101 ENCs themselves, the other components of S-100 are well underway already, with tremendous promise. With digital soundings and tide heights everywhere on the chart, we are then aware of the actual water depths everywhere, which can also be forecasted continuously over time.

So far the S-412 weather products do not add to what racing sailors have been using for years with GRIB formatted model forecasts overlaid on their charts, but this will make the data more universally available to commercial and governmental vessels in the future. Unfortunately, the GRIB format we are all accustomed to, created specifically by the WMO for weather work, will be replaced in S-100 by a new h5 format, that so far none of the popular ECS apps or ECDIS can read! 

Because of the h5 format, it takes extra work to view these new data sets. We have notes on this elsewhere, along with custom conversion apps. 

But the question at hand is the charts themselves and what will govern how they should be displayed, keeping in mind that we are looking ahead, and largely just answering a question that might have come up. S-101 charts are likely to be 5 or so years out, and hopefully by that time the rest of the S-100 suite will be well underway.

Here are notes on the S-101 ENC display standards as presented at the moment.

S-101 absorbs the display standard into itself — it will not be a separate numbered standard.

Unlike the S-57 family (where S-57 = data, S-52 = display, S-58 = validation, S-63 = encryption, as four separate documents), the S-101 ENC Product Specification covers content, structure, data encoding, and metadata for S-101 ENC data, and the same specification also includes the portrayal (display) requirements for use within ECDIS. So portrayal/display rules are baked directly into S-101 as its Portrayal Catalogue, rather than living in a standalone "S-52 equivalent."  The S-101 Portrayal Catalog is analogous to the S-52 Presentation Library.

Conceptually, S-101's portrayal does the same job S-52 does today.

S-101 is similar in content to the current S-57 object catalogue and S-52 presentation library, but implements the dynamic constructs prescribed by the S-100 framework. The key structural difference: in S-101, the relationships between features, attributes, and enumerants are defined in a single feature catalogue, and the portrayal catalogue links those feature catalogue elements to their graphical representation — both built through a machine-readable registry rather than being hard-coded into ECDIS software.

Why this matters practically.

Under S-57/S-52, catalogue updates (new symbols, new display rules) are embedded in ECDIS software and can take up to five years to roll out via software updates, whereas under S-100/S-101 the feature and portrayal catalogues are versioned in a continuously-adapted registry, letting updates happen via catalogue update rather than a full software upgrade cycle. 

There is active work explicitly comparing the two. 

The IHO's S-101 Project Team has a working document titled "Allowable Differences Between S-52 and S-101 Display," and earlier project team materials describe an explicit S-52 to S-101 portrayal gap analysis, along with a list of S-52 symbols no longer required in S-101 and proposals to retire some symbol definitions — so the transition is being managed carefully, symbol-by-symbol, rather than a clean swap.

Summary.

There won't be an "S-52 for S-101" as a separate cross-referenced document the way mariners are used to. The display rules will be part of S-101 itself (its portrayal catalogue), with the additional change that the rules can be updated from within the S-101 ENC itself.

Details of the above topics and S-100 more generally are at the IHO web site.

Shapefiles for qtVlm

May 31, 2026 update: added US states and bumped this note forward,

A powerful function of qtVlm is its ability to show shapefiles in a very convenient manner. They can even be configured to include links to live data. One example is the UK shipping forecasts that we made for qtVlm some time ago, which we put here at the top of the list.  But we need a list because there are many of these floating around that can be very useful for navigation, and I am beginning to loose as many as I find. Just found a couple neat ones for the Gulf Stream, which motivated setting up this index.

(1) UK Shipping forecasts
Note this is a special type of shapefile in that Starpath has made code that lets you get live forecasts at each zone. Normally shapefiles load static data. If we want overlays that update automatically we need to have links to images or KML files.

(2) Add elevation contours to an ENC

(3) Add north and south walls to the Gulf Stream plus Add eddies with ID 

The above Navy data were typically updated every 36 hrs, but at present (4/30/25) it is nearly a month old. So we need to keep an eye on this.  There is a lot of chaos in ocean and weather data delivery these days. A sample below:

These shape files (two are loaded here) are to be overlaid onto either the RUCOOL SST images or one of the model forecasts for the current, or overlay onto the Navy Gulf Stream Analysis to annotate what they show. These eddies will coincide exactly with what are on the Analysis maps.  Note too that these shapefiles have to be downloaded  each time they are new, which is typically every 36 hr. They are identified by day of the year, ODate, ie in 2025, 90 = Mar 31.... however, as of May 4, 2025 we are seeing only erratic updating on Navy GS products, so their fate is uncertain.

(4) Up dated US Forecast zones

(5) US state borders with state ID

The zip file US_states.zip brings with it two sets of shape files. One is the outlines only where there is a tool tip showing the state, but it is not always clear which side of the boundary it refers to. The second shape file solves that problem by planting a mark at the centroid of each state with the states name.  The download brings both files into qtvlm, but you can choose to show either one or both. To show both, you need to load both individually.

Lunar Distance by Calculator — The Letcher Method

The lunar distance method is a way to find UTC by measuring the angular distance between the moon and an adjacent body (sun, star or planet).  The measurements are called "lunars." And finding UTC is equivalent to finding your longitude. Recall we can find an accurate latitude without knowing the correct time, but standard procedures requires accurate time to find longitude. Lunars are thus a way to fill in your position if you have lost accurate time—or, starting from scratch, you never had accurate time.

It is an advanced skill in cel nav, because it requires very accurate sights and special analysis. Finding UTC to an accuracy of ± 30 sec or so is considered good work. We have notes on the history and practice of the method (starpath.com/lunars), which shows that there are essentially three approaches to the solution.

The first solution is the easy one. There are numerous apps online and for sale that solve lunars. Our own StarPilot was one of the first ones.  With these apps, you can just enter your DR position, the date and best guess of the right time, the name of the body you are using, and the lunar distance. There is usually an optional input for the measured altitudes of the moon and body, but these are not needed accurately, so they can be computed from the DR position. 

Everything else is computed and the output is the right time and right longitude, keeping in mind the uncertainty of the process: namely, every 0.1' of error in the  measured distance or clearing process leads to about 12 sec of time error, which corresponds to 3' for longitude error. 

The second solution is just the opposite: do it all by books and tables, like it was done in the late 1700s to early 1800s. The only math required is adding and subtracting longish numbers, but the tables and procedures can be complicated. With that said, this is the only logical solution, in that it is waterproof and no batteries are required.

Luckily, we have a modern all-paper solution created some years ago by Starpath friend and associate the late Bruce Stark. His book Stark Tables for Clearing the Lunar Distance — And Finding Universal Time by Sextant Observation has become a modern classic in cel nav studies. Experts consider his solution superior to some of those actually used historically (see discussion in the lunars link above.) But like the historic versions, doing this all with tables takes some practice before it becomes routine.

The third solution, which is the subject at hand, is a compromise of sorts between the first two. Namely we use a set of four trig equations that we can solve on any simple trig calculator along with standard sight reduction tables and a Nautical Almanac, and we compute the solution "by hand."

To my knowledge, this method was first put together by John S. Letcher, Jr in his excellent 1977 book on cel nav called Self-Contained Celestial Navigation with H.O. 208.  He was also a major technical authority and innovator of self steering devices, as presented in his 1974 book Self Steering for Sailing Craft. Both books are rare, but still found periodically in used book sites.

Below is an outline of his method. It has been elaborated upon in the 1980 book by Shufeldt and Newcomer called The Calculator Afloat, which is online in full. 

To help learn this process, we made an app (Letcher Lunar Distance Calculator)  and spreadsheet that solves the Letcher method that can be used to double check that you are computing the terms correctly. The app includes the examples presented in both books above. There is no logic to using this for actual solutions as there are other apps that are equally, if not a bit more, accurate that require much less input. The app and spreadsheet are purely training tools.

The idea here is you practice this a few times then write this prescription in your logbook to fall back on as needed, keeping in mind that the StarPilot, which covers all aspects of ocean and inland navigation computations, includes a lunar solution if needed.

It is important to skim over the discussion in the lunars link above. The summary is:

1) We measure the distance between moon and another body , which will be edge to edge. Then we use the Almanac to find the semi diameter of the moon (and sun if using it) so we can correct the edge to edge to get D, the lunar distance center to center, at time Ts which is our best guess of the UTC. In practice we need to take several sights and plot them D vs T then do a best fit to the line and find our best estimate of D and its corresponding Ts.

2) Then we "clear" that distance, which in this case means applying two corrections to D, refraction (R) and parallax (P). These corrections require us to compute the Hc of the moon (Hm) and of the body (Hb) at time Ts, which we do by looking up their GHAs and Decs, and then compute the distances with the formulas below. 

Note if you are underway, or have good horizon for the bodies on land, you can measure these heights in the normal way, and plot them to find a fix. The Lat of that fix will be correct, but the Lon will be off by the error in Ts, which we are finding from the lunars.

3) Once we have the cleared lunar (Dc) we need to see what time the two bodies where that far apart. We do this by computing the distance a the whole hour before Ts and at the whole hour after Ts.

Note that the lunar distance is just the zenith distance (z) to the moon assuming you are standing at the GP of the body being used. Thus D = z = 90º - Hc, which we can compute using the navigation triangle formula below (we just change our a-Lat to the dec of the body and our a-Lon to the GHA of the body).

Here is how the app input looks, showing also the Almanac data we need to enter.

Here is the sample solution from the Shufeldt book.

Once we have our measured Dc, we need to find out what time were these two bodies that far apart, keeping in mind the main premise of this measurement being that the moon moves eastward relative to the other bodies in the sky at a rate of about 12º per day, which is about 2' per minute. Not much, but right at the edge of our being able to measure this with standard sextant.

We figure this by interpolation as shown below:

Then within the accuracy of this method, Tc is he right time and Tc - Ts is our watch error.  The corresponding Lon error is 15'/1 min of time error.

The app is essentially two worked out examples that you can test with your own calculator.  The spreadsheets are there for those who want to look at that to see how these equations are entered into Excel.

Note that both examples given in the app are from May 27, 1973, so to follow though each step, here is the almanac data for that date that shows where the input came from.

These data are also needed if you want to check any of the online apps, as they typically want input of raw sextant data and then they compute everything, so to use them we have to unfold the two heights to Hs values and the LD they want is edge to edge, then they make the corrections in the apps.  Convenient for use underway, but not convenient for checking the Letcher method, so let me just add that the Letcher method does indeed work (within limits noted below), and can be improved a bit more by adding easy corrections for augmentation of the moon's SD and earth oblateness.

Letcher streses that his procedure for the important refraction correction is not valid for moon or body altitudes or lunar distances less than 10º and also the method is not valid for Venus and Mars since parallax and phase corrections are not addressed. These are not severe limitations for practical use, but we should keep them in mind.