Amsterdam is in France

[klokan]

See: http://osmnames.org/#q=amsterdam

Dear Sir or Madam, recently, i found your osmnames.org project in the internet. I wanted to thank you for that project, it helps me a lot. Jet, I might have found a little problem in it. I looked for Amsterdam in your database. And found it with the osm_id... Yet the country_code is france, which must be a mistake. Is there any chance, that could fixe that? sincerely, Erik Radisch

I forgot the geoname-ID in my previous email: 271110

Reported by: erik.radisch@uni-passau.de

[philippks]

The whole Netherlands are actually "part of France" 💩

Just a short investigation:

The problem is, that the relation 47796 only has the admin_level 3. Since its geometrical center seems to be in France and the admin_level is lower, France is determined as parent.

But in OpenStreetMap the the relation 47796 is linked to the relation 2323309 as subarea (which has the admin_level 2). If we consider this attribute when determining linked places, the problem should be solved. (Edit: subarea seems not to be the correct tag since it is used widely...)

The hierarchy could maybe be improved by using the subarea relation member.

[sfkeller]

At least this particular issue could be solved, when - instead of ST_Centroid the admin_centre would be taken if it exists. In this case it's the Node Amsterdam (268396336) as part of this relation http://www.openstreetmap.org/relation/47796 .

[Johanneke]

We are trying to setup an app where we need to lookup countries and continents based on latitude/longitude and I just ran into this issue (Netherlands being part of France) as well. Do you know if this issue exists for other area's? We can't use this if we can't determine country/continent correctly...

[klokan]

@Johanneke these problems were not present in the original data release.
Download TSV from https://github.com/OSMNames/OSMNames/releases/tag/v1.1

Version 2 has a lot of improvements - but unfortunately a lot of bugs too - despite 3 bug fix releases there are still critical bugs introduced as students at HSR have been adding new functionality to the data generator.

@philippks @sfkeller is there one more fix release planned anytime soon?
Bugs like this one are embarrassing.

[philippks]

@klokan you're right, these are terrible bugs.

I believe most critical was a change in the creation of the hierarchy due to better performance and special cases. Unfortunately it did break the quality in some cases.

I have almost no time to invest at the moment but I did a quick revert about this change and am running a new export. Could you @klokan or @MartinMikita review the newest export when it is finished? It should fix this issue and #155 as well.

I can't offer much more right now...

[MartinMikita]

Yes, prepare the draft release, and we will review the changes on our side.

[klokan]

Thank you very much @philippks! We are ready to dig into this on our side too... @jirik

[Johanneke]

Do you know what the ETA on the new release is? The 1.1 version results in a bunch of errors in the klokantech/osmnames-sphinxsearch docker container :-(

[philippks]

@Johanneke I'll upload the new export the next hour. After a review of @MartinMikita it hopefully can be released.

[MartinMikita]

@Johanneke If you want to use OSMNames release 1.1, you need to use older version of osmnames-sphinxsearch, for example the latest supported for OSMNames 1.1 is 1.4 with docker image klokantech/osmnames-sphinxsearch:1.4

[Johanneke]

Thank you so much!

[philippks]

@MartinMikita I uploaded the newest geonames.tsv.gz and created a pre-release v2.0.4. (the housenumbers will follow). Could you have a look?

[MartinMikita]

Thanks a lot, @philippks! We are now indexing this data already, we should know something more in about 1 hour.