Changer SRID mais absence de SRID

Georgie · 24/10/2012 19:18:30

Tout est dans le titre.
Voilà j'aimerai changer la projection d'une table, mais il semblerait que celle-ci ne possède même pas de SRID, ce qui bloquerait la fonction permettant de changer le SRID.
Cette table s'affiche pourtant sans problème dans QGIS.
Ma question est donc : comment conférer un SRID à une table ?
J'avoue avoir chercher sur le net, mais sans succès.
Merci d'avance !!!

Dernière modification par Georgie (24/10/2012 19:59:04)

SQLpro · 25/10/2012 16:27:41

Il n'y a pas de projection dans une table, ni même dans une colonne. Le SRID n'est même pas une projection. C'est un référentiel de sphéroïde valable localement ou terrestriel. Il sert à effectuer des calculs précis compte tenu de la courbure retenue, par exemple pour la navigation orthodromique. Il est propre à chaque données de type géographique.

Commencez donc par nous préciser :
1) quelle version de PostGreSQL
2) quelle version de PostGIS
3) la description DDL de la table
4) un exemple de données

A +

vincentp · 26/10/2012 16:57:05

Bonjour.

Mettre des gros mots dans les phrases pour que personne comprenne n'autorise pas à dire des bêtises. Je me permets donc de corriger légèrement vos propos.

Commençons par le problème initial.
On parle de PostGIS < 2.0, le fonctionnement est différent (et un peu plus simple) pour du >= 2.0.

A priori Georgie a du faire un chargement de données géographiques sans spécifier le système de coordonnées d'origine. Le chargement a donc été fait en donnant un SRID à -1, qui est la valeur que PostGIS utilise pour dire que le SRID est inconnu.

Comme ce système d'origine est inconnu de PostGIS, on ne peut pas faire de reprojection. La table s'affiche dans QGIS car ce dernier imagine que si le SRID est inconnu on utilise le SRID 4326 (ou alors la projection par défaut du projet en cours). Le SRID 4326 est l'indication de coordonnées en latitude/longitude (donc non projeté). I

Il faut donc remettre tout ça en ordre.

Le SRID est stocké à deux endroits : dans la table geometry_columns (métadonnées sur la base géo), et dans chaque géométrie. Il faut donc modifier les deux. Ce qui est sympa c'est qu'il y a une fonction pour ça :

UpdateGeometrySRID(varchar table_name, varchar column_name, integer srid)

La doc : http://postgis.refractions.net/document … ySRID.html

Par exemple ici :

SELECT UpdateGeometrySRID('matable', 'the_geom', 4326);

Sinon il faut le faire à la main :

- Supprimer les contraintes sur la table en question (avec pgadmin par exemple c'est le plus simple). puis :
- update matable set the_geom = st_setsrid(the_geom, 4326);
- remettre les contraintes et les infos dans geometry_columns (par exemple avec populate_geometry_columns())

Ensuite, corrigeons des idées fausses :

Un SRID est un identifiant de projection (sisi). Il est en fait un numéro qui référence une entrée dans une liste de projections (table spatial_ref_sys pour PostGIS).

Chaque entrée de cette liste contient la définition mathématique de ladite projection : le type de projection, les paramètres d'icelle, et l'ellipsoïde de référence utilisée pour la modélisation de la terre. Les SRID correspondent (quasi toujours) aux codes standardisés par l'EPSG.

À noter que certains SRID déterminent un système de coordonnée non projeté. C'est le cas de EPSG:4326, qui a des coordonnées en latitude, longitude, donc en angles référencés sur une sphéroïde de référence.

Ce SRID est stocké dans la table de métadonnées geometry_columns ET dans la sérialisation de la géométrie qui est stockée dans la colonne géométrique des tables elles-mêmes.

La définition de la projection de la table spatial_ref_sys est utilisée par PROJ pour effectuer les calculs de projection.

Donc en résumé :
- il y a un identifiant SRID de projection dans les métadonnées des tables
- il y a un identifiant SRID de projection dans les géométries d'une colonne de type geometry
- Un SRID correspond à une projection
- Une projection utilise une sphéroïde de référence mais contient plus que ça (sauf cas de coordonnées sphériques).
- Les codes de projections sont (pour la plupart) standardisés, et les données d'un même ensemble partagent généralement la même projection.

Au plaisir,
Vincent

Dernière modification par vincentp (26/10/2012 16:58:27)

SQLpro · 26/10/2012 18:22:48

Non, vous vous trompez. Le SRID est un système de référence (coordonnées utilisées pour la courbure du sphéroïde , point de référence et unité de mesure). Une famille de projection peut être déduite d'après les données géométriques + le SRID... Dire que le SRID est la projection, c'est une ellipse (au sens figuré évidemment) un peu raccourcie (cette fois au sens propre)... La meilleure preuve est qu'à partir de telles données plusieurs types de projections sont possible dans la même famille de projection. Exemple projection conique de Delisles, Albers, Lambert...

A +

Dernière modification par SQLpro (26/10/2012 18:23:20)

Olivier Courtin · 27/10/2012 17:22:24

@SQLp*
En moins de 5 lignes arriver à cumuler: #14, #17 et #36 constitue une performance à part entière.
(cf http://fr.wikisource.org/wiki/L%E2%80%9 … urs_raison)

Pour ceux qui ont par contre envie de comprendre quelque chose sur ce sujet,
le moins que l'on puisse dire c'est que vous n'êtes pas aidant.

Comme Vincent le mentionnait, le SRID est l'identifiant de système de projection.
(cf le standard sous jacent OGC Simple Feature for SQL)

Pour faire suite, à une de vos méconnaissances, apparaissant à la lecture de votre dernier post:

- Les coordonnées géométriques ne suffisent pas à inférer à quel système/famille
de projection la géométrie fait référence (d'où l'intérêt du SRID pour se faire).

Votre 'meilleure preuve' me demeure inintelligible.

Pour revenir à la demande initiale de Georgie,
il est important d'insister sur le fait qu'associer un SRID à ses géométries,
est vraiment une 'bonne pratique', et va ensuite permettre:

- de lancer des reprojections via ST_Transform (comme déjà mentionné par Vincent)

- d'empêcher tout UPDATE ou INSERT de Geometry ayant un autre SRID,
dans une même colonne géométrique (via des CHECK pour PostGIS 1.x
et les Typmods pour PostGIS 2.x)

- de permettre aux fonctions d'analyses spatiales utilisant plusieurs géométries en entrée
(e.g ST_Intersects) de bien vérifier qu'elles utilisent des géométries d'un même référentiel.

- d'être utilisé par certaines fonctions d'export de PostGIS, où le SRS (ou CRS) peut ensuite
faire partie intégrante du flux de sortie (ST_AsGML par exemple)

- d'éviter qu'un futur utilisateur (potentiellement soi même) puisse ensuite avoir à consacrer
temps et énergie à tenter de retrouver, par la suite, par empirisme et recoupements ,
quel peut bien être le SRID associé à cette colonne géométrique (si tant est qu'il y parvienne).

- que des outils SIG tiers puisse manipuler/afficher correctement les géométries stockées
dans PostgreSQL/PostGIS

(liste pas forcemment exhaustive)

Bref si à l'issue des deux requêtes ci après, la sélection n'est pas vide,
vous savez ce qu'il vous reste à faire (cf post de Vincent)

SELECT populate_geometry_columns();
SELECT f_table_schema, f_table_name, f_geometry_column FROM geometry_columns
WHERE srid <= 0;

(valable pour PostGIS 1.4.x et supérieur)

Enfin pour les plus curieux qui ont envie de creuser davantage le sujet des systèmes de projection,
sans rentrer, immédiatement, dans des considérations trop 'matheuses':

- Cours ENSG sur les systèmes de projections
http://fad.ensg.eu/moodle/file.php/11/G … ctions.pdf

- "Datums and map projections" de J-C Iliffe
ISBN 1-870325-28-1
(couvre ellipsoïde/geoid, bases des systèmes de projections,
et considérations générales sur les transformations d'un système à un autre)

Dernière modification par Olivier Courtin (27/10/2012 17:26:29)

vincentp · 27/10/2012 18:13:03

Petite illustration pratique du mécanisme des SRID dans PostGIS et généralisable à tous les SIG.

Prenons une table "transports" dans PostGIS. On peut visualiser ses métadonnées :

formation=# select * from geometry_columns where f_table_name = 'transports';
 f_table_catalog | f_table_schema | f_table_name | f_geometry_column | coord_dimension | srid  |      type       
-----------------+----------------+--------------+-------------------+-----------------+-------+-----------------
                 | public         | transports   | the_geom          |               2 | 27572 | MULTILINESTRING
(1 ligne)

On voit que le SRID est 27572. On peut vérifier que ce SRID est bien présent dans chaque géométrie :

formation=# select gid, st_srid(the_geom) from transports limit 10;
 gid | st_srid 
-----+---------
   1 |   27572
   2 |   27572
   3 |   27572
   4 |   27572
   5 |   27572
   6 |   27572
   7 |   27572
   8 |   27572
   9 |   27572
  10 |   27572
(10 lignes)

C'est bien le même. Si on regarde les objets de la base, on peut voir qu'il y a une contrainte sur la table transports dont la définition est :

ALTER TABLE transports
  ADD CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = 27572);

Donc à chaque fois qu'on insère ou modifie de la donnée de cette table, on vérifie que le SRID est bien 27572. Une table ("propre") ne contient donc que des géométries ayant le même SRID.

Si on va voir du côté de spatial_ref_sys :

formation=# select srid, auth_name, auth_srid  from spatial_ref_sys where srid = 27572;
 srid  | auth_name | auth_srid 
-------+-----------+-----------
 27572 | EPSG      |     27572
(1 ligne)

Cela signifie que mon SRID correspond à un système de coordonnées standardisé par l'EPSG, et que le SRID de ce système pour cet organisme est également 27572. Il peut parfois y avoir des différences entre le numéro de l'organisme et celui utilisé dans PostGIS comme SRID, mais c'est rare (actuellement aucun dans la table spatial_ref_sys par défaut).

Il s'agit donc de ce système de référence là :

http://spatialreference.org/ref/epsg/27572/

Allons voir la définition WKT de ce SRID. WKT est un format textuel standardisé par l'OGC de représentation des géométries, et également des système de projection.

formation=# select srid, srtext  from spatial_ref_sys where srid = 27572;

 srid  |                                                                                                                                                                                                                                                                                                                                                          srtext                                                                                                                                                                                                                                                                                                                                                          
-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 27572 | PROJCS["NTF (Paris) / Lambert zone II",GEOGCS["NTF (Paris)",DATUM["Nouvelle_Triangulation_Francaise_Paris",SPHEROID["Clarke 1880 (IGN)",6378249.2,293.4660212936265,AUTHORITY["EPSG","7011"]],TOWGS84[-168,-60,320,0,0,0,0],AUTHORITY["EPSG","6807"]],PRIMEM["Paris",2.33722917,AUTHORITY["EPSG","8903"]],UNIT["grad",0.01570796326794897,AUTHORITY["EPSG","9105"]],AUTHORITY["EPSG","4807"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Lambert_Conformal_Conic_1SP"],PARAMETER["latitude_of_origin",52],PARAMETER["central_meridian",0],PARAMETER["scale_factor",0.99987742],PARAMETER["false_easting",600000],PARAMETER["false_northing",2200000],AUTHORITY["EPSG","27572"],AXIS["X",EAST],AXIS["Y",NORTH]]

C'est un peu dense, mais on voit qu'on retombe bien sur la définition donnée par le site spatialreference.org ( http://spatialreference.org/ref/epsg/27572/prettywkt/ )

En plus lisible :

PROJCS["NTF (Paris) / Lambert zone II",
    GEOGCS["NTF (Paris)",
        DATUM["Nouvelle_Triangulation_Francaise_Paris",
            SPHEROID["Clarke 1880 (IGN)",6378249.2,293.4660212936269,
                AUTHORITY["EPSG","7011"]],
            TOWGS84[-168,-60,320,0,0,0,0],
            AUTHORITY["EPSG","6807"]],
        PRIMEM["Paris",2.33722917,
            AUTHORITY["EPSG","8903"]],
        UNIT["grad",0.01570796326794897,
            AUTHORITY["EPSG","9105"]],
        AUTHORITY["EPSG","4807"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Lambert_Conformal_Conic_1SP"],
    PARAMETER["latitude_of_origin",52],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",0.99987742],
    PARAMETER["false_easting",600000],
    PARAMETER["false_northing",2200000],
    AUTHORITY["EPSG","27572"],
    AXIS["X",EAST],
    AXIS["Y",NORTH]]

Que peut on comprendre de ces informations. Principalement plusieurs points :

- C'est un système de projection nommé "NTF (Paris) / Lambert zone II"
- Cette projection est de type "Lambert_Conformal_Conic_1SP", donc une projection conique
- Elle est référencée par l'EPSG sous le code 27572
- Elle est en unité métrique
- Elle est basée sur une ellipsoide de référence qui est la "NTF (Paris)". C'est l'objet modélisant la terre sur lequel on effectue la projection conique.
- L'ellipsoide, comme la projection, sont paramétrées. Ces paramètres servent à la bibliothèque PROJ pour pouvoir faire les calculs de projection.

Proj utilise d'ailleurs en interne une autre notation pour ces informations, qui est également dans la table spatial_ref_sys (et sur spatialreference.org) :

formation=# select srid, proj4text from spatial_ref_sys where srid = 27572;
 srid  |                                                                               proj4text                                                                                
-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 27572 | +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs 
(1 ligne)

Ce sont les mêmes informations représentées un peu différemment.

Nous avons fait le tour du mécanisme de SRID dans PostGIS. Le reste c'est de la théorie de la géodésie. Les plus courageux pourront se lancer dedans.

Au passage, merci pour ce thread, je comprends mieux pourquoi l'article de comparaison sql server spatial versus PostGIS est rempli d'inepties.

Olivier Courtin · 27/10/2012 21:14:40

Pour compléter le post didactique de Vincent,
on peut préciser que dans le cas particulier de PostGIS,
les paramètres utilisés pour reprojeter (lors d'un appel à ST_Transform)
sont contenus dans la colonne proj4text et non dans srtext.

Intérressant à savoir donc, si vous voulez rajouter un système de projection
ou modifier un paramètre d'une projection existante de la table spatial_ref_sys
(il arrive encore que certains codes (vraiment) peu usités soient mal configurés
pour leurs valeurs de proj4text)

Ce qui ne veut pas dire pour autant que l'on peut se passer de srtext,
vu que d'autres composants y font aussi appel (pgsql2shp,
autres outils SIG interopérable…)

La colonne proj4text, elle, ne fait pas partie du standard OGC SFS,
C'est donc plus un workaround de PostGIS qui reflète le fait que Proj4 ne sait pas,
à ce jour, parser du WKT.

Il avait été question d'écrire un parser au niveau PostGIS,
mais c'est en priorité basse (litote), dans la pile des actions à venir.

On pourrait imaginer un Google Summer of Code, sur ce sujet,
et à ce titre l'écrire directement pour Proj4.

Si vous vous sentez une envie particulière d'écrire un parser
(style flex/bison ou re2c/lemon) n'hésitez pas à vous manifester.

Dernière modification par Olivier Courtin (27/10/2012 21:15:32)

catherine mazzoni · 28/10/2012 03:15:51

Merci Vincent pour ce post vraiment pédagogique.

Juste un détail pour compléter.
Vous dites :

vincentp a écrit :

- C'est un système de projection nommé "NTF (Paris) / Lambert zone II"
...
- Elle est basée sur une ellipsoide de référence qui est la "NTF (Paris)". C'est l'objet modélisant la terre sur lequel on effectue la projection conique.

Pour être plus précis, on ne peut pas dire que la NTF est un ellipsoïde. C'est un système de référence géodésique (un "datum" pour les anglophones), qui est lui-même défini par
- un ellipsoïde. En l'occurrence Clarke 1880 (IGN) dans le cas de la NTF
- et la position de son centre. La position du centre de l'ellipsoïde est calculée par rapport au centre de la terre que l'on assimile, par convention, au centre du système géodésique WGS84.

Il est vrai que ces précisions relèvent d'avantage de la géodésie que des bases de données spatiales. Mais tant qu'on y était de creuser la question des systèmes de coordonnées, autant la creuser jusqu'au plus profond. Le centre de la terre par exemple !

Merci encore à vous d'avoir apporté les éléments qui me manquaient dans le mécanisme de l'utilisation du SRID et que justement je cherchais en ce moment.

SQLpro · 28/10/2012 12:31:07

Voici la définition données par Morten Nielsen du SRID :

Spatial references, coordinate systems, projections, datums, ellipsoids – confusing?
"
Spatial reference

The spatial reference is a combination of all the above. It defines an ellipsoid, a datum using that ellipsoid, and either a geocentric, geographic or projection coordinate system.
"

Reprise par Boston GIS :

SRID, SRS ID: Spatial Reference System Identifiers
qui qualifie d'ailleurs cette définition d'excellente (je cite) mais commet la même erreur que beaucoup...

Vous noterez le mot EITHER qui en anglais veut dire L'UN OU L'AUTRE, c'est à dire que la définition d'un SRID peut encapsuler une projection OU un système de coordonnées géocentrique ou géographique...

Il n'y a donc pas de projection systématiquement encaspulée dans un SRID, mais les données d'un SRID permettent de définir les projections...

Pour avoir discuté avec Morten Nielsen de vive voix lors des MVP Summit aux USA, la confusion entre le SRID est le système de projection est vieille et hélas très répandue, notamment dans la documentions de PostGIS et même sur Wikipedia, dont on sait, hélas, que de nombreuses notices sont sujettes à caution...

Bref, je sais à peu près de quoi je parle et j'enseigne aussi cette matière notamment à travers des cours pro sur ce sujet, comme celui-ci que j'ai monté à Orsys : Gestion de données spatiales sous PostGreSQL et SQL Server 2008

Alors sans doute, vous direz que Morten Nielsen est vendu à Microsoft.... et que ce n'est donc pas une source fiable !!!

Voici quelques autres sources indépendantes de PostGIS ou SQL Server et autres :

Popular websites with the topic: epsg
"
SRID
A Spatial Reference System Identifier is a unique value used to unambiguously identify projected, unprojected, and local spatial coordinate system definitions.
"
Vous noterez le terme unprojected !

Voir aussi le problème dans le livre "la mise en œuvre d'un SIG dans les collectivité territoriales", aux pages 58 à 60 ou le problème est posé au sujet du RGF93 et de la projection Lambert.

Si vous avez envie, d'une référence encore plus pointue, ouvrez l'ouvrage "Encyclopedia of GIS" édité par Springer Verlag (1370 pages, ed 2008) à la page 364 et suivante qui décrit le GML dont les réferentiels spatiaux sont originaires !...

Comme vous avez fournit une référence de choix, celles collectant les référentiel terrestre, jetez un coup d'oeil au SRID 4326 :
Spatial Reference Projection: 4326

GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.01745329251994328,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]

Vous n'y verrez nulle projection, mais bien l’ellipsoïde de référence !
C'est même la plus utilisée en général, par exemple pour les routes maritimes ou aérienne.

Vous avez aussi fournit une autre référence : LES PROJECTIONS ET RÉFÉRENTIELS CARTOGRAPHIQUES

À la page 5 figure un dessin montrant bien comment une référence spatiale associée à une ellipsoïde de référence (ce qu'est un SRID) permet, par le choix d'une projection, d'effectuer une représentation des données de manière cartographique. Les pages suivantes montrant bien la décomposition....

Malheureusement la confusion SRID/projection est extrêmement commune et visiblement l'essentiel de ceux qui postent dans ce forum la font... C'est dommage !

A +

Dernière modification par SQLpro (28/10/2012 12:58:29)

SQLpro · 28/10/2012 12:43:13

vincentp a écrit :

... Au passage, merci pour ce thread, je comprends mieux pourquoi l'article de comparaison sql server spatial versus PostGIS est rempli d'inepties.

Au passage ceci constitue à l'évidence une diffamation.

Si vous dite que ce que j'ai écrit dans cet article :
SQL et système d’information géographique (SIG)
est faux, prouvez-le, sinon, je vous prie de corriger votre message pour enlever ces termes diffamatoire !

C'est toujours sympathique de voir des gens dénigrer les autres, sans pour autant faire quoi que ce soit comme travail sur le sujet...

Salutations

Olivier Courtin · 28/10/2012 13:15:15

SQLpro a écrit :

Vous noterez le mot EITHER qui en anglais veut dire L'UN OU L'AUTRE, c'est à dire que la définition d'un SRID peut encapsuler une projection OU un système de coordonnées géocentrique ou géographique...
Il n'y a donc pas de projection systématiquement encaspulée dans un SRID, mais les données d'un SRID permettent de définir les projections...

Certes, et jusque là ce n'est contesté par personne, mais après ?

Il a toujours était fait mention de système de projection, dans le cadre de ce thread,
qui est une traduction française acceptable pour Spatial Reference.

SQLpro a écrit :

Pour avoir discuté avec Morten Nielsen de vive voix lors des MVP Summit aux USA,

Vous m'en direz tant,
l'autorité en matière de système de projections dans l'univers carto SIG est et reste
le tandem OGC/ISO, soit ISO 19107 en l'espèce:
http://portal.opengeospatial.org/files/ … t_id=39049

SQLpro a écrit :

Bref, je sais à peu près de quoi je parle et j'enseigne aussi cette matière notamment à travers des cours pro sur ce sujet,

Argument d'autorité (aka #30)
On a tous souvenir dans nos cursus respectif d'enseignants brillants,
et d'autres l'étant nettement moins...

Olivier Courtin · 28/10/2012 14:44:43

SQLpro a écrit :

Si vous dite que ce que j'ai écrit dans cet article :
SQL et système d’information géographique (SIG)
est faux, prouvez-le, sinon, je vous prie de corriger votre message pour enlever ces termes diffamatoire !

Tiens je ne connaissais pas cet article, merci de me le faire découvrir,
et autant la première partie est une compilation propre et relativement claire
des notions déja connues sur la thématique de OGC SFS 1.1.

Autant la partie conclusion est quant à elle pour le moins hétérodoxe,
(je la reprend ci après en vous citant, vu que c'est votre article):

SQLpro a écrit :

Il semble bien que les méthodes disponible dans l’un et l’autre système soient quasiment identiques.

Certes sur la partie OGC SFS 1.1 (soit environ 80 fonctions), sauf que PostGIS en implémente
au moins 150 de plus...

La seule implémentation de OGC SFS 1.1 corrrespond à la version 1.0 de PostGIS sortie en ... 2005

SQLpro a écrit :

La différence la plus criante entre MS SQL Server et PostGIS (PostGreSQL) porte sur l’utilisation des différents référentiels spatial. PostGreSQL n’est capable d’utiliser que le référentiel mondial (SRID 4326 : WGS 84) tandis que SQL Server en gère 390 dont le français (4171 – RGF 93) et ceux des différents territoires d’outremer (Voir ci après). Cela limite considérablement l’utilisation de PostGIS sur le plan national, car les Lois nationales imposent la plupart du temps et pour chaque état d’utiliser un SRID local. (voir annexe 1) Par exemple, en France métropolitaine, les mairies, le cadastre et les collectivités territoriale comme les ministères, doivent utiliser le SRID 4171. Il s’agit d’une obligation légale…

Rien ne vous empèche avec PostGIS de stocker en 4171 si bon vous sied.
Sachant que la seule différence entre EPSG:4326 et EPSG:4171 est le changement de l'ellipsoide WGS84 vers GRS80,
qui est non mesurable pour une utilisation classique en SIG.
(la transformation de l'un vers l'autre via proj4 renvoit d'ailleurs les même coordonnées)

Pour s'en convaincre:

SELECT   ST_AsText('SRID=4326;POINT(10.123456789 10.123456789)'::geometry) AS orig_4326,
              ST_AsText(ST_Transform('SRID=4326;POINT(10.123456789 10.123456789)'::geometry, 4171)) AS dest_4171;

Le fait de stocker dans une géométrie autorise à utiliser *toutes* les fonctions associées,
et pour celles sensibles au caractère non euclidien du référentiel, il suffit de rebasculer en geography.

On peut dans un cas classique reprojeter, mais vu qu'ici le paramétre de transformation (towgs84
est à 0,0,0) on peut directement surcharger à la volée le SRID dans une requête soit par exemple:

SELECT ST_Distance(ST_SetSRID('SRID=4171;POINT(1 2)'::geometry, 4326)::geography, 
                               ST_SetSRID('SRID=4171;POINT(2 3)'::geometry, 4326)::geography);

SQLpro a écrit :

De plus cette limitation rend inopérant certains méthodes comme Dimension, GeometryType et bien entendu Srid dans le type GEOGRAPHY. Il faut alors passer par un type GEOMETRY, c’est à dire sans la courbure terrestre.

humm il suffit de caster à la volée, c'est effectivement un tantinet plus pénible à l'écriture,
mais en rien inopérant ou limitant.

Ex:

SELECT ST_Dimension(('SRID=4326;LINESTRING(1 1,2 2)'::geography)::geometry);

SQLpro a écrit :

La fonction MakeValid() (voir annexe 2) de MS SQL Server (conforme à l’OGC) permet de recalculer un objet géométrique afin de le rendre opérable en tant que tel. Elle n’existe pas sous PostGreSQL et son absence est susceptible de provoquer dans les calculs des erreurs liées notamment aux opérateurs géométriques.

MakeValid n'est pas une fonction OGC SFS (ni en 1.1, ni en 1.2)

ST_MakeValid a été introduit dans PostGIS à partir de la 2.0
(cette version n'était pas encore sortie en stable à la date de la rédaction de votre article,
néanmoins elle était déjà présente dans la version de développement et documentée)

L'objectif de MakeValid est de rendre un objet géométrique conforme à sa représentation OGC SFS.
Concrétement cela concerne uniquement les polygones,
pas d'auto intersection, ni de trous chevauchant l'enveloppe externe du polygone...

Avant PostGIS 2.0 le workaround était de faire un buffer de 0.0 pour obliger GEOS a renvoyer une
géométrie valide à partir de ses données imparfaites.
(une bonne pratique est précisons le au passage, d'avoir des données valides en base)

Bref cet article s'il est une jolie compilation de l'existant, est résolument partial dans ses conclusions.

SQLpro a écrit :

C'est toujours sympathique de voir des gens dénigrer les autres, sans pour autant faire quoi que ce soit comme travail sur le sujet...

Si vous saviez comme je suis bien de votre avis ^^

Dernière modification par Olivier Courtin (28/10/2012 14:46:30)

daamien · 29/10/2012 14:52:43

#1 24/10/2012 19:18:30