Stsezhka

Appearance

Use Case #13: «Заделка дыр» 🌉 (Ремонт мостов и тоннелей на графике) ​

1. Жизненная ситуация (Боль пользователя) ​

Представь: Пользователь строит маршрут по абсолютно плоскому автомобильному мосту-виадуку, висящему на высоте 200 метров над глубоким ущельем. Что происходит на "глупом" сайте: На графике высот появляется жуткий V-образный кратер (отвесный провал вниз на 200 метров и такой же вертикальный подъем). Сайт портит всё:

  1. Статистика врет: В Общий набор высоты прибавляется 200 несуществующих метров изнурительного подъема.
  2. Время врет: Правило Найсмита смотрит на этот выдуманный подъем и накидывает лишние 20-30 минут в пути. То же самое с тоннелями — на графике внезапно вырастает Эверест. Сайт как бы предлагает юзеру слезть с велосипеда и лезть по макушке горы.

2. Почему карты тупят? (Причина бага) ​

В основе высот лежат базы радарной съемки со спутников NASA (SRTM или DEM). Спутник стреляет радаром из космоса вниз:

  • Мост: Луч прошибает тонкий бетонный мост и ударяется в воду на дне ущелья. Спутник пишет: "Высота 0 метров".
  • Тоннель: Луч бьется в снежную вершину горы. Спутник пишет: "Высота 2000 метров". Алгоритм сайта слепо верит этим координатам, рождая чудовищные баги на графиках.

3. Как это ДОЛЖНО работать у тебя (UX-Магия) ​

Когда юзер строит маршрут через мост или тоннель, график высот должен показывать идеально ровную, прямую линию, соединяющую два берега ущелья (или два входа в тоннель). Статистика набора высоты остается кристально чистой. Юзер видит, что твой планировщик понимает законы физики.

4. СЕКРЕТ ДЛЯ ПРОГРАММИСТА (Как починить это за час) ​

Программисту не нужно вручную искать все мосты в мире. База OpenStreetMap (OSM) уже всё знает. Алгоритм починки "фантомных провалов" состоит из 3 шагов:

  • Шаг 1 (Ловим триггер): Движок маршрутов (BRouter/OSRM/GraphHopper) умеет возвращать системные теги дороги. Учим код находить два волшебных слова: bridge=yes и tunnel=yes.
  • Шаг 2 (Мерки с берегов): Как только трек въезжает на мост, скрипт берет "честную" высоту входа (например, 150 метров) и высоту выхода (152 метра).
  • Шаг 3 (Доска над пропастью): Самое важное! Код БЕЗЖАЛОСТНО УДАЛЯЕТ все спутниковые данные высоты (DEM), которые лежат МЕЖДУ входом и выходом. Вместо них скрипт делает математическую линейную интерполяцию (мысленно натягивает струну от 150м до 152м). График становится ровным, фейковые скачки исчезают.

5. Идеальный GPX на экспорт ​

В скачанном GPX-файле высоты на мосту тоже будут исправленными (интерполированными). В лесу юзер въедет на мост, навигатор Garmin посмотрит в файл и покажет ровный профиль. Устройство не будет истерично пищать "Внимание! Смертельный спуск 200 метров!". Всё сработает как швейцарские часы.

Эпики и Задачи ​

Epic 1: Детектор Инфраструктуры (OSM Tag Parser) ​

  • Task 1.1: Настроить profile роутера (в BRouter/OSRM) на обязательную отдачу тегов покрытия и инфраструктуры в JSON-ответе.
  • Task 1.2: Написать парсер геометрии, который сканирует сегменты и помечает объекты (массивы точек), где присутствует bridge или tunnel.

Epic 2: Линейный Интерполятор Высот (Z-Axis Fix) ​

  • Task 2.1: Написать сервис ElevationFixer. Для каждого размеченного моста/тоннеля находить точку входа P_in и точку выхода P_out.
  • Task 2.2: Брать высоту Z_in и Z_out. Для всех промежуточных точек внутри этого отрезка удалять оригинальный Z (от DEM) и рассчитывать новый Z через математическую линейную интерполяцию в зависимости от дистанции от старта.

Epic 3: Pipeline Интеграция (Защита Системы) ​

  • Task 3.1: Встроить ElevationFixer в пайплайн обработки сразу ПОСЛЕ запроса к Elevation API, но ДО того, как координаты попадут в State Management (Zustand/Redux).
  • Task 3.2: Убедиться, что NaismithCalculator (База №11) и компонент отрисовки Profile Chart получают уже "исцеленные" (плоские) координаты.