Repository navigation
Weather panel stores and sends the chosen location at full geocoder precision #13050
Description
Omarchy version: 4.0.4
When a place is picked in the weather panel's location search, locationCommit() in shell/plugins/panels/weather/Model.js keeps the latitude and longitude exactly as Open-Meteo's geocoding API returns them: five decimal places, about one metre. persistLocation() writes them to ~/.local/state/omarchy/settings/weather.json, and every refresh then sends them unchanged to two third parties:
- wttr.in, through
wttrLocationQuery(), which uses the rawlat,lonas the path - api.open-meteo.com, through
refreshDailyForecast()inPanel.qml
A forecast does not need that precision, and it defeats a VPN, because the location is carried inside the request rather than inferred from the IP address. For a named place the geocoder returns a central point, so today the leak is limited to the town. But the stored format accepts any coordinates and omarchy-weather-location takes them from the command line, so a precise point entered there is sent as it is.
Suggested fix: round to two decimal places (about 1 km) in locationCommit() and in omarchy-weather-location before storing, and round again when building the two request URLs so existing settings files are covered too. Optionally send wttr.in only the place name.
Related but separate: #9706 and #12127 are about the label shown, not the precision sent.
Activity
Round weather coordinates to two decimal places
omarchybot commentedon Oct 12, 2026
I checked this against
quattroat defbf90 by reading the source. Nothing was run: the mechanism is visible in the code, and the fix is already in review.The report is right. Unrounded coordinates reach
weather.jsonby two paths, not one. The first iscommitLocation(), which runs on Enter in the search field and goes throughlocationCommit()inModel.js. The second ispickSuggestion()(Panel.qml:238), which runs when a suggestion is clicked and skipslocationCommit()entirely. Both callomarchy-weather-location --set, which stores whatever it is given. Every refresh then sends those coordinates out:wttrLocationQuery()puts them in the wttr.in path, andrefreshDailyForecast()(Panel.qml:170) puts them in the Open-Meteo URL. With no location set, the panel sends the coordinates wttr.in worked out from the IP address, so that path reveals nothing the request does not already.Two open pull requests fix this and already link this issue: #13113 and #13676. Both round to two decimals in three places: when the panel stores a location, when
omarchy-weather-location --setstores one, and when the two request URLs are built, so settings files written before the fix are covered too. Both also handle the click path: #13113 rounds inpickSuggestion(), and #13676 rounds the geocoder results themselves. Each pull request gets its own review and verification, and choosing between them is up to the maintainer.This is one model's reading (Claude Opus 5.5). No second opinion ran on this issue: the configured reviewer, Codex Medium, responds, but today's review budget had already been used.
Next step: the maintainer picks between #13113 and #13676.