Coordinates and lunar context#
Coordinates have semantics beyond two numbers. A lunar location needs a target body, latitude convention, longitude direction/domain, and any established reference-frame basis. Numerical coincidence does not establish that two coordinates are in the same frame.
The Lab’s user-defined reference#
The Lab accepts a user-defined planetocentric latitude and normalizes east-positive longitude into the half-open interval \([0,360)\). A negative east longitude is wrapped, not reinterpreted as a different physical point:
This normalization changes only the longitude representation. It does not transform latitude type or establish an unknown reference frame.
The interactive renderer uses a sphere of radius 1,737,400 m. A click is converted through that sphere to a query coordinate. The radius is a renderer convention for global context, not a measured terrain surface or a geolocation accuracy claim.
The input avoids the exact poles for the initial query grammar. Do not infer polar precision from the globe’s appearance.
The historical anchor remains separate#
The retained Chang’e 6 anchor records approximately \(41.6385^\circ\) S, \(206.0148^\circ\) E and the supplied event time. Its admitted latitude/reference-frame semantics are not established. The historical workbench preserves that boundary.
The Lab’s starter near \(42^\circ\) S, \(206^\circ\) E is instead a new user-editable research reference. It is not a higher-precision replacement for the historical anchor. Using the same event name or nearby numbers does not merge those evidence bases.
Query geometry#
Point intersection#
The existing Python query profile uses a symmetric \(10^{-6}\)-degree half-width and ODE intersection mode. This is a bounded source-query convention; it is not a claim about positional accuracy or a literal zero-area mathematical point.
Surrounding box#
The Lab can also request products intersecting a surrounding latitude/longitude rectangle. Its half-width is an angular input between 0.005 and 2 degrees. Latitude bounds are clipped at the poles. A box that crosses longitude zero is split into two source requests.
Segment counts can overlap. The Lab therefore does not claim a reconciled unique union total simply by adding those counts.
A box is not a circle and is not labelled with a kilometre radius. The existing Python compiler supports point events; the export bridge refuses to silently turn a box retrieval into a point compilation.
Basemap provenance and limits#
The initial renderer uses the repository-custodied NASA SVS CGI Moon Kit LROC-derived texture. NASA describes its longitude/latitude arrangement and explicitly notes that the color texture is optimized for visualization rather than scientific use. See the primary source in Primary sources and related tools.
The renderer does not add terrain, current solar illumination, or a registration transform. Source-provided observation outlines are contextual geometry; the UI does not claim their exact co-registration to the aesthetic texture.
A visibly precise outline cannot strengthen an unestablished geospatial relationship. Use external calibrated planetary processing when the task requires measurement or pixel-to-ground registration.
A useful interpretation checklist#
Before using a spatial result scientifically, ask:
Is this a user reference, a source center, a footprint, or a independently localized event?
Which latitude/longitude convention does it use?
Is the reference frame established, or merely unspecified?
Is the displayed background a contextual texture, a map product, or a registered raster?
Does the operation require a transform that has actually been retained?
Unknown answers should remain explicit, not disappear behind a successful 3D render.