4.2. Utilisation des standards de l'OpenGIS
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.
4.2.1. La table SPATIAL_REF_SYS
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 :
CREATE TABLE SPATIAL_REF_SYS (
SRID INTEGER NOT NULL PRIMARY KEY,
AUTH_NAME VARCHAR(256),
AUTH_SRID INTEGER,
SRTEXT VARCHAR(2048),
PROJ4TEXT VARCHAR(2048)
)
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.
haut de la page | table des matières 4.2.2. La table GEOMETRY_COLUMNS
La définition de la table GEOMETRY_COLUMNS est la suivante :
CREATE TABLE GEOMETRY_COLUMNS (
F_TABLE_CATALOG VARCHAR(256) NOT NULL,
F_TABLE_SCHEMA VARCHAR(256) NOT NULL,
F_TABLE_NAME VARCHAR(256) NOT NULL,
F_GEOMETRY_COLUMN VARCHAR(256) NOT NULL,
COORD_DIMENSION INTEGER NOT NULL,
SRID INTEGER NOT NULL,
TYPE VARCHAR(30) NOT NULL
)
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.
haut de la page | table des matières 4.2.3. Créer une table spatiale
Créer une table avec des données géographiques se déroule en deux étapes :
- Créer une table (non-spatialisée) normale. Par exemple :
CREATE TABLE ROADS_GEOM ( ID int4, NAME varchar(25) )
- 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à) :
CREATE TABLE parks ( PARK_ID int4, PARK_NAME varchar(128), PARK_DATE date, PARK_TYPE varchar(2) );
SELECT AddGeometryColumn('parks', 'park_geom', 128, 'MULTIPOLYGON', 2 );
Voici un autre exemple, utilisant le type générique "geometry" et un SRID indéfinie de valeur -1 :
CREATE TABLE roads ( ROAD_ID int4, ROAD_NAME varchar(128) );
SELECT AddGeometryColumn( 'roads', 'roads_geom', -1, 'GEOMETRY', 3 );
haut de la page | table des matières 4.2.4. Assurer la conformité OpenGIS des géométries
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()
:
gisdb=# select isvalid('LINESTRING(0 0, 1 1)'), isvalid('LINESTRING(0 0,0 0)');
isvalid | isvalid
---------+---------
t | f
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 :
ALTER TABLE mytable ADD CONSTRAINT geometry_valid_check CHECK (isvalid(the_geom));
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.
haut de la page | table des matières