L’information collectée dans cette page traite de sujet avancé, non trouvé dans la page PostgreSQL / PostGIS.
À partir de GDAL 1.8.0, l’ouverture de la base de données doit être significativement plus rapide que dans les versions précédentes, l’utilisation des options tables= ou schemas= ne devraient pas accélérer les choses.
À partir de GDAL 1.6.0, l’ensemble des tables à scanner peut être écrasé en spécifiant tables=[schema.]table[(geom_column_name)][,[schema2.]table2[(geom_column_name2)],...] dans la chaîne de connexion. Si le paramètre est trouvé, le pilote saute l’énumération des tables comme décrite dans le paragraphe suivant.
À partir de GDAL 1.7.0, il est possible de restreindre les schémas qui seront scannés lors de l’établissement de la liste des tables. Cela peut être réalisé en spécifiant schemas=schema_name[,schema_name2] dans la chaîne de connections. Cela peut aussi être un moyen d’accélérer la connexion à la base de données PostgreSQL s’il y a beaucoup de schémas. Remarquez que si seulement un schéma est listé, il sera aussi défini comme le schéma actif (et le nom du schéma ne sera pas en préfixe des noms des couches). Autrement, le schéma actif sera encore ‘public’, à moins que cela soit spécifié par l’option active_schema=.
À partir de GDAL 1.7.0, le schéma actif (‘public’ par défaut) peut être écrasé en définissant active_schema=schema_name dans la chaîne de connexion. Le schéma actif est le schéma où les tables sont créées ou recherchées lorsque leur nom n’est pas défini en préfixe explicitement dans les noms des couches. Notez que cela ne restreint pas les tables qui seront listées (voir l’option * schemas=* ci-dessus). Lors de l’obtention de la liste des tables, le nom des tables dans le schéma actif ne sera pas préfixé par le nom du schéma. Par exemple, si vous avez la table ‘foo’ dans le schéma public, et une table ‘foo’ dans le schéma ‘bar_schema’ et que vous définissez ‘active_schema=bar_schema, deux couches seront listées : ‘foo’ (implicitement dans ‘bar_schema’) et ‘public.foo’.
À partir de GDAL 1.6.0, le pilote PostgreSQL gère l’accès aux tables avec plusieurs colonnes géométriques PostGIS. Pour de telles tables, il y aura autant de couches reportées que de nombre de colonnes géométriques listées pour cette table dans la table geometry_columns. Par exemple, si une table ‘foo’ a deux colonnes géométriques ‘bar’ et ‘baz’, deux couches seront reportées : ‘foo(bar)’ et ‘foo(baz)’. Pour une compatibilité arrière, si une table possède une seule colonne géométrique, le nom de la couche est le nom de la table. Aussi si une table ‘foo’ possède plusieurs colonnes géométriques, avec une appelée ‘wkb_geometry’, la couche correspondante à cette colonne géométrique sera simplement reportée comme ‘foo’. Soyez attentif - le comportement lors de la création, mise à jour ou suppression de couches qui sont basées sur des tables avec de multiples colonnes géométriques PostGIS est connue pour avoir des effets secondaires (mal connu) sur les autres couches puisqu’elles sont intimement liées. Par conséquent, cette possibilité doit être utilisée essentiellement en lecture seule.
À partir de GDAL 1.6.0, même quand PostGIS est activé, si l’utilisateur définit la variable d’environnement
PG_LIST_ALL_TABLES=YES
(et ne définie pas ‘’tables=’‘), toutes les tables attributaires des utilisateurs et les vues nommées seront traitées comme des couches. Cependant, les tables avec des colonnes de géométrie multiple seront seulement rapportées une fois dans ce mode. Ainsi, cette variable est essentiellement utile lorsque PostGIS est activé pour retrouver les tables sans données spatiales, ou les vues sans entrée dans la table geometry_columns.
Dans tous les cas, tous les utilisateurs peuvent réaliser des requêtes explicitement avec GetLayerByName().
Les tables attributaires (non spatiale) peuvent être accédée, et retourneront les objets avec leurs attributs, mais sans géométrie. Si la table possède un champ wkb_geometry, elle sera traitée comme une table spatiale. Le type du champ est inspecté pour déterminer comment il doit être lu. Cela peut être un champ géométrique PostGIS, qui est supposé être au format WKT de l’OGC, ou de type BYTEA ou OID auquel cas il est utilisé comme une source de géométrie WKB de l’OGC.
À partir de GDAL 1.6.0, les tables héritées de tables spatiales sont gérées.
S’il y a un champ ogc_fid, il sera utilisé pour définir l’id de l’objet des géométries, et ne sera pas traité comme un champ régulier.
Le nom de la couche peut être de la forme schema.table. Le schéma doit exister, et l’utilisateur doit avoir les droits d’écriture pour la cible et le schéma public.
À partir de GDAL 1.7.0, i l’utilisateur définie la variable d’environnement PG_SKIP_VIEWS=YES (et ne spécifie pas tables=), seul les tables de l’utilisateur seront traité comme couche. L’action par défaut est d’inclure les vues. Cette variable est particulièrement utile lorsque vous devez copier les données dans un autre format tout en évitant la redondance des données à partir des vues.
Quand PostGIS est activé pour la base de données accédée, les vues nommées sont gérées, si et seulement si une entré dans la table geometry_columns existe. Mais, notez que la fonction SQL AddGeometryColumn() n’accepte pas l’ajout d’une entrée pour une vue (seulement pour les tables attributaires). Il faut donc le réaliser à la main avec une requête comme :
"INSERT INTO geometry_columns VALUES ('', 'public', 'name_of_my_view', 'name_of_geometry_column', 2, 4326, 'POINT');"
À partir de GDAL 1.6.0, il est également possible d’utiliser des vues nommées sans insertion dans la table geometry_columns. Pour cela, vous devez définir explicitement le nom de la vue dans l’option table= de la chaîne de connections. Voyez au-dessus. La contrainte est qu’OGR ne sera pas capable de rapporter un SRS valide et de retrouver le bon type de la géométrie.
À partir d’OGR 1.8.0 et des bases de données PostgreSQL >= 8.2, le FID d’une feature (i.e. habtiduellement la valeur de la colonne OGC_FID pour une feature) insérée dans une table avec CreateFeature(), en mode non copie, sera récupéré à partir de la base et peut être obtenu avec GetFID(). Un effet de bord de ce nouveau comportement est que vous devez faire attention si vous réutiliser le même objet feature dans une loupe qui réalise des intersections. Après la première itération, le FID sera définie à une valeur non null, à la deuxième itération donc, CreateFeature() tentera d’insérer la nouvelle feature avec le FID de l’ancienne feature, ce qui échouera puique vous ne pouvez pas insérer deux features avec le même FID. Dans ce cas vous devez explicitement reseter le FID avant l’appel de CreateFeature(), ou utiliser un objet feature tout neuf.
Court exemple en Python :
feat = ogr.Feature(lyr.GetLayerDefn())
for i in range(100):
feat.SetFID(-1) # Reset FID to null value
lyr.CreateFeature(feat)
print('The feature has been assigned FID %d' % feat.GetFID())
ou :
for i in range(100):
feat = ogr.Feature(lyr.GetLayerDefn())
lyr.CreateFeature(feat)
print('The feature has been assigned FID %d' % feat.GetFID())
Le comportement d’OGR < 1.8.0 peut être obtenu en définissant l’option de configuration OGR_PG_RETRIEVE_FID à FALSE.
Cet exemple montre l’utilisation de ogrinfo pour lister seulement les couches définies par l’option tables= (à partir de GDAL 1.6.0).
ogrinfo -ro PG:'dbname=warmerda tables=table1,table2'
Cet exemple montre l’utilisation de ogrinfo pour requêter une table ‘foo’ avec des colonnes à géométrie multiple (‘geom1’ et ‘geom2’) (à partir de GDAL 1.6.0) :
ogrinfo -ro -al PG:dbname=warmerda 'foo(geom2)'
Cet exemple montre comment lister seulement les couches dans les schémas apt200810 et apt200812. Les noms des couches seront préfixés par le nom du schéma auquel ils appartiennent (à partir de GDAL 1.7.0) :
ogrinfo -ro PG:'dbname=warmerda schemas=apt200810,apt200812'
Cet exemple montre l’utilisation de ogrinfo pour lister seulement les couches dans le schéma nommé apt200810. Notez que les noms des couches ne seront pas préfixés par apt200810 puisque seul un schéma est listé (à partir de GDAL 1.7.0) :
ogrinfo -ro PG:'dbname=warmerda schemas=apt200810'
Cet exemple montre comment convertir un ensemble de shapefile dans le répertoire apt200810 dans un schéma apt200810 existant de Postgres. Dans cet exemple, nous pourrions utiliser l’option the schemas= à la place (à partir de GDAL 1.7.0) :
ogr2ogr -f PostgreSQL "PG:dbname=warmerda active_schema=apt200810" apt200810
Cet exemple montre comment convertir toutes les tables dans le schéma apt200810 comme un ensemble de shapefile dans le répertoire apt200810. Notez que les noms des couches ne seront pas préfixés par apt200810 puisque seul un schéma est listé (à partir de GDAL 1.7.0) :
ogr2ogr apt200810 PG:'dbname=warmerda schemas=apt200810'
Cet exemple montre comment écraser une table existante dans un schéma existant. Notez que l’utilisation de l’option ‘’-nln’’ pour définir le nom de la couche qualifiée :
ogr2ogr -overwrite -f PostgreSQL "PG:dbname=warmerda" mytable.shp mytable -nln myschema.mytable
Notez que l’utilisation de -lco SCHEMA=mytable à la place de -nln n’aurait pas fonctionner dans ce cas (voir bug #2821 pour plus de détails).
Si vous désirez écraser plusieurs tables à la fois localisées dans un schéma, l’option -nln n’est pas plus appropriée, il peut être donc plus facile d’utiliser la chaîne de connexions active_schema (à partir de GDAL 1.7.0). L’exemple suivant écrasera, si nécessaire, toutes les tables PostgreSQL correspondantes à un ensemble de shapefile dans un répertoire apt200810 :
ogr2ogr -overwrite -f PostgreSQL "PG:dbname=warmerda active_schema=apt200810" apt200810