NavList:

Dave Walden, you wrote:
"There are limited options for the API.  There is some info on the USNO site.  The values are given to 3 decimal places."

I looked through the re-written docs briefly when you first posted the announcement five daya ago. It seems to be a little bit more detailed than the old system. Personally, I wouldn't call it an API since it's just URL modification. That's the oldest trick in the book for interactive web apps. My web apps have editable URLs. Even the NavList message boards do. But I wouldn't call these APIs. Setting that aside, is there a direct option to output decimal minutes of arc instead of decimal degrees? Or is there any option to return more than three digits past the decimal point in decimal degrees? If not, this introduces a small, but noticeable, rounding problem which will lead to fairly common differences between this new web app and the published Nautical Almanac (or equivalent systems with good accuracy, of which there are now many). An example: suppose the Declination of some star ends in 0.2142° with the understanding that the fourth digit past the decimal point is actually meaningful, significant. If we publish that value rounded to three decimal places, the result is 0.214°, of course. Or we could convert the angle, 0.2142°, to minutes of arc and then round to tenths (multiply by 60, then round). The result is 12.9'. But if they only publish the value rounded to three decimal places and then we do the conversion to minutes of arc after, the result is 12.8'. This is insignificant for navigation, but it's a question of data authority, provenance, validation, and all that. The numbers from the USNO web app should be able to reproduce the actual values in the Nautical Almanac (except in a few specific, well-known cases, which they warn about).

You wrote:
"Some comparisons seem to show agreement with the old ICE results, which is not a good thing."

The engine underneath the old web app was always an evolution of the old ICE (stand-alone, DOS) app. Are you saying that it appears to be a match for the older (un-evolved!) ICE app? What evidence are you seeing?

You added:
"would be nice if they returned deltaT."

Test the Moon's position in 2050. That should be revealing. For historical positions through the present (c.1750 to 2022), delta-T is a known value and should not be open to question.

You concluded:
"ps Can I chose a font for a post?  Seems hard to keep columns aligned."

No, I fixed up a couple of your posts manually to get alignment, but that's not a solution. I do have a recommendation. Since the USNO app team is almost certainly in the process of finalizing their own standard, formatted output, probably similar to the old web app, duplicating that would be pointless (unless you're trying for "black magic", like my web app clone!). In addition, solutions like fixed width fonts are a bit antique, and they don't transfer well. Instead, I suggest you create your output using a plain vanilla data transfer style that is human-readable, easily pasted into messages like here on the Navlist message boards or in common email, and supported by most major spreadsheets and other systems, while simultaneously skipping the un-necessary complexity of JSON. And it's also antique (but still widely supported). You've probably guessed it already. I'm talking about CSV ("comma separated values"). It's a ridiculously trivial transfer format, but it's extremely easy to work with.

An alternative if you're dead set on creating attractive formatted output: use whatever scheme you like to convert from the original JSON, and then output either images (jpg, png) or PDFs. Those can then be attachments to NavList messages preserving your formatting. I don't recommend this for most content posted in NavList messages since it creates a barrier of a sort (both for some users and for search engines), but for pure data tables like this, there's no problem.

Frank Reed