Gestion d'une base et de ses objets

Par défaut shp2pgsql et ogr2ogr ignorent l'encodage des fichiers et ne font pas de conversions.

Dans PostgreSQL chaque base peut avoir son jeu de caractères (éventuellement différent de celui qui a été attribué à la création du cluster de bases de données qui est généralement choisi comme étant UTF-8).

On peut voir l'encodage d'une base sans ses propriétés sous PgAdmin :

Que l'on peut retrouver dans la table base pg_database de la base postgres (base Postgres > catalogues > tables ) :

Une conversion automatique entre le client et le serveur est possible si on déclare explicitement le jeu de code du client, par l'une des méthodes indiquées sur cette page. En particulier SET CLIENT_ENCODING TO ‘valeur' (par exemple SET CLIENT ENCODING TO ‘LATIN1', à taper dans un requêteur SQL).

Dans un shell on pourra utiliser la variable PGCLIENTENCODING.

• Exemple sous windows : set PGCLIENTENCODING=latin1

• Exemple sous Unix : export PGCLIENTENCODING=latin1

On pourra également consulter cette page du site geoinfo.

Une erreur typique d'un problème d'encodage sera un message du type :

« ERROR 1: INSERT command for new feature failed. »

« ERREUR:  s├®quence d'octets invalide pour l'encodage ┬½ UTF8 ┬╗ : 0xe96475 »

Il arrive que en cas de géométrie invalide au sens de l'OGC, un import, par exemple par ogr2ogr vers PostgreSQL échoue. Dans ce cas il peut être utile d'utiliser l'option -skipfailure qui permet de continuer le traitement après erreur. Voir plus loin, le chapitre sur la correction des erreurs de géométrie dans module sur les compléments SQL.

Il peut arriver que l'on cherche à insérer un fichier ayant des géométries hétérogènes, typiquement POLYGON et MULTIPOLYGON.

Dans ce cas si la table existe déjà dans PostGIS il faut changer la contrainte sur la géométrie

exemple :.. CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL), avant PostGIS 2.0

A partir de PostGIS 2.0, on peut par exemple changer la définition du champs the_geom en geometry(geometry, 2154) qui permettra d'accepter n'importe quelle géométrie.

Autre exemple pour passer une table (y compris les entités déjà existantes) en géométrie MULTIPOLYGON :

ALTER TABLE ads49.parcelle

ALTER COLUMN the_geom

SET DATA TYPE geometry(MULTIPOLYGON,2154) USING ST_Multi(the_geom)

Il peut également arriver que les données soient importées en 4D ou 3D (import Bdtopo par exemple) alors que l'on souhaite les exploiter comme des données 2D.

Dans ce cas on pourra ramener les géométries en 2D avec un ST_Force_2D(), exemple :

ALTER TABLE police_eau.troncons_bdp

ALTER COLUMN the_geom TYPE geometry(MultiLineString) USING ST_Force_2D(the_geom);

Les projections IGNF ne sont pas présentes pas défaut dans PostGIS. Si on souhaite les ajouter on consultera le site de l'IGN qui propose un script de création sql.

A l’exécution vous risquez cependant d'avoir le message :

ERREUR: la nouvelle ligne viole la contrainte de vérification « spatial_ref_sys » de la relation « spatial_ref_sys_srid_check »

DETAIL: La ligne en échec contient (110598000, IGNF, 110598000, GEOCCS["MOP92 (Anaa) Tuamotu",DATUM["MOP92 (ANAA) TUAMOTU",SPHER..., +init=IGNF:ANAA92)

La contrainte de la table spatial_ref_sys est effectivement :

INT spatial_ref_sys_srid_check CHECK (srid > 0 AND srid <= 998999)

Il faut la supprimer par :

ALTER TABLE spatial_ref_sys DROP CONSTRAINT spatial_ref_sys_srid_check ;

(on pourra éventuellement en recréer une moins contraignante sur la valeur maxi du srid).

Après exécution du script, vous pouvez vérifier que les projections IGNF sont bien disponibles dans la table spatial_ref_sys.

On fera très attention à l'utilisation des projections bornées des fichiers TAB.

Si on charge un fichier TAB sans précaution dans QGIS on aura comme Système de Coordonnées, un système de type USER : 100006.

Ceci est du d'une part à un problème d'inversion des coordonnées lat1 et lat2 dans gdal dans les anciennes versions et d'autres part à l'utilisation d'une légère modification du paramètre lat2 dans MapInfo pour reconnaître les projections bornées  :

exemple :

+proj=lcc +lat_1=44 +lat_2=49.00000000001 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

alors que les paramètres de EPGS 2154 sont :

+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

Du coup QGIS ne reconnaît pas la projection utilisée et lui attribue une projection 'utilisateur'.

Si on n'indique pas explicitement la projection, en import par DBManager, il y aura création d'une nouvelle entrée dans la table spatial_ref_sys (une absence de droit en création sur cette table fait échouer l'import) :

si on recharge cette table dans QGIS on aura alors le message :

On pourra vérifier que la projection retenue est WGS84, ce qui n'est pas correct.

Une solution possible est par exemple d'affecter la projection EPSG2154 à la couche dans QGIS avant de l'importer dans PostgreSQL.