Маски горизонту та геометрія неба

До 0,36 кожна перевірка видимості над Землею в рушії була єдиним порогом висоти, mask_deg: супутник враховувався, якщо перебував на цій одній висоті або вище, незалежно від напрямку. Вулиця, причал, фіорд чи кран затуляють частину неба й залишають решту відкритою. Лінія горизонту (skyline) — це поріг висоти, що залежить від азимута; функції геометрії неба перетворюють місце, час, орбітальні угруповання та лінію горизонту на видимий набір, геометричний чинник DOP (погіршення точності), коваріацію геометрії, горизонтальний еліпс похибок, хмару Монте-Карло та скайплот. Проєктний документ — docs/design/2026-10-12-geometry-and-skyline-design.md (пункти 1 і 2).

Докази: рішення щодо маскованої видимості (геодезичні кути спостереження, табличну маску, видимий набір і його DOP) VALIDATED за Orekit 12,2 і gnss_lib_py 1.0.4 у попередньо зареєстрованому порівнянні, так само й еліпс похибок та коефіцієнт для кожної системи (numpy, попередня реєстрація); зведення каньйону, секторів і рельєфу, пресети та решта функцій геометрії неба MODELLED (Докази). Лінія горизонту прибирає супутники прямої видимості й нічого більше. Пресети — це REPRESENTATIVE геометрії, а не результати зйомки місцевості.

Лінія горизонту#

Лінія горизонту — це поточкове максимум чотирьох описів. Азимут — це градуси за годинниковою стрілкою від істинної півночі в локальній системі координат «схід–північ–вгору» місця спостереження; висоти задано в [0, 90).

preset = "<name>" починає з іменованої геометрії; поля каньйону потім перевизначають поля каньйону пресета по одному, а table, sectors і terrain доповнюють його.

Параметр mask_deg приймача зберігає своє значення: це пласка лінія горизонту. Ефективний поріг на азимуті az дорівнює max(mask_deg, skyline(az)), і супутник видимий, коли його висота не менша за нього: це той самий >=, що завжди використовувала пласка маска. Супутник над mask_deg, але під лінією горизонту, замаскований лінією горизонту.

Вуличний каньйон#

Вулиця проходить уздовж азимута s, між стінами w метрів, антена на висоті a метрів на осьовій лінії. Уздовж азимута az при θ = az − s промінь досягає стіни після d(az) = (w/2) / |sin θ|, тож стіна висотою h відсікає на

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

Відкрита смуга лежить уздовж вулиці. При length_m = L (антена посередині) промінь виходить через відкритий кінець, і стіна нічого не відсікає, коли d(az) · |cos θ| > L/2. Стіна не вища за антену нічого не відсікає. antenna_m за замовчуванням дорівнює 1,5 m (дах автомобіля або переносний приймач, вибране значення); новий каньйон потребує width_m.

Пресети#

Вибрані й наведені розміри (з проєктної нотатки), а не результати зйомки жодного реального місця. kshana skyline --preset <name> виводить один із них разом із походженням і порогом на кожен градус.

У сценарії#

Необов'язковий розділ [skyline] діє поверх власного порогу відповідного типу:

Наземне місце для orbit і integrity. Обидва типи моделюють користувача на орбіті з геоцентричною висотою і без азимута в земній системі координат, тому лінію горизонту вони приймають лише в режимі наземного місця з проєктної нотатки: user_site = { lat_deg, lon_deg, height_m } замість user (рівно одне з двох). Кожен відлік — це один абсолютний момент, epoch + t: кожен супутник пропагується до нього (набір елементів, бортові ефемериди або файл SP3 просуваються від власної епохи, супутник Walker відлічує t від epoch) і повертається в земну систему координат на цей момент, тож місце бачить одне узгоджене небо. epoch — це власна епоха орбітального сценарію; без неї (і завжди для integrity, який її не має) це найновіша епоха серед супутників, що її мають, або J2000 лише для візерунків Walker. Висота й азимут геодезичні (WGS-84). Поділ на горизонтальну та вертикальну складові рівнів захисту ARAIM типу integrity і вертикальної похибки за Stanford використовує ту саму геодезичну вертикаль (нормаль до еліпсоїда WGS-84, приблизно на 0,19° від геоцентричного радіуса на широті 45°); миттєвий RAIM її вже використовував. user_site без лінії горизонту — це звичайний наземний користувач; шлях орбітального user не змінюється.

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

[skyline]
preset = "harbour-approach"

Зворотна сумісність. Без розділу [skyline] сценарій побайтово збігається з тим, що давав той самий рушій до появи коду лінії горизонту: tests/skyline_scenarios.rs перевіряє JSON, діаграму та підсумок кожного постачуваного сценарію, що запускає один із цих типів, а також текст NMEA кожного навчального сценарію за дайджестами SHA-256 базового рівня «0,36 portable» (дайджести комміту випуску 0.35.0, перебазовані, коли рушій перейшов на портативну математику, і збережені в тесті як запис: docs/revisions/STUDIO15-portable-math-rebaseline.md). Порожній розділ [skyline] нічого не відсікає; тоді результат дорівнює прогону без нього, окрім доданого блока skyline і нульових лічильників masked_by_skyline.

Що відхиляється, з причиною в повідомленні: лінія горизонту для орбітального user; user і user_site разом; невідомий пресет; каньйон без width_m; таблиця, не строго зростаюча в [0, 360); висота поза [0, 90); порожній сектор; невласна (недодатна) відстань рельєфу; вхідні дані понад обмеження; будь-який невідомий ключ.

Результат отримує skyline: { source, open_fraction, provenance }, коли розділ присутній: source дорівнює preset:<name>, preset:<name>+overrides або custom; open_fraction — це частка тілесного кута верхньої півсфери над max(mask_deg, skyline) (середнє 1 − sin(cut) за азимутом: 1 для нульової маски, 0,5 для пласкої межі 30°); provenance — це рядок пресета або власний рядок сценарію. Одиниці та класи походження наведено в блоці units.

Вбудовані приклади (kshana example <name>):

Геометрія неба#

П'ять функцій рушія (src/geometry.rs), однакових на кожній поверхні:

Запит:

{
  "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 — це пресети орбітальних угруповань рушія (constellation-design: gps-baseline, galileo, beidou-meo, glonass, ...; пресети LEO xona-pulsar, iridium-stl, ...) або повна таблиця leo-pvt [[system]], пропагована до time_s (кеплерова з віковим J2, орбіти спільного режиму leo-pvt). Їхні відносні фази походять від різних опорних епох, тож небо — це репрезентативна геометрія, а не небо тієї дати в тому місці. Супутники можна натомість (або додатково) задати безпосередньо: "satellites": [{"id": "G05", "system": "GPS", "az_deg": 120, "el_deg": 35}, ...], або з "ecef_m": [x, y, z] і site чи user_ecef_m. Типові значення: маска кожної системи (5° для GNSS, 10° для LEO; 5° для супутників, заданих безпосередньо), один годинник приймача на систему ("common" для одного спільного годинника), σ_UERE 1 m (репрезентативний рядок бюджету для двох частот), довірча ймовірність 0,95. Обмеження вхідних даних: не більше 2000 супутників над горизонтом (системна таблиця, що запитує більше, відхиляється до її побудови) і 16 годинників приймача.

Датоване небо за наборами елементів. "tle" приймає текст двострокових наборів елементів (рядок з назвою перед кожним набором необов'язковий; не більше 4 MiB, обмеження вхідних даних), пропагований SGP4 рушія (WGS-72, пропагатор, який використовує orbit-real-tle) до "epoch" плюс time_s, повернутий у земну систему координат із UT1, прийнятим за UTC, і без полярного руху, та побачений із site. "epoch" — це UTC за ISO 8601 (2026-06-07T12:00:00Z), і воно датує лише набори елементів (пресети дати не мають, тому epoch без tle відхиляється); "tle_system" позначає їх для годинника кожної системи (типово TLE). Кожен результат вказує, яке саме небо в sky_source і sky_statement:

Суміш поєднує їх за допомогою +. epoch_utc — це момент, до якого пропаговано набори елементів, а tle_skipped називає, яку частину тексту не використано, з причиною: спотворені або осиротілі рядки наборів елементів (з їхніми номерами), набори, які парсер відхилив, і набори, які SGP4 не зміг пропагувати до цього моменту (зійшли з орбіти або вийшли за свої межі); усього не більше 100 записів, після чого один останній запис підраховує решту. Порожній список systems не додає пресетів. Скайплот зазначає підставу в нижньому колонтитулі.

Одне ядро. Матриця кофакторів — це orbit::cofactor_from_los, збирання матриці плану та обернення Гаусса–Жордана, що лежать в основі orbit::dop. orbit::dop_cov надає коваріацію, а orbit::dop — її згортку, тож скаляри VALIDATED не змінилися й досі зафіксовані в tests/dop_reference.rs. Другої реалізації DOP немає.

Еліпс. Півосі k σ √λ для власних значень λ блока схід–північ із k = √(−2 ln(1 − p)) (√5.991 = 2.448 при 95 %, 1 при 39,35 %) та азимут великої осі ½ atan2(2 Q_EN, Q_NN − Q_EE) у [0, 180) від півночі.

Кожен результат містить label (MODELLED), statement (геометрія за заданої моделі похибок: незалежні, однакові гауссові похибки дальності з нульовим середнім; це не прогноз реальної похибки приймача, яка містить також зміщення, багатопроменевість і похибки сигналів без прямої видимості; це не межа цілісності) та консультативну примітку: Консультативне програмне забезпечення, не навігаційне обладнання із затвердженням типу (IEC 61108, IEC 61162): відповідальність за навігацію судна залишається на операторі.

Докази#

П'ять рядків реєстру (docs/VERIFICATION-MATRIX.md), як їх окреслює проєктна нотатка:

Відсутність розділу [skyline] перевіряється побайтово щодо вихідних даних 0.35.0, що показує зворотну сумісність і нічого не підтверджує за зовнішнім еталоном. gnss_lib_py застосовує лише одну маску висоти, тож тут він є оракулом для DOP, а не для маски.

Чого лінія горизонту не моделює: дифракції на краю стіни, відбиттів і сигналів без прямої видимості, які реальний приймач усе ще може відстежувати (їх відкидають, а не послаблюють), часткової прозорості (ґратчастий кран непрозорий у межах свого сектора), рельєфу за межами заданих точок і кривизни Землі всередині форм каньйону та сектора.