Le pilote implémente la gestion de l’accès aux tables spatiales dans PostgreSQL étendue par la gestion des données spatiales PostGIS. Une gestion existe dans le pilote pour utiliser PostgreSQL sans PostGIS mais avec moins de fonctionnalité.
Ce pilote nécessite une connexion à une base Postgres. Si vous voulez préparer un dump SQL pour l’injecter plus tard dans une base Postgres, vous pouvez utiliser plutôt Dump SQL pour PostgreSQL (GDAL/OGR >= 1.8.0).
Vous pouvez trouver des informations additionnelles sur le pilote dans la page Informations avancées du pilote PostgreSQL / PostGIS.
Pour se connecter à une source de données Postgres, utilisez une chaîne de connections définissant le nom de la base de données, avec autant de paramètres supplémentaires que nécessaire :
PG:dbname=databasename
ou
PG:"dbname='databasename' host='addr' port='5432' user='x' password='y'"
Il est également possible d’omettre le nom de la base de données et se connecter à celle par défaut, avec le même nom comme le nom d’utilisateur.
Note
on utilise PQconnectdb() pour réaliser la connexion, n’importe quelles autres options et valeurs par défauts qui pourraient s’y appliquer, s’applique au nom (référez vous à la documentation du serveur PostgreSQL ici pour PostgreSQL 8.4). Le préfixe PG: est utilisé pour marquer le nom en tant que chaîne de connexion postgres.
Si la table geometry_columns existe, alors toutes les tables listées et les vues nommées seront traitées comme des couches OGR. Autrement toutes les tables utilisateurs attributaires seront traitées comme des couches.
À partir de GDAL 1.7.0, le pilote gère également la colonne de type geography introduit dans PostGIS 1.5.
Le pilote PostgreSQL envoie les commandes SQL directement à PostgreSQL par défaut, plutôt que de les évaluer en interne lors de l’utilisation de l’appel ExecuteSQL() sur OGRDataSource, ou l’option en ligne de commande -sql pour ogr2ogr. Les expressions des requêtes attributaires sont également envoyées à PostgreSQL. Il est aussi possible de questionner le pilote pour prendre en charge les commandes avec le moteur SQL dans OGR, en passant la chaine OGRSQL à la méthode ExecuteSQL(), comme nom du dialecte SQL.
Le pilote PostgreSQL dans OGR gère les appels OGRDataSource::StartTrasaction(), OGRDataSource::CommitTransaction() et OGRDataSource::RollbackTransaction() dans le sens normal de SQL.
Le pilote PostgreSQL ne gère pas la création de nouveau jeu de données (une base de données dans PostgreSQL), mais il permet la création de nouvelles couches dans une base de données existante.
Comme mentionné au-dessus, le système du type est pauvre, et plusieurs types d’OGR ne sont pas mappés correctement dans PostgreSQL.
Si la base de données a les types PostGIS chargés (c’est à dire le type geometry) les nouvelles couches crées seront crées avec le type géométrique de PostGIS. Autrement elles utiliseront un type OID. Par défaut il est supposé que le texte envoyé à Postgres est encodé au format UTF-8. Cela convient pour l’ASCII, mais peut entrainer des erreurs pour les caractères étendus (ASCII 155+ par exemple). Bien que OGR ne fournisse aucun contrôle direct pour cela, vous pouvez définir la variable d’environnement PGCLIENTENCODING pour indiquer le format qui est utilisé. Par exemple, si votre texte est LATIN1 vous pouvez définir la variable d’environnement à LATIN1 avant d’utiliser OGR et les données en entrées seront supposées être en LATIN1 au lieu de UTF-8.
Un moyen alternatif pour définir l’encodage du client est d’utiliser la commande SQL suivante avec ExecuteSQL() : “SET client_encoding TO encoding_name” où encoding_name est LATIN1, etc.
Les erreurs peuvent être récupérées en englobant cette commande avec la paire CPLPushErrorHandler()/CPLPopErrorHandler().
Aucune.
Il y a une variété d’options de configuration qui aide à contrôler le comportement de ce pilote.
Des traductions simples de shapefile dans PostgreSQL. la table ‘abc’ sera crée avec les géométries de abc.shp et les attributs de abc.dbf. L’instance de base de données (warmerda) doit déjà exister, et la table abc ne doit pas être crée.
% ogr2ogr -f PostgreSQL PG:dbname=warmerda abc.shp
Ce second exemple charge une couche des limites des pays à partir d’un VPF (via le pilote OGDI), et renomme le nom énigmatique de la couche OGDI en un nom plus lisible. Si une table existante du nom désiré existe, elle sera écrasée.
% ogr2ogr -f PostgreSQL PG:dbname=warmerda \
gltp:/vrf/usr4/mpp1/v0eur/vmaplv0/eurnasia \
-lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line'
Dans cet exemple nous fusionnons des données lignes tiger de deux répertoires différents de fichier tiger dans une table. Notez que la seconde invocation utilise -append et pas OVERWRITE=yes.
% ogr2ogr -f PostgreSQL PG:dbname=warmerda tiger_michigan \
-lco OVERWRITE=yes CompleteChain
% ogr2ogr -update -append -f PostgreSQL PG:dbname=warmerda tiger_ohio \
CompleteChain
Cet exemple montre l’utilisation d’ogrinfo pour évaluer une commande de requête SQL dans PostgreSQL. Des requêtes PostGIS plus sophistiquées peuvent être utilisées également via la commande -sql dans ogrinfo.
ogrinfo -ro PG:dbname=warmerda -sql "SELECT pop_1994 from canada where province_name = 'Alberta'"
Cet exemple montre l’utilisation de ogrinfo pour lister les couches PostgreSQL/PostGIS sur un hôte différent.
ogrinfo -ro PG:'host=myserver.velocet.ca user=postgres dbname=warmerda'
Vous devez avoir les permissions sur toutes les tables que vous voulez lire et geometry_columns et spatial_ref_sys.
Un comportement erroné peut ne renvoyer aucun message d’erreur si vous n’avez pas la permission à ces tables. Les problèmes de permission sur les tables geometry_columns et/ou spatial_ref_sys peut être généralement confirmés si vous pouvez voir les tables en définissant l’option de configuration PG_LIST_ALL_TABLES à YES. (par exemple ogrinfo --config PG_LIST_ALL_TABLES YES PG:xxxxx).