PostGIS est développé par la companie Refractions Research Inc dans le cadre d'un projet de recherche sur les bases de données spatiales. Refractions est une société de conseil dans le domaine du SIG et des bases de données, basée au Canada, à Victoria, Colombie Britanique, elles est spécialisée dans l'intégration de données et le développement de logiciels spécifiques. Ils ont prévu d'aider et de développer PostGIS afin de supporter un nombre important de fonctionnalités SIG, incluant un support complet de l'OpenGIS, la construction topologique avancée (couvertures, surfaces, réseaux), des interfaces utilisateurs permettant de visualiser et d'éditer des données SIG, et des applications accessibles via le web.

Sandro Santilli :

coordination de toutes les corrections de bogues et des efforts de maintenance, intégration des nouvelles fonctionnalités de GEOS, et amélioration des nouvelles fonctions.

Mark Leslie

Maintenances et développements continus des fonctions 'coeurs'.

Chris Hodgson :

maintient les nouvelles fonctions et la liaison avec l'index 7.2.

Paul Ramsey :

maintient les objets JDBC et conserve une trace de la documentation et du packaging.

Jeff Lounsbury :

développement initial du chargeur/extracteur de fichier vecteur.

Dave Blasby :

le développeur à l'origine de PostGIS. Dave a écrit les objets côté serveur, liaison avec les indexs, et certaines des fonctions analytiques côté serveur.

Autres contributeurs :

Par ordre alphabétique : Alex Bodnaru, Alex Mayrhofer, Bernhard Reiter, Bruno Wolff III, Carl Anderson, Charlie Savage, David Skea, David Techer, IIDA Tetsushi, Geographic Data BC, Gérald Fenoy, Gino Lucrezi, Klaus Foerster, Kris Jurka, Mark Cave-Ayland, Mark Sondheim, Markus Schaber, Michael Fuhr, Nikita Shulga, Norman Vine, Olivier Courtin, Ralph Mason, Steffen Macke.

Un grand merci à :

la bibliothèque d'opérations géométriques GEOS, et la partie algorithmique qui est le travail de Martin Davis <mbdavis@vividsolutions.com> de Vivid Solutions qui fait que tout fonctionne.

la bibliothèque de projection cartographique Proj4, et au travail de Gerald Evenden et Frank Warmerdam pour sa création et son maintien.

• La dernière version du logiciel, la documentation et les nouvelles informations sont disponibles sur le site web de PostGIS : http://postgis.refractions.net.
• Pour plus d'informations concernant la bibliothèque d'opérations géométriques GEOS consultez ceci : http://geos.refractions.net.
• Pour plus d'informations concernant la bibliothèque de projection Proj4 consultez ceci : http://www.remotesensing.org/proj.
• Pour plus d'informations concernant le serveur de base de données PostgreSQL consultez le site principal de PostgreSQL : http://www.postgresql.org.
• Pour plus d'informations concernant l'indexation GiST, consultez le site de développement GiST de PostgreSQL, http://www.sai.msu.su/~megera/postgres/gist.
• Pour plus d'informations concernant le serveur MapServer, consultez ceci : http://mapserver.gis.umn.edu.
• La spécification intitulée "Simple Features for Specification for SQL" est disponible sur le site web de l'OpenGIS Consortium : http://www.opengis.org

Voici la liste des traducteurs du manuel PostGIS :

• Jérôme Avond (aka jad)
• Eve R. (aka phytosociologue)
• Yves Jacolin (aka yjacolin )
• Gérald Fenoy (aka djay)

Le reste de ce chapitre va vous présenter chacune de ces étapes d'installation de manière détaillée.

Pour être compilé et utilisé, PostGIS nécessite l'ensemble des outils suivants.
Nécessaires :

• Une installation complète de PostgreSQL (incluant les fichiers d'entêtes du serveur). PostgreSQL est disponible à l'adresse http://www.postgresql.org. La version 8.1 ou supérieure est nécessaire
• Compilateur GNU C (gcc). D'autre compilateurs AINSI C peuvent être utilisés pour compiler PostGIS, mais nous rencontrons beaucoup moins de problèmes lorsque l'on utilise gcc.
• GNU Make (gmake ou make). Sur de nombreux systèmes, GNU make est la version par défaut de make. Vérifiez la version en utilisant la commande : make -v. Les autres versions de make pourrait ne pas exécuter correctement le Makfile de PostGIS
• La bibliothèque de reprojection Proj4, version 4.5.0 ou supérieure. La bibliothèque Proj4 est utilisée afin de permettre la reprojection des coordonnées avec PostGIS. Proj4 est disponible en téléchargement depuis : http://www.remotesensing.org/proj.
• La bibliothèque GEOS, version 3.0.0 ou supérieure. La bibliothèque GEOS est utilisée pour permettre l'utilisation des tests géométriques (ST_Touches(), ST_Contains(), ST_Intersects()) et les opérations (ST_Buffer(), ST_GeomUnion(), ST_Difference()) avec PostGIS. GEOS est disponible en téléchargement depuis http://geos.refractions.net.

Optionnels :

• Apache Ant (ant) est nécessaire pour la compilation d'un des pilotes contenu dans le répertoire java. Ant est dispopnible depuis la page officielle du projet : http://ant.apache.org.
• DocBook (xsltproc) est nécessaire pour la génération de la documentation. Docbook est disponible depuis la page officielle du projet : http://www.docbook.org/.
• DBLatex (dblatex) est nécessaire pour générer la documentation au format PDF. DBLatex est disponible depuis la page officielle du projet : http://dblatex.sourceforge.net/.
• ImageMagick (convert) est nécessaire pour la génération des images utilisées dans la documantation. ImageMagick est disponible depuis la page officielle du projet : http://www.imagemagick.org/.

Téléchargez l'archive du code source de PostGIS depuis la site de téléchargement : http://postgis.refractions.net/download/postgis-1.4.0.tar.gz.

Cela va créer un répertoire intitulé postgis-1.4.0 dans le répertoire courant où vous avez lancé les commandes précédentes.

Vous pouvez aussi récupérer le code source de PostGIS à partir du serveur svn de l'OSGeo http://svn.osgeo.org/postgis/trunk/.

Rendez-vous dans le nouveau répertoire postgis-1.4.0 pour continuer l'installation.

Le module PostGIS est une extension du serveur principal PostreSQL. En temps que tel, PostGIS 1.4.0 nécessite une accès à l'ensemble des fichiers d'entêtes (.h) du serveur PostgreSQL pour être compilé. Il peut être compilé en utilisant une version 8.2.0 ou supérieure de PostgreSQL. Les version plus ancienne de PostgreSQL ne sont pas supportées.

Référez vous aux guides d'installation de PostgreSQL si vous ne l'avez pas déjà installé http://www.postgresql.org.

LDFLAGS=-lstdc++ ./configure [VOS OPTIONS ICI]

Comme pour la plupart des installation Linux, la première étape consiste à générer le fichier Makefile qui sera utilisé pour compiler le code source. Cela est réalisé en lançant le script shell :

Sans paramètres supplémentaires, cette commande va tenter de localiser automatiquement les composants requis et les librairies nécessaires pour compiler le code source de PostGIS sur votre système. Bien que cela soit la manière standard d'utiliser le script configure, ce script supporte de nombreux paramètres pour ceux qui auraient installé les librairies nécessaires et les programmes dans des répertoires non standard.

La liste suivante présentent seulement les paramètres les plus couramment utilisés. Pour obtenir une liste complète des paramètres existant, utilisez le paramètre --help our --help=short.

--prefix=PREFIX

C'est le répertoire où seront installé les librairies et les scripts SQL de PostGIS. Par défaut, ce répertoire est le même que celui détecté de votre installation de PostgreSQL.

Attention : ce paramètre n'est actuellement pas opérationel, étant donné que le paquet va être installer dans le répertoire de votre installation de PostgreSQL. Consultez cette page : http://trac.osgeo.org/postgis/ticket/160 pour suivre l'état d'avancement de la résolution de ce problème.

--with-pgconfig=FICHIER

PostgreSQL fournit un utilitaire appelé pg_config pour permettre aux extensions comme PostGIS de récupérer le répertoire d'installation de PostgreSQL. Utilisez ce paramètre (--with-pg_config=/chemin/vers/pg_config) pour spécifier manuellement un répertoire d'installation de PostgreSQL spécifique à utiliser pour compiler PostGIS.

--with-geosconfig=FICHIER

GEOS, une librairie géométrique requise, fournit un utilitaire appelé geos-config qui permet au logiciels de récupérer le répertoire d'installation de GEOS. Utilisez ce paramètre (--with-geosconfig=/chemin/vers/geos-config) pour spécifier manuellement le répertoire d'installation de la version spécifique de GEOS avec laquelle vous souhaitez compilet PostGIS.

--with-projdir=RÉPERTOIRE

Proj4 est la librairie de reprojection requise par PostGIS. Utilisez ce paramètre (--with-projdir=/chemin/vers/le_repertoire_de_proj) pour spécifier manuellement le répertoire d'installation de la version de Proj4 spécifique avec laquelle vous souhaitez compiler PostGIS.
description

--with-gui

Compiler l'interface graphique d'inportation de données (nécessite GTK+ 2.0). Cela créera l'interface graphique pour shp2pgsql intitulée : shp2pgsql-gui

Une fois que le fichier Makefile a été produit, compiler PostGIS est aussi simple que de lancer la commande suivante :
make
La dernière ligne affichée devrait être "PostGIS was built successfully. Ready to install".
Depuis la version 1.4.0 de PostGIS, toutes les fonctions ont des commentaires générés à partir de la documentation. Si vous souhaitez installer ces commentaires dans votre base de données plus tard, utilsez la commande suivante :
make comments

Si vous souhaitez tester votre compilation de PostGIS, lancez la commande suivante

La commande ci-dessus va exécuter de nombreuses vérification et des tests de régressions en utilisant la librairie compilée avec la base PostgreSQL actuelle.

Si tout s'est bien passé, la sortie des vérifications devrait ressembler à ceci :

Pour installer PostGIS, lancez la commande suivante :

Cela va copier les fichiers d'installation de PostGIS dans leur répertoires respectifs par rapport au paramètre --prefix spécifié lors de la configuration. En particulier :

• les binaires de l'importeur et de l'exporteur seront installés dans le répertoire [prefix]/bin.
• Les fichiers SQL, comme lwpostgis.sql, seront installés dans le répertoire [prefix]/share/contrib/.
• Les librairies PostGIS seront installées dans le répertoire [prefix]/lib.

Si vous aviez précédemment lancer la commande make comments pour générer le fichier postgis_comments.sql, installez le fichier en lançant la commande :

La première étape pour créer une base de données PostGIS est de créer une simple base de données PostgreSQL.

Bon nombre de fonctions de PostGIS sont écritent dans le language procédural PL/pgSQL. Ainsi, la prochaine étape pour créer une base données PostGIS consiste a charger le support du langage PL/pgSQL dans votre nouvelle base de données. Ceci se fait en utilisant la commande ci-dessous.

Maintenant chargez les objets et les définitions de fonctions PostGIS dans votre base de données en utilisant le fichier de définition postgis.sql (installé dans le répertoire [prefix]/share/contrib spécifié lors de l'étape de configuration).

Pour obtenir un ensemble complet des identifiants de système de références spatiales, vous pouvez aussi charger le fichier de définition spatial_ref_sys.sql et remplir ainsi la table spatial_ref_sys. Cela vous permettra d'utiliser la fonction ST_Transform() sur vos objets géographiques.

Si vous souhaitez ajouter les commentaires des fonctions PostGIS, l'étape finale consiste à charger le fichier de définitions postgis_comments.sql dans votre base de données. Les commentaires peuvent être vu simplement en utilisant la méta-commande \dd [nom_de_la_fonction] depuis le terminal interactif psql.

Certaines distributions de PostGIS (en particulier l'installeur de PostGIS pour Win32 >= 1.1.5) charge les fonctionalités de PostGIS dans une base de données modèle appelé template_postgis. Si la base template_postgis existe dans votre installation de PostgreSQL, l'installation rend alors possible pour les utilisateurs ou les applications la création de bases de données spatiales en utilisant une seule commande. Notez que dans les deux cas, l'utilisateur de la base de données doit posséder les droits nécessaires à la création de bases de données.

Depuis un shell :

Pour le code SQL :

ndrpf : bien entendu si vous utilisiez directement template1 à la place de tamplate_postgis vous pourriez simplement utiliser la commande suivante : createdb ma_base_spatiale pour créer une base de données spatiale PostGIS. Cependant il semble pertinent de considérer que toutes les bases de données de votre serveur PostgreSQL n'auront pas besoin des fonctionnalités spatiales de PostGIS. C'est pourquoi template_postgis est présenté ici.

La mise à jour d'une base de données spatiale existante peut être compliquée étant donné qu'elle implique le remplacement ou l'introduction de nouvelles définitions d'objets PostGIS.
Hélas toutes les définitions ne peuvent pas être facilement remplacées dans une base de données en production, donc parfois le meilleur moyen est encore de sauvegarder puis de recharger les données.
PostGIS fournit une procédure de mise à jour 'légère' (SOFT UPGRADE) pour les versions mineures ou réparant simplement des bugs, et une procédure 'complète' (HARD UPGRADE) pour les versions majeures.
Avant de tenter de mettre à jour postgis, il est toujours plus sûr de sauvegarder vos données. Si vous utilisez l'option -Fc de pg_dump, vous serez toujours capable de restaurer la sauvegarde avec une mise à jour 'complète'.

La mise à jour 'légère' consiste à charger le script lwpostgis_upgrade.sql dans votre base de données

Si une mise à jour 'légère' n'est pas possible, le script abandonnera et vous serez informé qu'une mise à jour 'complète' doit être effectuée, donc n'hésitez pas à essayer une mise à jour 'légère' en premier.

Note
Si vous ne trouvez pas le fichier lwpostgis_upgrade.sql, vous utilisez probablement une version antérieure à 1.1 et vous devrez générer ce fichier vous même. Cela se fait avec la commande suivante :

Par mise à jour 'complète' nous entendons une sauvegarde/rechargement complet des base de données ayant PostGIS d'activé. Vous avez besoin d'une mise à jour 'complète' lorsque le stockage des objets internes de PostGIS change ou lorsqu'une mise à jour 'légère' n'est pas possible.

L'annexe des notes de sorties de versions PostGIS signale pour chaque version si vous devez désinstaller/réinstaller (mise à jour complète) lors du changement de version.

PostGIS fournit un utilitaire pour restaurer une sauvegarde créée avec la commande pg_dump -Fc. Il est expérimental, donc rediriger sa sortie standard dans un fichier sera utile en cas de problèmes. La procédure est la suivante :

Créez une sauvegarde au "format-particulier" de la base que vous souhaitez mettre à jour (appelons là "ancienne_base")

Restaurez la sauvegarde pour mettre à jour postgis dans une nouvelle base de données. La nouvelle base n'a pas à exister. postgis_restore prend en charge les paramètres passés à createdb après le nom du fichier de sauvegarde et cela peut être utilisé, par exemple, si vous souhaitez utiliser un encodage de caractères différent de celui utilisé par défaut par votre serveur PostgreSQL. Appelons là "nouvelle_base" et utilisons l'encodage de caractères UNICODE :

Vérifiez que tous les objets de la sauvegarde ont réellement besoin d'être restaurés à partir de la sauvegarde et n'entre pas en conflit avec ceux définis dans lwpostgis.sql

Si vous mettez à jour PostgreSQL d'une version < 8.0 à une version >= 8.0 vous devrez sans doute supprimer les colones attrelid, carattnum et stats de la table geometry_columns, qui ne sont plus nécessaires. Les conserver ne pose pas de problèmes. LES SUPPRIMER ALORS QU'ON EN A BESOIN POSERA UN PROBLÈME !!!

La table spatial_ref_sys est restaurée à partir de la sauvegarde, pour être sur que vos ajouts particuliers seront conservés, mais ceux fournis pourraient contenir des modifications et donc vous devriez sauvegarder vos modifications, supprimer la table et insérer la nouvelle. Si vous aviez fait des ajouts, nous supposons que vous savez comment les sauvegarder avant la mise à jour de la table. La remplacer par la nouvelle se fait de la manière suivante :

Il y a plusieurs choses à vérifier lorsque votre installation ou votre mise à jour ne se déroule pas comme prévu.

1. Vérifiez que vous avez installé la version de PostgreSQL 8.1 ou plus récente, et que vous avez compilé PostGIS avec la même version des sources de PostgreSQL que la version de PostgreSQL que vous utilisez sur votre serveur en production. Des problèmes de références peuvent arriver lorsque votre distribution (Linux) a déjà installé une version de PostgreSQL, ou que vous aviez déjà installé précédemment une version de PostgreSQL que vous avez oublié. PostGIS fonctionne uniquement avec les version 8.1 et supérieures de PostgreSQL, et bizarrement, des messages d'erreurs innattendus peuvent apparaître si vous utilisez une version plus ancienne. Pour vérifier la version de PostgreSQL que vous utilisez, connectez vous à la base de données en utilisant psql et exécutez la requête : SELECT version();. Si vous utilisez une distribution basé sur RPM, vous pouvez vérifier la présence des paquets installés en utilisant la commande rpm de la façon suivante : rpm -qa | grep postgresql.

Vérifiez aussi que le script configure a correctement détecté les répertoire d'installation et les versions de PostgreSQL et des librairies Proj4 et GEOS.

1. Le script configure est utilisé pour produire un fichier postgis_config.h. Vérifiez que les vairables POSTGIS_PGSQL_VERSION, POSTGIS_PROJ_VERSION et POSTGIS_GEOS_VERSION ont la bonne valeur.

L'extension JDBC fournit des objets Java correspondant aux types internes de PostGIS. Ces objets peuvent être utilisés pour écrire des clients java qui interrogent la base de données PostGIS et dessinent ou effectuent des calculs sur les données SIG dans PostGIS.

1. Entrez dans le sous-répertoire java/jdbc des sources de PostGIS.
2. Lancez la commande ant. Copiez le fichier postgis.jar là où vous avez l'habitude de stocker vos bibliothèques java.

Les extensions JDBC nécessitent qu'un pilote JDBC pour PostgreSQL soit déjà installé dans votre CLASSPATH actuel durant la compilation. Si le pilote JDBC PostgreSQL est situé dans un répertoire non standard, vous pouvez spécifier le chemin d'installation du JAR du pilote JDBC en utilisant le paramètre -D de la manière suivante :

Les pilote JDBC PostgreSQL peuvent être télécharger depuis la page suivante : http://jdbc.postgresql.org.

L'exporteur et l'importeur de données sont compilés et installés automatiquement lors de la compilation de PostGIS. Pour les compiler et les installer manuellement :

L'importeur est appelé shp2pgsql, il permet de convertir des fichiers vecteurs (Shape) ESRI en SQL capables d'être chargés dans PostGIS/PostgreSQL. L'exporteur est appelé pgsql2shp et il permet de convertir des tables PostGIS (ou des requêtes) en fichiers vecteurs (Shape) ESRI.

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).

Avant 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) :

• Les arbres R dans PostgreSQL ne peuvent pas gérer des objets qui ont une taille de plus de 8K. Les index GiST le peuvent, en utilisant une astuce avec perte qui substitue l'objet géographique par son cadre limite.
• Les arbres R dans PostgreSQL n'acceptent pas de valeurs null, ce qui implique que construire un index sur une colonne géométrique qui contient une valeur null échouera.

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).

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 :

• POINT(0 0)
• LINESTRING(0 0,1 1,1 2)
• POLYGON((0 0,4 0,4 4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1))
• MULTIPOINT(0 0,1 2)
• MULTILINESTRING((0 0,1 1,1 2),(2 3,3 2,5 4))
• MULTIPOLYGON(((0 0,4 0,4 4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 -2,-2 -2,-2 -1,-1 -1)))
• GEOMETRYCOLLECTION(POINT(2 3),LINESTRING((2 3,3 4)))

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 :

• POINT(0 0 0) -- XYZ
• SRID=32632;POINT(0 0) -- XY avec un SRID
• POINTM(0 0 0) -- XYM
• POINT(0 0 0 0) -- XYZM
• SRID=4326;MULTIPOINTM(0 0 0,1 2 1) -- XYM avec un SRID
• MULTILINESTRING((0 0 0,1 1 0,1 2 1),(2 3 1,3 2 1,5 4 1))
• POLYGON((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0))
• MULTIPOLYGON(((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0)),((-1 -1 0,-1 -2 0,-2 -2 0,-2 -1 0,-1 -1 0)))
• GEOMETRYCOLLECTIONM(POINTM(2 3 9),LINESTRINGM((2 3 4,3 4 5)))

Les entrées/sorties dans ces formats sont disponibles via les interfaces suivantes :

• bytea EWKB = ST_asEWKB(geometry);
• text EWKT = ST_asEWKT(geometry);
• geometry = ST_GeomFromEWKB(bytea EWKB);
• geometry = ST_GeomFromEWKT(text EWKT);

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(0 0, 1 1, 1 0)
  CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)
  Le type 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.
• COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))
  Une courbe composée est une courbe simple et continue qui a à la fois des segments courbes (circulaires) et des segments linéaires. Cela signifie que en plus d'avoir des composants bien formés, le point final de chaque composant (à l'exception du dernier) doit coincider avec le point de départ de l'élément suivant.
• CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1, 1 1))
  Exemple de courbes composée dans un polygone courbe : CURVEPOLYGON(COMPOUNDCURVE(CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),(4 3, 4 5, 1 4, 0 0)), CIRCULARSTRING(1.7 1, 1.4 0.4, 1.6 0.4, 1.6 0.5, 1.7 1) )
  Un objet de type 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.
  Depuis sa version 1.4 PostGIS supporte les coubres composées dans un polygon courbe.
• MULTICURVE((0 0, 5 5),CIRCULARSTRING(4 0, 4 4, 8 4))
  Un objet de type MULTICURVE est une collection de courbes, qui peut contenir des lignes, des courbes et des courbes composées.
• MULTISURFACE(CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1, 1 1)),((10 10, 14 12, 11 10, 10 10),(11 11, 11.5 11, 11 11.5, 11 11)))
  C'est une collection de surfaces qui peut contenir des polygones linéaires ou courbes.

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.

La 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 :

• SRID : Un entier qui identifie de façon unique le système de références spatiales (SRS) de la base.
• AUTH_NAME : Le nom du système de référence. Par exemple, "EPSG"
• AUTH_SRID : L'identifiant du SRS définie par l'autorité cité dans le AUTH_NAME. Dans le cas "EPSG", c'est celui pour lequel on utilise EPSG.
• SRTEXT : La représentation Well-Known Text (WKT) du SRS. Exemple:
  
  PROJCS["NAD83 / UTM Zone 10N",
  GEOGCS["NAD83",
  DATUM["North_American_Datum_1983",
  SPHEROID["GRS 1980",6378137,298.257222101]
  ],
  PRIMEM["Greenwich",0],
  UNIT["degree",0.0174532925199433]
  ],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["latitude_of_origin",0],
  PARAMETER["central_meridian",-123],
  PARAMETER["scale_factor",0.9996],
  PARAMETER["false_easting",500000],
  PARAMETER["false_northing",0],
  UNIT["metre",1]
  ]

  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.

• PROJ4TEXT : PostGIS utilise la librairie Proj4 pour offrir les possibilités de transformations de coordonnées. La colonne PROJ4TEXT contient les définitions de coordonnées Proj4 pour un SRID particulier. Exemple:
  +proj=utm +zone=10 +ellps=clrk66 +datum=NAD27 +units=m
  Pour plus d'information, voir Le site web Proj4.

Le 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 :

• F_TABLE_CATALOG, F_TABLE_SCHEMA, F_TABLE_NAME : le nom totalement qualifié de la table de propriétés contenant la colonne géométrique. Notez que le terme de "catalog" et "schema" sont propre à Oracle. Il n'y a pas d'équivalent à "catalog" dans PostgreSQL, cette colonne reste donc vide -- en ce qui concerne "schema", le nom du schema PostgreSQL est utilisé (la valeur par défaut est public).
• F_GEOMETRY_COLUMN : le nom de la colonne géométrique dans la table propriété.
• COORD_DIMENSION : la dimention spatiale (2,3 ou 4) de la colonne.
• SRID : l'identifiant du système de référence spatiale utilisée pour les coordonnées géométiques dans cette table. C'est une clef étrangère faisant référence à la table SPATIAL_REF_SYS.
• TYPE : le type d'objet géographique. Pour réstreindre la colonne spatiale à un type unique, utilisez l'un des types : POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION ou les versions correspondante XYM : POINTM, LINESTRINGM, POLYGONM, MULTIPOINTM, MULTILINESTRINGM, MULTIPOLYGONM, GEOMETRYCOLLECTIONM. Pour des types de collections hétérogènes (contenant plusieurs types), vous pouvez utiliser "GEOMETRY" comme type.
  NOTE :
  Cet attribut ne fait (probablement) pas partie des spécifications de l'OpenGIS, mais est requit pour assurer l'homégénéïté des types.

Créer une table avec des données géographiques se déroule en deux étapes :

1. Créer une table (non-spatialisée) normale. Par exemple : CREATE TABLE ROADS_GEOM ( ID int4, NAME varchar(25) )
2. Ajouter à la table la colonne spatiale en utilisant la fonction "AddGeometryColumn" de l'OpenGIS.
   La syntaxe est la suivante :
   
   AddGeometryColumn(<nom_du_schema>, <nom_de_la_table>,
                     <nom_de_la_colonne>, <srid>, <type>,
                     <dimension>)
   Ou, en utilisant le schéma courant :
   
   AddGeometryColumn(<nom_de_la_table>,<nom_de_la_colonne>,
                     <srid>, <type>, <dimension>)

   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).

Si 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 :

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.

L'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 :

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).

• Les arbres B sont utilisés pour les données qui peuvent être ordonnés sur un axes ; par exemple, les nombres, les lettres, les dates. Les données SIG ne peuvent pas rationnellement être ordonnées de cette manière (qui est plus grand, (0,0) ou (0,1) ou (1,0) ?) donc les indexation avec des arbres B n'est pas utile pour nous.
• Les arbres R répartissent les données en rectangles, et sous-rectangles, et sous-sous rectangles, etc. Les arbres R sont utilisés par certaine bases de données spatiales pour indexer les données SIG, mais l'implémentation des arbres R dans PostgreSQL n'est pas aussi robust que l'implémentation des GiST.
• Les arbres de recherches généralisés (GiST) répartissent les données dans des "les choses à coté", "les choses qui couvrent", "les choses qui sont incluses" et peuvent être utilisés pour un grand nombre de type de données, et notamment les données SIG. PostGIS utilise un arbre R implémenté au dessus du GiST pour indexer les données SIG.

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 :

• Premièrement, assurez vous que les statistiques sont bien au courant du nombre et des distributions de valeurs dans une table, pour fournir de meilleures informations au planificateur de requêtes afin qu'il soit apte à prendre la décision d'utiliser ou non l'index. Pour les installations de PostgreSQL 7.4 et inférieur ceci est fait en exécutant : 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.
• Si le nettoyage ne fonctionne pas, vous pouvez obliger le planificateur de requêtes à utiliser l'index en utilisant la commande : 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.

Lorsque 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 :

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 :

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.

• La page d'accueil de Mapserver est ici : http://mapserver.gis.umn.edu.
• Les spécifications "Web Map Server" de l'OpenGIS se trouve ici : http://www.opengis.org/techno/specs/01-047r2.pdf.

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 :

• La version 0.6 ou supérieure de PostGIS.
• La version 3.5 ou supérieure de Mapserver.

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).

1. Compilez et installez Mapserver, avec les supports qui vous souhaitez activer, incluant l'option de configuration : "--with-postgis".
2. Dans votre fichier map de Mpaserver, ajouté une couche PostGIS. Par exemple :
   
   LAYER
     CONNECTIONTYPE postgis
     NAME "widehighways"
     # Connect to a remote spatial database
     CONNECTION "user=dbuser dbname=gisdatabase host=bigserver"
     # Get the lines from the 'geom' column of the 'roads' table
     DATA "geom from roads"
     STATUS ON
     TYPE LINE
     # Of the lines in the extents, only render the wide highways
     FILTER "type = 'highway' and numlanes >= 4"
     CLASS
       # Make the superhighways brighter and 2 pixels wide
       EXPRESSION ([numlanes] >= 6)
       COLOR 255 22 22
       SYMBOL "solid"
       SIZE 2
     END
     CLASS
       # All the rest are darker and only 1 pixel wide
       EXPRESSION ([numlanes] < 6)
       COLOR 205 92 82
     END
   END
   
   

   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".

3. Dans votre base de données spatiale, assurez vous que vous avez des indexes spatiaux (GiST) pour chaque couches que vous souhaitez afficher.
   
   CREATE INDEX [nom_de_l_index]
   ON [nom_de_la_table]
   USING GIST ( [colonne_géometrique] GIST_GEOMETRY_OPS );
4. Si vous allez interroger vos couches en utilisant Mpaserver vous aurez aussi besoin d'un "index oid".
   Mapserver requière des indentifiants uniques pour chaque enregistrement spatial lorsque vous souhaitez effetuer des interrogations, et le module PostGIS de Mapserver utilise les valeurs d'oid de PostgreSQL pour fournir ces identifiants uniques. Cela implique comme effet de bord que si vous souhaitez effectuer des accès aléatoires rapides aux enregistrements durant les requêtes, un index sur les oid est necessaires.
   Pour construire un tel index, utilisez la requête SQL suivante :
   
   CREATE INDEX [nom_de_l_index] ON [nom_de_la_table] ( oid );

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 :

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".

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.

Les versions actuelles de PostgreSQL (dont 8.0) souffrent d'un défaut de l'optimiseur de requêtes en ce qui concerne les tables TOAST. Les tables TOAST sont une sorte
d'"espace supplémentaire" servant à stocker de "grandes" valeurs (grandes au sens de la taille des données) qui ne peuvent loger dans des pages de données normales (comme les longs textes, les images, ou les géométries complexes comportant un grand nombre d'arcs), voir http://www.postgresql.org/docs/8.0/static/storage-toast.html pour plus d'information).
Le problème apparait si vous possédez une table avec des géométries de taille importantes, mais avec peu de tuples (par exemple une table contenant les frontières des pays européens en haute résolution). La table elle-même est relativement petite, mais elle utilise énormément d'espace TOAST. Dans notre exemple, la table compte environ 80 lignes (ou tuples), et n'utilise que 3 pages de données, mais la table TOAST utilise 8225 pages.
A présent, essayez de lancer une requête en utilisant l'opérateur géométrique && pour rechercher une boite englobante qui ne comprend que quelques-uns de ces tuples.
L'optimiseur de requête constate que votre table ne compte que 3 pages et 80 lignes. Il estime par conséquent qu'un scan séquentiel sur une si petite table est beaucoup plus rapide que d'utiliser un index. Et il choisir d'ignorer l'index GIST. D'ordinaire, son estimation est juste mais dans notre cas, l'opérateur && doit aller récupérer chaque objet géométrique sur le disque pour comparer les boites englobantes, et il parcoure par la même occasion toutes les pages TOAST.
Pour vérifier si vous pâtissez de ce bogue, utilisez la commande "EXPLAIN ANALYZE" de postgresql. Pour plus d'informations et des détails techniques, vous pouvez lire ce sujet sur la liste de discussion des performances de postgres : http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php

Les développeurs de PostgreSQL essayent de résoudre ce problème en faisant en sorte que l'estimateur de la requête prenne en considération l'espace TOAST. Pour le moment, voici deux solutions de contournement :

La première est de forcer le préparateur de requête à utiliser l'index. Envoyez "SET enable_seqscan TO off;" au serveur avant de lancer la requête. Cela force le préparateur de requête à éviter les scans séquentiels intempestifs lorsque c'est possible. Il utilise alors l'index GIST comme d'habitude. Cependant, ce drapeau doit être fixé à chaque connexion, et il conduit le préparateur de requête à faire des erreurs d'estimation dans d'autres cas de figure, il faut donc le remettre à "SET enable_seqscan TO on;" après la requête.

La seconde solution est de rendre le scan séquentiel aussi rapide que le préparateur de requête le pense. Cela peut se faire en créant un champ additionnel qui met la boîte englobante en cache, et de se servir de ce nouveau champ pour opérer les comparaisons. Dans notre exemple, les commandes sont :

Maintenant, changez votre requête en utilisant l'opérateur && sur la boîte englobante à la place de geom_column, comme suit:

Bien entendu, si vous changez ou ajoutez des lignes à mytable, vous devrez veiller à ce que la boîte englobante reste à jour. La façon la plus transparente de faire cela est par une moulinette automatique, mais vous pouvez aussi modifier votre application pour que le champ de la boîte englobante reste à jour de façon permanente ou lancer la requête UPDATE après chaque modification.

Pour des tables qui sont essentiellement en lecture seule et où un simple index sert à la majorité des requêtes, PostgreSQL offre la commande CLUSTER. Cette commande réordonne physiquement toutes les lignes de données dans l'ordre du critère de l'index, ce qui offre deux avantages du point de vue des performances. D'abord pour les scans d'index, le nombre de recherche dans la table est considérablement réduit. Deuxièmement, si votre ensemble de travaille ne concerne que de petits intervalles sur l'index, vous obtenez une recherche plus efficace car les données sont dispersées sur moins de pages. (Merci de vous référer à la documentation de la commande CLUSTER du manuel PostgreSQL pour davantage d'informations).

Cependant, PostgreSQL ne permet actuellement pas le clustering sur les index GIST de PostGIS car les index GIST ignorent les valeurs NULL, vous obtenez un message d'erreur du type :

Comme le message vous le spécifie, on peut contourner cet inconvénient en ajoutant une contrainte NOT NULLl à la table :

Bien sûr, cela ne fonctionnera pas si vous avez de fait besoin de valeurs NULL dans votre colonne de géométrie. En plus vous devez donc utiliser la méthode ci-dessus pour ajouter la contrainte, utiliser une vérification du style ALTER TABLE blubb ADD CHECK (geometry is not null); ne fonctionnera pas.

Il arrive quelquefois que vous ayez des données 3D ou 4D dans votre table, mais vous n'y accéder qu'au travers de fonctions conformes aux standards de l'OpenGIS telles que Text() ou Binary() qui ne fournissent en sortie que des données géométriques 2D. Ces fonctions utilisent en effet un appel à la fonction force_2d(), qui induit une perte de temps pour les géométries de grandes tailles. Pour l'éviter, vous pouvez au préalable vous débarrasser des dimensions superflues une bonne fois pour toutes en exécutant :

Veuillez noter que si vous avez ajouter votre champ géométrique au moyen de AddGeometryColumn() vous subirez une contrainte sur la dimension géométrique.

Pour la dépasser, vous devrez d'abord lever la contrainte. Rappelez-vous ensuite de mettre à jour l'entrée de la table geometry_columns et de recréer par la suite la contrainte.

Dans le cas de manipulation de grandes tables, il est préférable de diviser l'UPDATE entre plus petites parties en restreignant l'UPDATE à une partie de la table au moyen d'une clause WHERE et de votre clef primaire, ou d'un autre critère quelconque, et d'exécuter un simple nétoyage ("VACUUM;") entre vos UPDATEs. Cela réduit votre besoin temporaire en espace disque de manière radicale. De plus, si vous avez des données géométriques avec différentes dimensions, restreindre l'UPDATE à "WHERE dimension(the_geom)>2" vous évite de réécrire les géométries qui sont d'ores et déjà en 2D.

Les fonctions listées ci-dessous font partie de celles qu'un utilisateur PostGIS utilise couramment. Il existe d'autres fonctions qui servent à la manipulation d'objets PostGIS mais qui ne sont d'aucune utilité à l'utilisateur Lambda.

AddGeometryColumn(varchar, varchar, varchar, integer, varchar, integer)

Syntax : AddGeometryColumn(<nom_du_schema>, <nom_de_la_table>, <nom_de_la_colonne>, <srid>, <type>, <dimension>). Ajouter une colonne géométrique aux attributs d'une table existante. Le nom du schéma est le nom du schéma de la table (inutilisé pour les installations de PostgreSQL ne supportant pas les schémas). Le SRID doit être une valeur entière faisant référence à une entrée de la table spatial_ref_sys. Le type doit être une chaine de caractères en majuscule correspondant au type géométrique, par exemple, POLYGON ou MULTILINESTRING.

DropGeometryColumn(varchar, varchar, varchar)

Syntax : DropGeometryColumn(<nom_du_schema>, <nom_de_la_table>, <nom_de_la_colonne>). Supprimer une colonne géométrique d'une table spatiale. Notez que le nom_du_schéma devra correspondre au champ f_schema_name du tuple correspondant dans la table geometry_columns.

SetSRID(geometry, integer)

Attribut au SRID sur une géométrie une valeur entière particulière. Utile pour construire des cadres limites pour des requêtes.

Distance(geometry, geometry)

Renvoie la distance cartésienne entre deux géométries dans l'unité de projection.

Equals(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries passées en paramètres sont "spatialement égales". Utilisez ceci pour un meilleur résultat que l'opération '='. equals('LINESTRING(0 0, 10 10)','LINESTRING(0 0, 5 5, 10 10)') est vrai.
OGC SPEC s2.1.1.2

Disjoint(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries sont spatialement disjointes.
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 //s2.1.13.3 - a.Relate(b, 'FF*FF****')

Intersects(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries "s'intersectent spatialement"
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 //s2.1.13.3 - Intersects(g1, g2 ) --> Not (Disjoint(g1, g2 ))

Touches(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries se "touchent spatialement".
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3- a.Touches(b) -> (I(a) intersection I(b) = {empty set} ) and (a intersection b) not empty

Crosses(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries se "croisent spatialement".
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3 - a.Relate(b, 'T*T******')

Within(geometry A, geometry B)

(Effectué par le module GEOS) : retourne 1 (vrai) si la géométrie A est "spatialement inclue" dans la géométrie B.
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3 - a.Relate(b, 'T*F**F***')

Overlaps(geometry, geometry)

(Effectué par le module GEOS) : retourne 1 (vrai) si les géométries se superposent spatialement.
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3

Contains(geometry A, geometry B)

(Effectué par le module GEOS) : retourne 1 (vrai) si la géométrie A "contient spatialement" la géométrie B.
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3 - same as within(geometry B, geometry A)

Relate(geometry, geometry, intersectionPatternMatrix)

(Effectué par le module GEOS) : retourne 1 (vrai) si cette géométries est spatialement reliée à une autre géométrie, en testant l'intersections entre l'intérieur, la limite et l'extérieur des deux géométries comme spécifié par les valeurs dans l'intersectionPatternMatrix.
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
OGC SPEC s2.1.1.2 // s2.1.13.3

Relate(geometry, geometry)

(Effectué par le module GEOS) : retourne la DE-9IM (la neuvième matrice d'intersection dimentionellement étendue)
Ne pas appeler avec une GeometryCollection en argument.
NOTE : c'est la version "permissive" qui retourne un booléen, pas un entier.
pas dans les specs de l'OGC, mais implémenté. voir s2.1.13.2

Centroid(geometry)

Renvoie le barycentre de l'entité géométrique sous forme de point. Le calcul sera plus précis si vous utilisez le module GEOS (mis en place au moment de la compilation).

Area(geometry)

Renvoie la superficie de l'entité géométrique s'il s'agit d'un polygone ou d'un multi-polygone.

Length(geometry)

Renvoie la longueur d'un segment dans son système de référencement courant. Synonyme de length2d().
OGC SPEC 2.1.5.1

PointOnSurface(geometry)

Renvoie un point situé en surface.
Implémenté grâce à GEOS.
OGC SPEC 3.2.14.2 and 3.2.18.2 -

Boundary(geometry)

Renvoie le contour fermé du graphe de cet objet géométrique (geometry). Le graphe (combinatorial boundary) se définit comme décrit aux sections 3.12.3.2 des spécifications OGC. Comme le résultat de cette opération est un contour fermé, et par conséquent topologiquement fermé, le contour résultant peut se représenter au moyen des primitives géométriques décrites à la section 3.1.2.2. des spécifications OGC.
Exécuté par le module GEOS.
OGC SPEC s2.1.1.1

Buffer(geometry, double, [integer])

Renvoie un objet géométrique qui représente tous les points dont la distance à l'objet géométrique est inférieure ou égale à la distance fixée. Les calculs se font dans le système de référencement courant de cet objet géométrique. Le troisième paramètre optionnel fixe le nombre de segments à utiliser pour fournir une approximation du cercle quadratique (par défaut 8 ).
Exécuté par le module GEOS.
Ne l'appelez jamais avec une GeometryCollection en argument.
OGC SPEC s2.1.1.3

ConvexHull(geometry)

Renvoie un objet de type geometry qui représente la partie convexe de la géométrie passée en argument.
Exécuté par le module GEOS.
OGC SPEC s2.1.1.3

Intersection(geometry, geometry)

Renvoie un objet géométrique qui représente l'ensemble d'intersection des objets géométriques désignés.
Exécuté par le module GEOS.
Ne l'appelez jamais avec une GeometryCollection en argument
OGC SPEC s2.1.1.3

SymDifference(geometry A, geometry B)

Renvoie un objet géométrique qui représente l'ensemble d'exclusion de l'objet géométrique A avec l'objet géométrique B.
Ne l'appelez jamais avec une GeometryCollection en argument.
OGC SPEC s2.1.1.3

Difference(geometry A, geometry B)

Renvoie un objet géométrique qui représente l'ensemble de différence entre l'objet géométrique A et l'objet géométrique B.
Exécuté par le module GEOS.
Ne l'appelez jamais avec une GeometryCollection en argument.
OGC SPEC s2.1.1.3

GeomUnion(geometry, geometry)

Renvoie un objet géométrique qui représente l'ensemble d'union des objets géométriques désignés.
Exécuté par le module GEOS.
Ne l'appelez jamais avec une GeometryCollection en argument.
NOTE : initialement nommé "union", cette fonction a été renommé GeomUnion car Union est un mot-clef SQL.
OGC SPEC s2.1.1.3

GeomUnion(geometry set)

Renvoie un objet géométrique qui représente l'union de l'ensemble des objets géométriques pour un ensemble donné.
Exécuté par le module GEOS.
Ne l'appelez jamais avec une GeometryCollection en argument.
Non défini de façon explicite dans les OGC SPEC

MemGeomUnion(geometry set)

Identique à la fonction ci-dessus, mais travaille en utilisant moins de mémoire et plus de temps de calcul du processeur.

AsText(geometry)

Renvoie la représentation textuelle de l'objet géométrique. Par exemple : POLYGON(0 0,0 1,1 1,1 0,0 0)
OGC SPEC s2.1.1.1

AsBinary(geometry)

Renvoie la géométrie au format binaire de l'OGC, en utilisant l'encodage endian (small endian/big endian) du serveur sur lequel la base de données tourne. C'est utile dans le cas de parseurs binaires, pour extraire des données de la base sans avoir à les convertir en chaines de caractères.
OGC SPEC s2.1.1.1 - voir aussi asBinary(,'XDR') et asBinary(,'NDR')

SRID(geometry)

Renvoie l'entier SRID du système de référence spatial de l'objet géométrique.
OGC SPEC s2.1.1.1

Dimension(geometry)

La dimension propre à l'objet géométrique, qui doit être inférieure ou égale à la dimension de ses coordonnées. OGC SPEC s2.1.1.1 - renvoie 0 pour des points, 1 pour des lignes, 2 pour des polygones, et la plus grande dimension trouvée parmi les composants d'une GEOMETRYCOLLECTION.

select dimension('GEOMETRYCOLLECTION(LINESTRING(1 1,0 0),POINT(0 0)');

 dimension
-----------
 1

Envelope(geometry)

Renvoie un POLYGON représentant le cadre limite de l'objet géométrique.
OGC SPEC s2.1.1.1 - Le cadre limite minimale de cet objet géométrique, retournée sous forme de géométrie. Le polygone est défini par les angles du cadre limite ((MINX, MINY), (MAXX, MINY), (MAXX, MAXY), (MINX, MAXY), (MINX, MINY)).
NOTE : PostGIS ajoutera des coordonnées Zmin/Zmax aussi.

IsEmpty(geometry)

Renvoie vrai si la géométrie est vide. Si c'est vrai, Geometry représente alors l'ensemble vide - i.e. GEOMETRYCOLLECTION(EMPTY).
OGC SPEC s2.1.1.1

IsSimple(geometry)

Renvoie vrai si l'objet geometry ne comporte pas d'anomalies, telle qu'une auto-intersection ou une auto-tangence de l'objet.
Exécuté par le module GEOS
OGC SPEC s2.1.1.1

IsClosed(geometry)

Renvoie vrai si les points de départ et d'arrivée de l'objet géométrique coïncident.

IsRing(geometry)

Renvoie vrai si le contour est fermé (StartPoint ( ) = EndPoint ( )) et si le contour est simple (ne passe pas plus d'une fois par le même point).
Exécuté par le module GEOS
OGC spec 2.1.5.1

NumGeometries(geometry)

Si la géométrie est une GEOMETRYCOLLECTION (or MULTI*) renvoie le nombre d'objets géométriques, autrement renvoie NULL.

GeometryN(geometry,int)

Renvoie le nième objet géométrique si la géométrie est une GEOMETRYCOLLECTION, MULTIPOINT, MULTILINESTRING ou MULTIPOLYGON.
Sinon, renvoie NULL.
Note : l'index débute à 1conformément aux spécifications OGC depuis la version 0.8.0. Les versions antérieures débutaient à 0.

NumPoints(geometry)

Trouve et renvoie le nombre de points de la première ligne géométrique. Renvoie NULL s'il n'y a pas de ligne dans la géométrie.

PointN(geometry,integer)

Renvoie le nième point de la première ligne de la géométrie. Renvoie NULL s'il n'y a pas de ligne dans la géométrie.

Note : l'index débute à 1 conformément aux spécifications OGC depuis la version 0.8.0. Les versions antérieures débutaient à 0.

ExteriorRing(geometry)

Renvoie le pourtour extérieur de la géométrie d'un polygone. Retourne NULL si l'objet n'est pas un polygone.

NumInteriorRings(geometry)

Retourne le nombre de pourtours intérieurs du premier polygone de la géométrie. Renvoie NULL s'il n'y a aucun polygone dans la géométrie.

NumInteriorRing(geometry)

Équivalent à NumInteriorRings(geometry). Les spécifications OpenGIS donnent les deux appellations sans lever l'ambiguïté sur le nom réel de la fonction, nous fournissons par conséquent les deux appellations.

InteriorRingN(geometry,integer)

Renvoie le nième pourtour intérieur de la géométrie du polygone. Renvoie NULL si la géométrie n'est pas un polygone, ou si la valeur N ne se trouve pas dans l'intervalle considéré.

Note : l'index débute à 1conformément aux spécifications OGC depuis la version 0.8.0. Les versions antérieures débutaient à 0.

EndPoint(geometry)

Renvoie le dernier point d'une ligne géométrique en tant que point.

StartPoint(geometry)

Renvoie le premier point d'une ligne géométrique en tant que point.

GeometryType(geometry)

Renvoie le type géométrique sous forme de chaine. Par exemple : LINESTRING, POLYGON, MULTIPOINT, etc.
OGC SPEC s2.1.1.1 - Renvoie le nom du sous-type géométrique instanciable dont la géométrie fait partie. Le nom du sous-type géométrique instanciable est renvoyé sous forme de chaine.

X(geometry)

Renvoie la coordonnée X du point. L'objet en entrée doit être un point.

Y(geometry)

Renvoie la coordonnée Y du point. L'objet en entrée doit être un point.

Z(geometry)

Renvoie la coordonnée Z du point, ou NULL si la valeur n'est pas disponible. L'objet en entrée doit être un point.

M(geometry)

Renvoie la coordonnée M du point, ou NULL si la valeur n'est pas disponible. L'objet en entrée doit être un point.
Note : cela ne fait pas (encore) partie des spécifications OGC, mais on les donne ici afin de compléter la liste de fonctions d'extraction de coordonnées ponctuelles.

GeomFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité

PointFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est passé en paramètre, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un POINT.

LineFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas une LINE.

LinestringFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
Retourne une erreur si le WKT n'est pas une LINE.

PolyFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un polygone

PolygonFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un POLYGON.

MPointFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un MULTIPOINT.

MLineFromText(text,[<srid>]) :

Construit une géométrie à partir de WKT avec un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un MULTILINESTRING.

MPolyFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKT n'est pas un MULTIPOLYGON.

GeomCollFromText(text,[<srid>]) :

Construit une géométrie à partir d'un WKT et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un GEOMETRYCOLLECTION.

GeomFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.6.2 - l'option SRID correspond à la mise en conformité

GeomFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité

PointFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un POINT.

LineFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas une LINESTRING.

LinestringFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas une LINESTRING.

PolyFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un POLYGON.

PolygonFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir de WKB avec un SRID donné. Si aucun SRID n'est donné, on prend par défaut la valeur -1.
correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un POLYGON.

MPointFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un MULTIPOINT.

MLineFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, on prend par défaut la valeur -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un MULTILINESTRING.

MPolyFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, la valeur utilisée sera -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un MULTIPOLYGON.

GeomCollFromWKB(bytea,[<srid>]) :

Construit une géométrie à partir d'un WKB et d'un SRID donné. Si aucun SRID n'est donné, on prend par défaut la valeur -1.
OGC SPEC 3.2.7.2 - l'option SRID correspond à la mise en conformité
Retourne une erreur si le WKB n'est pas un GEOMETRYCOLLECTION.

BdPolyFromText(text WKT, integer SRID) :

Construit un polygone à partir d'une collection quelconque de polylignes fermées en tant que représentation texte MultiLineString.
Retroune une erreur si le WKB n'est pas un MULTILINESTRING. Retourne une erreur si la sortie est un MULTIPOLYGON; utilisez BdMPolyFromText dans ce cas, ou voyez BuildArea() pour une approche spécifique à PostGIS.
OGC SFSQL 1.1 - 3.2.6.2
Disponibilité : 1.1.0 - requiert GEOS >= 2.1.0.

BdMPolyFromText(text WKT, integer SRID) :

Construit un MULTIPOLYGON à partir d'une collection quelconque de polylignes fermées en tant que représentation texte MultiLineString.
Retourne une erreur si le WKT n'est pas un MULTILINESTRING. Forcez la sortie en MULTIPOLYGON même si le résultat ne comportte qu'un seul POLYGON; utilisez BdPolyFromText si vous êtes sûr qu'un seul POLYGON sortira de l'opération, ou voyez BuildArea() pour une approche spécifique à PostGIS.
OGC SFSQL 1.1 - 3.2.6.2
Disponibilité : 1.1.0 - requiert GEOS >= 2.1.0.

DropGeometryTable([<nom_de_schéma>], <nom_de_la_table>) :

Supprime une table ainsi que toutes ses références dans geometry_columns.

NOTE : utilise current_schema() pour des installations de PostgreSQL supportant les schémas si le schéma n'est spécifié.

UpdateGeometrySRID([<schema_name>], <table_name>, <column_name>, <srid>) :

Met à jour le SRID de toutes les propriétés dans une colonne géographique mettant à jour les contraintes et les références dans geometry_column.

NOTE : utilise current_schema() sur des installations PostgreSQL supportant les schémas si le schéma n'est pas spécifié.

update_geometry_stats([<table_name>, <column_name>]) :

Met à jour les statistiques concernant les tables spatiales qui seront utilisées par le planificateur de requête. Vous aurait aussi besoin d'exécuter : VACUUM ANALYZE [nom_de_la_table] [nom_de_colonne] pour compléter le processus de rapatriement des statistiques.

NOTE : à partir de la version 8.0 de PostgreSQL le rapatriement des statistiques est automatiquement effectué lors de l'exécution du VACUUM ANALYZE.

postgis_version() :

Renvoie le numéro de version de PostGIS et les options de compilation utilisées.

NOTE : avant la version 1.1.0 c'était une fonction procédurale, elle pouvait donc retourner des informations imprécises (dans le cas d'une mise à jour incomplète de la base de données).

postgis_lib_version() :

Renvoie le numéro de version de la bibliothèque PostGIS.
Disponible depuis la version : 0.9.0

postgis_lib_build_date() :

Renvoie la date de compilation de la bibliothèque PostGIS.
Disponible depuis la version : 1.0.0RC1

postgis_script_build_date() :

Renvoie la date de création des scripts PostGIS.
Disponible depuis la version : 1.0.0RC1

postgis_scripts_installed() :

Renvoie la version des scripts PostGIS installée dans la base de données.

NOTE : si le résultat de cette fonction ne correspond pas à celui obtenu avec postgis_scripts_released() cela signifie que vous avez sans doute oublié de mettre à jour convenablement vos bases de données existantes. Rapportez vous à la section "Mise à jour" du présent manuel pour de plus amples informations.

Disponible depuis la version : 0.9.0

postgis_scripts_released() :

Renvoie le numéro de version du script lwpostgis.sql fournit avec la bibliothèque PostGIS installée.

NOTE : à partir de la version 1.1.0, cette fonction renvoie la même valeur que postgis_lib_version(). Conservé pour des raisons de compatibilité arrière.

Disponible depuis la version : 0.9.0

postgis_geos_version() :

Renvoie le numéro de version de la bibliothèque GEOS, ou NULL si la gestion de GEOS n'est pas activée.
Disponible depuis la version : 0.9.0

postgis_jts_version() :

Renvoie le numéro de version de la bibliothèque JTS ou NULL si la gestion de JTS n'est pas activée.
Disponible depuis la version : 1.1.0

postgis_proj_version() :

Renvoie le numéro de version de la bibliothèque PROJ4 ou NULL si la gestion de PROJ4 n'est pas activée.
Disponible depuis la version : 0.9.0

postgis_uses_stats() :

Renvoie vrai si l'utilisation de STATS a été activé, faux sinon.
Disponible depuis la version : 0.9.0

postgis_full_version() :

Retourne la version complète de PostGIS et les informations de compilation.
Disponible depuis la version : 0.9.0

A &< B

L'opérateur "&<" renvoie vrai si le cadre limite de A "recouvre" ou "est à la gauche" du cadre limite de B.

A &> B

L'opérateur "&>" renvoie vrai si le cadre limite de A "recouvre" ou "est à la droite" du cadre limite de B.

A << B

L'opérateur "<<" renvoie vrai si le cadre limite de A est strictement à la gauche du cadre limite de B.

A >> B

L'opérateur ">>" renvoie vrai si le cadre limite de A est strictement à la droite du cadre limite de B.

A &<| B

L'opérateur "&<|" renvoie vrai si le cadre limite de A recouvre ou est en dessous du cadre limite de B.

A |&> B

L'opérateur "|&>" renvoie vrai si le cadre limite de A recouvre ou est au dessus du cadre limite de B.

A <<| B

L'opérateur "<<|" renvoie vrai si le cadre limite de A est strictement au dessous du cadre limite de B.

A |>> B

L'opérateur "|>>" renvoie vrai si le cadre limite de A est strictement au dessus du cadre limite de B.

A ~= B

L'opérateur "~=" est l'opérateur "même que". Il vérifie l'égalité géométrique de deux propriétés. Donc si A et B ont les même propriétés, point-par-point, l'opérateur retourne vrai.

A @ B

L'opérateur "@" renvoie vrai si le cadre limite de A est totalement inclus dans le cadre limite de B.

A ~ B

L'opérateur "~" renvoie vrai si le cadre limite de A contient entièrement le cadre limite de B.

A && B

L'opérateur "&&" est l'opérateur de superposition.Si le cadre limite de A recouvre le cadre limite de B, l'opérateur renvoie vraie.

area2d(geometry) :

renvoie la superficie d'un objet géométrique si c'est un polygone ou multi-polygone.

distance_sphere(point, point) :

renvoie la distance linéaire en mètre entre deux points en latitude/longitude. Utilise une Terre sphérique avec un rayon de 6370986 mètres. Plus rapide que distance_spheroid(), mais moins précis. N'est implémenté que pour des points.

distance_spheroid(point, point, spheroid) :

renvoie la distance linéaire en mètre entre deux points en latitude/longitude pour un sphéroïde donné. Voir l'explication sur les sphéroïdes donnés dans length_spheroid(). N'est implémenté que pour des points.

length2d(geometry) :

renvoie la longueur bi-dimensionnelle de l'objet géométrique si c'est un linestring ou multi-linestring.

length3d(geometry) :

renvoie la longueur tri-dimensionnelle de l'objet géométrique si c'est un linestring ou multi-linestring.

length_spheroid(geometry,spheroid) :

calcule la longueur d'un objet géométrique sur un ellipsoïde. C'est très pratique si les coordonnées de l'objet géométrique sont en latitude/longitude et qu'on veut connaitre la longueur sans avoir à reprojeter les données. L'ellipsoïde est un type spécifique de la base de données et peut se construire comme suit :

    SPHEROID[<NAME>,<SEMI-MAJOR AXIS>,<INVERSE FLATTENING>]

Par exemple :

    SPHEROID["GRS_1980",6378137,298.257222101]

Voici un exemple de calcul :

SELECT length_spheroid( geometry_column, 'SPHEROID["GRS_1980",6378137,298.257222101]' ) FROM geometry_table;

length3d_spheroid(geometry,spheroid) :

calcule la longueur de l'objet géométrique sur un ellipsoïde, en prenant en compte l'altitude. C'est exactement comme length_spheroid sauf que les coordonnées verticales (exprimées dans les mêmes unités que les valeurs d'axes du sphéroïde) sont utilisées pour calculer la distance supplémentaire ajoutée par le positionnement vertical.

distance(geometry, geometry) :

renvoie la distance la plus courte entre deux objets géométriques.

max_distance(linestring,linestring) :

renvoie la plus grande distance entre deux "line strings".

perimeter(geometry) :

renvoie le périmètre bi-dimensionnel d'un objet géométrique, si c'est un polygon ou un multi-polygon.

perimeter2d(geometry) :

renvoie le périmètre bi-dimensionnel d'un objet géométrique, si c'est un polygon ou un multi-polygon.

perimeter3d(geometry) :

renvoie le périmètre tri-dimensionnel d'un objet géométrique, si c'est un polygon ou un multi-polygon.

azimuth(geometry, geometry) :

renvoie l'azimut du segment défini par les géométries des points désignés, ou NULL si les deux points sont superposés. La valeur retournée est en radians. Disponibilité : 1.1.0

AsBinary(geometry,{'NDR'|'XDR'}) :

Renvoie la géométrie au format "binaire bien connu" de l'OGC en temps que bytea, en utilisant l'encodage little-endian (NDR) ou big-endian (XDR). C'est utile avec les curseurs binaires pour extraire de la base des données sans avoir à les convertir en chaine de caractères.

AsEWKT(geometry) :

Renvoie la géométrie au format EWKT (en tant que text).

AsEWKB(geometry, {'NDR'|'XDR'}) :

Renvoie la géométrie au format EWKB (en tant que bytea ) en utilisant soit l'encodage little-endian (NDR) soit big-endian (XDR).

AsHEXEWKB(geometry, {'NDR'|'XDR'}) :

Renvoie la géométrie au format HEXEWKB (en tant que text ) en utilisant soit l'encodage little-endian (NDR) soit big-endian (XDR).

AsSVG(geometry, [rel], [precision]) :

Renvoie la géométrie sous forme de donnée chemin SVG. Utilisez 1 comme second paramètre pour obtenir la donnée chemin représentée en terme de mouvements relatifs, la valeur par défaut (0) utilise le mouvement absolu. Le troisième argument peut être utilisé pour réduire le nombre maximal de chiffres après la virgule à utiliser dans le résultat (sa valeur par défaut est 15). Les points seront représentés sous la forme cx/cy si le paramètre "rel" vaut 0 et x/y lorsque "rel" vaut 1.

AsGML(geometry, [precision]) :

Renvoie la géométrie en temps qu'élément GML. Le second paramètre peut être utilisé pour réduire le nombre maximum de chiffres après la virgule à utiliser dans le résultat (par défaut sa valeur est 15).

AsKML(geometry, [precision]) :

Renvoie la géométrie en temps qu'élément KML. Le second paramètre peut être utilisé pour réduire le nombre maximum de chiffres après la virgule à utiliser dans le résultat (par défaut sa valeur est 15).

GeomFromEWKT(text) :

Construit une géométrie à partir de EWKT.

GeomFromEWKB(bytea) :

Construit une géométrie à partir de EWKB.

MakePoint(<x>, <y>, [<z>], [<m>]) :

Construit une géométrie de points 2d,3dz ou 4d.

MakePointM(<x>, <y>, <m>) :

Construit une géométrie de points 3dm.

MakeBox2D(<LL>, <UR>) :

Construit une BOX2D définie par la géométrie de points 2D.

MakeBox3D(<LLB>, <URT>) :

Construit une BOX3D définie par la géométrie de points 2D.

MakeLine(geometry set) :

Construit une Linestring à partir d'un ensemble de points géométriques. Vous aurez probablement besoin d'utiliser un sous-ensemble pour les ordonner avant de les traiter au moyen de cette fonction.

MakeLine(geometry, geometry) :

Construit une Linestring à partir de deux points géométriques donnés.

LineFromMultiPoint(multipoint) :

Construit une LineString à partir d'une géométrie MultiPoint.

MakePolygon(linestring, [linestring[]]) :

Construit un Polygon formé de l'enveloppe donnée et d'une liste de trous. Vous pouvez construire cette liste en utilisant Accum. Les objets géométriques choisis doivent être des contours LINESTRINGS fermés (voir IsClosed et GeometryType).

BuildArea(geometry) :

Construit une géométrie surfacique formée par le contour d'un objet géométrique donné. Le type renvoyé peut être un Polygon ou un Multipolygon, tout dépend de l'objet géométrique en entrée. Si l'objet en entrée ne forme pas un polygone, la fonction renvoie NULL.

Voir aussi BdPolyFromText et BdMPolyFromText - interface de cette fonction aux stantards OGC.

Disponibilité : 1.1.0 - requiert GEOS >= 2.1.0.

Polygonize(geometry set) :

Agrégat. Construit une GeometryCollection contenant des polygones potentiels formés à partir des contours d'un ensemble d'objets géométriques.

Disponibilité : 1.0.0RC1 - requiert GEOS >= 2.1.0.

Collect(geometry set) :

Cette fonction renvoie une GEOMETRYCOLLECTION ou un objet MULTI à partir d'un ensemble d'objets géométriques. La fonction collect() est une fonction "aggrégative" dans la terminologie de PostgreSQL. Cela signifie qu'elle opère sur des listes de données, de la même façon que les fonctions sum() et mean(). Par exemple, "SELECT COLLECT(GEOM) FROM GEOMTABLE GROUP BY ATTRCOLUMN" va renvoyer une GEOMETRYCOLLECTION séparée pour chaque valeur distincte de ATTRCOLUMN.

Collect(geometry, geometry) :

Cette fonction renvoie une géométrie qui est la collection de deux géométries en entrée. Le type en sortie peut être un MULTI* ou une GEOMETRYCOLLECTION.

Dump(geometry) :

Il s'agit d'une fonction retournant un ensemble (SRF). Elle renvoie un ensemble de lignes de geometry_dump, formée par une géométrie (geom) et un tableau d'entier (path). Quand la géométrie en entrée est un type simple (POINT,LINESTRING,POLYGON), on obtiendra en sortie un seul enregistrement avec un tableau vide et la géométrie donnée en entrée comme geom. Quand la géométrie en entrée est une collection ou multi, on obtiendra un enregistrement pour chacun des composants de la collection, et le chemin indiquera la position de chaque composant à l'intérieur de la collection.

NOTE : cette fonction n'est pas accessible en compilant avec PostgreSQL 7.2.x

AddBBOX(geometry) :

Ajoute le cadre limite à une géométrie. Cela devrait rendre les requêtes basées sur le cadre limite plus rapide, mais cela augmentera la taille de la géométrie.

DropBBOX(geometry) :

Supprimer le cache du cadre limite de la géométrie. Cela réduit la taille de la géométrie, mais rend les requêtes basées sur le cadre limite plus lentes.

AddPoint(linestring, point, [<position>]) :

Ajoute un point à une LINESTRING avant le point <position> (index d'origine 0). Le troisième paramètre peut être omis ou prendre la valeur -1 si vous souhaitez ajouter le point à la fin.

RemovePoint(linestring, décalage) :

Supprime un point d'une LINESTRING. Le décalage commence à 0.
Disponibilité : 1.1.0

SetPoint(linestring, N, point) :

Remplace le point N de la LINESTRING par le point passé en argument. L'index à pour origine 0.
Disponibilité : 1.1.0

Force_collection(geometry) :

Convertie une géométrie en une GEOMETRYCOLLECTION. Cela est utile pour simplifier la représentation en WKB.

Force_2d(geometry) :

Passe une géométrie dans le mode 2d, toutes les géométries auront donc uniquement les coordonnées X et Y. Cela est utile pour forcer la compatibilité avec l'OGC (pouisuqe l'OCG ne spécifie que des géométries 2d).

Force_3dz(geometry), Force_3d(geometry) :

Passe un géométrie dans le mode XYZ.

Force_3dm(geometry) :

Passe une géométrie dans le mode XYM.

Force_4d(geometry) :

Passe un géométrie dans le mode XYZM.

Multi(geometry) :

Renvoi la géométrie comme une géométrie multiple (MULTI*). Si la géométrie est déjà une MULTI*, elle est renvoyée inchangée.

Transform(geometry,entier) :

Renvoi une nouvelle géométrie dont les coordonnées sont transformées à l'aide du SRID représenté par le paramètre entier. Le SRID de destination doit exister dans la table SPATIAL_REF_SYS.

Translate(geometry,float8,float8,float8) :

Effectue la translation d'une géométrie vers une nouvelle position en utilisant les paramètres numériques comme vecteur de translation. Par exemple : translate(geom, X, Y, Z).

Scale(geometry,float8,float8,float8) :

Effectue une homothétie de la géométrie en multipliant les coordonnées par les paramètres. Par exemple : scale(geom, facteurX, facteurY, facteurZ).
Disponibilité : 1.1.0

TransScale(geometry,float8,float8,float8,float8) :

Commence par effectuer une translation de la géométrie en utilisant les deux flottants, puis effectue l'homothétie en utilisant les deux paramètres suivant, fonctionne uniquement dans le mode 2d. Utiliser transcale(geom, X, Y, facteurX, facteurY) est un raccourci efficace pour scale(translate(geom,X,Y,0),facteurX,facteurY,1).
Disponibilité : 1.1.0

Reverse(geometry) :

Renvoit la géométrie avec les sommets en ordre inverse.

ForceRHR(geometry) :

Force une collection de polygones à abéïr à la règle de la main droite.

Simplify(geometry, tolerance) :

Renvoi un version "simplifiée" de la géométrie passée en argument en utilisant l'algorithme Douglas-Peuker. Cela n'effectue actuellement une simplification que pour des (MULTI)LINES et des (MULTI)POLYGONS mais vous pouvez l'utiliser sans risque avec tout type de géométries. Puisque les simplifications se font objet par objet, vous pouvez aussi passé en argument une GEOMETRYCOLLECTION à cette fonction. Notez que la géométrie retournée peut avoir perdu sa simplicité (voir IsSimple).

SnapToGrid(geometry, originX, originY, sizeX, sizeY), SnapToGrid(geometry, sizeX, sizeY), SnapToGrid(geometry, size)

Snap all points of the input geometry to the grid defined by its origin and cell size. Remove consecutive points falling on the same cell, eventually returning NULL if output points are not enough to define a geometry of the given type. Collapsed geometries in a collection are stripped from it.
Note

The returned geometry might loose its simplicity (see IsSimple).
Note

Before release 1.1.0 this function always returned a 2d geometry. Starting at 1.1.0 the returned geometry will have same dimensionality as the input one with higher dimension values untouched. Use the version taking a second geometry argument to define all grid dimensions.

Availability: 1.0.0RC1

SnapToGrid(geometry, geometry, sizeX, sizeY, sizeZ, sizeM)

Snap all points of the input geometry to the grid defined by its origin (the second argument, must be a point) and cell sizes. Specify 0 as size for any dimension you don't want to snap to a grid.

Availability: 1.1.0

Segmentize(geometry, maxlength)

Return a modified [multi]polygon having no ring segment longer then the given distance. Interpolated points will have Z and M values (if needed) set to 0. Distance computation is performed in 2d only.

LineMerge(geometry) :

Renvoit un (ensemble d') objet(s) de type linestring composé(s) des lignes contigües inclues dans l'objet de type geometry passé en paramètre.
ndrpf: si le résultat est un ensemble, ce dernier semble être ordonné suivant la valeur minimal des coordonnées des points startpoint et endpoint (à vérifier).

Disponibilité : 1.1.0 - nécessite GEOS >= 2.1.0

Exemple concrêt : (ndrpf)


Cas d'un ensemble de linestring contigües :

select astext(linemerge(geometryfromtext('MULTILINESTRING((0 0,5 5),(5 5,6 10))',-1)));
LINESTRING(0 0,5 5,6 10)

Cas d'un ensemble de linestring non contigües :

select astext(linemerge(geometryfromtext('MULTILINESTRING((0 0,5 5),(5 4,6 10))',-1)));
MULTILINESTRING((0 0,5 5),(5 4,6 10))

line_interpolate_point(linestring, location) :

Retourne un point interpolé le long d'une ligne. Le premier argument doit être une LINESTRING. Le second argument est un flotant (float8) dont la valeur est comprise entre 0 et 1 et qui représente une fraction de la longuer 2d totale où le point doit être localisé.

Voir la fonction line_locate_point() pour localiser l'endroit le plus prêt d'un point sur une ligne.

Note : depuis la version 1.1.1 cette fonction interpole aussi les valeurs M et Z (lorsqu'elles sont présentes), tandis que les versions précédantes leur attribut la valeur 0.0.

Disponibilité : 0.8.2

line_substring(linestring, debut, fin) :

Retourne une ligne étant une sous partie de celle passée en argument commençant et terminant aux fractions de la longueur totale passées en argument. Le second et le troisième argument sont des flotants (float8) dont la valeur est comprise entre 0 et 1.

Si les valeurs de debut et fin sont identiques cette fonction est alors équivalente à line_interpolate_point().

Voir line_locate_point() pour localiser l'endroit le plus prêt d'un point sur une ligne.

Note : depuis la version 1.1.1 cette fonction interpole aussi les valeurs M et Z (lorsqu'elles sont présentes), tandis que les versions précédantes leur attribut des valeurs non spécifiées.

Disponibilité : 1.1.0

line_locate_point(LineString, Point) :

Retourne un flotant compris entre 0 et 1 représentant la position du point sur une LINESTRING le plus proche du point donné, sous la forme d'une fraction de la longuer 2d totale.

Vous pouvez utiliser la position retournée pour extraire un POINT (avec line_interpolate_point) ou la sous partie d'une ligne (line_substring).

Disponibilité : 1.1.0

locate_along_measure(geometry, float8) :

Renvoie un ensemble d'éléments géométriques dont les éléments respecte la mesure spécifiée. Les éléments de type POLYGON ne sont pas supportés.

La sémantique est spécifiée par : ISO/IEC CD 13249-3:200x(E) - Text for Continuation CD Editing Meeting

Availability: 1.1.0

locate_between_measures(geometry, float8, float8) :

Retourne un ensemble de valeurs géométriques dont les éléments sont inclues dans l'intervale de valeurs spécifié. Les éléments de type POLYGON ne sont pas supportés.

La sémantique est spécifiée par : ISO/IEC CD 13249-3:200x(E) - Text for Continuation CD Editing Meeting

Availability: 1.1.0

Summary(geometry) :

Renvoie un résumé textuel du contenu géométrique.

box2d(geometry) :

Renvoie une BOX2D représentant le cadre limite de l'objet géométrique.

box3d(geometry) :

Renvoie une BOX3D représentant le cadre limite de l'objet géométrique.

extent(geometry set) :

La fonction extent() est une fonction d'agrégation, selon la terminologie de PostgreSQL. Cela signifie qu'elle opère sur des ensembles de données, à la manière des fonctions sum() et mean(). Par exemple, "SELECT EXTENT(GEOM) FROM GEOMTABLE" renverra une boîte BOX3D qui correspond au cadre limite de tout les objets géométriques contenus dans la table. De la même façon, "SELECT EXTENT(GEOM) FROM GEOMTABLE GROUP BY CATEGORY" renverra un résultat d'emprise pour chacune des catégories.

zmflag(geometry) :

Renvoie le drapeau ZM (dimension(s) de la géométrie) des objets géométriques sous forme de small int. Il peut prendre les valeurs : 0=2d, 1=3dm, 2=3dz, 3=4d.

HasBBOX(geometry) :

Renvoie vrai si le cadre limite de l'objet géométrique est en cache, et faux sinon. Utilisez addBBOX() et dropBBOX() pour contrôler la mise en cache.

ndims(geometry) :

Renvoie le nombre de dimensions de l'objet géométrique sous forme de small int. Il peut prendre les valeurs 2,3 ou 4.

nrings(geometry) :

Si l'objet géométrique est un polygon ou un multi-polygon renvoie le nombre de rings.

npoints(geometry) :

Renvoie le nombre de points dans l'objet géométrique.

isvalid(geometry) :

Renvoie vrai si l'objet géométrique est valide.

expand(geometry, float) :

Cette fonction renvoie un cadre limite étendue dans chacune des directions à partir du cadre limite de l'objet géométrique en entrée, en fonction d'une variable spécifiée en second argument. Très utile pour les requêtes de distance(), pour ajouter un filtre d'index à la requête.

estimated_extent([schema], table, geocolumn) :

Renvoie l'emprise 'estimé' de la table spatiale désignée. L'estimation provient des statistiques du champ de géométrie. Le schéma courant sera utilisé si rien d'autre n'est précisé.

Pour PostgreSQL>=8.0.0, les statistiques sont rassemblées par VACUUM ANALYZE et l'emprise résultante représentera à peu près 95% de l'emprise réelle.

Pour PostgreSQL< 8.0.0, les statistiques sont rassemblées par update_geometry_stats() et l'emprise résultante sera exacte.

find_srid(varchar,varchar,varchar) :

La syntaxe est find_srid(<db/schema>, <table>, <column>) et la fonction renvoie l'entier SRID du champ spécifié en cherchant dans la table geometry_columns. Si le champ géométrie n'a pas été ajouté à l'aide la fonction adéquate AddGeometryColumns(), cette fonction ne marchera pas non plus.

mem_size(geometry) :

Renvoie la quantité d'espace disque (en bytes) qu'occupe l'objet géométrique.

numb_sub_objects(geometry) :

Renvoie le nombre d'objet stockés dans la géométrie. C'est spécialement utile pour les MULTI-géométries et les GEOMETRYCOLLECTIONs.

point_inside_circle(geometry,float,float,float) :

La syntaxe de cette fonction est point_inside_circle(<geometry>,<circle_center_x>,<circle_center_y>,<radius>). Renvoie vrai si l'objet géométrique est un point et se trouve à l'intérieur d'un cercle. Sinon renvoie faux.

xmin(box3d) ymin(box3d) zmin(box3d) :

Renvoie le minima spécifié d'une bounding box.

xmax(box3d) ymax(box3d) zmax(box3d) :

Renvoie le maxima spécifié d'une bounding box.

Accum(geometry set) :

Agrégat. Construit un tableau d'objets géométriques.

Ce module et les fonctions pl/pgsql associées (définies dans le fichier lwgeom/long_xact.sql.in du répertoire des sources de PostGIS) ont été implémentés afin de fournir le support pour de longs vérouillages requis par les spécifications Web Feature Service (page 34 du document).

Note : les utilisateurs doivent utiliser le mode d'isolation serializable sans quoi le méchanisme de vérouillage devrait ne pas fonctionner.

EnableLongTransactions() :

Active le support des transactions longues. Cette fonction crée les tables de métadonnées nécessaires, elle a besoin d'être appeler une seule fois avant l'utilisation de l'une des autres fonctions décrites dans cette partie. L'appeler une deuxième fois serait inutile.
Disponibilité : 1.1.3

DisableLongTransactions() :

Désactive le support des transactions longues. Cette fonctione supprime les tables de métadonnées du support des transactions longues, et enlève tout les triggers utilisés par les tables de vérification du vérouillage.
Disponibilité : 1.1.3

CheckAuth([<schema>], <table>, <rowid_col>) :

Vérifie si les mises à jour et les suppressions des lignes de la table spécifiée sont possibles (autorisables). Identifie les lignes en utilisant la colonne : <rowid_col>.
Disponibilité : 1.1.3

LockRow([<schema>], <table>, <rowid>, <authid>, [<expires>]) :

Attribut le verroux/l'autorisation pour une ligne spécific dans la table.
<authid> est une chaîne de charactère.
<expires> est une durée (de type timestamp) dont la valeur par défaut est : now()+1heure.
Renvoit 1 si le verroux a pu être assigné, 0 sinon (déjà verrouillé par un autre processus).
Disponibilité : 1.1.3

UnlockRows(<authid>) :

Supprime tout les verroux rattachés à l'identifiant d'autorisation spécifié. Renvoit le nombre de verroux relachés.
Disponibilité : 1.1.3

AddAuth(<authid>) :

Ajoute un marqueur d'autorisation à utiliser dans la transaction courrante.
Disponibilité : 1.1.3

Voici une liste des fonctions SQL-MM que PostGIS supporte. L'implémentation de ces fonctions est calquée sur celle d'ArcSDE, certaines parties, qui seront explicitées ici, varient donc des spécifications.

Avec la version 1.2.0, ces fonctions ont été implémentées par encapsulation des fonctions existantes de PostGIS. Ce qui à pour résultat, que certaines fonctionalités des objets géométriques de type courbes ne soient pas disponibles.

ST_Area

Revoie l'aire d'une ST_Surface ou ST_MultiSurface.

SQL-MM 3: 8.1.2, 9.5.3

ST_AsBinary

Renvoie la représentation binaire d'une ST_Geometry.

SQL-MM 3: 5.1.37

ST_AsText

Renvoie la représentation textuelle d'une ST_Geometry.

SQL-MM 3: 5.1.25

ST_Boundary

Return the boundary of the ST_Geometry value.

SQL-MM 3: 5.1.14

ST_Buffer

Renvoie l'ensemble des points dans l'espace autour d'une ST_Geometry.

SQL-MM 3: 5.1.17

ST_Centroid

Renvoie le barycentre d'une ST_Surface ou ST_MultiSurface.

SQL-MM 3: 8.1.4, 9.5.5

ST_Contains

Test si une ST_Geometry en contient spatialement une autre.

SQL-MM 3: 5.1.31

ST_ConvexHull

Renvoie l'enveloppe convexe d'une typeST_Geometry.

SQL-MM 3: 5.1.16

ST_CoordDim

Renvoie la dimension des coordonnées d'une ST_Geometry.

SQL-MM 3: 5.1.3

ST_Crosses

Test si deux ST_Geometry se croisent spatialement.

SQL-MM 3: 5.1.29

ST_Difference

Renvoie un objet de type ST_Geometry qui représente l'ensemble des points différents de deux objets de type ST_Geometry.

SQL-MM 3: 5.1.20

ST_Dimension

Renvoie la dimension d'un objet de type ST_Geometry.

SQL-MM 3: 5.1.2

ST_Disjoint

Test si un objet de type ST_Geometry est spatialement disjoint
d'un autre ST_Geometry.

SQL-MM 3: 5.1.26

ST_Distance

Renvoie la distance entre deux entités géométriques.

SQL-MM 3: 5.1.23

ST_EndPoint

Renvoie un objet de type ST_Point qui est le point final d'une entité de type ST_Curve.

SQL-MM 3: 7.1.4

ST_Envelope

Renvoie le rectangle englobant une entité de type ST_Geometry.

SQL-MM 3: 5.1.15

ST_Equals

Test si deux valeurs de type ST_Geometry sont spatialement égales.

SQL-MM 3: 5.1.24

ST_ExteriorRing

Renvoie l'anneau extérieur d'une ST_Surface.

SQL-MM 3: 8.2.3, 8.3.3

ST_GeometryN

Renvoie la valeur de type ST_Geometry à partir de l'index indiquée dans un ensemble de type ST_GeomCollection.

SQL-MM 3: 9.1.5

ST_GeometryType

Renvoie le type d'une ST_Geometry.

SQL-MM 3: 5.1.4

ST_GeomFromText

Renvoie une ST_Geometry à partir de sa représentation textuelle.

SQL-MM 3: 5.1.40

ST_GeomFromWKB

Renvoie une ST_Geometry à partir de sa représentation binaire.

SQL-MM 3: 5.1.41

ST_InteriorRingN

Renvoie l'anneau intérieur d'une entité géométrique de type ST_Surface.

SQL-MM 3: 8.2.6, 8.3.5

ST_Intersection

Renvoie un objet de type ST_Geometry représentant l'ensemble des points d'intersection de deux objets de types ST_Geometry.

SQL-MM 3: 5.1.18

ST_Intersects

Test si une valeur de type ST_Geometry intersecte spatialement un autre objet de type ST_Geometry.

SQL-MM 3: 5.1.27

ST_IsClosed

Test si un objet de type ST_Curve or ST_MultiCurve est fermé.

Note

SQL-MM spécifie que le résultat de ST_IsClosed(NULL) doit être 0, alors que PostGIS renvoie NULL.

SQL-MM 3: 7.1.5, 9.3.3

ST_IsEmpty

Test si une entité de type ST_Geometry correspond à l'ensemble vide.

Note

SQL-MM spécifie que le résultat de ST_IsEmpty(NULL) doit être 0, alors que PostGIS renvoie la valeur NULL.

SQL-MM 3: 5.1.7

ST_IsRing

Test si une entité de type ST_Curve est un anneau.

Note

SQL-MM spécifie que le résultat de ST_IsRing(NULL) doit être 0, alors ue PostGIS renvoie la valeur NULL.

SQL-MM 3: 7.1.6

ST_IsSimple

Test si une entité de type ST_Geometry ne contient pas d'anomalies géométriques, comme par exemple l'auto-intersection ou l'auto-tangent.

Note

SQL-MM spécifie que le résultat de ST_IsSimple(NULL) doit être 0, alors que PostGIS renvoie la valeur NULL dans ce cas.

SQL-MM 3: 5.1.8

ST_IsValid

Test si une entité de type ST_Geometry est bien formée.

Note

SQL-MM spécifie que le résultat de ST_IsValid(NULL) doit être 0, alors que PostGIS renvoie la valeur NULL dans ce cas.

SQL-MM 3: 5.1.9

ST_Length

Renvoie la longuer d'une ST_Curve ou ST_MultiCurve.

SQL-MM 3: 7.1.2, 9.3.4

ST_LineFromText

Renvoie une ST_LineString à parti de sa représentation textuelle.

SQL-MM 3: 7.2.8

ST_LineFromWKB

Renvoie une ST_LineString à parti de sa représentation binaire.

SQL-MM 3: 7.2.9

ST_MLineFromText

Renvoie un ST_MultiLineString à parti de sa représentation textuelle.

SQL-MM 3: 9.4.4

ST_MLineFromWKB

Renvoie un ST_MultiLineString à parti de sa représentation binaire.

SQL-MM 3: 9.4.5

ST_MPointFromText

Renvoie un ST_MultiPoint à parti de sa représentation textuelle.

SQL-MM 3: 9.2.4

ST_MPointFromWKB

Renvoie un ST_MultiPoint à parti de sa représentation binaire.

SQL-MM 3: 9.2.5

ST_MPolyFromText

Renvoie un ST_MultiPolygon à parti de sa représentation textuelle.

SQL-MM 3: 9.6.4

ST_MPolyFromWKB

Return a specified ST_MultiPolygon à parti de sa représentation binaire.

SQL-MM 3: 9.6.5

ST_NumGeometries

Renvoie le nombre l'éléments dans ST_GeomCollection.

SQL-MM 3: 9.1.4

ST_NumInteriorRing

Return the number of interior rings in an ST_Surface.

SQL-MM 3: 8.2.5

ST_NumPoints

Return the number of points in an ST_LineString or
ST_CircularString value.

SQL-MM 3: 7.2.4

ST_OrderingEquals

ST_OrderingEquals compare deux entités géométriques et renvoie t (vraie) si les entités géométriques sont égales et que les coordonées sont dans le même ordre, sinon revoie f (faux).

Note

Cette fonction est implémentée comme dans l'api SQL d'ArcSDE plutôt que comme spécifié par SQL-MM.

SQL-MM 3: 5.1.43

ST_Overlaps

Test si un objet de type ST_Geometry en recouvre spatialement une autre.

SQL-MM 3: 5.1.32

ST_Perimeter

Return the length measurement of the boundary of an
ST_Surface or ST_MultiRSurface value.

SQL-MM 3: 8.1.3, 9.5.4

ST_Point

Renvoie un objet de type ST_Point à partir des coordonées passés en paramètre.

SQL-MM 3: 6.1.2

ST_PointFromText

Renvoie un objet de type ST_Point à partir de sa représentation textuelle.

SQL-MM 3: 6.1.8

ST_PointFromWKB

Renvoie un objet de type ST_Point à partir de sa représentation binaire.

SQL-MM 3: 6.1.9

ST_PointN

Return the specified ST_Point value in an ST_LineString or
ST_CircularString

SQL-MM 3: 7.2.5, 7.3.5

ST_PointOnSurface

Renvoie une valeur ST_Point garantie pour intersecter spatialement la valeur de ST_Surface ou de ST_MultiSurface.

SQL-MM 3: 8.1.5, 9.5.6

ST_PolyFromText

Renvoie un objet de type ST_Polygon à partir de sa représentation textuelle.

SQL-MM 3: 8.3.6

ST_PolyFromWKB

Renvoie un objet de type ST_Polygon à partir de sa représentation binaire.

SQL-MM 3: 8.3.7

ST_Polygon

Renvoie un polygone construit à partir de la polyligne définie SRID.

SQL-MM 3: 8.3.2

ST_Relate

Test if an ST_Geometry value is spatially related to another
ST_Geometry value.

SQL-MM 3: 5.1.25

ST_SRID

Renvoie l'identifiant du SRID d''une entité géométrique de type ST_Geometry.

SQL-MM 3: 5.1.5

ST_StartPoint

Renvoie un objet de type ST_Point qui est le point de départ d'une entité géométrique de type ST_Curve.

SQL-MM 3: 7.1.3

ST_SymDifference

Renvoie un objet de type ST_Geometry qui représente l'ensemble d'exclusion de deux entités géométriques de type ST_Geometry value that represents the point set
symmetrcy difference of two ST_Geometry values.

SQL-MM 3: 5.1.21

ST_Touches

Test si un entité géométrique de type ST_Geometry en touche spatialement une autre.

SQL-MM 3: 5.1.28

ST_Transform

Renvoie un objet de type ST_Geometry value transformed to the specified
spatial reference system.

SQL-MM 3: 5.1.6

ST_Union

Renvoie un objet de type ST_Geometry qui représente l'ensemble des points de l'union de deux entités géométriques de type ST_Geometry.

SQL-MM 3: 5.1.19

ST_Within

Test si une entité gémétrique de type ST_Geometry est contenue dans une autre.

SQL-MM 3: 5.1.30

ST_WKBToSQL

Renvoie un objet de type ST_Geometry à partir de sa représentation binaire.

SQL-MM 3: 5.1.36

ST_WKTToSQL

Renvoie une entité géométrique de type ST_Geometry à partir de sa représentation textuelle.

SQL-MM 3: 5.1.34

ST_X

Renvoie la composante x des coordonées d'un ST_Point.

SQL-MM 3: 6.1.3

ST_Y

Renvoie la composante y des coordonées d'un ST_Point.

SQL-MM 3: 6.1.4

Des fonctions supplémentaires ont été ajoutées pour améliorer le support d'une interface de style ArcSDE.

SE_EnvelopesIntersect :

Renvoie vrai si les emprises de deux objets géométriques s'intersectent, sinon, elle renvoie faux.

SE_Is3d :

Test si une valeur géométrique a une composante z.

SE_IsMeasured :

Test si une valeur géométrique a une composante m.

SE_LocateAlong :

Renvoie un ensemble d'objet géométriques dont les éléments respectent la mesure spécifiée.

SE_LocateBetween :

Renvoie un ensemble d'objet géométriques dont les éléments sont inclues dans l'intervalle de valeur spécifié.

SE_M :

Renvoie la composante m d'une valeur de type ST_Point

SE_Z :

Renvoie la composante z d'une valeur géométrique de type ST_Point .

Signaler des bogues est essentiel pour soutenir le développement de PostGIS. La manière la plus efficace de produire un rapport de bogue est de faire en sorte que les développeurs puissent le reproduire. L'idéal est qu'il contienne un script qui déclenche le bogue et des renseignements complets sur l'environnement dans lequel il s'est produit. D'assez bonnes infos peuvent être trouvées grâce à
SELECT postgis_full_version() (pour postgis) et SELECT version() (pour postgresql).
Si vous n'utilisez pas actuellement la dernière version sortie, il vaut mieux d'abord jeter un coup d'œil aux derniers correctifs apportés afin de voir si votre bogue a déjà été corrigé.
L'utilisation du traqueur de bogue PostGIS vous garantit que vos rapports ne tomberont pas aux oubliettes et vous tiendra informé de sa résolution. Avant de dresser votre rapport de bogue, veuillez faire une recherche dans la base de données pour voir s'il s'agit d'un bogue déjà connu, et ajoutez y toute information utile que vous auriez.
Peut-être serez vous intéressés par l'article de Simon Tatham intitulé 'How to Report Bugs Effectively' (Comment faire de bons rapports sur les bogues) avant de remplir votre propre rapport.

Release date: 2006/01/23
This is an important Bugfix release, upgrade is highly recommended. Previous version contained a bug in postgis_restore.pl preventing hard upgrade procedure to complete and a bug in GEOS-2.2+ connector preventing GeometryCollection objects to be used in topological operations.

If you are upgrading from release 1.0.3 or later follow the soft upgrade procedure.
If you are upgrading from a release between 1.0.0RC6 and 1.0.2 (inclusive) and really want a live upgrade read the upgrade section of the 1.0.3 release notes chapter.
Upgrade from any release prior to 1.0.0RC6 requires an hard upgrade.

Fixed a premature exit in postgis_restore.pl
BUGFIX in geometrycollection handling of GEOS-CAPI connector
Solaris 2.7 and MingW support improvements
BUGFIX in line_locate_point()
Fixed handling of postgresql paths
BUGFIX in line_substring()
Added support for localized cluster in regress tester

New Z and M interpolation in line_substring()
New Z and M interpolation in line_interpolate_point()
added NumInteriorRing() alias due to OpenGIS ambiguity

Release date: 2005/12/21
This is a Minor release, containing many improvements and new things. Most notably: build procedure greatly simplified; transform() performance drastically improved; more stable GEOS connectivity (CAPI support); lots of new functions; draft topology support.
It is highly recommended that you upgrade to GEOS-2.2.x before installing PostGIS, this will ensure future GEOS upgrades won't require a rebuild of the PostGIS library.

This release includes code from Mark Cave Ayland for caching of proj4 objects. Markus Schaber added many improvements in his JDBC2 code. Alex Bodnaru helped with PostgreSQL source dependency relief and provided Debian specfiles. Michael Fuhr tested new things on Solaris arch. David Techer and Gerald Fenoy helped testing GEOS C-API connector. Hartmut Tschauner provided code for the azimuth() function. Devrim GUNDUZ provided RPM specfiles. Carl Anderson helped with the new area building functions. See the credits section for more names.

If you are upgrading from release 1.0.3 or later you DO NOT need a dump/reload. Simply sourcing the new lwpostgis_upgrade.sql script in all your existing databases will work. See the soft upgrade chapter for more informations.
If you are upgrading from a release between 1.0.0RC6 and 1.0.2 (inclusive) and really want a live upgrade read the upgrade section of the 1.0.3 release notes chapter.
Upgrade from any release prior to 1.0.0RC6 requires an hard upgrade.

scale() and transscale() companion methods to translate()
line_substring()
line_locate_point()
M(point)
LineMerge(geometry)
shift_longitude(geometry)
azimuth(geometry)
locate_along_measure(geometry, float8)
locate_between_measures(geometry, float8, float8)
SnapToGrid by point offset (up to 4d support)
BuildArea(any_geometry)
OGC BdPolyFromText(linestring_wkt, srid)
OGC BdMPolyFromText(linestring_wkt, srid)
RemovePoint(linestring, offset)
ReplacePoint(linestring, offset, point)

Fixed memory leak in polygonize()
Fixed bug in lwgeom_as_anytype cast funcions
Fixed USE_GEOS, USE_PROJ and USE_STATS elements of postgis_version() output to always reflect library state.

SnapToGrid doesn't discard higher dimensions
Changed Z() function to return NULL if requested dimension is not available

Much faster transform() function, caching proj4 objects
Removed automatic call to fix_geometry_columns() in AddGeometryColumns() and update_geometry_stats()

Makefile improvements
JTS support improvements
Improved regression test system
Basic consistency check method for geometry collections
Support for (Hex)(E)wkb
Autoprobing DriverWrapper for HexWKB / EWKT switching
fix compile problems in ValueSetter for ancient jdk releases.
fix EWKT constructors to accept SRID=4711; representation
added preliminary read-only support for java2d geometries

Full autoconf-based configuration, with PostgreSQL source dependency relief
GEOS C-API support (2.2.0 and higher)
Initial support for topology modelling
Debian and RPM specfiles
New lwpostgis_upgrade.sql script

JTS support improvements
Stricter mapping between DBF and SQL integer and string attributes
Wider and cleaner regression test suite
old jdbc code removed from release
obsoleted direct use of postgis_proc_upgrade.pl
scripts version unified with release version

Release date: 2005/12/06
Contains a few bug fixes and improvements.

If you are upgrading from release 1.0.3 or later you DO NOT need a dump/reload.
If you are upgrading from a release between 1.0.0RC6 and 1.0.2 (inclusive) and really want a live upgrade read the upgrade section of the 1.0.3 release notes chapter.
Upgrade from any release prior to 1.0.0RC6 requires an hard upgrade.

Fixed palloc(0) call in collection deserializer (only gives problem with --enable-cassert)
Fixed bbox cache handling bugs
Fixed geom_accum(NULL, NULL) segfault
Fixed segfault in addPoint()
Fixed short-allocation in lwcollection_clone()
Fixed bug in segmentize()
Fixed bbox computation of SnapToGrid output

Initial support for postgresql 8.2
Added missing SRID mismatch checks in GEOS ops

Release date: 2005/11/25
Contains memory-alignment fixes in the library, a segfault fix in loader's handling of UTF8 attributes and a few improvements and cleanups.
Note
Return code of shp2pgsl changed from previous releases to conform to unix standards (return 0 on success).

If you are upgrading from release 1.0.3 or later you DO NOT need a dump/reload.
If you are upgrading from a release between 1.0.0RC6 and 1.0.2 (inclusive) and really want a live upgrade read the upgrade section of the 1.0.3 release notes chapter.
Upgrade from any release prior to 1.0.0RC6 requires an hard upgrade.

Fixed memory alignment problems
Fixed computation of null values fraction in analyzer
Fixed a small bug in the getPoint4d_p() low-level function
Speedup of serializer functions
Fixed a bug in force_3dm(), force_3dz() and force_4d()

Fixed return code of shp2pgsql
Fixed back-compatibility issue in loader (load of null shapefiles)
Fixed handling of trailing dots in dbf numerical attributes
Segfault fix in shp2pgsql (utf8 encoding)

Schema aware postgis_proc_upgrade.pl, support for pgsql 7.2+
New "Reporting Bugs" chapter in manual

Release date: 2005/09/09
Contains important bug fixes and a few improvements. In particular, it fixes a memory leak preventing successful build of GiST indexes for large spatial tables.

If you are upgrading from release 1.0.3 you DO NOT need a dump/reload.
If you are upgrading from a release between 1.0.0RC6 and 1.0.2 (inclusive) and really want a live upgrade read the upgrade section of the 1.0.3 release notes chapter.
Upgrade from any release prior to 1.0.0RC6 requires an hard upgrade.

Memory leak plugged in GiST indexing
Segfault fix in transform() handling of proj4 errors
Fixed some proj4 texts in spatial_ref_sys (missing +proj)
Loader: fixed string functions usage, reworked NULL objects check, fixed segfault on MULTILINESTRING input.
Fixed bug in MakeLine dimension handling
Fixed bug in translate() corrupting output bounding box

Documentation improvements
More robust selectivity estimator
Minor speedup in distance()
Minor cleanups
GiST indexing cleanup
Looser syntax acceptance in box3d parser

Release date: 2005/08/08
Contains some bug fixes - including a severe one affecting correctness of stored geometries - and a few improvements.

Due to a bug in a bounding box computation routine, the upgrade procedure requires special attention, as bounding boxes cached in the database could be incorrect.
An hard upgrade procedure (dump/reload) will force recomputation of all bounding boxes (not included in dumps). This is required if upgrading from releases prior to 1.0.0RC6.
If you are upgrading from versions 1.0.0RC6 or up, this release includes a perl script (utils/rebuild_bbox_caches.pl) to force recomputation of geometries' bounding boxes and invoke all operations required to propagate eventual changes in them (geometry statistics update, reindexing). Invoke the script after a make install (run with no args for syntax help). Optionally run utils/postgis_proc_upgrade.pl to refresh postgis procedures and functions signatures (see Soft upgrade).

Severe bugfix in lwgeom's 2d bounding box computation
Bugfix in WKT (-w) POINT handling in loader
Bugfix in dumper on 64bit machines
Bugfix in dumper handling of user-defined queries
Bugfix in create_undef.pl script

Small performance improvement in canonical input function
Minor cleanups in loader
Support for multibyte field names in loader
Improvement in the postgis_restore.pl script
New rebuild_bbox_caches.pl util script

Release date: 2005/07/04
Contains a few bug fixes and improvements.

If you are upgrading from release 1.0.0RC6 or up you DO NOT need a dump/reload.
Upgrading from older releases requires a dump/reload. See the upgrading chapter for more informations.

Fault tolerant btree ops
Memory leak plugged in pg_error
Rtree index fix
Cleaner build scripts (avoided mix of CFLAGS and CXXFLAGS)

New index creation capabilities in loader (-I switch)
Initial support for postgresql 8.1dev

Release date: 2005/05/24
Contains a few bug fixes and some improvements.

If you are upgrading from release 1.0.0RC6 or up you DO NOT need a dump/reload.
Upgrading from older releases requires a dump/reload. See the upgrading chapter for more informations.

BUGFIX in 3d computation of lenght_spheroid()
BUGFIX in join selectivity estimator

BUGFIX in shp2pgql escape functions
better support for concurrent postgis in multiple schemas
documentation fixes
jdbc2: compile with "-target 1.2 -source 1.2" by default
NEW -k switch for pgsql2shp
NEW support for custom createdb options in postgis_restore.pl
BUGFIX in pgsql2shp attribute names unicity enforcement
BUGFIX in Paris projections definitions
postgis_restore.pl cleanups

Release date: 2005/04/19
Final 1.0.0 release. Contains a few bug fixes, some improvements in the loader (most notably support for older postgis versions), and more docs.

If you are upgrading from release 1.0.0RC6 you DO NOT need a dump/reload.
Upgrading from any other precedent release requires a dump/reload. See the upgrading chapter for more informations.

BUGFIX in transform() releasing random memory address
BUGFIX in force_3dm() allocating less memory then required
BUGFIX in join selectivity estimator (defaults, leaks, tuplecount, sd)

BUGFIX in shp2pgsql escape of values starting with tab or single-quote
NEW manual pages for loader/dumper
NEW shp2pgsql support for old (HWGEOM) postgis versions
NEW -p (prepare) flag for shp2pgsql
NEW manual chapter about OGC compliancy enforcement
NEW autoconf support for JTS lib
BUGFIX in estimator testers (support for LWGEOM and schema parsing)

Release date: 2005/03/30
Sixth release candidate for 1.0.0. Contains a few bug fixes and cleanups.

You need a dump/reload to upgrade from precedent releases. See the upgrading chapter for more informations.

BUGFIX in multi()
early return [when noop] from multi()

dropped {x,y}{min,max}(box2d) functions

BUGFIX in postgis_restore.pl scrip
BUGFIX in dumper's 64bit support

Release date: 2005/03/25
Fifth release candidate for 1.0.0. Contains a few bug fixes and a improvements.

If you are upgrading from release 1.0.0RC4 you DO NOT need a dump/reload.
Upgrading from any other precedent release requires a dump/reload. See the upgrading chapter for more informations.

BUGFIX (segfaulting) in box3d computation (yes, another!).
BUGFIX (segfaulting) in estimated_extent().

Small build scripts and utilities refinements.
Additional performance tips documented.

Release date: 2005/03/18
Fourth release candidate for 1.0.0. Contains bug fixes and a few improvements.

BUGFIX (segfaulting) in geom_accum().
BUGFIX in 64bit architectures support.
BUGFIX in box3d computation function with collections.
NEW subselects support in selectivity estimator.
Early return from force_collection.
Consistency check fix in SnapToGrid().
Box2d output changed back to 15 significant digits.

NEW distance_sphere() function.
Changed get_proj4_from_srid implementation to use PL/PGSQL instead of SQL.

BUGFIX in loader and dumper handling of MultiLine shapes
BUGFIX in loader, skipping all but first hole of polygons.
jdbc2: code cleanups, Makefile improvements
FLEX and YACC variables set *after* pgsql Makefile.global is included and only if the pgsql *stripped* version evaulates to the empty string
Added already generated parser in release
Build scripts refinements
improved version handling, central Version.config
improvements in postgis_restore.pl

Release date: 2005/02/24
Third release candidate for 1.0.0. Contains many bug fixes and improvements.

You need a dump/reload to upgrade from precedent releases. See the upgrading chapter for more informations.

BUGFIX in transform(): missing SRID, better error handling.
BUGFIX in memory alignment handling
BUGFIX in force_collection() causing mapserver connector failures on simple (single) geometry types.
BUGFIX in GeometryFromText() missing to add a bbox cache.
reduced precision of box2d output.
prefixed DEBUG macros with PGIS_ to avoid clash with pgsql one
plugged a leak in GEOS2POSTGIS converter
Reduced memory usage by early releasing query-context palloced one.

BUGFIX in 72 index bindings.
BUGFIX in probe_geometry_columns() to work with PG72 and support multiple geometry columns in a single table
NEW bool::text cast
Some functions made IMMUTABLE from STABLE, for performance improvement.

jdbc2: small patches, box2d/3d tests, revised docs and license.
jdbc2: bug fix and testcase in for pgjdbc 8.0 type autoregistration
jdbc2: Removed use of jdk1.4 only features to enable build with older jdk releases.
jdbc2: Added support for building against pg72jdbc2.jar
jdbc2: updated and cleaned makefile
jdbc2: added BETA support for jts geometry classes
jdbc2: Skip known-to-fail tests against older PostGIS servers.
jdbc2: Fixed handling of measured geometries in EWKT.

new performance tips chapter in manual
documentation updates: pgsql72 requirement, lwpostgis.sql
few changes in autoconf
BUILDDATE extraction made more portable
fixed spatial_ref_sys.sql to avoid vacuuming the whole database.
spatial_ref_sys: changed Paris entries to match the ones distributed with 0.x.

Release date: 2005/01/26
Second release candidate for 1.0.0 containing bug fixes and a few improvements.

You need a dump/reload to upgrade from precedent releases. See the upgrading chapter for more informations.

BUGFIX in pointarray box3d computation
BUGFIX in distance_spheroid definition
BUGFIX in transform() missing to update bbox cache
NEW jdbc driver (jdbc2)
GEOMETRYCOLLECTION(EMPTY) syntax support for backward compatibility
Faster binary outputs
Stricter OGC WKB/WKT constructors

More correct STABLE, IMMUTABLE, STRICT uses in lwpostgis.sql
stricter OGC WKB/WKT constructors

Faster and more robust loader (both i18n and not)
Initial autoconf script

Release date: 2005/01/13
This is the first candidate of a major postgis release, with internal storage of postgis types redesigned to be smaller and faster on indexed queries.

You need a dump/reload to upgrade from precedent releases. See the upgrading chapter for more informations.

Faster canonical input parsing.
Lossless canonical output.
EWKB Canonical binary IO with PG>73.
Support for up to 4d coordinates, providing lossless shapefile->postgis->shapefile conversion.
New function: UpdateGeometrySRID(), AsGML(), SnapToGrid(), ForceRHR(), estimated_extent(), accum().
Vertical positioning indexed operators.
JOIN selectivity function.
More geometry constructors / editors.
Postgis extension API.
UTF8 support in loader.