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

Дмитрий Киселев dmitry.v.kiselev at gmail.com
Mon Nov 28 23:28:00 UTC 2016


Hi Tom.

There is a list of OSM search engines.
http://wiki.openstreetmap.org/wiki/Search_engines
Most of the should have fuzzy search some of them do that better, some of
them - worse.

If you are looking for something what will work for Russia, try:

1. openstreetmap.ru (they have their own geocoder osm2pgsql + some magic
queries + sphynx, it's not open source, but you'll get the vision what you
can achive going osm2pgsql + sphynx way.

2. OSM-Gazetteer - that's my geocoder, since I'm from Russia and made some
trics for russian addresses should works fine. Or you can use it as an OSM
data preprocessor. But you may want more stability and enterprise stuff.

3. Photon, Pelias - they both have fuzzy search capabilities.

Other options from the list may also have fuzzy search, I just haven't
tried them so can't say for sure.

Regards, Dmitry.

2016-11-28 19:03 GMT-04:00 Tom <nominatim at tscholz.net>:

> Hi everybody,
>
> 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:
>
>
>    1. 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.
>
>    2. 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)?
>
>    3. 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.
>       1. Where would be the right place to integrate this into Nominatim?
>       2. Does it make sense to try to put this into Nominatim?
>       3. Or would it be easier to use just osm2psql and build on top of
>       that a new query-interface?
>
>
>
> Thanks a lot for anybody who can help me getting forward with this issue!
>
> Best regards,
>
> Tom
>
>
> PS: I put this on both mailing list, 'dev‘ and 'geocoding', since I’m not
> sure where it suits better. Please excuse me if this is wrong!
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
Thank you for your time. Best regards.
Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20161128/fc1931a0/attachment-0001.html>


More information about the dev mailing list