Masques d'horizon et géométrie du ciel

Jusqu'à la 0,36, chaque test de visibilité terrestre du moteur reposait sur un seul seuil d'élévation, mask_deg : un satellite comptait dès qu'il était à ce nombre ou au-dessus, quelle que soit sa direction. Une rue, un quai, un fjord ou une grue bloque une partie du ciel et laisse le reste dégagé. Une ligne d'horizon (skyline) est une coupure d'élévation qui dépend de l'azimut ; les fonctions de géométrie du ciel transforment un site, un instant, des constellations et une ligne d'horizon en ensemble visible, dilution de précision (DOP), covariance géométrique, ellipse d'erreur horizontale, nuage Monte Carlo et diagramme du ciel (skyplot). La conception est décrite dans docs/design/2026-10-12-geometry-and-skyline-design.md (points 1 et 2).

Preuves : la décision de visibilité masquée (angles de visée géodésiques, masque tabulé, ensemble visible et son DOP) est VALIDATED par rapport à Orekit 12,2 et à gnss_lib_py 1.0.4 dans une comparaison préenregistrée, de même que l'ellipse d'erreur et le cofacteur par système (numpy, préenregistré) ; les réductions de canyon, de secteur et de relief, les préréglages et le reste des fonctions de géométrie du ciel sont MODELLED (Preuves). Une ligne d'horizon retire les satellites en ligne de visée directe, et rien de plus. Les préréglages sont des géométries REPRESENTATIVE, et non des relevés.

La ligne d'horizon#

Une ligne d'horizon est le maximum point par point de quatre descriptions. L'azimut est exprimé en degrés dans le sens horaire à partir du nord vrai, dans le repère local est-nord-haut du site ; les élévations sont dans [0, 90).

preset = "<name>" part d'une géométrie nommée ; les champs du canyon remplacent alors, champ par champ, le canyon du préréglage, et table, sectors et terrain s'y ajoutent.

Le mask_deg du récepteur garde son sens : c'est une ligne d'horizon plate. La coupure effective à l'azimut az est max(mask_deg, skyline(az)), et un satellite est visible lorsque son élévation est égale ou supérieure à celle-ci : le même >= que celui qu'utilisait toujours le masque plat. Un satellite au-dessus de mask_deg mais sous la ligne d'horizon est masqué par la ligne d'horizon.

Le canyon urbain#

Une rue court selon l'azimut s, large de w mètres entre les murs, l'antenne se trouvant à a mètres de hauteur sur l'axe central. Selon l'azimut az, avec θ = az − s, le rayon atteint un mur après d(az) = (w/2) / |sin θ| ; un mur de hauteur h coupe donc à

cut(az) = atan( (h − a) / d(az) )          (the right wall for sin θ > 0, the side at s + 90°)

La bande dégagée s'étend le long de la rue. Avec length_m = L (l'antenne au milieu), un rayon sort par une extrémité ouverte, et le mur ne coupe rien, lorsque d(az) · |cos θ| > L/2. Un mur pas plus haut que l'antenne ne coupe rien. antenna_m vaut par défaut 1,5 m (un toit de voiture ou un récepteur portatif, un choix déclaré) ; un nouveau canyon exige width_m.

Préréglages#

Dimensions choisies et déclarées (celles de la note de conception), et non relevés d'un lieu réel. kshana skyline --preset <name> en affiche une avec sa provenance et sa coupure à chaque degré.

Dans un scénario#

Une section [skyline] facultative, par-dessus le seuil propre au type de scénario :

Le site au sol de orbit et de integrity. Ces deux types de scénario modélisent un utilisateur en orbite avec une élévation géocentrique et sans azimut lié à la Terre ; ils n'acceptent donc une ligne d'horizon qu'avec le mode site au sol de la note de conception : user_site = { lat_deg, lon_deg, height_m } à la place de user (exactement l'un des deux). Chaque échantillon est un instant absolu, epoch + t : chaque satellite y est propagé (un jeu d'éléments, des éphémérides diffusées ou un fichier SP3 sont avancés à partir de leur propre époque, un satellite Walker compte t à partir de epoch) et mis en rotation dans le repère terrestre à cet instant, de sorte que le site voit un seul ciel cohérent. epoch est celle du scénario d'orbite ; sans elle (et toujours pour integrity, qui n'en a pas), c'est l'époque la plus récente parmi les satellites qui en portent une, ou J2000 pour les seules constellations Walker. L'élévation et l'azimut sont géodésiques (WGS-84). La séparation horizontale et verticale des niveaux de protection ARAIM du type intégrité et de l'erreur verticale de Stanford utilise le même haut géodésique (la normale à l'ellipsoïde WGS-84, à environ 0,19° de la radiale géocentrique à 45° de latitude) ; le RAIM instantané l'utilisait déjà. Un user_site sans ligne d'horizon est un simple utilisateur au sol ; le chemin user en orbite est inchangé.

kind = "integrity"
mask_deg = 5.0
# ...
[user_site]
lat_deg = 59.45
lon_deg = 24.75
height_m = 15.0

[skyline]
preset = "harbour-approach"

Rétrocompatibilité. Sans section [skyline], un scénario est identique octet pour octet à ce que le même moteur donnait avant l'existence du code de ligne d'horizon : tests/skyline_scenarios.rs vérifie le JSON, le graphique et le résumé de chaque scénario livré qui exécute un de ces types de scénario, ainsi que le texte NMEA de chaque scénario d'entraînement, par rapport aux empreintes SHA-256 de la référence « 0,36 portable » (les empreintes du commit de la version 0.35.0, rebasées lorsque le moteur est passé aux mathématiques portables et conservées dans le test à titre de trace : docs/revisions/STUDIO15-portable-math-rebaseline.md). Une section [skyline] vide ne coupe rien ; le résultat est alors égal à l'exécution sans elle, à l'exception du bloc skyline ajouté et des compteurs masked_by_skyline à zéro.

Ce qui est refusé, avec la raison dans le message : une ligne d'horizon sur un user en orbite ; user et user_site ensemble ; un préréglage inconnu ; un canyon sans width_m ; une table qui n'est pas strictement croissante dans [0, 360) ; une élévation hors de [0, 90) ; un secteur vide ; une distance de relief non positive ; une entrée dépassant les plafonds ; toute clé inconnue.

Le résultat gagne skyline: { source, open_fraction, provenance } lorsque la section est présente : source vaut preset:<name>, preset:<name>+overrides ou custom ; open_fraction est la fraction de l'angle solide de l'hémisphère supérieur au-dessus de max(mask_deg, skyline) (la moyenne de 1 − sin(cut) sur l'azimut : 1 pour un masque nul, 0,5 pour une coupure plate à 30°) ; provenance est la ligne du préréglage ou celle du scénario lui-même. Les unités et les classes de provenance figurent dans le bloc units.

Exemples fournis (kshana example <name>) :

Géométrie du ciel#

Cinq fonctions du moteur (src/geometry.rs), identiques sur toutes les surfaces :

Une requête :

{
  "site": {"lat_deg": 59.91, "lon_deg": 10.75, "height_m": 5},
  "time_s": 3600,
  "systems": ["gps-baseline", "galileo", "beidou-meo", "xona-pulsar"],
  "mask_deg": 5,
  "skyline": {"preset": "fjord"},
  "clock": "per-system",
  "sigma_uere_m": 1.5,
  "confidence": 0.95
}

systems sont les préréglages de constellation du moteur (gps-baseline, galileo, beidou-meo, glonass, ... de constellation-design ; les préréglages LEO xona-pulsar, iridium-stl, ...) ou une table [[system]] complète de leo-pvt, propagée jusqu'à time_s (képlérienne avec J2 séculaire, les orbites en mode conjoint de leo-pvt). Leurs phases relatives proviennent d'époques de référence différentes ; le ciel est donc une géométrie représentative, et non le ciel de cette date à cet endroit. Les satellites peuvent aussi (ou en plus) être donnés directement : "satellites": [{"id": "G05", "system": "GPS", "az_deg": 120, "el_deg": 35}, ...], ou avec "ecef_m": [x, y, z] et un site ou user_ecef_m. Valeurs par défaut : le masque propre à chaque système (5° GNSS, 10° LEO ; 5° pour les satellites donnés directement), une horloge de récepteur par système ("common" pour une seule horloge partagée), σ_UERE de 1 m (une ligne de budget bifréquence représentative), confiance de 0,95. Plafonds d'entrée : 2000 satellites au plus au-dessus de l'horizon (une table de système qui en demande davantage est refusée avant d'être construite) et 16 horloges de récepteur.

Un ciel daté à partir de jeux d'éléments. "tle" accepte du texte de jeux d'éléments à deux lignes (une ligne de nom avant chaque jeu est facultative ; 4 MiB au plus, un plafond d'entrée), propagé par le SGP4 du moteur (WGS-72, le propagateur qu'utilise orbit-real-tle) jusqu'à "epoch" plus time_s, mis en rotation dans le repère terrestre avec UT1 pris égal à UTC et sans mouvement du pôle, et vu depuis site. "epoch" est en UTC ISO 8601 (2026-06-07T12:00:00Z) et ne date que les jeux d'éléments (les préréglages ne portent aucune date : un epoch sans tle est donc refusé) ; "tle_system" les étiquette pour l'horloge par système (par défaut TLE). Chaque résultat indique de quel ciel il s'agit dans sky_source et sky_statement :

Un mélange les réunit avec +. epoch_utc est l'instant jusqu'auquel les jeux d'éléments ont été propagés, et tle_skipped nomme la partie du texte qui n'a pas été utilisée, avec la raison : lignes de jeux d'éléments mal formées ou orphelines (avec leurs numéros de ligne), jeux que l'analyseur a refusés, et jeux que SGP4 n'a pas pu propager jusqu'à cet instant (en rentrée atmosphérique, ou au-delà de ses limites) ; 100 entrées au plus en tout, puis une dernière entrée qui compte le reste. Une liste systems vide n'ajoute aucun préréglage. Le diagramme du ciel indique la base dans son pied de page.

Un seul noyau. La matrice de cofacteurs est orbit::cofactor_from_los, l'assemblage de la matrice de conception et l'inverse de Gauss-Jordan derrière orbit::dop. orbit::dop_cov expose la covariance et orbit::dop en est la réduction ; les scalaires VALIDATED sont donc inchangés et toujours figés par tests/dop_reference.rs. Il n'existe pas de seconde implémentation du DOP.

L'ellipse. Demi-axes k σ √λ pour les valeurs propres λ du bloc est-nord, avec k = √(−2 ln(1 − p)) (√5.991 = 2.448 à 95 %, 1 à 39,35 %), et l'azimut ½ atan2(2 Q_EN, Q_NN − Q_EE) du grand axe dans [0, 180) à partir du nord.

Chaque résultat porte label (MODELLED), le statement (géométrie sous un modèle d'erreur déclaré : erreurs de distance gaussiennes indépendantes, égales, de moyenne nulle ; pas une prédiction de l'erreur réelle d'un récepteur, qui comporte aussi des biais, des trajets multiples et des erreurs hors ligne de visée ; pas une borne d'intégrité) et l'avis indicatif : Logiciel à titre consultatif, et non un équipement de navigation homologué (IEC 61108, IEC 61162) : l'opérateur reste responsable de la navigation du navire.

Preuves#

Cinq lignes du registre (docs/VERIFICATION-MATRIX.md), telles que la note de conception les délimite :

L'absence de section [skyline] est vérifiée octet pour octet par rapport aux sorties de la 0.35.0, ce qui démontre la rétrocompatibilité et ne valide rien. gnss_lib_py n'applique qu'un seul masque d'élévation ; c'est donc la référence indépendante pour le DOP ici, et non pour le masque.

Ce qu'une ligne d'horizon ne modélise pas : la diffraction sur le bord d'un mur, les réflexions et les signaux hors ligne de visée qu'un vrai récepteur peut encore suivre (ils sont écartés, et non dégradés), la transparence partielle (une grue à treillis est opaque sur tout son secteur), le relief au-delà des points donnés, et la courbure de la Terre à l'intérieur des formes de canyon et de secteur.