Ok Facci sapere poi come è andata a finire. A.
Il Sab 22 Set 2018, 21:16 ludovico frate <[email protected]> ha scritto: > 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 <[email protected]> > 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 <[email protected]> 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 >> >> _______________________________________________ >> >> [email protected] >> >> 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 >> > >> > >> >> _______________________________________________ >> [email protected] >> 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: *[email protected]*|* > [email protected] > *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>* > _______________________________________________ [email protected] 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
