Opened 4 years ago

Last modified 3 years ago

#4910 new defect

Edinburgh "EH*" postcode returns London "E*" results

Reported by: mcld Owned by: geocoding@…
Priority: minor Milestone:
Component: nominatim Version:
Keywords: Cc:


I'm using the search box on the OSM homepage. If I type "eh1 3bq" then I get a lot of London results (eg "E1 4UX") which are E not EH. I don't know why it's doing this - the exact postcode I entered is definitely there in OSM! <>

Change History (4)

comment:1 Changed 4 years ago by lonvia

Nominatim is doing some name normalization before looking up UK postcodes which the results in a mismatch. It really should be remembering the unnormalized tokens for future reference but that is not trivial to do in the current implementation.

Last edited 4 years ago by lonvia (previous) (diff)

comment:2 Changed 4 years ago by smsm1

Is it possibly to include the OS CodePoint? Open data for postcodes within the Nominatim search, and return those if there is a match?

comment:3 Changed 4 years ago by lonvia

Nominatim already use external data for UK post codes. It's really just the matching up with that data that goes wrong.

comment:4 Changed 3 years ago by lonvia

I've now normalized the postcodes in the external gb_postcodes table on the instance to alleviate the problem a bit. This is not a full fix but only a temporary hack. The wrong results will still be there but there is a better chance that also some from the right area show up and are ranked higher. Let me know if you see any degradation in search results that previously worked.

Commands used for normalization:

    update gb_postcode set postcode=upper(make_standard_name(postcode));
    select getorcreate_word_id(postcode) from gb_postcode;

Also requires b944e8b/nominatim

Note: See TracTickets for help on using tickets.