I intend to render tiles of a region in advance and serve them statically from a file system. According to http://tools.geofabrik.de/calc/ approximately 30 GB of disk space are required. Does anyone have experience how this would perform?
Regarding the main question: What is the most straightforwarded way to render tiles with default settings of a predefined region? The data split up in regions seems to be available at http://download.geofabrik.de/.
I was indeed aware that the performance would depend on the hardware. However, I lack knowledge whether a file system is suited for a task like this. In the meantime, I have thought of storing the tiles in a database.
I would like to highlight my main question: What is the most straightforwarded way to render tiles with default settings of a predefined region? What software is required and how is it configured? Tiles styled similiar to the ones on https://www.openstreetmap.org/ would be perfectly fine.
I don’t get what do you mean by “default settings” - objects have just tags, not settings, it’s up to style designers to make some settings how to render it and there are multiple styles, both from a visual and technical point of view.
The easiest is always to use some that are ready and are served by someone (usually some carto company), but sometimes it means paying for it when you want to use it on a wider scale than just personal needs.
Hah, store the images in a database? Yes, and where is the database going to store them? You guess it: in a filesystem (unless you are running oracle database on ASM storage). So I see only complication in adding the extra database layer, and no advantage.
from https://github.com/StyXman/osm-tile-tools, which is a heavily modified version of the original one from them old mapnik-stylesheets. It requires a rendering DB as imported with osm2pgsql (which is standard) and the XML Mapnik file. This one you can generate from osm-carto + carto.
It supports various ways to specify the region to render and various output formats, including individual tiles, renderd metatiles and MBT, which are basically SQLite files. If you have more questions about it you can find me in the #osm IRC channel as StyXman.
It is true that a db involves an extra layer, but this format can indeed provide extra performance:
Only one file to open and not one open/close pair of ops per tile.
Reduces internal fragmentation.
If it has some kind of Hillbert-like index and storage, it could retrieve close-by tiles faster on spinny disks.