LunaMap · Lunar Landing Site Navigator
← Back to the instrument

Method and limits

What this measures

LunaMap reports when the centre of the Sun or the Earth is above the geometric horizon at a point on the lunar surface: the horizon of a smooth sphere of radius 1,737.4 km, with nothing on it.

Everything else on this page is a consequence of that sentence.

Where the figures come from

Sun and Earth azimuth and elevation are queried from NASA/JPL Horizons for each site as a topocentric observer fixed to the lunar surface — CENTER=coord@301, geodetic site coordinates, airless apparent elevation, in the Moon's body-fixed frame with east longitude positive. Libration and orbital variation are inherent in that frame rather than added afterwards.

Read from each period's dataset
Period Range, UTC Cadence Samples per series Elevations cross-checked Worst disagreement
Reading the datasets…

Visibility windows are computed by interpolating the horizon crossing between samples, so a window's start and end are generally not sample timestamps. A window that touches the edge of the comparison period is flagged as continuing outside it, and the interface then declines to show a countdown rather than printing a number that would be a lower bound presented as a fact.

Values are stored at full precision and rounded once, at display.

For the mission windows that ship with LunaMap, the raw Horizons responses are in the repository, each beside the exact query parameters and retrieval time that produced it. A window generated on request is built by the same script from the same queries, and nothing is shown for it until it has passed the same cross-check; its raw responses are kept with the analysis on the server rather than in the repository. Either way, any number on screen traces to one of those files.

How it is checked

Every elevation is recomputed by a second, independent path: from the sub-solar and sub-Earth point series and spherical geometry, using none of Horizons' topocentric output as input.

—

Against a display precision of 0.01°.

That residual is not zero, and it is not agreement. The second path models the Moon as a sphere of fixed radius and ignores light-time, so a few thousandths of a degree is the check's own error. Both paths read the same ephemeris, so this verifies the observer convention and the derived geometry — not the ephemeris itself. No verification against an independent ephemeris has been performed.

The globe's lighting is a third use of the same data: the surface is lit from the sub-solar point by spherical geometry, which is a separate calculation from Horizons' topocentric elevations. They agree because they share an ephemeris, to within the residual above. A marker reads its lit state from the number its own readout shows, so the two cannot disagree on screen.

What this does not tell you

Terrain is not modelled.
The real horizon at these sites is made by terrain at every distance, from the slope a lander stands on to ridges and crater rims far away. Relief can hide a body this model calls visible, and high ground can reveal one it calls hidden. The Sun stays low over every period, so a few hundred metres of relief can matter more than the ephemeris does. The terrain images are shown for exactly this reason — so the limitation is visible rather than taken on trust — and they do not enter any calculation.
A separate terrain-aware proof of concept found that, at MMA01 over the 20 Nov–21 Dec 2025 window, Sun visibility changed from the total this page's dataset gives under the ideal geometric-horizon model to 14.2 days when local terrain was included. This experiment is not part of the shipped analysis and reinforces that LunaMap's current visibility metrics are first-pass geometric screening results.
Compare can show an experimental terrain-aware model beside the geometric figures: the same elevations tested against a terrain horizon traced through the LOLA south-polar elevation model, at the four analysis sites. It is not validated. A second, independent implementation reproduces its figures, but some of them move by a day or more when the site is moved 100 m and are marked position-sensitive, and two differ from a published record for reasons not yet established. Rankings, key moments, the key contrast, Geometry and Mission Brief use the geometric model only.
The Earth passing in front of the Sun is not modelled.
Seen from the Moon, a lunar eclipse is the Earth covering the Sun. Both models test only whether the Sun's centre is above the horizon. In the 20 Feb–21 Mar 2026 window, on 3 March 2026, the Earth covers part or all of the Sun for about four hours at all four sites, and the geometric model counts that time as Sun visibility. It is the same at every site, so no comparison between sites changes.
Sun visibility is not illumination or electrical power.
It says only that the Sun's centre is above the ideal geometric horizon: an opportunity for illumination, not sunlight on the ground, and not electrical output. Above the horizon at these latitudes the Sun is mostly within a few degrees of it, where cosine losses make any power figure a stretch.
Earth visibility is not a communications link.
It is a proxy for potential direct-to-Earth opportunity. A real link needs a ground station, a viable budget, and terrain that does not intervene.
A difference smaller than our own verification error is not reported as a difference.
The two calculation paths disagree by up to the worst residual shown above, so a contrast finer than that is declined — not because it looks unconvincing, but because we cannot support the claim. Each dataset carries its own measured floor and the interface reads it from there.
It does not tell you where to land.
Whether a site is better depends on whether a mission is constrained by power or by communications, and on a great deal this model does not contain. LunaMap makes the trade visible. It does not resolve it.

Three kinds of place on the map, and what each one carries

The map shows places of three different standings, and they are never blurred into one word.

Analysis sites.
The four with computed, cross-checked Sun and Earth series. Only these carry visibility figures, only these are ranked, and only these can enter a comparison.
Reference places.
Named lunar features whose coordinates come from the IAU/USGS Gazetteer, shown so the four sit in their real surroundings. They carry a name, a kind and a citation, and the coordinate given is the centre of the named feature rather than a landing point. They have no Sun or Earth figure and they take no rank.
User-provided sites.
Points imported from a file by whoever is using the page. They are location only. No Sun or Earth analysis is generated for an imported coordinate: computing one would mean querying the ephemeris and cross-checking it, which is the pipeline, not the interface. So an imported point shows Analysis not generated, carries no citation, takes no rank, and cannot be added to a comparison. Its coordinates are recorded as given and are not checked against anything — a row whose latitude is missing, non-numeric, or outside −90 to 90 is refused by name rather than placed somewhere approximate.

What the scenario export contains

The export writes the current state to a file: the mission window, the chosen priority and the ranking it produced, the cursor time, the selected sites with their figures, the period notes, the key moments, and any user-provided points marked as such.

It also writes the identity of the dataset — file, source, frame, cadence, sample count, crossing method, the generated timestamp, and the measured contrast floor — and the limitations, in full, as text.

That last part is the point rather than a formality. A figure on this page sits under a footer saying what it is not; the same figure in a file does not. So every metric in the export is named geometric_… with its unit, nothing the page declines to state is written to the file, and the limitations travel with the numbers rather than being left behind on the screen.

Data sources

NASA/JPL Horizons
Every quantitative figure, and the sub-solar, sub-Earth and sub-lunar point series.
NASA Moon Trek
Shaded relief at each site: layer LRO_LOLA_Shade_Global_256ppd_v06, a hillshade of the global LRO LOLA elevation model at 256 pixels per degree. Captured at build time rather than embedded, so the picture explaining this model's main limitation does not depend on a live service. Context only.
LRO LOLA
The Lunar Orbiter Laser Altimeter, whose global elevation model that hillshade is drawn from. The validated geometric analysis uses LOLA only as that picture; no elevation value enters any geometric figure. The relief on the south-pole view is slope shading from the LOLA gridded elevation record (LDEM_80S_80M) at 240 m: visual context, with no cast shadows, and not a statement about what a site can see.
LOLA south-polar DEM, Barker et al. (2023)
Not used by the validated geometric analysis. Read by the experimental terrain-aware model shown in Compare and by the proof of concept quoted under “Terrain is not modelled”.
NASA SVS CGI Moon Kit
The Moon's colour map. Visual only.
NASA GIBS Blue Marble
The Earth's colour map. Visual only.
Wueller et al. (2026), Table A1
Site coordinates. Their visibility figures are terrain-aware and use a different metric and time step, so they are not comparable with these and are not presented as validation.
NASA — Artemis III site selection downselect, thirteen regions to nine
The source for which south-polar regions NASA shortlisted and on what criteria. Four of those nine regions contain the four sites analysed here, and the study names Earth visibility and seasonal illumination among its own concerns. Cited for site selection; no figure derives from it.
IAU/USGS Gazetteer of Planetary Nomenclature
Official feature centres and bounding boxes, used to check that each site coordinate falls inside the IAU bounds of the feature it is named for. All four do. Enters no visibility calculation. It is also the source of the coordinates of the context places on the map, each of which is a feature centre and not a landing point.

No Space Agency Partner data is used.

Reproduce it

python3 scripts/build_dataset.py
python3 scripts/crosscheck_dataset.py
python3 scripts/verify_reproducible.py data/comparison.json data/rebuild.json

The third compares two builds field by field and exits non-zero on the first difference. It compares values rather than hashing, because the claim is value equality and two builds may format a float differently while agreeing on every number.