Resolved FIXFIXFIX comments regarding whether or not to
correct for aberration. In all cases, the observations are
made from the Earth, in which case it makes the most sense
to correct for aberration.
I was using "relative longitude" to mean two different things.
Resolved the ambiguity by using relative longitude only for
differences in eclitpic longitude as seen from the Sun.
Use "ecliptic separation" for differences in ecliptic longitude
as measured from the Earth.
Fixed completely wrong documentation in the JavaScript code;
it had the meanings backwards inside the ElongationEvent class.
I'm not sure exactly whether it is Windows versus Linux,
or just different versions of doxygen, but on my Windows laptop
I was getting messed up doxygen output. It turns out that everything
is back on track once I cleaned up all the trailing whitespace in
template/astronomy.c. I will need to automate this in the future.
The following functions had parameters that accepted cryptic numeric values:
Astronomy_GeoVector
Astronomy_Equator
Astronomy_SearchRiseSet
Replaced such parameters with enumerations. Added the following enumerated types:
astro_aberration_t
astro_direction_t
astro_equator_date_t
Added more C documentation.
I don't want to mix performance information with results.
If I need performance information later, I can do it through
a side channel. Renamed SearchErr to SearchError, to be consistent
with the other functions that generate error structs.
Certain macros and typedefs were ending up in Doxygen output
that have no reason to be documented for outside users.
Mostly I used Doxygen conditionals to hide them.
In a couple of cases I had some internal functions that needed
to be declared static so Doxygen hides them.
Added DoxygenLayout.xml, but not using it yet.
Still trying to figure out how to make Markdown output
that doesn't look terrible. Not sure I can get Moxygen
to do what I want. I may have to create my own simple(?) tool.
These functions allow generating a Gregorian calendar date and time
in UTC from an astro_time_t, and vice versa.
This filled in a gap where we needed a way to transform an astronomy
time value into something a user would recognize.
I may have to revisit this later for compatibility with the <time.h>
standard library, etc.
I made sure it is not possible to get stuck in an infinite
loop inside SearchLunarApsis, both the C and JavaScript versions.
If we loop over more time than 2 synodic months (more than enough time),
bail out with an exception (JS) or an internal error (C).
Astronomy_Ecliptic was using midnight on 2000-01-01 as the epoch,
but it should have been using noon. Fixed it. Discovered because
there was a tiny but larger than expected error in calculating
the tilt of Saturn's rings.
