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