|
In my installation of Nominatim, reverse queries are showing the wrong city name for numerous locations in the San Francisco Bay Area. However the “official” Nominatim website seems to do it correctly: Shows city as “San Jose” (correct): http://nominatim.openstreetmap.org/reverse?format=json&lat=37.342&lon=-121.886&zoom=&addressdetails=1 Shows city as “Santa Clara” (incorrect): http://osm.ourcast.com/ocreverse.php?lat=37.342&lng=-121.886 Also here is an incorrect street’s details page: http://osm.ourcast.com/details.php?place_id=29332445 I found this question which suggests that I can fix the city names by drawing the city as a relation. But as it is working on the official Nominatim, doesn’t that mean that the correct city boundaries are in the OSM dataset, and my installation is just displaying it incorrectly? https://help.openstreetmap.org/questions/17207/wrong-city-names My nominatim url is here: http://osm.ourcast.com/nominatim.php Any help is greatly appreciated! |
|
The boundary relation for San Jose is broken. You can see a few errors reported by OSM Inspector. Nominatim has a mechanism to keep old versions of boundaries around when it finds a broken one. That is why you see the difference between the osm.org instance and your import. If you have just imported your database, you can get a list of broken polygons under the URL your.instance/polygons.php (you don't seem to have exported that on your instance but it still should be there). This list is not updated when diffs are applied, so the list on osm.org is not really useful at the moment. Once the data is fixed in OSM, things will sort themselves out in Nominatim when diffs are applied. If you don't use diffs, you can also manually reimport the relation with: I'd firstly like to thank the people who have replied thus far! As suggested, I’ve fixed the relation for San Jose and this is now live on OpenStreetMap and has found its way into my instance through the diffs: http://osm.ourcast.com/details.php?osmid=112143&osmtype=R But it does not appear to have solved the problem. I also notice that I don’t get proper place names for Berkeley, even though the Berkeley relation is intact (and always has been). Here are some comparisons between my instance and the official Nominatim instance: Hearst Ave, Berkeley: The city is correctly shown as “Berkeley” in the address, referencing the boundary:administrative for Berkeley http://nominatim.openstreetmap.org/details.php?osmid=207140275&osmtype=W The city is incorrectly shown as “Alameda” in the address, referencing the place:city for Alameda. The boundary:administrative for Berkeley appears there, but is greyed out, and so doesn’t appear in the address returned by the API: http://osm.ourcast.com/details.php?osmid=207140275&osmtype=W The two instances also disagree on the neighbourhood (I don’t know which is correct) but I don’t mind too much about this, as my application doesn’t use neighbourhood. East Saint James St includes the boundary:administrative for San Jose as part of the address: http://nominatim.openstreetmap.org/details.php?osmid=157781928&osmtype=W East Saint James St does not reference the boundary:administrative for San Jose, even though it is now available on the instance: http://osm.ourcast.com/details.php?osmid=157781928&osmtype=W
(21 Nov '13, 07:55)
mparncutt
2
It's possible that Nominatim did not propagate the boundary changes for efficiency reasons. Try to force a reindex on the entire city by running the following command directly on your DB:
(21 Nov '13, 09:22)
lonvia
I don't have that function because I was using Nominatim 2.0.1. I've tried to upgrade to the latest Nominatim from git, but now I have this additional issue when I was trying to import the file as suggested in here: https://github.com/twain47/Nominatim/pull/54#issuecomment-17277092 But I get this error: http://pastebin.com/E7nC0aNg I also seem unable to run updates anymore. It imports 0 nodes/ways/relations each time :(
(22 Nov '13, 05:05)
mparncutt
1
You can't update to 2.1 without a reimport, there have been some other changes to the database schema as well. If you cannot reimport, go back to 2.0.1 and just install the
(23 Nov '13, 11:22)
lonvia
|
You don't need to create this relation, it already exists and also indexed by the official Nominatim instance. I guess your instance did not index this relation and thus provides a less accurate geolocation result. Maybe some problem during the import? Or did you import a dataset which didn't contain relations?
Did you end up finding a solution to this? I'm also having this problem with SF Bay Area.