Vous pouvez stocker des points, des lignes, des polygones, des multipoints, des multilignes, des multipolygones et des geometrycollections. Ceci est spécifié dans le format Textuel Bien Connu (Well Known Text) de l'OpenGIS Consortium (avec les extensions XYZ, XYM, XYZM).
haut de la page | table des matièresAvant tout, vous devez créer une table avec une colonne de type "géométrique" pour stocker vos données SIG. Connectez-vous à la base de données avec psql et essayez le code SQL suivant :
Si l'ajout de la colonne gémétrique échoue, c'est sans doute que vous n'avez pas chargé les fonctions et objets PostGIS dans la base de données. Consultez les instructions d'installation.
Ensuite, vous pouvez insèrer un objet géométrique dans la table en utilisant la commande SQL INSERT. L'objet SIG est fomaté en utilisant le format Textuel Bien Connu (Well Known Text) de l'OpenGIS Consortium :
Pour plus d'information concernant les autres objets SIG, consultez la référence de l'objet.
Pour visualiser vos objets SIG de la table :
Le résultat obtenu devrait ressembler à quelque chose comme ça :
De la même manière que vous construisez n'importe quel autre type de requête pour vos bases de données, comme une combinaison SQL de valeurs de retour, fonctions et autre tests booléens.
Pour les requêtes spatiales, il y a deux choses importantes à garder à l'esprit lorsque vous construisez votre requête : y-a-t-il un index spatial que vous pouvez utiliser ; et, faites vous des calculs couteux sur un grand nombre de géométries.
En général, vous voudrez utiliser l'opérateur d'intersection (&&) qui test si les cadres limites des objets s'intersectent. La raison pour laquelle l'opérateur && est utile vient du fait que si un index spatial est disponible pour accélérer le test, l'opérateur && l'utilisera. Ceci peut rendre les requête beaucoup plus rapides.
Vous pourrez aussi utiliser des fonctions spatiales, comme par exemple Distance(), Intersects(), Contains() et Within(), parmi tant d'autres, pour limiter les résultats de vos recherches. La plupart des requêtes spatiales contiennent à la fois un test indexé et un test utilisant une fonction spatiale. Le test indexé sert à limiter le nombre de tuples résultants, uniquement ceux qui respectent la condition. La fonction spatiale est ensuite utilisée afin de tester réellement la condition.
Les requêtes rapides sur de grandes tables sont la raison d'être des bases de données spatiales (transactionnelles) donc avoir un bon index est primordial.
Pour construire vos index spatiaux sur les tables qui ont un colonne géométrique, utilisez la fonction CREATE INDEX de la manière suivante :
L'option USING GIST signifie que le serveur doit utiliser un index GiST (Generalized Search Tree, en d'autres termes : un arbre de recherche généralisé).
Vous devriez aussi vous assurer que le planificateur de requête de PostgreSQL a suffisamment d'informations concernant votre index pour prendre une décision rationnelle quant à son utilisation. Pour ce faire, vous devez rassembler les statistiques de vos tables géométriques.
Pour PostgreSQL 8.0.x et supérieur, lancez simplement la commande VACUUM ANALYZE
Pour PostgreSQL 7.4.x et précédant, lancez la commande : SELECT UPDATE_GEOMETRY_STATS().
Les précédentes versions de PostGIS utilisaient les arbres R de PostgreSQL. Cependant, les arbres R de PostgreSQL ont été totalement supprimé depuis la version 0.6, et l'indexation spatiale est disponible avec un schéma arbre R sur arbre de recherches généralisés (GiST).
Nos tests ont montrés que la rapidité d'exécution pour les arbres R natifs et les GiST sont comparables. Les arbres R natifs de PostgreSQL ont deux limitations qui les rendent inutilisable pour une utilisation dans le cadre SIG (notez que ces limitations sont dues à l'implémentation des arbres R natifs de PostgreSQL, et non au concept d'arbre R en lui-même) :
Si vous ne voulez pas utiliser les fonctionnalités spécifiées par l'OpenGIS, vous n'avez pas à les utiliser. Créez simplement vos tables comme vous le faisiez avec les versions précédentes, définissez vos colonnes géométriques lors de leurs créations. Toutes vos géométries auront alors -1 comme valeur pour SRID et les tables de méta-données de l'OpenGIS ne seront pas remplies correctement. Cependant, cela a pour conséquence que la plupart des applications basées sur PostGIS ne fonctionneront plus. C'est pourquoi il est généralement conseillé d'utiliser la fonction AddGeometryColumn() pour créer ses tables géométriques.
Par exemple Mapserver est une application qui utilise les méta-données de la table geometry_columns. Par exemple, Mapserver peut utiliser le SRID de la colonne géométrique afin de réaliser des reprojections.
Afin d'utiliser la base de données plus efficacement, il vaut mieux faire une requête de rayon qui combine le test de rayon et le test des cadres limites : le test de cadre limite utilise un index spatial, permettant un accès rapide à un sous-ensemble de données pour lesquels le test de rayon est ensuite effectué.
La fonction ST_DWithin(geometry, geometry, distance) permet de réaliser un calcul de distance utilisant les index. Elle fonctione en créant un espace rectangulaire de recherche suffisamment large pour contenir le rayon ayant la valeur du parmètre distance, ensuite elle réalise l'opération exacte de calcul de distance sur le sous-ensemble résultant.
Par exemple, pour trouver tout les objets dans un rayon de 100 mètres autour du point POINT(1000 1000), la requête suivante devrait bien fonctionner :
Pour effectuer une reprojection, les systèmes de références spatiales source et destination doivent être tout deux définis dans la table SPATIAL_REF_SYS, et les géométries qui doivent être reprojetées doivent déjà avoir un SRID d'attribué. Une fois que cela est fait, une reprojection consiste simplement à stipuler le SRID du système de projection désiré pour la destination. L'exemple ci-dessous reprojette une géométrie dans le système NAD 83 long lat. Cet exemple ne fonctionnera que si la valeur du srid de la colonne the_geom est différente de -1 (qui correspond à un système de référence indéfini).