From OpenStreetMap Wiki
Jump to: navigation, search

One of the simplest ways in which people can help with the development of Nominatim is to provide examples of searches together with the OSM item (node, way, relation) which they would expect the search term to return. It would be helpful if people could group test cases by country to make automated testing easier!

Please note the Name_finder:Abbreviations page for documentation of abbreviations. Please note [1] for general bug reporting. Test cases only.

For Example:


48°42'42N, 10°42'42E an other common conversions



  • Vestergade, København -> way 1700503 (iD, JOSM, Potlatch2, history, XML) -- Its seems that Nominatim ignores the "København" query part. I have to include "Vesterbro" in the query to get the expected result.



For several months most villages in the region of Cantabria, in Spain, are associated with the Basque village of La Arena. For example, if we look "Reinosa" we see the result:

 Reinosa, La Arena, Cantabria, 39200, Spain, Europe

When right is:

 Reinosa, Cantabria, 39200, Spain, Europe

The origin of the problem was an incorrect labeling of the locality "La Arena" as place=county which I corrected long ago. However as we see in Nominatim this relation has not been eliminated from the index and this error keeps appearing in searches (La Arena is still parent of most of Cantabria [2]).

I believe that this mistake can be the causer of whom cities as Bilbao, in the Basque Country, appear in Cantabria [3]. --Tony Rotondas 16:12, 29 June 2011 (BST)

It´s tagged as building = dormitory, but in the search results it appears as "yes".



  • Ille-et-Vilaine, Bretagne -> relation 7465
    This département (adminlevel=6) is currently located incorrectly in the region (admin_level=4) "Pays de la Loire", instead of "Bretagne" (even though the region itself is tagged). This affects then all other cities (e.g. Rennes, the main city of Bretagne, tagged as its admin_center, is located in Pays de la Loire) and subdivisions of this department (the 3 arrondissements of the department, the EPCI's...).
    The bug is apparently caused by the fact that there's not an exact inclusion of the department within the region (whose stored geometry is still missing some details that still need to be fixed: a long task to perform and that has to be checked several times, for example when new islands are added, or coastal details are edited and added locally).
    In that case (absence of a strict inclusion), Nominatim attempts to locate the region according to the "nearest" feature, by computing a distance (from centroïds ?) and finds that the centroïd of Ille-et-Vilaine (near Rennes) is nearer from the centroïd of "Pays de la Loire" (near Angers), than from the centroïd of "Bretagne" (about midway between Carhaix-Plougher and Ploermel). The difference of these distance is very close (a few kilometers), but still "Pays de la Loire" wins.
    Nominatim should better solve the problem of absence of a strict inclusion by computing the surface of intersection between the candidate boundaries, in order to select the region that has the largest intersection (in this case, he would find absolutely NO intersection between Ille-et-Vilaine and Pays de la Loire, or something very near 0 km², if there are small artefacts).
    This problem could have been solved by making sure that ALL parts of an administrative subdivision are listed in the containing subdivision. But in this case, this concerns small islands (or islets and rocks) that may be added at any time in the smaller area, but still not reported in the larger one (due to server load problems, it may be difficult to add it immediately, as the larger region has a lot of defining ways and nodes). This problem can also occur when a smaller subdivision details some small enclaves from another similar subdivision that does not belong to the containing one.
    But may be Nominatim is just currently caching the computed centroids from areas that it has already processed, to save itself from having to cache locally all nodes and ways when it searches for neighboring regions. What it does is an heuristic, not an algorithm, and this causes such errors. Anyway, instead of using centroids in its cache, it could better use the bounding box as an approximation of the area, and would generate much less frequent errors.
    So, in case of doubts about which area contains another one, the containment relations should be logged and verified manually. There are frequent evidences that are easy verifiable by humans, simply by reading the existing tags, even if the exact geometries are not checked (because they are costly in terms of server load when requesting all the nodes and ways, the server may reject the query, or will require you to make smaller requests by loading not all ways and nodes at the same time).
  • Nantes, Loire-Inférieure -> relation 59874
    Loire-Inférieure is the previous name of Loire-Atlantique, and is correctly found as relation 7432, Nantes, Loire-Atlantique is correctly found as relation 59874 but Nantes, Loire-Inférieure is not found.
  • École 42 (or "school 42" or "42, France" or just "42") → relation 3957506





  • Via Garibaldi,Livorno -> way 92241010 (iD, JOSM, Potlatch2, history, XML) -- the name of the way is "Via Giuseppe Garibaldi" where "Giuseppe" is the first name and is usually omitted in a user query.
  • 520, Cannaregio -> node 1068080535 (iD, JOSM, Potlatch2, history, XML) -- Venice addresses should use place:neighbourood or addr:neighbourhood, and not street name (they are uncorrelated). Same thing with "520, Cannaregio, Venezia". Instead of "Quartiere" there should be "Sestiere" (Venice is an unique case?)


  • 福岡 -> node 331385074 (iD, JOSM, Potlatch2, history, XML) -- The English name is "Fukuoka", which does seem to be found. The name tag is "福岡 (Fukuoka)", which is the standard format for Japanese name tags.
  • 親富孝通り -> way 43105756 (iD, JOSM, Potlatch2, history, XML) -- A road in Fukuoka city. The name tag is "親富孝通り (Oyafuko-dori)". The Japanese name consists of 2 "words" ("親富孝/oyafuko" and "通り/dori/street"), with the second "word" being a mixture of kanji ("通/do") and hiragana ("り/ri").



  1. Kraków, D17 -> way 181823531 (iD, JOSM, Potlatch2, history, XML)
  2. Poland, AGH -> way 157902552 (iD, JOSM, Potlatch2, history, XML)
  3. Kraków, AGH -> way 157902552 (iD, JOSM, Potlatch2, history, XML)
  4. AGH -> way 157902552 (iD, JOSM, Potlatch2, history, XML)
  5. AGH, A0 -> {{relation|3111004))
  6. Świętego Idziego, Kraków -> way 201589921 (iD, JOSM, Potlatch2, history, XML)


  • 76, Большая Садовая улица, Ростов-на-Дону -> relation 1084709
  • Тула should _not_ find Tulle, FR (relation 104501


13 Carlos St, Port Of Spain -> way 37412953 (iD, JOSM, Potlatch2, history, XML) -- Way is coming back there is node: node 1318085432 (iD, JOSM, Potlatch2, history, XML) with addr:house=13/addr:street=CARLOS ST/addr:city=PORT OF SPAIN that should have been returned. This consistently does not work in Trinidad but same node structure in Canada does consistently work.