Come velocizzare il partizionamento dello spazio in PostGis?


9

Ho un sacco di poligoni sovrapposti e sto cercando di dividere lo spazio per evitare di avere quelli sovrapposti. Penso che il mio problema sia abbastanza semplice. Usando alcuni prodotti ESRI e http://arcscripts.esri.com/details.asp?dbid=16700 il mio collega lo ha calcolato in 48 secondi.

Sto cercando di farlo con Postgis usando http://s3.opengeo.org/postgis-power.pdf#page=24 (indovinando i dettagli, usando http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology come ispirazione) ma è così lento che non riesco a farlo con più di 10 polis (ne ho 800 da dividere). La parte lenta è ST_Union, ho provato varie cose, ma nessuna dove ha avuto successo, ecco lo stato attuale delle cose:

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

questo è stato calcolato per 26 minuti (il linemerge () in realtà non lo è). I poligoni sono MultiPoligoni nel caso in cui lo st_dump ti infastidisca.

Hai qualche consiglio? La st_union () del linework è la parte molto lenta.

Grazie,

Nico.

PS: ecco alcuni numeri: 852 multipoligoni, che portano a 14880 poligoni, che portano a 21467 linestring per un totale di 315513 vertici.


Se nessuno risponde, potresti provare la mailing list postGIS.
GIS-Jonathan,

Non sono davvero un fan delle mailing list, inoltre, potrebbe anche essere un problema GEOS, che potrebbe lamentarsi di JTS, beh, preferisco tenere aperto il problema.
nraynaud,

raccogliendo il disegno al tratto e facendo un'unione con una geometria vuota, posso farlo negli anni '800: st_union (st_collect (geom), st_setsrid (geomfromtext (' POINT EMPTY '), 900913)) che è quasi 20 volte più lento della roba ESRI.
nraynaud,

1
dalla memoria, prova a eliminare st_union da st_linemerge (st_union ...) se aiuta
simplexio,

Risposte:


3

Questa risposta potrebbe non aiutare direttamente @nraynaud, ma si spera che farà luce sull'argomento.

C'è un problema simile in spatiaLite <4.0 a causa di un problema con GEOS. Vedi questo link per una discussione del problema.

Per risolvere il problema, sostituire la funzione ST_Union () con ST_UnaryUnion (ST_Collect ()). Sfortunatamente, ST_UnaryUnion non è disponibile fino a postGIS 2.0 (per quanto ne so.)


1

Quale versione di PostGIS stai usando? L'unione è molto più lenta se si utilizza PostGIS <1.4 o GEOS <3.2. L'unione molto più veloce è stata introdotta in 1.4, ma richiede anche GEOS 3.2+. Quindi prima se stai usando un valore inferiore a 1.4, aggiornerei ad almeno 1.5.

SELECT postgis_full_version();

Controllare.

Inoltre è tua intenzione mantenere i bordi originali dei poligoni. Se vuoi solo dissolvere le aree sovrapposte,

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

Farebbe il trucco.


ciao, ecco il risultato: "POSTGIS =" 1.5.3 "GEOS =" 3.3.2-CAPI-1.7.2 "PROJ =" Rel. 4.8.0, 6 marzo 2012 "LIBXML =" 2.7.3 "USE_STATS". Recentemente non ho trovato alcuna aggiunta rilevante al sindacato in GEOS. Ho trovato uno speedup nei sindacati poligonali, ma non sto unendo poligoni e questo speedup sembra controverso. Non voglio assolutamente unire i miei poligoni poiché devo aggiungere valori per i poligoni sovrapposti.
nraynaud,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.