Comment accélérer le partitionnement de l'espace dans les postgis?

J'ai un tas de polygones qui se chevauchent et j'essaie de partitionner l'espace pour éviter d'avoir des polygones qui se chevauchent. Je pense que mon problème est assez simple. En utilisant un produit ESRI et http://arcscripts.esri.com/details.asp?dbid=16700, mon collègue l'a calculé en 48 secondes.

J'essaie de le faire avec postgis en utilisant http://s3.opengeo.org/postgis-power.pdf#page=24 (deviner les détails, en utilisant http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology comme inspiration) mais c'est tellement lent que je ne peux pas le faire avec plus de 10 polys (j'en ai 800 à séparer). La partie lente est la ST_Union, j'ai essayé différentes choses, mais aucune n'a réussi, voici l'état actuel des choses:

select geom from
(select st_linemerge(st_union(geom)) as geom from
    (select st_exteriorring((st_dumprings((st_dump(t.geom)).geom)).geom) as geom from
        (SELECT geometry AS geom, id
               FROM tt
              WHERE campaign_id = 204
              ORDER BY id limit 200) t) t2) t3

cela fait des calculs depuis 26 min (le linemerge () ne l'est en fait pas). Les polys sont des MultiPolygons au cas où le st_dump vous dérangerait.

Avez-vous une astuce? Le st_union () du dessin au trait est la partie très lente.

Merci,

Nico.

PS: voici quelques chiffres: 852 multipolygones, menant à 14880 polygones, menant à 21467 lignes de lignes totalisant 315513 sommets.

postgis topology optimization

— nraynaud
source

Si personne ne répond, vous pouvez essayer la liste de diffusion postGIS.

— GIS-Jonathan

Je ne suis pas vraiment fan des listes de diffusion, de plus, cela pourrait aussi être un problème GEOS, qui pourrait se plaindre de JTS, eh bien, je préfère garder le problème ouvert.

— nraynaud

en collectant le dessin au trait et en faisant une union avec une géométrie vide, je peux le faire en 800s: st_union (st_collect (geom), st_setsrid (geomfromtext ('POINT EMPTY'), 900913)) qui est presque 20 fois plus lent que le truc ESRI.

— nraynaud

de mémoire, essayez de supprimer st_union de st_linemerge (st_union ...) si cela vous aide

— simplexio

Réponses:

Cette réponse n'aidera peut-être pas @nraynaud directement, mais nous espérons qu'elle éclaircira le sujet.

Il y a un problème similaire dans spatiaLite <4.0 en raison d'un problème avec GEOS. Voir ce lien pour une discussion de la question.

La solution de contournement consiste à remplacer la fonction ST_Union () par ST_UnaryUnion (ST_Collect ()). Malheureusement, ST_UnaryUnion n'est pas disponible avant le postGIS 2.0 (pour autant que je sache.)

— Scro
source

Quelle version de PostGIS utilisez-vous? L'union est beaucoup plus lente si vous utilisez PostGIS <1.4 ou GEOS <3.2. L'union beaucoup plus rapide a été introduite en 1.4, mais nécessite également GEOS 3.2+. Donc, d'abord, si vous utilisez une version inférieure à 1,4, je passerais à au moins 1,5.

SELECT postgis_full_version();

Vérifier.

Votre intention est également de conserver les bords d'origine des polygones. Si vous souhaitez simplement dissoudre les zones qui se chevauchent,

SELECT ST_Union(geom) FROM tt WHERE campaign_id = 204;

Ferait l'affaire.

— LR1234567
source

bonjour, voici le résultat: "POSTGIS =" 1.5.3 "GEOS =" 3.3.2-CAPI-1.7.2 "PROJ =" Rel. 4.8.0, 6 mars 2012 "LIBXML =" 2.7.3 "USE_STATS". Je n'ai trouvé aucun ajout à l'union pertinent dans GEOS récemment. J'ai trouvé une accélération dans les unions de polygones, mais je ne fusionne pas de polygones, et cette accélération semble controversée. Je ne veux absolument pas faire l'union de mes polygones car je dois ajouter des valeurs pour les polygones qui se chevauchent.

— nraynaud