Le portail francophone de la géomatique

Salut,

pour ce qui est de le changement des géométries après traitement :

pour le type :
les traitement sont susceptibles de produire des géométries de type différents
de ceux des arguments, mêmes quand tout les arguments partagent le même type.

Exemple :
Deux lignes dont la différence serait un point unique :
ici chaque caractère - représente un point
différence de:
______________________
|geometrie |        type       |
|_________|____________|
|-----         | (LINESTRING)|
|----          | (LINESTRING)|
|=             |                     |   
|     -         | (POINT)         |
|_________|____________|

Il se peut également que le traitement produise plusieurs types de géométrie en sortie,
pour cela Postgis englobe tout cela dans une GeometryCollection.


pour le SRID:
La colonne SRID de geometry_columns est un SRID de contrainte,
ou 0 signifie pas de contrainte.
Si vous créez une table à partir d'une requête, PostgreSQL ne peut pas savoir
à l'avance si les résultat de la requête auront toujours le même type de geometry
et le même SRID, donc il se borne à dire que la colonne est de type géométrie "libre".
Pour contraindre, vous pouvez créer la table en amont en spécifiant les contraintes,
ou spécifier le type voulu du résultat d'un traitement en le castant .

Exemple

CREATE TABLE satan_estate AS 
SELECT st_difference(poly1.geom, poly2.geom)::geometry(POLYGON, 666)
FROM poly1,poly2;

La requête ci-dessus produira une erreur si un  des résultat n'est pas du type POLYGON localisé en enfer.

Dernière modification par tumasgiu (Thu 15 November 2018 16:56)

Bonjour,

Pour continuer sur le sujet, et malgré un peu de pratique, j'ai aussi énormément de mal à comprendre comment gérer les types géométriques dans les fonctions spatiales. Bien que la documentation soit claire sur les types pris en entrée dans les fonctions, elle l'est beaucoup moins sur les fonction permettant de convertir les types. Notemment lors de l'écriture de requêtes uniques, sans tables intermédiaires (ou à la rigueur avec des CTE).
Autant pour les multigéométries, St_Multi, St_Linemerge ou autre permet le plus souvent de passer en multigeometrie, autant l'inverse est complexe : ST_Dump produit une double geométrie qui peut entrer en conflit avec les contraintes geometry_columns, et la formulation avec les :: est aléatoire dans ses résultats.

Par ailleurs je n'ai trouvé aucun tuto clair sur ce sujet (passage de geometries simples à multi) et les nouvelles requêtes demandent de longs tatonnements.

Est-ce que que quelqu'un aurait de la documentation à ce sujet? Comment utiliser correctement les fonctions et les assignations de type (: sans risquer de futurs conflits d'interprétation?

Bonjour,

Pour résumer sur les passages d'une multi-géométrie à une géométrie simple :

1. Vérifier le type geométrique des tables :

select st_geometrytype(geom) FROM table

2. Vérifier si les geometries ont plus d'une partie :

SELECT COUNT(CASE WHEN ST_NumGeometries(geom) > 1 THEN 1 END) AS multi_geom,
COUNT(geom) AS total_geom FROM table;

3.1. Si oui : Passage de multigeom à geom avec la fonction st_dump. Créer d'abord une cope de la table a modifier avec

CREATE TABLE table_simple AS SELECT * FROM table_multi

WITH dump_temp AS
(SELECT (ST_Dump(geom)).geom as geom, id FROM table_multi)
UPDATE table_simple SET geom = dump_temp.geom
FROM dump_temp WHERE table_simple.idcana = dump_temp.idcana

Les multigéometries seront bien sûr éclatées par la fonction dump. Noter la formulation pour le ST_DUMP pour ne séléctionner que la géométrie qui nous intéresse (cf. documentation).

3.2 Si non : Changer le type (la contrainte) d'une colonne de geometrie sur une table :

Ici passage de multilinestring à string simple : spécifier dans la fonction geometry le type et le SRID en premier et second argument puis avec ST_GeometryN spécifier le nom de la colonne portant les géometries et la dimension de celle-ci - cf. doc postgis) :

ALTER TABLE table
ALTER COLUMN geom TYPE geometry(linestring,2972) USING ST_GeometryN(geom, 1);