baldav/docs/brouter-findings.md

Разбор BRouter 1.6.3 под две идеи BalDav (2026-09-07)

Получено разбором brouter-1.6.3.zip (read-only: листинг архива, чтение текстовых доков и профилей через stdout, инспекция brouter-1.6.3-all.jar в памяти — распаковки на диск и запуска Java не было). Цель — понять, как BRouter «знает, где дорога» и строит маршруты с малым набором высоты, и оценить под это две идеи пользователя:

1. Заполнение GPS-пропусков по дороге — когда GPS пропадает и появляется, пробел заполнять кратчайшим путём по реальным дорогам, а не хордой/скорость×время.
2. Оффлайн-планирование маршрута по опорным точкам в BalDav — замена онлайн-BRouter.

Обе идеи требуют оффлайн-роутинга; сеть в поле недоступна (РЭБ/РКН — как в обсуждениях ветра и DEM), поэтому годятся только оффлайн-схемы.

---

1. Что внутри дистрибутива

Часть	Что это
BRouterApp.1.6.3-api19-release.apk, ...api30-release.apk	Android-приложение btools.routingapp (одно и то же, под разные min-SDK). Считает маршрут, карту НЕ рисует.
brouter-1.6.3-all.jar (356 КБ)	Standalone-движок на чистой Java. Main-Class btools.server.BRouter (HTTP-сервер). Тот же движок, что в apk.
profiles2/*.brf	Профили маршрутизации (текстовые скрипты стоимости). lookups.dat — таблица тегов/значений.
readmes/	Документация: установка, profile_developers_guide.txt, mapcreation.md, интеграция с OsmAnd, особенности Android 11.

BRouter — маршрутизатор без карты: на вход опорные точки + профиль, на выход трек (GPX/GeoJSON). Отрисовка и навигация — на стороне карт-тула (OsmAnd/Locus/…), либо, в нашем случае, на стороне BalDav.

2. Где дорога: данные .rd5

• Граф дорог — сегментные файлы .rd5, тайлы 5°×5° по широте/долготе. Внутри — OSM-ways и nodes, закодированные в бинарный битстрим по таблице lookups.dat (для каждого тега — набор значений с частотами и алиасами).
• Готовые тайлы качаются с brouter.de/brouter/segments4 (пересобираются еженедельно) или строятся самому из OSM-dump + SRTM (mapcreation.md, скрипт process_pbf_planet.sh, требуется Osmosis/pbfparser).
• Высоты в сегментах берутся из SRTM-90м (CGIAR). Именно они дают BRouter'у профиль рельефа, по которому он считает набор высоты (см. §4). Без SRTM сегменты соберутся, но без высот — маршруты «с малым набором» не получатся.
• Для нашего региона (Ростовская обл., ~47N/40E) нужны тайлы, чьи SW-углы кратны 5: вероятно E35_N45.rd5 (35–40E, 45–50N) и E40_N45.rd5 (40–45E) — город ~40.1E попадает во второй. Точные имена и размер (обычно десятки МБ на тайл) — проверить при загрузке. Загрузка одноразовая по проводу — тот же паттерн «скачать дома», что для DEM/прогноза.

3. Как строится маршрут (движок)

• Класс btools.router.RoutingEngine. Ключевые шаги (по строкам байткода): matchWaypointsToNodes — привязка каждой опорной точки к ближайшему дорожному узлу графа (это и есть ответ «где дорога, а где нет»: точка вне дорог подтягивается к дороге), затем поиск пути по графу между привязанными узлами.
• Стоимость ребра считает интерпретатор профиля (btools.expressions) по тегам ребра из .rd5. Поиск минимизирует суммарную стоимость (по сути A*/Dijkstra по сегментному графу с кэшами профиля).
• На выход движок отдаёт трек и метрики: track-length, filtered ascend и plain-ascend (набор высоты — сглаженный и сырой), cost, energy, time (по кинематике профиля). Формат — GPX (formatAsGpx/writeGpx) или GeoJSON/KML.

4. Малый набор высоты — как именно (основной режим)

Это чисто вопрос профиля, а не движка. В trekking.brf (context:global):

assign consider_elevation = true
assign downhillcost   = 60     # штраф за спуск
assign downhillcutoff = 1.5    # уклоны меньше 1.5% не штрафуются
assign uphillcost     = 0      # (в trekking по умолчанию 0; крутить вверх — здесь)
assign uphillcutoff   = 1.5

Плюс кинематическая модель времени/энергии — прямой аналог модели мощности BalDav:

assign totalMass  = 90     # масса байк+седок, кг
assign maxSpeed   = 45     # км/ч
assign S_C_x      = 0.225  # CdA (площадь×коэф. лобового сопротивления)
assign C_r        = 0.01   # коэффициент качения
assign bikerPower = 100    # средняя мощность, Вт

Чтобы получить маршрут с малым набором высоты, поднимают uphillcost (и/или downhillcost): движок начинает предпочитать обходные, но более пологие дороги. uphillcutoff/downhillcutoff задают порог уклона, ниже которого рельеф игнорируется. То есть «основной режим» пользователя в онлайн-BRouter — это trekking с ненулевым uphillcost.

Отдельно есть shortest.brf: downhillcost=0, uphillcost=0, turncost=0 — чистейший кратчайший путь по дорогам, без учёта рельефа. Это ровно то, что нужно для идеи 1 (заполнить GPS-пропуск — важно «просто чтобы была дорога», кратчайшая).

5. Как вызвать оффлайн — три поверхности

(а) Standalone-jar на компе (HTTP-сервер). Подтверждённая строка usage:

java -cp brouter-1.6.3-all.jar btools.server.RouteServer <segmentdir> <profiledir> <customprofiledir> <port> <maxthreads> [bindaddress]

Запрос (тот же API, что у brouter.de/brouter-web):

GET http://127.0.0.1:<port>/brouter?lonlats=39.7,47.2|40.1,47.4&profile=shortest&format=geojson&timode=0&alternativeidx=0

Параметры (из байткода RouteServer): lonlats (пары lon,lat через |), profile, format (gpx/geojson/kml), timode (turnInstructionMode), alternativeidx, nogos. Нужен JRE + каталог сегментов .rd5 + каталог профилей. Годится для инструментов tools/track/ (проложить маршрут по lonlats, что уже выдаёт tools/steep_segments.js).

(б) Приложение BRouter на телефоне — Server-Mode. Приложение поднимает локальный HTTP-сервер (порт 17777 по умолчанию); любой клиент на устройстве, включая WebView BalDav, шлёт тот же GET /brouter?lonlats=.... Требует установленного приложения BRouter и скачанных сегментов.

(в) Приложение BRouter — Android-intent. С v1.6.2 у приложения есть «интерфейс без файлового доступа»: BalDav (Kotlin) шлёт intent к btools.routingapp с опорными точками и профилем, получает GPX/GeoJSON обратно. Данные приложения с Android 11 лежат в Android/media/btools.routingapp/brouter/segments4.

(г) Встраивание движка в BalDav. brouter-1.6.3-all.jar — чистая Java (356 КБ), пакеты router/mapaccess/expressions/codec/util. Классы движка можно добавить в Android-модуль BalDav (src-tauri/gen/android) и звать из Kotlin, а из JS — через существующий Rust↔Kotlin-мост (как GPS-сервис). Полностью самодостаточно и оффлайн, второе приложение не нужно.

6. Идея 1 — заполнение GPS-пропусков по дороге

• Как: при разрыве взять последнюю точку до пропуска и первую после, проложить между ними маршрут профилем shortest.brf, вставить дорожную полилинию как заполнение гэпа.
• Стык с computeStats (frontend/js/gps.js, ветка isGap): сейчас гэп заполняется хордой или скорость×время. Дорожный путь точнее (по реальным дорогам). Точки-заполнители помечать estimated (как dead-reckoning), чтобы они не влияли на глюк-фильтры высоты и были видимо «достроенными». Решить: идёт ли дорожная дистанция в зачёт трека или только рисуется (сейчас гэп считается по скорости; дорожная длина может быть и точнее, и длиннее реального пути).
• Риски/границы: без сегментов на регион заполнить нечем; дорога-кратчайшая может отличаться от фактически проеханной; на бездорожье (поля, где пользователь реально ездит) кратчайший путь по графу дорог может увести. Нужен разумный лимит длины гэпа, при котором достраиваем.

7. Идея 2 — оффлайн-планирование маршрута по точкам

• Что уже есть в BalDav (frontend/js/main.js): showRouteEditor (тап по карте = точка, тап по линии = вставка, тащить/удалять), showRouteDetail (предпросмотр + профиль высоты routeElevStats + фуллскрин), drawRoutePolyline, «Сохранённые маршруты», топо/уклон-обводка. Парсер parseRouteGPX уже читает GPX/<ele>.
• Чего не хватает: оффлайн-роутера между опорными точками. Сейчас линия между тапами — прямая (ручное рисование). BRouter вернёт дорожный GPX/GeoJSON, который уже парсится parseRouteGPX, и дальше работает существующий предпросмотр/профиль высоты.
• То есть UI-обвязка в основном готова; предметная работа — вызов BRouter и подмена прямых отрезков дорожным маршрутом (+ выбор профиля: trekking с uphillcost для «поменьше в горку»).

8. Варианты интеграции и рекомендация

Вариант	Плюсы	Минусы
A. Зависимость от приложения BRouter (intent или localhost HTTP)	Быстро; роутинга в BalDav нет; BRouter сам качает/обновляет сегменты	Второе приложение ставить и настраивать; управление сегментами вне BalDav; связанность
B. Встраивание движка (jar в Android-модуль + Rust/JS-команда)	Самодостаточно, полностью оффлайн, один apk; сегменты кладём куда хотим	Бандлинг Java-движка; доставка .rd5 в приложение; проверить лицензию (GitHub abrensch/brouter); управление хранилищем сегментов
C. Порт на Rust/JS	Нет внешних зависимостей	Огромный объём (движок + формат .rd5 + интерпретатор профилей) — отклонить

Решение — B (встраивание) (подтверждено пользователем). Встраиваемость проверена по байткоду: движок (150 классов) использует только java.io/net/util/lang/text/security/zip — ни AWT/Swing/ RMI/ImageIO/servlet/sun.*, всё есть на Android ART. RouteServer — на голых ServerSocket/Socket (контейнер не нужен). Значит в процессе можно звать напрямую btools.router.RoutingEngine (без HTTP-сервера): дать каталог сегментов + профиль + опорные точки, получить GPX/GeoJSON. Для инструментов tools/track/ (анализ, не телефон) сразу годится вариант (а) — jar на компе.

9. Решения и открытые вопросы

Решено (2026-09-07):

1. Лицензия — MIT («Copyright (c) 2019 BRouter contributors», github.com/abrensch/brouter). Встраивание разрешено без ограничений; при распространении сохранить копирайт-нотис MIT (положить LICENSE-brouter в репозиторий рядом с движком).

2. Интеграция — вариант B (встраивание движка). Код BalDav открыт, MIT это позволяет.

3. Профиль — trekking (для обеих идей). Идея 1 всё же считается shortest для чистого кратчайшего пути (см. §6); trekking — для планирования (идея 2).

4. Идея 1, порог хорды: прокладывать по графу, НО если дорожная длина в разы больше хорды — рисовать хорду (граф увёл не туда, напр. вокруг поля). Коэффициент подобрать на практике (старт ~3×, вынести в конфиг/константу).

5. «Крутилка» uphillcost (см. §4) — пользователь про неё не знал. План: начать со стандартного trekking; если маршруты слишком в горку — добавить настройку «избегать подъёмов» (поднимать uphillcost). Пока не крутим.

6. Доставка сегментов — загрузка по проводу внутри BalDav (решено). Экран в BalDav: дома на Wi-Fi/проводе скачать готовые тайлы региона с brouter.de/segments4 в папку приложения (app data dir, аналог seed-БД); в поле сеть не нужна. Тот же паттерн, что задумывался для DEM/ прогноза. Свою сборку сегментов из OSM+SRTM не делаем.

7. Встраиваемость подтверждена (см. §8): движок без десктоп-зависимостей, зовём btools.router.RoutingEngine в процессе из Kotlin.

10. Проверка (PoC, отдельным шагом, по согласию)

Требует JRE и загрузки сегментов региона (сеть) — вне текущей задачи. Когда разрешишь: запустить RouteServer на компе с каталогом .rd5 и profiles2/, дёрнуть GET /brouter?lonlats=...&profile=shortest&format=geojson по паре точек из tools/steep_segments.js, убедиться, что возвращается дорожный маршрут с track-length/ascend.