Le portail francophone de la géomatique

Bonjour,

Effectivement comme le dit Yves, l'opérateur && et la fonction st_intersects ne font pas la même chose. Les docs de la version 1.5 sont ici :
- http://postgis.refractions.net/document … erlap.html
- http://postgis.refractions.net/document … sects.html

Selon la version de postgis, st_intersects ne fait pas de comparaison d'enveloppe il me semble. Il peut alors être utile dans le where de faire d'abord un "&&" puis un "st_intersects".

Et pour optimiser encore un peu, tu peux tester aussi en mettant

WHERE zone_humide='670057' 
AND zone_humide.the_geom && parcelle.the_geom 
AND Intersects(zone_humide.the_geom ,parcelle.the_geom)

Bonsoir,

dans mon souvenir,

st_intersects(geom1,geom2)

est la "nouvelle" syntaxe pour faire

geom1 && geom2 AND Intersects(geom1,geom2)

http://postgis.refractions.net/documentation/manual-1.5/ST_Intersects.html

mentionne "This function call will automatically include a bounding box comparison that will make use of any indexes that are available on the geometries."

Dernière modification par Mathieu BOSSAERT (Thu 01 September 2011 18:15)

Pour Mathieu :

Je peux me tromper mais :

Avant l'arrivé des fonctions st_* le fonctionnement était en effet d'utiliser cet  opérateur non pas pour utiliser les index mais parce que cet opérateur déclenchait l'utilisation des index. Bon la nuance est faible, je vous l'accorde et je ne suis pas très claire mais l'idée est que cet opérateur va réaliser un premier tri entre les géométries pour réaliser ensuite le test d'intersection qui va utiliser l'index.

Nebuka, si tu enlèves " zone_humide.the_geom && parcelle.the_geom AND " ta requête met combien de temps pour se réaliser ?

Y.

Bonjour,

Quelle est la différence de traitement entre une requête utilisant && pour comparer les boxs et stocker le résultat dans une table temporaire puis executer une requête intersect sur cette table temporaire et une requête comme indiquée par nebuka, qui combine les deux en une seule commande SQl ?

Ensuite juste pour info connaissez vous le type d'algo en œuvre dans intersects() ?

Bon alors après quelques dizaines de minutes de traitement j'ai ce message d'erreur :

NOTICE:  TopologyException: side location conflict at 924854 6.51993e+06


ERREUR:  GEOS intersects() threw an error!

********** Erreur **********

ERREUR: GEOS intersects() threw an error!
État SQL :XX000

Donc pour débugger je fais un

SELECT isValid(the_geom) from zone_humide

et j'obtien 3 warning :

NOTICE:  Ring Self-intersection at or near point 735616 7.04323e+06
NOTICE:  Ring Self-intersection at or near point 955606 6.75697e+06
NOTICE:  Ring Self-intersection at or near point 163887 6.77441e+06

J'ai corrigé les erreurs et je relance ... wait and see

Nebuka

Plusieurs questions :

- Que fais-tu comme correction pour enlever les self-intersection ? Buffer(the_geom,0), cleangeometry(the_geom) ? voir http://www.kappasys.ch/pgtools/cleangeo … ometry.sql

- Es-tu sûr que les objets sont bien indexés ? Create index....   puis vacuum analyse. voir  http://www.postgis.fr/node/187

- combien as-tu de parcelles ?  combien as-tu de zones humides ?  et quelle est en gros la surface moyenne d'une zone humide ? 

- As tu tenté de booster Postresql en de modifiant les paramètres par défaut de postgresql dans le fichier  : C:\Program Files (x86)\PostgreSQL\8.4\data\postgresql.conf voir http://wiki.postgresql.org/wiki/Tuning_ … SQL_Server

A bientôt

Pour mettre à jour une table entière de 50M d'enregistrement, notamment s'il y a des géométries, il vaut mieux faire une création de nouvelle table avec tous les champs et la géométrie modifiée, puis supprimer l'ancienne et renommer la nouvelle. Ensuite rajouter les contraintes et les indexes.

Les updates de table entière ça peut etre très long, et ça nécessite ensuite de faire du vacuum, alors que la création de table élimine pas mal de problèmes liés au MVCC.

D'autre part, si la machine est multi-processeur, il peut être intéressant de séparer la requête unique (qui va s'exécuter sur un seul processeur), en N requêtes en parallèle, car l'opération de buffer − st_buffer − est couteuse en calculs.

Mais le plus efficace reste de faire le st_buffer uniquement sur les géométries invalides, avec un update s'il n'y en a pas trop :
  update parcelles set the_geom = st_buffer(the_geom, 0) where not st_isvalid(the_geom)

Merci pour vos info ppluvinet et vincentp la réparation à été effectivement plus rapide ... la j'ai en cours le vacuum analyse et après je lance quelques requêtes de test.
Si tout est OK je lance la requete principale.

Dans postgis 1.5, "REINDEX TABLE" ne prennent pas en compte les index spatiaux (au lieu de faire un VACUUM ANALYSE) ?

Bon apparemment j'aurais toujours des erreurs dans mes données "parcelle".
Quand j'ai utilisé la requête de ppluvinet j'ai eu ça comme message :

NOTICE:  Self-intersection at or near point 642276 6.87328e+06
CONTEXT:  PL/pgSQL function "cleangeometry" line 15 at IF

pour moi je pensais qu'il avait corrigé les erreurs nan ? Ou est-ce que j'ai un soucis avec la fonction cleangeometry ?

Bonjour,

je viens après quelques jours d'absence vous donner les "résultats" des manipulations :
- tout d'abord j'ai réussis à corriger toutes les données géographique
- j'ai pu faire tourner ma "grosses" requête ... 2.5 jours de calcul et avoir tout les résultats.

Au sujet de l'optimisation de la base, j'avais déjà fait toutes les manipulations décrites, par contre j'ai une question au sujet du multi processeurs. A priori postgres peut travailler en mutli processeurs mais 1 requêtes par processeurs.
Est-ce qu'il n'y a pas moyen d'optimiser ça au niveau des fonctions spatiales ? Car en vérifiant les processus tournant sur mon serveur (top sous centos), j'ai vu que très rarement il y avait 2 processus psql ... mais jamais 3 ou 4 (4 étant le nombre de core du serveur).

Encore merci pour vos différentes interventions qui on pu faire avancer le schmilblik.