Saturday, January 30, 2016

How to Verify Computer File Integrity

Is this really navigation?  I would have to say no, unless we are talking about really modern times where the navigator gets more and more involved with computer programs and computer files.

We have been working on converting weather maps to echarts, which has led us to using several open source utilities. Often free programs we download online can get corrupted or polluted by accident or some malware.  Or maybe we want to send someone a file of data or a gpx file of a long list of way points or a detailed GPS track, and we worry that loading or unloading of it from an echart program might change the content of the file in some way. Or maybe you just want to send a long text document to someone and be sure it has not changed when it gets there or when it goes somewhere else.

It turns out that the tech world has a solution for this, which I suspect is well known to those who know it well.  It is called the MD5 sum. It is a unique number created by an encryption program that is a fingerprint of that file.

To use it, you need a program that reads the MD5 value of a file (any file: executable, image, text, etc) and then you just use that program to read the MD5 sum of that file and post it, or tell the recipient what it is.  Then when they get the file, they run it through the same program to check the values.  If anything at all has changed in that file, just one dot or one space, then the MD5 sum will have changed and you will know it has changed.

This test does not tell you what has changed, but I believe there are numerous programs that will also compare files to detect the change. But for images or encrypted executables, you still might not know what has changed.

This very easy to use test is just to confirm that it has not changed. That is all.

One convenient version I have found is called WinMD5.exe.  An example of the use of this is in this video below confirming the authenticity of the open source graphics program called Gimp... which we are suggesting could be useful for making BSB files from images.

Converting Weather Maps to BSB echarts

Our goal is to convert weather maps to echarts for use in forecast evaluation (overlaying model forecasts) and general route planning. We started with the easy ones, namely the color maps from OPC that have a nice lat-lon grid on them that lets us scale the margins of the charts. This way we can make a prescription for doing this that does not involve trimming the charts for each conversion.

Underway, however, we are most likely to have access to the black and white tif maps that we can get from saildocs in reduced file size.  The problem that comes up immediately is these maps do not have a nice lat-lon grid; it is shown only every 10º with large blank margins. Thus are simple approach of making the header files by hand does not work for these maps.  I have tried numerous tricks that I thought would work around this, but none succeeded. We are standing by for an easier solution if someone has it. Just post a comment.

One approach that does work is to call up two more custom programs and built the map in several steps.

Step 1. This always has to be done: download the map and convert to a png, and read the dimensions of the chart viewed upright—we typically get the maps sideways as tifs.

Step 2. Georeference the chart and define the borders using MapCal_2, and save what it calls chartcal.dir, which is a text file you can open in notepad.  This step is illustrated here:

Video Note: watching carefully you will see a blunder being made on the bottom right cal point, but it got caught and corrected during a simple check at the end.... nice to have such things to see how this works!  There is also an error early on calling a png file a gif file. Unfortunately, nothing to learn from that if we rule out author evaluations. 

Step 3. Use the program mc2bsbh to build the header from the chartcal.dir. The extension of the header made this way is .hdr.  We need to change that to .kap before using imgkap (you could also create one with the right name, but this is just as easy).

Step 4. Proceed to convert the png to a kap file with the header just created using imgkap.

In an earlier video-illustrated post we did this making the header file by hand, which worked for easy to scale charts that have a full lat-lon grid. That does not work for these BW maps with large vacant borders and few reference lines, which is why we move to this procedure.... at least till we learn a better way. On the other hand, once you have these utility programs in a folder, it is probably fastest to use this present method for all charts.

( I should mention for completeness, that if one has the high-end navigation program called Expedition, you don't need any of this. You just import the image, georeference two opposite corners with a slick, fast interface they have, and you are done, and ready to view the map as an interactive chart.  It is then saved for later use or for overlaying model forecasts, etc. One minute would be a long estimate of the time it takes from beginning to end! )

In principle, there is a package of utilities called kapgen that will do all of what we describe above at once, but I have not had any luck yet with using that.

It took long enough to learn to do what we do here that I want to document this process before I forget the details; later we might return to figuring out what we are doing wrong with kapgen.

All of these methods are described in the OpenCPN manual or FAQ, or links they provide. It seems easy enough when reading about it, but there are nuances that I hope we point out here.

Program sources:

imgkap.exe from

mc2bsbh.exe from

MapCal_2.exe comes from installing the program SeaClear. Install the program, then look in the Programs Files directory, and from their you can make a shortcut to MapCal_2.exe for your desktop or other folder you are usin for the conversions.


For reference, here is the header file we created for the epac surface analysis, a map that is 1446 x 1728. With this, all you need is imgkap to make a chart out of any epac surface analysis. This is for the full size maps. We need to make another one for the saildocs versions that are half this size.

! Created by mc2bsbh beta09 - Use at your own risk!

Tuesday, January 26, 2016

Weather Maps—Where To Get Them and What We Get?

When we are underway paying $1.50 per minute for satellite phone time, we clearly care if we can get the same weather map from one place that is much smaller in size than from another place, not to mention that some services might not even allow larger files to be transmitted. The latest surface analysis of the Eastern Pacific, for example, can vary from 13 to 312 kb, with multiple options in between. Again, these are the same maps.

But not only download air time matters. Storage space on our computers or tablets underway, as well as the time it takes to process the files when we look at them in different applications are also factors that make us aware of file size.

Our present project at Starpath is studying ways to get these graphic maps into an echart program (i.e. convert them to nautical charts) so we can see our precise position on the map, read precise ranges and bearings, and also to compare these professionally produced graphic products with the vectorized grib format of single numerical model predictions, such as the GFS. With the weather map made into chart we can overlay the grib forecasts right on top of the graphic forecasts.

We want to use the digital grib forecasts as much as we can because route analysis is much easier with them, We can also read digital values of wind and pressure at any point on the map—not to mention that if we are using an automated weather routing tool we must use the grib files.

But any single numerical model forecast might not be right. We need to compare them with the forecasts made by the NWS, who are looking at several models in addition to the GFS as well as other factors when making their forecasts. The pure GFS will be close to the truth much more often than far from the truth, but actual differences can be crucial in some circumstances, especially with newly developed or fast moving systems. It is simply prudent navigation to compare them on some level.

To make a chart out of a map, we first need the graphic file of the map, which leads to this topic at hand.

Our own Starpath Custom Briefings pdfs discussed below (one for the Atlantic and one for the Pacific) are very convenient ways to request any of the maps, both onland and underway, so we will look at this option after looking at the more standard sources.

We will use the 12z Eastern Pacific Surface Analysis for the example, but other products have similar results. And we list file size as downloaded—which has to be said when the options include tifs, which increase in size notably when you do anything at all to them! Some maps are presented sideways, so they have to be rotated to be read or manipulated, which if tiffs will notably increase their size, but this all takes place after they are on your computer.

Note too that capitalization of name and extension matters in the file names. NOAA now has some in color and others in black and white (BW). Below we give dimensions as w x h as viewed in normal portrait mode. Sideways means we get the map in landscape mode and have to rotate it.

Where to download the maps
The main source of weather maps is the FTP site at NOAA, all are there with a specific file name for each map along with (for some, not all) a file name that represents the latest version of that map. For example, PYBA05.tif is the 12z surface analysis of the East Pacific. It updates once a day at about 1430z to the current day’s map for 12z, but the file name remains the same.  Likewise, PYBA07.tif is the map for 18z. But there is also a map called PYBA90.tif which is the latest version of this 12z analysis. It could be the 00z, 06z, 12z, or 18z map, which ever has updated the most recently.  Usually we want the latest version, but there could be reasons for looking at a specific map that is outdated.

If we know the file names, we could get them directly from the FTP link. But there are several sites that index the maps so we do not need to know specific file names... but what is at the other end of these links is what we look at now. In passing, the system of keeping the same file name and updating the contents daily is a real blessing when it comes to working with these maps.  Some other sources, and most European maps, have the date and time built into the file name, which really complicates any automated acquisition of them.

File names for NWS surface analysis maps. From Modern Marine Weather

Starting with the neat shortcut link, which is a nice portal to all weather products, we can find the graphic map links. They link to map indexes in three different formats, but as we shall see, it is only the index layout that changes, not the maps. The link to the map index options is and here is what we find.

Main link (select valid time)       37 kb    1446 x 1728    BW    sideways         90 kb    1446 x 1728    BW    sideways    90 kb    1446 x 1728    color    upright   

Condensed versions (same as main links but only latest)     37 kb     1446 x 1728    BW    sideways      90 kb     1446 x 1728     BW    sideways

Hyperlinked schedules at     90 kb    1446 x 1728    BW    sideways    37 kb    1446 x 1728    BW    sideways

Mobile version (latest only) at    90 kb    1446 x 1728    BW    sideways

So knowing the maps are the same you can choose the index presentation that best meets your needs.

These links (except for the color maps) are direct to the FTP site:  The color maps seem to be a product of the Ocean Prediction Center, which I believe is where they are produced. They also provide a side link to another interactive radiofax schedule, but the maps we get there are in slightly different sizes than on the FTP site, which makes them less attractive for our purpose of making echarts out of them. Notice too that they use a different format for the file names—extensions and names all lower case.        312 kb      1440 x 1728    BW     upright        105 kb     1332 x 1600    color   upright     86 kb     1440 x 1728    BW     upright       

A very convenient way to request maps on land or underway is our own Starpath Custom Briefings. These are pdf graphic indexes to each of the maps, organized by map type and forecast period, including notes on each of file size and update times. The link above explains the use of the briefings. These briefings make use of the wonderful service of, which reduces the file sizes by about a factor of two. This is a blessing when underway on limited bandwidth.

In the Starpath Briefings we link to the saildocs latest version of each map, which you request by email from saildocs with a single click and send. In the example we are using here, they will send back to you in return email the PYBA90.TIF that is normally 37 kb at 1446 x 1728 reduced to 18 kb at 864 x 723, also sideways. This tif format will double in size when you rotate it and save it, but it was small when you downloaded it. The reduced file size is still plenty legible, but it does not get better when the size doubles after rotating.

Download  Starpath Atlantic Maps Briefing pdf index

Download  Starpath Pacific Maps Briefing pdf index.

For Reference (not needed when using the Starpath Briefings):


Saturday, January 23, 2016

Weather Maps to eCharts—Making the Header File

In a recent note I outlined how to make a BSB compatible echart from a graphic image of a weather map using a utility called imgkap.  The key to that process is the header file that tells imgkap how to process the image into a .kap file that reads in an echart program.

Our goal is to provide a set of these header files covering each type of weather map so the process can be quick and painless.  On the other hand, if you do want to get a little pain into the process you can see below how these header files are being made. There might even be other reasons, as something like this is required to georeference any image you  might want to use for live navigation. My main goal for writing this up is to document the process if we need it later. Some of the steps took a while to figure out, and would be easy to forget.

Several details of this process discussed here are illustrated in the video below. Later we will add the most important article and video, namely what to do with these georeferenced weather maps once you have them.

We will use a Surface Analysis map for this example.  Here are the steps (you might skip to the bottom for a moment to see the header file we are creating).

Step 1.  Download the image. The maps we are working with now are the new (as of last 2105) color format from OPC. Some are in the png format, others are gifs. The gifs must be converted to pngs, which can be done with most graphics programs, including the stock Paint program in Windows or Preview on a Mac. Just load the gif and save or export as png.

(Later we address the black and white tiff files of the same maps. These have a few special issues to address, including rectangular pixels! )

Step 2.  Read image dimensions (w x h), i.e. 1332 x 1600
In the header file, this is then RA=1332,1600

Step 3. Figure DX, DY = meters per pixel (m/px):
One approach is choose a latitude near the center of the chart, and measure the height of a rectangle some degrees on either side. For example,  if 40N is in the middle, measure the pixels between 30N and 50N, i.e. 587 px. We are going to call the Lat where this is valid PP=40.

Then figure m/px from: 587px = 20º = 1200 nmi x 1852m/nmi = 2222400 m, so there are 3786.0 m/px.   So DX=3786.0,DY=3786.0.

Aside: We have the option for different DX and DY values in the header. All NOAA Mercator charts have square pixels and these are the same for wx maps in png format. (Not sure yet what we will need to do here for the tifs).

Step 4.  We next figure a chart scale, which is needed for the header. The concept of chart scale is transparent for RNC, which are copies of printed charts that do indeed have a scale, i.e. 1” on a 1:80,000 printed paper chart is 80,000 inches on the land. This is not so clear a concept for these weather map files that do not have a standard print size. But we do have to input a dpi for the image called DU, so once we choose that along with the DX,DY values we are committed to a scale.

The png or gif files when downloaded are likely to be at 72 dpi when downloaded on a Mac or 96 dpi when downloaded to a PC. So the 587 px we measured for 1200 nmi, would (using a Mac) correspond to 587/72 = 8.15 inches, which is = 1200 nmi x 1852m/nmi x 100cm/m x 1 inch/2.54cm  = 87496063 inches, so the scale is 1: 87496063 / 8.15 = 10735713 = SC in the header.

You can do the above for whatever dpi the image comes with. It will not matter  so long as we are consistent as outlined above. The dpi value is not a property of the image. It is only related to printing, which we are not doing. What we are doing is fudging a format that was intended to represent a paper chart that had known and fixed dimensions. The announcement a few years ago that NOAA was expanding all of their RNC from 250 dpi to 400 dpi was just a way to say the file dimensions (w x h) are going to be bigger.

Step 5.  Now we have to figure the Lat, Lon of the corners, which involves extrapolation of the scales to project them out to the edges of the paper. (We could crop the images to the scales shown, but that would involve an extra graphics step on each conversion. Doing it this way, we  have no graphics work at all once the header is in hand describing the full image.)

In this surface analysis image the Lon meridians line up nicely with the edges of the images at -175.0 to the west and -115.00 to the east. Note West Lon and South Lat are negative in this system, which is common.  The top of the chart is 9 px above 65 N, and the width of 64N to 65N is 52 px, so the top edge Lat is 65 + 9/52 = 0.173, so top Lat = 65.173.

The bottom edge of the image is 37 px below Lat 16N, and the width of 16N to 17N is 23px, so the bottom of the image is at a lat of 37/23 = 1.609º below 16N, which is 14.391N.

Measuring the pixel width of the bottom margin (37 px) with the selection tool in Mac Preview (left) and Windows Paint (right). Paint does not show the bottom most line of pixels, so it adjusted up one. Step 1 in both cases is be sure the view is set to "Actual Pixels" or "Normal View." This measurement is more precise with a more sophisticated program such as Photoshop or the open source Gimp, with which you can zoom in to close view and still read the actual pixel count.
Step 6.  Now we can specify both the georeference points and the chart corners, which we have simplified here by making them the same 4 points.  The reference points (called REF/1, REF/2,…) can go in any order and be any number larger than 3, but the 4 corners (PLY/1, PLY/2,…) must go in order, starting at the SW corner and proceeding clockwise.  (Actual NOAA RNC include a reference point for all major lights on the chart!)

Step 7.  Now we can construct the header for this chart, using the standard minimum information as determined above. We will call it EPacSurfaceAnalysis. Pixel locations are referenced to the top left, with X increasing to the right and Y increasing toward the bottom.

! East Pacific surface analysis from OPC.
REF/1, 1,1600, 14.391,-175.0
REF/2, 1,1,65.173,-175.0
REF/3, 1332,1,65.173,-115.0
REF/4, 1332,1600,14.391,-115.0

If we name the image EPacSurfaceAnalysis.png, then we can copy this text and paste into a txt file and save it as EPacSurfaceAnalysis_header.kap, and now we are ready to make our map.

This is clearly a bit tedious, but we do not have to do this again. Once this header is made and tested we can use it as is for all East Pacific Surface Analysis maps in the future. The earlier note presented one that works with the EPac 24h surface forecast.  Then getting a map into the echart program will be just download the file to the right place, run imgkap, and open the map.  In fact, you can just copy and paste this text into a cmd line to get your map:  imgkap EPacSurfaceAnalysis.png EPacSurfaceAnalysis_header.kap EPacSurfaceAnalysis.kap


To learn more about the kap header file see this short description:

To get the primary information about the BSB format go to this link at the International Hydrographic Office.

Thursday, January 21, 2016

How to load NOAA Weather Maps into OpenCPN

With the latest surface analysis and forecast maps in an echart viewer, we can see our GPS position right on the map and plan routes across the weather patterns. It also facilitates reading wind and pressure from the map at places where none are shown. Another important application is overlaying the GFS grib forecasts on actual NWS forecasts to evaluate the GFS data—in areas where we do not have digitized NWS forecasts in the form of NDFD gribs, in which case this could be done more easily by just comparing gribs.

We discuss this in Modern Marine Weather in Section 7.2 called Georeferencing Weather Maps. In that discussion we had recommended the program Memory-Map Navigator as a way to do this as it was possible with their free, demo version. That program still has this functionality, but the demo version no longer includes this option.  Other commercial products also offer this, including Ocens MetMapper, and Polar View. In principle the free program Sea Clear can do this, but I have not yet succeeded with that. All of these solutions can create a weather map echart, but they would each be unique to their own viewers. The procedure below makes a file that will open in any echart viewer.

Our electronic charting and weather training now use OpenCPN for the in class exercises, so the goal at hand was to develop a method for loading weather maps into OpenCPN. The final product should in principle open in any echart viewer. The explanation of the process is outlined below, followed by a video showing each step in action.

We will use a free utility called imgkap.exe for the PC. It is used to convert images to the .kap file format that is used in the RNC echart format, also called BSB.  Once the file is made, it will open in Mac or PC versions of OpenCPN. I do not know of a Mac equivalent, but there could be something.

Below is the step by step procedure, and here is a video that shows the steps in action using a later 24h surface analysis.

Step 1. Download a copy of imgkap.exe (Windows binary, v 1.11, 3.5 MB) from This program is discussed at that link as well as in the OpenCPN Manual at this link

Step 2. Make a folder on your desktop called imgkap and put imgkap.exe in it. Needless to say, you can call things what you want and store them where you want; we just need one place to put all the parts. We will need three parts: this program, the map image itself, and a header file that tells the program how to make the kap. With the nice tools made available to us, the work reduces to making the header file.... and I hope to reduce that part of the work by providing a header file for each of the standard wx maps we get from NOAA.

Step 3. Download the weather map image and save it to the imgkap folder. We use here the example of a 24h surface forecast for the Pacific, which you can get from  This gif image should be 907 x 1200 pixels. The main index to all of their maps is at — click the ocean tabs to get to the maps. Below is the top part of the map we are working with.

Step 4. Convert that gif to a png using a graphics program. This can be done in any version of Windows by right clicking it, choose Open With, select Paint, then after it opens Save As, choose png, save it, and close Paint. Then you will have two images in the folder a gif and an png. You no longer need the gif and could delete it.

Step 5. Now create the header file: Open Notepad and copy this text into it:

! 24h pacific surface forecast from OPC.
REF/1, 1,1200, 15.7,-157.0
REF/2, 1,1,62.5,-157.0
REF/3, 907,1,62.5,-108.0
REF/4, 907,1200,15.7,-108.0

Note that the indents matter; they signify that the line above it was more than 80 characters, which is the limit. No blank lines before this text and none after it.

Then save this notepad file in the imgkap folder and name it P_24hrsfc_header.kap.

Step 6. Now we are ready to make the kap file. Now open a cmd window, ie from the Start button or equivalent type cmd and enter and the window will popup.  Then type cd desktop/imgkap and enter and you should see something like this:

Then type   imgkap P_24hrsfc.png P_24hrsfc_header.kap filename.kap   and then enter. Filename is anything without spaces you want to name the map, ie 24h_valid_12z_jan16.kap.  You can copy and paste this into the cmd window if you like with right click and paste—assuming you are using the same file names. Put another way, you can make your own generic file name convention and just use that each time as long as you have the right extensions and list them in the right order. You will get a clear error msg saying what is wrong if you make an error.

Or you can just type imgkap and enter to see the inputs and the other things you can to with this utility, ie you get a help file.

Then if you do not get error messages you will have another file in the folder called filename.kap.  This is the file that will open in OpenCPN as a georeferenced wx map. Here is what you see after a successful map.

At this point, we need to just move the newly created file into a place the echart program can read it as shown in the video.

Here is what the map looks like in OpenCPN.

A final note on use of this type of home made kap file in other programs. Some echart viewers require a second descriptive file be created as well called (in analogy to above) filename.bsb.  OpenCPN does not require this; it just flashes a note that there is no information on the chart. The .bsb files are relatively easy to construct from the information in the header file. I will leave that till it comes up in a specific need.

For example, one of our favorite echart programs is Coastal Explorer from Rose Point Navigation. This program does require the bsb file.  These bsb files are most important for programs that are monitoring your charts to be sure they are up to date. They are also used in ECS functionality that links hotspots on the chart to announcements or corresponding Coast Pilot data and so on.

There is a note on how to make the header files here, but once you have one you can use it without knowing the details of how they are made.


Friday, January 8, 2016

How to Check the Accuracy of Airport Weather Reports

Barometers and the role of barometric pressure in marine navigation has been an ongoing focus of interest at Starpath since the mid 1980s. We make books on the subject, offer extensive online training in the optimum use of barometers, and we have even designed a state of the art barometer ourselves, which is now used by the NWS, Navies, and individual mariners around the world.

Thus it is no surprise that we appreciate related valuable contributions to this field. One that we have known about, praised, and used for many years is the subject at hand. It came up today in class when a student was following one of our course exercises on calibrating his own barometer using online pressure resources, in particular an airport pressure reported in the form of a metar.

Essentially all airports around the world offer pressure data in this format, which is available hourly  in plain language, giving sea level pressure in the form of QNH (called "altimeter" in these reports) or QFF (called "sea level pressure").  Both are pressures relative to sea level; the latter is closer to what the weather maps use, although these two pressures do not differ much unless the airport is high or the ambient temperature is extreme, or changed a lot in the past 12h. We have notes on this topic (and related one on temperature dependence of the conversions).

When we use one of these reports, or in fact any of the "official" reports, we tacitly assume the data are accurate, which is frankly—on the level we care about—not always the case.  Luckily, we have a very easy way to check this, which brings us to the Gladstone Family project run by Philip Gladstone.

The Gladstone Family website is a wealth of airport weather related information, but the part we address now is his monitoring or compiling of daily accuracy records of all the pressure sensors used in the metar reports around the world. Samples below are for an airport having some troubles at the moment and one that is doing just fine.

Two reports on pressure sensor accuracy from the Gladstone Family

It is always valuable to check his report when using one of the airport stations for barometer calibration data. I wish we had such a convenient service for the buoy and lighthouse data we get from NDBC.

For completeness I should also mention our own free service for doing something similar, using all official sources, including buoys and lighthouses, as well as airport metars.

You can read about how the Gladstone Family reported accuracy is determined. As I read this, they use  the same methods the NWS uses to evaluate ship and other station reports before incorporating the observations into the model forecasts.

Our free online service works differently.  It is located at  There is a detailed help file with an explanation of the process there.  Briefly, we do this:

You enter the Lat-Lon of your barometer, and we find the nearest 10 stations to you that have accurate pressure online. Then you look at a plot of their location relative to you, so you can decide which 4 or 5 (or more) offer a uniform distribution of references in all directions.

At this point you could just choose the closest one and use that, but you can do very much better.  Print out our form for entering  pressure data for this application. Then select at least 4 of them, and go to each one and record two times and two pressures that span a time you have a pressure recorded from your own barometer.  Once you have these 4 or 5 sets of data, enter them into the online version of the form and submit.

Our program will then normalize them all to a common time, and then do a least squares fit to a 3d pressure surface that spans this area, and then it drops a point at your Lat-Lon, which is equivalent to an average of all nearby sensors. This is an accurate sea level pressure value you can use for your calibration at a specific time.

But this is not yet analogous to the Gladstone Family service. So far we have only found an accurate pressure, but do not know its uncertainty.  The figure below is the final output from out method, and the numbers on the right are related to this question.

The bottom line is the best estimate of your SLP at the time given.  Pavg is the reported pressure at each station, normalized to the one common time. Pcomputed is the pressure we get from our computed surface at each station at this time. Delta is the difference between these two, which is a measure of how consistent that station is with its neighboring stations. If all stations agreed precisely, these deltas would all be zero.

In the example shown, we see that #1, 3, 4, and 5 are all consistent to within ± 0.5 mb, which is about all we can hope for.  #2 is questionable, but OK. The one that stands out is #6, off by more than 2 mb relative to the others.  When something like this is observed, we should just remove #6 from the list and do the pressure surface computation again, and generally you will see all deltas get smaller and the resulting pressure for your location will be better.... maybe not much, but better.

Thus we also have this way to check the accuracy of a pressure report,  but I will be the first to agree that the neat presentation of the Gladstone Family data is extremely valuable and we are grateful for the time he has spent on developing and maintaining that fine service.

To use the Gladstone Family service, look up the 4 letter metar code for the airport in question, ie  google "seatac metar" to learn it is KSEA, and then google "gladstone family ksea."


Saturday, December 19, 2015

How to Find Archived Weather Maps

Normally we care about weather now, or even more often weather in the future, but it can happen that we want to know what took place sometime in the past.  You might, for example, want to review past weather data for the analysis of a voyage or yacht race, or maybe to look into sea and wind conditions from an event you see in the news. Schools like ourselves are often looking though archives for an example of a point we want to illustrate.... and indeed the example given below will answer one of our quiz questions, namely what was the wind speed and direction and the pressure at 30N, 130W on July 4, 2001?

Before addressing this specific question, I note that we are looking for archived data at random places, which often means we need to find the corresponding surface analysis maps. But if you happen to just need the data from a place that has an official reporting station, then the process is much easier.

Just find the station at the National Buoy Data Center and then at the bottom of the page find the link that goes to archived data.  Here is an example from our local West Point Lighthouse, station WPOW1: Historical Data & Climatic Summaries.

The less well known, but far more extensive, source we look at now is called the National Climatic Data Center (NCDC)—or to be more precise, that is what the agency used to be called. The NCDC has been incorporated into what is now called National Centers for Environmental Information (NCEI).  We can hope this frequent restructuring (a common practice in government agencies) is progress and not just job security. (The NCDC underwent a major restructure in how we access data just a few years ago.)

Neat new logo for the National Centers for Environmental Information (NCEI)

In any event, it is almost certain that had we known the new right place to look for what we want, it would take much longer to succeed.  In fact, we progress with our search below using the old name of the agency (NCDC), though it looks like Google does indeed know what NCEI stands for.  We will have to change our training materials to cover the new name.

Below is one path to the map we want for the Pacific surface analysis at 30N, 130W on July 4, 2001.

1) Google NCDC   NOAA   (Later we will look into a new route starting with NCEI.)

2) Find first link  (This will eventually be replaced, but is valid now.)

3) Click I want quick access to your products

4) Choose No. 9, scrolls you down to charts section.

5) Click Analysis and Forecast Charts

6) Select region and map type, i.e. Forecast or Analysis

7) For surface analysis maps, select Ocean Analysis, and click Continue

8) For our example select  Pacific East Surface Analysis, and click Continue

9) Note package limits given. For our example set beginning and end to 2001 07 04, click Continue

10) You will see a list of the 4 maps of that day. Click the .sfc.12 product (that will be the 12z map).

11) Right click and save the map, so you can view it better. They will be in the wrong orientation.

12) Then open it in a viewer of choice, rotate it, and look to 30N, 130W to find the answer.

That is the process and it will show you all the options you have for archived data as you play around with the site.

The video below illustrates the above, and then address the issue that once the map is in hand it might not give you what you want without further analysis, so we include that analysis as well in a second short video. 

The video below shows how to read the data we want from the map, once we have found it.

Monday, December 14, 2015

Viewing and Downloading Nautical Chart with Google Earth

We have been working on using Google Earth (GE) for practice with echart navigation, which led to a couple short videos on the process listed at the end here.  In this process we discovered a remarkable NOAA service that I am embarrassed to say that I did not know about till now.  I am not sure how long it has been online, but it is there now and works great. It is part of their new products on seamless display, that we discuss more at the end here.  The GE feature of that program is the subject at hand.

With this easy to use utility you can see at a glance all 2100 NOAA charts outlined on the GE world map, with the ability to actually view the individual charts, with or without a border, as well as a very quick way to download the RNC echart of any one of them.

The process is explained on a page of the NOAA site called Seamless Raster Navigational Chart Server & Web Map Services, but you pretty much have to know it is there to find it. Once there the main link that is needed is the Google Earth kmz file, called NOAA_RNCs.kmz.

When you click that link it will download the 340-kb kmz file to your downloads, and then just open Google Earth and drag and drop that file onto the GE world. You will see something like Figure 1.

Figure 1. NOAA's GE interactive chart catalog.

Then just zoom to the region you care about. Below is the region we use for our coastal nav training program near the chart 18465.  In Figure 2 I have rolled the cursor over the 18465 boundary, which highlight it, then clicked the boundary line to pop up the control panel shown.

Figure 2. Zoom into a specific chart.

At this point you can start experimenting with the options.  The "collarless preview" loads the chart without the borders; the collared preview shows a full copy of the paper chart with all borders and scales.

Below is a short video about this process, showing some of the neat features it offers, including how to do a a direct download of any RNC echart.

We also have an earlier video that shows a bit  more of using the GE display for practice with echarts, though for work on 18465 it would be best to use the above, latest chart rather than the 18465TR we discuss in this older video.

As noted earlier, NOAA is getting started with their own version of this type of display from their own server, which has a lot of potential, but it is not yet nearly as convenient as the GE version. Especially promising is the counter part they have for vector charts, but this one is even less developed than their seamless raster chart. All in all though, NOAA has been doing a tremendous amount of development of their site with many benefits to mariners.

Wednesday, December 9, 2015

USCG Chronometer Time — Bless Their Hearts

We have often had occasion to point out how the USCG supports navigation schools, but one of the contenders for the top price is their use of chronometer time (CT). Someone making up the tests must have read the fine print of the Bowditch definition and had an aha moment on how they could support navigation schools.

“chronometer time. The hour of the day as indicated by a chronometer. Shipboard chronometers are generally set to Greenwich mean time. Unless the chronometer has a 24-hour dial, chronometer time is usually expressed on a 12-hour cycle and labeled AM or PM.”

In other words, CT is the same as UTC, except for a possible chronometer error (CE) correction, but it can be kept on a 12-hr watch dial.  The insidious step in the USCG exam preparation was to use this concept of CT on a 12-hr dial, and then not tell the test taker if the chronometer time is AM or PM! That way, every single USCG cel nav exam question must start out with the candidate having to figure out what time they meant using other information in the question—it brings to mind the old computer game called Myst

Granted, candidates do need broader cel nav knowledge to figure out the time, but it runs the risk of implying this is, in some universe, a viable way to keep time, which of course it is not. No navigator in the world would use such a system.

So the first step of each USCG cel nav question is to, for example, read the given time of the event as CT = 10h 13m 20s and then use other information in the question to determine if this is 10h 13m 20s UTC (CT was AM) or is it 22h 13m 20s UTC (CT was PM).

Sometimes the process is straightforward, in that we get at least one zone time (ZT) and a DR-lon.  We can figure the zone description (ZD) and from this convert the ZT given to UTC.

The rule for finding ZD is round the Lon to nearest degree, divide by 15, and round the result to nearest whole number. West is + and East is -.  ZD is defined by this equation:

UTC = ZT + ZD.

Below are a few examples of how candidates must figure out the time.

Here is an easy one:
On 15 August your 0512 zone time position was LAT 29°18.0’N, LON57/G 57°24.0’W. Your vessel was steaming on course 262°T at a speed of 20.0 knots. An observation of the Sun’s lower limb was made at 0824 ZT. The chronometer read 00h 22m 24s and was slow 01m 34s.

Find ZD: 57/15 = 3.8, so ZD = +4.  Then UTC = 0824 + 04 = 1224, so CT must be PM, and we get the right UTC = 12h 22m 24s + 01m 34s = 12h 23m 57s.  The chronometer error correction (CE) is normal. If slow you add it; if fast you subtract it.

Another easy one:
On 10 March in DR position LAT 21°42.0’S, LONG 57°28.0’E, you take an ex-meridian observation of the Sun’s lower limb. The chronometer time of the sight is 08h 28m 17s, and the chronometer error is 00m 00s.

No zone time given, and it does not say upper or lower transit, but it has to be upper for the sun viewed from 21S. We also know it must be near midday on ZT.   Find ZD = 57/15 = 3.8, so ZD = -4 and use UTC = ZT + ZD to find ZT = 0828 - (-4) = 1228.  Or it could be ZT = 2028 -(-4) = 2408,  which is near local midnight, so this can’t be right. The first is correct and UTC = 08h 28m 17s   (CE = 0).

Another (sort of) easy one:
On 24 August in DR position LAT 26°49.4’N, LONG 146°19.4’E, you observe an amplitude of the Sun. The Sun’s center is on the celestial horizon and bears 084°psc. The chronometer reads 07h 55m 06s and is 01m 11s fast. Variation in the area is 15°W. What is the deviation of the magnetic compass?
o (A) 8.0°E
• (B) 8.3°E
o (C) 8.5°E
o (D) 8.7°E°.

This is an amplitude problem, so we know the sun is rising or setting. With bearing given as about 069T (084-15), it must be rising, so we know local time (ZT) is early morning.  The ZD = 146/15 = 9.7 or ZD = -10.  So we have two choices for the local ZT, which in turn tells us if the CT is AM or PM. If CT is AM, then ZT = 0755 + 10 = 1755 ZT, or if PM we have ZT = 1955 +10 = 0555 ZT the previous day. That is, going back to the definition of ZD, we have UTC = ZT + ZD = 0555 ZT (Aug 24) + (-10h) = 1955 Aug 23.

Without looking up the sunrise times, we know this must be 0555 ZT (ie CT was PM) and therefore the right UTC of the sight is 19h 55m 06s -(01m 11s) = 19h 53m 55s on Aug 23.

This beauty brings out a couple nuances for test takers to note. For one, the phrase “On 24 August in DR position...” implies that the date is the zone time date.  DR positions are always given in ZT—at least on all the test questions where the date is not ambiguous, and fortunately that is most of them. So we then learn that the CT given could indeed be on a different date. One way to check this is to compute the actual Zn of the sun at that time on each of the two days by standard sight reduction. The result would be:

19 53 55 Aug 23   GHA 117 51.5   dec N11 16.2   Hc = - 0 01.8    Zn = 077.3 (= 092.3 M) -> dev 8.3E
19 53 55 Aug 24,  GHA 117 55.5   dec N10 55.7   Hc = - 0 07.8    Zn = 077.7 (= 092.7 M) -> dev 8.7E

The other point we are reminded of is the wrong answers in USCG exams are not random. It is probably not fair to call the problems “trick questions,” but there are certainly trick answers. Namely, the wrong answers for most USCG exam questions are the result you would get from making a typical error. We see this here by noting the wrong date leads to one of the wrong answers, but the distracting answers in most amplitude questions are more subtle.  The wrong answers are mostly tied to making an error in the conventional amplitude solution (using Bowditch tables 22 and 23), which is the intended way to solve the problem. I have more to say about these amplitude questions elsewhere, but it is beyond the subject of figuring out what CT means.

Here is one a little more involved:
On 16 June in DR position LAT 50°57.0’S, LONG 53°03.9’W (ZD+4), you take an ex-meridian observation of Acrux at lower transit. The chronometer time of the sight is 10h 08m 18s, and the chronometer error is 02m 12s fast.

Again, the ZT of the sight was not given, but with ZD = +4h we can check CT. That is, CT = 1008, means either UTC = 1008 or 2208. The first gives sight time = 0608 ZT; the latter gives 1808ZT.  Under some circumstances we might be able to judge from this much information alone, but not in this case— either one could be within twilight without further knowledge. So we need to check which one of these happens to be in twilight when stars and horizon can both be seen. 

Checking the 1981 Nautical Almanac, and noting that DR-Lon 53º 3.9’ = 3h 32m (Arc to Time table), we find that sight time in the morning (ie nautical to civil twilight) = 0646 to 0812 LMT, which corresponds to 1018 to 1144 UTC.  We find the LMTs in the Almanac, and then correct for the longitude to get the UTC, ie 0646 LMT + 0332 (Lon correction) = 0978 = 1018 UTC.

Evening sights are taken between civil and nautical twilight, which in this case would be 1630 to 1715 LMT, which corresponds to 2002 to 2047 UTC. 

We see that an AM CT is very close to morning twilight time, but the PM CT is not close at all. Thus we know then that the CT given must have been AM, and that the UTC we need for the problem is 10h 08m 18s - (2m 12s) = 10h 06m 06s.

And one final example:
On 30 March in DR position LAT 20°26.2’N, LONG 131°17.9’E, you take an ex-meridian observation of the Moon’s lower limb at upper transit. The chronometer time of the sight is 10h 36m 02s, and the chronometer error is 02m 06s slow.

This one is a more challenging CT puzzle, meaning we simply have to know they ask such questions and be prepared with how to solve them.  There are no zone times given for anything, which always makes the solution more interesting.  We can assume ZD is -9 (from 131º/15 = 8.7, which rounds to -9.

So we ask (after applying CE) does UTC = 10 38 08 or UTC = 22 38 08?

Checking to see what the ZT of the sight  would have been for each of these interpretations, we have to choose between: 1938 ZT Mar 30 or 0737 ZT on Mar 31?  But since this is a moon sight, we cannot get any hints from the twilight times—moon sights could occur in either twilight or throughout the day.  So they are handing us a bit more than the average amount of sleuth work. Unlike the sun, when we know mer pass is near midday on ZT,  we have no such hint about when the moon might cross the meridian.

At this point, we might resort to a nuance mentioned in an earlier example, namely the statement  that your sight is from a DR position on a given date essentially implies the ZT date of the sight time is the one given.   There is no zone time given, just the CT, and the CT is UTC (either AM or PM), but without other information, we have to assume the UTC date is the one given. In other words, this is either 1038 UTC on Mar 30 or it is 2238 on Mar 30.  These two different interpretations of the CT would in fact lead to different days on the ZT clock, which could be all we need to know to choose the right UTC. In other words, from the DR date argument alone we would have to choose the PM interpretation of CT leading to UTC = 22 38 08 Mar 30.

But these arguments about the DR and CT dates are just what we have discerned from looking at a lot of USCG problems. That interpretation of the dates is not spelled out in any official definition.  It would be reassuring to have some physical evidence to back this up—navigators do not like to  rely on just one source of information for crucial decisions.  So we should look into this a bit further.

It is an upper transit, so that means the GHA of the moon must be near the DR-Lon at the sight time. The Lon of 131º E corresponds to a GHA of (360 -131) = 229º.  So we can look up the GHA at 1038 UTC on Mar 30 and at 2238  UTC on Mar 30 to see which one puts the moon on or near the meridian, ie has a GHA of about this value.

Using the Nautical Almanac, we find that on Mar 30, 1981:

1038 UTC,  GHA moon =   46º 39.5’ 
2238 UTC,  GHA moon = 220º 21.5’

At 1038z the moon is no where near the meridian (actually not even above the horizon), so the CT was clearly set to PM, and we have the correct UTC = 10h 38m 08s. 

To save time, you could learn this faster by just checking the GHA at the whole hours in the Almanac (1000 and 2200) since one is not even close. 

Looking ahead, with a GHA of 220W and a Lon of “229W” (ie 131 E), when we finish this problem, we should expect the moon to be to the left of the meridian. Its GP (moving west around the globe) has another 9º to go before it gets to the DR meridian.

Sunday, November 29, 2015

Latitude by Meridian Transit, Ex-meridians, and the USCG Cel Nav Exam

A meridian is a longitude line. Your meridian is the longitude you are on. Meridian transit—also called meridian passage (mer pass)—is the time a celestial body crosses your meridian. The sextant height of the body above the horizon at that moment provides your latitude with a just a few steps of paperwork, and thus this has been a popular exercise in cel nav since earliest days.

When it is the sun crossing your meridian, it is called Local Apparent Noon (LAN), with the sun at its peak height in the sky, bearing either due south or due north. Latitude from LAN is part of every text on cel nav since the mid 1700s, but it has clung to prominence in modern times far beyond its practical value.

We tend to think most often of stars and other bodies moving east to west across the sky. The motion is left to right looking south, or right to left looking north. These paths are called the upper transit of a body across the horizon, because in both cases the bodies are moving over the top of their nearest poles. Upper transits reach their highest angle above the horizon as they cross the meridian bearing due north or south.

But if we look toward the elevated pole in either hemisphere, we also see circumpolar bodies moving the other direction, west to east, as they pass under their nearest pole. These bodies, in contrast, reach their lowest elevation as they cross the meridian. These are called lower transits. We can find our latitude from either transit.

To get an accurate latitude this way we need to measure the peak sextant height (upper transit) or minimum sextant height (lower transit), which defines the transit. This is usually accomplished by estimating the time of the transit from our DR position and the Nautical Almanac—a process that takes just minutes—and then we start the sights somewhat before that time, and take a series of sights until we see that the maximum or minimum has indeed been captured.

It can happen, however, that our best plans don’t work out. Just as we approach the peak height in a noon sight, the sun might get covered by clouds. We end up with a sight near the transit, but not exactly at the transit. Likewise we might notice at twilight that we have time to take a lower transit star or planet near the meridian, but discover that it is already going back up. We missed the lowest point at the true transit. Or we might catch one going down, but it gets too light out to see it start back up. Again, we have a sight near the meridian transit, but not right at the transit.

A near miss on the transit, however, does not have to be a miss on a latitude determination. The paths of the bodies are well predicted, so if we have accurate time and a reasonable DR accuracy we can figure out what the height of the body would have been had we actually seen it cross the meridian, and from this we can figure a latitude in the normal meridian transit method. This type of near miss sight solved for latitude is called an ex-meridian sight.

And that is the process we will discuss here, but I must say up front that the only reason we do this is because the USCG asks ex-meridian questions on their cel nav exams. We do not cover these in our regular cel nav course. In fact, it seems that the latest publication of the USCG database of questions (August, 2015) has more ex-meridian questions than it used to, and they are asking lower levels of licenses to solve them. [Need note here to prove this.]

If it were not for the USCG tests, and like-minded thinking elsewhere, these methods would have disappeared 50 years ago. I like to think of this as the way the USCG supports navigation schools, so we remain grateful to them.

The reason these particular cel nav questions should have disappeared is they are not needed—meaning they do not add to the navigation—and they risk presenting a false sense of accuracy in latitude. The sextant sight alone (regardless of what time it was taken) provides a line of position (LOP) on the chart that we know we are on. If the time happened to be at mer pass, the LOP is parallel to the bottom of the chart (i.e. it is a latitude line), but if the sight is a bit earlier or later, the line is tilted some degrees, depending on how far the time was from mer pass, as shown in Figure 1. The navigation information is no different. We are somewhere on the line.  

The ex-meridian sights originated at a time when it was not easy to do what we now called a sight reduction to find an LOP—in fact, the methodology had not yet been discovered at the time, so this was a way to get something from a sight that would not otherwise be useful.  This has long not been the case, so these should be thrown out.

Figure 1. LOPs near meridian passage. Each LOP is perpendicular to the azimuth line pointed to the GP of the sun.

Indeed, the prominence of even the simple meridian transit sights—forgetting about ex-meridians—is likewise overrated, for exactly the same reason. Meridian sights take much longer than regular sights, because we need a longer sequence of sights to identify the peak or minimum value, and these sights must be done at a specific time of day. In contrast, we do just as good navigation taking the sights whenever we need them in the most efficient manner. 

The popularity of taking the noon sight is largely tradition; we could just as well find our position at a comfortable time near midday, then DR to the time of LAN we did (or will) experience, and record that LAN position in the logbook for the sake of tradition. 

At this point we show a few graphics to illustrate meridian and ex-meridian sights, then jump straight into shop talk (ie we are going to assume the reader is familiar with standard sight reduction) to show a trick way to solve ex-meridians that is faster and less prone to error than the conventional solution using Bowditch Tables 24 and 25.

The key concept is the zenith distance, z = 90º - Ho, is equal to the distance on the globe between the observer’s position (Lat, Lon) and the geographical position (GP) of the body. As a body circles the earth, z decreases as it gets closer, while its height in the sky (Ho) increases, as shown in Figure 2. At mer pass, z is minimum and Ho is maximum for an upper transit. If the GP is close enough to us (meaning for practical purposes, Lat and Dec are not more than about 80º apart) then we see the body in the sky throughout its path around the earth. Viewed in the sky, it is called circumpolar. For these bodies seen crossing our meridian on the other side of the earth, the situation is reversed—at lower transit, z is maximum, and Ho is minimum.

Figure 2. Relationship between observed height, Ho, and zenith distance, z. Adapted from
Celestial Navigation: A Complete Home Study Course.

A lower transit sight must be of a circumpolar body, which means Lat and Dec are Same Name and the Dec > (90-Lat). Figure 3 below shows the simple way we can determine Lat from a true meridian transit.

Figure 3. Computing Lat from meridian sights of circumpolar stars. Only addition and subtraction of Ho and the Dec is needed for upper or lower transits. The height of the elevated pole is always equal to our latitude.  To be circumpolar, a star must be Same Name with Dec > (90 - Lat).

When we miss the true transit, we have the situation shown in Figure 4.

Figure 4. Body heights at upper and lower transits and the height differences between them. The correction is not precisely the same for upper and lower transits even if they miss the meridian by the same time difference, because the peak height of the path affects its shape, but for either one, the correction is the same on each side of the transit at the same time offset. Since the problems can involve any latitude looking either direction, we recommend plotting a sketch of the LOP before choosing an answer.

Sample USCG Upper-Transit Ex-meridian Question

253. ( On 15 August [1981] an ex-meridian altitude of the Sun’s lower limb at upper transit was observed at 1130 ZT. Your DR position is LAT 26°24.0’S, LONG 155°02.0’E, and your sextant altitude (Hs) is 48° 45.9’. The index error is 2.6’ on the arc, and your height of eye is 51.5 feet. The chronometer time of the observation is 01h 27m 38s, and the chronometer error is 02m 14s slow. Find the latitude at meridian transit from the ex-meridian observation.

o (A) LAT 26°32.6’S
• (B) LAT 26°51.6’S
o (C) LAT 26°57.0’S
o (D) LAT 27°09.9’S

Step 1. Figure UTC from CT and look up Dec and GHA at UTC of sight time. DR-Lon is 155º 02’ E; so zone description (ZD) = 155/15 = 10.33, or ZD = -10h. Sight at ZT 1130, so UTC is about 0130, so UTC = 01h 27m 38s + 02m 14s = 01h 29m 52s. [Note on USCG time keeping]

From Nautical Almanac, converted to decimals for later computations.

Dec = N 14º 07.9’ = N 14.132º
GHA = 201º 20.4’ = 201.340º
DR Lat = 26º 24.0’ S = 26.400º S
DR Lon = 155º 2.0’ E = 155.03º E
LHA = GHA + LonE = 356.370º

Step 2. Do a sight reduction by computation from the DR position, just as if we were going to do normal navigation and plot an LOP… which we are in fact going to do. We can use computation here (as opposed to Pub 229) because to be prepared for the full range of USCG great circle sailings questions we must know the same formula.  

Hc = arcsin [ sin Lat * sin Dec + cos Lat * cos Dec * cos LHA ] Z = arccos [ ( sin Dec - sin Lat * sin Hc ) / cos Lat * cos Hc ]

Sign Rules: enter all angles as positive, but if contrary name, enter Dec as a negative number… which is the case at hand.

Hc = arcsin [sin (26.400) sin (-14.132) + cos (26.400) cos (-14.132) cos (356.370) ]
Hc = arcsin (0.75830) = 49.315º = 49º 18.9’ [ See key strokes ]

Now find the azimuth angle Z.

Z = arccos { [ sin (-14.132) - sin (26.400) x sin(49.316)] / [cos(26.400) x cos (49.316)] }

Z = arccos (-0.995596) = 174.6

(Had Z ended up negative, we would change it to Z+180, but this example does not call for that.)

Step 3. Convert Z to Zn and Hs to Ho and figure a-value to plot the LOP. (This is all standard procedure if we were just plotting an LOP from this sun sight.) S Lat with LHA > 180, so

The standard rules for converting Z to Zn:
N Lat, LHA > 180, Zn = Z, else Zn = 360 - Z
S Lat, LHA > 180, Zn = 180 - Z, else Zn = 180 + Z

We have S Lat, with LHA > 180, so
Zn = 180 - z = 180 - 174.6 = 005.4
(The sun was indeed just to the right of our meridian, looking north.)

Ha = Hs ± IC - dip = 48° 45.9’ -2.6’ - 7.0’ = 48º 36.3’
Ho = Ha ± alt corr = 48º 36.3’ + 15.1 = 48º 51.4’
a = Hc - Ho = 49º 18.9’ - 48º 51.4’ = 27.5’ A 005.4

Step 4. Make a sketch of the LOP plot to figure the ex-meridian Lat, i.e. to find what our latitude would be if we assume the DR-Lon is correct, which is part of the rash assumptions made in all ex-meridian sights. We could plot this and read it from the scales, but for ex-meridian only we can compute the offset; the sketch just keeps the situation in perspective, ie does the correction make our ex-meridian Lat larger or smaller than the DR-Lat, as shown in Figure 5.

Figure 5. A plot sketch to check the computation of dLat. The scale does not matter, we just want to show that for S Lat with Zn to the N, an a-value Away makes the Lat a larger number to the south. Note that in this fictitious problem made up by the USCG for the exam, we find a latitude that is near 30' off the DR-Lat with a method that must assume the corresponding DR-Lon is correct. We know the LOP is correct, and we should in practice just leave it at that.

The offset can be computed from dLat = a / cos Zn, which means the ex-meridian Lat = DR-Lat + dLat . In this example, dLat = 27.5 / cos 5.4 = 27.6’ and the final answer is 26º 24.0’ + 27.6’ = 26º 51.6’ S, which is answer B.

Sample USCG Lower Transit Ex-meridian Question

164. ( On 16 June [1981] in DR position LAT 50°57.0’S, LONG 53°03.9’W (ZD+4), you take an ex-meridian observation of Acrux at lower transit. The chronometer time of the sight is 10h 08m 18s, and the chronometer error is 02m 12s fast. The sextant altitude (hs) is 23°49.0’. The index error is 1.1’ off the arc, and your height of eye is 26 feet. What is the latitude at meridian transit?

• (A) 50°41.2’S
o (B) 51°02.2’S
o (C) 51°33.0’S
o (D) 51°41.2’S


Step 1. Figure UTC. (It is a pity we have to do this, but we do.)

In contrast to the first example, the ZT of the sight was not given, but with ZD = +4h we can check CT. That is, CT = 1008, means either UTC = 1008 or 2208. The first gives sight time = 0608 ZT; the latter gives 1808ZT.  Under some circumstances we might be able to judge from this alone, but not in this case, ie either one could be twilight without further knowledge. So we need to check which one of these happens to be in twilight when stars and horizon can both be seen.  

Checking the 1981 Nautical Almanac, and noting that DR-Lon 53º 3.9’ = 3h 32m (Arc to Time table), we find that sight time in the morning (ie nautical to civil twilight) = 0646 to 0812 LMT = 1018 to 1144 UTC, and in the evening, 1630 to 1715 LMT = 2002 to 2047 UTC.  So CT 1008 is a morning sight corresponding to 1008 UTC.

UTC = 10h 08m 18s -02m 12s = 10h 06m 06s.  

[Note this was about 10m before nautical twilight, but still within reason as they could have had (in the virtual circumstance of this fictitious problem) very clear skies that let them see the horizon early.]

Look up Nautical Almanac data and convert to decimals. 
Dec = S63º 00.0’ = S63.000º
GHA = 229° 43.4’ = 229.723º
DR Lat = 50° 57.0’S = 50.950º S
DR Lon = 53°03.9’ W= 53.075º W
LHA = GHA - LonW = 176.658º

[Acrux is a bright star at the base of the Southern Cross, and now we know that at sight time it was 176.6º west of us. This is confusing information as we know we were looking south and would expect—from upper transit experience—a Zn within a few degrees of 180, which for upper transits would in turn call for LHA of a few degrees or (360 minus a few degrees). 

But this is a lower transit sight, which frankly confuses the reasoning. But it does not matter. We are just going to do a sight reduction and plot the LOP. We do not care if it is upper or lower, or even if it is not anywhere near transit. This note is just to say, do not be confused by the LHA value.]

Step 2. Do a sight reduction from the DR position.

Hc = arcsin [sin (50.950) sin (63.000) + cos (50.950) cos (63.000) cos (176.658) ]
Hc = arcsin (0.406426) =  23.980º =  23º 58.8’ 

and find Z from: 
Z = arccos { [ sin (63.000) - sin (50.959) x sin(23.980)] / [cos(50.950) x cos (23.980)] }
Z = arccos (-0.99958) = 1.6 and Zn = 181.6

Step 3. Convert Hs to Ho and figure a-value to plot the LOP. (This is all standard procedure if we were just plotting an LOP from this sun sight.)

Ha =  Hs ± IC - dip = 23° 49.0’ +1.1’ - 4.9’ = 23º 45.2’
Ho =  Ha ± alt corr = 23º 45.2’ -2.2 = 23º 43.0’
a = Hc - Ho = 23º 58.8’ - 23º 43.0’ = 15.8’ A 181.6

Step 4. We could make the sketch, but at Zn = 181.6 the angle off the meridian is just 1.6º, which will not change the a-value, so dLat = a-value. We are S Lat looking S, so an Away a-value makes the Lat a smaller number. 

The offset can be computed from dLat = a / cos Zn, which means the ex-meridian Lat = DR-Lat + dLat . In this example, dLat = 15.8 / cos 181.6 = -15.8’ and the final answer is 50° 57.0’ - 15.8’ = 50º 41.2’ S, which is answer A.


Final note: We have used a shortcut method to find a logical value of the Lat, namely if your DR Lon is right, then this is the right Lat. But this is not the Lat at meridian transit. It is the Lat at the time of the sight.  These USCG exam questions inevitably ask for the "Latitude at meridian transit," and then proceed to find the result using two tables in Bowditch, which are specifically annotated as "...remember that the value obtained [using Tables 24 and 25] is the latitude at the time of observation, not at the time of meridian transit."  And since course and speed are never given with these problems, this is all we can do. 

So I maintain that these problems, along with the ones they have for finding compass error by amplitude, should be removed from the tests.  The latter should be removed for the same generic reason, namely there is an easier and more accurate way to get the result... maybe not 80 years ago (before sight reduction tables) but certainly today.