Im Folgenden sind die gebräuchlichsten Funktionen aufgeführt, die zur Zeit durch PostGIS-Raster zur Verfügung gestellt werden. Es gibt noch zusätzliche Funktionen, die zur Unterstützung von Rasterobjekten benötigt werden und für den Anwender nur geringe Bedeutung haben.
raster
ist ein neuer PostGIS Datentyp, der zum Speichern und zur Analyse von Rasterdaten verwendet wird.
Um Raster aus Rasterdateien zu laden, siehe Section 10.1, “Laden und Erstellen von Rastertabellen”
Die Beispiele dieser Referenz benutzen eine Rastertabelle, die mit folgendem Code aus Dummy-Rastern erstellt wurde
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);
Dieser Abschnitt listet die PostgreSQL Datentypen, welche zur Rasterunterstützung angelegt wurden.
exclude_nodata_value
auf FALSE gesetzt ist, werden auch die Pixel mit einem nodata
Wert mit einbezogen. Wenn exclude_nodata_value
nicht übergeben wird, dann wird er über die Metadaten des Rasters ausgelesen.
NODATA
Wert eines bestimmten Pixels aus, das über "columnx" und "rowy" oder durch eine Punktgeometrie - im gleichen Koordinatenreferenzsystem wie der Raster - ausgewählt wird.
NODATA
Werten um ein bestimmtes Pixel herum zusammensetzt. Das Pixel Kann über "columnx" und "rowy" oder über eine Punktgeometrie - im gleichen Koordinatenreferenzsystem wie der Raster - ausgewählt werden.
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
zurück, wenn das umschreibende Rechteck von A das umschreibende Rechteck von B schneidet.
TRUE
zurück, wenn das umschreibende Rechteck von A links von dem von B liegt.
TRUE
zurück, wenn das umschreibende Rechteck von A rechts von dem von B liegt.
TRUE
zurück, wenn die umschreibenden Rechtecke von A und B ident sind. Das umschreibende Rechteck ist in Double Precision.
TRUE
zurück, wenn das umschreibende Rechteck von A in jenem von B enthalten ist. Das umschreibende Rechteck ist in Double Precision.
TRUE
zurück, wenn die bounding box von A ident mit jener von B ist.
TRUE
zurück, wenn das umschreibende Rechteck von A jenes von B enthält. Das umschreibende Rechteck ist in Double Precision.
Dieser Abschnitt beinhaltet verschiedene Gotchas/Fallstricke und Tipps in Bezug auf PostGIS Raster.
Wenn GDAL eine Datei öffnet, dann liest es eifrig das gesamte Verzeichnis in dem sich die Datei befindet um einen Katalog mit den weieren Dateien zu erstellen. Wenn dieses Verzeichnis viele Dateien (z.B.: Tausende, Millionen) enthält, kann das Öffnen dieser Datei extrem lange dauern (insbesondere wenn sich die Datei auf einem Netzlaufwerk, wie einem NFS befindet).
Dieses Verhalten kann durch folgende Umgebungsvariable von GDAL beeinflusst werden: GDAL_DISABLE_READDIR_ON_OPEN. Setzen Sie GDAL_DISABLE_READDIR_ON_OPEN
auf TRUE
um das Scannen von Verzeichnissen zu verhindern.
Auf Ubuntu (angenommen Sie verwenden ein PostgreSQL Paket für Ubuntu), kann GDAL_DISABLE_READDIR_ON_OPEN
in /etc/postgresql/POSTGRESQL_VERSION/CLUSTER_NAME/environment gesetzt werden (wobei POSTGRESQL_VERSION der Version von PostgreSQL entspricht, z.B. 9.6 und CLUSTER_NAME der Bezeichnung des Datenbankclusters, z.B. maindb). Sie können hier ebenso die Umgebungsvariablen von PostGIS setzen.
# 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'
Die Einstellungen von Linux und PostgreSQL bezüglich der maximal erlaubten Anzahl von offenen Dateien sind üblicherweise sehr konservativ (normalerweise 1024 offene Dateien pro Prozess), da sie unter der Annahme getroffen wurden, dass das System von Menschen genutzt wird. Bei Out-DB Rastern kann eine einzelne Abfrage spielend dieses Limit überschreiten (z.B. ein Datensatz mit Rasterwerten über 10 Jahre, wobei ein Raster die Tageswerte der niedrigsten und höchsten Temperaturwerte enthält und wir den absoluten Mindest- und Höchstwert des Datensatzes abfragen wollen).
Am einfachsten kann dies über die PostgreSQL Einstellung max_files_per_process geändert werden. Der Standardwert von 1000 ist für Out-DB Raster viel zu niedrig. Ein zuverlässiger Anfangswert könnte 65536 sein, wobei dies jedoch sehr stark von den verwendeten Datensätzen abhängt und den Abfragen die Sie auf diese ausführen wollen. Diese Einstellung muss vor dem Starten des Servers gesetzt werden und kann vermutlich nur in der Konfigurationsdatei von PostgreSQL (z.B. /etc/postgresql/POSTGRESQL_VERSION/CLUSTER_NAME/postgresql.conf auf Ubuntu) vorgenommen werden.
...
# - Kernel Resource Usage -
max_files_per_process = 65536 # min 25
# (change requires restart)
...
Die wesentliche Änderung muss an den Limits des Linux Kernels für offene Dateien vorgenommen werden. Dies umfasst zwei Teile:
Die maximale Anzahl geöffneter Dateien für das ganze System
Die maximale Anzahl geöffneter Dateien pro Prozess
Das folgende Beispiel zeigt, wie Sie die aktuelle Einstellung zu der maximalen Anzahl geöffneter Dateien für das ganze System anzeigen können:
$ sysctl -a | grep fs.file-max fs.file-max = 131072
Wenn der ausgegebene Wert zu niedrig ist, können Sie wie im folgenden Beispiel gezeigt wird, eine Datei zu /etc/sysctl.d/ hinzufügen:
$ 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
Die maximale Anzahl geöffneter Dateien pro Process für die Serverprozesse von PostgreSQL sollten geändert werden.
Um die maximale Anzahl geöffneter Dateien herauszufinden, welche von den Prozessen des PostgreSQL Dienstes genutzt werden, können Sie folgendes ausführen (stellen Sie sicher, dass PostgreSQL läuft):
$ 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
Im oberen Beispiel haben wir die Limits für geöffnete Dateien für den Prozess 31718 ausgelesen. Es spielt dabei keine Rolle welcher Prozess von PostgreSQL, es genügt jeder. Von Interesse ist dabei die Rückmeldung von Max open files.
Wir wollen das Soft Limit und das Hard Limit für die Max open files so erhöhen, dass sie über dem Wert liegen den wir in der Einstellung von PostgreSQL für max_files_per_process
angegeben haben. In unserem Beispiel haben wir max_files_per_process
mit 65536 angegeben.
Auf Ubuntu (angenommen Sie verwenden ein PostgreSQL Paket für Ubuntu), kann das Soft Limit und das Hard Limit am einfachsten durch editieren von /etc/init.d/postgresql (SysV) oder /lib/systemd/system/postgresql*.service (systemd) geändert werden.
Befassen wir uns zuerst mit dem Fall SysV auf Ubuntu, bei dem wir ulimit -H -n 262144 und ulimit -n 131072 zu /etc/init.d/postgresql hinzufügen.
...
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)
...
Nun der Fall mit systemd unter Ubuntu. Wir fügen LimitNOFILE=131072 in jeder Datei /lib/systemd/system/postgresql*.service in dem Abschnitt [Service] ein.
...
[Service]
LimitNOFILE=131072
...
[Install]
WantedBy=multi-user.target
...
Nach den erforderlichen systemd Änderungen müssen Sie den Dämon neu laden
systemctl daemon-reload