Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: Exercise #14 Multi-Moon LOP's
    From: George Huxtable
    Date: 2009 May 3, 15:31 +0100

    Frank Reed wrote-
    "most of these software packages do exactly the same thing: they use the 
    least squares solution for multiple sights provided in many sources, 
    including every copy of the Nautical Almanac for some twenty-odd years. "
    Indeed, that's true. The Nautical Almanac provides a routine by which an 
    increasingly good fit can be made to a series of observations by a 
    least-squares process, under the heading "Position from intercept and 
    altitude by calculation". What the almanac omits is any estimate of the 
    errors involved in that process. That omission is made up for, in 
    "AstroNavPC and compact data", from her majesty's nautical almanac office 
    (in my now-outdated edition 2001-5, the error ellipse estimation procedure 
    is described in para 7.5).
    He adds
    "In a (typical) rapid-fire fix, the error ellipse will be aligned with its 
    long axis perpendicular to the mean azimuth of the sights (quite comparable 
    to lat/lon at noon, by the way). The error in this direction is given 
    approximately by (3/2)*S/(sqrt(N)*A) where S is the standard deviation of 
    the observations themselves, N is the number of sights, and A is the range 
    of azimuth in the sights (azimuth expressed as a pure number, "in 
    That may perhaps be so, but Frank gives no reference or reasoning to back 
    it, for us to check for ourselves. It's somewhat disconcerting to find that 
    the multiplier constant is uncertain by a factor of nearly 2 (0.8 to 1.5). 
    Does that expression take account of the uniform spacing of the observations 
    over the time-span, as Frank proposes? How would it differ, then, if 
    instead, half were closely grouped at the start of that time-span, and the 
    rest at its end? That was a question that's been asked but not yet 
    and continues-
    "So take Jeremy's moon sights in his "Exercise #14". First, we need the 
    standard deviation of observations. Jeremy has posted quite a few cases, and 
    he gets pretty good sights, with s.d. around 0.5 minutes of arc. In this 
    particular set, N is 11, A is 0.1 (5.5 degrees is a tenth of a radian). So 
    the standard deviation "cross-range" would be 2.3 nautical miles. Pretty 
    Not quite that good. Indeed, Jeremy's observations show little scatter; my 
    own estimate of the standard deviation, in [8062]  was somewhat less than 
    Frank's. It shows what can be done from a big-ship, in good conditions. 
    Taking Frank's error formula at face value, if you refer to the data-sets in 
    Jeremy's linked file, at
    the range of azimuths is 4.4 degrees, not 5.5, which makes the factor A 
    0.077, not 0.1, making the calculated scatter 30% greater, or now, 3 
    nautical miles. So our position ends up as somewhere within a bracket 6 
    miles or so either side of the estimated position. Not a marvellous result, 
    when you take the high  precision of the original observations, and the fact 
    that it called for 11 such observations to be made. Alternatively, if, after 
    just a single such observation, Jeremy had simply waited a few hours, then 
    taken one additional Moon altitude, at a moment to suit himself, the 
    uncertainty should have been within a mile. Or instead, he could have 
    immediately taken a sight of another object in a different direction. So, 
    hardly a saving of effort, this "rapid-fire fix". Instead, a 
    labour-intensive method for discarding most of the inherent precision 
    achievable from celestial observation, and ending up with a second-rate 
    Frank has presented this particular observation as an example of his 
    proposed method; indeed, the only example he has offered so far. Was this a 
    typical situation, then? Far from it. Jeremy's own words, in [6066] explain 
    "that is why I shot the moon, as the azimuth is changing rapidly, even away 
    from the time or meridian transit" It was selected, deliberately, for 
    enhanced effect.
    And indeed, that was the case. In the 7min 48 sec of the observation set, 
    the Moon's azimuth changed by 4.4�, or at a rate of 34� per hour, mainly 
    because it was rather high in the sky. In most circumstances, a typical rate 
    of change is more like 15� per hour, corresponding to the spin rate of the 
    Earth. In which case, the errors that we've seen in this example would be 
    more than doubled.
    Frank had a dig at me, in [8145], when he wrote- "I reminded the group of an 
    interesting case where someone on NavList actually tried this out for 
    himself, rather than just pontificating and declaring it impossible from his 
    armchair, as you have done, George. It was an EXAMPLE of the sort of results 
    you can expect in the real world." It's the responsibility of the proponent 
    of such a notion to rise from his own armchair and try it out to show 
    results that prove its  worth, but Frank has not bothered to do so. It's 
    left to others to point out the weaknesses in the optimistic gloss, which is 
    all we've been offered so far.
    contact George Huxtable, at  george@hux.me.uk
    or at +44 1865 820222 (from UK, 01865 820222)
    or at 1 Sandy Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK.
    Navigation List archive: www.fer3.com/arc
    To post, email NavList@fer3.com
    To unsubscribe, email NavList-unsubscribe@fer3.com

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

    (please, no nicknames or handles)
    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 Settings

    Posting Code:

    Custom Index

    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