Author: lonvia
[Added to the original trac issue at 10.09pm, Tuesday, 4th February 2014]

It turns out that the relation for [http://nominatim.openstreetmap.org/details.php?place_id=98156803 Metropolitan France] has inconsistent data because the admin_level has been reduced from 2 to 3. admin_level has been updated to level 3 but rank_address is still at 4. That means that it clashes with the actual country relation for [http://nominatim.openstreetmap.org/details.php?place_id=9157173744 France] in the place_address table overriding it as an address part, so France is no longer an official part of the address. When computing the address details, admin_level is used instead rank_address and then Metropolitan France becomes a state, so that there is no country in the address.

The proper way of fixing would be to replace a place in the placex table when the admin level changes. But in the case of the Metropolitan France relation that means that the entire country gets reindexed which is not really doable. I can neither think of any way to hack the change of the admin level into the placex and place_addressline tables in a way that would actually fix the problem above.

So I'm thinking of doing the replacement in placex and putting a hard limit of around 10000 on the number of [https://github.com/twain47/Nominatim/blob/master/sql/functions.sql#L1955 linked objects to be reindexed]. twain47 any better ideas?

Author: lonvia
[Added to the original trac issue at 10.49am, Saturday, 8th February 2014]

Fixed the admin_level update in [changeset:98b93df/nominatim]. Remains to be seen if poldi can handle the additional load or if the reindexing needs to be restricted further.

As for Metropolitan France: I've manually fixed the search ranks but it is not possible to reindex all of France to fix the addresses. They will sort themselves out with time when the OSM objects are edited for other reasons.

Author: zeenix[at]gmail.com
[Added to the original trac issue at 1.09am, Tuesday, 4th March 2014]

This doesn't seem to be fixed. I still don't get country in address in address for 'Bonneville, Rhne-Alpes' (place id: 97213041):

http://nominatim.openstreetmap.org/search?q=bonneville&limit=10&addressdetails=1&accept-language=fr-FR&format=xml

Author: lonvia
[Added to the original trac issue at 8.21am, Tuesday, 4th March 2014]

As I said, the underlying update problem has been fixed but the data that was already wrong has not been corrected. Recomputing all of France would bring down the server for a day or so. So if you prefer the wording: data-wise it is a won't fix until the next full reimport.

Author: zeenix[at]gmail.com
[Added to the original trac issue at 12.11am, Thursday, 6th March 2014]

Replying to [comment:5 lonvia]:

As I said, the underlying update problem has been fixed but the data that was already wrong has not been corrected. Recomputing all of France would bring down the server for a day or so. So if you prefer the wording: data-wise it is a won't fix until the next full reimport.

When is that going to happen? How do i track this issue (so that we can re-enabled our failing test cases)? Why not keep this open until that is done. If you claim that issue has been fixed why resolve it to 'wontfix'?

Author: lonvia
[Added to the original trac issue at 7.14am, Thursday, 6th March 2014]

This is a bug tracker for the software, not for the contents of the database. I've set it to won't fix now so that people don't keep reopening this bug just because there is still some bad data left.

Reimports happen infrequently, I can't tell you when the next one is going to be and we've never explicitly announced them as they happen without any downtime. If your tests rely on our servers always delivering the same data then you might want to reconsider your test strategy. OSM is a live database with lots of editing happening and breaks like this can happen. If you need the country information, you should use country_code from the address details as a fallback.

Author: zeenix[at]gmail.com
[Added to the original trac issue at 2.24pm, Tuesday, 11th March 2014]

Replying to [comment:7 lonvia]:

This is a bug tracker for the software, not for the contents of the database.

Ah ok, fair enough.

I've set it to won't fix now so that people don't keep reopening this bug just because there is still some bad data left.

I don't think the status/resolution of the bug is about telling people not to reopen it but you can use it however you like.

Reimports happen infrequently, I can't tell you when the next one is going to be and we've never explicitly announced them as they happen without any downtime.

It would be really nice to have a way to track that. I imagine we wont be the only one finding such bugs.

If your tests rely on our servers always delivering the same data then you might want to reconsider your test strategy. OSM is a live database with lots of editing happening and breaks like this can happen.

Its fine for tests to break every now and then and us having to either update our test cases or Nominatim database.

If you need the country information, you should use country_code from the address details as a fallback.

The issue is that we are testing localization in this case and country_code is not localized. Also country name (along with place's name and state etc) is used to create a nice user-friendly name for each search result in geocode-glib. We are also testing that code here. Country name is important here because the same place exists in other countries and this code of ours is therefore supposed to include the country name in the friendly name.

Author: lonvia
[Added to the original trac issue at 7.58am, Wednesday, 12th March 2014]

The localization test does not sound like it makes sense because localization happens on the server side. So, correct localization of the address parts should be tested by Nominatim internally not by your library. You can only test that you send the right parameters to trigger localization. Do that on a simple query like 'France' or 'Paris' and check that you get a different display_name back.

For the tests for user-friendly names, it makes more sense to rely on mock-up answers than fixing your tests every time the Nominatim database changes.