[Gfoss] Spatialite e dissolve

[ludovico frate]

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.furieri a 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 a 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: *frateludovico a gmail.com*|*
ludovicofrate a 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>*