|
I already asked this over at gis.stackexchange.com, but the response was very little. Also, I think it suits much better here. I'm currently thinking about setting up my own tile server (mapnik, mod_tile, renderd) and geocoder (nominatim) for my application. In short, the application aims to let a user specify his location via address, which is then converted into coordinates. Furthermore, the user is able to create POI. The given address of the POI is also geocoded to acquire the coordinates. The least level of interactiveness required is that the maps is able to display pins of the user location and the location of the POIs. Currently, the app encompasses only one country, Germany. The map doesn't have to be totally up-to-date. I'm still a bit worried that the Nominatim and Map databases impose too much of a burden on the hardware and finally the costs of hosting. So my questions is: Are there any strategies to alleviate the hosting costs like pre-rendering? I just used this tool http://tools.geofabrik.de/calc/ to determine the data size of all tiles in Germany. It seems to be 83GB in total at zoom level 17. Is it viable to pre-render all the tiles up to this zoom level and to do this e.g. once per month for updates? It should make the displaying of maps "free" of hardware after the rendering, or am I wrong? |
|
A Nominatim for Germany can be 50-100GB as well. I don't have a recent installation to check. On a 16core, 48GB RAM, SSD drives it took half a day to create the initial index. I wouldn't attempt the index build with less than 8GB RAM, it might still take several days. During query time Nominatim (or rather PostgreSQL) works best with more RAM, I'd say 4GB and more for Germany. For tiles you have to remember that only a tiny fraction is seen by users. It sounds like such a POI website would need more frequent updates as users/mappers want feedback "has this been added now?" when they come back the next day (or next hour, or check the next 10 minutes). Personally I would concentrate on a static website (hosting cost $0 with github pages or every cheap regardless) and pay of tiles and geocoding. Let others worry about hardware costs, installation and keeping the data (worldwide, minutely) uptodate with OSM. I'm biased, I run a hosted geocoder, and will only point to website listing several geocoder options http://wiki.openstreetmap.org/wiki/Nominatim Thanks for your answer. The problem with most offered geocoders and mapservice is, that they have restrictions in their usage (not allowed to stored coordinates etc. - see Mapbox). I don't think that we would be the primary ressource for mappers to check whether their additions are already visible in our maps and they are also not really the audience we are targeting (needless to say that we still value their work, OSM is an amazing project). So, in the end, I hardly see any other solution than hosting it ourselves, since quotas or restrictions in the ToS force us to do so.
(29 Jan '16, 14:48)
Emtschikay
You choose to save money, that's fine. But I disagree that you're forced to host yourself. Compare how many hours you'll spend installing and administering systems over time. My advice is to build the system using hosted services and only if it gets enough users/traction install your own map tile and geocoding systems. You'll have enough work with the app itself and user registration (users have to agree to the OSM terms of service, save data in their name). It's entirely possible the application won't be used as much as you're planning. Mapbox wasn't listed on the URL I gave in my last answer, others don't have the saving restriction.
(29 Jan '16, 15:10)
mtmail
Yeah, you're probably right. I'!! have a look at the alternarives in your URL. Thanks a lot for your tips!
(29 Jan '16, 18:21)
Emtschikay
OpenCage sure looks nice and simple!
(29 Jan '16, 22:11)
Emtschikay
|
You'll still need to serve the tiles (so hosting costs are always there); the load of running Nominatim and db are negligible, except for the initial import. Also, the biggest storage cost would be for zooms 17+18, but I'd guess that not every of those tiles would be actually requested.
Yes, I'm aware of that, but the computation for rendering the tiles should be gone? On second thought, I'm probably wrong. If I'll prerender all tiles, tiles are rendered that are maybe not even requested. Consequently, rendering on the fly is cheaper in terms of computation of I don't update my data?