Celestial Navigation Plugin Redux

[seandepagnier]

Originally Posted by NAV

Each observation has it's own observation time, but which time is used for the fix?

There is no time for the fix. The fix is a position. If you enter a few sights they may all have different times, it will compute a fix for a position on the earth.

In case the star observations span 15 or 20 minutes and the vessel speed is relatively high, the LOP's (when using the old fashioned computational methods) should be shifted to one time, according to speed and course of the vessel. How does the plugin handle this?
Traditionally (because it's so easily done), a noon position is obtained from a sun sight at 12:00 LT an a (shifted) sight at about 09:00 LT. As I understand so far, this is not possible using the plugin.

It is possible. You can enter the bearing and estimated distance to shift the sight.

The plugin cannot compute a fix anymore because it is not possible to do so. It uses least squares to compute the fix from many sights from spherical circles. If you shift the points that define a spherical circle on a sphere by a distance and bearing, unless the bearing is due east or due west, or the circle is a great circle, the result is no longer a circle. Consider the case where the circle is shifted north through the pole. The bearing is relative to each point on the circle, so the result is a figure 8. I could get into more detail about this and I explain it in the documentation, but the result cannot be used in my least squares equations. Instead the fix must be determined visually. Maybe this math problem can be solved, and maybe it can determine the fix from using all the thousands of computed coordinates rather than spherical circles.

This leads me to the question: can I obtain somehow a textual description of the computational methods that you use in the plugin?

It is on the computations tab when you edit the sight correct?

Will follow later ...



Yes, same problem. Entering two sights, double clicking on one of them in the main window (or selecting one and clicking on the 'Edit' button) shows the other sight and vice versa.

Originally Posted by NAV

In case an error is made entering the sight data, corrections cannot be made. Any corrections for a sight made via the 'Edit' button are not being saved.

I will look into these

[rgleason]

Sean,
Nav is right about the selection of Sights for Editing. When you select by highlighting a sight, the wrong sight data comes up. This makes it very hard to edit sights, because what you edit is saved back to the sight that was selected! Obviously there needs to be parity between the sight selected, the sight brought up for editing and the sight that is saved.

I'll continue testing with the textbook example after you can fix this problem.

[NAV]

Originally Posted by boat_alexandra

There is no time for the fix. The fix is a position. If you enter a few sights they may all have different times, it will compute a fix for a position on the earth.

In navigation, a fix is a position at a certain time.

If you observe the altitudes of a number of heavenly bodies (at different times, to obtain a fix) the resulting LOP (or COP) for each observation is correct only for the observation time of that particular body. So the initially derived LOPs should be moved such (speed, course, time period) that the moved LOPs represent a common time (often the time of the last observation is used for the fix time). Traditionally, that is done by plotting on the chart.

Bowditch 2002 states on page 296, paragraph 2004:
"A navigator often takes sights of more than one body when determining a celestial fix. After plotting the lines of position from these several sights, advance the resulting LOP's along the track to the time of the last sight and label the resulting fix with the time of this last sight".

[NAV]

Originally Posted by boat_alexandra

It is possible. You can enter the bearing and estimated distance to shift the sight.

The plugin cannot compute a fix anymore because it is not possible to do so. It uses least squares to compute the fix from many sights from spherical circles. If you shift the points that define a spherical circle on a sphere by a distance and bearing, unless the bearing is due east or due west, or the circle is a great circle, the result is no longer a circle. Consider the case where the circle is shifted north through the pole. The bearing is relative to each point on the circle, so the result is a figure 8. I could get into more detail about this and I explain it in the documentation, but the result cannot be used in my least squares equations. Instead the fix must be determined visually. Maybe this math problem can be solved, and maybe it can determine the fix from using all the thousands of computed coordinates rather than spherical circles.

I noticed that I can enter course and distance for shifting. But how does the plugin use this? The only reason to shift a LOP is to be able to construct or calculate a fix at a common time from LOP's derived at different times, but the plugin cannot do this as you explain in the documentation and again in your message above.

I wonder (but I'm no programmer and I don't know which computational methods you're using) whether it might be possible to calculate tangent lines to each COP and use these as a basis for fix calculation (i.e. the traditional way).

[seandepagnier]

I have tried, and the plugin works fine, maybe the problem is wxwidgets on windows.

The problem before with the azimuth was only on windows too, it is very hard to fix problems with an operating system I do not have.

[seandepagnier]

Originally Posted by NAV

I noticed that I can enter course and distance for shifting. But how does the plugin use this? The only reason to shift a LOP is to be able to construct or calculate a fix at a common time from LOP's derived at different times, but the plugin cannot do this as you explain in the documentation and again in your message above.

I wonder (but I'm no programmer and I don't know which computational methods you're using) whether it might be possible to calculate tangent lines to each COP and use these as a basis for fix calculation (i.e. the traditional way).

The plugin does not know where you are in the world. On paper, you may shift the line of position by a distance and bearing, but how do you know what slope to draw the line in the first place? It is because of a dead reckoned position! If this position is wrong, then the line was wrong.

This means, you will have errors from using lines rather than the true sight positions, and also because you don't know what slope to use for the line, this is based on a dead reckoned position which may be completely wrong.

To be clear, using the traditional method, you must have a good guess of your position, if this guess is hundreds or thousands of miles wrong, it won't work.

The plugin doesn't make such assumptions, and works without the inaccuracies of a guessed position, and therefore is far more accurate than the traditional method.

It propagates each position on the resulting circle of positions by a distance and bearing relative to where that position was to give the correct result.

Is there something wrong with determining the fix by viewing where the sights intersect on the chart?

[rgleason]

Sean I empathsize. Long pole problem... hopefully this will be solved when the package arrives! So you can actually see and use it on win.

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

[NAV]

Originally Posted by boat_alexandra

The plugin does not know where you are in the world. On paper, you may shift the line of position by a distance and bearing, but how do you know what slope to draw the line in the first place? It is because of a dead reckoned position! If this position is wrong, then the line was wrong.

This means, you will have errors from using lines rather than the true sight positions, and also because you don't know what slope to use for the line, this is based on a dead reckoned position which may be completely wrong.

To be clear, using the traditional method, you must have a good guess of your position, if this guess is hundreds or thousands of miles wrong, it won't work.

The plugin doesn't make such assumptions, and works without the inaccuracies of a guessed position, and therefore is far more accurate than the traditional method.

It propagates each position on the resulting circle of positions by a distance and bearing relative to where that position was to give the correct result.

Dead Reckoning is an important part of navigation. Nowadays, I cannot imagine a navigator not knowing his DR position to within a hundred nautical miles. DR positions are always 'wrong', but generally for celestial positioning that is not a problem. Errors caused by using LOP's instead of COP's are generally negligibly small when the distance between DR position and calculated (Most Probable) position is less than 30 NM. When this distance is more then 30 NM, the calculated (Most Probable) position can be used as DR position to recalculate the fix, using the same observation data.

Measurement errors (altitude and time) are generally the largest errors encountered in celestial positioning. These are caused by unknown instrument errors, bad visibility of horizon or body, moving vessel and operator errors. Whatever computation method is used, these errors will stay. A standard deviation (1 sigma) of a single astronomical LOP of 1.5 NM is a reasonable guess, as stated in the German navigation bible "Leitfaden der Navigation". This means that your position is 95% sure to be within 3 NM from that LOP.

Nothing wrong with visually checking the COP's on the chart, but it's a bit strange to see the calculated position disappear when course and distance are entered to shift a COP.

A question I have is how a navigator can guess what the error margin is for each individual measurement that he enters for altitude (default set at 0.25 degrees!) and time (default set at 1 second).

[seandepagnier]

Originally Posted by NAV

Dead Reckoning is an important part of navigation. Nowadays, I cannot imagine a navigator not knowing his DR position to within a hundred nautical miles. DR positions are always 'wrong', but generally for celestial positioning that is not a problem. Errors caused by using LOP's instead of COP's are generally negligibly small when the distance between DR position and calculated (Most Probable) position is less than 30 NM. When this distance is more then 30 NM, the calculated (Most Probable) position can be used as DR position to recalculate the fix, using the same observation data.

I completely agree. You could simply iterate a second time to eliminate the error.

Measurement errors (altitude and time) are generally the largest errors encountered in celestial positioning. These are caused by unknown instrument errors, bad visibility of horizon or body, moving vessel and operator errors. Whatever computation method is used, these errors will stay. A standard deviation (1 sigma) of a single astronomical LOP of 1.5 NM is a reasonable guess, as stated in the German navigation bible "Leitfaden der Navigation". This means that your position is 95% sure to be within 3 NM from that LOP.

Right, the biggest source of error is generally the sextant measurement, not the incorrect dead reckoned position.

Nothing wrong with visually checking the COP's on the chart, but it's a bit strange to see the calculated position disappear when course and distance are entered to shift a COP.

I agree it is strange. The current way it computes fixes is really cool, but cannot work for distance/bearing shifts. So, yes I see what you mean, we could implement a way to compute a fix which works also for running sights, using lines of position, and least squares, then iterating 2 or 3 rounds to eliminate any errors. I believe the initial dead reckoning position would be required though.

You might notice it is already needed for only 2 sights and in some cases for more sights as they can have multiple possible fix locations which are very far apart and the program cannot know which to pick.

A question I have is how a navigator can guess what the error margin is for each individual measurement that he enters for altitude (default set at 0.25 degrees!) and time (default set at 1 second).

Good question. Maybe after using the plugin enough he will know what the error is, maybe not. Maybe we should have an option for no error, just showing a line.

I think higher incline shots have more error, so maybe that could somehow be added. In any case it isn't used for fix calculation.

[rgleason]

Nav is right about the selection of Sights for Editing. When you select by highlighting a sight, the wrong sight data comes up. This makes it very hard to edit sights, because what you edit is saved back to the sight that was selected! Obviously there needs to be parity between the sight selected, the sight brought up for editing and the sight that is saved.

Just so I understand, Sean are you saying you can't fix this windows problem?

http://www.cruisersforum.com/forums/...ml#post1593698

[seandepagnier]

Maybe you can click on the other sight to edit the one you want for now? Eventually this can get fixed.

[rgleason]

Attached are screenshots of the plotting of the 4 stars, as I entered them. I hope this is close enough to the altitude intended. The initial positon is shown as a MOB symbol and the fix by the math techniques outlined by Sean is shown as a Pink circle. This is shown in the close up screenshot.

There is the Nav's word doc attached with the Calculation output for each star cut and pasted in at the end from the Calculation Tab.

===========================
First and Last Sighting switch, when Editing, Problem
==================================

There are three screenshots. The last two show the problem with the Windows version of the plugin Switching First and Last Stars...
The stars fixes are listed in this order:
Hamal
Canopus
Capella
Procyon

1. Click on Hamal brings up Procyon, if you edit Procyon and save it saves to Procyon!

2. Click on Procyon brings up Hamal, if you edit Hamal and save it saves to Hamal!

=======

TIME entry problem
=================
There is another problem with entering Time. For the longest time, repeatedly I would bring up a star and it would have July 28, 1978 for the time. I would change the month to February and hit OK, but the July would stay the same in the window!

So then I would bring up the fix again, and reenter Feb at the Time tab, then I would tab out of the the date entries, then hit each TAB, going back to time, check to make sure "February" still showed, then hit "OK" to close. Often this would not change the July listed in the window to "February".

So I would open the star fix again, and check the Time tab, ...It showed "February"!!!! which surprized me. So I thought the changes were not being written to the CN Sights window... So I closed the plugin and reopened it. "July" still appeared.

So then I went on to another pesky fix which did not show the right month, similar problem. While I was fixing that month at some point, the CN Sights screen was rewritten, and eventually I got the sights on the right times.

Once that happened the circles made some sense, and were much closer to the initial position given.
==========

Color change problem
======

When I make a change in color, the changed name of the color does not show up in the Celestial Nav Sights window, the original color name stays there.

I believe both of these problems are because the CN Sights window is not rewritten after changes.

=========

[rgleason]

Paraphrase of Sean's very interesting writing on the methodology, some of which should probably be put in the description - instructions.

Because the program is using a more accurate "modern" Least Squares calculation without advancing an LOP using DR to put all sights at the same time:
1. Determining the "Fix" requires visual inspection and location of the two read cross hairs, with the cursor located over it to drop a waypoint and click on properties to get the Lat/Long
2. This calculation technique does not have "Time" associated with it, (it is just a position). -Question: Is is fair to assume that the time could be the average of the times?
3. This calculation technique does not permit easy linear transformation along an LOP because of problems with the circles placed.
======

My suggestion is to keep the current methodology and calculation just as it is, without linear transformation along LOP of the circles.

Then later add a separate function which will allow advancing an LOP with a short line segment pulled out of the circle near the "Fix" which then shows a popup with "Time" in it, so the user can then place the line segment along the DR route at a similar time to the other sights. Then once there is a purely graphic representation of the 2,3, or 4 sights all at the same time, allow the navigator to calculate his own fix in a traditional way. These features would be a completely separate routine, just using the sight circles for pulling out the short line segment.

Sean has probably figured out a better way of doing it, perhaps by leaving the "Sight" circles in place, but adding companion "Time adjusted" circles (Dashed) which uses some user entered time. Then the least squares calc could be done on the dashed companion "Time adjusted" circles.

[rgleason]

I adjusted the error from .25 to .05 for each of the 4 sights to make things easier to see.

There could be a manual "Adjust Sight Time" mode, that allows Navigator to pull out a line segment that shows a dynamic time.

Alternatively a time entry window would pop up to enter date and time wanted, hit enter and the time offset is calculated and an offset line segment is placed.

Do similar to other sights to place common time segments.

Then graphically solve it by drawing lines to find a reasonable fix, or use other more traditional graphic methods.

[NAV]

Originally Posted by boat_alexandra

You might notice it is already needed for only 2 sights and in some cases for more sights as they can have multiple possible fix locations which are very far apart and the program cannot know which to pick.

The program doesn't know (unless OpenCPN plus any electronic positioning system is used, or in case OpenCPN can carry out DR calculations based on course and speed input by the navigator), but the navigator should know and can enter it as input. The distance between the two intersections of two COP's is generally so large, that under normal conditions no doubt can exist which one to choose as the Most Probable Position.