Celestial Navigation Plugin Redux

[rgleason]

Nav, I was just suggesting that the sight circles could be supplemented with a second offset line which adjusts all the sight circles to be as if they were taken at the same time.

(I think you may be suggesting that the boats speed and direction (DR) also must be a part of this secondary calculation?) If so perhaps there should be some entry fields for that as well when placing the secondary line.

[seandepagnier]

I had a plan before, to allow first, to adjust all the time offsets. This means with 3 or more sights, you could calibrate your clock.

Another possibility, if there are enough sights to correct errors in assumed speed and bearing.

[rgleason]

I had a plan before, to allow first, to adjust all the time offsets. This means with 3 or more sights, you could calibrate your clock.

Another possibility, if there are enough sights to correct errors in assumed speed and bearing.

I like the sounds of your earlier plan, but don't understand enough yet.

If one takes a sight at a certain time (altitude angle), is it possible to move the sight forward in time (do you use the same altitude angle?) without knowing at least the DR speed and course? Say you are headed west and the sightings are taken spread over 15 minutes, wouldn't the calcs for adjusting to a common time be different than if you are heading east?

Maybe there should be a place for entry of assumed position, boat speed and course, so that at least that information can be used when adjusting the time of the sightings? You mention that with enough sightings you could derive boat speed and course more accurately. This sounds like a difficult multi-variable problem to me, but I am not as good at math as you Sean.

Also, would you advance time to the most current sighting, Or give the navigator a chance to enter a time?

I think for simplicity, you'd probably show the derived sightings, but don't know what the standard is... I think it would be best to keep the programming problems simple....rather than complicated, and my pull out a line segment idea might require more UI and interface programming work.

NAV what are your thoughts on this? We would appreciate some quidance.

[rgleason]

Sean just git pulled a 3 day old, I just found. Sorry, I tried a git pull earlier, but somehow it had not registered or pulled new.
It compiles now, no inttype.h error. Thank you. Will upload now too.

Build succeeded.

"C:\Data-Dart\Up-Soft\Navigation\o-plugin\celestial_navigation_pi\build\ALL_BUIL
D.vcxproj" (default target) (1) ->
"C:\Data-Dart\Up-Soft\Navigation\o-plugin\celestial_navigation_pi\build\celestia
l_navigation_pi.vcxproj" (default target) (3) ->
(ClCompile target) ->
..\src\CelestialNavigationDialog.cpp(163): warning C4800: 'int' : forcing valu
e to bool 'true' or 'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigati
on\o-plugin\celestial_navigation_pi\build\celestial_nav igation_pi.vcxproj]

1 Warning(s)
0 Error(s)

..CPack: Create package
CPack: - package: C:/Data-Dart/Up-Soft/Navigation/o-plugin/celestial_navigation_
pi/build/celestial_navigation_pi-1.9-win32.exe generated.

[NAV]

Coming days I cannot spend much time on this discussion, due to other work.

For the moment I'm a bit confused by all circles and lines and probably don't understand the ideas both of you mentioned in your last posts . And I still have the wish to some textual explanation about the theoretical background of the computational methods used by Sean.

If time permits, tomorrow I'll download the latest plugin version which Rick seems to have build yesterday.

[NAV]

Originally Posted by rgleason

If one takes a sight at a certain time (altitude angle), is it possible to move the sight forward in time (do you use the same altitude angle?) without knowing at least the DR speed and course?.

In my opinion yes, speed, track direction and time difference between two observation times are sufficient to calculate the distance a LOP/COP has to be shifted along the track line (from the intersection of a COP with this track line).

Originally Posted by rgleason

Say you are headed west and the sightings are taken spread over 15 minutes, wouldn't the calcs for adjusting to a common time be different than if you are heading east?

No. Just use the standard nautical methods for DR calculations.

Originally Posted by rgleason

Maybe there should be a place for entry of assumed position, boat speed and course, so that at least that information can be used when adjusting the time of the sightings?

I think that would be useful. Input either manual or, when possible, automatically from other available OpenCPN data.

Originally Posted by rgleason

You mention that with enough sightings you could derive boat speed and course more accurately.

So far, I don't understand this theory at all.

Originally Posted by rgleason

Also, would you advance time to the most current sighting, or give the navigator a chance to enter a time?.

Most current sighting is general practice. Sometimes it might be easy to choose an 'easy' time (full hour or full half hour).

Originally Posted by rgleason

NAV what are your thoughts on this? We would appreciate some quidance.

I'm wondering whether each circle can be moved to a common time, before the position calculation and graphical calculation takes place.

The Nautical Almanac shows a method to directly calculate a position from intercept (Ho-Hc) and azimuth of the body, using the earlier mentioned iteration method (input MPB as new DR position for 2nd iteration; the NA however uses a maximum acceptable distance of 20 NM, where I mentioned 30 NM).

[NAV]

Attached is a Word doc with a comparison between the plugin and an example from the Nautical Almanac, for altitude reduction only.

[seandepagnier]

Originally Posted by rgleason

Maybe there should be a place for entry of assumed position, boat speed and course, so that at least that information can be used when adjusting the time of the sightings? You mention that with enough sightings you could derive boat speed and course more accurately. This sounds like a difficult multi-variable problem to me, but I am not as good at math as you Sean.

I was considering just using two sliders (or a single 2 axis slider) one for boat speed, the other for direction. Then if you have say 5 or so sights, spread over time, set the sliders to your assumed course and speed. Now you can adjust the sliders to watch the circles converge on the chart to all overlap on a single position. This corrects your assumed direction and speed as well as actual location.

The problem with this method is, it would not work if the speed or course changes while taking the sights. If the speed and course doesn't change much, and there are many sights, say 6 or more over a short period, of a few hours, and hopefully getting sights from multiple celestial bodies, I think this could allow some interesting correction.

Also, would you advance time to the most current sighting, Or give the navigator a chance to enter a time?

Already each sight has a unique time for when it was taken.

I think for simplicity, you'd probably show the derived sightings, but don't know what the standard is... I think it would be best to keep the programming problems simple....rather than complicated, and my pull out a line segment idea might require more UI and interface programming work.

Yes, well I could use line segments, but it is simply not as correct and since we are using computers that do millions of calculations in a second. The same is true for mercator charts. We use these on opencpn, and I hope to correct this in future versions by supporting various projections. Mercator dates to an era before computers when the world needed to be made flat so it could fit on papers. Now computers can render everything in 3 dimensions and get an accurate projection for every location, especially polar regions.

It might be the only way I can estimate a fix using multiple sights over time though. It can also estimate course and bearing (would need at least 4 or 5 sights)

Originally Posted by NAV

Attached is a Word doc with a comparison between the plugin and an example from the Nautical Almanac, for altitude reduction only.

I will take a look. First I want to fix errors with calculations if there are any.

[rgleason]

Dear Nav and Sean,
I found your responses very informative and I think I understand Celestial Navigation better than before - Thank you.

I am confident that Sean will find an appropriate way to handle time normalization and the use of estimated boat speed and direction and I hope NAV will "stay tuned" and thank him for the response during a busy work schedule.

I like the concept of the boat speed and direction sliders, and I am intrigued by the idea of using spherical charts.

[NAV]

Two articles about direct computation:
http://ind.ntou.edu.tw/~mmsel/Data/R...%20315-335.pdf

http://fer3.com/arc/imgx/v44n1-2.pdf

And a general, but very clear text on celestial positioning can be downloaded from here:
http://www.celnav.de/page2.htm

[NAV]

Originally Posted by boat_alexandra

Can I download the nautical almanac you are using so I can make some comparisons as well?

I finally found a digital Nautical Almanac on the web. It's from 1994. Link: http://reednavigation.com/files/Naut...manac-1994.pdf

Another article on direct computation:
http://fer3.com/arc/img/122939.celnavalg%20tsau.pdf

[NAV]

Originally Posted by boat_alexandra

I was considering just using two sliders (or a single 2 axis slider) one for boat speed, the other for direction. Then if you have say 5 or so sights, spread over time, set the sliders to your assumed course and speed. Now you can adjust the sliders to watch the circles converge on the chart to all overlap on a single position. This corrects your assumed direction and speed as well as actual location.

Correct me if I'm wrong, but when you move the COP's such that these intersect in 1 point only (the fix) and recalculate speed and track from this, you assume automatically that there are no other errors in measurement and calculation.

[NAV]

Originally Posted by boat_alexandra

The problem with this method is, it would not work if the speed or course changes while taking the sights. If the speed and course doesn't change much, and there are many sights, say 6 or more over a short period, of a few hours, and hopefully getting sights from multiple celestial bodies, I think this could allow some interesting correction.

Standard practice in navy and merchant navy with regard to celestial positioning is as follows (assuming no artificial horizon is available on the sextant):

• During morning nautical twilight (about 15 minutes): if possible take 6 star/planet observations.
• In the morning at about 09:00LT: take a sun's observation (later to be shifted to noon-time).
• At local noon: take a sun's observation (traditionally only direct latitude calculation from sun at meridian passage). Construct a fix for noon from both sun observations.
• During evening nautical twilight (about 15 minutes): if possible take 6 star/planet observations.
• Use moon for an observation in above practice when situation permits.

[seandepagnier]

Originally Posted by NAV

Correct me if I'm wrong, but when you move the COP's such that these intersect in 1 point only (the fix) and recalculate speed and track from this, you assume automatically that there are no other errors in measurement and calculation.

Since the COP's in this case are really areas of position (they have thickness) then in some sense, if it minimizes the overlapping area at the fix it is still considering error, but of course, it may be trading one error for another. At least the sights which are at the current time won't be shifted, and the oldest ones may be adjusted more. I am very busy on some projects, but I do intend to improve this plugin a lot.

[rgleason]

So the visual result of the overlapping "wide band" would give the navigator an understanding of the amount of possible error. By adjusting the error band for each COP to what is appropriate the navigator may be able to give appropriate "weight" to to the fix.

It might be helpful to have "eyes" to show/hide and recalculate the fix easily dropping one or two sightings, if possible.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app