Welcome to the NavList Message Boards.

NavList:

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

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    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
    to adjust MS or any parameter that generates it. If you start with a wrong
    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.
    
    > I don't have ready access to Chauvenet,
    
    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
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

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

    Email Settings

    NavList ID Code:

    Custom Index

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

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site