Nominatim integration likely breaches public usage policy and risks service blocking

Summary

Current Nominatim integration likely violates public Nominatim usage policy requirements for identification, acceptable request patterns, and operational safeguards.

Evidence

• Product integration points:
  • src/components/SearchBar.tsx:47 calls Nominatim search directly from client.
  • src/app/page.tsx:176 calls Nominatim reverse geocode on map movement cadence.
  • src/app/api/region-dossier/route.ts:16 calls Nominatim reverse geocode server-side.
• No explicit attribution handling is visible in these call sites.
• No backend proxy-level rate governance is visible for these calls.

Product / ToS links

• Product: https://nominatim.openstreetmap.org
• Usage policy: https://operations.osmfoundation.org/policies/nominatim/
• OSMF Terms of Use reference from policy: https://wiki.osmfoundation.org/wiki/Terms_of_Use

Why this matters

Nominatim public infrastructure has strict limits and usage requirements. Non-compliant clients can be throttled or banned, causing geocoding outages in core UX flows.

Attack or failure scenario

Traffic growth or bot traffic triggers sustained geocoding bursts. Nominatim rate-limits or blocks requests, degrading search and location labeling in production.

Root cause

Nominatim is used as an embedded production dependency without an explicit compliance layer (centralized proxy, enforceable quotas, attribution controls, and provider-switch mechanism).

Recommended fix

1. Move all Nominatim access behind a controlled backend proxy.
2. Enforce global request ceilings per app/user/session.
3. Implement explicit attribution and license compliance checks in UI.
4. Add provider abstraction + fallback to self-hosted/commercial geocoder.
5. Document Nominatim policy compliance and monitor request rates.

Acceptance criteria

• All Nominatim calls are proxied and rate-limited centrally.
• UI shows required attribution in all relevant surfaces.
• Compliance doc maps implementation to Nominatim policy clauses.
• Alerting exists for approaching policy limits.

Suggested labels

• legal
• production-readiness
• reliability
• architecture

Priority

P1 (High)

Severity

High — policy non-compliance can result in immediate service denial from a core data dependency.

Confidence

Likely — direct code evidence confirms usage pattern; formal legal determination needs policy-owner validation.