How to set up an OpenStreetMap server | Hacker News Reader

How to set up an OpenStreetMap server

thinkonbytes.blogspot.com

150 pointsashitlerferad30 comments

Note that there are many different things that people tend to use the term "OpenStreetMap Server" for. What is being described here is what's known as a _tileserver_.

But it's only Europe, without being able to update in real-time and only for serving bitmap tiles. Not much fun (although still useful for lots of use cases).

Sort of off topic but is there a walk through like this for installing and running a server that serves up points of interest within a bounding box?

More generally - I find the OSM community super fragmented - am i missing a well organized inventory of the different open source efforts?

It can be stale or contain weird opinions, but the OSM wiki certainly serves as an adequate inventory (maybe not perfectly organized).

http://wiki.openstreetmap.org/wiki/Software

To your specific question:

https://github.com/twain47/Nominatim#installation

with a viewbox:

http://wiki.openstreetmap.org/wiki/Nominatim#Search

Nice! Some questions: How much time is needed for the import ? How much disk space should the server have ? (120 GB as in the title?) What do you mean by the 1700 in the phrase "1700 is the GB of RAM" ?

Thanks !

> What do you mean by the 1700 in the phrase "1700 is the GB of RAM"

It looks like the 1700 is the Cache size for the command to use in MiB of ram - https://github.com/openstreetmap/osm2pgsql#usage

<cache size> is about 75% of memory in MiB, to a maximum of about 30000. Additional RAM will not be used.

OSM wiki says "XML variant over 666GB uncompressed, 49.1GB bz2 compressed and 31.1GB PBF at 2016-03-20". Not sure where the 120GB comes from.

Maybe because he drops some info from the file (he keeps only the roads) ?

He imports only Europe from geofabrik.de dumps, not whole planet.

A sizable chunk of that is probably database indexes.

I remember having asked once in the osm irc channel on how to setup a private mirror including web service of osm and nobody could answer, telling me that's the first request of that type. It's good to see that there are advances into that direction.

This a tile rendering stack. Similar documentation has been here for years:

https://switch2osm.org/serving-tiles/building-a-tile-server-...

There certainly isn't much documentation about setting up a private editing API, but there is quite a bit of information published in this repo:

https://git.openstreetmap.org/chef.git/

Huh? https://switch2osm.org is many years old and provides exactly that.

I was not referring to using osm. On the contrary, I wanted to be able to provide a working one-to-one copy of the service available at osm.org including all files, databasis and services.

The reason was to make myself more independent of web services.

The switch2osm guides cover what I would call the interesting side of this, primarily the tile server and geocoder. A lot of the other stuff actually depends on external services (the navigation, some of the queries).

If you aren't the nexus of worldwide OpenStreetMap editing (which parts of osm.org are that), there isn't so much reason to run a whole bunch of the stuff. You don't need to support thousands of people making edits, if you aren't capturing edits you don't need a system to replicate them out to data consumers. Etc, etc.

https://github.com/openstreetmap/openstreetmap-website/ a rails app basically and a way to import the planet back into the database (not sure how to do this but I think its possible).

You wont have any of the history, and no users info etc, but you can edit and if you have tile server set up can serve tiles from it as well.

Far better though is to import the data into PostGIS (the rendering database) and edit and add that way with a desktop gis.

I struggled with OSRM on CentOS 7 this morning. So easy on Debian but stxxl and boost woes aplenty.

Likewise, though when I tried a couple of weeks ago my first attempt was on a CentOS 6 VM; now that was painful, little in the way of distro supplied packages, having to workaround outdated dependencies, etc.

CentOS 7 in comparison was much easier, and then, the easiest: upgrading my laptop to Fedora 24 -- tile server basically comes for free, sigh ;-)

a) This is only Europe

b) This is only roads

OSM is global and covers much much more than just roads. As it is this is a clickbait title.

If you want more of its data displayed in client maps, check out http://www.osm2vectortiles.org which is preprocessed data at 50G global. This also has many omissions and as far as I know a limit to detail in terms of your maximum zoom but if roads is all you need this would probably be a much better choice.

There is so much you can put in a title. Calling it as "clickbait" is too much. They are simple instructions to get the maps of a continent online.

> There is so much you can put in a title.

"Your OpenStreetMap server in 120GB" is only 35 characters, out of 80 allowed for the title, so there's plenty of room to be more specific. "Your OpenStreetMap server of Roads in Europe in 120GB" is still only 56/80 and is much more accurate.

HN wants us to use the title of the source. This is the title of the source, and it's not even clickbait.

> HN wants us to use the title of the source. This is the title of the source, and it's not even clickbait.

I never said it was clickbait, that was the GP comment. And if you're going to refer to the guidelines:

"Otherwise please use the original title, unless it is misleading or linkbait."

One could make a reasonable case that the title of the source is misleading because it is incomplete, so the additional specificity may be warranted.

My point is that it's not misleading at all (and thus not clickbait). It doesn't tell the full story, for that you'll have to click it. Most titles on HN don't tell the full story. Many of them could be suffixed with "in America", or "for Mac" or something like that. Yet we don't do that either.

clickbait would be

1) "You'll never believe what we built in only 120GB of Ram" 2) "This is how much RAM you need to run an OSM server" 3) "10 reasons you need this simple piece of technology in your life"

I agree that this is pretty uninteresting and don't know why it got so many upvotes, but it definitely isn't clickbait.

Nope, this is absolutely clickbait akin to pretending 'Wikipedia in 5 megabytes' if you limit that to just pokemon and no images. It gives a false promise.

Even if it were lying outright (and it didn't claim "complete Open Street Maps" or anything akin), it still wouldn't be clickbait. If we want to kill clickbait, we shouldn't overload the term.

"Wikipedia in 5MB" = lie "How small do you think this popular encyclopedia can become? The number will blow your mind" = clickbait

Now we are fighting semantics. I consider lies in titles to be attempts to bait my interest. If they are in link titles, they try to make me click. Thus = clickbait. Not sure how that definition changed after buzzfeed but that's how I 'learned' it many years ago.

It's interesting because MapQuest discontinued their free OpenStreetMap tile server this week, leaving map app developers scrambling to find something else to use.

But if you're not a map app developer or a user of one of the affected maps, then it's probably not interesting.

>clickbait

That word doesn't mean what you think it means.

Reply on news.ycombinator.com