#1 Mon 05 November 2012 14:01
- bruns81
- Participant occasionnel
- Date d'inscription: 11 Apr 2009
- Messages: 14
[POSTGIS] requĂȘte d'intersection trop lente
Bonjour,
Je dois dĂ©couper une couche complexe dâobjets multipolygones par une couche des communes de mon dĂ©partement (le but Ă©tant de rĂ©cupĂ©rer la surface communal de chaque objet)
Jâai testĂ© cette requĂȘte pour dĂ©couper mes objets initiaux :
Code:
CREATE TABLE obj_com AS
(
SELECT commune.insee as insee, obj.periode as periode, st_intersection(obj.the_geom,commune.the_geom) as the_geom
FROM obj,commune
ORDER BY commune.insee, obj.periode
)Comme toutes les communes sont intersectĂ©es par les objets je nâai pas ajoutĂ© WHERE st_intersects.
Mes deux tables ont été indexées .
RĂ©sultat : cela fonctionne mais câest trĂšs long (plusieurs heures). Jâai testĂ© le mĂȘme traitement en sĂ©lectionnant quâun objet (jâen ai une dizaine au total). Certains mettent 2 min pour ĂȘtre dĂ©coupĂ©s et dâautres + dâune heure. Le temps de traitements me semble pas linĂ©aire mais plutĂŽt exponentiel en fonction de la complexitĂ© de lâobjetâŠ(Le nombre de gĂ©omĂ©tries des multipolygones varie de 3000 Ă 16000).
Du coup, je me demande si ma requĂȘte peut ĂȘtre amĂ©liorĂ©e (jâai testĂ© dâajouter lâopĂ©rateur && mais cela ne change rien) et sâil ne faut pas que je change de mĂ©thodeâŠ
Faut il que je décompose mes objets multipolygones (avec un st_dump) ?
Faut il que je rĂ©alise lâintersection uniquement que sur les polygones qui intersectent les contours communaux et que je rĂ©cupĂšre les autres avec un st_contains⊠?
Si certains peuvent me donner des pistes âŠ.
Je dĂ©couvre depuis peu postgis et jâavoue ĂȘtre trĂšs frustrĂ© car je suis persuadĂ© que Postgis peut rĂ©pondre beaucoup plus vite Ă cette requĂȘte âŠ
Hors ligne
#2 Mon 05 November 2012 14:48
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: [POSTGIS] requĂȘte d'intersection trop lente
Bonjour,
Si c'est long, c'est qu'il y a beaucoup de choses à faire: vous travaillez avec toutes les communes du département ?
Vous devriez rajouter une clause "where st_intersects", pour utiliser les index.
Vous pouvez aussi simplifier les données (par ex, pas de décimales pour des coordonnées métriques en France) avec st_snapToGrid et st_simplify.
Le CPU est-il utilisé a 100% pendant l'intersection ?
Nicolas
Hors ligne
#3 Mon 05 November 2012 15:57
- bruns81
- Participant occasionnel
- Date d'inscription: 11 Apr 2009
- Messages: 14
Re: [POSTGIS] requĂȘte d'intersection trop lente
Je travail sur toutes les communes du département.
J'ai ajoutĂ© where st_intersects dans mon dernier test mais je viens de craquer : j'ai arrĂȘtĂ© la requĂȘte car toujours rien au bout de 3 h (ce qui est rĂ©dhibitoire pour moi) et suis retournĂ© Ă mon logiciel SIG...
J'ai testĂ© st_simplify mais je ne souhaite pas dĂ©grader la prĂ©cision de mes objets (j'ai beaucoup de ronds et le gain en nombre de nĆuds semble minime). Par contre il me faut tester st_snapToGrid ...
Pendant que cela tourne, j'ai découvert la modification du shared_buffers. Par défaut, j'ai 32MB et je compte le passer à 128 Mb (j'ai 3.5Go de RAM).
Faut il que je modifie d'autres paramĂštres ?
Je vais relancer la requĂȘte cette nuit aprĂšs cette modif.
Hors ligne
#4 Mon 05 November 2012 16:30
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: [POSTGIS] requĂȘte d'intersection trop lente
Les PG qui intersectent les communes sont-ils grands par rapport aux communes ? Si oui, ca peut etre interessant de les découper en petits objets avant de lancer l'intersection.
Sinon oui, il faut tuner PG !!
Il y a de bons tutos sur le web pour cela, recommandant par ex 70 a 80% de la ram pour les shared_buffer (32, ou meme 128 mo, c'est tout petit)
Il faut aussi augmenter les autres parametres, notamment work_mem puisque vous faites des order by et des classements.
Ne pas hesiter a faire un conf costaude rien que le process spatial, quitte a en changer ensuite lorsque le traitement est fini.
Nicolas
Hors ligne
#5 Tue 06 November 2012 08:45
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3235
- Site web
Re: [POSTGIS] requĂȘte d'intersection trop lente
Bonjour,
Je tenterai d'analyser l'intersection des bouding box avec un && et de stocker le résultat dans une table temporaire, pour ensuite passer à l'intersection réelle sur cette table.
Christophe
L'avantage d'ĂȘtre une Ăźle c'est d'ĂȘtre une terre topologiquement close
Hors ligne
#6 Tue 06 November 2012 10:18
- Ted
- Participant assidu
- Date d'inscription: 16 Jan 2007
- Messages: 181
Re: [POSTGIS] requĂȘte d'intersection trop lente
Bonjour,
Est-il possible d'avoir un jeu de données pour le test?
a+
Hors ligne
#7 Tue 06 November 2012 10:58
- bruns81
- Participant occasionnel
- Date d'inscription: 11 Apr 2009
- Messages: 14
Re: [POSTGIS] requĂȘte d'intersection trop lente
Pour répondre à Nicolas, les objets à découper sont trÚs grands car ils couvrent l'ensemble du département.
Je suis actuellement en train de tenter de comprendre comment configurer PostgreSQl. Pour l'instant, j'ai juste modifié le shared_buffer et j'ai divisé par 4 le temps de traitement d'une autre procédure donc ça me parait trÚs prometteur...
Il me faut revoir ma requĂȘte pour travailler sur les objets dĂ©groupĂ©s (ce qui permettra sans doute de mieux exploiter les index gĂ©o).
Pour le jeu de données, c'est vraiment volumineux donc je ne peux les ajouter à mon message.
Hors ligne
#8 Tue 06 November 2012 12:05
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1566
Re: [POSTGIS] requĂȘte d'intersection trop lente
La taille des objets doit expliquer en partie la mauvaise perf:
l'index spatial n'est alors pas approprié pour trier les bons candidats.
Une solution consiste a creer une grille rectangulaire définissant la taille "acceptable" d'un PG, puis de découper les polygones par rapport a cette grille (en gardant un lien entre les n morceaux découpés et le pg original).
Nicolas
Hors ligne

