Chapter 4. Gestion des données

L'Open Geospatial Consortium (OGC) a développé le standard Simple Features Access (SFA) pour fournir un modèle de données géospatiales. Ce standard définit le type spatial Geometry, ainsi que les opérations pour manipuler et transformer des géométries, et permettre des tâches d'analyses spatiales. PostGIS implémente le modèle OGC Geometry sous forme de types PostgreSQL geometry et geography.

Geometry est un type abstrait. Les valeurs géométriques utilisent les sous-types concrets, qui représentent les diverses formes géométriques. Ces types incluent les types atomiques Point, LineString, LinearRing et Polygon, ainsi que les types de collections MultiPoint, MultiLineString, MultiPolygon et GeometryCollection. Le standard Simple Features Access - Part 1: Common architecture v1.2.1 ajoute les sous-types pour les structures PolyhedralSurface, Triangle et TIN.

Geometry représente des formes dans le plan cartésien en 2 dimensions. Les types PolyhedralSurface, Triangle, et TIN peuvent également représenter des formes en 3 dimensions. La taille et la localisation des formes sont spécifiées par leurs coordonnées. Chaque coordonnées a une dimension X et une Y, qui déterminent sa position sur le plan. Les formes sont construites à partir de points ou de segments. Les points sont spécifiés par une seul coordonnée ; les segments par deux coordonnées.

Les coordonnées peuvent inclure des valeurs pour les dimensions optionnelles Z et M. La dimension Z est souvent utilisée pour représenter l'élévation. La dimension M contient une mesure, qui représente par exemple le temps ou une distance. Si la dimension Z ou M est présente pour une valeur géométrique, elle doit être définie pour tous les points de la géométrie. Si une géométrie a une dimension Z ou M, la dimension de la coordonnée est 3D ; si elle a à la fois les dimension Z et M, la dimension de la coordonnée est 4D.

Les valeurs géométriques sont associées à un système de coordonnées de référence (SCR, ou en anglais spatial reference system, SRS), qui indique dans quel système de coordonnées les valeurs sont définies. Le SCR est identifié par un identifiant appelé SRID. Les unités sur les axes X et Y sont déterminées par ce système de coordonnées de référence. Dans un système planaire, les coordonnées X et Y représentent les distances respectivement selon l'Est et le Nord. Dans un système géodésique elles représentent la longitude et la latitude. L'identifiant SRID 0 représente un plan cartésien infini, sans unité sur ses axes. Voir Section 4.5, “Systèmes de référence spatiale”.

La dimension d'une géométrie est une propriété des types géométriques. Les types Point ont une dimension 0, les types linéaires ont une dimension 1, et les types polygonaux ont une dimension 2. Les collections ont la dimension de leur élément de plus grande dimension.

Une valeur géométrique peut être vide. Une valeur vide ne contient aucun vertex (pour les types de géométriques atomiques) ou aucun élément (pour les collections).

Une propriété important des valeurs géométriques est leur emprise spatiale (extent en anglais) ou leur boîte englobante (bounding box en anglais), que le modèle OGC nomme enveloppe (envelope). La boîte englobante est la boîte 2D ou 3D qui contient les coordonnées d'une géométrie. C'est une façon efficace de représenter l'emprise d'une géométrie dans un espace et de tester comment deux géométries interagissent.

Le modèle de géométrie permet d'évaluer les relations topologiques, telles que décrites dans Section 5.1.1, “Modèle à 9 intersections dimensionnellement étendu”. Pour supporter cela, les concepts de intérieur (interior en anglais), frontière (boundary en anglais) et extérieur (exterior en anglais) sont définis pour tous les types de géométries. Les géométries sont topologiquement fermées, donc elle contiennent toujours leur frontière. La dimension de la géométrie de la frontière est la dimension de la géométrie moins un.

Le modèle de géométrie OGC définie des règles de validité pour chaque type géométrique. Ces règles permettent de s'assurer que les valeurs géométriques représentent des situations réalistes (e.g. il est possible de définir un polygone avec un trou à l'extérieur, mais cela n'a pas de sens au niveau géométrique, et est donc invalide). PostGIS permet de stocker et de manipuler des valeurs géométriques invalides, ceci permet de les détecter et de les corriger si besoin. Voir Section 4.4, “Validation de la géométrie”

POINT (1 2)
POINT Z (1 2 3)
POINT ZM (1 2 3 4)

LINESTRING (1 2, 3 4, 5 6)

LINEARRING (0 0 0, 4 0 0, 4 4 0, 0 4 0, 0 0 0)

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

MULTIPOINT ( (0 0), (1 2) )

MULTILINESTRING ( (0 0,1 1,1 2), (2 3,3 2,5 4) )

MULTIPOLYGON (((1 5, 5 5, 5 1, 1 1, 1 5)), ((6 5, 9 1, 6 1, 6 5)))

GEOMETRYCOLLECTION ( POINT(2 3), LINESTRING(2 3, 3 4))

POLYHEDRALSURFACE Z (
  ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)),
  ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)),
  ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)),
  ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)),
  ((0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)),
  ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

TRIANGLE ((0 0, 0 9, 9 0, 0 0))

TIN Z ( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

La norme ISO/IEC 13249-3 SQL Multimedia - Spatial (SQL/MM) étend l'OGC SFA pour définir des sous-types de géométrie contenant des courbes avec des arcs circulaires. Les types SQL/MM prennent en charge les coordonnées 3DM, 3DZ et 4D.

	Toutes les comparaisons en flottant dans l'implémentation de SQL-MM sont effectuées avec une tolérance spécifiée, actuellement 1E-8.

CIRCULARSTRING(0 0, 1 1, 1 0)

CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0)

COMPOUNDCURVE( CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))

CURVEPOLYGON(
  CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),
  (1 1, 3 3, 3 1, 1 1) )

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

MULTICURVE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

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

La spécification OGC SFA définit deux formats pour représenter des valeurs géométriques : Well-Known Text (WKT) et Well-Known Binary (WKB). Ces deux formats incluent les informations sur le type d'objet et sur les coordonnées qui le définissent.

Well-Known Text (WKT) fournit un standard pour représenter de façon textuelle des données spatiales. Voici quelques exemples de représentations WKT :

Des méthodes d'entrée/sortie en WKT sont fournies via les fonctions ST_AsText et ST_GeomFromText :

text WKT = ST_AsText(geometry);
geometry = ST_GeomFromText(text WKT, SRID);

Par exemple, une requête pour créer et insérer une objet spatial sous forme de WKT et avec un SRID :

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

Well-Known Binary (WKB) fournit un moyen portable et sans perte de précision pour représenter des données spatiales sous la forme de données binaires (tableau d'octets). Voici quelques exemples de représentations WKB :

Des méthodes d'entrée/sortie en WKB sont fournies via les fonctions ST_AsBinary et ST_GeomFromWKB :

bytea WKB = ST_AsBinary(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);

Par exemple, une requête pour créer et insérer une objet spatial sous forme de WKB :

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromWKB('\x0101000000000000000000f03f000000000000f03f', 312), 'A Place');

Les spécifications OGC SFA ne supportaient initialement que les géométries 2D, et le SRID de la géométrie n'est pas inclut dans les représentations d'entrée/sortie. La spécification OGC SFA 1.2.1 (qui est alignée avec le standard ISO 19125) ajoute le support pour la 3D (ZYZ) et les mesures (XYM et XYZM), mais n'inclut toujours pas la valeur du SRID.

À cause de ces limitations, PostGIS définit les formats étendus EWKB ((Extended Well-Known Binary) et EWKT (Extended Well-Known Text). Ils supportent la 3D (XYZ et XYM) et 4D (XYZM) et incluent l'information de SRID. Le format EWKB incluant toutes les informations de la géométrie, cela permet à PostGIS d'utiliser ce format pour les enregistrements (e.g. dans les fichiers DUMP).

EWKB et EWKT sont utilisés pour les "formes canoniques" des objets spatiaux de PostGIS. En tant qu'entrée, la forme canonique pour les données binaires est EWKB ; pour les données textuelles EWKB et EWKT sont tous deux acceptés. Cela permet de créer des valeurs géométriques en transtypant une valeur textuelle en HEXEWKB ou EWKT vers une valeur géométrique en utilisant ::geometry. Pour la sortie, la forme canonique pour les données binaires est EWKB et HEXEWKB (hex-encoded EWKB) pour les données textuelles.

Par exemple, cette requête créé une géométrie en transtypant depuis une chaîne de caractères contenant du EKWT, et retourne sa valeur sous sa forme canonique en HEXEWKB :

SELECT 'SRID=4;POINT(0 0)'::geometry;
  geometry
  ----------------------------------------------------
  01010000200400000000000000000000000000000000000000

La sortie PostGIS EWKT a quelques différences avec le OGC WKT :

EWKT évite de sur-spécifier les dimensions et ainsi éviter les inconsistances possibles avec le format OGC/ISO, comme :

	Les formats étendus PostGIS sont des sur-ensembles des formats OGC, donc les représentations valides WKB/WKT sont aussi des représentations EWKB/EWKT valides. Cependant, cela pourrait changer à l'avenir, si l'OGC définit un format qui rentrerait en conflit avec la définition de PosGIS. Vous ne devriez donc PAS vous appuyer sur cette compatibilité !

Voici quelques exemples de représentations d'objets spatiaux sous forme EWKT :

Des méthodes d'entrée/sortie sont fournies via les fonctions 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 pour créer et insérer une objet spatial sous forme de EWKT :

INSERT INTO geotable ( geom, name )
  VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

Vous pouvez créer une table pour stocker des données géographiques en utilisant la requête SQL CREATE TABLE, avec une colonne de type geography. L'exemple suivant créé une table avec une colonne géographique pour stocker des lignes 2D dans un SCR géodésique WGS84 (SRID 4326) :

CREATE TABLE global_points (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    location geography(POINT,4326)
  );

Le type geography supporte deux modificateurs de type :

Exemples de création de tables utilisant des colonnes géographiques :

Les colonnes géographiques sont enregistrées dans la vue système geography_columns. Vous pouvez effectuer un requête sur la vue geography_columns et vérifier que la table est bien listée :

SELECT * FROM geography_columns;

La création d'index spatiaux sur les colonnes de type geography fonctionne de la même manière qu'avec le type geometry. PostGIS va prendre en compte que le type de la colonne est GEOGRAPHY et créer un index sphérique au lieu d'un index planaire utilisé pour GEOMETRY.

-- Index the test table with a spherical index
CREATE INDEX global_points_gix ON global_points USING GIST ( location );

Vous pouvez insérer des données dans des tables géographiques de la même façon qu'avec les géométries. Les données géométriques seront automatiquement transtypées en type geography si le SRID des données est 4326. Les formats EWKT et EWKB peuvent aussi être utilisés pour spécifier les valeurs géographiques.

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

Tout CRS géodésique (longitude/latitude) disponible dans la table spatial_ref_sys peut être utilisé comme SRID d'une géographie. L'utilisation d'un CRS non géodésique provoquera une erreur.

-- NAD 83 lon/lat
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140

-- NAD27 lon/lat
SELECT 'SRID=4267;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140

-- NAD83 UTM zone meters - gives an error since it is a meter-based planar projection
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.

Les requêtes et les fonctions de mesure utilisent le mètre comme unité. Les paramètres de distance doivent être exprimés en mètres, et les valeurs de retours seront également en mètres (ou en mètres carré pour les surfaces).

-- A distance query using a 1000km tolerance
SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

Vous pouvez vérifier la puissance des géographies en calculant à quel point un avion s'approche de Reykjavik (POINT(-21.96 64.15)) lors d'un trajet en arc de cercle depuis Seattle à Londres (LINESTRING(-122.33 47.606, 0.0 51.5)) (voir la route).

Le type geography donne la plus petite distance réelle de 122,235 km sur la sphère entre Reykjavik et l'arc de cercle entre Seattle et Londres.

-- Distance calculation using GEOGRAPHY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);
   st_distance
-----------------
 122235.23815667

Le type geometry quant à lui calcule la distance cartésienne entre Reykjavik et la ligne droite entre Seattle et Londres, telle qu'elle serait tracée sur un plan. Cette distance n'a pas de sens réel, d'autant que l'unité du résultat est techniquement en degrés, mais que le résultat ne correspond à aucune différence angulaire entre les points, donc même considérer le résultat comme des degrés serait faux.

-- Distance calculation using GEOMETRY
SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);
      st_distance
--------------------
 13.342271221453624

Le type de données geography permet de stocker des données en utilisant les coordonnées longitude/latitude, mais cela a un prix : il y a moins de fonctions disponibles sur le type GEOGRAPHY que sur le type GEOMETRY, et les fonctions disponibles prendront plus de temps CPU pour s'exécuter.

Le type de données à choisir devrait être déterminé par la zone de travail de l'application que vous construisez. Est-ce que vos données s'étendront sur l'ensemble du globe ou sur un continent, ou bien est-ce qu'elle seront locales, comme une région, un département ou une ville ?

Référez-vous à Section 12.11, “Matrice d'aide aux fonctions de PostGIS” pour comparer les supports Geography et Geometry. Pour avoir un résumé des fonctions géographiques disponibles, référez-vous à Section 12.4, “Fonctions d'aide au type geography de PostGIS”

Une géométrie simple est une géométrie qui ne présente pas de points géométriques anormaux, tels qu'une intersection ou une tangence propre.

Un POINT est intrinsèquement simple en tant qu'objet géométrique à 0 dimension.

Les MULTIPOINT sont simples si deux coordonnées (POINTs) ne sont pas égales (ont des valeurs de coordonnées identiques).

Une LINESTRING est simple si elle ne passe pas deux fois par le même point, à l'exception des extrémités. Si les extrémités d'une simple LineString sont identiques, elle est dite fermée et appelée anneau linéaire.

(a) et (c) sont des LINESTRING simples. (b) et (d) ne sont pas simples. (c) est un anneau linéaire fermé.

(a)	(b)
(c)	(d)

Un MULTILINESTRING est simple uniquement si tous ses éléments sont simples et si la seule intersection entre deux éléments quelconques se produit en des points situés sur les limites des deux éléments.

(e) et (f) sont de simples MULTILINESTRINGs. (g) n'est pas simple.

(e)

(f)

(g)

Les POLYGON sont formés à partir d'anneaux linéaires, de sorte que la géométrie polygonale valide est toujours simple.

Pour tester si une géométrie est simple, utilisez la fonction ST_IsSimple :

SELECT
   ST_IsSimple('LINESTRING(0 0, 100 100)') AS straight,
   ST_IsSimple('LINESTRING(0 0, 100 100, 100 0, 0 100)') AS crossing;

 straight | crossing
----------+----------
 t        | f

En général, les fonctions PostGIS n'exigent pas que les arguments géométriques soient simples. La simplicité est principalement utilisée comme base pour définir la validité géométrique. C'est également une exigence pour certains types de modèles de données spatiales (par exemple, les réseaux linéaires interdisent souvent les lignes qui se croisent). La géométrie multipoint et linéaire peut être rendue simple en utilisant ST_UnaryUnion.

La validité géométrique s'applique principalement aux géométries bidimensionnelles (POLYGONs et MULTIPOLYGONs). La validité est définie par des règles qui permettent à la géométrie polygonale de modéliser des zones planes sans ambiguïté.

Un POLYGON est valide si :

(h) et (i) sont des POLYGON valides. (j-m) ne sont pas valides. (j) peut être représenté comme un MULTIPOLYGON valide.

(h)	(i)	(j)
(k)	(l)	(m)

Un MULTIPOLYGON est valide si :

(n) est un MULTIPOLYGON valide. (o) et (p) ne sont pas valides.

(n)

(o)

(p)

Ces règles signifient que la géométrie polygonale valide est également simple.

Pour la géométrie linéaire, la seule règle de validité est que les LINESTRING doivent avoir au moins deux points et une longueur non nulle (ou, de façon équivalente, au moins deux points distincts).

SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)') AS len_nonzero,
   ST_IsValid('LINESTRING(0 0, 0 0, 0 0)') AS len_zero,
   ST_IsValid('LINESTRING(10 10, 150 150, 180 50, 20 130)') AS self_int;

 len_nonzero | len_zero | self_int
-------------+----------+----------
 t           | f        | t

Les géométries POINT et MULTIPOINT n'ont pas de règles de validité.

PostGIS permet de créer et de stocker des géométries valides et non valides. Cela permet de détecter les géométries non valides et de les signaler ou de les corriger. Il existe également des situations où les règles de validité de l'OGC sont plus strictes que souhaité (par exemple, les lignes de longueur nulle et les polygones avec des trous inversés).

De nombreuses fonctions fournies par PostGIS reposent sur l'hypothèse que les arguments géométriques sont valides. Par exemple, il n'est pas logique de calculer la surface d'un polygone dont le trou est défini à l'extérieur du polygone, ou de construire un polygone à partir d'une ligne de démarcation non simple. Le fait de supposer que les entrées géométriques sont valides permet aux fonctions de fonctionner plus efficacement, puisqu'elles n'ont pas besoin de vérifier l'exactitude topologique. (Les exceptions notables sont que les lignes de longueur nulle et les polygones avec des inversions sont généralement traités correctement). En outre, la plupart des fonctions PostGIS produisent une géométrie valide si les données d'entrée sont valides. Cela permet d'enchaîner les fonctions PostGIS en toute sécurité.

Si vous rencontrez des messages d'erreur inattendus lors de l'appel de fonctions PostGIS (tels que "GEOS Intersection() threw an error !"), vous devez d'abord vous assurer que les arguments de la fonction sont valides. Si ce n'est pas le cas, envisagez d'utiliser l'une des techniques ci-dessous pour vous assurer que les données que vous traitez sont valides.

	Si une fonction signale une erreur avec des entrées valides, il se peut que vous ayez trouvé une erreur dans PostGIS ou dans l'une des bibliothèques qu'il utilise, et vous devez le signaler au projet PostGIS. Il en va de même si une fonction PostGIS renvoie une géométrie non valide pour des données d'entrée valides.

Pour vérifier si une géométrie est valide, utilisez la fonction ST_IsValid :

SELECT ST_IsValid('POLYGON ((20 180, 180 180, 180 20, 20 20, 20 180))');
-----------------
 t

Les informations relatives à la nature et à la localisation d'une invalidité géométrique sont fournies par la fonction ST_IsValidDetail :

SELECT valid, reason, ST_AsText(location) AS location
    FROM ST_IsValidDetail('POLYGON ((20 20, 120 190, 50 190, 170 50, 20 20))') AS t;

 valid |      reason       |                  location
-------+-------------------+---------------------------------------------
 f     | Self-intersection | POINT(91.51162790697674 141.56976744186045)

Dans certaines situations, il est souhaitable de corriger automatiquement la géométrie non valide. Utilisez la fonction ST_MakeValid pour ce faire. (ST_MakeValid est un exemple de fonction spatiale qui doit permettre une entrée non valide).

Par défaut, PostGIS ne vérifie pas la validité lors du chargement de la géométrie, car les tests de validité peuvent prendre beaucoup de temps CPU pour les géométries complexes. Si vous ne faites pas confiance à vos sources de données, vous pouvez imposer un contrôle de validité à vos tables en ajoutant une contrainte de contrôle :

ALTER TABLE mytable
  ADD CONSTRAINT geometry_valid_check
        CHECK (ST_IsValid(geom));

La table SPATIAL_REF_SYS utilisée par PostGIS est une table de base de données conforme à l'OGC qui définit les systèmes de référence spatiale disponibles. Elle contient les SRID numériques et les descriptions textuelles des systèmes de coordonnées.

La définition de la table spatial_ref_sys est la suivante :

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

Les colonnes sont :

Lors de la récupération des définitions des systèmes de référence spatiale pour les utiliser dans les transformations, PostGIS utilise la stratégie suivante :

La table PostGIS spatial_ref_sys contient plus de 3000 définitions des systèmes de référence spatiale les plus courants qui sont gérés par la bibliothèque de projection PROJ. Mais il existe de nombreux systèmes de coordonnées qu'elle ne contient pas. Vous pouvez ajouter des définitions de SRS à la table si vous disposez des informations requises sur le système de référence spatiale. Vous pouvez également définir votre propre système de référence spatiale personnalisé si vous êtes familiarisé avec les constructions PROJ. Gardez à l'esprit que la plupart des systèmes de référence spatiale sont régionaux et n'ont aucune signification lorsqu'ils sont utilisés en dehors des limites pour lesquelles ils ont été conçus.

Une ressource permettant de trouver des systèmes de référence spatiale non définis dans le jeu de base est http://spatialreference.org/

Les systèmes de référence spatiale les plus couramment utilisés sont les suivants : 4326 - WGS 84 Long Lat, 4269 - NAD 83 Long Lat, 3395 - WGS 84 World Mercator, 2163 - US National Atlas Equal Area, et les 60 zones UTM WGS84. Les zones UTM sont parmi les plus idéales pour les mesures, mais elles ne couvrent que des régions de 6 degrés. (Pour déterminer la zone UTM à utiliser pour votre zone d'intérêt, voir la utmzone PostGIS plpgsql helper function.)

Les États américains utilisent des systèmes de référence spatiale State Plane (basés sur le mètre ou le pied) - il en existe généralement un ou deux par État. La plupart des systèmes basés sur le mètre se trouvent dans le jeu de base, mais de nombreux systèmes basés sur le pied ou créés par ESRI devront être copiés à partir de spatialreference.org.

Vous pouvez même définir des systèmes de coordonnées non terrestres, tels que Mars 2000 Ce système de coordonnées martien n'est pas planaire (il est en degrés sphéroïdaux), mais vous pouvez l'utiliser avec le type géographie pour obtenir des mesures de longueur et de proximité en mètres au lieu de degrés.

Voici un exemple de chargement d'un système de coordonnées personnalisé à l'aide d'un SRID non attribué et de la définition PROJ pour une projection Lambert conforme centrée sur les États-Unis :

INSERT INTO spatial_ref_sys (srid, proj4text)
VALUES ( 990000,
  '+proj=lcc  +lon_0=-95 +lat_0=25 +lat_1=25 +lat_2=25 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs'
);

Vous pouvez créer une table pour stocker des données géométriques en utilisant l'instruction SQL CREATE TABLE avec une colonne de type geometry. L'exemple suivant crée une table avec une colonne géométrie stockant des chaînes de lignes 2D (XY) dans le système de coordonnées BC-Albers (SRID 3005) :

CREATE TABLE roads (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    geom geometry(LINESTRING,3005)
  );

Le type geometry prend en charge deux modificateurs de type facultatifs :

Exemples de création de tableaux avec des colonnes géométriques :

Il est possible d'avoir plus d'une colonne de géométrie dans une table. Cela peut être spécifié lors de la création de la table, ou une colonne peut être ajoutée à l'aide de l'instruction SQL ALTER TABLE. Cet exemple ajoute une colonne qui peut contenir des LineStrings 3D :

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);

L'OGC Simple Features Specification for SQL définit la table de métadonnées GEOMETRY_COLUMNS pour décrire la structure de la table géométrique. Dans PostGIS, geometry_columns est une vue qui lit les tables de catalogue du système de base de données. Cela garantit que les informations de métadonnées spatiales sont toujours cohérentes avec les tables et les vues actuellement définies. La structure de la vue est la suivante :

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

Les colonnes sont :

Deux des cas où vous pouvez avoir besoin de cela sont les cas de vues SQL et les insertions en masse. Dans le cas des insertions en masse, vous pouvez corriger l'enregistrement dans la table geometry_columns en contraignant la colonne ou en effectuant une modification de la table. Pour les vues, vous pouvez exposer en utilisant une opération CAST. Notez que si votre colonne est basée sur un typmod, le processus de création l'enregistrera correctement, il n'est donc pas nécessaire de faire quoi que ce soit. De même, les vues qui n'ont pas de fonction spatiale appliquée à la géométrie s'enregistreront de la même manière que la colonne géométrique de la table sous-jacente.

-- Lets say you have a view created like this
CREATE VIEW public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395) As geom, f_name
        FROM public.mytable;

-- For it to register correctly
-- You need to cast the geometry
--
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
        FROM public.mytable;

-- If you know the geometry type for sure is a 2D POLYGON then you could do
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name
        FROM public.mytable;

--Lets say you created a derivative table by doing a bulk insert
SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

-- Create 2D index on new table
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- If your points are 3D points or 3M points,
-- then you might want to create an nd index instead of a 2D index
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- To manually register this new table's geometry column in geometry_columns.
-- Note it will also change the underlying structure of the table to
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- If you are using PostGIS 2.0 and for whatever reason, you
-- you need the constraint based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); 

Bien que l'ancienne méthode basée sur les contraintes soit toujours supportée, une colonne géométrique basée sur les contraintes utilisée directement dans une vue ne s'enregistrera pas correctement dans geometry_columns, tout comme une colonne typmod. Dans cet exemple, nous définissons une colonne à l'aide de typmod et une autre à l'aide de contraintes.

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

Si nous exécutons dans psql

\d pois_ny;

Nous observons qu'ils sont définis différemment - l'un est un typmod, l'autre une contrainte

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

Dans geometry_columns, les deux s'enregistrent correctement

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

Cependant, si nous devions créer une vue comme celle-ci

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

La colonne de la vue géométrique basée sur le modèle s'enregistre correctement, mais pas celle basée sur les contraintes.

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

Cela pourrait changer dans les prochaines versions de PostGIS, mais pour l'instant, pour forcer la colonne de vue basée sur les contraintes à s'enregistrer correctement, vous devez procéder comme suit :

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

Si les données spatiales peuvent être converties en une représentation textuelle (WKT ou WKB), l'utilisation de SQL pourrait être le moyen le plus simple d'introduire les données dans PostGIS. Les données peuvent être chargées en masse dans PostGIS/PostgreSQL en chargeant un fichier texte d'instructions SQL INSERT à l'aide de l'utilitaire SQL psql.

Un fichier de chargement SQL (roads.sql par exemple) peut ressembler à ceci :

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres');
COMMIT;

Le fichier SQL peut être chargé dans PostgreSQL en utilisant psql :

psql -d [database] -f roads.sql

Le chargeur de données shp2pgsql convertit les Shapefiles en SQL pour les insérer dans une base de données PostGIS/PostgreSQL au format geometry ou geography. Le chargeur a plusieurs modes de fonctionnement sélectionnés par des indicateurs de ligne de commande.

Il existe également une interface graphique shp2pgsql-gui qui offre la plupart des options du chargeur en ligne de commande. Cette interface peut être plus facile à utiliser pour un chargement ponctuel sans script ou si vous êtes novice en matière de PostGIS. Il peut également être configuré comme un plugin pour PgAdminIII.

Un exemple de session utilisant le chargeur pour créer un fichier d'entrée et le charger peut ressembler à ceci :

# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable > roads.sql
# psql -d roadsdb -f roads.sql

Une conversion et un chargement peuvent être effectués en une seule étape à l'aide de pipes UNIX :

# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

La manière la plus simple d'extraire des données spatiales de la base de données consiste à utiliser une requête SQL SELECT pour définir l'ensemble de données à extraire et à transférer les colonnes résultantes dans un fichier texte analysable :

db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
          1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
          2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
          3 | LINESTRING(192783 228138,192612 229814) | Paul St
          4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
          5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
          6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
          7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

Il peut arriver qu'une restriction soit nécessaire pour réduire le nombre d'enregistrements renvoyés. Dans le cas de restrictions basées sur des attributs, utilisez la même syntaxe SQL que pour une table non spatiale. Dans le cas de restrictions spatiales, les fonctions suivantes sont utiles :

Vous pouvez ensuite utiliser ces opérateurs dans des requêtes. Notez que lorsque vous spécifiez des géométries et des box sur la ligne de commande SQL, vous devez explicitement transformer les représentations de chaînes de caractères en fonction géométrique. Le 312 est un système de référence spatiale fictif qui correspond à nos données. Ainsi, par exemple, le 312 est un système de référence spatiale fictif qui correspond à nos données :

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

La requête ci-dessus renverrait le seul enregistrement de la table "ROADS_GEOM" dont la géométrie est égale à cette valeur.

Vérifier si certaines routes passent dans la zone définie par un polygone :

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

La requête spatiale la plus courante sera probablement une requête "basée sur un cadre", utilisée par les logiciels clients, tels que les navigateurs de données et les cartographes web, pour saisir un "cadre de carte" d'une valeur de données pour l'affichage.

Lorsque vous utilisez l'opérateur "&&", vous pouvez spécifier soit une BOX3D comme élément de comparaison, soit une GEOMETRY. Toutefois, lorsque vous spécifiez une GEOMETRY, c'est sa boîte de délimitation qui sera utilisée pour la comparaison.

En utilisant un objet "BOX3D" pour le cadre, une telle requête se présente comme suit :

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

Notez l'utilisation du SRID 312 pour spécifier la projection de l'enveloppe.

Le table dumper pgsql2shp se connecte à la base de données et convertit une table (éventuellement définie par une requête) en un fichier shape. La syntaxe de base est la suivante :

pgsql2shp [<options>] <database> [<schema>.]<table>

pgsql2shp [<options>] <database> <query>

Les options de la ligne de commande sont les suivantes :

GiST signifie "Generalized Search Tree" (arbre de recherche généralisé) et constitue une forme générique d'indexation pour les données multidimensionnelles. PostGIS utilise un index R-Tree implémenté au-dessus de GiST pour indexer les données spatiales. GiST est la méthode d'indexation spatiale la plus couramment utilisée et la plus polyvalente, et offre de très bonnes performances en matière de requêtes. D'autres implémentations de GiST sont utilisées pour accélérer les recherches sur toutes sortes de structures de données irrégulières (tableaux d'entiers, données spectrales, etc.) qui ne se prêtent pas à l'indexation B-Tree normale. Pour plus d'informations, voir le manuel PostgreSQL.

Dès qu'une table de données spatiales dépasse quelques milliers de lignes, vous devez créer un index pour accélérer les recherches spatiales dans les données (sauf si toutes vos recherches sont basées sur des attributs, auquel cas vous devez créer un index normal sur les champs d'attributs).

La syntaxe pour construire un index GiST sur une colonne "geometry" est la suivante :

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

La syntaxe ci-dessus permet toujours de créer un index 2D. Pour obtenir un index à n dimensions pour le type de géométrie, vous pouvez en créer un à l'aide de cette syntaxe :

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

La construction d'un index spatial est un exercice de calcul intensif. Il bloque également l'accès en écriture à votre table pendant le temps de sa création, donc sur un système de production, vous voudrez peut-être le faire d'une manière plus lente, en tenant compte de la notion de CONCURRENCE :

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

Après avoir construit un index, il est parfois utile de forcer PostgreSQL à collecter les statistiques de la table, qui sont utilisées pour optimiser les plans de requête :

VACUUM ANALYZE [table_name] [(column_name)];

BRIN signifie "Block Range Index". C'est une méthode d'indexation générale introduite dans PostgreSQL 9.5. BRIN est une méthode d'indexation lossy, ce qui signifie qu'une vérification secondaire est nécessaire pour confirmer qu'un enregistrement correspond à une condition de recherche donnée (ce qui est le cas pour tous les index spatiaux fournis). Elle permet une création d'index beaucoup plus rapide et une taille d'index beaucoup plus petite, avec des performances de lecture raisonnables. Son objectif principal est de permettre l'indexation de très grandes tables sur des colonnes qui ont une corrélation avec leur emplacement physique dans la table. Outre l'indexation spatiale, BRIN peut accélérer les recherches sur divers types de structures de données d'attributs (entiers, tableaux, etc.). Pour plus d'informations, voir le Manuel de PostgreSQL.

Dès qu'une table spatiale dépasse quelques milliers de lignes, vous voudrez construire un index pour accélérer les recherches spatiales dans les données. Les index GiST sont très performants tant que leur taille ne dépasse pas la quantité de mémoire vive disponible pour la base de données, et tant que vous pouvez vous permettre la taille de stockage de l'index et le coût de la mise à jour de l'index en écriture. Sinon, pour les très grandes tables, l'index BRIN peut être considéré comme une alternative.

Un index BRIN stocke la boîte englobant toutes les géométries contenues dans les lignes d'un ensemble contigu de blocs de table, appelé plage de blocs. Lors de l'exécution d'une requête à l'aide de l'index, les plages de blocs sont examinées pour trouver celles qui recoupent l'étendue de la requête. Cette méthode n'est efficace que si les données sont physiquement ordonnées de manière à ce que les zones de délimitation des plages de blocs se chevauchent le moins possible (et, dans l'idéal, s'excluent mutuellement). L'index qui en résulte est de très petite taille, mais il est généralement moins performant en lecture qu'un index GiST sur les mêmes données.

La construction d'un index BRIN est beaucoup moins gourmande en ressources CPU que la construction d'un index GiST. Il est courant de constater qu'un index BRIN est dix fois plus rapide à construire qu'un index GiST pour les mêmes données. Et comme un index BRIN ne stocke qu'une seule boîte englobante pour chaque plage de blocs de table, il est courant d'utiliser jusqu'à mille fois moins d'espace disque qu'un index GiST.

Vous pouvez choisir le nombre de blocs à résumer dans une plage. Si vous diminuez ce nombre, l'index sera plus volumineux mais offrira probablement de meilleures performances.

Pour que le BRIN soit efficace, les données de la table doivent être stockées dans un ordre physique qui minimise le chevauchement de l'étendue du bloc. Il se peut que les données soient déjà triées de manière appropriée (par exemple, si elles sont chargées à partir d'un autre jeu de données déjà trié dans l'ordre spatial). Dans le cas contraire, il est possible de trier les données en fonction d'une clé spatiale unidimensionnelle. Une façon de procéder consiste à créer une nouvelle table triée par les valeurs géométriques (qui, dans les versions récentes de PostGIS, utilisent un classement efficace par courbe de Hilbert) :

CREATE TABLE table_sorted AS
   SELECT * FROM table  ORDER BY geom;

Il est également possible de trier les données en place en utilisant un GeoHash comme index (temporaire) et en effectuant un regroupement sur cet index :

CREATE INDEX idx_temp_geohash ON table
    USING btree (ST_GeoHash( ST_Transform( geom, 4326 ), 20));
CLUSTER table USING idx_temp_geohash;

La syntaxe pour construire un index BRIN sur une colonne geometry est la suivante :

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geome_col] ); 

La syntaxe ci-dessus permet de créer un index en 2D. Pour construire un index à trois dimensions, utilisez la syntaxe suivante :

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_3d);

Vous pouvez également obtenir un index quadridimensionnel à l'aide de la classe d'opérateurs 4D :

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ([geome_col] brin_geometry_inclusion_ops_4d);

Les commandes ci-dessus utilisent le nombre par défaut de blocs dans une plage, qui est de 128. Pour spécifier le nombre de blocs à résumer dans une plage, utilisez la syntaxe suivante

CREATE INDEX [indexname] ON [tablename]
    USING BRIN ( [geome_col] ) WITH (pages_per_range = [number]); 

Gardez à l'esprit qu'un index BRIN ne stocke qu'une entrée d'index pour un grand nombre de lignes. Si votre table stocke des géométries avec un nombre variable de dimensions, il est probable que l'index qui en résultera sera peu performant. Vous pouvez éviter cette pénalité de performance en choisissant la classe d'opérateur avec le plus petit nombre de dimensions des géométries stockées

Le type de données geography est pris en charge pour l'indexation BRIN. La syntaxe pour construire un index BRIN sur une colonne géographique est la suivante :

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geog_col] ); 

La syntaxe ci-dessus permet de créer un index 2D pour les objets géospatiaux sur le sphéroïde.

Actuellement, seul le "support d'inclusion" est fourni, ce qui signifie que seuls les opérateurs &&, ~ et @ peuvent être utilisés pour les cas 2D (à la fois pour geometry et geography), et seulement l'opérateur &&& pour les géométries 3D. Il n'y a actuellement pas de support pour les recherches kNN.

Une différence importante entre BRIN et les autres types d'index est que la base de données ne maintient pas l'index de manière dynamique. Les modifications apportées aux données spatiales de la table sont simplement ajoutées à la fin de l'index. Cela entraîne une dégradation des performances de recherche de l'index au fil du temps. L'index peut être mis à jour en effectuant un VACUUM, ou en utilisant une fonction spéciale brin_summarize_new_values(regclass). C'est la raison pour laquelle BRIN peut être plus approprié pour les données qui sont en lecture seule ou qui ne changent que rarement. Pour plus d'informations, consultez le manuel.

En résumé, l'utilisation de BRIN pour les données spatiales :

SP-GiST signifie "Space-Partitioned Generalized Search Tree" et est une forme générique d'indexation pour les types de données multidimensionnelles qui prend en charge les arbres de recherche partitionnés, tels que les arbres quadratiques, les arbres k-d et les arbres radix (tries). La caractéristique commune de ces structures de données est qu'elles divisent de manière répétée l'espace de recherche en partitions qui ne sont pas nécessairement de taille égale. Outre l'indexation spatiale, SP-GiST est utilisé pour accélérer les recherches sur de nombreux types de données, telles que le routage téléphonique, le routage ip, la recherche de substrats, etc. Pour plus d'informations, voir le manuel PostgreSQL.

Comme pour les index GiST, les index SP-GiST sont avec perte, dans le sens où ils stockent la boîte englobante qui entoure les objets spatiaux. Les index SP-GiST peuvent être considérés comme une alternative aux index GiST.

Lorsqu'une table de données SIG dépasse quelques milliers de lignes, un index SP-GiST peut être utilisé pour accélérer les recherches spatiales dans les données. La syntaxe pour construire un index SP-GiST sur une colonne "géométrie" est la suivante :

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

La syntaxe ci-dessus permet de créer un index bidimensionnel. Un index tridimensionnel pour le type de géométrie peut être créé à l'aide de la classe d'opérateurs 3D :

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

La création d'un index spatial est une opération très gourmande en ressources informatiques. Elle bloque également l'accès en écriture à votre table pendant la durée de la création, donc sur un système de production, vous voudrez peut-être le faire d'une manière plus lente, en tenant compte de la notion de CONCURRENCE :

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

Après avoir construit un index, il est parfois utile de forcer PostgreSQL à collecter les statistiques de la table, qui sont utilisées pour optimiser les plans de requête :

VACUUM ANALYZE [table_name] [(column_name)];

Un index SP-GiST peut accélérer les requêtes impliquant les opérateurs suivants :

Il n'y a pas de support pour les recherches kNN pour le moment.

Normalement, les index accélèrent de manière invisible l'accès aux données : une fois qu'un index est construit, le planificateur de requêtes de PostgreSQL décide automatiquement quand l'utiliser pour améliorer les performances de la requête. Mais dans certaines situations, le planificateur ne choisit pas d'utiliser les index existants, et les requêtes finissent par utiliser des balayages séquentiels lents au lieu d'un index spatial.

Si vous constatez que vos index spatiaux ne sont pas utilisés, il y a plusieurs choses que vous pouvez faire :

Pour plus d'informations, voir la section du manuel Postgres sur Query Planning.