Chapter 2. PostGIS Installation

Das PostGIS Quellarchiv kann von der Download Webseite https://postgis.net/stuff/postgis-3.6.0dev.tar.gz bezogen werden.

wget https://postgis.net/stuff/postgis-3.6.0dev.tar.gz
tar -xvzf postgis-3.6.0dev.tar.gz
cd postgis-3.6.0dev

Dadurch wird das Verzeichnis postgis-3.6.0dev im aktuellen Arbeitsverzeichnis erzeugt.

Alternativ kann der Quellcode auch von svn repository http://svn.osgeo.org/postgis/trunk/ bezogen werden.

git clone https://git.osgeo.org/gitea/postgis/postgis.git postgis
cd postgis
sh autogen.sh
    

Um die Installation fortzusetzen ist in das neu erstellte Verzeichnis postgis-3.6.0dev zu wechseln.

./configure

Zur Kompilation und Anwendung stellt PostGIS die folgenden Systemanforderungen:

Notwendige Systemvoraussetzungen

Optionale Systemanforderungen

Wie bei den meisten Installationen auf Linux besteht der erste Schritt in der Erstellung eines Makefiles, welches dann zur Kompilation des Quellcodes verwendet wird. Dies wird durch einen Aufruf des Shell Scripts erreicht.

./configure

Ohne zusätzliche Parameter legt dieser Befehl die Komponenten und Bibliotheken fest, welche für die Kompilation des PostGIS Quellcodes auf Ihrem System benötigt werden. Obwohl dies der häufigste Anwendungsfall von ./configure ist, akzeptiert das Skript eine Reihe von Parametern, falls sich die benötigten Bibliotheken und Programme nicht in den Standardverzeichnissen befinden.

Die folgende Liste weist nur die am häufigsten verwendeten Parameter auf. Für eine vollständige Liste benutzen Sie bitte --help oder --help=short .

	Wenn Sie PostGIS vom Code Repository bezogen haben, müssen Sie zu allererst das Skript ausführen ./autogen.sh Dieses Skript erzeugt das configure Skript, welches seinerseits zur Anpassung der Installation von PostGIS eingesetzt wird. Falls Sie stattdessen PostGIS als Tarball vorliegen haben, dann ist es nicht notwendig ./autogen.sh auszuführen, da configure bereits erzeugt wurde.

Sobald das Makefile erzeugt wurde, ist der Build-Prozess für PostGIS so einfach wie

make

Die letzte Zeile der Ausgabe sollte "PostGIS was built successfully. Ready to install." enthalten

Seit PostGIS v1.4.0 haben alle Funktionen Kommentare, welche aus der Dokumentation erstellt werden. Wenn Sie diese Kommentare später in die räumliche Datenbank importieren wollen, können Sie den Befehl ausführen der "docbook" benötigt. Die Dateien "postgis_comments.sql", "raster_comments.sql" und "topology_comments.sql" sind im Ordner "doc" der "tar.gz"-Distribution mit paketiert, weshalb Sie bei einer Installation vom "tar ball" her, die Kommentare nicht selbst erstellen müssen. Die Kommentare werden auch als Teil der Installation "CREATE EXTENSION" angelegt.

make comments

Eingeführt in PostGIS 2.0. Erzeugt HTML-Spickzettel, die als schnelle Referenz oder als Handzettel für Studenten geeignet sind. Dies benötigt xsltproc zur Kompilation und erzeugt 4 Dateien in dem Ordner "doc": topology_cheatsheet.html,tiger_geocoder_cheatsheet.html, raster_cheatsheet.html, postgis_cheatsheet.html

Einige bereits Vorgefertigte können von PostGIS / PostgreSQL Study Guides als HTML oder PDF heruntergeladen werden

make cheatsheets

Die PostGIS Erweiterungen/Extensions werden ab PostgreSQL 9.1+ automatisch kompiliert und installiert.

Wenn Sie aus dem Quell-Repository kompilieren, müssen Sie zuerst die Beschreibung der Funktionen kompilieren. Diese lassen sich kompilieren, wenn Sie docbook installiert haben. Sie können sie aber auch händisch mit folgender Anweisung kompilieren:

make comments

Sie müssen die Kommentare nicht kompilieren, wenn sie von einem Format "tar" weg kompilieren, da diese in der tar-Datei bereits vorkompilierten sind.

Wenn Sie gegen PostgreSQL 9.1 kompilieren, sollten die Erweiterungen automatisch als Teil des Prozesses "make install" kompilieren. Falls notwendig, können Sie auch vom Ordner mit den Erweiterungen aus kompilieren, oder die Dateien auf einen anderen Server kopieren.

cd extensions
cd postgis
make clean
make
export PGUSER=postgres #overwrite psql variables
make check #to test before install
make install
# to test extensions
make check RUNTESTFLAGS=--extension

	make check benutzt psql um Tests auszuführen und kann daher psql Umgebungsvariablen benutzen. Gängige Variablen, die man überschreiben kann, sind PGUSER,PGPORT und PGHOST. Siehe psql Umgebungsvariablen

Die Erweiterungsdateien sind für dieselbe Version von PostGIS immer ident, unabhängig vom Betriebssystem. Somit ist es in Ordnung, die Erweiterungsdateien von einem Betriebssystem auf ein anderes zu kopieren, solange die Binärdateien von PostGIS bereits installiert sind.

Falls Sie die Erweiterungen händisch auf einen anderen Server installieren wollen, müssen sie folgende Dateien aus dem Erweiterungsordner in den Ordner PostgreSQL / share / extension Ihrer PostgreSQL Installation kopieren. Ebenso die benötigten Binärdateien für das reguläre PostGIS, falls sich PostGIS noch nicht auf dem Server befindet.

Sobald Sie das getan haben, sollten Sie postgis, postgis_topology als verfügbare Erweiterungen in PgAdmin sehen -> extensions.

Falls Sie psql verwenden, können Sie die installierten Erweiterungen folgendermaßen abfragen:

SELECT name, default_version,installed_version
FROM pg_available_extensions WHERE name LIKE 'postgis%' or name LIKE 'address%';

             name             | default_version | installed_version
------------------------------+-----------------+-------------------
 address_standardizer         | 3.6.0dev         | 3.6.0dev
 address_standardizer_data_us | 3.6.0dev         | 3.6.0dev
 postgis                      | 3.6.0dev         | 3.6.0dev
 postgis_raster               | 3.6.0dev         | 3.6.0dev
 postgis_sfcgal               | 3.6.0dev         |
 postgis_tiger_geocoder       | 3.6.0dev         | 3.6.0dev
 postgis_topology             | 3.6.0dev         |
(6 rows)

Wenn Sie in der Datenbank, die Sie abfragen, eine Erweiterung installiert haben, dann sehen Sie einen Hinweis in der Spalte installed_version. Wenn Sie keine Datensätze zurückbekommen bedeutet dies, dass Sie überhaupt keine PostGIS Erweiterung auf dem Server installiert haben. PgAdmin III 1.14+ bietet diese Information ebenfalls in der Sparte extensions im Navigationsbaum der Datenbankinstanz an und ermöglicht sogar ein Upgrade oder eine Deinstallation über einen Rechtsklick.

Wenn die Erweiterungen vorhanden sind, können Sie die PostGIS-Extension sowohl mit der erweiterten pgAdmin Oberfläche als auch mittels folgender SQL-Befehle in einer beliebigen Datenbank installieren:

CREATE EXTENSION postgis;
CREATE EXTENSION postgis_raster;
CREATE EXTENSION postgis_sfcgal;
CREATE EXTENSION fuzzystrmatch; --needed for postgis_tiger_geocoder
--optional used by postgis_tiger_geocoder, or can be used standalone
CREATE EXTENSION address_standardizer;
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION postgis_topology;

Sie können psql verwenden, um sich die installierten Versionen und die Datenbankschemen in denen sie installiert sind, anzeigen zu lassen.

\connect mygisdb
\x
\dx postgis*

List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
Name        | postgis
Version     | 3.6.0dev
Schema      | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
Name        | postgis_raster
Version     | 3.0.0dev
Schema      | public
Description | PostGIS raster types and functions
-[ RECORD 3 ]-------------------------------------------------
Name        | postgis_tiger_geocoder
Version     | 3.6.0dev
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name        | postgis_topology
Version     | 3.6.0dev
Schema      | topology
Description | PostGIS topology spatial types and functions

Die Erweiterungstabellen spatial_ref_sys. layer und topology können nicht explizit gesichert werden. Sie können nur mit der entsprechenden postgis oder postgis_topology Erweiterung gesichert werden, was nur geschieht, wenn Sie die ganze Datenbank sichern. Ab PostGIS 2.0.2 werden nur diejenigen Datensätze von SRID beim Backup der Datenbank gesichert, die nicht mit PostGIS paketiert sind. Sie sollten daher keine paketierte SRID ändern und Sie können erwarten, dass Ihre Änderungen gesichert werden. Wenn Sie irgendein Problem finden, reichen Sie bitte ein Ticket ein. Die Struktur der Erweiterungstabellen wird niemals gesichert, da diese mit CREATE EXTENSION erstellt wurde und angenommen wird, dass sie für eine bestimmten Version einer Erweiterung gleich ist. Dieses Verhalten ist in dem aktuellen PostgreSQL Extension Model eingebaut, weshalb wir daran nichts ändern können.

Wenn Sie 3.6.0dev ohne unser wunderbares Extension System installiert haben, können Sie auf erweiterungsbasiert wechseln, indem Sie folgende Befehle ausführen, welche die Funktionen in ihre entsprechenden Erweiterungen paketieren.

CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_raster FROM unpackaged;
CREATE EXTENSION postgis_topology FROM unpackaged;
CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;

Wenn Sie die Kompilation von PostGIS überprüfen wollen:

make check

Obiger Befehl durchläuft mehere Überprüfungen und Regressionstests, indem er die angelegte Bibliothek in einer aktuellen PostgreSQL Datenbank ausführt.

	Falls Sie PostGIS so konfiguriert haben, dass nicht die Standardverzeichnisse für PostgreSQL, GEOS oder Proj4 verwendet werden, kann es sein, dass Sie die Speicherstellen dieser Bibliotheken in der Umgebungsvariablen "LD_LIBRARY_PATH" eintragen müssen.

Zurzeit beruht make check auf die Umgebungsvariablen PATH undPGPORT beim Ausführen der Überprüfungen - es wird nicht die Version von PostgreSQL verwendet, die mit dem Konfigurationsparameter --with-pgconfig angegeben wurde. Daher stellen Sie sicher, dass die Variable PATH mit der während der Konfiguration dedektierten Installation von PostgreSQL übereinstimmt, oder seien Sie auf drohende Kopfschmerzen vorbereitet.

Wenn make check erfolgreich ist, wird die Ausgabe von fast 500 Tests erzeugt. Die Ergebnisse sehen ähnlich aus wie die folgenden (zahlreiche Zeilen wurden weggelassen):

CUnit - A unit testing framework for C - Version 2.1-3
     http://cunit.sourceforge.net/

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     44     44    n/a      0        0
               tests    300    300    300      0        0
             asserts   4215   4215   4215      0      n/a
Elapsed time =    0.229 seconds

        .
        .
        .

Running tests

        .
        .
        .

Run tests: 134
Failed: 0


-- if you build with SFCGAL

        .
        .
        .

Running tests

        .
        .
        .

Run tests: 13
Failed: 0

-- if you built with raster support

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     12     12    n/a      0        0
               tests     65     65     65      0        0
             asserts  45896  45896  45896      0      n/a


        .
        .
        .

Running tests

        .
        .
        .

Run tests: 101
Failed: 0

-- topology regress

.
.
.

Running tests

        .
        .
        .

Run tests: 51
Failed: 0

-- if you built --with-gui, you should see this too

     CUnit - A unit testing framework for C - Version 2.1-2
     http://cunit.sourceforge.net/

        .
        .
        .

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites      2      2    n/a      0        0
               tests      4      4      4      0        0
             asserts      4      4      4      0      n/a

Die Erweiterungen postgis_tiger_geocoder und address_standardizer unterstützen zurzeit nur die standardmäßige Installationsüberprüfung von PostgreSQL. Um diese zu überprüfen siehe unterhalb. Anmerkung: "make install" ist nicht notwendig, wenn Sie bereits ein "make install" im Root des Ordners mit dem PostGIS Quellcode durchgeführt haben.

Für den address_standardizer:

cd extensions/address_standardizer
make install
make installcheck
          

Die Ausgabe sollte folgendermaßen aussehen:

============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries        ==============
test test-init-extensions     ... ok
test test-parseaddress        ... ok
test test-standardize_address_1 ... ok
test test-standardize_address_2 ... ok

=====================
 All 4 tests passed.
=====================

Für den Tiger Geokodierer müssen Sie die Erweiterungen "postgis" und "fuzzystrmatch" in Ihrer PostgreSQL Instanz haben. Die Überprüfungen des "address_standardizer" laufen ebenfalls an, wenn Sie postgis mit "address_standardizer" Unterstützung kompiliert haben:

cd extensions/postgis_tiger_geocoder
make install
make installcheck
          

Die Ausgabe sollte folgendermaßen aussehen:

============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== installing fuzzystrmatch               ==============
CREATE EXTENSION
============== installing postgis                     ==============
CREATE EXTENSION
============== installing postgis_tiger_geocoder      ==============
CREATE EXTENSION
============== installing address_standardizer        ==============
CREATE EXTENSION
============== running regression test queries        ==============
test test-normalize_address   ... ok
test test-pagc_normalize_address ... ok

=====================
All 2 tests passed.
=====================

Um PostGIS zu installieren geben Sie bitte folgendes ein

make install

Dies kopiert die Installationsdateien von PostGIS in das entsprechende Unterverzeichnis, welches durch den Konfigurationsparameter --prefix bestimmt wird. Insbesondere:

Falls Sie zuvor den Befehl make comments ausgeführt haben, um die Dateien postgis_comments.sql und raster_comments.sql anzulegen, können Sie die SQL-Dateien folgendermaßen installieren:

make comments-install

	postgis_comments.sql, raster_comments.sql und topology_comments.sql wurden vom klassischen Build- und Installationsprozess getrennt, da diese mit xsltproc eine zusätzliche Abhängigkeit haben.

Eine von vielen Beschwerden betrifft die Funktion Normalize_Address des Adressennormierers, die eine Adresse vor der Geokodierung vorbereitend standardisiert. Der Normierer ist bei weitem nicht perfekt und der Versuch seine Unvollkommenheit auszubessern nimmt viele Ressourcen in Anspruch. Daher haben wir ein anderes Projekt integriert, welches eine wesentlich bessere Funktionseinheit für den Adressennormierer besitzt. Um diesen neuen Adressennormierer zu nutzen, können Sie die Erweiterung so wie unter Section 2.3, “Installation und Verwendung des Adressennormierers” beschrieben kompilieren und als Extension in Ihrer Datenbank installieren.

Sobald Sie diese Extension in der gleichen Datenbank installieren, in der Sie auch postgis_tiger_geocoder installiert haben, dann können Sie Pagc_Normalize_Address anstatt Normalize_Address verwenden. Diese Erweiterung ist nicht auf Tiger beschränkt, wodurch sie auch mit anderen Datenquellen, wie internationalen Adressen, genutzt werden kann. Die Tiger Geokodierer Extension enthält eine eigenen Versionen von rules table (tiger.pagc_rules), gaz table (tiger.pagc_gaz) und lex table (tiger.pagc_lex). Diese können Sie hinzufügen und aktualisieren, um die Normierung an die eigenen Bedürfnisse anzupassen.

Der Ladeprozess lädt Daten von der Census Webseite für die jeweiligen Nationsdateien und die angeforderten Bundesstaaten herunter, extrahiert die Dateien und lädt anschließlich jeden Bundesstaat in einen eigenen Satz von Bundesstaattabellen. Jede Bundesstaattabelle erbt von den Tabellen im Schema tiger, wodurch es ausreicht nur diese Tabellen abzufragen um auf alle Daten zugreifen zu können. Sie können auch jederzeit Bundesstaattabellen mit Drop_State_Tables_Generate_Script löschen, wenn Sie einen Bundesstaat neu laden müssen oder den Bundesstaat nicht mehr benötigen.

Um Daten laden zu können benötigen Sie folgende Werkzeuge:

Wenn Sie von tiger_2010 aktualisieren, müssen Sie zuerst Drop_Nation_Tables_Generate_Script generieren und ausführen. Bevor Sie die Daten eines Staates laden, müssen Sie die landesweiten Daten laden, was Sie mit Loader_Generate_Nation_Script tun. Dabei wird ein Loader-Skript für Sie generiert. Loader_Generate_Nation_Script ist ein einmaliger Schritt, der für Upgrades (von Tiger-Volkszählungsdaten aus dem Vorjahr) und für Neuinstallationen durchgeführt werden sollte.

Wie ein Skript zum Laden der Daten für Ihre Plattform und für die gewünschten Bundesstaaten generiert werden kann siehe Loader_Generate_Script. Sie können diese stückchenweise installieren. Sie müssen nicht alle benötigten Staaten auf einmal laden. Sie können sie laden wenn Sie diese benötigen.

Nachdem die gewünschten Bundesstaaten geladen wurden, führen Sie so wie unter Install_Missing_Indexes beschrieben

SELECT install_missing_indexes();

aus.

Um zu überprüfen, dass alles funktioniert wie es sollte, können Sie eine Geokodierung über eine Adresse Ihres Staates laufen lassen, indem Sie Geocode verwenden

Aktualisieren Sie zunächst Ihre postgis_tiger_geocoder Erweiterung wie folgt:

ALTER EXTENSION postgis_tiger_geocoder UPDATE;

Anschließend löschen Sie alle "nation"-Tabellen und laden die Neuen. Erstellen Sie ein "drop"-Skript mit den unter Drop_Nation_Tables_Generate_Script beschriebenen SQL-Anweisungen

SELECT drop_nation_tables_generate_script();

Führen Sie die erstellten SQL "drop"-Anweisungen aus.

Die untere SELECT Anweisung erstellt ein Skript zum Laden eines Staates. Details dazu finden Sie unter Loader_Generate_Nation_Script.

Auf Windows:

SELECT loader_generate_nation_script('windows'); 

Auf Unix/Linux:

SELECT loader_generate_nation_script('sh');

Unter Section 2.4.1, “Tiger Geocoder Aktivieren Sie Ihre PostGIS-Datenbank” finden Sie Anweisungen zur Ausführung des Generierungsskripts. Dieser Vorgang muss nur einmal durchgeführt werden.

	Sie können verschiedene Jahrestabellen für die einzelnen Bundesländer verwenden und jedes Bundesland separat aktualisieren. Bevor Sie ein Bundesland aktualisieren, müssen Sie zunächst die Statustabellen des Vorjahres für dieses Bundesland mit Drop_State_Tables_Generate_Script löschen.