Abstract geocoding/map provider layer for swappable backends

[malkoG]

Summary

Introduce a provider abstraction layer for geocoding and map rendering so that backends (Google Places, Naver, Kakao, VWorld/NGII, OSM Nominatim) can be swapped without touching consumer code.

Currently the app uses OSM-based geocoding directly, which has poor data quality for Korean locations (e.g. subway stations labeled as street addresses) and strict rate limits (1 req/sec on public Nominatim). This makes checkin and place search unreliable.

Motivation

• Data quality: Commercial providers (Google, Naver, Kakao) and Korean government APIs (VWorld) have far richer POI/address data than open alternatives
• Flexibility: Different deployments may prefer different providers depending on budget, locale, and self-hosting constraints
• Future-proofing: Provider abstraction makes it safe to switch backends without refactoring consumer code
• Open-source philosophy trade-off: geocoding quality directly affects usability, so pragmatism should win here

Proposed approach

• Define a geocoding provider interface (forward geocode, reverse geocode, place search)
• Define a map renderer interface (static map URL, dynamic map component)
• Implement at least one provider behind the interface (current OSM/Nominatim as default)
• Allow provider selection via environment config

Discussion context

From community feedback:

• Google Places API works well internationally but not as good as Naver/Kakao for Korean POIs
• OSM Nominatim (public) is too rate-limited and data quality is poor for Korea
• Recommendation: Use Google as default worldwide, Naver for Korea-specific. Set a budget limit on Google API usage.
• Map rendering strategy: Use static maps for display, dynamic maps only when editing location — reduces API costs
• Korean government maps (VWorld, NGII): Worth investigating; rich commercial/building data, but may block overseas IPs
• Map libraries vary by provider (Leaflet, MapLibre, OpenLayers) so abstraction won't be perfectly clean, but still worth doing for swappability

Related issues

• Geolocation does not work reliably on mobile devices #106 Geolocation does not work reliably on mobile devices
• Improve place discovery: add OSM POI search and manual lat/lng input #110 Improve place discovery: add OSM POI search and manual lat/lng input
• Consider Photon as alternative geocoding backend #111 Consider Photon as alternative geocoding backend