[ac1982]

The satellite guide uses WGS84 for geographic positions and later shows selecting SGP4 gravity constants, which can make the default WGS72 propagation look inconsistent (#1039).

Explain that these are separate choices: SGP4's gravity constants should match the orbital elements, while wgs84.latlon() and wgs84.subpoint_of() describe geographic coordinates without changing the satellite's gravity model. Keep the existing explicit gravity-model override example and link to SGP4's explanation.

Validation on Python 3.12/Linux arm64:

• Public API checks with scalar and array times confirm the default matches explicit WGS72, geographic conversions leave propagation unchanged, and explicit WGS84 gravity changes the propagated position.
• HTML builds successfully with the same 42 warnings as the unchanged base.
• Full code suite: 584 pass, 2 fail identically on base and branch (integer casting and an arm64 numerical tolerance). Full documentation tests have 5 identical failure blocks on both, including NumPy scalar representations. These suites are not fully green in this environment.

Documentation only. AI-assisted contribution, investigated and validated with Codex.

[brandon-rhodes]

Yes, that is an interesting source of possible confusion! I will plan, before the next release, to either adopt the language here in this PR, or else to write a couple of sentences of my own on that page of documentation (sometimes the concepts make more sense to me if I explain them a bit differently, which then makes the words easier for me to maintain in the future).

Hopefully any confusion that you yourself ran into about the difference between the WGS84 ellipsoid and the WGS84 gravity model didn't delay your project for very long!