Sync workspace with Gitea: merge June/July session docs
- README + siklos-docker-services: add authentik/searxng/beszel rows, photos VM section, 2026-06-24 cleanup notes, 2026-07-03 Portainer conversion note (jgpc naming preserved) - Add: authentik setup docs, frigate docs/config, OCIS migration docs, AdventureLog bug report, install-native-apps.sh, workstation-disk-analysis.md - Remove obsolete: cgitta-nextcloud-zip-analysis.md, kopia-restore-guide.md - .gitignore: ocis-credentials.md (secrets stay local), *.bak
This commit is contained in:
@@ -0,0 +1,71 @@
|
||||
# [BUG] Selecting a location search result overwrites the correct name with a reverse-geocoded POI name (e.g. "39")
|
||||
|
||||
🛑 **Note**: I searched existing issues before filing and did not find a match.
|
||||
|
||||
## 🐞 Bug Description
|
||||
|
||||
When adding a location, the search box returns the correct place from OpenStreetMap (e.g. **"Elk Rock State Park"**) with the correct address. But as soon as I **click that search result**, the app discards the result's name and replaces the location **Name** field with an unrelated value — in my case the bare number **"39"**.
|
||||
|
||||
The root cause is that selecting a search result does not keep the name the search already provided. Instead the app takes only the result's coordinates and performs a **reverse geocode** on them, then uses that reverse-geocode's `location_name` as the location Name. At the park's center point, the nearest named OSM object is a campsite tagged `tourism=39`, so the Name becomes "39". The coordinates and region (Marion County, Iowa) are correct — only the Name is wrong.
|
||||
|
||||
This means the app is throwing away good data it already has.
|
||||
|
||||
## 🔄 Steps to Reproduce
|
||||
|
||||
1. Add a new Location (e.g. inside a Collection).
|
||||
2. In "Search for a location", type `Elk Rock State Park`.
|
||||
3. The dropdown correctly shows **"Elk Rock State Park — Elk Rock State Park, Knoxville Township, Marion County, Iowa, United States"**.
|
||||
4. Click that result.
|
||||
5. The Name field is populated with **"39"** instead of "Elk Rock State Park".
|
||||
|
||||
## ✅ Expected Behavior
|
||||
|
||||
When a user selects a search result, the location **Name** should be set from that result's `name` (e.g. "Elk Rock State Park"). Reverse geocoding is fine for filling region/city/country, but it should **not overwrite** the name the user just selected from search.
|
||||
|
||||
## 📸 Evidence (server-side reproduction)
|
||||
|
||||
Running the app's own geocoding functions on the backend (`v0.12.1`, OSM/Nominatim, no Google key):
|
||||
|
||||
**Step A — what the search dropdown returns (`search_osm('elk rock state park')[0]`):**
|
||||
```
|
||||
name = 'Elk Rock State Park'
|
||||
lat, lon = 41.4008688, -93.0776561
|
||||
display_name = 'Elk Rock State Park, Knoxville Township, Marion County, Iowa, United States'
|
||||
```
|
||||
|
||||
**Step B — what the app does on selection (`reverse_geocode(41.4008688, -93.0776561, user)`):**
|
||||
```
|
||||
location_name = '39'
|
||||
display_name = 'Marion County, Iowa, US'
|
||||
city / region = Marion County / Iowa
|
||||
```
|
||||
|
||||
Raw Nominatim reverse lookup for those coordinates confirms the source of "39":
|
||||
```
|
||||
name: '39'
|
||||
display_name: '39, Hayes Drive, Knoxville Township, Marion County, Iowa, 50138, United States'
|
||||
address: { "tourism": "39", "road": "Hayes Drive", "county": "Marion County", ... }
|
||||
```
|
||||
|
||||
So the correct name ("Elk Rock State Park") from Step A is replaced by the reverse-geocode `location_name` ("39") from Step B.
|
||||
|
||||
## 🔧 Suggested Fix
|
||||
|
||||
In the frontend "add location" flow, when a search result is chosen, keep that result's `name` for the location Name field. Continue to call `reverse_geocode` for region/city/country enrichment, but do not let its `location_name` overwrite a name that came from an explicit search-result selection. (Only fall back to the reverse-geocoded name when the location was placed by clicking the map, where no search name exists.)
|
||||
|
||||
Relevant backend code for reference:
|
||||
- `adventures/views/reverse_geocode_view.py` → `search` (returns the correct `name`)
|
||||
- `adventures/geocoding.py` → `search_osm` (passes OSM `name` through) and `reverse_geocode` / `reverse_geocode_osm` (returns `location_name` from the nearest OSM object, which can be a bare number)
|
||||
|
||||
## 🐳 Environment Details
|
||||
|
||||
- **Host:** Self-hosted (Proxmox VM, Docker via Portainer)
|
||||
- **Install Method:** Docker Compose
|
||||
- **AdventureLog Version:** v0.12.1
|
||||
- **Reverse Proxy:** Caddy
|
||||
- **Geocoding provider:** OpenStreetMap / Nominatim (no `GOOGLE_MAPS_API_KEY` set)
|
||||
- **Browser:** <fill in, e.g. Firefox / Chrome + version>
|
||||
|
||||
## 📎 Additional Context
|
||||
|
||||
The reverse-geocoded region data (Marion County, Iowa, United States) is correct — this bug is specifically about the **Name** field being overwritten after a search-result selection. Users can manually retype the Name as a workaround, but it defeats the purpose of searching.
|
||||
Reference in New Issue
Block a user