4aiman/baldav
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
baldav/IMPLEMENTATION_PLAN.md

94 lines
8.9 KiB
Markdown
Raw Normal View History

BRouter: analysis + embed the offline routing engine (Stage 1) Analysis in docs/brouter-findings.md: how BRouter knows roads (.rd5 segments), routes and reaches low elevation gain (profile uphill/downhill cost + kinematics), the three call surfaces, and an evaluation of two ideas — fill GPS gaps along roads, and offline waypoint route planning. License is MIT; the engine has no desktop-only deps, so it embeds on Android ART. Stage 1 (embed + bridge, compiles into the apk; on-device route not yet run): - vendored brouter-1.6.3-all.jar into the Android module (dexes cleanly) and bundled the trekking/shortest profiles + lookups.dat as assets, copied to files/brouter/profiles2 on launch - MainActivity: a brouter_command.txt handler on the existing FileObserver runs btools.router.RoutingEngine off the UI thread (recipe taken via javap from ServerHandler) and returns the track as GPX - Rust brouter_route command: same file bridge as GPS (request + command, poll for the result), registered in the invoke handler - frontend/js/router.js: BRouter.route(points, profile) -> GPX (parseRouteGPX) - LICENSE-brouter (MIT notice) kept alongside the vendored engine Segments (.rd5, ~13-23 MB per 5x5 tile) are delivered later (Stage 2, wired download inside BalDav). IMPLEMENTATION_PLAN.md tracks the 5 stages.
2026-09-09 00:56:13 +03:00
# IMPLEMENTATION_PLAN: встраивание BRouter в BalDav
Основано на `docs/brouter-findings.md`. Цель — оффлайн-роутинг внутри BalDav (движок BRouter
встроен в Android-модуль, `btools.router.RoutingEngine` в процессе, MIT). Две прикладные фичи:
идея 1 (заполнение GPS-пропусков по дороге) и идея 2 (оффлайн-планирование маршрута по точкам).
Ключевые решения: встраивание (вариант B); сегменты `.rd5` качаются по проводу внутри BalDav в
app data dir; профиль trekking (идея 2) и shortest (идея 1); лицензия MIT (положить `LICENSE-brouter`).
Мост как у GPS-сервиса: JS → Rust `invoke` → Kotlin (движок) → результат обратно. Данные:
профили — assets в apk; сегменты — app data dir (скачиваются). Движок зовём напрямую (без RouteServer).
---
## Stage 1 — Встраивание движка + спайк «проложи 2 точки»
**Goal:** движок компилируется в составе BalDav и возвращает маршрут по паре точек на телефоне.
**Changes:**
- Извлечь `brouter-1.6.3-all.jar` в `src-tauri/gen/android/app/libs/`, подключить в gradle
(`implementation files('libs/brouter-1.6.3-all.jar')`), включить desugaring при необходимости.
- Профили в assets: `assets/brouter/profiles2/{lookups.dat,trekking.brf,shortest.brf}`.
- Kotlin `BRouterService`/функция: копирует профили из assets в files, зовёт
`btools.router.RoutingEngine(segmentsDir, profilesDir, profile, waypoints, outGpx)`, читает результат.
- Rust-команда `brouter_route(lonlats, profile) -> String(geojson/gpx)` в plugin bridge.
- JS-обёртка (новый `frontend/js/router.js` или в gps.js): `BRouter.route(points, profile)`.
- `LICENSE-brouter` (MIT-нотис) в корень.
**Success:** на телефоне с вручную положенным тайлом региона (adb push для спайка) вызов
`BRouter.route([[lon,lat],[lon,lat]], "shortest")` возвращает дорожный GPX/GeoJSON, а не ошибку.
**Tests:** ручной вызов из DevTools (CDP) + лог движка; сверить, что трек идёт по дорогам.
BRouter Stage 1: verified on device; ship v11 lookups/profiles to match segments End-to-end offline routing confirmed on the phone: shortest ~5.4 km in Rostov (3.2s cold), trekking cross-tile Rostov->region 44.8 km / 316 m ascend (1.2s), 617 ms on the apk-shipped data. JS -> Rust brouter_route -> Kotlin engine -> GPX works through the whole chain. The 1.6.3 distribution ships lookups.dat v10, but the live brouter.de/segments4 tiles are v11 ("lookup version mismatch"). Replaced the vendored lookups.dat + trekking/shortest profiles with the v11 set from abrensch/brouter master (misc/profiles2); the 1.6.3 engine accepts them. Profiles and lookups MUST match the segments' version.
2026-09-09 01:07:24 +03:00
**Status:** DONE (проверено на устройстве 2026-09-09). `shortest` Ростов 5.4км за 3.2с;
`trekking` кросс-тайл Ростов→город 44.8км/набор 316м за 1.2с; GPX с track-length/ascend/cost.
ВАЖНО: bundled `lookups.dat` из 1.6.3 — версии 10, а живые сегменты brouter.de/segments4 — v11
(«lookup version mismatch»). Ассеты заменены на v11 из репозитория (abrensch/brouter master:
misc/profiles2/{lookups.dat,trekking.brf,shortest.brf}); движок 1.6.3 их принимает. Профили/lookups
ОБЯЗАНЫ совпадать по версии с сегментами.
BRouter: analysis + embed the offline routing engine (Stage 1) Analysis in docs/brouter-findings.md: how BRouter knows roads (.rd5 segments), routes and reaches low elevation gain (profile uphill/downhill cost + kinematics), the three call surfaces, and an evaluation of two ideas — fill GPS gaps along roads, and offline waypoint route planning. License is MIT; the engine has no desktop-only deps, so it embeds on Android ART. Stage 1 (embed + bridge, compiles into the apk; on-device route not yet run): - vendored brouter-1.6.3-all.jar into the Android module (dexes cleanly) and bundled the trekking/shortest profiles + lookups.dat as assets, copied to files/brouter/profiles2 on launch - MainActivity: a brouter_command.txt handler on the existing FileObserver runs btools.router.RoutingEngine off the UI thread (recipe taken via javap from ServerHandler) and returns the track as GPX - Rust brouter_route command: same file bridge as GPS (request + command, poll for the result), registered in the invoke handler - frontend/js/router.js: BRouter.route(points, profile) -> GPX (parseRouteGPX) - LICENSE-brouter (MIT notice) kept alongside the vendored engine Segments (.rd5, ~13-23 MB per 5x5 tile) are delivered later (Stage 2, wired download inside BalDav). IMPLEMENTATION_PLAN.md tracks the 5 stages.
2026-09-09 00:56:13 +03:00
## Stage 2 — Экран загрузки сегментов по проводу
**Goal:** пользователь скачивает тайлы `.rd5` региона внутри BalDav в app data dir.
**Changes:**
- Экран/настройка «Сегменты дорог»: список нужных тайлов по региону (карта/выбор), кнопка скачать
с `brouter.de/brouter/segments4/<tile>.rd5`, прогресс, размер, дата. Хранить в app data dir
(путь, который читает Stage 1).
- Управление: список скачанного, удалить/обновить.
BRouter Stage 2 (primitive): download .rd5 segments inside the app Kotlin owns the download so tiles land in the exact dir the engine reads (files/brouter/segments4) — no Rust path guessing. processBrouterCommand now dispatches: dltile:<tile> streams brouter.de/brouter/segments4/<tile>.rd5 to a .tmp then renames, writing progress/final state to brouter_dl_<tile>.json; listtiles writes brouter_tiles.json. Tile names are sanitized ([A-Za-z0-9_]). Rust relays: brouter_download_tile / brouter_download_status / brouter_list_tiles. JS: BRouter.downloadTile/downloadStatus/listTiles/downloadTileAndWait. Compiles into the apk. Not yet exercised on device (phone offline) — the tile selection UI and the end-to-end download->offline-route test are the remaining Stage 2 work. IMPLEMENTATION_PLAN updated.
2026-09-09 01:11:20 +03:00
**Success:** дома по проводу тайлы региона (E35_N45/E40_N45 — подтверждены) скачиваются и лежат так,
BRouter: analysis + embed the offline routing engine (Stage 1) Analysis in docs/brouter-findings.md: how BRouter knows roads (.rd5 segments), routes and reaches low elevation gain (profile uphill/downhill cost + kinematics), the three call surfaces, and an evaluation of two ideas — fill GPS gaps along roads, and offline waypoint route planning. License is MIT; the engine has no desktop-only deps, so it embeds on Android ART. Stage 1 (embed + bridge, compiles into the apk; on-device route not yet run): - vendored brouter-1.6.3-all.jar into the Android module (dexes cleanly) and bundled the trekking/shortest profiles + lookups.dat as assets, copied to files/brouter/profiles2 on launch - MainActivity: a brouter_command.txt handler on the existing FileObserver runs btools.router.RoutingEngine off the UI thread (recipe taken via javap from ServerHandler) and returns the track as GPX - Rust brouter_route command: same file bridge as GPS (request + command, poll for the result), registered in the invoke handler - frontend/js/router.js: BRouter.route(points, profile) -> GPX (parseRouteGPX) - LICENSE-brouter (MIT notice) kept alongside the vendored engine Segments (.rd5, ~13-23 MB per 5x5 tile) are delivered later (Stage 2, wired download inside BalDav). IMPLEMENTATION_PLAN.md tracks the 5 stages.
2026-09-09 00:56:13 +03:00
что Stage 1 их читает; в поле сеть не нужна.
**Tests:** скачать тайл, проложить маршрут офлайн (сеть выключить) — работает.
BRouter Stage 2 (primitive): download .rd5 segments inside the app Kotlin owns the download so tiles land in the exact dir the engine reads (files/brouter/segments4) — no Rust path guessing. processBrouterCommand now dispatches: dltile:<tile> streams brouter.de/brouter/segments4/<tile>.rd5 to a .tmp then renames, writing progress/final state to brouter_dl_<tile>.json; listtiles writes brouter_tiles.json. Tile names are sanitized ([A-Za-z0-9_]). Rust relays: brouter_download_tile / brouter_download_status / brouter_list_tiles. JS: BRouter.downloadTile/downloadStatus/listTiles/downloadTileAndWait. Compiles into the apk. Not yet exercised on device (phone offline) — the tile selection UI and the end-to-end download->offline-route test are the remaining Stage 2 work. IMPLEMENTATION_PLAN updated.
2026-09-09 01:11:20 +03:00
**Status:** ПРИМИТИВ ГОТОВ (компилируется; тест на железе завтра). Kotlin качает тайл в
files/brouter/segments4 (путь детерминирован — качает сам Kotlin, без Rust-догадок): команды
`dltile:<tile>`/`listtiles` в processBrouterCommand, прогресс/статус в brouter_dl_<tile>.json.
Rust-реле: `brouter_download_tile`/`brouter_download_status`/`brouter_list_tiles`. JS:
BRouter Stage 2: resilient segment downloader (Range resume), verified on device In-app download initially stalled at 7922 bytes — not the network: the phone reaches brouter.de fully (confirmed via Termux). BalDav was not in the device's split tunnel, so its traffic took the wrong path; fixed device-side. Over the now-working but bursty link the fixed 30s readTimeout tripped, so the downloader is rewritten to resume: HTTP Range (append to the .tmp, 206=resume / 200=restart), readTimeout 60s, up to 30 retries. Verified on device: E40_N45 (14.1 MB) downloaded by the app (done ~55s), a cross-tile trekking route on the app-downloaded tile (44.8 km / 316 m, 1.66s) matches the PC-pushed tile, and listTiles returns both. Remaining Stage 2 work: the tile-selection UI.
2026-09-09 11:10:24 +03:00
`BRouter.downloadTile/downloadStatus/listTiles/downloadTileAndWait`.
ПРОВЕРЕНО НА УСТРОЙСТВЕ 2026-09-09: E40 (14.1 МБ) скачан самим BalDav (done за ~55с), маршрут на
скачанном тайле — кросс-тайл trekking 44.8км/316м за 1.66с (метрики = ПК-версии, тайл валиден),
listTiles отдаёт оба. Прежний стоп на 7922 байтах был из-за того, что BalDav не входил в
сплит-туннель устройства (НЕ сеть/код), — исправлено на устройстве. Загрузчик сделан устойчивым к
рывковой связи: HTTP Range-докачка (продолжает с места обрыва), readTimeout 60с, до 30 попыток.
ОСТАЛОСЬ: UI-экран выбора/загрузки тайлов по региону.
BRouter: analysis + embed the offline routing engine (Stage 1) Analysis in docs/brouter-findings.md: how BRouter knows roads (.rd5 segments), routes and reaches low elevation gain (profile uphill/downhill cost + kinematics), the three call surfaces, and an evaluation of two ideas — fill GPS gaps along roads, and offline waypoint route planning. License is MIT; the engine has no desktop-only deps, so it embeds on Android ART. Stage 1 (embed + bridge, compiles into the apk; on-device route not yet run): - vendored brouter-1.6.3-all.jar into the Android module (dexes cleanly) and bundled the trekking/shortest profiles + lookups.dat as assets, copied to files/brouter/profiles2 on launch - MainActivity: a brouter_command.txt handler on the existing FileObserver runs btools.router.RoutingEngine off the UI thread (recipe taken via javap from ServerHandler) and returns the track as GPX - Rust brouter_route command: same file bridge as GPS (request + command, poll for the result), registered in the invoke handler - frontend/js/router.js: BRouter.route(points, profile) -> GPX (parseRouteGPX) - LICENSE-brouter (MIT notice) kept alongside the vendored engine Segments (.rd5, ~13-23 MB per 5x5 tile) are delivered later (Stage 2, wired download inside BalDav). IMPLEMENTATION_PLAN.md tracks the 5 stages.
2026-09-09 00:56:13 +03:00
## Stage 3 — Идея 2: оффлайн-планирование по опорным точкам
**Goal:** тап опорных точек → дорожный маршрут trekking → существующий предпросмотр/профиль.
**Changes:**
- В `showRouteEditor` (frontend/js/main.js): между опорными точками звать `BRouter.route(...,
"trekking")` вместо прямых отрезков; результат (GPX/GeoJSON) парсить существующим `parseRouteGPX`,
дальше работает `showRouteDetail`/`routeElevStats`/`drawRoutePolyline`.
- Фолбэк на прямую линию, если движок/сегмент недоступны.
**Success:** тап точек даёт маршрут по дорогам с профилем высоты; сохраняется как маршрут.
**Tests:** спланировать знакомый маршрут офлайн, сверить с онлайн-BRouter (та же геометрия).
**Status:** not started
## Stage 4 — Идея 1: заполнение GPS-пропусков по дороге
**Goal:** GPS-разрыв заполняется дорожным путём (shortest), с фолбэком на хорду.
**Changes:**
- В ветке `isGap` `computeStats`/при обработке трека: проложить `BRouter.route(предгэп, послегэп,
"shortest")`; если длина по графу > ~3× хорды (константа, подобрать на практике) — оставить хорду.
- Точки-заполнители помечать `estimated`; решить зачёт дорожной дистанции (по умолчанию — считать
дорожную длину, но с лимитом гэпа).
**Success:** записанный трек с дропаутом GPS показывает дорожный фолловинг вместо хорды, кроме
случая «дорога в разы длиннее».
**Tests:** трек с известным дропаутом на дороге → заполнение по дороге; дропаут на поле → хорда.
**Status:** not started
## Stage 5 — Полировка (опционально)
**Goal:** удобство и корректность.
**Changes:** настройка «избегать подъёмов» (крутилка `uphillcost` в trekking); обновление сегментов;
доки (README/PROJECT_MAP), лог сессии; проверка размера apk.
**Status:** not started
---
## Потенциальные проблемы
- Desugaring/`java.lang.invoke` при dex — проверить сборку (AGP обычно тянет).
- Размер/имена тайлов региона на brouter.de — уточнить при Stage 2.
- Время роутинга на телефоне на больших `.rd5` — замерить (может понадобиться таймаут/поток).
- Формат вывода: GeoJSON проще парсить, чем GPX; выбрать при Stage 1.
- Заполнение гэпов не должно ломать существующие фильтры высоты/скорости (estimated-флаг).
Reference in a new issue Copy permalink