[Gfoss] Spatialite e dissolve

[aperi2007]

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
>
>