Place Matching & Geolocation
WFY24 resolves weather pages through localized search, nearest-place lookup and canonical place slugs instead of relying on raw coordinates alone.
Search -> canonical weather page
The site search is already built around canonical place pages and localized results, without needing to expose internal endpoints here.
Search input
The user types a query and the component clears stale results before each new request.
Debounced query
The query is not sent immediately. The system waits briefly so it can avoid unnecessary requests and stale results.
Protected search gateway
The frontend goes through a controlled search layer before place results are returned.
Place resolver
Search returns candidate places with slug, country context and breadcrumb data.
/{locale}/weather/{slug}
Selecting a result always lands on a canonical place slug instead of a free-text search page.
The public promise here is simple: from query to the right canonical place page with clear geographic context.
Auto-location without forcing a GPS prompt on load
The auto-location flow is already privacy-aware: it starts conservatively and only asks for precise location when the user wants it.
Homepage local weather card
If no cache exists, the component starts with IP geolocation and does not request GPS on first render.
IP-based location lookup
The system starts with a light IP-based lookup so it can offer an approximate location without forcing a GPS prompt.
Self-hosted geolocation service
The result returns an approximate location or a clean fallback when no usable match exists.
Nearest canonical place match
The coordinates are converted into a real canonical place with localized breadcrumb context.
Use resolved place coords for weather
The component fetches weather with the resolved place coordinates, not with rough IP coordinates.
The important public point is that the product avoids aggressive permission prompts and keeps the homepage aligned with canonical place pages.
1. Search starts with place slugs
When a user types into the main search dialog, WFY24 debounces the query and calls the internal /api/places/search route with the active locale. Results are displayed with localized names when available, plus region breadcrumb context and a country flag when the country code exists.
Selecting a result routes the user to the canonical place URL under /{locale}/weather/{slug}. That keeps every place page anchored to a stable slug rather than a temporary free-text query.
2. Reverse geocoding prefers the nearest known place
For auto-location experiences, WFY24 does not stop at raw coordinates. After obtaining approximate coordinates, the frontend calls /api/geo/reverse, which proxies the nearest-place lookup and returns a place object with localized breadcrumb information.
This extra step matters because users do not think in latitude and longitude. They think in places, regions and countries, and the product is designed around those canonical entities.
3. GPS is not auto-requested on page load
The homepage local weather card is intentionally conservative with permissions. On first load it tries self-hosted IP geolocation first. GPS is only requested after explicit user interaction, which avoids surprise prompts and keeps the initial page experience lighter.
Once a place is resolved, WFY24 fetches weather using the resolved place coordinates rather than rough IP coordinates so the homepage card stays aligned with the canonical city or place page.
4. Privacy and real-world limits
The codebase also shows a one-time session observation flow that can report a granted GPS fix to improve the self-hosted IP geolocation system. That is a product-quality loop, not a requirement for browsing weather pages.
Search quality still depends on the underlying place database, place types, translated names and administrative hierarchies. Remote settlements, disputed areas or recently changed boundaries may require data corrections over time.