Vous n'êtes pas identifié(e).
Pages : 1
A chaud, je dirai:
- Faire l'intersection entre la ligne et le nuage de points
- Recreer une ligne à partir des points résultants de l 'intersection via ST_MakeLine
(si les points sont ordonnées/ordonnables c'est trivial, sinon les prendre 2 à 2 et un appel final à ST_LineMerge)
HTH,
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):
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
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);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);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.
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 ^^
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.
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
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...
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.
@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)
Pages : 1