You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: wandsecacher [Submitted to the original trac issue database at 11.15am, Monday, 28th October 2013]
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 "Europischen Union" which is not correct. The translation should be "Europische 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.
The text was updated successfully, but these errors were encountered:
Author: lonvia [Added to the original trac issue at 12.00am, Tuesday, 29th October 2013]
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.
Reporter: wandsecacher
[Submitted to the original trac issue database at 11.15am, Monday, 28th October 2013]
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 "Europischen Union" which is not correct. The translation should be "Europische 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.
The text was updated successfully, but these errors were encountered: