Hacker News Reader

Hacker News

Comment by LordHeini | Hacker News Reader

Full thread

LordHeini

There is another option.

- Get a (cheap) docker capable server.

- Install the OSM/Nominatim stack using docker.

Setting this up used to be a pita, but due to docker its super easy.

This has a couple of benefits.

Like fixed, predicable costs. You can whatever you want without thinking about weird API points which costs a random amount of money. You can serve whatever traffic you want and a cheap v-server gets you an astonishingly long way. There are no 3rd-party privacy issues you can just embed your maps without annoying cookie banners.

View on HN

Before you do this, triple check that that the buildings and addresses for the area you are interested in are actually there (and correct). I've tried to use this approach several times, and at least for Sweden, the results are basically unusable. Hugh amount of missing buildings and missing or incorrect data. Last I tried I think it got something like 20% of my queries correct.

In case others are looking at Nominatim, this is from the Nominatim docs:

"For a full planet import 128GB of RAM or more are strongly recommended. Do not report out of memory problems if you have less than 64GB RAM."

That's ~$150/mo at Hetzner on bare metal, $672/mo at Digital Ocean, starting at $487/mo at AWS. For a non-redundant, low-availability configuration.

I guess this is for type-ahead speed type queries? I found the page: https://nominatim.org/release-docs/latest/admin/Installation...

But it doesn't mention why you need this amount of RAM or how you could opt out of that requirement? i.e., if the queries run directly against the DB w/o indexes, etc. why the high RAM requirement?

AFAIK, a lot of the RAM requirements come from importing and processing the data. It already takes quite a long time and would be even slower without heavily utilizing RAM.

Nominatim also doesn't support any sort of typeahead queries. There's Photon(https://github.com/komoot/photon), which works in concert with Nominatim and is similarly tied to OSM as a data source.

There's also Pelias(https://pelias.io/), an open-source geocoder that handles all types of geocoding in one and supports OSM, OpenAddresses and many other sources (including custom data) out of the box. Admittedly it can have more moving parts as a result, but it can be set up with relatively little RAM if you're careful (I bet a planet install could be done somewhat slowly with 32GB RAM). Full disclosure, I have been a core-maintiner of the project since 2015.

I tried going that route and it unfortunately didn’t work well. At least in Europe OSM is missing a lot of house numbers and even has some larger flaws of missing data / invalid attributed streetnames.

I'm also thinking of trying to set this up. Can you give a specific example? Are these common house numbers?

Unfortunately I don't have any examples at hand right now. What I remember is that in some smaller villages in germany it was missing house numbers and some streets weren't "cut" correctly. So when you had an intersection of Street A and Street B and after the intersection it becomes Street A, sometimes OSM would still name it Street B and therefore all numbers are wrong. This was around 2 years ago so maybe the map data is better now.

Reply on news.ycombinator.com