Le portail francophone de la géomatique

Bonsoir Nicolas,

j'ai lu tes pistes, merci beaucoup.
Je dois y aller, mais demain, j'essaie le VACUUM et l'analyse avec EXPLAIN pour alimenter ma prochaine réponse.


Bonne soirée, à demain.

Bonjour Nicolas,

Merci déjà en tous cas, pour toutes ces pistes.

Dernière modification par sigdu80 (Thu 24 January 2013 11:47)

23 secondes pour une jointure de 16K éléments c'est énorme.
Quel genre de géométries on trouve dans la table infos ?
Si ce sont des grosses géométries,  avec beaucoup de points, et une étendue large, ou bien des géométries dégénérées (type croissant de lune), alors l'explication se trouve là. Les indexes géométriques dans ce cas sont peu efficaces voire pénalisants, et le calcul d'intersection très long car trop détaillé.
C'est un des cas limite d'utilisation de PostGIS (et du principe d'indexation RTree de façon général).

Solution : découper les géométries infos en sous-éléments plus simples et plus petits, les simplifier (st_simplify) avant le calcul d'intersection.

Le dessin n'est pas très explicite, on ne voit pas bien ce que sont les polygones.

Si ce sont des lits de cours d'eau entiers, c'est effectivement très probable que ce soient des géométries «dégénérées».

Il faut a moins les simplifier, mais surtout les prédécouper avant en des entités plus simples.

Les parcelles n'ont pas non plus l'air d'etre des parcelles cadastrales, donc si elles sont complexes également ça peut empirer les traitements.

v.

Oui Nicolas, j'aime les belles choses donc je fais dans les beaux polygones

J'ai refait un impr écran (j'explique un peu plus juste en dessous) :

[img]http://img838.imageshack.us/img838/1781/tmpcarto2.jpg[/img]

Alors le gros bloc qui était tout violet est la table "infos".
Elle a 3 classes de valeurs différentes. J'ai mis des couleurs différentes (opacité >50%, couleur violette, rose, rose très pâle limite blanc), attention la bande horizontale du haut très rose flashy doit être plus dû à un bug d'affichage de QGIS je pense.
Ma parcelle de test est en bas à droite en vert. Elle est énorme et donc complètement délirante par rapport à la réalité (j'ai dessiné une forme de maison de travers ). Par contre, tu trouves que sa forme est complexe ?
On voit différentes couleurs pour montrer l'intersection de la parcelle avec différentes classes de valeurs de la table infos.

Ce sont des polygones dégénérés tu disais donc.
Dans l'ordre, il faudrait :
- 1) prédécouper les entités générées de la table infos
- 2) utiliser st_simplify dans la requête

1) le shapefile a été transféré par QGIS dans la base postgresql.
Ensuite, j'ai réinjecté dans une table de référence.
Il faudrait que j'efface le contenu de cette table (TRUNCATE) et que je fasse une opération (mais laquelle ? comment pré-découper ?).

2) utiliser le st_simplify au moment du WHERE st_intersects ? -> st_intersects(st_simplify(a.geom,2), st_simplify(a.geom,2)
OU/ET avec st_intersection ?

Dernière modification par sigdu80 (Thu 24 January 2013 15:34)

... et une fois les géométries réduites, le st_simplify ne devrait pas faire de grosse différence, ce n'est pas la priorité.

Bonjour,

Vincent indiquait qu'il faut bien vérifier que les objets ne soient pas en latitude longitude avant de faire des calculs, mais dans un systeme projeté, pour que les calculs mathématiques soient corrects (espace plan)

Nicolas

Bonjour,

je commence à lire/traduire/comprendre l'article que m'a conseillé Vincent.
La notion "espace plan" et autres, je dois regarder cela aussi.
J'ai fait aussi une requête pour détecter la classe de valeurs de la table infos, qui demande le plus de temps de calcul.

J'ai fait la requête suivante :

SELECT id,lower,upper,st_intersection(a.geom, b.geom) 
FROM parcelles a
INNER JOIN infos b ON (st_intersects(a.geom,b.geom) AND b.classe = X)
WHERE a.id IN (1,2);

Les temps de réponse :
- couleur violette :            0.157s
- couleur rose :              23.125s
- couleur rose très pâle :  0.094s

Il faudrait sûrement découper (comme vous me le conseilliez la semaine dernière) fortement cette classe de valeur précise, dans la table infos.
Je retourne à ma lecture "map dicing ...".

Dernière modification par sigdu80 (Tue 29 January 2013 10:07)

Bonjour à tous,

me revoilà sur ce sujet que j'avais dû laissé de côté, ayant d'autres choses à faire à côté.
Je reviens ici pour dire que j'ai réussi ce que je souhaitais : optimiser le temps de calcul d'intersection entre la table infos et parcelles.
Grâce au map dicing que vous m'avez conseillé !

En fait, j'avais mal défini ma bbox de la case d'une grille 10*10, donc forcément, çà ne fonctionnait pas correctement !
J'illustre, çà pourrait peut-être servir à quelque chose à quelqu'un qui sait.

Déjà, j'ai détecté que la complexité des polygones ne provenaient uniquement que d'un seul enregistrement !
Le voici :
[img]http://imageshack.us/a/img543/9943/polygonecomplexe.jpg[/img]

Après avoir revérifier les étapes du map dicing, j'ai vu que j'avais mal fait l'étape 3. J'ai bien fait attention avec la bbox d'une case d'une grille 10*10.
J'ai appliqué la bbox (Xorigine Yorigine,Xorigine+largeur Yorigine+hauteur).
Ce qui donne :
[img]http://imageshack.us/a/img267/4729/coucheetgrille10x10pres.jpg[/img]


On voit qu'il y a un décalage, pourtant j'applique la formule explicitée.
Pour corriger, j'essaie avec :
bbox(Xorigine-largeur Yorigine-hauteur,Xorigine Yorigine)

Ce qui donne :
[img]http://imageshack.us/a/img19/2940/coucheetgrille10x10corr.jpg[/img]

A partir de là, les étapes suivantes s'enchaînent correctement.
La réalisation de la découpe dure plus de 10minutes.
A la fin, on constate que l'on a bien optimisé les choses car je passe de 23.5s à 0.5s.
Le but est atteint !

Bonne fin de journée à tous.

Dernière modification par sigdu80 (Tue 19 February 2013 18:06)