Search returns no results when postal code is not known in OSM

[jarek]

Canadian postal addresses have a canonical form like "661 University Ave, Toronto, ON, M5G 1M1" (housenumber, street, city, province, postal code). Unfortunately, Canadian postal codes are not open data nor very systematic, and thus difficult to verify and largely untagged.

Searching for an address with the postal code returns no results if the postal code is not tagged: https://nominatim.openstreetmap.org/search?q=661+University+Ave,+Toronto,+ON,+M5G+1M1&format=json&namedetails=1&limit=100&debug=1

Manually removing the postal code gives the expected results: https://nominatim.openstreetmap.org/search?q=661+University+Ave,+Toronto,+ON&format=json&namedetails=1&limit=100&debug=1

(First result I get is https://nominatim.openstreetmap.org/details.php?place_id=51631255 and second https://nominatim.openstreetmap.org/details.php?place_id=25703309 - they are both correct, optimally the order would be flipped, but this can also be improved with better local tagging.)

Is it possible/feasible to ignore parts of the search query when doing so will return a result fully matching the rest of the query? I suppose doing this without breaking other searches would require recognizing which part of the query is the postal code?

[lonvia]

Ignoring is not possible but it is possible to detect unknown postcodes when they follow a well known format.

Needs #1302.

[alexrsagen]

I'd like to offer some input on this, based on the following observations:

• A query against Nominatim for "Lot 8, Jalan Hi-Tech 2/3 Kulim Kedah MY 09000 " returns no results (Nominatim query)
• When querying with the (seemingly correct) postal code, a single result is returned, as expected (Nominatim query)
• Additionally, when excluding the postal code, the same correct result is also returned (Nominatim query)
• Other geocoding engines return the correct place, no matter what postal code is entered. (Google Maps, Apple Maps)

It seems to me that other geocoding engines may not filter results based on the postal code, but instead sort results based on it (most correct result first).

This way we are not ignoring the postal code, but are also not excluding plausible matches.

Could this be a possible resolution to the issue?

Note: The address used as an example is sourced from the IEEE OUI assignments list (~3MB .CSV) and belongs to Intel Corporate.