NavList:

Chris Allison, you wrote:
"this was built to validate manual calculations using sight reduction tables requiring integer values. Azimuth needs to display tenths of a degree - it's an easy fix but does it have any real-world application?"

Trying to deduce something from your comment, I take it that your paper sight reduction method is HMNAO's "Rapid Sight Reduction Tables"? For anyone following along that's numbered NP303(AP3270) in the UK, and it's equivalent to Pub.249 "Tables for Air Navigation" ("air navigation" in name only) in the US. In those tables, as in Pub.229, one requires an integer value for LHA, but this is not a property of all manual sight reduction calculations. Many good paper sight reduction methods allow non-integer values for LHA and Latitude, and in that case the AP position can be chosen to be identical to any convenient position, like a DR or a destination point (if not too far off).

Another property of those "Rapid" tables: they give the azimuth to the nearest whole degree. This is fine, of course, but other tables and most calculations go one digit further. Displaying azimuth to the nearest tenth of a degree is probably a bit preferred unless you are absolutely sure that only users of the Rapid Sight Reduction Tables would be looking at your app.

With all that out of the way, of course the real reason that you're making this app (I'm guessing based on my own experience and many years of experience watching people develop similar tools) is because it's fun, it gives you the pleasure of building your own tools, and it's a great way to solidify your understanding of the material.

Why do I re-invent the wheel? Because I wish to be an expert in roundness! :)

So how's it built?! I looked at your code. Searching on "cos(" is a quick way to find the juicy bits! I can see pieces of the development cycle in there and lots of stock boilerplate, but I don't recognize it all. What's the development environment? Some Bootstrap? What else? I did discover, digging a little deeper, that you're using a standard javascript library for astronomical data. Which library is that? The keyword that many folks here would recognize in the code is "VSOP87" which means this is probably one of the implementations of "Astronomical Algorithms" by Jean Meeus. Or is there another source here? What's your refraction model? You don't have to answer any of these queries, by the way, if you don't want to give up details on a "product". I'm just curious.

How big is the total app when downloaded? I assume that this web app downloads its dependencies and required modules behind the scenes, as needed. Is there any way for a navigation enthusiast to get the whole thing as a unit? You mentioned that it works offline, and certainly there's a "market" for that. But how does an end user guarantee that it has been fully downloaded? Is there a way to check that it's all installed (apart from the obvious: cut the internet and see if it still works).

A couple of trivial suggestions: you allow height of eye in meters, but not feet. Quite reasonable except that nearly all US navigators still use feet exclusively (maybe "if (lang=='en-us') give_us_feet()"...?). It also seems that you limit height of eye to ten meters. I would suggest bumping that up to at least 100 and maybe even 500. Many people use apps like these when practicing from shore points, and hills, high bluffs and cliffs are popular.

Frank Reed
Clockwork Mapping / ReedNavigation.com
Conanicut Island USA