# 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:
On improving data
From: Peter Fogg
Date: 2003 Jan 18, 05:17 +1100

```Dan Allen wrote:

> ... like my land sights: some are amazingly accurate while
> others are not.  We know this because we have the luxury of comparing
> our sextant results with an averaged GPS location or a typographic map
> location.
>
> But how would we do without these crutches?  How would we do on a
> rolling ship in a storm?  What statistical measures or rules of thumb
> can be
> used to help throw out the bad sights and keep the good ones?  This is
> an
> area that I am considering more and more.

The common answer is to 'average' a series of sights. The problem with
this is that the bad sights pollute the others, and there is no way to
know just which is what from just looking at the numbers. But there is a
technique to separate the good from the bad, so telling which is which
becomes clear with a glance. It has been described before but may bear
repeating.

The rate a celestial body appears to rise or fall over a 5 minute period
can be expressed as a sloping line on a graph. If the sights taken (as
many as possible of the same body over the 5 minutes*) are plotted above
this line then a second line can be drawn parallel which best fits the
pattern of sights - they should also rise or fall. Then any point along
this 'line of best fit' can be used for the 'time/sextant altitude' data.
Any sights that are wildly off are ignored, so unlike 'averaging' they
make no contribution to the result.

That's it in a nutshell. The bad sights are obvious - they are the ones
far from the 'line of best fit'. The reasonably good ones will lie just
above and below the 'line of best fit' - meaning that the line may give a
more accurate result than any individual sight. And this is my experience.
Its a technique ideally suited for the 'rolling ship in a storm'. An
additional advantage is that a precise time for the sight can be chosen in
advance, by starting the sight taking process a few minutes before and
extending it a few minutes after the exact time required. Whether you took
a sight at the right moment and whether that one is any good is
irrelevant. This enables, for example, a sight when the body is at 90 or
270 degrees of azimuth, giving a line of position that indicates the
longitude.

The alternative seems to be to take sights of multiple bodies and discard
the LOPs that seem wrong, compared to the others. But this entails much
more work, lots of sight reduction, improved possibility of error. Then
you are left with a plotting sheet full of confusing lines. With multiple
LOPs all over the place I find it difficult to choose the point of fix .
If some of these bodies have similar azimuths their usefulness is
questionable - they are more likely to promote further confusion. Better,
I propose, to have just 3 bodies with nicely separated azimuths, and the
assurance in advance that they are quite accurate.

expand further. Its a simple routine and I am mildly surprised that it is
not more widely known and practiced - it is simpler to do than to
describe.

(PS*This reminds me that I've been reading about how the United States was
comprehensively surveyed, a mammoth task. They found that the best
technique was to get their sights done quickly; that extra fiddling with
the theodolite was counter-productive - it tired the operator and, in any
case, led to less accurate results.)

```
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)