NavList:

By the way, the web app in question can be coded using the "querystring" in the URL. In many web addresses, especially those on websites with older designs, data is passed to the server by attaching a bunch of cryptic codes to the main URL. It's ugly (and creates suspicion among many web users), but it can be fun. Querystrings start with a question mark, "?", and then additional paramaters are separated by ampersands, "&". The USNO "celnavtable.php" app creates querystrings like this, and we can modify the inputs directly on the results page without going back to this input page.

If you launch the standard USNO web app with default parameters, you'll be directed to the results page showing the GHA, Dec, etc. for all bodies visible above the horizon, or just below it in the case of the Sun. The URL for that result page is:
http://aa.usno.navy.mil/cgi-bin/aa_flamenav.pl
?ID=AA
&calc=7
&qq1=2018
&qq2=9
&qq3=22
&qq4=0
&qq5=0
&qq6=0
&qqo=all
&yy0=1
&yy1=40
&yy2=00.0
&xx0=-1
&xx1=60
&xx2=00.0
&ZZZ=END

Here I have given each of the parameters in the querystring its own line, but in the address bar of your web browser they're all glued together in one long string. First things first, at least two of these parameters are un-necessary. The "ID" parameter can be dropped, but if you use the service extensively, USNO AA (the Astronomical Applications dept.) requests that you include a tag there identifying yourself for their auditing purposes. For example, I might use "ID=ClockworkMapping". But it's not necessary. Also, the parameter "ZZZ=END" was always bizarre (probably a misunderstanding on the part of the original programmer of the web app back in the late 1990s), and whoever is maintaining the code finally dropped the processing for it, so it is not required at all. The arbitrary parameter "calc=7" is required but apparently serves no purpose. It was probably used during early debugging of the service.

The parameters qq1 through qq6 provide the UT in the order year, month, day, hours, minutes, seconds. There's some weird error-checking on these parameters. For example, you can bump up the date by increasing the day value by 1. So if you have "&qq0=2018&qq1=9&qq2=22" you'll get data for today and if you change qq2 to 23, you'll get data for tomorrow. But if you change qq2 to 43, you'll get data for the correct date in October as if it's the 43rd day of September (displayed correctly though). In fact, you can enter any date value up to 99. So rather than tossing out invalid values for the number of days in a specific month, the app limits dates to two digits (why bother? either have proper range checking or no range checking). This can be useful if you want to look at the next ten days of data, as in my example below, and don't want to think about month boundaries. The range-checking on the month numbers seems to fail. You can enter unusual values and get inconsistent results. So don't do that! :)

The next parameter, qqo, determines the list of bodies that will be displayed. Note that this is "qqo" with a lower case letter  "O", not qq0 (with the digit zero). The standard choice is "qqo=all". There are lots of games you can play here, but the most useful is that you can identify any celestial object by the first three letters and get data specific to that body. This choice also over-rules the horizon limits. This is especially useful for the Sun. To see data for the Sun only, just edit "qqo=all" to read "qqo=sun" (and then hit enter to refresh the page). You can get data for Jupiter by setting qqo to "jup". You can also find quite a few unlisted bodies. Set "qqo=mer" and you have "official" USNO ephemeris data for the planet Mercury whenever you want it

The parameters yy0, yy1, yy2 provide the sign, +1 for N, -1 for S, of the observer's latitude, the degrees, and the minutes of the latitude, respectively. Unfortunately, the range checking on these fields is strict. It would be nice to be able to enter a decimal value for yy1, the observer's latitude in degrees, for example 41.5, leaving the minutes at zero, but the system prohibits that. The parameters xx0, xx1, xx2 similarly provide the longitude. The sign for positive longitude follows the twenty-first century standard convention, which contradicts usual celestial navigation practice: +1 for E, -1 for W.

Any of these parameters can be edited manually or in automated code which repeatedly calls the USNO web app. Many options can be accessed by coding the querystring directly. Note that frequent hits in a short period of time may get you tagged as a malicious visitor to the site so you'll need to throttle automated hits on the site appropriately. Once per second seems to cause no problems. By the way, order does not count in the querystring of any URL. You can move things around.

Let's say you want to get GHA and Dec for the planet Mercury for 5 days beginning on Sep.28, 2018 at 0h UT each day (near noon in the eastern US). You would start with the standard base: http://aa.usno.navy.mil/cgi-bin/aa_flamenav.pl?calc=7 and you would append the other querystring parameters as described above. 

Since we're only looking for GHA and Dec, we can drop the xx*, yy* parameters for longitude, latitude and they will default to the standard 40N, 60W values.

We set qqo to Mercury and then fill in the values for the initial date:
&qqo=mer&qq1=2018&qq2=9&qq3=28.
Note that the time parameters qq4,qq5,qq6 will default to zero. Attach this string immediately after the "calc=7" arbitrary parameter in the base URL:
http://aa.usno.navy.mil/cgi-bin/aa_flamenav.pl?calc=7&qqo=mer&qq1=2018&qq2=9&qq3=28.

And then to get five days of data, we can just increment the value of qq3 (as long as it doesn't exceed 99, we can ignore month boundaries):
http://aa.usno ... &qq3=28
http://aa.usno ... &qq3=29
http://aa.usno ... &qq3=30
http://aa.usno ... &qq3=31
http://aa.usno ... &qq3=32

Frank Reed

PS: And just to reiterate from my last post, you can trust the GHA, Dec, Hc, and Zn, from this web app, but you should treat the altitude corrections as examples. They are not definitive, and in some real-world cases they are emphatically incorrect.