Идея: список мест полётов из OSM и закачка полных данных по месту

01.10.2026. Статус: идея, не принята. Альтернатива пакетам регионов из docs/plan/offline_world_data.md (там — отложено).

1. Список мест полётов из OSM

Из OSM брать размеченные места свободных полётов и показывать их списком для выбора старта.

Теги:

sport=free_flying — место полётов;
free_flying:site=takeoff|landing|toplanding|towing|training — старт, посадка, буксировка;
free_flying:hanggliding=yes/no, free_flying:paragliding=yes/no — для кого место;
free_flying:site_orientation=N;NE… — при каком ветре работает старт;
name, ele, иногда описание и рейтинги.

Что даёт игре:

список «куда полететь» с готовыми точками старта вместо выбора наугад на карте;
пары «старт → посадка» в одном районе: посадку показать на карте, можно задать цель полёта;
ветер по умолчанию по ориентации старта (склон работает только при своём ветре — это физика);
в сетевой игре — общая точка сбора по названию места.

Ограничения:

полнота: в Альпах разметка густая, в России редкая; ориентация и признак «дельтаплан» заполнены ещё реже. До работы — один запрос Overpass: сколько мест в России/на Алтае/на Урале и в Словении;
многие места параплановые, hanggliding часто не указан — не фильтровать строго по =yes, показывать все с пометкой;
дубли, одна точка на всё место, устаревшие места;
дополнение: ручной список от пилотов (лучше — внести их места в сам OSM); внешние базы (ParaglidingEarth, DHV Geländedatenbank) — только после проверки лицензии.

В плане пакетов это уже частично есть (sport=free_flying в слое «объекты для пилота», задачи 7 и 9а) — отдельного направления не нужно, только индекс мест и список в интерфейсе.

2. Кнопка «закачать полные данные» после выбора места

После выбора места (из списка или на карте) — кнопка «закачать полные данные». По ней игра скачивает и упаковывает для этого места всё то же, что сейчас готовится для встроенных локаций: рельеф, покров, OSM (ЛЭП, дороги, реки, озёра, посёлки), маску воды. Дальше место летается без сети, как встроенное.

Плюсы:

вместо пакета региона на сотни МБ — 10–15 МБ на место и только туда, куда реально летают;
снимается вопрос «какие регионы»: работает любое место, где есть данные;
связка со списком мест: выбрал старт → закачал → летаешь офлайн; перед поездкой можно закачать нужные места заранее;
встроенные локации становятся просто «заранее закачанными» местами того же формата; код дальше не различает встроенные и скачанные.

Минусы и вопросы:

расходится с решением «сеть убрать совсем»: сеть остаётся, но только на шаге закачки, полёт — из локальных данных. Решение за пользователем;
чужие серверы (Overpass, Terrarium, WorldCover) бывают перегружены или отказывают — нужны зеркало, User-Agent и понятная ошибка «повторите позже»;
формат скачанного места = формат встроенного (data/terrain/<id>/ + OSM), хранить в user://;
карта выбора старта без сети показывает только уже закачанные места.

Что из плана пакетов остаётся нужным при любом источнике вектора: подложка на GPU (задача 5), классы для термиков из OSM (6), объекты для пилота (7), процедурные дома (8). Сборщик build_pack.py и раздача пакетов на itch — не нужны или откладываются.

3. Чем собирать место у пилота

Сейчас сборка встроенных мест — на Python (tools/osm/fetch_osm.py, tools/terrain/osm_water.py, сборка рельефа). У пилота Python нет. Два варианта:

А. Go-сборщик, свой бинарник под каждую сборку (Win/Linux/macOS).

кросс-сборка одной командой, статический бинарник без зависимостей;
библиотеки есть: paulmach/osm, paulmach/orb, andybalholm/brotli (формат .f32.br сохраняется), растеризация image/draw / fogleman/gg;
быстро, многопоточно, игра не подвисает;
главное: тем же бинарником собирать и встроенные места в репозитории — один путь сборки, не два расходящихся;
минусы: третий язык в проекте; сборка бинарника в new-release на каждую платформу и тесты; неподписанный исполняемый файл, ходящий в сеть (SmartScreen/антивирус на Windows, Gatekeeper на macOS); перенос кода с numpy — циклами; игра запускает процесс (OS.create_process), читает прогресс из stdout.

Б. Прямо в игре (GDScript + GPU).

второго бинарника и проблем с подписью нет;
HTTP, JSON, Image в Godot есть; растеризация воды/подложки всё равно на GPU (задача 5);
минусы: Godot пишет не brotli (только читает) — формат сменить на zstd (совместимость не нужна); тяжёлый CPU-код на GDScript медленный.

Выбор зависит от того, что делает сегодняшняя Python-сборка: если в основном «скачать → перепаковать → растеризовать полигоны» — Б; если заметная обработка массивов рельефа и покрова — А.

Первый шаг (если идею берём)

Разбор сборки встроенного места: список шагов, для каждого — вход/выход, тяжесть по CPU, цена переноса в GDScript и в Go → выбор А или Б.
Запрос Overpass: сколько мест sport=free_flying в России (Алтай, Южный Урал) и в Словении, сколько с hanggliding и site_orientation.