Doc: Clarify usage of WGS-72 vs WGS-84

[scottshambaugh]

A suggestion for the docs, I was confused on for a while on usage of WGS-72 vs WGS-84.

In the skyfield docs on https://rhodesmill.org/skyfield/earth-satellites.html, there are several examples of using the WGS-84 model for determining subpoints, and there is an example (https://rhodesmill.org/skyfield/earth-satellites.html#build-a-satellite-with-a-specific-gravity-model) of building satellites from custom orbital elements using a WGS-84 frame. But then later it's listed that the default in sgp4lib was WGS-72, and I was confused on why a I would want to use an older, less accurate model.

Adding to the confusion is that the ODM spec doesn't list WGS-72 anywhere, so it seemed to me that WGS-84 would be what best matches Celestrak OMMs.

Vallado's revisiting spacktrack report #3 doesn't really help un-muddy the waters:

Kaya et al. (2001, 2004) focuses on the difficulties encountered when mixing WGS-72 and WGS-84 constants. Because the SGP4 codes contain references to WGS-72, AFSPC may have updated the constants to WGS-84, but there is no other documentation supporting this so we present the development in case new official documentation is released. However, because many operational sites may still have embedded software containing a version of SGP4 using WGS-72, and the fact that the accuracy of the theory would not really be impacted, AFSPC may well have chosen to retain the older set of constants to better maintain interoperability with its internal resources. We use WGS72 as the default value. As with other changes we discuss, this is only necessary to interface with external programs, but it will cause a difference in ephemeris results.

But in the sgp4 docs there is this helpful explanation:

Gravity
The SGP4 algorithm operates atop a set of constants specifying how strong the Earth’s gravity is. The most recent official paper on SGP4 (see below) specifies that “We use WGS-72 as the default value”, so this Python module uses the same default. But in case you want to use either the old legacy version of the WGS-72 constants, or else the non-standard but more modern WGS-84 constants, the twoline2rv() constructor takes an optional argument:

>>> from sgp4.api import WGS72OLD, WGS72, WGS84
>>> satellite3 = Satrec.twoline2rv(s, t, WGS84)
You will in general get less accurate results if you choose WGS-84. Even though it reflects more recent and accurate measures of the Earth, satellite TLEs across the industry are most likely generated with WGS-72 as their basis. The positions you generate will better agree with the real positions of each satellite if you use the same underlying gravity constants as were used to generate the TLE.

I think a similar explanation would be useful in the skyfield docs. My impression now is that this is how they should generally be used:

• TLEs/OMMs from Space-Track, Celestrak and most other sources are generated with sgp4 using WGS-72 as their basis, which is why that is the default in sgp4lib. When propagating orbits based on these data sources, it will therefor give more accurate positioning results than using WGS-84.
• When generating & referencing all other positions, WGS-84 will give more accurate positioning.
• Distances & angles within a coordinate frame are independent of the datum/gravity model, so there is no need to worry about interoperability when calculating relative positions between objects.

Is that accurate?