Grazie per la risposta. Ho sbagliato a scrivere, sono poligoni: si tratta di una griglia (ho anche i punti, per quello ho fatto confusione). Comunque sono 3 ore e più che lo script è in esecuzione, ma nulla.. Mi toccherà fare il dissolve in QGIS.
Saluti, Ludovico Il giorno sab 22 set 2018 alle ore 20:37 aperi2007 <aperi2...@gmail.com> ha scritto: > Se l'archivio è grande è ESSENZIALE fare l'indice sul campo di > aggregazione altrimenti i tempi sono lentissimi. > > Come addendum: > > Te psrli di punti. Quindi desumo che l'archivioe' puntuale. > > Il problema e' che se l'aggregazione siu un valore è comosta di 1 solo > punto ti verrà una geometria puntuale. > Se e' composta di piu' punti ti verra' MULTIPOINT. > Quando andrai ad assegnare il tipo di geometria ti darebbe errore. > > Per cui la soluzione èe metterci una forzatura a MULTIPOINT. > QUindi: > > SELECT cod_90, > > ST_Multi(ST_Union (geom)) AS geometry > FROM iuti_join > GROUP BY cod_90 > > Se invece erano linee o poligoni, il discorso cambia un po'. > Ma se sono punti va bene cosi'. > > Saluti, > A. > > > Il 22/09/2018 17:59, ludovico frate ha scritto: > > Ciao Sandro, > > grazie per la risposta. Infatti, da quel poco che so di Spatialite, non > > trovavo il modo semplicemente perché non esiste! > > In effetti sto aggregando tutto il dataset utilizzando cod_90. > > Seguirò il tuo consiglio con la creazione di un indice non spaziale. > > > > Grazie, > > Ludovico > > > > Il giorno sab 22 set 2018 alle ore 17:52 <a.furi...@lqt.it> ha scritto: > > > >> On Sat, 22 Sep 2018 08:21:31 -0700 (MST), ludovico.frate wrote: > >>> Ciao a tutti, > >>> sto provando ad effettuare un dissolve su un dataset composto da > >>> oltre > >>> 1.200.000 punti. > >>> > >>> SELECT cod_90, > >>> ST_Union (geom) AS geometry > >>> FROM iuti_join > >>> GROUP BY cod_90 > >>> > >>> Solo che questo richiede parecchio tempo. Come è possibile > >>> implementare lo > >>> spatial index (che ho già creato) in questa query per velocizzare il > >>> processo? > >>> > >> Ludovico, > >> > >> lo Spatial Index non e' una polverina magica in grado di accelerare > >> miracolosamente qualsiasi elaborazione Spatial. > >> > >> e' semplicemente un meccanismo che consente di rendere molto piu' > >> veloce il filtraggio preventivo delle features da elaborare, visto > >> che lavorando sulla valutazione preventiva dei BBOX e' in grado di > >> scartare rapidamente gran parte delle geometrie "impossibili", > >> facendo cosi' risparmiare un sacco di tempo. > >> > >> ma nella tua query non e' presente nessuna clausola di filtro > >> basata su relazioni Spatial; anzi, per l'esattezza, manca del tutto > >> la clausola WHERE, il che significa che e' tua intenzione aggregare > >> _TUTTE_ le geometrie presenti nella tavola "iuti_join". > >> in queste condizioni (assenza di qualsiasi filto su base Spatial) > >> anche l'eventuale presenza di uno Spatial Index non puo' avere alcun > >> ruolo nell'accelerare la query. > >> > >> vedo invece che stai aggregando in base ai valori di una colonna > >> non-spatial (GROUP BY cod_90). > >> definire un indice "normale" su questa colonna potrebbe aiutare > >> a velocizzare l'esecuzione della tua query: > >> > >> CREATE INDEX idx_cod_90 ON iuti_join (cod_90); > >> > >> a parte questa eventuale piccola ottimizzazione, per il resto > >> il tempo di esecuzione di una query come questa dipende quasi > >> esclusivamente dal tempo che ci impiega la ST_Union(), e qua > >> non c'e' proprio nulla che tu possa fare per ottimizzare. > >> dipende tutto dal numero delle geometrie, dalla loro complessita', > >> dall'efficienza interna degli algoritmi della GEOS e dalla > >> velocita' della tua CPU; tutti fattori sui quali non puoi > >> esercitare alcun controllo. > >> > >> ciao Sandro > >> _______________________________________________ > >> Gfoss@lists.gfoss.it > >> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > >> Questa e' una lista di discussione pubblica aperta a tutti. > >> I messaggi di questa lista non hanno relazione diretta con le posizioni > >> dell'Associazione GFOSS.it. > >> 796 iscritti al 28/12/2017 > > > > > > _______________________________________________ > Gfoss@lists.gfoss.it > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 796 iscritti al 28/12/2017 -- *Dott. For. Ludovico Frate, Ph.D.* *Via Montalto 17, 86087 - Rionero Sannitico (IS) - ITALIA.* *Collaboratore presso Studio Associato Ecoview <http://www.ecoview.it/>* https://www.lezionigis.it *Cel: ++39 3333767557* *P.IVA 00960030948E-mail: *frateludov...@gmail.com*|* ludovicofr...@hotmail.it *Research Gate <https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7>* |*Google Scholar <https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it>*|*LinkedIn <https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name>* _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 796 iscritti al 28/12/2017