ST_Union e PostGIS

[a.furieri]

On Wed, 13 Dec 2017 17:46:13 +0100, Massimiliano Moraca wrote:
> Da premettere che non ho usato(ancora) nessun plugin o tool di QGIS
> per manipolare il db.
>
> I TRIGGER (di cui so 0!) potrebbero ovviare alla creazione delle
> view?
>

si e no: tu hai due problemi distinti e separati.
1. far girare le cose sotto SQL; e qua la tua View (proprio quella
    che hai gia' realizzato) potrebbe risultare decisamente utile.
2. riuscrire a convincere QGIS che deve visualizzare determinati
    dati; qua scattano tutta una serie di vincoli ulteriori, e la
    presenza di una aggregata crea un sacco di problemi.

insomma, detto con altre parole, a te serve gestire due "layers":
a. il primo e' un vero e proprio layer/tavola, e su cui andrai a
    fare INSERT/UPDATE/DELETE
b. il secondo rappresenta semplicemente l'aggregazione del primo,
    ad eclusivo beneficio dei processi di visualizzazione di QGIS.
    definire alcuni opportuni Triggers potrebbe consentirti di
    rendere totalmente automatico il processo di corretta
    sincronizzazione tra le due tavole.


> Mi spiego meglio. Mi sono rassegnato, per ora, a creare le tabelle e
> non le view: un trigger potrebbe fare in modo che aggiornata la
> tabella principale(ammesso si possa fare questo distinguo) si attivi
> automaticamente l'aggiornamento di quella "correlata" all'area
> aggiornata?
>

esattamente: e' proprio cosi'.
se vuoi entrare piu' in profondita' ti consiglio di studiarti
il codice SQL dei triggers a supporto dello Spatial Index.

prova a spulciare con SpatiaLite GUI una qualsiasi tavola con
geometria e Spatial Index; vedrai che ha associati tre triggers
il cui nome sara' "gii_<tavola>_<geom>" e "giu_<tavola>_<geom>"

come vedrai, il trigger "gii_" intercetta tutte le INSERT sulla
tavola-madre, ed aggiorna coerentemente lo Spatial Index.
invece "giu_" intercetta tutte le UPDATE (ma solo nel caso in
cui la geometria sia realmente variata), ed anche in questo
caso aggiorna lo SpatialIndex.

ovviamente il tuo caso richiedera' un approccio diverso, ma
l'idea di fondo e' identica; ogni evento che tocca la
tavola-madre dovra' riflettersi automaticamente sull'altra
tavola.


> Come ho scritto stavo provando con i filtri di QGIS, ma forse Sandro
> quando parlavi dell'approccio ingannevole di QGIS ti riferivi a
> questo?
>

mi riferivo semplicemente alla mia esperienza diretta maturata sulla
mailing list di spatialite.
per il 90% degli utenti (power users Spatial SQL, sviluppatori
Java/C++/Python etc) il problema delle Spatial Views e delle Views
"updatable" non si pone proprio, e' qualcosa che non interessa o
che al massimo viene percepito come un'ardita stravaganza tecnica.
tutte le domande relative a questi due argomenti arrivano solo
ed esclusivamente dagli utenti di qgis.
pare abbastanza ovvio che e' una specie di "bisogno indotto" ;-)

ciao Sandro
_______________________________________________
[hidden email]
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.
801 iscritti al 19/07/2017

[Massimiliano Moraca]

Pare quindi che debba per forza fare conoscenza con i TRIGGER.....
Grazie a tutti per le indicazioni :)

Il giorno 13 dicembre 2017 18:18, <[hidden email]> ha scritto:

> On Wed, 13 Dec 2017 17:46:13 +0100, Massimiliano Moraca wrote:
>
>> Da premettere che non ho usato(ancora) nessun plugin o tool di QGIS
>> per manipolare il db.
>>
>> I TRIGGER (di cui so 0!) potrebbero ovviare alla creazione delle view?
>>
>>
> si e no: tu hai due problemi distinti e separati.
> 1. far girare le cose sotto SQL; e qua la tua View (proprio quella
>    che hai gia' realizzato) potrebbe risultare decisamente utile.
> 2. riuscrire a convincere QGIS che deve visualizzare determinati
>    dati; qua scattano tutta una serie di vincoli ulteriori, e la
>    presenza di una aggregata crea un sacco di problemi.
>
> insomma, detto con altre parole, a te serve gestire due "layers":
> a. il primo e' un vero e proprio layer/tavola, e su cui andrai a
>    fare INSERT/UPDATE/DELETE
> b. il secondo rappresenta semplicemente l'aggregazione del primo,
>    ad eclusivo beneficio dei processi di visualizzazione di QGIS.
>    definire alcuni opportuni Triggers potrebbe consentirti di
>    rendere totalmente automatico il processo di corretta
>    sincronizzazione tra le due tavole.
>
>
> Mi spiego meglio. Mi sono rassegnato, per ora, a creare le tabelle e
>> non le view: un trigger potrebbe fare in modo che aggiornata la
>> tabella principale(ammesso si possa fare questo distinguo) si attivi
>> automaticamente l'aggiornamento di quella "correlata" all'area
>> aggiornata?
>>
>>
> esattamente: e' proprio cosi'.
> se vuoi entrare piu' in profondita' ti consiglio di studiarti
> il codice SQL dei triggers a supporto dello Spatial Index.
>
> prova a spulciare con SpatiaLite GUI una qualsiasi tavola con
> geometria e Spatial Index; vedrai che ha associati tre triggers
> il cui nome sara' "gii_<tavola>_<geom>" e "giu_<tavola>_<geom>"
>
> come vedrai, il trigger "gii_" intercetta tutte le INSERT sulla
> tavola-madre, ed aggiorna coerentemente lo Spatial Index.
> invece "giu_" intercetta tutte le UPDATE (ma solo nel caso in
> cui la geometria sia realmente variata), ed anche in questo
> caso aggiorna lo SpatialIndex.
>
> ovviamente il tuo caso richiedera' un approccio diverso, ma
> l'idea di fondo e' identica; ogni evento che tocca la
> tavola-madre dovra' riflettersi automaticamente sull'altra
> tavola.
>
>
> Come ho scritto stavo provando con i filtri di QGIS, ma forse Sandro
>> quando parlavi dell'approccio ingannevole di QGIS ti riferivi a
>> questo?
>>
>>
> mi riferivo semplicemente alla mia esperienza diretta maturata sulla
> mailing list di spatialite.
> per il 90% degli utenti (power users Spatial SQL, sviluppatori
> Java/C++/Python etc) il problema delle Spatial Views e delle Views
> "updatable" non si pone proprio, e' qualcosa che non interessa o
> che al massimo viene percepito come un'ardita stravaganza tecnica.
> tutte le domande relative a questi due argomenti arrivano solo
> ed esclusivamente dagli utenti di qgis.
> pare abbastanza ovvio che e' una specie di "bisogno indotto" ;-)
>
> ciao Sandro
>

_______________________________________________
[hidden email]
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.
801 iscritti al 19/07/2017

[Amedeo Fadini]

Ciao a tutti,

Il giorno 13 dicembre 2017 17:05, Sandro Santilli <[hidden email]> ha scritto:

> On Wed, Dec 13, 2017 at 04:38:22PM +0100, Massimiliano Moraca wrote:
> > Tra l'altro noto che le VIEW rendono il caricamento dei dati in QGIS un
> > processo molto lento, cosa che non avviene nelle table.
>
> Perche' non puo' usare un indice su un oggetto che non esiste ancora
> fino al momento della SELECT, immagino. Se la materializzi, e ci
> definisci un indice, dovresti risolvere.


Concordo, in postgis le viste materializzate sono utilissime, io ho dati
che arrivano da diversi database con data wrapper,
ho creato le viste materializzate con un suffisso che mi permette di
identificarle e ho una funzione che a intervalli regolari esegue per
ciascuna il refresh.

In pratica l'utente aggiorna i dati alfanumerici e dopo x minuti io ho già
a disposizione le nuove geometrie corrispondenti,
ad esempio funziona per i consorzi di comuni, situazione simile alla tua

Le istruzioni sono qui:
https://www.postgresql.org/docs/9.6/static/rules-materializedviews.html

amefad
_______________________________________________
[hidden email]
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.
801 iscritti al 19/07/2017