[Gfoss] Spatialite e dissolve

[Andrea Peri]

Ok
Facci sapere poi come è andata a finire.
A.


Il Sab 22 Set 2018, 21:16 ludovico frate <frateludovico a gmail.com> 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 <aperi2007 a 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.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
>> >
>> >
>>
>> _______________________________________________
>> 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>*
>