Nominatim's reverse lookup, given the Eiffel Tower's own coordinates, returns a defibrillator instead

What it covers

Nominatim turns free text into coordinates, and coordinates into addresses. It uses only OpenStreetMap data. A live GET this session to /search?q=Eiffel+Tower&format=jsonv2&limit=1 returned 200 in 0.36 seconds. It gave one result: osm_type way, osm_id 5013364, name "Tour Eiffel", licence "ODbL 1.0".

A follow-up GET to /lookup?osm_ids=W5013364&format=jsonv2 confirmed the same way by its OSM ID. It returned 200 in 1.06 seconds, with a fuller address block: house number, road, district, city, postcode, and country. The address block also carried a man_made field reading "Tour Eiffel".

A third call, to /search?q=Statue+of+Liberty&format=geojson&limit=1, returned 200 in 0.75 seconds as a GeoJSON FeatureCollection. This confirms the third listed format, alongside JSON and XML.

Do not store the place_id from an answer. The public hostname is a pool of separate backends, and each one keeps its own ID space. This session sent five /lookup calls for the same way, 5013364, and read the x-nominatim-server header on each. Four different backends replied and gave four different place_id values: poldi 97838275, longma 98616190, stormfly-04 98183338, and vhagar 97665530. The two calls that landed on longma both returned 98616190, so the value is stable per backend, not random. Use osm_type and osm_id instead. Those matched on all five calls.

No key, but a real usage policy

No key or sign-up was needed for any call this session. This matches the auth: None already on file. Every request carried a descriptive User-Agent naming this research and a contact address. The policy requires a valid User-Agent or Referer that identifies the application. It states plainly that a stock User-Agent from an HTTP library will not do.

The policy, read live at operations.osmfoundation.org/policies/nominatim/, caps the public instance at 1 request per second. It calls that an absolute maximum. This session kept every call at least 1.6 seconds apart.

The policy forbids autocomplete-style querying outright. It restricts bulk geocoding instead of banning it. A smaller one-time bulk task is permitted under extra rules. Those rules allow a single thread on a single machine. A distributed or multi-machine script is not permitted. A script that runs longer than a day is capped at 4 requests per minute.

The policy says the service mainly powers the search bar on openstreetmap.org. It says the service runs on donated servers with very limited capacity. It points larger users first at commercial third-party providers. It points the largest users at running their own Nominatim instance.

No response this session carried a rate-limit header of any kind. A caller has no live signal of how close it is to the cap. The limit lives only in the policy document, not in the API.

Reverse geocoding the tower's own point misses the tower

This session took the Eiffel Tower's own coordinates from the search result above, 48.8582599, 2.2945006. It sent them straight back through /reverse?format=jsonv2. The 200 response, in 1.19 seconds, did not name the tower. It returned osm_type node, osm_id 7992604958, category emergency, type defibrillator, with an empty name field.

A second reverse call, at the same coordinates but with zoom=17 instead of the default zoom=18, changed the answer again. The 200 response, in 0.52 seconds, named a pedestrian street: Avenue Gustave Eiffel, osm_type way, place_rank 26. Neither zoom level returned the tower whose own coordinates were used as input.

Reverse geocoding in Nominatim answers one question: what is registered at this exact point, at this zoom level. It does not answer a different question: what named landmark sits nearest. The tower itself is a way that covers an area, not a single point. A point lookup lands on whatever small feature OpenStreetMap mapped closest to that coordinate. Here that was a defibrillator at zoom 18, and a street at zoom 17. Some callers expect reverse lookup to return the landmark a user tapped on. Those callers should widen the zoom. They can also fall back to a forward search on the name.

Caching is on the caller, and the server does not say for how long

The policy requires callers to cache results on their own side. It warns that a client which repeatedly sends the same query may be classified as faulty and blocked. This session's first search call came back with an Age: 192 header and X-Cache: MISS, HIT. Nominatim's own Varnish front cache had already served that answer 192 seconds earlier. None of the responses this session carried a Cache-Control or Expires header. A caller that follows the policy has to pick its own cache lifetime. The server says to cache results, but not how long a given answer stays valid.

This session did not test one thing: whether the public instance still answers requests that carry no User-Agent at all. Sending one is part of the policy this session followed throughout.