Opened 5 years ago

Closed 5 years ago

#5022 closed enhancement (fixed)

Old version for relation 2668952 used?

Reported by: wandsecacher Owned by: geocoding@…
Priority: major Milestone:
Component: nominatim Version:
Keywords: Cc:

Description

There seems to be a problem with the German translation for relation http://www.openstreetmap.org/browse/relation/2668952 when Nominatim searches for adresses using German locale in Austria or Germany. Examples are Mozartgasse in Wien (http://nominatim.openstreetmap.org/details.php?place_id=21015925) and Ballindamm in Hamburg (http://nominatim.openstreetmap.org/details.php?place_id=37831114). The translation for the relation of the European Union in German language is always "Europäischen Union" which is not correct. The translation should be "Europäische Union" instead. Some month ago I found this misspelling in name:de in the OSM data and fixed it - but up to now it does not show up in Nominatim searches. The relation 2668952 shows the right translation text in name:de (version 34) but in the place_id http://nominatim.openstreetmap.org/details.php?place_id=3674043432 there is still the old translation (and there are many translations for other languages missing that are available in version 34 of releation 2668952). Is there maybe an outdated cache? For me this is a major topic because users might have the impression that OSM data still are of low quality each time they enter a search. Other users also have detected this behaviour (http://forum.openstreetmap.org/viewtopic.php?id=21370) and other tools like http://www.maposmatic.org/ that are based on Nominatim show the same behaviour, too.

Change History (1)

comment:1 Changed 5 years ago by Sarah Hoffmann

Resolution: fixed
Status: newclosed

Somebody has changed 2668952 into a super relation which is not supported by Nominatim (or osm2pgsql to be more precise) and there is little chance that it ever will. As Nominatim keeps old versions of boundaries around when it finds a broken boundary, your changes never made it into the DB.

I've now manually fixed the name:de tag and taken the relation out of the address computation while I was at it. So the EU part of the addresses will gradually disappear as objects are updated. Hopefully that's the end of this dreadful relation.

Note: See TracTickets for help on using tickets.