# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Message:αβγ
Message:abc
 Add Images & Files Posting Code: Name: Email:
Re: Use of Sun Sights for Local time,and Lunars for Longitude
From: Herbert Prinz
Date: 2002 Oct 24, 19:52 +0000

```Hello George,

You wrote:

> Method 1.HERE'S THE BAD WAY TO CORRECT THE LUNAR DISTANCE..
>
> First, assume that an accurate measurement has been made of
> latitude, from a Sun meridian altitude, and that later a lunar distance has
> been taken, but without measuring the Moon's altitude, so that altitude
> needs to be calculated. We don't know yet the Greenwich Time, but we will
> make a guess at it. Just imagine that guess is an hour out: a big error, I
> know.
>

Something essential is missing here. The problem, as stated is underdetermined.
From latitude and measured distance alone you cannot get GMT.

> Note also, that we haven't even considered any errors caused by an initial
> guess at the observer's longitude.

Ah! Did you mean to feed longitude into the process? If you guess at the
longitude to use it for establishing LHA Moon, your resulting GMT will be
flawed in all cases but the single one where you guess longitude just right. No
iteration is going to change this, because there is no feedback to correct a
wrong longitude. GMT and Longitude are mutually dependent:  If you observe Moon
and Star around 3pm GMT at an angle of  40 deg 5', but  the almanac says the
angle at 15:00 GMT is  40 deg 20', you can either ask "At what time GMT do I
see this angle as 40 deg 5' from my assumed longitude?" but you could also ask
"At which longitude do I see this angle as 40 deg 5' at 15:00 GMT?".

If you don't know the hour angles of the observed bodies, both questions will
allow a possible answer. So you get a rather fancy position line in
4-dimensional Timespace consisting of the position/GMT pairs that are
consistent with the observation. With what do you intersect it to get
meaningful information from it?

I think, the method isn't just a bad one; It's not a valid method at all,
unless I totally misunderstand it.

>
> Method 2. HERE'S A MUCH BETTER WAY TO CORRECT THE LUNAR DISTANCE.
>
> Just as last time, assume that an accurate measurement has been made of
> latitude, from a Sun meridian altitude, and that later (or earlier) a lunar
> distance has been taken, but without measuring the Moon's altitude.
>
> This time, however, the navigator also measures an altitude of the Sun,
> ideally that same evening or morning, at a time well away (a few hours)
> from Noon. This is what was called an "observation for time", and taken
> with the known latitude, allows an accurate calculation of the Local Hour
> Angle of the Sun at that moment, within a very few minutes of arc. This
> requires no knowledge of Greenwich time.

Yes, now the problem is well determined. This is and was the standard method
for the case where terrestrial position is not known with absolute certainty.
The knowledge of  local time stemming from that additional altitude measurement
is not a luxury (to accelerate convergence, or whatever), it is a sine qua non
for the solution, because it provides you with the hour angles of the observed
bodies.

In order to clear the distance, you need to KNOW the triangle MSZ
(Moon-Star-Zenith). A guess is not good enough, because the subsequent
iteration marches towards the cleared (i.e. geocentric) distance MS by
adjusting GMT accordingly. There is no feedback from the iterative calculation
value for MS, you end up with wrong a GMT.

One way of knowing the triangle MSZ is to measure all three sides. The other
way is to compute MZ and/or SZ. For this you need the hour hangles.

There is exactly one moment of time in each sidereal month where the distance
between Moon and star is equal to MS, so M and S, and with them the whole
triangle MSZ, are nailed to the celestial sphere. So Z is nailed to the
celestial sphere at that very moment of the observation. The celestial
co-ordinates of Z are: Declination = your latitude, and RA of the zenith = your
local sidereal time. Without these, you cannot compute MZ or SZ. A similar
argument can be built for the Sun by replacing 'sidereal' with 'synodic' or
'solar', where appropriate.

We know that local time and latitude can be found from a combined altitude
problem. (Noon sight / time sight is a special case of that). Conversely, if we
know local time and latitude, we can find the altitude (distance) of any body
of which we know its co-ordinates, in particular those of the Moon and the Star
of interest. In other words, the information contents in a latitude/local time
pair or in a pair of two altitudes is equivalent.

With an initial estimate of date and time to the nearest month, plus 3
measurements, one of  which is a lunar distance, the other two are altitudes,
we find position and GMT. It does not matter whether we spread the measurements
out over a day or take them all at once, but to reduce the lunar distance we
must have all three. They are sufficient and necessary. That means that at that
stage we do have local time, implicitly or explicitly, like it or not.

>
> I ask Herbert Prinz which of these methods (or perhaps some other method)
> he uses when the altitudes of the bodies have to be calculated.

It depends on what else is given. Occasionally I am interested in the
circumstances of an occultation. This is a special case of a lunar distance.
When I want to know when it happens as seen from our local observatory, I
iterate GMT until the topocentric distance equals the semi-diameter of the
Moon. This brute force method essentially what I understand to be your method
1. It works when observer position is given.

For navigation I cannot imagine using anything but method 2 or variants
thereof. It works when local time is given and position is in question.

Chauvenet very briefly says, like everybody else, that altitudes can be
computed from hour angles and latitude, whereas  Ra and Dec Moon are taken from
the Ephemeris for approximate GMT. Then he suggests to iterate if the error in
assumed longitude is greater than 30". (I guess that is for land observation,
not for sea.) He also recommends that on land one should compute altitudes "as
thereby the observer gains time to multiply the observations of the distance.
But at sea, where an immediate result is required with the least expenditure of
figures, the altitude should be observed." Maybe, he was also thinking of the
fact that altitude observations on land are much harder than at sea, but he did
not say so.

> but I do to Cotter's "History of
> Nautical Astronomy". What Cotter has to say on the topic is very condensed,
> and not (to me) particularly clear. It's on page 206, as follows-

There, he speaks of solving the triangle  PZX, by which he means computing ZX
from angle XPZ. He deals with the XPZ triangle in more detail on p. 244, but
describes only the inverse operation, namely finding time from altitude.

>
> Cotter complicates matters by introducing the Right Ascension of the Moon,
> a concept familiar to astronomers but which for navigators was replaced in
> the Almanac by GHA, from 1952. Cotter was writing in 1968.

Cotter was writing ABOUT a time when the Nautical Almanac tabulated RA and Dec
and not GHA.

All navigation manuals of the 18th and 19th century that I checked (Moore,
Pezenas, Bowditch) employ the PZX triangle for calculating the altitudes, which
implies that one has local time. Most of the texts don't make a big deal of
this, because having local time and starting everything from there was taken
for granted. So it's easy to read over this. However, most manuals mention
calculated distances only in passing, as a fallback if one cannot measure them.

Borda, on the other hand, who deals extensively with lunars in his treatise on
the Reflection Circle, expresses the opposite view. He prefers computed
altitudes to observed ones whenever possible, for the reason that one  wants to
shoot the distance during the night, but establish time when the horizon is
more favorable for this purpose. He remarks that using computed altitudes is
easier on the observer (surprise!), heavier in calculatations (surprise!)  but
also more precise. The latter comment I find interesting, to say the least.
Borda's deadreckoning abilities must have been excellent.

Borda's worked example for computed altitudes extends over five pages. In it,
the resulting correction to be applied to the assumed Paris MT happens to turn
out as 2.5 min .  During this time Ra changes over 6 sec in Ra and 4" in Dec.
Strangely, Borda does not mention iteration at all. It would be perfectly
reasonable to neglegt such a small of error in practical navigation, if Borda
would not at the same time bother with a correction for oblateness of the earth
amounting to 3" of arc in order to show off a table that he devised for the
purpose.

Best regards

Herbert Prinz

```
Browse Files

Drop Files

### Join NavList

 Name: (please, no nicknames or handles) Email:
 Do you want to receive all group messages by email? Yes No
You can also join by posting. Your first on-topic post automatically makes you a member.

### Posting Code

Enter the email address associated with your NavList messages. Your posting code will be emailed to you immediately.
 Email:

### Email Settings

 Posting Code:

### Custom Index

 Subject: Author: Start date: (yyyymm dd) End date: (yyyymm dd)