Horisontmasker og himmelgeometri

Til og med 0,36 var hver synlighetstest mot jorden i motoren én enkelt elevasjonsgrense, mask_deg: en satellitt telte når den var ved eller over ett tall, uansett retning. En gate, en kai, en fjord eller en kran blokkerer en del av himmelen og lar resten være åpen. En skyline er en elevasjonsgrense som avhenger av asimut; himmelgeometrifunksjonene gjør et sted, et tidspunkt, konstellasjoner og en skyline om til den synlige mengden, presisjonsfortynningen (DOP), geometrikovariansen, den horisontale feilellipsen, en Monte Carlo-sky og et skyplot. Utformingen er docs/design/2026-10-12-geometry-and-skyline-design.md (punkt 1 og 2).

Evidens: beslutningen om maskert synlighet (geodetiske synsvinkler, tabellmasken, den synlige mengden og dens DOP) er VALIDATED mot Orekit 12,2 og gnss_lib_py 1.0.4 i en forhåndsregistrert sammenligning, og det samme gjelder feilellipsen og kofaktoren per system (numpy, forhåndsregistrert); reduksjonene for kanjon, sektor og terreng, forhåndsinnstillingene og resten av himmelgeometrifunksjonene er MODELLED (Evidens). En skyline fjerner satellitter med fri sikt og ingenting mer. Forhåndsinnstillingene er REPRESENTATIVE geometrier, ikke oppmålinger.

Skylinen#

En skyline er det punktvise maksimum av fire beskrivelser. Asimut er grader med klokken fra sann nord i stedets lokale øst-nord-opp-system; elevasjoner er i [0, 90).

preset = "<name>" starter fra en navngitt geometri; kanjonfeltene overstyrer deretter preset-ens kanjon felt for felt, og table, sectors og terrain legges til den.

Mottakerens mask_deg beholder sin betydning: den er en flat skyline. Den effektive grensen ved asimut az er max(mask_deg, skyline(az)), og en satellitt er synlig når elevasjonen er ved eller over den: den samme >= som den flate masken alltid brukte. En satellitt over mask_deg men under skylinen er maskert av skylinen.

Bygaten#

En gate går langs asimut s, w meter mellom veggene, med antennen a meter oppe på midtlinjen. Langs asimut az, med θ = az − s, når strålen en vegg etter d(az) = (w/2) / |sin θ|, så en vegg med høyde h skjærer ved

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

Den åpne stripen ligger langs gaten. Med length_m = L (antennen i midten) forlater en stråle gjennom en åpen ende, og veggen skjærer ingenting, når d(az) · |cos θ| > L/2. En vegg som ikke er høyere enn antennen skjærer ingenting. antenna_m er som standard 1,5 m (et biltak eller en håndholdt mottaker, et oppgitt valg); en ny kanjon trenger width_m.

Forhåndsinnstillinger#

Valgte og oppgitte dimensjoner (fra utformingsnotatet), ikke oppmålinger av noe reelt sted. kshana skyline --preset <name> skriver ut én med proveniensen og grensen for hver grad.

I et scenario#

En valgfri seksjon [skyline], som gjelder foran kind-ens egen grense:

Bakkestedet for orbit og integrity. Begge kind-ene modellerer en bruker i bane med geosentrisk elevasjon og uten jordfast asimut, så de tar en skyline bare med utformingsnotatets bakkestedsmodus: user_site = { lat_deg, lon_deg, height_m } i stedet for user (nøyaktig én av de to). Hvert sample er ett absolutt tidspunkt, epoch + t: hver satellitt propageres til det (et elementsett, en kringkastet efemeride eller en SP3-fil føres frem fra sin egen epoke, en Walker-satellitt teller t fra epoch) og roteres til jordfast ved det, slik at stedet ser én konsistent himmel. epoch er orbit-scenarioets egen; uten en (og alltid for integrity, som ikke har noen) er det den nyeste epoken blant satellittene som har en, eller J2000 bare for Walker-mønstre. Elevasjon og asimut er geodetiske (WGS-84). Fordelingen mellom horisontal og vertikal for ARAIM-beskyttelsesnivåene og Stanford-vertikalfeilen i integritetskind-en bruker den samme geodetiske opp-retningen (WGS-84-ellipsoidens normal, omtrent 0,19° fra den geosentriske radialen ved 45° bredde); øyeblikksbilde-RAIM brukte den allerede. Et user_site uten skyline er en vanlig bakkebruker; banestien user i bane er uendret.

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

[skyline]
preset = "harbour-approach"

Bakoverkompatibilitet. Uten en seksjon [skyline] er et scenario byte-identisk med det samme motoren ga før skylinekoden fantes: tests/skyline_scenarios.rs kontrollerer JSON, diagram og sammendrag for hvert medfølgende scenario som kjører en av disse kind-ene, og NMEA-teksten for hvert treningsscenario, mot SHA-256-sammendrag av grunnlinjen «0,36 portable» (sammendragene fra utgivelsescommiten for 0.35.0, rebasert da motoren gikk over til portabel matematikk og beholdt i testen som protokoll: docs/revisions/STUDIO15-portable-math-rebaseline.md). En tom seksjon [skyline] skjærer ingenting; resultatet er da lik kjøringen uten den, bortsett fra den tillagte blokken skyline og de nullstilte tellingene for masked_by_skyline.

Hva som avvises, med begrunnelsen i meldingen: en skyline på en user i bane; user og user_site sammen; en ukjent preset; en kanjon uten width_m; en tabell som ikke er strengt økende i [0, 360); en elevasjon utenfor [0, 90); en tom sektor; en ikke-positiv terrengavstand; inndata over grensene; enhver ukjent nøkkel.

Resultatet får skyline: { source, open_fraction, provenance } når seksjonen er til stede: source er preset:<name>, preset:<name>+overrides eller custom; open_fraction er andelen av den øvre halvkulens romvinkel over max(mask_deg, skyline) (gjennomsnittet av 1 − sin(cut) over asimut: 1 for en nullmaske, 0,5 for en flat grense på 30°); provenance er preset-ens linje eller scenarioets egen. Enheter og proveniensklasser står i blokken units.

Medfølgende eksempler (kshana example <name>):

Himmelgeometri#

Fem motorfunksjoner (src/geometry.rs), de samme på alle flater:

En forespørsel:

{
  "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 er motorens konstellasjonspreset-er (constellation-designs gps-baseline, galileo, beidou-meo, glonass, ...; LEO-preset-ene xona-pulsar, iridium-stl, ...) eller en full leo-pvt-tabell [[system]], propagert til time_s (Kepler med sekulær J2, banene i fellesmodusen leo-pvt). Deres relative faser kommer fra ulike referanseepoker, så himmelen er en representativ geometri, ikke himmelen på den datoen på det stedet. Satellitter kan i stedet (eller i tillegg) gis direkte: "satellites": [{"id": "G05", "system": "GPS", "az_deg": 120, "el_deg": 35}, ...], eller med "ecef_m": [x, y, z] og et site eller user_ecef_m. Standardverdier: hvert systems egen maske (5° for GNSS, 10° for LEO; 5° for satellitter gitt direkte), én mottakerklokke per system ("common" for én felles klokke), σ_UERE 1 m (en representativ budsjettlinje for to frekvenser), konfidensnivå 0,95. Grenser for inndata: høyst 2000 satellitter over horisonten (en systemtabell som ber om flere avvises før den bygges) og 16 mottakerklokker.

En datert himmel fra elementsett. "tle" tar tekst med to-linjers elementsett (en navnelinje før hvert sett er valgfri; høyst 4 MiB, en grense for inndata), propagert av motorens SGP4 (WGS-72, propagatoren orbit-real-tle bruker) til "epoch" pluss time_s, rotert til jordfast med UT1 satt lik UTC og uten polbevegelse, og sett fra site. "epoch" er UTC i ISO 8601 (2026-06-07T12:00:00Z) og daterer bare elementsettene (preset-ene har ingen dato, så en epoch uten tle avvises); "tle_system" merker dem for klokken per system (standard TLE). Hvert resultat sier hvilken himmel det er i sky_source og sky_statement:

En blanding forener dem med +. epoch_utc er tidspunktet elementsettene ble propagert til, og tle_skipped navngir hva av teksten som ikke ble brukt, med begrunnelse: misdannede eller foreldreløse elementsettlinjer (med linjenumre), sett parseren avviste, og sett SGP4 ikke kunne propagere til det tidspunktet (forfalt, eller utenfor sine grenser); høyst 100 oppføringer til sammen, deretter én siste oppføring som teller resten. En tom systems-liste legger ikke til noen preset-er. Skyplottet oppgir grunnlaget i bunnteksten.

Én kjerne. Kofaktormatrisen er orbit::cofactor_from_los, oppbyggingen av designmatrisen og Gauss-Jordan-inversen bak orbit::dop. orbit::dop_cov eksponerer kovariansen og orbit::dop er reduksjonen av den, så de VALIDATED skalarene er uendret og fortsatt festet av tests/dop_reference.rs. Det finnes ingen andre DOP-implementasjon.

Ellipsen. Halvakser k σ √λ for egenverdiene λ til øst-nord-blokken, med k = √(−2 ln(1 − p)) (√5.991 = 2.448 ved 95 %, 1 ved 39,35 %), og hovedaksens asimut ½ atan2(2 Q_EN, Q_NN − Q_EE) i [0, 180) fra nord.

Hvert resultat bærer label (MODELLED), statement (geometri under en oppgitt feilmodell: uavhengige, like gaussiske avstandsfeil med null forventning; ikke en prediksjon av en mottakers reelle feil, som også har biaser, flerveisutbredelse og feil uten fri sikt; ikke en integritetsgrense) og den veiledende merknaden: Veiledende programvare, ikke typegodkjent navigasjonsutstyr (IEC 61108, IEC 61162): operatøren er fortsatt ansvarlig for fartøyets navigasjon.

Evidens#

Fem registerrader (docs/VERIFICATION-MATRIX.md), slik utformingsnotatet avgrenser dem:

At en seksjon [skyline] mangler, kontrolleres byte for byte mot utdataene fra 0.35.0, noe som viser bakoverkompatibilitet og validerer ingenting. gnss_lib_py bruker bare én enkelt elevasjonsmaske, så den er DOP-referansen her, ikke maskereferansen.

Hva en skyline ikke modellerer: diffraksjon over en veggkant, refleksjoner og signaler uten fri sikt som en reell mottaker fortsatt kan spore (de forkastes, ikke degraderes), delvis gjennomsiktighet (en gitterkran er ugjennomsiktig over hele sektoren sin), terreng utenfor de oppgitte punktene, og jordens krumning inne i kanjon- og sektorformene.