Les objets SIG supportés par PostGIS sont un sur-ensemble des "Fonctionnalités Simples" définies par l'OpenGIS Consortium (OGC). Depuis la version 0.9, PostGIS gère tous les objets et fonctions définis dans les spécifications "Simple Features Specifications for SQL" de l'OGC.
PostGIS étend les standards en ajoutant le support pour les coordonnées 3DZ, 3DM et 4D.
Les spécifications de l'OpenGIS définissent deux méthodes standards pour décrire les objets spatiaux : la forme "textuelle bien connue" et la forme "binaire bien connue". Les deux formats contiennent des informations sur le type de l'objet ainsi que sur ses coordonnées.
Exemples de représentation en WKT d'objets spatiaux dont voici la description :
Les spécifications de l'OpenGIS imposent également que le format de stockage interne des objets géographiques inclue un identifiant du système de références spatiales ("spatial referencing system identifier", SRID). Le SRID est obligatoire lors de la création d'objets géographiques dans la base de données.
La gestion des entrées/sorties dans ces formats est rendue possible grâce aux fonctions suivantes :
Par exemple, voici des commandes valides pour créer et insérer des objets géographiques OGC :
Les formats proposés par l'OGC gèrent seulement la 2D et le SRID associé n'est jamais embarqué dans la représentation en entrée/sortie.
Les formats étendus de PostGIS sont actuellement un sur-ensemble de ceux de l'OGC (chaque WKB/WKT valide est un EWKB/EWKT valide) mais cela pourrait changer à l'avenir, particulièrement si l'OGC venait à sortir un nouveau format qui serait en conflit avec nos extensions. Donc vous NE DEVRIEZ PAS compter sur cette propriété.
Les format EWKB/EWKT de PostGIS ajoute les gestions de système de coordonnées 3dm, 3dz et 4d et contiennent l'information relative au SRID.
Des exemples de la représentation textuelle (EWKT) d'objets spatiaux étendus des propriétés sont les suivantes :
Les entrées/sorties dans ces formats sont disponibles via les interfaces suivantes :
Par exemple, une requête d'insertion valide pour créer et insérer un objet spatial PostGIS pourrait être :
Les "formes canoniques" d'un type PostgreSQL sont les représentations que vous obtenez avec de simples requêtes (sans appel de fonctions) et celle qui est sûr d'être accepté avec un simple insert, update ou copy. Pour le type geometry de PostGIS se sont les suivantes :
Par exemple cette requêtes lit du EWKT et renvoie du HEXEWKB dans le processus d'entrée/sortie canonique ascii :
Les spécifications des applications multimédia spatiales SQL étendent les propriétés simples des spécifications SQL en définissant un nombre de "courbes circulairement interpolées"
(original : "a number of circularly interpolated curves").
Les définitions de SQL-MM incluent les coordonées 3dm, 3dz et 4d, mais ne permettent pas d'embarquer l'information pour le SRID.
Les extensions "texte bien-connu" ne sont pas totalement supportées. Des exemples de quelque géométries courbées sont disponibles ci-dessous :
CIRCULARSTRING est le type de base des courbes, semblable à un élément de type LINESTRING dans le monde linéaire. Un ségment seul nécessite 3 points, les points de départ et d'arrivé (le premier et le troisième) et un autre point sur l'arc. À l'exception des cercles fermés, pour lesquels le poinr de départ et d'arrivé sont les mêmes.Dans ce cas, le deuxième point DOIT être le centre du cercle. Pour assembler les arcs ensemble, le dernier point du l'arc précédent devient le premier du suivant, exactement comme pour les géométries de type LINESTRING. Cela signifie qu'une chaîne circulaire valide doit avoir un nombre impair de points supérieur à 1.
CURVEPOLYGON est simplement un polygone, avec une partie extérieure et aucune ou plusieurs parties intérieures. La différence réside dans le fait que les différentes parties qui composent le polygone sont des courbes, des lignes ou des courbes composées.MULTICURVE est une collection de courbes, qui peut contenir des lignes, des courbes et des courbes composées.
Les versions précédentes de la version 1.4 de PostGIS ne supportent pas les courbes composées dans les polygones courbes, mais les versions supérieures ou égales à la version 1.4 supporte l'utilisation de courbes composées dans les polygones courbes.
Note : tout les comparaisons à virgule flottante dans l'implémentation de SQL-MM sont effectuées avec une tolérance spécifiée, actuellement fixée à 1e-8.
La spécification "Simple Features for SQL" de l'OpenGIS definie les types d'objets géographiques standards, les fonctions necessaires pour les manipuler et un ensemble de tables de méta-données. Pour s'assurer que les méta-données seront toujours complètes, les opérations telles que créer ou supprimer une colonne géométrique sont effectuées selon certaines procédures définies par l'OpenGIS.
Il y a deux tables de méta-données OpenGIS : SPATIAL_REF_SYS et GEOMETRY_COLUMNS. La table SPATIAL_REF_SYS contient les identifiants numériques et la description textuelle des systèmes de coordonnées utilisés dans la base de données.
haut de la page | table des matièresLa table spatial_ref_sys est inclue dans PostGIS et est conforme aux spécifications de l'OGC, elle contient environ 3000 systèmes de références spatiales et les détails nécessaires à la transformation/reprojection entre eux.
Bien que la table spatial_ref_sys contienne environ 3000 des systèmes de références spatiales les plus communément utilisés qui sont gérés par la librairie Proj4, elle ne contient pas tout les systèmes de références spatiales connue et vous pouvez même définir vos propres systèmes si vous êtes familiers avec la syntaxe de Proj4. Gardez à l'esprit que la plupart des systèmes de références spatiales sont régionaux et n'ont pas de signification hors de leurs limites respectives.
Une ressource essentiel pour la recherche de systèmes de références spatiales qui ne seraient pas présent dans la table spatial_ref_sys est le site web http://spatialreference.org/.
Les systèmes de références spatiales les plus couramment utilisés sont : 4326 - WGS 84 Long Lat, 4269 - NAD 83 Long Lat, 3395 - WGS 84 World Mercator, 2163 - US National Atlas Equal Area, les systèmes de références spatiales pour les zones NAD 83, WGS 84 UTM zone - UTM sont idéaux pour mesurer, mais couvrent uniquement des régions de 6 degrés.
Pour des détails sur la détermination de la zone UTM à utiliser pour votre espace d'intérêts, utilisez la fonction plpgsql de PostGIS : utmzone.
Voici la définition de la table SPATIAL_REF_SYS :
Et voici les colonnes de SPATIAL_REF_SYS :
Pour une liste des codes de projection EPSG et leur correspondance en WKT, suivez ce lien. Pour des explications sur le WKT, voir OpenGIS "Coordinate Transformation Services Implementation Specification".
Pour des informations sur "the European Petroleum Survey Group" (EPSG) et leur base de SRS voir ceci.
+proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=mLe fichier spatial_ref_sys.sql contient les définitions de SRTEXT et de PROJ4TEXT pour toutes les projections EPSG.
La définition de la table GEOMETRY_COLUMNS est la suivante :
Les colonnes sont les suivantes :
Créer une table avec des données géographiques se déroule en deux étapes :
CREATE TABLE ROADS_GEOM ( ID int4, NAME varchar(25) ) Exemple 1:
SELECT AddGeometryColumn('public', 'roads_geom', 'geom', 423, 'LINESTRING', 2)
Exemple 2:
SELECT AddGeometryColumn( 'roads_geom', 'geom', 423, 'LINESTRING', 2)
Voici un exemple de code SQL utilisé pour créer une table et ajouter une colonne spatiale (en supposant qu'un SRID de 128 existe déjà) :
Voici un autre exemple, utilisant le type générique "geometry" et un SRID indéfinie de valeur -1 :
La plupart des fonctions implémentées par la librairie GEOS supposent que vos données géométrique soient valides du point de vue des spécifications "Simple Feature for SQL" de l'OpenGIS. Pour vérifier la validité de vos géométries, vous pouvez utiliser la fonction isValid() :
Par défaut, PostGIS n'exécute pas la vérification de la validité lors de l'insertion d'objets géométriques, du fait qu'un tel test requière beaucoup de temps processeur pour les géométries complexes, principalement les polygones. Si vous n'avez pas confiance en vos données, vous pouvez manuellement contraindre vos tables en ajoutant une contrainte de validité de la façon suivante :
Si vous rencontrez un quelconque message d'erreur étrange du style "GEOS Intersection() threw an error!" ou "JTS Intersection() threw an error!" lorsque vous faites appel aux fonctions PostGIS avec des géométries valides, vous avez sans doute trouvé une erreur soit dans PostGIS soit dans une des librairies qu'il utilise, et vous devriez contacter les développeurs de PostGIS pour les en informer. Ceci est aussi vrai si une fonction de PostGIS vous renvoi une géométrie invalid pour une entrée géométriques valide.
Note :
Les géométries strictement conformes à l'OGC ne peuvent pas avoir de valeurs Z ou M. La fonction isValid() ne considèrera pas les géométries de plus grandes dimensions comme invalide ! L'invocation de AddGeomtryColumn() ajoutera une contrainte vérifiant les dimensions de la géométrie, il est donc suffisant ici de spécifier 2.
Une fois que vous avez créer une table spatiale, vous êtes prêt pour ajouter des données SIG à la base de données. Actuellement, il y a deux façons d'insérer les données dans une base PostgreSQL/PostGIS : en utilisant des requête SQL ou en utilisant l'importeur/exporteur de fichiers vecteurs (Shape).
haut de la page | table des matièresSi vous pouvez convertir vos données en une représentation textuelle, alors utiliser du code SQL pourrait être la manière la plus simple d'insérer vos données dans PostGIS. Comme avec Oracle et d'autre bases de données SQL, les données peuvent être chargées par le moniteur interactif en utilisant un fichier texte contenant des requêtes de type "INSERT" :
Un fichier d'importation de données (par exemple roads.sql) pourrait ressembler à ceci :
Le fichier de données peut être chargé dans PostgreSQL vraiment facilement en utiliant le moniteur interactif psql de la façon suivante :
psql -d [database] -f roads.sql
L'importeur de données shp2pgsql convertit des fichiers vecteurs (Shape) ESRI en requêtes SQL directement utilisables pour insérer des données dans des bases PostgreSQL/PostGIS. L'importeur possède différents modes opératoires qui se distinguent suivant les options qui lui sont passées en paramètre :
| -d | Supprime la table de la base données avant la création de la nouvelle table avec les données du fichier vecteur (Shape). | |
| -a | Ajoute les données du fichier vecteur dans la table de la base de données. Notez qu'il faut utiliser cette option pour charger plusieurs fichiers, qui doivent contenir les mêmes attributs et les mêmes types de données. | |
| -c | Crée une nouvelle table et la remplit avec le contenu du fichier vecteur (Shape). C'est le mode par défaut. | |
| -p | Produit uniquement le code de création des tables, sans ajouter les données. Cela peut être utile lorsque vous avez besoin de séparer complètement les étapes de création de table et celle de son remplissage. | |
| -D | Utilise le format d'export spécial de PostgreSQL pour extraire les données. Cette option peut être combinée avec -a, -c et -d. Ceci est plus rapide pour charger des données que d'utiliser des requêtes au format SQL de type "INSERT". Utilisez ceci pour l'insertion d'une grande quantité de données. | |
| -s <SRID> | Crée et remplit les tables géométriques avec le SRID spécifié. | |
| -k | Respecte la syntaxe (casse : majuscules/minuscules) des identifiants (colonne, schéma et attributs). Notez que les attributs dans des fichiers vecteurs sont en majuscules. | |
| -i | Coercition de tous les entiers en entiers 32 bits standards, ne crée pas de bigints 64 bits, même si la signature de l'en-tête DBF apparait pour le garantir. | |
| -I | Crée un index GiST sur la colonne géométrique. | |
| -w | Retour au format WKT, utilisé avec les anciennes versions (0.X) de PostGIS. Notez que cela introduira des dérives de coordonnées et supprimera les valeurs M des fichiers vecteurs. | |
| -W <encoding> | Spécifie l'encodage des données en entrée (du fichier dbf). Lorsque cette option est utilisée, tous les attributs du dbf sont convertis de l'encodage spécifié en UTF-8. La sortie SQL résultante contiendra une commande SET CLIENT_ENCODING to UTF8, donc le serveur principal sera capable de reconvertir de l'UTF-8 dans l'encodage choisi dans la configuration de la base de données. |
Notez que les options -a, -c, -d et -p sont mutuellement exclusives.
Une session exemple utilisant l'importeur pour générer un fichier d'importation et le chargement de ce fichier est décrite ci-dessous :
Une conversion et une importation des données peuvent être faites en une seule étape en utilisant les tubes UNIX :
Pour accéder aux données de la base vous pouvez soit utiliser le langage SQL soit l'importeur/exporteur de fichiers vecteurs (Shape File). Dans la section traitant du SQL, nous présenterons certains opérateurs disponibles pour comparer les objets géographiques et interroger les tables spatiales.
haut de la page | table des matièresL'intérêt principal d'insérer des données dans une base de données est de pouvoir utiliser une requête SQL de type SELECT et de récupérer les champs retournés dans un fichier texte lisible :
Parfois certain types de clauses sont nécessaires pour limiter le nombre de champs retournés. Dans le cas de clauses utilisant des attributs standards, utilisez simplement la même syntaxe SQL que celle utilisée pour des tables non spatiales. Dans le cas de clauses mettant en oeuvre des champs spatiaux, les opérateurs suivant sont à utiliser :
&& : Cet opérateur vérifie si "le cadre limite d'un objet géométrique intersecte celui d'un autre".~= : Cet opérateur vérifie si deux objets géométriques sont géographiquement identique. Par exemple, 'POLYGON((0 0,1 1,1 0,0 0))' est géographiquement identique à 'POLYGON((0 0,1 1,1 0,0 0))' (c'est le cas).= : Cet opérateur est un peu moins naïf, il vérifie uniquement si les cadres limites des objets géographiques sont les mêmes.Maintenant, vous pouvez utiliser ces opérateurs dans vos requêtes. Remarquez que lorsque vous utilisez des géométries et des boites dans vos requêtes SQL en ligne de commande, vous devez explicitement spécifier que vous souhaitez créer une géométrie à partir d'une chaine de caractères en utilisant la fonction ST_GeomFromText().
Par exemple :
La requête ci-dessus devrait renvoyer un enregistrement unique de la table "ROADS_GEOM" dans lequel l'objet géométrique serait égal à cette valeur.
Lorsque l'opérateur && est utilisé, vous pouvez spécifier soit une BOX3D soit un objet géométrique. Lorsque vous spécifiez une GEOMETRY, cependant, son cadre limite est utilisé pour réaliser la comparaison.
La requête ci-dessus utilisera le cadre limite du polygone pour effectuer la comparaison.
La requête spatiale la plus communément utilisée par une logiciel client, comme par exemple pour des navigateurs de données et des générateurs de cartes sur internet, sera probablement une requête basée sur des cadres limites, pour saisir la valeur du cadre limite d'une carte des données pour affichage. En utilisant un objet de type BOX3D pour le cadre, une telle requête ressemblerait à cela :
Vous remarquerez l'utilisation d'un SRID, pour spécifier le système de projection de l'objet de type BOX3D. La valeur -1 est utilisée pour indiquer que le SRID n'est pas défini.
L'exporteur de table pgsql2shp se connecte directement à la base de données et convertit une table (potentiellement définie par une requête) en fichier vecteur (shapefile). La syntaxe de base est :
Les options en ligne de commande sont les suivants :
| -f <nom_de_fichier> | Écrit le résultat dans le fichier spécifié. |
| -h <hôtet> | Le nom du serveur de base de données auquel se connecter. |
| -p <port> | Le port utilisé pour se connecter au serveur. |
| -P <mot_de_passe> | Le mot de passe à utiliser lors de la connection au serveur. |
| -u <utilisateur> | Le nom d'utilisateur à utiliser lors de la connection au serveur. |
| -g <colonne géometrique> | Dans le cas de tables avec des colonnes géométriques multiples, la colonne géométrique à utiliser lors de la rédaction du fichier vecteur (shapefile). |
| -b | Utilise un curseur binaire. Cela rend l'opération d'extraction plus rapide, mais ne fonctionnera pas si un attribut non-géométrique dans la table n'a pas de conversion en texte possible. |
| -r | mode raw. Ne supprime pas le champ gid, ou échappe les noms de colonnes. |
| -d | Pour une compatibilité en arrière : crée un fichier vecteur en 3 dimensions lorsque l'on exporte à partir de vieilles versions (pre-1.0.0) de bases de données PostGIS (par défaut il crée des fichiers vecteurs en 2 dimensions dans ce cas). À partir des versions 1.0.0 et supérieures de PostGIS, les dimensions sont complètement encodées. |
Les index rendent possible l'utilisation de base de données spatiales avec de grandes quantités de données. Sans indexation, chaque recherche de propriété pourrait requérir un "parcours séquentiel" de chaque enregistrement de la base de données. L'indexation rend plus rapide les recherches en organisant les données dans un arbre de recherche qui peut être parcouru plus rapidement afin de trouver un enregistrement particulier. Par défaut PostgreSQL supporte trois type d'indexes : les arbres B, les arbres R et les arbre de recherche généralisés (GiST).
GiST signifie "arbre de recherche généralisé" et est une forme générique d'indexation. En plus pour l'indexation GiST, GiST est utilisé pour accélérer les recherches de tout type de données irrégulières (tableau d'entier, données spectrales, etc) qui ne sont pas utilisables avec l'indexation normale par arbre B.
Une fois que les tables de données SIG dépassent quelques milliers d'enregistrements, vous voudrez créer des index pour accélérer les recherches spatiales des données (à moins que vos recherches soient basées sur des attributs, auquel cas vous devrez créer des index normaux sur les champs de ces attributs).
La syntaxe pour créer un index GiST sur une colonne géométrique est la suivante :
Créer un index spatial est un calcul informatique important : sur les tables d'environ un million d'enregistrements, sur une machine Solaris à 300MHz, nous avons trouvé que la création d'un index GiST prend environ une heure. Après avoir créer un index, il est important de forcer PostgreSQL à collecter les statistiques sur les tables, qui sont utilisées pour optimiser les planifications de requêtes :
Dans PotgreSQL, les index GiST ont deux avantages par rapport aux arbres R. Premièrement, les arbres de recherches généralisées acceptent les valeurs null, ce qui signifie qu'ils peuvent indexer des colonnes incluant des valeurs null. Deuxièmement, les arbre de recherches généralisées supportent le concept de "déperdition" qui est important lorsqu'on utilise des objets SIG d'une taille supérieur à la taille de 8K des pages de PostgreSQL. La "déperdition" permet à PostgreSQL de stocker uniquement les parties "importantes" d'un objet dans un index - dans le cas d'objets SIG, uniquement le cadre limite. Les objets SIG plus larges que 8K impliquent que le processus de création des arbres R échouera.
Habituellement, les index accélèrent l'accès aux données de façon transparente : une fois les index créés, le planificateur de requêtes décide de manière transparente quand utiliser l'index pour accélérer le plan de requête. Hélas, le planificateur de requête de PostgreSQL n'optimise pas bien l'utilisation d'index GiST, donc parfois les recherches qui devraient utiliser les index spatiaux par défaut au lieu d'un parcours séquentiel sur la table entière ne sont pas utilisés.
Si vous constatez que vos index spatiaux ne sont pas utilisés (ou vos index sur les champs, par exemple) il y a quelques "trucs" que vous pouvez tenter :
update_geometry_stats([nom_de_la_table, nom_de_colonne]) (calcul la distribution) et VACUUM ANALYZE [nom_de_la_table] [nom_de_colonne] (calcul le nombre de valeurs). À partir de PostgreSQL 8.0, exécuter VACUUM ANALYZE suffit pour effectuer les deux opérations. De toute manière, vous pouvez régulièrement nettoyer votre base de données - plusieurs administrateurs de base de données PostgreSQL exécutent dans leur crontab un nettoyage via VACUUM.SET ENABLE_SEQSCAN=OFF. Vous devez utiliser cette commande avec parcimonie, et uniquement des requêtes spatialement indexées : plus généralement, le planificateur de requêtes connait mieux que vous lorsqu'il faut utiliser normalement l'arbre B. Une fois que vous avez effectué votre requête, vous pouvez réaffecter la valeur initiale de ENABLE_SEQSCAN, de sorte que les autres requêtes utiliseront normalement le planificateur.Note :
Comme pour la version 0.6, il n'est pas nécessaire de forcer le planificateur à utiliser l'index avec ENABLE_SEQSCAN.
Si vous constatez que le planificateur a tort à propos du cout d'un parcours séquentiel par rapport à l'index, essayez de réduire la valeur du paramètre random_page_cost dans votre postgresql.conf ou utilisez la commande SET random_page_cost=#. La valeur par défaut pour ce paramètre est 4, essayez d'y attribuer les valeurs 1 ou 2. Décrémenter cette valeur rend le planificateur plus enclin à utiliser les parcours via l'index.
La raison d'être des fonctionnalités spatiales des base de données est de vous permettre d'effectuer des requêtes qui requièrent habituellement des outils SIG bureautiques. Utiliser PostGIS de manière efficace nécessite de connaitre qu'elles sont les fonctions spatiales disponibles et de s'assurer que les indexes appropriés sont en place pour obtenir de bonne performances.
haut de la page | table des matièresLorsque vous construisez une requête il est important de se souvenir que seuls les opérateurs du cadre-limite comme && tirent avantage des indexes spatiaux GIST. Les fonctions comme distance() ne peuvent pas utiliser les indexes pour optimiser leur opérations. Par exemple, la requête suivante pourrait être légèrement lente sur une grosse table :
geom_table qui sont dans un rayon de 100 unités du point (100000, 200000). Elle est lente parce qu'elle calcule la distance entre chaque point de la table et le point que nous avons spécifié, par exemple un calcul de distance() pour chaque enregistrement de la table. Nous pouvons éviter cela en utilisant l'opérateur && pour réduire le nombre de distance requit :
the_geom, le planificateur de requêtes constatera qu'il peut utiliser l'indexe pour réduire le nombre de ligne avant de calculer le résultat de la fonction distance(). Notez que la géométrie BOX3D qui est utilisé dans l'opération && est un cadre carré de 200 unités centré sur le point original - c'est notre "cadre de requête". L'opérateur && utilise l'indexe pour réduire rapidement l'ensemble résultant aux géométries qui ont un cadre limite qui recouvre le "cadre de requête". En supposant que notre "cadre de requête" est plus petit que l'extension de la totalité de la table, cela réduira considérablement le nombre de calculs de distance qui devra être effectué.
ST_Disjoint and ST_Relate, utilisent implicitement l'opérateur de superposition du cadre limite.
Les exemples de cette section utiliseront deux tables, une table de routes linéaires, et une table de limite polygonales des municipalités. La définition pour la table bc_routes est la suivante :
La définition pour la table bc_minicipalitees est la suivante :
Vous pouvez répondre à cette question avec une requête SQL simple :
longueur_routes_en_km
------------------
70842.1243039643
(1 row)
Cette requête combine une condition attributaire (sur le nom de la municipalité) avec un calcul spatial (de l'aire) :
Cette requête utilise une mesure spatiale comme condition. Il y a plusieurs manières d'approcher ce problème, mais la plus efficace est la suivante :
Vous remarquerez que pour répondre à cette question nous devons calculer l'aire de tous les polygones. Si nous faisons souvent cela, il serait judicieux d'ajouter une colonne "aire" à la table que nous pourrions alors indexer pour plus de performance. En ordonnant le résultat par ordre décroissant, et en utilisant la commende LIMIT de PostgreSQL nous pouvons aisément récupérer la plus grande valeur sans avoir à utiliser de fonction d'agrégation comme max().
Ceci est un exemple de "jointure spatiale', parce que nous utilisons les données de deux tables (en faisant une jointure) mais en utilisant une condition d'interaction spatiale ("contenue") comme condition de jointure au lieu d'utiliser l'approche relationnelle habituelle de jointure sur une clef commune :
Cette requête dure un moment, parce que chaque route de la table est disponible dans le résultat final (environ 250K routes pour notre table d'exemple). Pour des couvertures plus petites (quelques milliers ou centaines d'enregistrements) la réponse peut être très rapide.
Ceci est un exemple de "couverture", qui extrait les données de deux tables et retourne une nouvelle table qui contient l'ensemble des résultantes incluses ou partiellement coupées. Contrairement à la "jointure spatiale" présentée précédemment, cette requête crée de nouvelles géométries. Une couverture est comme une jointure spatiale turbo-cached, et est utile pour un travail d'analyse plus précis :
Minnesota Mapserver est un serveur cartographique Internet qui se conforme aux spécifications "Web Mapping Server" de l'OpenGIS.
Pour utiliser PostGIS avec Mapserver vous aurez besoin de savoir comment configurer Mapserver, ce qui dépasse le cadre de cete documentation. Cette section va couvrir les particularités d'une utilisation avec Postgis et les détails de la configuration.
Pour utiliser PostGIS avec Mapserver, vous aurez besoin de :
Mapserver accède aux données PostgreSQL/PostGIS comme n'importe quel autre client PostgreSQL - c'est à dire en utilisant la libpq. Cela signifie que Mapserver peut être installé sur chaque machines ayant un accès réseau vers un serveur PostGIS, temps que le système possède la libraire client de PostgreSQL (libpq).
Dans l'exemple ci-dessus, les directives spécifiques à PostGIS sont les suivantes :
CONNECTIONTYPE
Pour les couches PostGIS, cela sera toujours "postgis".
CONNECTION
La connection à la base de données est gouvernée par "la chaine de charatères de connection" ("connection string") qui est contituée d'un ensemble de couples nom/valeur comme ceci (avec la valeur par défaut entre < >) :
user=<nom_d_utilisateur> password=<mot_de_passe> dbname=<nom_de_la_base_de_données> hostname=<serveur> port=<5432>
Une chaine de charactères de connection vide reste valide, et chacun des couples nom/valeur peut être omis. Au minimum vous aurez généralement besoin de spécifier le nom de la base de données et le nom d'utilisateur avec lequel vous souhaitez vous connecter.
DATA
La forme de ce paramètre est : "<colonne> from <nom_de_la_table>" où la colonne est une colonne spatiale qui doit être affiché sur la carte.
FILTER
Le filtre doit être une chaîne de charactères SQL valide correspondant à la logique normale suivant le mot clef "WHERE" dans les requêtes SQL. Donc, par exemple, pour afficher uniquement les routes ayant 6 voies ou plus, utilisé le filtre "nombre_de_voies >= 6".
Contrairement aux fichiers vecteurs (shapefile), les noms de champs PostGIS doivent être référencés dans EXPRESSIONS en utilisant des lettres en minuscule.
Contrairement aux fichiers vecteurs (shapefile), les filtres pour les couches PostGIS utilisent la syntaxe SQL (ils sont concaténés à l'état SQL que le connecteur PostGIS génère pour afficher les couches dans Mapserver).
En général, les couches PostGIS sont 10 % plus lentes que les couches équivalentes en fichier vecteurs, ceci est due au temps qui incombe à la connection au serveur de base de données, les transformations et la transmission des données entre la base et Mapserver.
Si vous avez des problèmes de performance d'affichage, cela est généralement lié au fait que vous n'avez pas créé les indexes spatiaux pour vos tables.
Pour que les requêtes soient rapides, vous devez avoir une clef unique pour vos tables spatiales et un index sur cette clef unique.
Vous pouvez spécifier quelle clef unique doit être utilisée par Mapserver, en utilisant la clause : USING UNIQUE dans votre ligne DATA :
DATA "the_geom FROM geotable USING UNIQUE gid"
Si votre table n'a pas de colonne explicitement unique, vous pouvez "faire semblant" de rendre une colonne unique en utilisant la colonne PostgreSQL "oid" comme colonne unique. "oid" est la colonne unique par défaut si vous n'en déclarez pas une, donc pour améliorer le temps d'exécution de vos requêtes vous devez créer des indexes sur les valeurs oid de vos tables spatiales.
postgis# CREATE INDEX geotable_oid_idx ON geotable (oid);
La clause pseudo-SQL USING est utilisée afin d'ajouter des informations pour aider Mapserver à comprendre les résultats de plusieurs requêtes complexes. Plus précisément, lorsqu'une vue ou une sous-requête de sélection est utilisée comme table source (le terme à la droite du FROM dans la définition de DATA) il est plus difficile pour Mapserver de déterminer automatiquement un identifiant unique pour chaque tuple et le SRID pour la table. La clause USING peut fournir à Mapserver ces deux types d'informations :
USING UNIQUE <idunique>
Mapserver requière un identifiant unique pour chaque tuple dans le but d'identifier une ligne lorsque l'on effectue des interrogations de la carte. Normalement, il devrait utiliser l'oid comme identifiant unique, mais les vues et les sous-requêtes de sélection n'ont pas obligatoirement cette colonne oid. Si vous souhaitez utiliser les fonctionnalités d'interrogation de Mapserver, vous aurez besoin d'ajouter une colonne unique à vos vues ou vos sous-requêtes de sélection, et déclarer ceci en utilisant : USING UNIQUE. Pour ce faire, vous pouvez, par exemple, explicitement sélectionner une des valeurs d'oid de la table, ou l'une des autres colonnes pour laquelle vous garantissez l'unicité dans l'ensemble résultant.
L'état USING peut aussi être utile pour de simples état DATA, si vous effectuez des interrogations de la carte. Il était jadis recommandé d'ajouter un indexe sur la colonne oid des tables utilisées dans les couches interrogeables, dans le but d'accélérer les requêtes de la carte. Cependant, avec la clause USING, il est possible de spécifier à Mapserver d'utiliser la clef primaire de votre table comme identifiant pour interroger la carte, il n'est ainsi plus nécessaire d'avoir un indexe supplémentaire.
Note :
"Interroger une carte" est l'action qui consiste à cliquer sur la carte pour demander les informations relatives à la zone géographique sélectionnée. Ne confondez pas "interrogation de carte" avec requête SQL dans la définition de DATA.
USING SRID=<srid>
PostGIS a besoin de connaitre quel système de référence spatial doit être utilisé par les géométries afin de retourner correctement les données à Mapserver. Normalement il est possible de trouver ces informations dans la table "geometry_columns" dans une base de données PostGIS, cependant, il n'est pas possible pour les tables qui ont été créées à la volée comme des sous-requêtes de sélection ou des vues. Donc l'option USING SRID= vous permet de spécifier le SRID correspondant à vos données dans la définition de DATA.
Attention :
Le parser pour les couches PostGIS de Mapserver est légérement primitif et est sensible à la casse dans certaines parties. Faites attention à ce que tous les mots clefs SQL et toutes les clauses USING soient en lettres majuscules, et que vos clauses USING UNIQUE précèdent bien vos clauses USING SRID.
Commençons avec un exemple simple et qui nous servira de base pour la suite. Considérons la définition de couche Mapserver suivante :
Cette couche affichera toutes les géométries de la table routes comme des lignes noires.
Maintenant, supposons que nous voulions uniquement afficher les autoroutes lorsque nous zoomons au moins à une échelle de 1:100000, les deux prochaines couches permettent cela :
La première couche est utilisée lorsque l'échelle est plus grande que 1:100000, et affiche uniquement des lignes noires pour les routes de type "autoroute". L'option FILTER entraine que seules les routes de type "autoroute" doivent être affichées.
La seconde couche est utilisée lorsque l'échelle est plus petite que 1:100000, et affichera les autoroutes comme des lignes rouges à double-profondeurs, et les autre routes comme des lignes noires standards.
Donc, nous avons fait un couple de choses intéressantes en utilisant uniquement les fonctionnalités de Mapserver, mais nos états SQL dans les définitions de DATA sont restées simples. Supposons que le nom des routes soit stocké dans une autre table (pour une raison quelconque) et que nous souhaitions faire une jointure pour récupérer et étiqueter nos routes.
Cette couche d'annotation ajoute des étiquettes vertes à toutes les routes lorsque l'échelle atteint 1:20000 ou moins. Cela montre aussi comment utiliser les jointures SQL dans une définition de DATA.
Les clients Java peuvent accéder aux objets géométriques de PostGIS dans une base de données PostgreSQL soit directement via les représentations textuelles ou en utilisant les objets de l'extension JDBC distribuée avec PostGIS. Dans le but d'utiliser les objets de l'extension, le fichier "postgis.jar" doit être ajouté à votre CLASSPATH ainsi que le driver JDBC de PostgreSQL "postgresql.jar".
public class JavaGIS {
public static void main(String[] args)
{
java.sql.Connection conn;
try
{
/*
* Chargement du pilote JDBC et établissement d'une connection.
*/
Class.forName("org.postgresql.Driver");
String url = "jdbc:postgresql://localhost:5432/database";
conn = DriverManager.getConnection(url, "postgres", "");
/*
* Ajout du type géométrique à la connection. Notez que vous devez effectuer
* une convertion de type pour la connection avant de faire appèle à la méthode
* addDataType().
*/
((org.postgresql.Connection)conn).addDataType("geometry","org.postgis.PGgeometry");
((org.postgresql.Connection)conn).addDataType("box3d","org.postgis.PGbox3d");
/*
* Crée un état et exécute la requête de selection.
*/
Statement s = conn.createStatement();
ResultSet r = s.executeQuery("select AsText(geom) as geom,id from geomtable");
while( r.next() )
{
/*
* Récupération de la géométrie comme un objet puis convertion de type en
* vers le type geometry. Affichage des résultats.
*/
PGgeometry geom = (PGgeometry)r.getObject(1);
int id = r.getInt(2);
System.out.println("Row " + id + ":");
System.out.println(geom.toString());
}
s.close();
conn.close();
}
catch( Exception e )
{
e.printStackTrace();
}
}
}
L'objet "PGgeometry" est un objet de transition qui contient un objet géométrique à topologie spécifique (sous-classe de la classe abstraite "Geometry") dépendant du type : Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon.
La JavaDoc fournit, pour les objets de l'extension, une référence pour les diverses méthodes d'accès aux données dans les objets géométriques.