Curious about underlying algorithm

[0dB]

This seems to be just what I have been looking for and I will be spending some time with your explanations and code. I have yet to study the actual algorithm.

I am reading scientific papers and other resources on algorithms for the two-height problem. Just curious: Are you using a known algorithm or did you just "do the maths"? Are you aware of the work by Matthias Hoffrichter? He seems to have revived an "exact" algorithm by Gauss, which was not practical in the old days, but now is, since computers.

I found your site while looking for code and spreadsheets. Code that does not focus on the more or less imprecise graphical / intercept / lines of position (tangent) methods, but based on more exact methods, like the original Sumner and Gauss, meaning, methods based on circles of position / circles of equal altitudes.

[alinnman]

Hello 0dB!

No, I am not aware of the work of Matthias Hoffrichter.
The maths I use for this toolkit is based on a rather simple (trivial?) formula for deducing the intersections of small circles on a sphere. I found it described by Dutch game developer Thomas ten Cate, in this article. Initially I was just curious to see if this could be used for a simple foundation algorithm for celestial navigation, and I started working on this last summer. I have also had contact with him, offering a formal cred, but he politely declined the offer since the underlying maths is so basic (based on the Pythagorean theorem for a sphere).
The spherical problem is briefly described on this page. However, the more complex ellipsoidal problem requires more. I made an attempt over Christmas to make a "transform algorithm" where geodetic observations (sextant angles) are transformed to spherical, computations are done in spherical space and then are transformed back to a geodetical frame (WGS84). This is sketched in the doc you find here (Note the "C2D" and "D2C" transforms). The underlying code uses standard algorithms for the ellipsoid and you find source references in the code.

The goal of this work is described here. It is just a "hobby" project right now but it may grow to something bigger. It works, and I have made quite a few successful sight reductions myself (from home, and when traveling). I have also had contact with navigators across the globe and have successfully made sight reductions on their sights. Right now I am looking into the astrometics part of this, and will probably take a dive into SkyField (or similar code to get and process Hipparcos data) to use for the preparation of machine-readable Nautical Almanacs. To be continued! Down the road is the possibility of rebuilding the code as an app for the mobile phone.

[0dB]

Sure, is there a way to share it just with you?

Right, it would be good to see the circles in any case. (But I did double check that I used the same data for both apps, but who knows if I missed something 😊)

Ok, East is positive.

[alinnman]

In Google Colab go the "File" menu. Goto "Save a copy in Drive".
Make sure the notebook loads, it will now reside in your Drive area.
Now copy the URL from the address bar and give it to me.

Another maybe easier way is to go "File" -> "Download" -> "Download .ipynb". And then post it here as a file attachment.

[alinnman]

You can also send the ipynb to me as a mail. august@linnman.net

[alinnman]

I have now made a commit where handling of "Bad DRP:s" should work a lot better. There is a new optional parameter for SightCollection.get_intersections where you can state whether you think your DRP is good or not good. Default is not good. The price you pay for a bad DRP is longer execution time (but this is still just milliseconds..). The ellipsoidal algorithm (iteration) seems to converge nicely, at least when I test it, even if the DRP is located on the antipode.
I have also updated the ipynb:s, but not yet uploaded a new Colab sample.
Commit id: 0b2c6bc

[0dB]

Ok, today I am not getting the "math domain error" error, using two new sightings from today, and again entered into the "vacation" Colab notebook. (But see the interesting case in the following paragraph.) The fix, though, is about two or three times more "off" than with the Hoffrichter app (which in my first two days has been pretty close both times, like around only 2nm off). Again, like yesterday, I would say I have double checked everything, all my values, all corrections, all data from the Nautical Almanac, and again GHA and declination are plausible when checked against the app. Since I am using "lower limb" sightings (with an artificial horizon), I am applying SD corrections depending on the "apparent altitude" from the table called "Altitude Correction Tables for 10° to 90°", is that correct? I will double check if I am overlooking something here. (The values for today were +14.8 for late morning and +11.3 for early evening.)

I have noticed one thing: The program seems to be quite "volatile" regarding the SD correction. When I jiggle the values around a bit, I can again provoke the "math domain error". (For example when I used 16 and 14 instead of 14.8 and 11.3.) Like I said, maybe I have to check if I am doing everything right here. But maybe this is something that rings a bell for you? Can you already tell if I am doing something wrong regarding the semi-diameter (SD) correction?

I will send you the notebook with the "slightly off" SD values for today. If you like, I can also re-enter the values from yesterday (which also caused the math error) and send you that as well, let me know.

Edit: I would love to see some graphical results when the "math domain error" arises, e.g., what the circles look like, if they are too small and don't intersect. I have not tried out your new code yet, am still just playing with the Colab notebook, let me know when you have updated that 😊