homelab-configs/AdventureLog-BugReport-location-name-overwrite.md

[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.