# This file defines default environment variables for all images # Layers definition and meta data TILESET_FILE=openmaptiles.yaml # Use 3-part patch version to ignore patch updates, e.g. 7.0.0 TOOLS_VERSION=7.1 # Make sure these values are in sync with the ones in .env-postgres file PGDATABASE=openmaptiles PGUSER=openmaptiles PGPASSWORD=openmaptiles PGHOST=postgres PGPORT=5432 # BBOX may get overwritten by the computed bbox of the specific area: # make generate-bbox-file # By default, the Makefile will use the content of data/$(area).bbox file if it exists. #BBOX=2.255544,49.857797,6.586904,51.389246 #BBOX=2.255544,49.857797,6.586904,51.389246 # Which zooms to generate with make generate-tiles-pg MIN_ZOOM=0 MAX_ZOOM=16 # `MID_ZOOM` setting only works with `make generate-tiles-pg` command. Make sure MID_ZOOM < MAX_ZOOM. # See https://github.com/openmaptiles/openmaptiles-tools/pull/383 # MID_ZOOM=11 # Use true (case sensitive) to allow data updates DIFF_MODE=false # The current setup assumes this file is placed inside the data/ dir MBTILES_FILE=tiles.mbtiles # This is the current repl_config.json location, pre-configured in the tools Dockerfile # Makefile and quickstart replace it with the dynamically generated one, but we keep it here in case some other method is used to run. IMPOSM_CONFIG_FILE=/usr/src/app/config/repl_config.json # Number of parallel processes to use when importing sql files MAX_PARALLEL_PSQL=5 #MAX_PARALLEL_PSQL=16 # Number of concurrent IO ops to use when generating vector map tiles # Set to ridiculous high values for SSD/NVME # Test results: (These were without setting UV_THREADPOOL_SIZE) # 64: ~100/s peak # 256: ~200/s peak, stabilizes to a 50% improvement over 64 concurrency # 1024: ~400/s peak, still at 400/s speed after a few minutes (unlike before, oddly enough) # 4096: ~250/s peak, stabilizes to 200. But it appears to be choking on something, only updates progress periodically # 1024 & 24 Threads: ~700/s peak - drops to 214s after 10mins, 178/s after 15mins. EST after 20min: 23hours # Postgres is mainly idle during all of this (coarse dataset), using only half a core # To be tested if 1 core is dedicated to postgres and the others to tilelive(UV_THREADPOOL_SIZE) # will prove to be more efficient on average. Or just UV_THREADPOOL_SIZE==CPU_THREADS. #COPY_CONCURRENCY=10 COPY_CONCURRENCY=64 #COPY_CONCURRENCY=256 #COPY_CONCURRENCY=512 #COPY_CONCURRENCY=1024 #COPY_CONCURRENCY=4096 #UV_THREADPOOL_SIZE=16 #UV_THREADPOOL_SIZE=24 # Variables for generate tiles using tilelive-pgquery PGHOSTS_LIST=