champs-libres/openstreetmap-tile-server
5
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #44 from Istador/master

Browse Source 
README.md consistent indentation and error in docker run command
This commit is contained in:
Alexander Overvoorde 2019-07-10 20:52:59 +02:00 committed by GitHub
commit 4953b4f0c5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 56 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
README.md
View File

@ -11,7 +11,8 @@ First create a Docker volume to hold the PostgreSQL database that will contain t
Next, download an .osm.pbf extract from geofabrik.de for the region that you're interested in. You can then start importing it into PostgreSQL by running a container and mounting the file as `/data.osm.pbf`. For example: Next, download an .osm.pbf extract from geofabrik.de for the region that you're interested in. You can then start importing it into PostgreSQL by running a container and mounting the file as `/data.osm.pbf`. For example:
``` ```
docker run -v /absolute/path/to/luxembourg.osm.pbf:/data.osm.pbf \ docker run \
-v /absolute/path/to/luxembourg.osm.pbf:/data.osm.pbf \
-v openstreetmap-data:/var/lib/postgresql/10/main \ -v openstreetmap-data:/var/lib/postgresql/10/main \
overv/openstreetmap-tile-server \ overv/openstreetmap-tile-server \
import import
@ -24,7 +25,8 @@ If the container exits without errors, then your data has been successfully impo
If your import is an extract of the planet and has polygonal bounds associated with it, like those from geofabrik.de, then it is possible to set your server up for automatic updates. Make sure to reference both the OSM file and the polygon file during the import process to facilitate this: If your import is an extract of the planet and has polygonal bounds associated with it, like those from geofabrik.de, then it is possible to set your server up for automatic updates. Make sure to reference both the OSM file and the polygon file during the import process to facilitate this:
``` ```
docker run -v /absolute/path/to/luxembourg.osm.pbf:/data.osm.pbf \ docker run \
-v /absolute/path/to/luxembourg.osm.pbf:/data.osm.pbf \
-v /absolute/path/to/luxembourg.poly:/data.poly \ -v /absolute/path/to/luxembourg.poly:/data.poly \
-v /openstreetmap-data:/var/lib/postgresql/10/main \ -v /openstreetmap-data:/var/lib/postgresql/10/main \
overv/openstreetmap-tile-server \ overv/openstreetmap-tile-server \
@ -38,7 +40,8 @@ Refer to the section *Automatic updating and tile expiry* to actually enable the
Run the server like this: Run the server like this:
``` ```
docker run -p 80:80 \ docker run \
-p 80:80 \
-v openstreetmap-data:/var/lib/postgresql/10/main \ -v openstreetmap-data:/var/lib/postgresql/10/main \
-d overv/openstreetmap-tile-server \ -d overv/openstreetmap-tile-server \
run run
@ -52,7 +55,8 @@ Tiles that have already been rendered will be stored in `/var/lib/mod_tile`. To
``` ```
docker volume create openstreetmap-rendered-tiles docker volume create openstreetmap-rendered-tiles
docker run -p 80:80 \ docker run \
-p 80:80 \
-v openstreetmap-data:/var/lib/postgresql/10/main \ -v openstreetmap-data:/var/lib/postgresql/10/main \
-v openstreetmap-rendered-tiles:/var/lib/mod_tile \ -v openstreetmap-rendered-tiles:/var/lib/mod_tile \
-d overv/openstreetmap-tile-server \ -d overv/openstreetmap-tile-server \
@ -64,11 +68,12 @@ Tiles that have already been rendered will be stored in `/var/lib/mod_tile`. To
Given that you've specified both the OSM data and polygon as specified in the *Automatic updates* section during server setup, you can enable the updating process by setting the variable `UPDATES` to `enabled`: Given that you've specified both the OSM data and polygon as specified in the *Automatic updates* section during server setup, you can enable the updating process by setting the variable `UPDATES` to `enabled`:
``` ```
docker run -p 80:80 \ docker run \
-p 80:80 \
-e UPDATES=enabled \
-v openstreetmap-data:/var/lib/postgresql/10/main \ -v openstreetmap-data:/var/lib/postgresql/10/main \
-v openstreetmap-rendered-tiles:/var/lib/mod_tile \ -v openstreetmap-rendered-tiles:/var/lib/mod_tile \
-d overv/openstreetmap-tile-server \ -d overv/openstreetmap-tile-server \
-e UPDATES=enabled \
run run
``` ```
@ -82,14 +87,24 @@ Details for update procedure and invoked scripts can be found here [link](https:
The import and tile serving processes use 4 threads by default, but this number can be changed by setting the `THREADS` environment variable. For example: The import and tile serving processes use 4 threads by default, but this number can be changed by setting the `THREADS` environment variable. For example:
``` ```
docker run -p 80:80 -e THREADS=24 -v openstreetmap-data:/var/lib/postgresql/10/main -d overv/openstreetmap-tile-server run docker run \
-p 80:80 \
-e THREADS=24 \
-v openstreetmap-data:/var/lib/postgresql/10/main \
-d overv/openstreetmap-tile-server \
run
``` ```
### AUTOVACUUM ### AUTOVACUUM
The database use the autovacuum feature by default. This behavior can be changed with `AUTOVACUUM` environment variable. For example: The database use the autovacuum feature by default. This behavior can be changed with `AUTOVACUUM` environment variable. For example:
```
docker run -p 80:80 -e AUTOVACUUM=off -v openstreetmap-data:/var/lib/postgresql/10/main -d overv/openstreetmap-tile-server docker run \
-p 80:80 \
-e AUTOVACUUM=off \
-v openstreetmap-data:/var/lib/postgresql/10/main \
-d overv/openstreetmap-tile-server \
run
```
### Benchmarks ### Benchmarks
You can find an example of the import performance to expect with this image on the [OpenStreetMap wiki](https://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks#debian_9_.2F_openstreetmap-tile-server). You can find an example of the import performance to expect with this image on the [OpenStreetMap wiki](https://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks#debian_9_.2F_openstreetmap-tile-server).
@ -99,14 +114,19 @@ You can find an example of the import performance to expect with this image on t
### ERROR: could not resize shared memory segment / No space left on device ### ERROR: could not resize shared memory segment / No space left on device
If you encounter such entries in the log, it will mean that the default shared memory limit (64 MB) is too low for the container and it should be raised: If you encounter such entries in the log, it will mean that the default shared memory limit (64 MB) is too low for the container and it should be raised:
```
renderd[121]: ERROR: failed to render TILE ajt 2 0-3 0-3 renderd[121]: ERROR: failed to render TILE ajt 2 0-3 0-3
renderd[121]: reason: Postgis Plugin: ERROR: could not resize shared memory segment "/PostgreSQL.790133961" to 12615680 bytes: ### No space left on device renderd[121]: reason: Postgis Plugin: ERROR: could not resize shared memory segment "/PostgreSQL.790133961" to 12615680 bytes: ### No space left on device
```
To raise it use `--shm-size` parameter. For example: To raise it use `--shm-size` parameter. For example:
```
docker run -p 80:80 -v openstreetmap-data:/var/lib/postgresql/10/main --shm-size="192m" -d overv/openstreetmap-tile-server run docker run \
-p 80:80 \
-v openstreetmap-data:/var/lib/postgresql/10/main \
--shm-size="192m" \
-d overv/openstreetmap-tile-server \
run
```
For too high values you may notice excessive CPU load and memory usage. It might be that you will have to experimentally find the best values for yourself. For too high values you may notice excessive CPU load and memory usage. It might be that you will have to experimentally find the best values for yourself.
## License ## License