Nominatim/TestCases

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 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:

coordinates

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

DA

  • Vestergade, København -> Way 1700503 -- Its seems that Nominatim ignores the "København" query part. I have to include "Vesterbro" in the query to get the expected result.

DE

ES

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)

  • Residencia Universitaria Miguel de Unamuno -> Node 724184816

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

  • Alfons Sola, Caldes Montbui -> Way 108411811 - Names should be splitted around the apostrophe ' character. Contraction of determinants (l', n') and prepositions (d') in french and catalan languages is mandatory most of the times the adjacent word begins (or ends) with a vocal (or h + vocal). Not splitting the tagged names turns a huge amount of items not found. This serious issue had been already reported in trac.osm.org but tickets just fell into oblivion. https://trac.openstreetmap.org/ticket/3604 https://trac.openstreetmap.org/ticket/3961
  • Carrer d'Avelí Xalabarder, Caldes Montbui -> Way 59311053 - Another issue of the catalan language: http://en.wikipedia.org/wiki/Interpunct#Catalan . Most times people don't know the correct spelling of a word when it contains an interpunct. L·L should match either L, LL, or L·L.
  • Llorens Artigas, Caldes Montbui -> Way 111823171 - Another issue of the catalan language: http://en.wikipedia.org/wiki/%C3%87 . Ç can be graphically confused with C and orally confused with S. Therefore Ç should match either Ç, C or S.

FI

FR

  • Ille-et-Vilaine, Bretagne -> Relation 7465 (XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx)
    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).

GB

HR

  • 7 Trg Ivana Kukuljevića, Zagreb -> Node 538819653 -- There is no street with that name, just housenumbers with addr:street=*

IE

IT

  • Via Garibaldi,Livorno -> Way 92241010 -- the name of the way is "Via Giuseppe Garibaldi" where "Giuseppe" is the first name and is usually omitted in a user query.

JA

  • 福岡 -> Node 331385074 -- 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 -- 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").

NL

  • 1 Watermolenpad, Culemborg -> Way 52534995 -- Doesn't use addr:street because street is a Cycleway
  • 8 Standerdmolenpad, Culemborg -> Way 68827966 -- Cycleway problem again
  • 1 Oudaen, Eindhoven -> Way 108007140 -- Search result on openstreetmap.org points at 1 Drakenstein (Way 108007160)

PL

  1. Kraków, D17 -> Way 181823531
  2. Poland, AGH -> Way 157902552
  3. Kraków, AGH -> Way 157902552
  4. AGH -> Way 157902552
  5. AGH, A0 -> {{relation|3111004))
  6. Świętego Idziego, Kraków -> Way 201589921

RU

TT

13 Carlos St, Port Of Spain -> Way 37412953 -- Way is coming back there is node: Node 1318085432 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.

US

  • 2001 North Fuller Avenue, Los Angeles, CA -> Node 421224631
  • 214 Biittig Road, Averill Park, NY US -> Node 1043772820
  • 1005 W Burnside -> Node 392913040 -- it works if you add just about any disambiguation: "St", "OR", "Portland", but without it gives locations in Scotland. Adding "US" as the disambiguation also suggests places in Virginia which are not named Burnside; Adding "USA" or "America" gives no results at all.
  • Hammond, LA -> Node 151337978 -- Spelling out Louisiana gives correct result first, using "LA" finds result in Indiana first

AU