randy
d9879bad60
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.
MapTool
Table of Contents
A mapping application written in Ruby with Sinatra.
The project’s shape is still open — this is the initial scaffold.
Status
Early scaffold. The web application serves a vector map (MapLibre GL JS), with an online style and an optional offline style backed by a local PMTiles file, an animated RainViewer radar overlay, GPX upload/display (points and tracks, organized in folders), and a live position marker from a local GNSS receiver via gpsd.
Requirements
-
Ruby (see
.ruby-version) and Bundler
Getting started
bundle install
bundle exec puma -C config/puma.rbThen open http://127.0.0.1:4567 in a browser.