Chapter 2. Installation de PostGIS

Table of Contents

Ce chapitre décrit les étapes nécessaires pour installer PostGIS.

2.1. Version courte

Pour compiler, en supposant que toutes les dépendances soient dans votre chemin de recherche :

tar -xvzf postgis-3.5.0dev.tar.gz
cd postgis-3.5.0dev
./configure
make
make install

Une fois PostGIS installé, il est nécessaire de l'activer (Section 3.3, “Création de bases de données spatiales”) ou de le mettre à jour (Section 3.4, “Mise à jour des bases de données spatiales”) dans chaque base de données où vous voulez l'utiliser.

2.2. Compilation et installation depuis les sources

[Note]

La plupart des systèmes d'exploitation dispose de paquets pré-compilés de PostgreSQL/PostGIS. La compilation est réellement nécessaire uniquement pour disposer des toutes dernières fonctionnalités ou pour les responsables de paquets PostGIS.

Cette section décrit le processus générique de compilation. Si vous compilez pour Windows ou d'autres systèmes d'exploitation, vous trouverez des instructions plus détaillées dans les wiki de la communauté guides de compilation et PostGIS Dev Wiki.

Les paquets pré-compilés pour de multiples systèmes d'exploitation sont listés dans PostGIS Pre-built Packages

Pour les utilisateurs Windows, des versions stables sont disponibles sur Stackbuilder ou sur le site de téléchargement PostGIS Windows. Des compilations expérimentales incluant les dernières fonctionnalités sont disponibles. Ces compilations sont généralement mises à jour une ou deux fois par semaines, ou chaque fois qu'une nouvelle fonctionnalité intéressante est ajoutée. Vous pouvez les utiliser pour suivre l'avancée des versions de PostGIS

Le module PostGIS est une extensions pour le serveur backend PostgreSQL. Par conséquent, PostGIS 3.5.0dev nécessite l'ensemble des entêtes du serveur PostgreSQL pour pouvoir être compilé. PostGIS peut être compilé pour les versions PostgreSQL 12 à 17. Les versions précédentes de PostgreSQL ne sont pas supportées.

Référez-vous aux guides d'installation de PostgreSQL si vous ne l'avez pas encore installé : https://www.postgresql.org .

[Note]

Pour les fonctionnalités de GEOS, quand vous installez PostgreSQL, vous aurez peut-être besoin de lier explicitement PostgreSQL avec la bibliothèque standard C++ :

LDFLAGS=-lstdc++ ./configure [YOUR OPTIONS HERE]

Ceci est une solution de contournement d'exceptions C++ d'interactions bugués dans des outils de développements plus ancien. Si vous tombez sur ce genre de problèmes (backend soudainement fermé ou des choses similaires) essayez cette astuce. Cela nécessite de recompiler votre PostgreSQL du début, bien sur.

Les étapes suivantes résument la configuration et la compilation des sources PostGIS. Elles ont été rédigées pour les utilisateurs sous Linux et ne fonctionneront pas pour Windows et Mac.

2.2.1. Obtenir les Sources

Les sources de PostGIS sont disponible depuis https://postgis.net/stuff/postgis-3.5.0dev.tar.gz

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

Un répertoire appelé postgis-3.5.0dev sera créé dans le répertoire courant.

Les sources peuvent également être obtenues depuis le dépôt git https://git.osgeo.org/gitea/postgis/postgis/ .

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

Se placer dans le nouveau répertoire créé postgis-3.5.0dev pour poursuivre l'installation.

./configure

2.2.2. Pré requis à l'installation

La compilation et l'utilisation de PostGIS nécessitent les éléments suivants :

Obligatoire

  • PostgreSQL 12 - 17. Une installation complète de PostgreSQL (y compris les en-têtes du serveur) est nécessaire. PostgreSQL est disponible à partir de https://www.postgresql.org .

    Pour une matrice complète de compatibilité PostgreSQL/PostGIS et PostGIS/GEOS, référez-vous à https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS

  • Un compilateur GNUC C (gcc). D'autres compilateurs ANSI C peuvent être utilisés, mais la compilation avec gcc est source de moins de problèmes.

  • GNU Make (gmake ou make). Sur beaucoup de systemes, GNU make est la version par défaut de make. Vous pouvez vérifier la version de make avec la commande make -v. D'autres versions de make peuvent ne pas être compatibles avec le Makefile de PostGIS.

  • Proj, bibliothèque de reprojection. Proj 6.1 ou supérieur est nécessaire. La bibliothèque Proj est utilisée pour fournir le support de reprojection de coordonnées dans PostGIS. Proj est disponible au téléchargement depuis https://proj.org/ .

  • La bibliothèque de géométrie GEOS, version 3.8.0 ou supérieure, mais GEOS 3.12+ est nécessaire pour profiter pleinement de toutes les nouvelles fonctions et caractéristiques. GEOS peut être téléchargé à partir de https://libgeos.org .

  • LibXML2, version 2.5.x ou supérieur. LibXML2 est actuellement utilisée dans certaines fonctions d'import (ST_GeomFromGML et ST_GeomFromKML). LibXML2 est disponible au téléchargement depuis https://gitlab.gnome.org/GNOME/libxml2/-/releases.

  • JSON-C, version 0.9 ou supérieure. JSON-C est utilisé pour l'import GeoJSON avec la fonction ST_GeomFromGeoJson. JSON-C est disponible depuis https://github.com/json-c/json-c/releases/.

  • GDAL, version 2+ nécessaire, 3+ de préférence. GDAL est nécessaire pour le support raster. https://gdal.org/download.html.

  • Si vous compilez avec PostgreSQL+JIT, LLVM version >=6 est nécessaire https://trac.osgeo.org/postgis/ticket/4125.

Optionnel

  • GDAL (pseudo optionnel) vous pouvez l'omettre seulement si vous ne voulez pas du support raster. Pensez également à activer les pilotes que vous souhaitez utiliser, comme décrit dans Section 3.2, “Configurer la prise en charge du raster”.

  • GTK (GTK+2.0, 2.8+) pour compiler le chargeur de shape file shp2pgsql-gui. http://www.gtk.org/ .

  • SFCGAL, version 1.3.1 (ou supérieure), 1.4.1 ou supérieure est recommandée et requise pour pouvoir utiliser toutes les fonctionnalités. SFCGAL can be used to provide additional 2D and 3D advanced analysis functions to PostGIS cf Chapter 8, Référence des fonctions SFCGAL. Il permet également d'utiliser SFCGAL plutôt que GEOS pour certaines fonctions 2D fournies par les deux backends (comme ST_Intersection ou ST_Area, par exemple). Une variable de configuration PostgreSQL postgis.backend permet à l'utilisateur final de contrôler quel backend il veut utiliser si SFCGAL est installé (GEOS par défaut). Nota : SFCGAL 1.2 nécessite au minimum CGAL 4.3 et Boost 1.54 (cf : https://sfcgal.org) https://gitlab.com/sfcgal/SFCGAL/.

  • Pour compiler Section 12.1, “Address Standardizer”, vous aurez également besoin de PCRE http://www.pcre.org (qui est généralement déjà installé sur les systèmes nix). Section 12.1, “Address Standardizer” sera automatiquement compilé s'il détecte une bibliothèque PCRE, ou si vous passez un --with-pcre-dir=/path/to/pcre valide pendant la configuration.

  • Pour permettre d'utiliser ST_AsMVT, la bibliothèque protobuf-c 1.1.0 ou supérieur (pour l'utilisation) et le compilateur protoc-c (pour la compilation) sont nécessaires. Également, pkg-config est nécessaire pour vérifier la version minimale correcte de protobuf-c. Voir protobuf-c. Par défaut, PostGIS utilise Wagyu pour valider les polygones MVT plus rapidement, ce qui nécessite un compilateur c++11. Ceci utilisera les CXXFLAGS et le même compilateur que l'installation PostgreSQL. Pour désactiver cela et utiliser GEOS à la place, utilisez la variable --without-wagyu pendant l'étape de configuration.

  • CUnit (CUnit). Nécessaire pour les tests de régression. http://cunit.sourceforge.net/

  • DocBook (xsltproc) est nécessaire pour générer la documentation. Docbook est disponible depuis le site http://www.docbook.org/ .

  • DBLatex (dblatex) est nécessaire pour générer la documentation au format PDF. DBLatex est disponible depuis http://dblatex.sourceforge.net/ .

  • ImageMagick (convert) est nécessaire pour générer les images de la documentation. ImageMagick is available from http://www.imagemagick.org/ .

2.2.3. Configuration de la compilation

Comme pour la plupart des installations linux, la première étape est de générer le Makefile qui sera utilisé pour compiler le code source. Ceci est réalisée en lançant le script shell

./configure

Sans paramètre supplémentaire, cette commande tentera de localiser automatiquement les composants requis et les bibliothèques nécessaires à la compilation de PostGIS. Bien que cela soit l'utilisation la plus commune de la commande ./configure, vous pouvez également ajouter différents paramètres à ce script. Par exemple, vous pouvez définir l'emplacement de bibliothèques ou de programmes si ceux-ci ne sont pas localisés à un emplacement standard.

La liste suivante présente les options les plus courantes. Pour consulter la liste complète utilisez l'option --help ou --help=short.

--with-library-minor-version

À partir de PostGIS 3.0, les fichiers de bibliothèque générés par défaut n'auront plus la version mineur dans le nom de fichier. Ceci signifie que les libs PostGIS 3 se termineront par postgis-3. Ceci a été fait pour faciliter l'usage de pg_upgrade, avec la contrainte que vous ne pouvez installer qu'une seule version de PostGIS 3 sur votre serveur. Pour basculer sur l'ancien comportement et avoir des fichiers qui incluent la version mineure : e.g. postgis-3.0, ajoutez ce paramètre dans la commande de configuration.

--prefix=PREFIX

Cela correspond à l'emplacement où les exécutables et librairies de PostGIS seront installés. Par défaut, cet emplacement est le même que celui de l'installation de PostgreSQL.

[Caution]

Ce paramètre est actuellement défectueux : le paquet s'installe uniquement dans le répertoire d'installation de PostgreSQL. Le suivi de ce bug est disponible depuis http://trac.osgeo.org/postgis/ticket/635 .

--with-pgconfig=FILE

PostgreSQL fournit l'utilitaire pg_config permettant aux extensions comme PostGIS de localiser le répertoire d'installation de PostgreSQL. Utiliser ce paramètre (--with-pgconfig=/path/to/pg_config) pour spécifier une installation particulière de PostgreSQL pour laquelle PostGIS doit être compilée.

--with-gdalconfig=FILE

GDAL, une des bibliothèques requises pour le support des rasters. gdal-config pour permettre au logiciel de localiser le répertoire d'installation de GDAL. Utiliser ce paramètre (--with-gdalconfig=/path/to/gdal-config) pour spécifier un répertoire d'installation particulier de GDAL qui sera utilisé pour compiler PostGIS.

--with-geosconfig=FILE

GEOS, une des bibliothèques requises, fournit un utilitaire appelé geos-config permettant aux logiciels de localiser le répertoire d'installation de GEOS. Utiliser ce paramètre (--with-geosconfig=/path/to/geos-config) pour spécifier le repertoire de GEOS qui sera utilisé pour la compilation de PostGIS.

--with-xml2config=FILE

LibXML est la bibliothèque requise pour les processus GeomFromKML/GML. Elle est normalement trouvée si libxml est installé, mais si ce n'est pas le cas ou si vous souhaitez qu'une version spécifique soit utilisée, vous devrez indiquer à PostGIS un fichier confi xml2-config spécifique pour permettre aux installations logicielles de localiser le répertoire d'installation de LibXML. Utilisez ce paramètre (>--with-xml2config=/path/to/xml2-config) pour spécifier manuellement une installation LibXML particulière avec laquelle PostGIS sera construit.

--with-projdir=DIR

Proj4 est la bibliothèque de reprojection nécessaire à PostGIS. Utilisez ce paramètre (--with-projdir=/path/to/projdir) pour spécifier le répertoire de Proj qui sera utilisé pour la compilation de PostGIS.

--with-libiconv=DIR

Répertoire d'installation d'iconv.

--with-jsondir=DIR

JSON-C est une bibliothèque sous licence MIT utilisée par PostGIS pour les traitements JSON (ST_GeomFromJSON par exemple). Utiliser ce paramètre (--with-jsondir=/path/to/jsondir) pour spécifier le répertoire de JSON-C qui sera utilisé pour la compilation de PostGIS.

--with-pcredir=DIR

PCRE (Perl Compatible Regular Expression) est une bibliothèque sous licence BSD requise par l'extension address_standardizer. Utilisez ce paramètre (--with-pcredir=/chemin/vers/pcredir) pour spécifier un répertoire contenant PCRE qui sera utilisé par PostGIS.

--with-gui

Compile l'interface graphique d'import de données (nécessite GTK+2.0). Ceci créé l'interface graphique shp2pgsql-gui à shp2pgsql.

--without-raster

Compilation sans support des raster.

--without-topology

Désactive le support des topologies. Il n'y a pas de bibliothèque correspondante car toute la logique requise pour les topologies est incluse dans postgis-3.5.0dev.

--with-gettext=no

Par défaut PostGIS tentera de détecter la gestion de gettext et de reposer dessus pour la compilation, cependant si vous tombez sur des problèmes d'incompatibilités qui cause la cassure du chargeur, vous pouvez le désactiver entièrement avec cette commande. Référez vous au ticket http://trac.osgeo.org/postgis/ticket/748 pour un exemple de problème résolu par cette configuration. NOTE : que vous perdez beaucoup de chose en le désactivant. Cela est utilisé pour la gestion de l'aide et des labels internationaux dans le chargeur graphique qui n'est pas documenté et encore expérimental.

--with-sfcgal=PATH

Par défaut, PostGIS ne contiendra pas le support sfcgal sans cet argument. PATH est un argument optionnel permettant de préciser un chemin alternatif vers sfcgal-config.

--without-phony-revision

Désactive la mise à jour de postgis_revision.h à partir du HEAD courant du dépôt git.

[Note]

Si vous avez téléchargé PostGIS depuis le dépôt du code , la première étape est d'exécuter le script

./autogen.sh

Ce script générera le script configure qui est utilisé pour personnaliser votre installation de PostGIS.

Si vous avez obtenu PostGIS comme archive, lancer la commande ./autogen.sh n'est pas nécessaire puisque configure a déjà été généré.

2.2.4. Compiler

Une fois le Makefile généré, compiler PostGIS est aussi simple que lancer

make

La dernière ligne de la sortie doit être "PostGIS was built successfully. Ready to install."

À partir de PostGIS v1.4.0, toutes les fonctions ont leur commentaire généré à partir de la documentation. Si vous souhaitez installer ces commentaires dans votre base de données spatiale plus tard, exécutez la commande suivante, qui nécessite docbook. Les fichiers de commentaires pour PostGIS postgis_comments.sql et pour les autres paquets raster_comments.sql, topology_comments.sql sont aussi inclus dans le paquet tar.gz de la distribution, dans le répertoire doc, il est donc inutile d'utiliser cette commande si vous installez depuis l'archive tar. Les commentaires sont aussi inclus par l'installation via CREATE EXTENSION.

make comments

Introduit dans PostGIS 2.0. Cela génère un mémo en html disponible pour une référence rapide ou pour les étudiants. La compilation nécessite xsltproc et génèrera 4 fichiers dans le répertoire doc topology_cheatsheet.html, tiger_geocoder_cheatsheet.html, raster_cheatsheet.html, postgis_cheatsheet.html

Vous pouvez télécharger des pré-compilations disponibles en HTML et PDF à partir de PostGIS / PostgreSQL Study Guides

make cheatsheets

2.2.5. Compiler les Extensions PostGIS et les déployer

Les extensions PostGIS sont compilées et installées automatiquement si vous utilisez PostgreSQL 9.1+.

Si vous compilez à partir des dépôts des sources, vous devez compiler les descriptions de fonction d'abord. Ceci est compilé si vous avez docbook installé. Vous pouvez également compiler manuellement avec cette commande :

make comments

Compiler les commentaires n'est pas nécessaire si vous avez compilé à partir d'une release d'archive puisque ceux-ci sont des pré-compilations packagés avec le tar ball.

Les extensions devraient être automatiquement compilées lors du make install. Vous pouvez, si nécessaire, compiler à partir des répertoires d'extensions ou copier les fichiers si vous en avez besoin sur un serveur différent.

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
[Note]

make check utilise psql pour faire tourner les tests, et peut donc utiliser les variables d'environnement psql. Les variables classiques utiles à définir sont PGUSER,PGPORT, and PGHOST. Voir variables d'environnement psql

Les fichiers extensions seront toujours les mêmes pour les mêmes versions de PostGIS et PostgreSQL indépendamment de l'OS, par conséquent il n'y a pas de problème à copier les fichiers extensions d'un OS à un autre du moment que vous avez les binaires PostGIS déjà installés sur vos serveurs.

Si vous voulez installer les extensions manuellement sur un serveur différent séparé de votre développement, vous devez copier les fichiers suivants à partir du répertoire extension dans le répertoire PostgreSQL / share / extension de votre installation PostgreSQL ainsi que les binaires nécessaires pour une version correcte de PostGIS si vous ne les avez pas déjà sur le serveur.

  • Ceux-ci sont les fichiers de contrôle qui renvoie les informations telles que la version de l'extension à installer si non spécifié. postgis.control, postgis_topology.control.

  • Tous les fichiers dans le répertoire /sql de chaque extension. Notez que ceux-ci nécessitent d'être copiées à la racine du répertoire share/extension de PostgreSQL extensions/postgis/sql/*.sql, extensions/postgis_topology/sql/*.sql

Une fois que vous avez fait cela, vous devriez voir postgis, postgis_topology comme extensions disponibles dans PgAdmin -> extensions.

Si vous utilisez psql, vous pouvez vérifier que les extensions sont installées en lançant cette requête :

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.5.0dev         | 3.5.0dev
 address_standardizer_data_us | 3.5.0dev         | 3.5.0dev
 postgis                      | 3.5.0dev         | 3.5.0dev
 postgis_raster               | 3.5.0dev         | 3.5.0dev
 postgis_sfcgal               | 3.5.0dev         |
 postgis_tiger_geocoder       | 3.5.0dev         | 3.5.0dev
 postgis_topology             | 3.5.0dev         |
(6 rows)

Si vous avez l'extension installée dans la base de données que vous interrogez, vous verrez la mention dans la colonne installed_version. Si vous n'obtenez aucun enregistrement , cela signifie que vous n'avez pas d'extension postgis installés sur le serveur. PgAdmin III 1.14+ fournira aussi cette information dans la section extensions dans l'arbre de l'explorateur de la base de données et autorisera même la mise à jour ou la désinstallation par clic-droit.

Si vous avez les extensions disponibles, vous pouvez installer les extensions postgis dans votre base de données de votre choix soit en utilisant l'interface d'extension de PgAdmin ou lançant ces commandes SQL :

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;

Avec psql, vous pouvez contrôler les versions installées ainsi que les schémas d'installation.

\connect mygisdb
\x
\dx postgis*
List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
Name        | postgis
Version     | 3.5.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.5.0dev
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name        | postgis_topology
Version     | 3.5.0dev
Schema      | topology
Description | PostGIS topology spatial types and functions
[Warning]

Les tables d'extension spatial_ref_sys, layer, topology ne peuvent pas être explicitement sauvegardées. Elles peuvent être uniquement sauvegardées quand les extensions respectives postgis ou postgis_topology sont sauvegardées, ce qui semble seulement arriver quand vous sauvegardez l'ensemble de la base. À partir de PostGIS 2.0.1, seulement les enregistrements des srid non packagés avec PostGIS sont sauvegardés quand la base de données est sauvegardée. Par conséquent, ne vous attendez pas à ce vos modifications persistent si vous changez les srids que nous fournissons. Créez un ticket si vous trouvez un problème. Les structures des tables d'extensions ne sont jamais sauvegardées puisque créées avec CREATE EXTENSION et sont supposées être identiques à version égale d'une extension. Ce comportement fait partie du modèle actuel d'extensions de PostgreSQL, nous ne pouvons donc rien faire à ce sujet.

Si vous avez installé la version 3.5.0dev sans utiliser le système d'extensions, il est possible de l'activer via les commandes suivantes pour packager les fonctions dans leurs extensions respectives. L'installation via `unpackaged` a été supprimé dans PostgreSQL 13, nous vous invitons donc à basculer sur une installation utilisant le système d'extensions avant de migrer à PostgreSQL 13.

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

2.2.6. Tests

Si vous désirez tester la compilation de PostGIS, lancez

make check

La commande ci-dessus fonctionnera pour différentes tests de vérification et de régression en utilisant la bibliothèque générée selon la base de données actuelle.

[Note]

Si vous avez configuré PostGIS en utilisant un emplacement non standard de PostgreSQL, GEOS, ou Proj4, vous pourrez avoir besoin d'ajouter l'emplacement des bibliothèques à la variable d'environnement LD_LIBRARY_PATH.

[Caution]

Pour le moment, make check repose sur les variables d'environnement PATH et PGPORT lors de la réalisation des vérifications - il n'utilise pas la version de PostgreSQL qui a pu être définie en utilisant la paramètre de configuration --with-pgconfig. Assurez vous donc de modifier votre PATH pour correspondre l'installation de PostgreSQL détectée durant la configuration ou préparez vous à gérer des maux de tête à venir.

Si réussi, make check sortira les résultats de près de 500 tests. Les résultats seront similaires à la sortie ci-dessous (avec de nombreuses lignes omises) :

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

Les extensions postgis_tiger_geocoder et address_standardizer ne supportent actuellement que l'installcheck de PostgreSQL. Pour les tester, cf ci-dessous. Note : Il n'est pas nécessaire de lancer make install si cette commande a déjà été lancée dans le répertoire racine des sources PostGIS.

Pour l'extension address_standardize :

cd extensions/address_standardizer
make install
make installcheck
          

La sortie de la commande devrait ressembler à :

============== 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.
=====================

Le géocodeur tiger nécessite d'avoir les extensions postgis et fuzzystrmatch installée sur l'instance PostgreSQL. Les tests de l'extension address_standardizer seront lancés si PostGIS est compilé avec le support address_standardizer :

cd extensions/postgis_tiger_geocoder
make install
make installcheck
          

La sortie de la commande devrait ressembler à :

============== 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.
=====================

2.2.7. Installation

Pour installer PostGIS, entrez

make install

Ceci copiera les fichiers d'installation de PostGIS dans leur sous-répertoires appropriés définis par le paramètre de configuration --prefix. En particulier :

  • Les binaires du chargeur et du dumper sont installés dans [prefix]/bin.

  • Les fichiers SQL, tel que postgis.sql, sont installé dans [prefix]/share/contrib.

  • Les bibliothèques PostGIS sont installées dans [prefix]/lib.

Si vous avez déjà lancé la commande make comments pour générer les fichiers postgis_comments.sql, raster_comments.sql, installer le fichier sql en lançant

make comments-install

[Note]

postgis_comments.sql, raster_comments.sql, topology_comments.sql ont été séparés de la compilation initiale et des cibles de l'installation depuis qu'ils sont dépendant de xsltproc.

2.3. Installation et utilisation de l'extension address standardize

L'extension address_standardizer était précédemment livrée sous forme d'un paquet séparé nécessitant son propre téléchargement. Depuis la version 2.2 de PostGIS, cette extension est intégrée. Pour de plus amples informations sur cette extension, sa configuration, son utilisation, se référer à Section 12.1, “Address Standardizer”.

Ce normalisateur d'adresses peut être utilisé avec l'extension PostGIS tiger en remplacement de Normalize_Address. Se référer à la page Section 2.4.2, “Utilisation de l'Extension Address Standardizer avec le Geocodeur Tiger” pour mettre en place ce remplacement. Il peut également être utilisé pour fabriquer son propre géocodeur ou pour normaliser des adresses pour les comparer plus facilement.

Le normalisateur d'adresses se base sur PCRE, généralement installé sur les systèmes Nix. Il peut également être téléchargé ici : http://www.pcre.org. Durant la phase Section 2.2.3, “Configuration de la compilation”, si PCRE est détecté, le normalisateur d'adresses sera automatiquement compilé. Pour utiliser une installation personnalisée de PCRE, passer le paramètre --with-pcredir=/chemin/vers/pcre dans la commande configure, où /chemin/vers/pcre est le répertoire contenant les sous-répertoires pcre include et lib.

Pour les utilisateurs de Windows®, les versions 2.1 et supérieures de PostGIS sont livrées avec l'extension address_standardizer. Il n'est donc pas besoin de compiler cette extension. La commande CREATE EXTENSION suffit.

Une fois installée, vous pouvez vous connecter à votre base de données et lancer le SQL :

CREATE EXTENSION address_standardizer;

Le test suivant ne nécessite pas de table rules, gas, ou lex

SELECT num, street, city, state, zip
 FROM parse_address('1 Devonshire Place PH301, Boston, MA 02109');

La sortie de la commande devrait ressembler à

num |         street         |  city  | state |  zip
-----+------------------------+--------+-------+-------
 1   | Devonshire Place PH301 | Boston | MA    | 02109

2.4. Installation, mise à jour et chargement de données pour le géocodeur Tiger

L'extension géocodeur Tiger peut ne pas être distribué avec votre installation de PostGIS. Si vous n'avez pas l'extension géocodeur Tiger, ou si vous souhaitez utiliser une version plus récente de celle de votre installation, vous pouvez utiliser les fichiers share/extension/postgis_tiger_geocoder.* depuis les paquets disponibles à Windows Unreleased Versions, dans la section pour votre version de PostgreSQL. Même si ces paquets sont pour Windows, les fichiers d'extension postgis_tiger_geocoder fonctionneront quel que soit votre système d'exploitation car c'est une extension en SQL/plpgsql.

2.4.1. Tiger Geocoder Activation de votre base de données PostGIS

  1. Ces instructions supposent que l'extension postgis_tiger_geocoder soit déjà installée dans votre installation PostgreSQL.

  2. Connectez-vous à la base de données avec psql ou PgAdmin (ou tout autre client) et lancez la commande SQL suivante. Note : Si l'installation se déroule sur une base de données contenant déjà PostGIS, la première étape n'est pas nécessaire. Si l'extension fuzzystrmatch est déjà installée, la seconde étape n'est pas nécessaire non plus.

    CREATE EXTENSION postgis;
    CREATE EXTENSION fuzzystrmatch;
    CREATE EXTENSION postgis_tiger_geocoder;
    --this one is optional if you want to use the rules based standardizer (pagc_normalize_address)
    CREATE EXTENSION address_standardizer;

    Si l'extension postgis_tiger_geocoder est déjà installée et que vous souhaitez la mettre à jour, lancez :

    ALTER EXTENSION postgis UPDATE;
    ALTER EXTENSION postgis_tiger_geocoder UPDATE;

    Si vous avez modifié tiger.loader_platform ou tiger.loader_variables, vous devrez peut être les mettre à jour.

  3. Pour tester l'installation, lancez cette commande SQL sur la base de données :

    SELECT na.address, na.streetname,na.streettypeabbrev, na.zip
            FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;

    Qui devrait afficher

    address | streetname | streettypeabbrev |  zip
    ---------+------------+------------------+-------
               1 | Devonshire | Pl               | 02109
  4. Créez un nouvel enregistrement dans la table tiger.loader_platform contenant les chemins vers les exécutables et le serveur.

    Par exemple, pour créer un profil nommé debbie suivant la convention sh, vous feriez :

    INSERT INTO tiger.loader_platform(os, declare_sect, pgbin, wget, unzip_command, psql, path_sep,
                       loader, environ_set_command, county_process_command)
    SELECT 'debbie', declare_sect, pgbin, wget, unzip_command, psql, path_sep,
               loader, environ_set_command, county_process_command
      FROM tiger.loader_platform
      WHERE os = 'sh';

    Et modifiez les chemins dans la colonne declare_sect pour les faire correspondre aux chemins des programmes pg, unzip, shp2pgsql, psql, etc. sur le serveur Debbie.

    Si vous ne modifiez pas la table loader_platform, elle contiendra des chemins par défaut pour les programmes, et vous aurez à modifier les scripts après leur génération.

  5. Depuis PostGIS 2.4.1, le chargement des données de "ZIP Code Tabulation Area" zcta5 a été modifié pour charger les données actuelles zcta5, celui-ci est inclus dans Loader_Generate_Nation_Script si activé. Le chargement est désactivé par défaut car cela prend du temps (20 à 60 minutes), occupe de l'espace disque, et n'est pas souvent utile.

    Pour l'activer, exécutez :

    UPDATE tiger.loader_lookuptables SET load = true WHERE table_name = 'zcta520';

    Si disponible, la fonction Geocode peut l'utiliser lorsqu'un filtre de frontière est utilisé avec des codes zips. La fonction Reverse_Geocode l'utilise si l'adresse retournée n'a pas de code zip, ce qui arrive souvent avec le géocodage inverse sur des autoroutes.

  6. Créez un répertoire nommé gisdata à la racine du serveur ou de la machine locale si le réseau entre les deux est suffisamment rapide. Ce répertoire contiendra les fichiers tiger téléchargés et traités. Pour changer ce répertoire, modifier le champ staging_fold dans la table tiger.loader_variables.

  7. Créez un répertoire nommé temp dans le répertoire gisdata (ou dans le répertoire que vous avez configuré dans le champ staging_fold). Ce répertoire contiendra les données tiger extraites.

  8. Puis exécutez la fonction SQL Loader_Generate_Nation_Script, pour vous assurer que votre libellé de profil personnalisé est utilisé, et sauvegardez le script dans un fichier .sh ou .bat. Par exemple pour générer le script de chargement d'une nation :

    psql -c "SELECT Loader_Generate_Nation_Script('debbie')" -d geocoder -tA > /gisdata/nation_script_load.sh
  9. Exécutez en ligne de commande les scripts de chargement précédemment générés.

    cd /gisdata
    sh nation_script_load.sh
  10. Lorsque vous avez terminé d'exécuter les scripts, vous devriez avoir trois tables dans votre schéma tiger_data, avec des données déjà remplies. Vous pouvez confirmer cela avec les requêtes suivantes, à exécuter dans psql ou pgAdmn

    SELECT count(*) FROM tiger_data.county_all;
    count
    -------
      3235
    (1 row)
    SELECT count(*) FROM tiger_data.state_all;
    count
    -------
        56
    (1 row)
    

    Celle-ci n'aura des données que si vous avez spécifié le chargement de zcta5

    SELECT count(*) FROM tiger_data.zcta5_all;
    count
    -------
      33931
    (1 row)
    
  11. Par défaut, les tables correspondant à bg, tract, tabblock20 ne sont pas chargées. Ces tables ne sont pas utilisées par le géocodeur, mais sont typiquement utilisées pour les statistiques de population. Si vous souhaitez charger ces données lors du chargement des états, exécutez la requête suivante.

    UPDATE tiger.loader_lookuptables SET load = true WHERE load = false AND lookup_name IN('tract', 'bg', 'tabblock20');

    Autrement, il est possible de charger juste ces tables après le chargement des données sur les états en utilisant le Loader_Generate_Census_Script

  12. Pour chaque état dont vous voulez charger les données, générez un script d'état Loader_Generate_Script.

    [Warning]

    NE GÉNÉREZ PAS le script d'état avant d'avoir chargé les données de nation, car le script d'état utilise la liste des comtés chargés par le script de nation.

  13. psql -c "SELECT Loader_Generate_Script(ARRAY['MA'], 'debbie')" -d geocoder -tA > /gisdata/ma_load.sh
  14. Lancez alors les lignes de commande générées.

    cd /gisdata
    sh ma_load.sh
  15. Après le chargement des données, ou lors d'une pause dans le chargement, il peut être utile de lancer analyze sur toutes les tables tiger pour mettre à jour les statistiques (y compris les statistiques héritées)

    SELECT install_missing_indexes();
    vacuum (analyze, verbose) tiger.addr;
    vacuum (analyze, verbose) tiger.edges;
    vacuum (analyze, verbose) tiger.faces;
    vacuum (analyze, verbose) tiger.featnames;
    vacuum (analyze, verbose) tiger.place;
    vacuum (analyze, verbose) tiger.cousub;
    vacuum (analyze, verbose) tiger.county;
    vacuum (analyze, verbose) tiger.state;
    vacuum (analyze, verbose) tiger.zcta5;
    vacuum (analyze, verbose) tiger.zip_lookup_base;
    vacuum (analyze, verbose) tiger.zip_state;
    vacuum (analyze, verbose) tiger.zip_state_loc;

2.4.2. Utilisation de l'Extension Address Standardizer avec le Geocodeur Tiger

Une des plaintes les plus récurrentes concerne la fonction Normalize_Address, qui normalise l'adresse avant de la géocoder. La normalisation est loin d'être parfaite, et corriger ces imperfections consomme énormément de ressources. Par conséquent, nous avons intégré un autre projet qui a un moteur de standardisation d'adresses bien meilleur. Pour utiliser ce nouveau address_standardizer, compilez l'extension en suivant Section 2.3, “Installation et utilisation de l'extension address standardize” et installez l'extension dans votre base de données.

Une fois que vous avez installé cette extension dans la même base de données où vous avez installé postgis_tiger_geocoder, vous pouvez utiliser Pagc_Normalize_Address à la place de Normalize_Address. Cette extension ne dépend pas de Tiger, et peut donc être utilisée avec d'autres sources de données telles que des adresses internationales. L'extension de géocodage Tiger est installée avec ses propres versions spécifiques de rules table ( tiger.pagc_rules) , gaz table (tiger.pagc_gaz), et lex table (tiger.pagc_lex). Vous pouvez les améliorer et ajouter des règles pour avoir de meilleurs résultats de géocodage pour vos besoins spécifiques.

2.4.3. Outils nécessaires pour charger des données tiger

Le processus de chargement télécharge les données du site web census pour respectivement les fichiers nation, état demandé, extrait les fichiers, puis charge chaque état dans son ensemble de tables état. Chaque table state hérite de la table définie dans le schéma tiger, il est suffisant d'interroger ces tables pour accéder à toutes les données et supprimer un ensemble de table state n'importe quand en utilisant Drop_State_Tables_Generate_Script si vous devez recharger un état ou si vous en avez plus besoin.

Dans l'objectif de charger des données vous avez besoin des outils suivants :

  • Un outils pour décompresser les fichiers zip du site web census.

    Pour les systèmes Unix-like : un exécutable unzip qui est habituellement installé sur la plupart des plateformes Unix-like.

    Pour Windows, 7-zip qui est un outils de compression/décompression libre, vous pouvez le récupérer à partir de http://www.7-zip.org/

  • La commande shp2pgsql qui est installé par défaut quand vous installez PostGIS.

  • wget qui est un outil de récupération de lien habituellement installé sur les systèmes Unix/Linux.

    Si vous êtes sous Windows, vous pouvez obtenir des binaires pré-compilés à partir de http://gnuwin32.sourceforge.net/packages/wget.htm

Si vous mettez à jour depuis tiger_2010, vous aurez besoin d'abord de générer et exécuter le Drop_Nation_Tables_Generate_Script. Avant de charger les données d'états, vous devez charger les données de nation via Loader_Generate_Nation_Script. Celui-ci va générer un script de chargement pour vous. Loader_Generate_Nation_Script est une étape à exécuter une seule fois, pour la mises à jour (depuis des données tiger précédentes) ou pour de nouvelles installations.

Pour charger les données d'états, voir Loader_Generate_Script pour générer un script pour charger les données pour votre plateforme et les états que vous souhaitez. Note : vous pouvez les charger peu à peu, vous n'avez pas besoin de tout charger d'un coup. Vous pouvez les charger lorsque vous en avez besoin.

Après que les états que vous désirez aient été chargé, assurez vous de lancer la commande :

SELECT install_missing_indexes();

comme décrit dans Install_Missing_Indexes.

Pour tester que les choses fonctionnent comme elles le devraient, essayez de lancer un géocodage sur une adresse de votre état en utilisant Geocode

2.4.4. Mise à jour du géocoder Tiger et de ses données

Tout d'abord, mettez à jour l'extension postgis_tiger_geocoder en exécutant :

ALTER EXTENSION postgis_tiger_geocoder UPDATE;

Puis supprimez toutes les tables nation et chargez les nouvelles. Générez un script de suppression avec la requête SQL comme détaillée dans Drop_Nation_Tables_Generate_Script

SELECT drop_nation_tables_generate_script();

Lancement des requêtes SQL de suppression générées.

Générez un script de chargement des pays avec la requête SELECT comme détaillé dans Loader_Generate_Nation_Script

Pour windows

SELECT loader_generate_nation_script('windows'); 

Pour unix/linux

SELECT loader_generate_nation_script('sh');

Reportez-vous à Section 2.4.1, “Tiger Geocoder Activation de votre base de données PostGIS” pour savoir comment exécuter le script de génération. Cette opération ne doit être effectuée qu'une seule fois.

[Note]

Vous pouvez avoir un mix de différentes années dans vos tables d'états et vous pouvez les mettre à jour indépendamment. Avant de mettre à jour un état, vous devez d'abord supprimer l'année précédente dans les tables d'états pour cet état en utilisant Drop_State_Tables_Generate_Script.

2.5. Problèmes courants pendant l'installation

Il y a plusieurs choses à vérifier quand votre installation ou mise à jour ne va pas dans la direction souhaitée.

  1. Vérifiez que vous avez installé PostgreSQL 12 ou plus récent et que vous êtes en train de compiler avec la même version du code source de PostgreSQL que la version qui fonctionne. Un mélange peut arriver lorsque votre distribution (Linux) a déjà une version de PostgreSQL installée ou que vous avez oublié que vous avez déjà installée une version. PostGIS fonctionnera uniquement avec PostgreSQL 12 ou plus récent, et des messages d'erreurs étranges et inhabituelles en résultera si vous utilisez une version plus ancienne. Pour vérifier la version de PostgreSQL qui fonctionne, connectez vous à la base en utilisant psql et lancez la requête :

    SELECT version();

    Si vous utilisez une distribution basé sur les RPM, vous pouvez vérifier l'existence de paquets pré-installés en utilisant la commande rpm comme suit : rpm -qa | grep postgresql

  2. Si votre mise à jour plante, assurez vous de la présence de PostGIS dans la nouvelle base de données.

    SELECT postgis_full_version();

Vérifiez également que le script configure a correctement détecté les chemins et versions de PostgreSQL, de la bibliothèque Proj.4 et de la blibliothèque GEOS.

  1. La sortie du configure est utilisée pour générer le fichier postgis_config.h. Vérifiez que les variables POSTGIS_PGSQL_VERSION, POSTGIS_PROJ_VERSION et POSTGIS_GEOS_VERSION ont été définies correctement.