OSM on own server doesn't match while nominatim.openstreetmap.org does

[Runner-Runner]

I found out that for some places, the osm on our own server doesn't find a match, but when I search with the same search params at nominatim.openstreetmap.org, the correct place is found. Example: http://nominatim.openstreetmap.org/search?&street=&city=Port+d'Andratx&country=Spanien&countrycodes=ES&postalcode=07157&format=json&accept-language=de&addressdetails=1&limit=1

The version we use on our server is 2.0.5. The current version in this branch is, 2.0.7, correct? Might it correct this problem to update to 2.0.7? Which version is running on nominatim.openstreetmap.org? I couldn't find this information.

We got our map data from http://download.geofabrik.de/ (map: europe-latest). Our software data source is https://github.com/twain47/Nominatim.git. We imported via osm2pgsql, update import via osmosis 0.40.1. This script was used for installing: https://github.com/cyclestreets/nominat … ter/run.sh

Are there any configuration settings that might lead to this behavior?

[mtmail]

The current stable release of Nominatim is 2.4.0 (see http://www.nominatim.org/), Osmosis is at 0.44.1 as of May 2015. The Cyclestreets folks are changing their installation script(s) a lot lately because they're setting up a new server so I can't find out which version of the installation script you might have used. The number of changes between 2.0 and 2.4 are too mayor (see release notes on https://github.com/twain47/Nominatim/wiki) and just updating the software isn't enough. You would have to start a full reindexing of the database.

Differences between Nominatim instances are normal. For example one server might update from 2.3.8 to 2.3.9 one month later and all data processed/updated in that month gets handled slightly different.

[lonvia]

There is also occasionally an issue with missing boundary data in extracts. To investigate you can do the following:

1. Search the object in question on nominatim.osm.org and note the osm type and id of the result. Here it would be node 253262105
2. List the details for this object on your server with the following URL: http://yourserver/nominatim/details.php?osmtype=N&osmid=253262105
3. Do the same on nominatim.osm.org

If there is no result on your server, then there is data missing. If the address section misses the postcode, then that is also a problem of missing data in OSM. If other parts of the address section look different then this might indeed be a problem of missing boundaries.

[Runner-Runner]

Thank you for your answers. We will update as soon as possible. I checked both results and they are almost identical. The only difference I see is at some places the type is boundary:administrative at nominatim.osm.org instead of place:. Might this also hint at a problem with the boundaries?

Our server: Port d'Andratx (Type: place:town, node 253262105, 15, 0 GOTO) Andratx (Type: boundary:administrative, relation 347551, 8, 0.0382057837056925 GOTO) Serra de Tramuntana (Type: boundary:administrative, relation 2175756, 7, 0.354076751332997 GOTO) Balearische Inseln (Type: boundary:administrative, relation 348981, 4, 0.522430540503622 GOTO) 07157 (Type: place:postcode, 0 GOTO) Spanien (Type: boundary:administrative, relation 1311341, 2, 0.387379931507353 GOTO) Spanien (territoriale Gewässer) (Type: boundary:administrative, way 46430214, 2, 0.87594788995626 GOTO) es (Type: place:country_code, 0 GOTO)

nominatim.osm.org: Port d'Andratx (Type: place:town, node 253262105, 15, 0 GOTO) Andratx (Type: place:town, relation 347551, 8, 0.0382059063427614 GOTO) Serra de Tramuntana (Type: boundary:administrative, relation 2175756, 7, 0.354076751332876 GOTO) Balearische Inseln (Type: place:archipelago, relation 348981, 4, 0.522430540503644 GOTO) 07157 (Type: place:postcode, 0 GOTO) Spanien (Type: place:country, relation 1311341, 2, 6.4017104440383 GOTO) Spanien (territoriale Gewässer) (Type: boundary:administrative, way 46430214, 2, 0.87594788995626 GOTO) es (Type: place:country_code, 0 GOTO)

[lonvia]

That looks ok. The address parts always point to the same OSM object. Does it work if you leave out the country= parameter?

[Runner-Runner]

No it doesn't work without the country parameter. It does however work when I leave out the postalcode parameter, although it then shows the same postal code in the result.

So search?&street=&city=Port+d'Andratx&country=Spanien&countrycodes=ES&format=json&accept-language=de&addressdetails=1&limit=1

instead of

search?&street=&city=Port+d'Andratx&country=Spanien&countrycodes=ES&postalcode=07157&format=json&accept-language=de&addressdetails=1&limit=1

finds:

[{"place_id":"107592302","licence":"Data \u00a9 OpenStreetMap contributors, ODbL 1.0. http:\/\/www.openstreetmap.org\/copyright","osm_type":"node","osm_id":"253262105","boundingbox":["39.5455474853516","39.5455513000488","2.39116358757019","2.39116382598877"],"lat":"39.5455483","lon":"2.3911636","display_name":"Port d'Andratx, Serra de Tramuntana, Balearische Inseln, 07157, Spanien","class":"place","type":"town","importance":1.1537943348397,"icon":"http:\/\/osm02.onoffice.de\/nominatim\/images\/mapicons\/poi_place_town.p.20.png","address":{"town":"Port d'Andratx","county":"Serra de Tramuntana","state":"Balearische Inseln","postcode":"07157","country":"Spanien","country_code":"es"}}]

[Runner-Runner]

Wow, I just realized that if I use postcode= instead of postalcode=, it finds the correct result. The parameter postalcode has been used by our software for some time and it seems to work for most cases (but obviously not for all). Is postalcode some alternate or deprecated version?

[lonvia]

postalcode is the correct parameter name. postcode is simply ignored, so it's the same as leaving it out all together.

The above suspiciously looks like a bug (or missing feature). I'll have a closer look later.

[Runner-Runner]

Were you able to find out if this behavior might be a bug?

[Runner-Runner]

A server update to a newer version also did not fix this problem. Is there a way to fix this bug?

[lonvia]

This issue likely got fixed with the postcode rewrite. Please open a new bug if you encounter a similar issue.