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
    Computing Lunar Comparing Distances by "Plane Sailing"
    From: David Iwancio
    Date: 2021 Jan 7, 04:18 -0800

    I've been considering the idea that, once a single comparing distance between the moon and another body has been computed rigorously with great-circle calculations, further comparing distances for the next several hours can be computed with plane trigonometry (specifically mid-latitude saling) while still keeping the same 0.1' precision.

    It's the same concept as "interpolating for latitude and local hour angle" as described in HO 229, only doing it numerically instead of graphically to preserve accuracy.

    As a worst-case scenario, if the moon and (for example) Venus are both at declination 30° (same name), the difference between the great circle distance and rhumb line distance doesn't reach 0.05' until their hour angles differ by around 6°, and accounting for rounding errors there isn't a consistent error of 0.1' until around a GHA difference of 8° or so.  Along the 30° parallel, HO 229 gives the same result at 7° LHA as a traverse table gives for a DLon of 420.

    If we compound this worst-case scenario by giving the moon a v value of 0.0' and Venus a v value of +4.0', (keeping the d value at 0.0' for both)  the difference between their hour angles is changing by 45.0' per hour.  Treating the moon's motion as parallel sailing still gives more than 8 hours' worth of usable comparing distances.

    Realistically, it seems half a day's worth of comparing distances could be produced from a single computation of great-circle distance and direction from the moon's position in the sky.

    There's no real saving of effort if you're only looking for a single pair of comparing distances (say, t[0] and t[1]), since you'd be replacing two "altitude" computations with an "altitude," an "azimuth" and some traverses.  But if you have concerns about second differences, this would let you compute four distances much faster than you could otherwise.

    (Or I suppose this approximation lets you use v and d values for a given hour in a simple differential equation rather than determining second differences at all.)

    From what I can tell, course angles and mid-declinations would be needed to an accuracy of 0.1°.  This is a lot of page-flipping to interpolate with your typical traverse tables, though the maximum difference to interpolate across would be about 3.0'.  Table openings would be reduced by determining the same quantity for all desired times at once (they generally won't change much) rather than working each desired time separately.  On the other hand, five-figure logarithm tables would be overkill.  Rounding logarithms off to three figures would be enough, and at that resolution distances up to at least 360' (6°) can be treated as equal to their sines, saving the need for a separate table.

    Thoughts, if any?

       
    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