## Documentation |

On this page… |
---|

Conventions for Navigational Functions |

Navigation is the process of planning, recording, and controlling
the movement of a craft or vehicle from one location to another. The
word derives from the Latin roots *navis* ("ship")
and *agere* ("to move or direct").
Geographic information—usually in the form of latitudes and
longitudes—is at the core of navigation practice. The toolbox
includes specialized functions for navigating across expanses of the
globe, for which projected coordinates are of limited use.

Navigating on land, over water, and through the air can involve a variety of tasks:

Establishing position, using known, fixed landmarks (piloting)

Using the stars, sun, and moon (celestial navigation)

Using technology to fix positions (inertial guidance, radio beacons, and satellite navigation, including GPS)

Deducing net movement from a past known position (dead reckoning)

Another navigational task involves planning a voyage or flight, which includes determining an efficient route (usually by great circle approximation), weather avoidance (optimal track routing), and setting out a plan of intended movement (track laydown). Mapping Toolbox™ functions support these navigational activities as well.

You can use and convert among several angular and distance measurement units. The navigational support functions are

`dreckon``gcwaypts``legs``navfix`

To make these functions easy to use, and to conform to common
navigational practice, *for these specific functions only*,
certain conventions are used:

Related functions that *do not *carry this
restriction include `rhxrh`, `scxsc`, `gcxgc`, `gcxsc`, `track`, `timezone`, and `crossfix`,
because of their potential for application outside navigation.

Navigational track format requires column-vector variables for
the latitudes and longitudes of track waypoints. A *waypoint* is
a point through which a track passes, usually corresponding to a course
(or speed) change. Navigational tracks are made up of the line segments
connecting these waypoints, which are called *legs*.
In this format, therefore, *n* legs are described
using *n+1* waypoints, because an endpoint for
the final leg must be defined. Mapping Toolbox navigation functions
always presume angle units are always given in degrees.

Here, five track legs require six waypoints. In navigational track format, the waypoints are represented by two 6-by-1 vectors, one for the latitudes and one for the longitudes.

The fundamental objective of navigation is to determine at a
given moment how to proceed to your destination, avoiding hazards
on the way. The first step in accomplishing this is to establish your
current position. Early sailors kept within sight of land to facilitate
this. Today, navigation within sight (or radar range) of land is called *piloting*.
Positions are fixed by correlating the bearings and/or ranges of landmarks.
In real-life piloting, all sighting bearings are treated as rhumb
lines, while in fact they are actually great circles.

Over the distances involved with visual sightings (up to 20 or 30 nautical miles), this assumption causes no measurable error and it provides the significant advantage of allowing the navigator to plot all bearings as straight lines on a Mercator projection.

The Mercator was designed exactly for this purpose. Range circles, which might be determined with a radar, are assumed to plot as true circles on a Mercator chart. This allows the navigator to manually draw the range arc with a compass.

These assumptions also lead to computationally efficient methods
for fixing positions with a computer. The toolbox includes the `navfix` function,
which mimics the manual plotting and fixing process using these assumptions.

To obtain a good navigational fix, your relationship to at least three known points is considered necessary. A questionable or poor fix can be obtained with two known points.

In this imaginary coastal region, you take a visual bearing on the radio tower of 270º. At the same time, Gilligan's Lighthouse bears 0º. If you plot a 90º-270º line through the radio tower and a 0º-180º line through the lighthouse on your Mercator chart, the point at which the lines cross is a fix. Since you have used only two lines, however, its quality is questionable.

But wait; your port lookout says he took a bearing on Cape Jones of 300º. If that line exactly crosses the point of intersection of the first two lines, you will have a perfect fix.

Whoops. What happened? Is your lookout in error? Possibly, but perhaps one or both of your bearings was slightly in error. This happens all the time. Which point, 1, 2, or 3, is correct? As far as you know, they are all equally valid.

In practice, the little triangle is plotted, and the fix position
is taken as either the center of the triangle or the vertex closest
to a danger (like shoal water). If the triangle is large, the quality
is reported as *poor*, or even as *no
fix*. If a fourth line of bearing is available, it can be
plotted to try to resolve the ambiguity. When all three lines appear
to cross at exactly the same point, the quality is reported as *excellent* or *perfect*.

Notice that three lines resulted in three intersection points.
Four lines would return six intersection points. This is a case of
combinatorial counting. Each intersection corresponds to choosing
two lines to intersect from among *n* lines.

The next time you traverse these straits, it is a very foggy morning. You can't see any landmarks, but luckily, your navigational radar is operating. Each of these landmarks has a good radar signature, so you're not worried. You get a range from the radio tower of 14 nautical miles and a range from the lighthouse of 15 nautical miles.

Now what? You took ranges from only two objects, and yet you have two possible positions. This ambiguity arises from the fact that circles can intersect twice.

Luckily, your radar watch reports that he has Cape Jones at 18 nautical miles. This should resolve everything.

You were lucky this time. The third range resolved the ambiguity and gave you an excellent fix. Three intersections practically coincide. Sometimes the ambiguity is resolved, but the fix is still poor because the three closest intersections form a sort of circular triangle.

Sometimes the third range only adds to the confusion, either
by bisecting the original two choices, or by failing to intersect
one or both of the other arcs at all. In general, when *n* arcs
are used, 2`x`(*n*-choose-2) possible
intersections result. In this example, it is easy to tell which ones
are *right*.

Bearing lines and arcs can be combined. If instead of reporting a third range, your radar watch had reported a bearing from the radar tower of 20º, the ambiguity could also have been resolved. Note, however, that in practice, lines of bearing for navigational fixing should only be taken visually, except in desperation. A radar's beam width can be a degree or more, leading to uncertainty.

As you begin to wonder whether this manual plotting process could be automated, your first officer shows up on the bridge with a laptop and Mapping Toolbox software.

The `navfix` function can be used to determine
the points of intersection among any number of lines and arcs. Be
warned, however, that due to the combinatorial nature of this process,
the computation time grows rapidly with the number of objects. To
illustrate this function, assign positions to the landmarks. Point
A, Cape Jones, is at (`latA`,`lonA`).
Point B, the radio tower, is at (`latB`,`lonB`).
Point C, Gilligan's Lighthouse, is at (`latC`,`lonC`).

For the bearing-lines-only example, the syntax is:

[latfix,lonfix] = navfix([latA latB latC],[lonA lonB lonC],... [300 270 0])

This defines the three points and their bearings as taken *from
the ship*. The outputs would look something like this, with
actual numbers, of course:

latfix = latfix1 NaN % A intersecting B latfix2 NaN % A intersecting C latfix3 NaN % B intersecting C lonfix = lonfix1 NaN % A intersecting B lonfix2 NaN % A intersecting C lonfix3 NaN % B intersecting C

Notice that these are two-column matrices. The second column
consists of `NaN`s because it is used only for the
two-intersection ambiguity associated with arcs.

For the range-arcs-only example, the syntax is

[latfix,lonfix] = navfix([latA latB latC],[lonA lonB lonC],... [16 14 15],[0 0 0])

This defines the three points and their ranges as taken from the ship. The final argument indicates that the three cases are all ranges.

The outputs have the following form:

latfix = latfix11 latfix12 % A intersecting B latfix21 latfix22 % A intersecting C latfix31 latfix32 % B intersecting C lonfix = lonfix11 lonfix12 % A intersecting B lonfix21 lonfix22 % A intersecting C lonfix31 lonfix32 % B intersecting C

Here, the second column is used, because each pair of arcs has two potential intersections.

For the bearings and ranges example, the syntax requires the final input to indicate which objects are lines of bearing (indicated with a 1) and which are range arcs (indicated with a 0):

[latfix,lonfix] = navfix([latB latB latC],[lonB lonB lonC],... [20 14 15],[1 0 0])

The resulting output is mixed:

latfix = latfix11 NaN % Line B intersecting Arc B latfix21 latfix22 % Line B intersecting Arc C latfix31 latfix32 % Arc B intersecting Arc C lonfix = lonfix11 NaN % Line B intersecting Arc B lonfix21 lonfix22 % Line B intersecting Arc C lonfix31 lonfix32 % Arc B intersecting Arc C

Only one intersection is returned for the line from B with the arc about B, since the line originates inside the circle and intersects it once. The same line intersects the other circle twice, and hence it returns two points. The two circles taken together also return two points.

Usually, you have an idea as to where you are before you take
the fix. For example, you might have a dead reckoning position for
the time of the fix (see below). If you provide `navfix` with
this estimated position, it chooses from each pair of ambiguous intersections
the point closest to the estimate. Here's what it might look like:

[latfix,lonfix] = navfix([latB latB latC],[lonB lonB lonC],... [20 14 15],[1 0 0],drlat,drlon) latfix = latfix11 % the only point latfix21 % the closer point latfix31 % the closer point lonfix = lonfix11 % the only point lonfix21 % the closer point lonfix31 % the closer point

Define some specific points in the middle of the Atlantic Ocean. These are strictly arbitrary; perhaps they correspond to points in Atlantis:

lata = 3.1; lona = -56.2; latb = 2.95; lonb = -55.9; latc = 3.15; lonc = -55.95;

Plot them on a Mercator projection:

axesm('MapProjection','mercator','Frame','on',... 'MapLatLimit',[2.8 3.3],'MapLonLimit',[-56.3 -55.8]) plotm([lata latb latc],[lona lonb lonc],... 'LineStyle','none','Marker','pentagram',... 'MarkerEdgeColor','b','MarkerFaceColor','b',... 'MarkerSize',12)

Here is what it looks like (with labeling and imaginary coastlines added after the fact for illustration):

Take three visual bearings: Point A bears 289º, Point B bears 135º, and Point C bears 026.5º. Calculate the intersections:

[newlat,newlong] = navfix([lata latb latc],[lona lonb lonc],... [289 135 26.5],[1 1 1]) newlat = 3.0214 NaN 3.0340 NaN 3.0499 NaN newlong = -55.9715 NaN -56.0079 NaN -56.0000 NaN

Add the intersection points to the map:

plotm(newlat,newlong,'LineStyle','none',... 'Marker','diamond','MarkerEdgeColor','r',... 'MarkerFaceColor','r','MarkerSize',9)

Bearing lines have been added to the map for illustration purposes. Notice that each pair of objects results in only one intersection, since all are lines of bearing.

What if instead, you had ranges from the three points, A, B, and C, of 13 nmi, 9 nmi, and 7.5 nmi, respectively?

[newlat,newlong] = navfix([lata latb latc],[lona lonb lonc],... [13 9 7.5],[0 0 0]) newlat = 3.0739 2.9434 3.2413 3.0329 3.0443 3.0880 newlong = -55.9846 -56.0501 -56.0355 -55.9937 -56.0168 -55.8413

Here's what these points look like:

Three of these points look reasonable, three do not.

What if, instead of a range from Point A, you had a bearing to it of 284º?

[newlat,newlong] = navfix([lata latb latc],[lona lonb lonc],... [284 9 7.5],[1 0 0]) newlat = 3.0526 2.9892 3.0592 3.0295 3.0443 3.0880 newlong = -56.0096 -55.7550 -56.0360 -55.9168 -56.0168 -55.8413

Again, visual inspection of the results indicates which three of the six possible points seem like

*reasonable*positions.When using the dead reckoning position (3.05ºN,56.0ºW), the closer, more reasonable candidate from each pair of intersecting objects is chosen:

drlat = 3.05; drlon = -56; [newlat,newlong] = navfix([lata latb latc],[lona lonb lonc],... [284 9 7.5],[1 0 0],drlat,drlon) newlat = 3.0526 3.0592 3.0443 newlong = -56.0096 -56.0360 -56.0168

You know that the shortest path between two geographic points
is a great circle. Sailors and aviators are interested in minimizing
distance traveled, and hence time elapsed. You also know that the
rhumb line is a path of constant heading, the *natural* means
of traveling. In general, to follow a great circle path, you would
have to continuously alter course. This is impractical. However, you
can approximate a great circle path by rhumb line segments so that
the added distance is minor and the number of course changes minimal.

Surprisingly, very few rhumb line *track legs* are
required to closely approximate the distance of the great circle path.

Consider the voyage from Norfolk, Virginia (37ºN,76ºW), to Cape St. Vincent, Portugal (37ºN,9ºW), one of the most heavily trafficked routes in the Atlantic. A due-east rhumb line track is 3,213 nautical miles, while the optimal great circle distance is 3,141 nautical miles.

Although the rhumb line path is only a little more than 2% longer, this is an additional 72 miles over the course of the trip. For a 12-knot tanker, this results in a 6-hour delay, and in shipping, time is money. If just three rhumb line segments are used to approximate the great circle, the total distance of the trip is 3,147 nautical miles. Our tanker would suffer only a half-hour delay compared to a continuous rhumb line course. Here is the code for computing the three types of tracks between Norfolk and St. Vincent:

figure('color','w'); ha = axesm('mapproj','mercator',... 'maplatlim',[25 55],'maplonlim',[-80 0]); axis off, gridm on, framem on; setm(ha,'MLineLocation',15,'PLineLocation',15); mlabel on, plabel on; load coast; hg = geoshow(lat,long,'displaytype','line','color','b'); % Define point locs for Norfolk, VA and St. Vincent Portugal norfolk = [37,-76]; stvincent = [37, -9]; geoshow(norfolk(1),norfolk(2),'DisplayType','point',... 'markeredgecolor','k','markerfacecolor','k','marker','o') geoshow(stvincent(1),stvincent(2),'DisplayType','point',... 'markeredgecolor','k','markerfacecolor','k','marker','o') % Compute and draw 100 points for great circle gcpts = track2('gc',norfolk(1),norfolk(2),... stvincent(1),stvincent(2)); geoshow(gcpts(:,1),gcpts(:,2),'DisplayType','line',... 'color','red','linestyle','--') % Compute and draw 100 points for rhumb line rhpts = track2('rh',norfolk(1),norfolk(2),... stvincent(1),stvincent(2)); geoshow(rhpts(:,1),rhpts(:,2),'DisplayType','line',... 'color',[.7 .1 0],'linestyle','-.') [latpts,lonpts] = gcwaypts(norfolk(1),norfolk(2),... stvincent(1),stvincent(2),3); % Compute 3 waypoints geoshow(latpts,lonpts,'DisplayType','line',... 'color',[.4 .2 0],'linestyle','-')

The resulting tracks and distances are shown below:

The Mapping Toolbox function `gcwaypts` calculates
waypoints in navigation track format in order to approximate a great
circle with rhumb line segments. It uses this syntax:

[latpts,lonpts] = gcwaypts(lat1,lon1,lat2,lon2,numlegs)

All the inputs for this function are scalars a (starting and
an ending position). The `numlegs` input is the number
of equal-length legs desired, which is 10 by default. The outputs
are column vectors representing waypoints in navigational track format
(`[heading distance]`). The size of each of these
vectors is `[(numlegs+1) 1]`. Here are the points
for this example:

[latpts,lonpts] = gcwaypts(norfolk(1),norfolk(2),... stvincent(1),stvincent(2),3) % Compute 3 waypoints latpts = 37.0000 41.5076 41.5076 37.0000 lonpts = -76.0000 -54.1777 -30.8223 -9.0000

These points represent waypoints along the great circle between which the approximating path follows rhumb lines. Four points are needed for three legs, because the final point at Cape St. Vincent must be included.

Now we can compute the distance in nautical miles (nm) along each track and via the waypoints:

drh = distance('rh',norfolk,stvincent); % Get rhumb line dist (deg) dgc = distance('gc',norfolk,stvincent); % Get gt. circle dist (deg) % Compute headings and distances for the waypoint legs [course distnm] = legs(latpts,lonpts,'rh');

Finally, compare the distances:

distrhnm = deg2nm(drh) % Nautical mi along rhumb line distgcnm = deg2nm(dgc) % Nautical mi along great circle distlegsnm = sum(distnm) % Total dist along the 3 legs rhgcdiff = distrhnm - distgcnm % Excess rhumb line distance trgcdiff = distlegsnm - distgcnm % Excess distance along legs distrhnm = 3.2127e+003 distgcnm = 3.1407e+003 distlegsnm = 3.1490e+003 rhgcdiff = 71.9980 trgcdiff = 8.3446

Following just three rhumb line legs reduces the distance travelled from 72 nm to 8.3 nm compared to a great circle course.

Navigational tracks are most useful when graphically displayed. Traditionally, the navigator identifies and plots waypoints on a Mercator projection and then connects them with a straightedge, which on this projection results in rhumb line tracks. In the previous example, waypoints were chosen to approximate a great circle route, but they can be selected for a variety of other reasons.

Let's say that after arriving at Cape St. Vincent, your tanker must traverse the Straits of Gibraltar and then travel on to Port Said, the northern terminus of the Suez Canal. On the scale of the Mediterranean Sea, following great circle paths is of little concern compared to ensuring that the many straits and passages are safely transited. The navigator selects appropriate waypoints and plots them.

To accomplish this with Mapping Toolbox functions, you can
display a map axes with a Mercator projection, select appropriate
map latitude and longitude limits to isolate the area of interest,
plot coastline data, and interactively mouse-select the waypoints
with the `inputm` function. The `track` function
will generate points to connect these waypoints, which can then be
displayed with `plotm`.

For illustration, assume that the waypoints are known (or were
gathered using `inputm`). To learn about using `inputm`, see Picking Locations Interactively, or `inputm` in the Mapping Toolbox reference
pages.

waypoints = [36 -5; 36 -2; 38 5; 38 11; 35 13; 33 30; 31.5 32] waypoints = 36.0000 -5.0000 36.0000 -2.0000 38.0000 5.0000 38.0000 11.0000 35.0000 13.0000 33.0000 30.0000 31.5000 32.0000 load coast axesm('MapProjection','mercator',... 'MapLatLimit',[30 47],'MapLonLimit',[-10 37]) framem plotm(lat,long) [lttrk,lntrk] = track(waypoints); plotm(lttrk,lntrk,'r')

Although these track segments are straight lines on the Mercator projection, they are curves on others:

The segments of a track like this are called *legs*.
Each of these legs can be described in terms of course and distance.
The function `legs` will take the waypoints in
navigational track format and return the course and distance required
for each leg. Remember, the order of the points in this format determines
the direction of travel. Courses are therefore calculated from each
waypoint to its successor, not the reverse.

[courses,distances] = legs(waypoints) courses = 90.0000 70.3132 90.0000 151.8186 98.0776 131.5684 distances = 145.6231 356.2117 283.6839 204.2073 854.0092 135.6415

Since this is a navigation function, the courses are all in degrees and the distances are in nautical miles. From these distances, speeds required to arrive at Port Said at a given time can be calculated. Southbound traffic is allowed to enter the canal only once per day, so this information might be economically significant, since unnecessarily high speeds can lead to high fuel costs.

When sailors first ventured out of sight of land, they faced
a daunting dilemma. How could they find their way home if they didn't
know where they were? The practice of *dead reckoning* is
an attempt to deal with this problem. The term is derived from *deduced
reckoning*.

Briefly, dead reckoning is vector addition plotted on a chart. For example, if you have a fix at (30ºN,10ºW) at 0800, and you proceed due west for 1 hour at 10 knots, and then you turn north and sail for 3 hours at 7 knots, you should be at (30.35ºN,10.19ºW) at 1200.

However, a sailor *shoots the sun* at local
apparent noon and discovers that the ship's latitude is actually 30.29ºN.
What's worse, he lives before the invention of a reliable chronometer,
and so he cannot calculate his longitude at all from this sighting.
What happened?

Leaving aside the difficulties in speed determination and the need to tack off course, even modern craft have to contend with winds and currents. However, despite these limitations, dead reckoning is still used for determining position between fixes and for forecasting future positions. This is because dead reckoning provides a certainty of assumptions that estimations of wind and current drift cannot.

When navigators establish a fix from some source, be it from piloting, celestial, or satellite observations, they plot a dead reckoning (DR) track, which is a plot of the intended positions of the ship forward in time. In practice, dead reckoning is usually plotted for 3 hours in advance, or for the time period covered by the next three expected fixes. In open ocean conditions, hourly fixes are sufficient; in coastal pilotage, three-minute fixes are common.

Specific DR positions, which are sometimes called *DR*s,
are plotted according to the *Rules of DR*:

DR at every course change

DR at every speed change

DR every hour on the hour

DR every time a fix or running fix is obtained

DR 3 hours ahead or for the next three expected fixes

DR for every line of position (LOP), either visual or celestial

For example, the navigator plots these DRs:

Notice that the 1523 DR does not coincide with the LOP at 1523. Although note is taken of this variance, one line is insufficient to calculate a new fix.

Mapping Toolbox function `dreckon` calculates
the DR positions for a given set of courses and speeds. The function
provides DR positions for the first three rules of dead reckoning.
The approach is to provide a set of waypoints in navigational track
format corresponding to the plan of intended movement.

The time of the initial waypoint, or fix, is also needed, as
well as the speeds to be employed along each leg. Alternatively, a
set of speeds and the times for which each speed will apply can be
provided. `dreckon` returns the positions and times
required of these DRs:

`dreckon`calculates the times for position of each course change, which will occur at the waypoints`dreckon`calculates the positions for each whole hourIf times are provided for speed changes,

`dreckon`calculates positions for these times if they do not occur at course changes

Imagine you have a fix at midnight at the point (10ºN,0º):

waypoints(1,:) = [10 0]; fixtime = 0;

You intend to travel east and alter course at the point (10ºN,0.13ºE) and head for the point (10.1ºN,0.18ºE). On the first leg, you will travel at 5 knots, and on the second leg you will speed up to 7 knots.

waypoints(2,:) = [10 .13]; waypoints(3,:) = [10.1 .18]; speeds = [5;7];

To determine the DR points and times for this plan, use `dreckon`:

[drlat,drlon,drtime] = dreckon(waypoints,fixtime,speeds); [drlat drlon drtime] ans = 10.0000 0.0846 1.0000 % Position at 1 am 10.0000 0.1301 1.5373 % Time of course change 10.0484 0.1543 2.0000 % Position at 2 am 10.1001 0.1801 2.4934 % Time at final waypoint

Here is an illustration of this track and its DR points:

However, you would like to get to the final point a little earlier to make a rendezvous. You decide to recalculate your DRs based on speeding up to 7 knots a little earlier than planned. The first calculation tells you that you were going to increase speed at the turn, which would occur at a time 1.5373 hours after midnight, or 1:32 a.m. (at time 0132 in navigational time format). What time would you reach the rendezvous if you increased your speed to 7 knots at 1:15 a.m. (0115, or 1.25 hours after midnight)?

To indicate times for speed changes, another input is required, providing a time interval after the fix time at which each ordered speed is to end. The first speed, 5 knots, is to end 1.25 hours after midnight. Since you don't know when the rendezvous will be made under these circumstances, set the time for the second speed, 7 knots, to end at infinity. No DRs will be returned past the last waypoint.

spdtimes = [1.25; inf]; [drlat,drlon,drtime] = dreckon(waypoints,fixtime,... speeds,spdtimes); [drlat,drlon,drtime] ans = 10.0000 0.0846 1.0000 % Position at 1 am 10.0000 0.1058 1.2500 % Position at speed change 10.0000 0.1301 1.4552 % Time of course change 10.0570 0.1586 2.0000 % Position at 2 am 10.1001 0.1801 2.4113 % Time at final waypoint

This following illustration shows the difference:

The times at planned positions after the speed change are a little earlier; the position at the known time (2 a.m.) is a little farther along. With this plan, you will arrive at the rendezvous about 4 1/2 minutes earlier, so you may want to consider a greater speed change.

Dead reckoning is a reasonably accurate method for predicting position if the vehicle is able to maintain the planned course. Aircraft and ships can be pushed off the planned course by winds and current. An important step in navigational planning is to calculate the required drift correction.

In the standard drift correction problem, the desired course and wind are known, but the heading needed to stay on course is unknown. This problem is well suited to vector analysis. The wind velocity is a vector of known magnitude and direction. The vehicle's speed relative to the moving air mass is a vector of known magnitude, but unknown direction. This heading must be chosen so that the sum of the vehicle and wind velocities gives a resultant in the specified course direction. The ground speed can be larger or smaller than the air speed because of headwind or tailwind components. A navigator would like to know the required heading, the associated wind correction angle, and the resulting ground speed.

What heading puts an aircraft on a course of 250° when the wind is 38 knots from 285°? The aircraft flies at an airspeed of 145 knots.

course = 250; airspeed = 145; windfrom = 285; windspeed = 38; [heading,groundspeed,windcorrangle] = ... driftcorr(course,airspeed,windfrom,windspeed) heading = 258.65 groundspeed = 112.22 windcorrangle = 8.65

The required heading is about 9° to the right of the course. There is a 33-knot headwind component.

A related problem is the calculation of the wind speed and direction from observed heading and course. The wind velocity is just the vector difference of the ground speed and the velocity relative to the air mass.

[windfrom,windspeed] = ... driftvel(course,groundspeed,heading,airspeed) windfrom = 285.00 windspeed = 38.00

Time zones used for navigation are uniform 15º extents
of longitude. The `timezone` function returns a
navigational time zone, that is, one based solely on longitude with
no regard for statutory divisions. So, for example, Chicago, Illinois,
lies in the statutory U.S. Central time zone, which has irregular
boundaries devised for political or convenience reasons. However,
from a navigational standpoint, Chicago's longitude places it in the *S* (Sierra)
time zone. The zone's *description* is +6, which
indicates that 6 hours must be added to local time to get Greenwich,
or *Z* (Zulu) time. So, if it is noon, standard
time in Chicago, it is 12+6, or 6 p.m., at Greenwich.

Each 15º navigational time zone has a distinct description
and designating letter. The exceptions to this are the two zones on
either side of the date line, *M* and *Y* (Mike
and Yankee). These zones are only 7-1/2º wide, since on one side
of the date line, the description is +12, and on the other, it is
-12.

Navigational time zones are very important for celestial navigation calculations. Although there are no Mapping Toolbox functions designed specifically for celestial navigation, a simple example can be devised.

It is possible with a sextant to determine *local apparent
noon*. This is the moment when the Sun is at its zenith
from your point of view. At the exact center longitude of a time zone,
the phenomenon occurs exactly at noon, local time. Since the Sun traverses
a 15º time zone in 1 hour, it crosses one degree every 4 minutes.
So if you observe local apparent noon at 11:54, you must be 1.5º
east of your center longitude.

You must know what time zone you are in before you can even attempt a fix. This concept has been understood since the spherical nature of the Earth was first accepted, but early sailors had no ability to keep accurate time on ship, and so were unable to determine their longitude. The invention of accurate chronometers in the 18th century solved this problem.

The `timezone` function is quite simple.
It returns the description, `zd`, an integer for
use in calculations, a string, `zltr`, of the zone
designator, and a string fully naming the `zone`.
For example, the information for a longitude 123ºE is the following:

[zd,zltr,zone] = timezone(123) zd = -8 zltr = H zone = -8 H

Returning to the simple celestial navigation example, the center longitude of this zone is:

-(zd*15) ans = 120

This means that at our longitude, 123ºE, we should experience local apparent noon at 11:48 a.m., 12 minutes early.

Was this topic helpful?