[Geocoding] [OSM-dev] Nominatim and/or a fault-tolerant geocoder

Tue Nov 29 11:51:11 UTC 2016

Hi Sarah and Dmitry,

thanks for your responses! I will definitely investigate into the libpostal project later on as well as some of the geocoders Dmitry suggested.

But right now I’m doing some tests with pg_trgm. And Sarah, I cannot confirm so far your comment

"Trigrams only work with misspellings of a letter or two, they fail
completely when trying to match up abbreviations.“

To me the opposite seems true, as you can see in the following examples. Let’s take this address, as I want to look for it and the way OSM has it stored and spelled.

		(asked address)			(OSM address)
—street: 	Верещагина ул			улица Верещагина
—town:	Ханская ст-ца			Ханская 
—city:	Майкоп г				городской округ Майкоп 
—region:	Адыгея Респ				Адыгея 

The Nominatim standard query is basically this (for the street):

select word_id, word_token, word
from word
where word_token = make_standard_name('Ханская ст-ца')

…and does not return anything.

Now I enabled the extension (CREATE EXTENSION pg_trgm;) and created an index (CREATE INDEX word_token_trgm_idx ON word USING GIST (word_token gist_trgm_ops);) and modified the select slightly:

select word_id, word_token, word, gettokenstring(transliteration(‚Верещагина ул')) as asked, 
	similarity(word_token, gettokenstring(transliteration('Верещагина ул'))) as sml
from word
where word_token % make_standard_name('Верещагина ул')
order by sml desc
limit 20

…and this is the result (I hope the formatting gets through…):

word_id
integerword_token
textword
textasked
textsml
real
19098ul virishchaghinaулица Верещагинаvirishchaghina ul119099ul virishchaghinavirishchaghina ul119100virishchaghinavirishchaghina ul0.8333331525904virishchaghinaВерещагинаvirishchaghina ul0.833333115343ul virishchaghinovirishchaghina ul0.8115342ul virishchaghinoулица Верещагиноvirishchaghina ul0.8568775n virishchaghinaНа Верещагинаvirishchaghina ul0.75568776n virishchaghinavirishchaghina ul0.751256480pl virishchaghinaплощадь Верещагинаvirishchaghina ul0.7142861256481pl virishchaghinavirishchaghina ul0.714286351652virishchaghinВерещагинvirishchaghina ul0.684211351653virishchaghinvirishchaghina ul0.684211217731virishchaghinskaia ulВерещагинская улицаvirishchaghina ul0.666667217732virishchaghinskaia ulvirishchaghina ul0.666667115344virishchaghinovirishchaghina ul0.65824366v v virishchaghinВ.В.Верещагинvirishchaghina ul0.65824367v v virishchaghinvirishchaghina ul0.65855756virishchaghinoВерещагиноvirishchaghina ul0.65721916ur virishchaghinovirishchaghina ul0.636364721915ur virishchaghinoур. Верещагиноvirishchaghina ul0.636364
So the first two answers with a matching of 1 (=100%) are exactly the town I asked for!

The same happens with the town („Ханская ст-ца“ <-> „Ханская“) and with the region („Адыгея Респ“ <-> „Адыгея“). Of course the similarity is not alway 1, but this doesn’t matter, as long as the best match is still my address. And furthermore it tells me how certain the answer is, so I can deal with the information.

What Sarah mentions might apply to the city („Майкоп г“ <-> „городской округ Майкоп“), where the real answer only appears as 23. result with a matching of 40%, after the „best“ (but wrong) match of 70%.

Maybe libpostal could help here, or the OSM data are wrong or the name I asked for. Anyway this would be acceptable because of the huge difference in spelling. It could even be healed with a clever combination of region, city, town and street.

So, in conclusion, to me pg_trgm looks really promising! And the query doesn’t change a lot. Sure, Nominatim would have to deal with the similarity in the response, but this doesn’t seem a huge thing, is it?

Kind regards,

Tom

Am 29.11.2016 um 09:11 schrieb Sarah Hoffmann <lonvia at denofr.de>:

Hi,

On Tue, Nov 29, 2016 at 12:03:35AM +0100, Tom wrote:
> I’m in the quest for a geocoder for OSM that is fault-tolerant in regards of miss-spelled search terms.
> 
> The company I’m working for does different projects for customers in the logistics field. From every customer we receive several hundred thousand address-records, which we have to geocode in order to do different calculations. I started to use Nominatim for that (on an own installation), but it seems that Nominatim has not much of tolerance regarding miss-spelled street and city names. Especially on our last project in Russia it turned out, that street- and city-names often include abbreviations in different ways (like „street“, „str.“, „s“, …). Since we receive the address information from our customers, we have not much influence on the quality of the data. So there are not just these valid abbreviations, but also real spelling errors. Nevertheless we have to geocode as much of these addresses as possible. 
> 
> But right now, Nominatim throws out around 40% of the addresses, not finding anything, although the address is in OSM and could be found (just slightly different spelled). What I would expect is, that a geocoder gives me back some kind of answer for every question I ask, being it an exact match on the city or on the street, or only a „similar“ match. It should tell me if there was no 100%-match, there were several records found, matching my street or my city from e.g. 80% to 50%. So then I can decide later on which records I consider a match and which not. In any case the first row returned should be the best match available.
> 
> So I have a couple of questions here: 
> 
> Does anybody know of a geocoder for OSM-data that does this already? 
> I found besides Nominatim there are several other geocoders. But I cannot test them all. Maybe some work already this way.

As a rule of thumb, the elastic-search-based geocoders do a bit better
for misspelled terms but they are still not ideal because elastic search
is optimised for free text, which has a different distribution of words
than addresses.

> There is a Postgresql-module that seems to do just what I want: pg_trgm. It does not seem like Nominatim uses that right now.
> Is there anybody already working on implementing this (or anything similar)?

Trigrams only work with misspellings of a letter or two, they fail
completely when trying to match up abbreviations.

> If not, I would be willing to invest further time and effort into this, but I need some help on the internals of Nominatim, which I’m not firm with. 
> Where would be the right place to integrate this into Nominatim? 
> Does it make sense to try to put this into Nominatim?
> Or would it be easier to use just osm2psql and build on top of that a new query-interface?

One of the most promising new approaches might be libpostal:
https://github.com/openvenues/libpostal

It's not a geocoder but a library for normalising addresses.
So you would use it to preprocess your address and then geocode
the results with a conventional geocoder. There is a php
library for it, so it would be easy to extend the Nominatim
query interface. Although I would probably rather try photon
as the geocoding backend as it will likely catch a few more
spelling errors.

In any case, I'd be very interested in the results if you
experiment with libpostal and would be happy to take a
pull request for Nominatim.

Kind regards

Sarah

_______________________________________________
Geocoding mailing list
Geocoding at openstreetmap.org
https://lists.openstreetmap.org/listinfo/geocoding

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/geocoding/attachments/20161129/9b159366/attachment-0001.html>