Nominatim geocoder - returns different results for postalcode before vs after city name

[webprogrammierer]

Maybe this is not an issue of geocode-php/nominatim-provider , it maybe an issue of Nominatim itself:

osm-search/Nominatim#2167

But Nominativ has closed the issue instead of solving the problem.

Please check the problem and example on osm-search/Nominatim#2167 and help to solve this problem.

Thank you.

[mtmail]

Nominatim hasn't closed the issue, we locked further comments.

[webprogrammierer]

It is not good to lock further comments. So people see you are not interested in solving it.

[mtmail]

We have received all information needed to investigate the issue. We will update the issue when there is progress.

[jbelien]

Hello @webprogrammierer, thanks for your "issue" but we do not tweak or change results returned by external APIs ; we just process the result returned by the API.

You will need to wait for this "issue" to be "fixed" in Nominatim API itself.

[jbelien]

That being said address parsing is indeed REALLY difficult.

In 9400 Wolfsberg AT or Wolfsberg 9400 AT, the 9400 could be a postal code or a house number ; I'm guessing that's (part of) the reason the result is different.

[webprogrammierer]

House number 9400?
Very funny.

9400 is the right postal code for Wolfsberg. So there is no reason to doubt, no reason for the software to do a second query.

[webprogrammierer]

Hello @webprogrammierer, thanks for your "issue" but we do not tweak or change results returned by external APIs ; we just process the result returned by the API.

You will need to wait for this "issue" to be "fixed" in Nominatim API itself.

I think you did not understand the problem and how it could be solved. There is NO NEED to change results! The only thing to be done is to make correct queries:

You can use the right syntax for the query.
The right syntax is: postalcode after city.

Instead of the free-form queries you can also use "Alternative query string format split into several parameters for structured requests", see here:
https://nominatim.org/release-docs/develop/api/Search/

So you have 2 ways to solve this. That is done in a few minutes and thousands of users will have a solution for a huge problem!

Otherwise if you do not solve the problem, users will use Google API geocoder or other geocoders instead.

So PLEASE rewrite the code and use the correct syntax for Nominatim search queries! So that it will work in all cases not only in some case as it does now.

[jbelien]

House number 9400?
Very funny.

Maybe not in Austria but the goal of Nominatim is to work globally ...

9400 is the right postal code for Wolfsberg. So there is no reason to doubt, no reason for the software to do a second query.

You know that because you're a human with knowledge of postal code in Autria.
Nominatim has to parse a completely random string and "guess" that a number is (or is not) a postal code ; definitely not the same process.

The right syntax is: postalcode after city.

Where does this assessment come from ?
Is there anywhere in Nominatim documentation stating that postal code should go after the city ?

Instead of the free-form queries you can also use "Alternative query string format split into several parameters for structured requests", see here: https://nominatim.org/release-docs/develop/api/Search/

I'm well aware of the structured requests.
I don't have time to improve Nominatim provider at the moment but you're more than welcome to submit a Pull Request.

Otherwise if you do not solve the problem, users will use Google API geocoder or other geocoders instead.

Even though at a personal level (as OSM contributor) I do understand what you're saying, the goal of this project is to provide an easy way to use ANY geocoding API (including Google's API).

[webprogrammierer]

Where does this assessment come from ?

https://nominatim.org/release-docs/develop/api/Search/

street=<housenumber> <streetname>
city=<city>
county=<county>
state=<state>
country=<country>
postalcode=<postalcode>

Postalcode is the last value in the list! You have to keep the order if using a simple query q?=. I takes less than 5 minutes to find that out (order is important if the search is used for geocoding! or use structured query). Test it out and you will be convinced.

... provide an easy way to use ANY geocoding API

The changes in code should be done only here:
https://github.com/geocoder-php/nominatim-provider
where it is not possible to create issues. Therefore the issue was created here.

If you make the changes in Nominatim this will not concern Google API. Why do you write such things if everyone can see how it is.

If there is a problem that concerns millions of people in the world you should be able to find somebody to do this adaptions.

[mtmail]

Postalcode is the last value in the list

In the Nominatim API documentation those are names of URL parameters. They can be in any order. Postalcode being last in the list has no significance. In the value "housenumber streetname" the order can be "streetname housenumber", too.

Nominatim geocoder - returns different results for postalcode before vs after city name - please use correct search syntax

The issue is Nominatim software not interpreting the free form text (address) correctly. I think the git issue here can be closed, it's filed in osm-search/Nominatim#2167 and it will be solved eventually.

But not within the 3 days you mentioned you need a solution. If you see another geocoder API interpreting the address better, every software uses different approaches, complexity and data, it's a good approach to use that geocoder API instead in the meantime.

[jbelien]

In the Nominatim API documentation those are names of URL parameters. They can be in any order. Postalcode being last in the list has no significance. In the value "housenumber streetname" the order can be "streetname housenumber", too.

Thanks @mtmail for confirming what I thought. 👍

---

@webprogrammierer
Please remember that people working on Nominatim or on this project are volunteers. They usually do the work on their free time.
If your problem do not find a solution quick enough, I suggest you submit a PR here to add support for structured requests.

You can also use any other provider ; if you need to use OSM data, there are other providers based on OSM data (Geocode Earth, GraphHopper, Mapbox, OpenCage, Photon, ...).

On a more personal note, using a tone in your message that is a bit less aggressive will probably make people more eager to help you.