Les fonctions mentionnées ci-dessous sont celles qu'un utilisateur typique de PostGIS Raster sera amené à utiliser et qui sont disponibles dans PostGIS Raster. D'autres fonctions sont également définies, requises en interne pour le support des objets rasters, mais ne sont pas destinées à être utilisées par le grand public.
raster
est un nouveau type PostGIS pour stocker et analyser les données raster.
Pour charger des rasters depuis des fichiers, voir Section 10.1, “Chargement et création de rasters”
Pour les exemples dans cette section, nous utiliserons une table de rasters fictifs, créée via la requête suivante
CREATE TABLE dummy_rast(rid integer, rast raster); INSERT INTO dummy_rast(rid, rast) VALUES (1, ('01' -- little endian (uint8 ndr) || '0000' -- version (uint16 0) || '0000' -- nBands (uint16 0) || '0000000000000040' -- scaleX (float64 2) || '0000000000000840' -- scaleY (float64 3) || '000000000000E03F' -- ipX (float64 0.5) || '000000000000E03F' -- ipY (float64 0.5) || '0000000000000000' -- skewX (float64 0) || '0000000000000000' -- skewY (float64 0) || '00000000' -- SRID (int32 0) || '0A00' -- width (uint16 10) || '1400' -- height (uint16 20) )::raster ), -- Raster: 5 x 5 pixels, 3 bands, PT_8BUI pixel type, NODATA = 0 (2, ('01000003009A9999999999A93F9A9999999999A9BF000000E02B274A' || '41000000007719564100000000000000000000000000000000FFFFFFFF050005000400FDFEFDFEFEFDFEFEFDF9FAFEF' || 'EFCF9FBFDFEFEFDFCFAFEFEFE04004E627AADD16076B4F9FE6370A9F5FE59637AB0E54F58617087040046566487A1506CA2E3FA5A6CAFFBFE4D566DA4CB3E454C5665')::raster);
Cette section liste les types de données PostgreSQL créés pour supporter les fonctionnalités raster.
exclude_nodata_value
vaut false, tous les pixels y compris ceux ayant la valeur nodata
sont considérés comme intersectés et leur valeur sera retournée. Si exclude_nodata_value
n'est pas spécifié, la valeur est lue depuis les méta-données du raster.
NODATA
pour une bande raster spécifiée au pixel donné par columnx et rowy, ou à un point géométrique spécifié dans le même système de référence spatial que le raster.
NODATA
autour du pixel de la bande spécifiée, aux coordonnées spécifiées par columnX & rowY ou par un point géométrique dans le même système de référence spatial que le raster.
crop
is not specified or TRUE, the output raster is cropped. If touched
is set to TRUE, then touched pixels are included, otherwise only if the center of the pixel is in the geometry it is included.
TRUE
si la boite englobante de A intersecte la boite englobante de B.
TRUE
si la boîte englobante de A est à gauche de celle de B.
TRUE
si la boîte englobante de A est à droite de celle de B.
TRUE
si la boîte englobante de A est la même que celle de B. Utilise des boîtes englobantes en double précision.
TRUE
si la boîte englobante de A est contenue dans celle de B. Utilise des boîtes englobantes en double précision.
TRUE
si la boîte de délimitation de A est la même que celle de B.
TRUE
si la boîte englobante de A contient celle de B. Utilise des boîtes englobantes en double précision.
Cette section présente divers pièges et astuces liés à PostGIS raster.
Lorsque GDAL ouvre un fichier, il parcourt l'entièreté du répertoire du fichier pour construire un catalogue d'autres fichiers. Si ce répertoire contient de nombreux fichiers (par exemple des milliers, des millions), l'ouverture de ce fichier devient extrêmement lente (en particulier si ce fichier se trouve sur un lecteur réseau tel que NFS).
Pour contrôler ce comportement, GDAL fournit la variable d'environnement suivante : GDAL_DISABLE_READDIR_ON_OPEN. Définissez GDAL_DISABLE_READDIR_ON_OPEN
à TRUE
pour désactiver l'analyse des répertoires.
Sous Ubuntu (et en supposant que vous utilisez les paquets PostgreSQL pour Ubuntu), GDAL_DISABLE_READDIR_ON_OPEN
peut être défini dans /etc/postgresql/POSTGRESQL_VERSION/CLUSTER_NAME/environment (où POSTGRESQL_VERSION est la version de PostgreSQL, par ex.9.6 et CLUSTER_NAME est le nom du cluster, par exemple maindb). Vous pouvez également définir les variables d'environnement PostGIS ici.
# environment variables for postmaster process
# This file has the same syntax as postgresql.conf:
# VARIABLE = simple_value
# VARIABLE2 = 'any value!'
# I. e. you need to enclose any value which does not only consist of letters,
# numbers, and '-', '_', '.' in single quotes. Shell commands are not
# evaluated.
POSTGIS_GDAL_ENABLED_DRIVERS = 'ENABLE_ALL'
POSTGIS_ENABLE_OUTDB_RASTERS = 1
GDAL_DISABLE_READDIR_ON_OPEN = 'TRUE'
Le nombre maximum de fichiers ouverts autorisé par Linux et PostgreSQL est généralement prudent (typiquement 1024 fichiers ouverts par processus), étant donné l'hypothèse que le système est utilisé par des utilisateurs humains. Pour les rasters Out-DB, une seule requête valide peut facilement dépasser cette limite (par exemple, un jeu de données de 10 ans avec un raster pour chaque jour contenant les températures minimales et maximales et nous voulons connaître les valeurs min et max absolues pour un pixel dans ce jeu de données).
Le changement le plus simple à effectuer est le paramètre suivant de PostgreSQL : max_files_per_process. La valeur par défaut est de 1000, ce qui est beaucoup trop faible pour les données raster Out-DB. Une valeur de départ sûre pourrait être 65536, mais cela dépend vraiment de vos ensembles de données et des requêtes exécutées sur ces ensembles de données. Ce paramètre ne peut être défini qu'au démarrage du serveur et probablement uniquement dans le fichier de configuration de PostgreSQL (par exemple /etc/postgresql/POSTGRESQL_VERSION/CLUSTER_NAME/postgresql.conf dans les environnements Ubuntu).
...
# - Kernel Resource Usage -
max_files_per_process = 65536 # min 25
# (change requires restart)
...
La principale modification à apporter concerne les limites des fichiers ouverts du noyau Linux. Il y a deux parties à cela :
Nombre maximal de fichiers ouverts pour l'ensemble du système
Nombre maximal de fichiers ouverts par processus
L'exemple suivant vous permet de connaître le nombre maximum de fichiers ouverts sur l'ensemble du système :
$ sysctl -a | grep fs.file-max fs.file-max = 131072
Si la valeur retournée n'est pas assez importante, ajoutez un fichier dans /etc/sysctl.d/ comme dans l'exemple suivant :
$ echo "fs.file-max = 6145324" >> /etc/sysctl.d/fs.conf $ cat /etc/sysctl.d/fs.conf fs.file-max = 6145324 $ sysctl -p --system * Applying /etc/sysctl.d/fs.conf ... fs.file-max = 2097152 * Applying /etc/sysctl.conf ... $ sysctl -a | grep fs.file-max fs.file-max = 6145324
Nous devons augmenter le nombre maximum de fichiers ouverts par processus pour les processus du serveur PostgreSQL.
Pour connaître le nombre maximal de fichiers ouverts utilisé par les processus de service PostgreSQL, suivez l'exemple suivant (assurez-vous que PostgreSQL est en cours d'exécution) :
$ ps aux | grep postgres
postgres 31713 0.0 0.4 179012 17564 pts/0 S Dec26 0:03 /home/dustymugs/devel/postgresql/sandbox/10/usr/local/bin/postgres -D /home/dustymugs/devel/postgresql/sandbox/10/pgdata
postgres 31716 0.0 0.8 179776 33632 ? Ss Dec26 0:01 postgres: checkpointer process
postgres 31717 0.0 0.2 179144 9416 ? Ss Dec26 0:05 postgres: writer process
postgres 31718 0.0 0.2 179012 8708 ? Ss Dec26 0:06 postgres: wal writer process
postgres 31719 0.0 0.1 179568 7252 ? Ss Dec26 0:03 postgres: autovacuum launcher process
postgres 31720 0.0 0.1 34228 4124 ? Ss Dec26 0:09 postgres: stats collector process
postgres 31721 0.0 0.1 179308 6052 ? Ss Dec26 0:00 postgres: bgworker: logical replication launcher
$ cat /proc/31718/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 15738 15738 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 15738 15738 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Dans l'exemple ci-dessus, nous avons inspecté la limite des fichiers ouverts pour le processus 31718. Peu importe le processus PostgreSQL, n'importe lequel fera l'affaire. La réponse qui nous intéresse est Max open files.
Nous voulons augmenter Soft Limit et Hard Limit de Max open files pour qu'il soit supérieur à la valeur que nous avons spécifiée pour le paramètre PostgreSQL max_files_per_process
. Dans notre exemple, nous avons fixé max_files_per_process
à 65536.
Sous Ubuntu (et en supposant que vous utilisez les paquets PostgreSQL pour Ubuntu), la façon la plus simple de changer les paramètres Soft Limit et Hard Limit est d'éditer /etc/init.d/postgresql (SysV) ou /lib/systemd/system/postgresql*.service (systemd).
Commençons par le cas de SysV Ubuntu où nous ajoutons ulimit -H -n 262144 et ulimit -n 131072 à /etc/init.d/postgresql.
...
case "$1" in
start|stop|restart|reload)
if [ "$1" = "start" ]; then
create_socket_directory
fi
if [ -z "`pg_lsclusters -h`" ]; then
log_warning_msg 'No PostgreSQL clusters exist; see "man pg_createcluster"'
exit 0
fi
ulimit -H -n 262144
ulimit -n 131072
for v in $versions; do
$1 $v || EXIT=$?
done
exit ${EXIT:-0}
;;
status)
...
Passons maintenant au cas de systemd Ubuntu. Nous ajouterons LimitNOFILE=131072 à chaque fichier /lib/systemd/system/postgresql*.service dans la section [Service].
...
[Service]
LimitNOFILE=131072
...
[Install]
WantedBy=multi-user.target
...
Après avoir effectué les changements nécessaires à systemd, assurez-vous de recharger le démon
systemctl daemon-reload