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.