Nominatim/FAQ
How should I report problems?
For questions about Nominatim please use the Geocoding mailinglist.
Bugs can also be reported in the Github issue tracker. Before reporting any issues, read this FAQ carefully to check that you are not reporting a known problem. Also have a look at the tickets that are already logged to avoid duplicate reports. Please remember that OSM data is user editable - please don't report missing data, instead go and add it!
You can also contact the developers on IRC on channel #osm-nominatim.
How often is the index updated?
Data is imported and indexed as fast as possible. You can find how far behind the service currently is by looking at the lag graph (lag is in minutes)
My data is still missing and it's been several days
Check the date of the latest data refresh at the top of https://nominatim.openstreetmap.org/ as there may be a delay with the refresh. If it's up to date, you can verify if your data has been loaded using the following url
https://nominatim.openstreetmap.org/details?osmtype=[N|W|R]&osmid=<idnumber>
where "N" is node, "W" is way and "R" is relation. For objects with bigint id numbers this will fail with error message "Please select a place id".
If no item is found then your data has not been loaded, please report the problem and the osm id number of the feature using Github
How was the address calculated?
Features down to street level addresses are calculated using a combination of admin boundaries, is_in tags and place features. For building level features addresses are calculated using the address of the most suitable street. If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong!
To see how Nominatim created the full address, with links to the OSM features it used: search for the feature on the Nominatim website and click the small grey 'details' link at the end of the search result you want.
For more details see the Development Overview.
How do I fix the address?
First, it's helpful to get details about how the address was calculated: search for the feature on the Nominatim website and click the small grey 'details' link at the end of the search result you want.
Then, how to fix the address:
of a Building / Amenity / House
If a building has the wrong street either add a addr:street or a associatedStreet relation. This can either be added to the individual address node or the addr:interpolation way.
If a building has the wrong neighborhood, it may be using the closest node available - you can give it better data by adding an appropriate nearby neighborhood node or area.
of a Street / City / County
If a street or higher level feature (city, town, county, etc.) has the wrong address you can either add a is_in tag to provide an explicit address or, preferably, draw a polygon or create an admin boundary relation for the feature that should contain it.
postal codes
Please add missing postal codes as either nodes or (where possible) as polygons.
Why doesn't Nominatim process addr:* tags on buildings
For performance reasons buildings (and other low level features) are not fully indexed, but are instead simply inherit from their parent street. As such many addr:* tags except those directly related to the building are ignored. For instance addr:town=* will never be used - instead the town of the road will be used.
Why wasn't anything found for my search?
There are a number of reasons why no result may have been found:
- There is no data currently in OSM which matches your criteria. Data which you expect to match may be defective in some way. For example, if you search for "Springfield, Massachusetts", it may not be found if the state border has been damaged and no longer encloses Springfield.
- The place is spelled wrongly. The name has to be the same as in the OSM database, Nominatim is not able to correct bad spelling.
- The search query does not use the correct encoding.
My postcode is missing/wrong but I've fixed it in the OSM data. What is wrong?
Support for post codes in Nominatim currently is very primitive. The post codes you see have been computed from OSM data in October 2012 and they are not updated. Postcodes from addr:postcode and similar tags are largely ignored. Please don't report bugs about postcodes. Better support for them is planned and will arrive at some time in the future.
Where have all the place/city/country nodes gone?
The new version of nominatim attempts to merge place nodes and boundary relations to avoid duplication. This is done in 2 ways:
- Using the explicit 'label' and 'admin_centre' relation members for boundary relations
- Using a simple heuristic that looks for a node at the right admin level, name and approximate location
obviously explicit tagging is far better and more accurate. As more data is explicitly tagged we may in future turn off the heuristic approach.
Why is the place I'm looking for not at the top of the list?
Nominatim uses various heuristics to calculate the order to show search results, these include the area of the map you were looking at when you did the search, the 'importance' or a place and how accurately your search string matches the result. Exact matches win over anything else but after that the most significant factor is importance of the returned feature which is calculated either from the tagging (i.e. town, city, country) or preferably from the linked wikipedia article.
If you find a place is not where you expect it to be the simplest way to resolve the problem is usually to add a wikipedia tag to the data in osm.
What tags does Nomination use to generate its searching index?
The tags to be used is configurable. The instance at openstreetmap.org uses the import-extratags.style
Where are the translations of features?
They are is the .yml file of your language in openstreetmap-website/locales under the key geocoder.search_osm_nominatim.prefix.
For example, amenity=airport is translated in Aéroport in french and its translation is in openstreetmap-website/config/locales/fr.yml
In .yml files, keys are hierarchical:
geocoder:
search_osm_nominatim:
prefix:
aeroway:
aerodrome: Aérodrome
How to translate features?
Only with TranslateWiki.net. See openstreetmap-website/config/locales/README
Is there are reason why you see different results when using nominatim.openstreetmap.org and a local Nominatim installation?
There could be a lot of reasons. One of them is that openstreetmap.org is using a different version of Nominatim than the stable release.
If your search is using potential stop words the root cause may be a known issue with stable release 2.5.0 of Nominatim that is described here on github and that you can fix based on the issue's description.
When your problem still persists you should figure out what the difference between the nominatim.openstreetmap.org behaviour and behaviour of own installation of Nominatim is.
The first step is to check if you have the object - that is found in the openstreetmap.org resultset - in your own database. Check out the object details and have a look for the OSM(ID) information like:
OSM: way 50308474
Then try to retrieve this object from your own instance like described above.
If you do not find the object in your database the problem most likely is that you do not have to most current data in your database or you did not import the part of the "planet" where the object resides in. But when the object can be found in your database you should compare the debug-output of both instances by adding the debug=1 parameter to the search-URI of the of the instance. E.g. for the search term "University of Paris Descartes":
- https://nominatim.openstreetmap.org/search.php?q=University+of+Paris+Descartes&debug=1 for nominatim.openstreetmap.org and
- http://<your_instance's_hostname>/nominatim/search.php?q=University+of+Paris+Descartes&debug=1 for your own instance.
By analysing the differences you may be able to figure out what are the differences between the instances in processing the search term.