5 Commits

Include renames

Author	SHA1	Message	Date
randy	141b7a08ce	Show accuracy circle around the browser-location fallback marker ... Re-adds the gray radius MapLibre's own GeolocateControl used to draw, using the same element/class and pixel-radius calculation.	2026-09-08 14:16:16 +02:00
randy	d9879bad60	Switch to GNSS immediately if it turns on mid-track ... If Locate was already tracking via the browser-geolocation fallback (GNSS was off when clicked) and GNSS then gets turned on via the sidebar, it kept using the browser position until the button was clicked again -- the browser's own (often less accurate) position had no business still being used once the app's own receiver had a fix. GnssControl#onEnabledChange (a small internal callback list) notifies LocateControl the moment the sidebar toggle changes; if it's actively tracking via the browser at that point, it stops that and jumps to GNSS's position instead. Caught a real bug while verifying this: the automatic handoff reused the same jump-to-GNSS helper a deliberate click uses, which alerts if GNSS has no fix yet -- but GNSS only just turned on and almost certainly hasn't gotten its first poll response back yet at the exact moment the handoff fires, so this popped a blocking window.alert() (which halts the whole page until dismissed) on every single enable. A test hung on exactly this before I noticed. Fixed with an alertIfNoFix option, true only for the deliberate-click path. Verified end to end (simulating the "already tracking" state directly since headless geolocation isn't reliable enough to trust as the trigger): toggling GNSS mid-track removes the blue browser marker, shows the green GNSS one once its poll lands, and no dialog appears.	2026-09-08 08:50:43 +02:00
randy	f0ac8ac5d4	Give the browser-location fallback its own (blue) marker color ... The browser-geolocation fallback was reusing GnssControl's green .gnss-marker for its own position dot -- on a machine with no real GPS chip, wifi/IP-estimated location can jump around noticeably between watchPosition updates, and a green dot doing that reads as "GNSS is somehow still being used" even when it very much isn't (confirmed: code review found no path from locate.js to /api/gnss/position at all, and GNSS was off in the report). Switched to MapLibre's own blue pulsing .maplibregl-user-location-dot -- the same look GeolocateControl itself had here before, and now visually distinct from GNSS's green on purpose rather than by accident. Verified: both markers rendered side by side (GNSS on via the simulator, plus a manually-placed browser-fallback-style marker) -- clearly different colors, no shared styling.	2026-09-08 08:04:31 +02:00
randy	6e5676c890	Make "find my location" actually follow GNSS, gated on the sidebar toggle ... Two fixes based on feedback after the last commit: 1. The map wasn't following the position at all -- only the first fix recentered, later updates just moved the marker. Now every fix recenters (easeTo, not flyTo, after the first one, so it doesn't repeat that zoom swoop on every update) -- matches how GeolocateControl's own trackUserLocation always behaved. 2. GNSS should only be used when explicitly turned on via the sidebar "GNSS" icon, not whenever a receiver happens to have a fix -- simpler to test against the simulator that way, and puts the visitor in control of whether GNSS is engaged at all. GnssControl now owns following the map on its own (same flyTo-once/easeTo-after pattern) whenever it's enabled; LocateControl checks GnssControl#isEnabled() and, when true, just jumps to #getPosition()'s current fix and reuses its existing .gnss-marker instead of polling/marking on its own. Only falls back to the browser's own geolocation when GNSS is off. Verified end to end with the GNSS simulator: enabling sidebar GNSS recenters immediately and keeps following over several polls; clicking Locate while GNSS is on jumps to the same position without creating a second marker or touching its own active state; turning GNSS back off and clicking Locate correctly falls through to the browser geolocation path instead.	2026-09-08 00:56:25 +02:00
randy	aec665179f	Prefer this app's own GNSS receiver for "find my location" ... LocateControl (public/js/locate.js) replaces MapLibre's own GeolocateControl -- same button, reusing its exact CSS/icon so it's a visual drop-in, but sourced differently. Checks GET /api/gnss/position once on click: if a fix is available (gpsd, possibly bin/gnss_simulator.rb's simulated one), tracks that instead of the browser's separate (and often less accurate) location service, which is now only a fallback. Only the first fix recenters the map; later updates just move the marker, unlike GeolocateControl's own default of recentering on every update, which would fight a pan/zoom made in the meantime. Verified end to end with the GNSS simulator running: clicking the button centered on the simulated position and dropped a marker, clicking again cleared both, no console errors.	2026-09-08 00:46:14 +02:00