|
Right now we are using Bing Map Web Services API for Map/geocoding/reverse geocoing at our application. Our application is installed on premise and so we are evaluating some on premise replacement. Based on current research, OpenStreetMap should be a good candidate for this purpose, however I found out this from OpenStreetMap dowloading data
The file size is quite huge for an on premise installation and plus long time to load data into database. We don't need all layers of the data, just wonder if there is any simple approach we would strip the data to just show the road Map. |
|
The easiest way to slim down OSM data is by region instead of by feature class, so if you can work with e.g. "just Europe" or "just North America" then you'll already save a lot. Pre-filtering by feature is possible (using e.g. the Osmosis or osmfilter tools) but it is not straightforward. Some in-depth knowledge will be required to actually define what exactly you want - these tools don't take "just the road map" for an answer. Does that include the traffic light, the barrier, the turning circle? A typical "tile server" is based on a PostgreSQL database. You could set up a full rendering server on a big machine connected to the Internet, and then export from that a - regional or thematic - subset to deploy on your on-site server. Since the on-site subset wouldn't have to be updatable, this would incur significant space savings. Another option is to pre-produce ready-made map tiles on a big machine and store them on the on-site machine. This works if you only need a regional extract or only a limited amount of detail, e.g. the world down to zoom level 12 or so. 1
Between the unwanted history, type of data, and type of use, you can reduce the needed size drastically. The initial whole-world import takes a lot of time, but keeping it up to date is easyer. Do your initial importing and filtering on a smalish country, like Denmark. You'll be able to iterate faster and get a proper estimate of what you will need once you add France, then Europe, then the rest of the world.
(21 Oct '13, 22:03)
Vincent de P... ♦
thanks, at this point, it won't be on one country. it is the whole world since this would be installed on customer on premise env and we don't know what country they would need
(22 Oct '13, 22:20)
windfly
|
|
The exact space required will vary with what are you import and how you import it. I wouldn't regard the decompressed XML size as too relevant because a) virtually no one decompress the XML for the planet to disk and b) you should use the .pbf formatted data, not the .osm.bz2 formatted data because PBF is a much faster format to process, and smaller too. I've also updated the wiki page with more accurate speeds. If you want to render tiles on-demand with the standard setup you need an osm2pgsql database. I posted two months ago details of the space required. It is possible to run a rendering server off of one 7200 RPM hard drive, but it won't be super-fast. Rendering and geocoding are normally run on separate servers because they need independent databases - a database structured for one is not structured for the other. I don't have the same experience with nominatim as I do with osm2pgsql and rendering, but poldi, the server powering nominatim.osm.org, has a 1TB database. A rendering database takes under a day to import on reasonably powerful hardware. |
|
Hi I solved this and wrote an Medium article how to do this. Hope it will help: https://medium.com/dac-technology-blog/openstreetmap-map-size-reduction-guide-43372bbf38c9 |
