Reverse geocoding wrong state #4995
Comments
|
Author: lonvia If it works on osm.org, there should be no changes necessary but hard to say without knowing more about your installation. Are you using extracts and updates from Geofabrik or a full planet? If you use the 2.0 version of Nominatim, you should do a reimport with the latest code from github. |
|
Author: emilio.mejia[at]gmail.com I use the lastest code from gtihub and extracts updates from Geofabrik with central-america-latest.osm.pbf. |
|
Author: lonvia You can add a single relation with the update script by doing something like: ./utils/update.php --import-relation 3222933 --index The boundary was published in the diff of [http://download.geofabrik.de/central-america-updates/000/000/199.osc.gz Sept 22nd], so it should be there. Could you confirm that the diff was imported without errors? |
|
Author: emilio.mejia[at]gmail.com The diff was imported without error. |
|
Author: lonvia The relation was broken, it did contain one of the boundary ways twice. After [http://www.openstreetmap.org/browse/changeset/18050009 fixing that], the relation imports fine. The osm.org instance happened to import one of the intermediate versions that was ok. Check the other relations for similar duplicates. |
|
Author: emilio.mejia[at]gmail.com Perfect!!! |
Reporter: emilio.mejia[at]gmail.com
[Submitted to the original trac issue database at 9.20am, Wednesday, 25th September 2013]
On my local server the xml result query show wrong state.
Tested:
http://nominatim.openstreetmap.org/reverse?format=xml&lat=10.3116016666667&lon=-84.1814116666667&zoom=18&addressdetails=1
Result: (OK) Alajuela
On my local installation:
http://192.168.1.117/nominatim/reverse?format=xml&lat=10.3116016666667&lon=-84.1814116666667&zoom=18&addressdetails=1
Result: (Wrong) Heredia
The local server is update to : Data: 2013/09/25 19:13 GMT
I need to make some additional changes to my server or in osm?
The text was updated successfully, but these errors were encountered: