Le portail francophone de la géomatique

Bonjour,

En regardant de plus près l'exemple donné dans la doc, on lit que ST_Contains(geomA, ST_Boundary(geomA)) renvoie false, j'aurais donc tendance à penser que la frontière est considérée comme non contenue dans la géométrie.

Ca a l'air d'être une subtile différence avec ST_Covers et ST_Within... Peut-être auras-tu plus de succès avec l'une de ces dernières...

Je confirme ce que dit Vianney :
ST_CONTAINS c'est entièrement contenu (y compris pas de bordure commune donc de sommets communs) alors que ST_COVERS autorise la bordure.

Pour  la différence "st_contains(geomA,geomB) et le couple geomA && geomB and _st_contains(geomA,geomB)", les 2 cas doivent être autant rapide (différence infime).

Toutes les fonctions st_ font le préfiltrage d'index alors que les anciennes fonctions (sans st_) ne le faisaient pas et que les _st_ ne le font pas non plus.

Dernière modification par Cornet Jérémie (Thu 20 February 2014 15:36)

Non: la définition est:
Geometry A contains Geometry B if and only if no points of B lie in the exterior of A, and at least one point of the interior of B lies in the interior of A.

Bonjour,

Oui, ma phrase sur la frontiere n'est pas claire et prete a confusion: qd je parle de frontière d'un polygone, il s'agit de la linestring qui compose la frontiere.
Je vais essayer d'etre un peu plus clair, avec des exemples simples (a noter que les définitions topologiques des fonctions définies par l'OGC sont parfois contre intuitives, mais décrivent toujours toutes les combinaisons entre intérieurs, exterieur et frontieres des objets:

Soit un polygone simple: POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))

Il se contient lui-meme ?

nicolas=# select st_contains (
nicolas(#     'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry,
nicolas(#     'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry
nicolas(# );
 st_contains 
-------------
 t
(1 ligne)

Contient-il sa frontiere ?

nicolas=# select st_contains (
nicolas(#     'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry,
nicolas(#     st_boundary('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry)
nicolas(# );
 st_contains 
-------------
 f
(1 ligne)

C'est en ce sens que ce n'est pas intuitif: un polygone peut contenir un autre polygone, mais ne contient pas une "partie" de ce polygone qui est sa frontiere.

St_contains renvoie également vrai si un ou plusieurs sommets du polygone contenu sont sur la frontière du polygone contenant:

select st_contains (
    'POLYGON((0 0, 3 0, 3 3, 0 3, 0 0))'::geometry,
    'POLYGON((2 0, 2.5 2, 1.5 2, 2 0))'::geometry
);
 st_contains 
-------------
 t
(1 ligne)

Dans cet exemple, les deux polygones partagent des points sur leur frontiere et st_contains renvoie vrai.

st_covers, opérateur non défini par l'OGC, a ete introduit pour permettre de répondre vrai aux deux cas précédents: Il y a souvent des process géomatiques dans lesquels les objets sont décomposés en leurs frontière et intérieur, et st_contains pose donc des pb dans ces cas.

select st_covers (
    'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry,
    'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry
);
 st_covers 
-----------
 t
(1 ligne)

select st_covers (
    'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry,
    st_boundary('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'::geometry)
);
 st_covers 
-----------
 t
(1 ligne)

Dans votre cas de numérisation, le problème vient, a mon sens, de problèmes de précision: le point numérisé "sur la frontière" de l'autre polygone n'est pas sur la frontière, a la précision prés: contains renvoie faux.
Ces problèmes de précisions peuvent etre particulièrement piégeux (cf forum postgis users): il y a des cas ou st_distance(point, ligne) renvoie 0: le point est donc sur la ligne, mais st_contains ou st_within utilisé avec les memes géométries renverra faux. Postgis n'est pas robuste dans tous les cas, d'ou souvent le conseil de travailler en coordonnées entières ou d'utiliser st_snapToGrid pour eviter ces pb d'arrondis.

Si je reprends votre phrase:

Non ! D'abord parce qu'il n'y a pas, dans Postgis, la notion de "ces sommets ne sont pas des sommets de la géométrie contenante": Pour postgis, il n'y a que des points communs entre géométries, que ce soit les memes points (des sommets), ou un sommet et un point sur un segment.
Le probleme vient du fait que quand postgis calcule la coordonnée commune entre deux objets, il peut y avoir des erreurs d'arrondis qui font que le résultat de la fonction est faux.

Pas plus que st_contains: pour des polygones, st_contains et st_covers renverront tjs le meme résultat... aux erreurs d'arrondi près: les algorithmes étant différents, une des deux fonctions peut "planter" alors que l'autre marchera, pour les meme geometries.

Pour résumer, dans votre cas de numérisation:
Vous travaillez avec des polygones et vous voulez controler que le nouveau polygone est bien contenu dans le polygone d'origine: st_contains et st_covers renverront vrai.
Vous trouvez des résultats curieux avec l'une ou l'autre des fonctions: il faut controler la précision des données.
Et enfin, les algorithmes étant différents entre les deux fonctions, une est peut etre plus "robuste" que l'autre et sera moins sensible aux erreurs d'arrondis, mais il ne faut pas compter sur ce comportement dans votre application.

Nicolas

Bonjour,

Avec OpenJump, j'ai observé le meme probleme que vous: un polygone de départ (pg1), je numérise un polygone a l'intérieur (pg2), avec des sommets qui se trouvent sur le bord de pg1 grâce à l'option de snapping des points:

st_contains(pg1, pg2) renvoie faux.

Avec st_contains(pg1, st_snapToGrid(pg2, 0.00000001)) j'obtiens vrai.

Un petit arrondi sur les coordonnées pour éviter le problème de précision des calculs.

PS: no life...