[Gfoss] Spatialite e dissolve

Local Chapters GFOSS.it
1

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?

Grazie

--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/

2

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

3

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

--
*Dott. For. Ludovico Frate, Ph.D.*

*Via Montalto 17, 86087 - Rionero Sannitico (IS) - ITALIA.*
*Collaboratore presso Studio Associato Ecoview <http://www.ecoview.it/&gt;\*
https://www.lezionigis.it
*Cel: ++39 3333767557*

*P.IVA 00960030948E-mail: *frateludovico@gmail.com*|*
ludovicofrate@hotmail.it
*Research Gate
<https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7&gt;\*
|*Google Scholar
<https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it&gt;\*|\*LinkedIn
<https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name&gt;\*

4

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

5

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@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@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/&gt;\*
https://www.lezionigis.it
*Cel: ++39 3333767557*

*P.IVA 00960030948E-mail: *frateludovico@gmail.com*|*
ludovicofrate@hotmail.it
*Research Gate
<https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7&gt;\*
|*Google Scholar
<https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it&gt;\*|\*LinkedIn
<https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name&gt;\*

6

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

Il Sab 22 Set 2018, 21:16 ludovico frate <frateludovico@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@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@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/&gt;\*
https://www.lezionigis.it
*Cel: ++39 3333767557*

*P.IVA 00960030948E-mail: *frateludovico@gmail.com*|*
ludovicofrate@hotmail.it
*Research Gate
<https://www.researchgate.net/profile/Ludovico_Frate?ev=hdr_xprf&_sg=lGaI2daIBO6kPmtye069ckFfDExcPoNVKJHrqvQEPQmsmnHolvnRZzPQdcyxs1g7&gt;\*
|*Google Scholar
<https://scholar.google.it/citations?user=wGFhBrkAAAAJ&hl=it&gt;\*|\*LinkedIn
<https://www.linkedin.com/in/ludovico-frate-a387aa57?trk=hp-identity-name&gt;\*