2026-05-13 10:21:24 +03:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
<html lang="ru">
|
|
|
|
|
<head>
|
|
|
|
|
<meta charset="UTF-8" />
|
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" />
|
|
|
|
|
<title>BalDav</title>
|
|
|
|
|
<link rel="stylesheet" href="lib/leaflet.css" />
|
|
|
|
|
<link rel="stylesheet" href="css/styles.css" />
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
<div id="app"></div>
|
|
|
|
|
|
|
|
|
|
<!-- Load order matters: db.js and bmr.js expose window.DB / window.BMR,
|
|
|
|
|
then main.js uses them. Tauri injects window.__TAURI__ before page scripts. -->
|
|
|
|
|
<script src="lib/leaflet.js"></script>
|
2026-06-25 16:54:45 +03:00
|
|
|
<script src="lib/leaflet-rotate.js"></script>
|
2026-05-14 14:17:57 +03:00
|
|
|
<script src="lib/hammer.min.js"></script>
|
2026-05-16 21:21:13 +03:00
|
|
|
<script src="lib/chart.min.js"></script>
|
2026-05-14 14:17:57 +03:00
|
|
|
<script src="lib/chartjs-plugin-zoom.min.js"></script>
|
2026-05-13 10:21:24 +03:00
|
|
|
<script src="lib/jszip.min.js"></script>
|
2026-08-27 09:42:05 +03:00
|
|
|
<script src="lib/zxing-wasm.js"></script>
|
2026-05-13 10:21:24 +03:00
|
|
|
<script src="js/db.js"></script>
|
ble: read DIY barometer (BaroBalDav) over BLE + firmware
Self-made altitude sensor: ESP32-C3 SuperMini + BMP280 broadcasting pressure and
temperature over standard BLE Environmental Sensing. Read into baldav the same way as
the heart-rate strap (Kotlin BLE service -> file -> Rust -> JS), new device_type 'baro'.
- BleHrService: 'baro' type subscribes to ESS 0x181A (pressure 0x2A6D uint32 0.1 Pa,
temperature 0x2A6E int16 0.01 C), writes ble_baro_data.json + ble_baro_log.jsonl.
Every baro branch is gated by deviceType=='baro', so HR/GPS paths are untouched.
- ble.rs: BaroReading, ESS detection, ble_get_baro command (Android reads the file,
desktop returns None). Registered in lib.rs.
- frontend/js/baro.js: passive window.BARO - hypsometric pressure->altitude using the
sensor temperature, anchored to GPS altitude at ride start. Nothing runs until
BARO.start(), so with no barometer the app is unchanged.
- tools/baro-sensor: firmware (PlatformIO main.cpp + Arduino sketch) that reads BMP280
at max oversampling and advertises the ESS service.
Prep only: no hardware yet, verified by compile (build 0.1.538). Live wiring and
ride-track integration pending the board.
2026-10-30 00:38:12 +03:00
|
|
|
<script src="js/baro.js"></script>
|
2026-05-13 10:21:24 +03:00
|
|
|
<script src="js/bmr.js"></script>
|
|
|
|
|
<script src="js/tilecache.js"></script>
|
|
|
|
|
<script src="js/gps.js"></script>
|
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
|
|
|
<script src="js/router.js"></script>
|
POI overlay on maps: circular contrasting icons + category filter (offline)
Points of interest (cafe, shops, water, toilets, bank/ATM, bus, shelter,
viewpoint, ...) as circular contrasting badges (emoji in a white/dark circle,
readable on light and dark tiles) — not pins. A 📍 control toggles the layer
and opens a per-category filter (checkboxes, remembered). Markers are culled to
the visible bounds and shown from zoom 13 (cap 500/view), on the recording,
track-detail and roads maps.
Data is bundled and fully offline: frontend/data/pois.json ([{la,lo,c,n}], 358KB,
5662 POIs) fetched once from Overpass for ~100km around region (the whole
bbox returned in one query; adaptive subdivision was ready if it had truncated).
Verified functionally on device: 124 badges rendered in view at z16 over
region with correct bounds/category culling; the live visual could not be
screenshotted (the WebView surface is black under CDP). frontend/data + poi.js.
2026-09-09 16:51:58 +03:00
|
|
|
<script src="js/poi.js"></script>
|
2026-06-25 16:54:45 +03:00
|
|
|
<script src="js/sync.js"></script>
|
2026-08-27 03:27:15 +03:00
|
|
|
<script src="js/chzn.js"></script>
|
2026-05-13 10:21:24 +03:00
|
|
|
<script src="js/main.js"></script>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|