Gfoss -- Geographic Free and Open Source Software - Italian mailing list

ST_Union e PostGIS

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Massimiliano Moraca

ST_Union e PostGIS

Buongiorno,
in QGIS con un virtual layer scrivendo questa query:

>
>
>
>
>
>
> *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
> dipartimentiGROUP BY cd_diparti;*

Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite.

La stessa query in PostGIS mi genera invece questo errore:

>
>
>
>
>
> *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire nella
> clausola GROUP BY o essere usata in una funzione di aggregazioneLINE 3:
> ogc_fid, ^SQL state: 42803Character: 39*

Se assecondo il messaggio mi chiede successivamente di inserire anche
*dipartimen
*ed il risultato non è il *DISSOLVE *ma la replica di ogni tupla della
tabella selezionata.

Eliminando *ogc_fid *e *dipartimen *e rieseguendo la query in PostGis
ottengo il risultato atteso.

Il tutto confluirà in una *VIEW*. Ho la necessità che nella view siano
presenti anche le due colonne in questione per motivi di etichettatura
*dipartimen
*(ma questo è il male minore visto che potrei risolvere con un *JOIN *in
QGIS sfruttando *cd_diparti*) e *ogc_fid *perchè dovrò poi esportare questo
database in SpatiaLite. SpatiaLite per le view "geometriche" chiede l'id
della tabella associata alla view quanto si va ad usare:

>
>
> * INSERT INTO views_geometry_columns (view_name, view_geometry,
> view_rowid, f_table_name, f_geometry_column, read_only) VALUES ('geometria
> creata', 'geom', 'chiave geometria sorgente', 'geometria sorgente',
> 'geom',1)*

Temo che nell'esportazione la view non venga attivata per questo vorrei che
ci fosse *ogc_fid*.

Forse concettualmente sbaglio qualcosa?

La versione di PgAdmin che uso è la 4, quella di PostgreSQL è la 10 mentre
PostGIS è 2.4. Il file se può servire è scaricabile da questo link:
https://drive.google.com/open?id=14RX4k7oXO6zxrzgjBVuIYKVE6AVCaaxk
_______________________________________________
[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

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

giohappy

Re: ST_Union e PostGIS

Ciao Massimiliano,
come puoi aspettarti di avere il campo ogc_fid dopo aver fatto il dissolve?
PostgreSQL ti chiede di usare un GROUP BY anche su quel campo OPPURE devi
passarlo ad una funzione di aggregazione. Es.

SELECT ST_Union(geom) AS geometry, min(ogc_fid) FROM dipartimenti GROUP BY
cd_diparti;

In questo esempio prendo l'ogc_fid più piccolo (scelta arbitraria ma
ammissibile) tra tutti i cd_diparti aggregati (dissolved).

Giovanni

Il giorno 13 dicembre 2017 12:13, Massimiliano Moraca <
[hidden email]> ha scritto:

> Buongiorno,
> in QGIS con un virtual layer scrivendo questa query:
>
> >
> >
> >
> >
> >
> >
> > *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
> > dipartimentiGROUP BY cd_diparti;*
>
> Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite.
>
> La stessa query in PostGIS mi genera invece questo errore:
>
> >
> >
> >
> >
> >
> > *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire nella
> > clausola GROUP BY o essere usata in una funzione di aggregazioneLINE 3:
> > ogc_fid, ^SQL state: 42803Character: 39*
>
>
> Se assecondo il messaggio mi chiede successivamente di inserire anche
> *dipartimen
> *ed il risultato non è il *DISSOLVE *ma la replica di ogni tupla della
> tabella selezionata.
>
> Eliminando *ogc_fid *e *dipartimen *e rieseguendo la query in PostGis
> ottengo il risultato atteso.
>
> Il tutto confluirà in una *VIEW*. Ho la necessità che nella view siano
> presenti anche le due colonne in questione per motivi di etichettatura
> *dipartimen
> *(ma questo è il male minore visto che potrei risolvere con un *JOIN *in
> QGIS sfruttando *cd_diparti*) e *ogc_fid *perchè dovrò poi esportare questo
> database in SpatiaLite. SpatiaLite per le view "geometriche" chiede l'id
> della tabella associata alla view quanto si va ad usare:
>
> >
> >
> > * INSERT INTO views_geometry_columns (view_name, view_geometry,
> > view_rowid, f_table_name, f_geometry_column, read_only) VALUES
> ('geometria
> > creata', 'geom', 'chiave geometria sorgente', 'geometria sorgente',
> > 'geom',1)*
>
>
> Temo che nell'esportazione la view non venga attivata per questo vorrei che
> ci fosse *ogc_fid*.
>
> Forse concettualmente sbaglio qualcosa?
>
> La versione di PgAdmin che uso è la 4, quella di PostgreSQL è la 10 mentre
> PostGIS è 2.4. Il file se può servire è scaricabile da questo link:
> https://drive.google.com/open?id=14RX4k7oXO6zxrzgjBVuIYKVE6AVCaaxk
> _______________________________________________
> [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

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

Sandro Santilli-2

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

On Wed, Dec 13, 2017 at 12:13:37PM +0100, Massimiliano Moraca wrote:

> > *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
> > dipartimentiGROUP BY cd_diparti;*

> Se assecondo il messaggio mi chiede successivamente di inserire anche
> *dipartimen
> *ed il risultato non è il *DISSOLVE *ma la replica di ogni tupla della
> tabella selezionata.

Certo, se gruppi per "ogc_fid" e' normale, sono tutti diversi.

> Eliminando *ogc_fid *e *dipartimen *e rieseguendo la query in PostGis
> ottengo il risultato atteso.

E' quello che mi attenderei anche io.

> Il tutto confluirà in una *VIEW*. Ho la necessità che nella view siano
> presenti anche le due colonne in questione per motivi di etichettatura

Se dissolvi finisci con avere una unica geometria, derivante da
diverse geometrie, ognuna col suo "ogc_fid" e "cd_diparti", come
vuoi etichettare la nuova geometria risultante dall'unione ?

Potresti voler vedere la lista di tutti i "ogc_fid", nel qual caso
potresti aggregare anche quel campo, con array_agg(ogc_fid).

--strk;

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

Marco Li Volsi

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

Ciao.

Chiedo alcune informazioni sui dati

Tu vuoi dissolvere una serie di geometrie in base ad un campo con valore
comune (cd_diparti), ma i valori degli altri campi sono diversi?
intendo dire: hai una situazione del genere?

cd_diparti ogc_fid
dipartimen
Pippo
1
Qui
Pippo 2
Qui
Pippo 3
Qui
Pluto
4
Quo
Pluto 5
Quo
Paperino
6
Qua

il campo ogc_fid contiene la chiave primaria della tabella con la geometria?

Il 13/12/2017 12:13, Massimiliano Moraca ha scritto:

> Buongiorno,
> in QGIS con un virtual layer scrivendo questa query:
>
>>
>>
>>
>>
>>
>> *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
>> dipartimentiGROUP BY cd_diparti;*
> Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite.
>
> La stessa query in PostGIS mi genera invece questo errore:
>
>>
>>
>>
>>
>> *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire nella
>> clausola GROUP BY o essere usata in una funzione di aggregazioneLINE 3:
>> ogc_fid, ^SQL state: 42803Character: 39*
>
> Se assecondo il messaggio mi chiede successivamente di inserire anche
> *dipartimen
> *ed il risultato non è il *DISSOLVE *ma la replica di ogni tupla della
> tabella selezionata.
>
> Eliminando *ogc_fid *e *dipartimen *e rieseguendo la query in PostGis
> ottengo il risultato atteso.
>
> Il tutto confluirà in una *VIEW*. Ho la necessità che nella view siano
> presenti anche le due colonne in questione per motivi di etichettatura
> *dipartimen
> *(ma questo è il male minore visto che potrei risolvere con un *JOIN *in
> QGIS sfruttando *cd_diparti*) e *ogc_fid *perchè dovrò poi esportare questo
> database in SpatiaLite. SpatiaLite per le view "geometriche" chiede l'id
> della tabella associata alla view quanto si va ad usare:
>
>>
>> * INSERT INTO views_geometry_columns (view_name, view_geometry,
>> view_rowid, f_table_name, f_geometry_column, read_only) VALUES ('geometria
>> creata', 'geom', 'chiave geometria sorgente', 'geometria sorgente',
>> 'geom',1)*
>
> Temo che nell'esportazione la view non venga attivata per questo vorrei che
> ci fosse *ogc_fid*.
>
> Forse concettualmente sbaglio qualcosa?
>
> La versione di PgAdmin che uso è la 4, quella di PostgreSQL è la 10 mentre
> PostGIS è 2.4. Il file se può servire è scaricabile da questo link:
> https://drive.google.com/open?id=14RX4k7oXO6zxrzgjBVuIYKVE6AVCaaxk
> _______________________________________________
> [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

a.furieri

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

On Wed, 13 Dec 2017 12:13:37 +0100, Massimiliano Moraca wrote:

> Buongiorno,
> in QGIS con un virtual layer scrivendo questa query:
>
>> *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti,
>> dipartimenFROM
>> dipartimentiGROUP BY cd_diparti;*
>
> Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite.
>
> La stessa query in PostGIS mi genera invece questo errore:
>
>> *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire
>> nella
>> clausola GROUP BY o essere usata in una funzione di aggregazioneLINE
>> 3:
>> ogc_fid, ^SQL state: 42803Character: 39*
>

Massimiliano,

occhio ai dettagli, a volte sono assolutamente critici.
i due dialetti SQL supportati rispettivamente da PostgreSQL e da SQLite
si assomigliano, ma non sono affatto identici.

l'implementazione delle clausole GROUP BY e' uno dei punti in cui si
nota
maggiormente la diversitra' tra i due: su SQLite e' decisamente
flessibile
e molto pratica da usarsi, mentre su PostgreSQL e' molto piu' rigida e
pedante.

scendendo nei dettagli, SQLite non ti impone mai il vincolo per cui
tutte
le colonne presenti nel dataset devono essere obbligatoriamente
definite
nella GROUP BY oppure devono essere il risultato di una funzione di
aggregazione. Viceversa per PostgreSQL il vincolo e' stringente.

nota: inserire "ogc_fid" (che si suppone sia una PK) tra i risultati
senza citarlo nella GROUP BY non ha senso logico; SQLite accetta
tranquillamente questa condizione, ma poi scoprirai che nel
resultset di ritorno ci troverai semplicemente un valore pescato
a casaccio tra tutti quelli che presentano il medesimo valore
per "cd_diparti".

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

Re: ST_Union e PostGIS

Innanzitutto grazie a tutti per le risposte.
Mo vi rispondo uno ad uno. Sembra una minaccia ma non lo è :D

Ciao Massimiliano,
> come puoi aspettarti di avere il campo ogc_fid dopo aver fatto il
> dissolve?
> PostgreSQL ti chiede di usare un GROUP BY anche su quel campo OPPURE devi
> passarlo ad una funzione di aggregazione. Es.
> SELECT ST_Union(geom) AS geometry, min(ogc_fid) FROM dipartimenti GROUP
> BY cd_diparti;
> In questo esempio prendo l'ogc_fid più piccolo (scelta arbitraria ma
> ammissibile) tra tutti i cd_diparti aggregati (dissolved).
> Giovanni

Ciao Giovanni infatti non l'avrei usato quel campo ma mi serve per
SpatiaLite in cui quel campo è poi pescato random tra gli altri presenti
nella tabella.

> > *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
>
> > > dipartimentiGROUP BY cd_diparti;*
> > Se assecondo il messaggio mi chiede successivamente di inserire anche
> > *dipartimen
> > *ed il risultato non è il *DISSOLVE *ma la replica di ogni tupla della
> > tabella selezionata.
>
> Certo, se gruppi per "ogc_fid" e' normale, sono tutti diversi.
>
> > Eliminando *ogc_fid *e *dipartimen *e rieseguendo la query in PostGis
> > ottengo il risultato atteso.
>
> E' quello che mi attenderei anche io.
>
> > Il tutto confluirà in una *VIEW*. Ho la necessità che nella view siano
> > presenti anche le due colonne in questione per motivi di etichettatura
>
> Se dissolvi finisci con avere una unica geometria, derivante da
> diverse geometrie, ognuna col suo "ogc_fid" e "cd_diparti", come
> vuoi etichettare la nuova geometria risultante dall'unione ?
> Potresti voler vedere la lista di tutti i "ogc_fid", nel qual caso
> potresti aggregare anche quel campo, con array_agg(ogc_fid).
> --strk;
>
> Ciao Sandro, mi aspetto anche io ciò che accade se gruppo per *ogc_fid*,

il perchè mi serve è la risposta che ho dato a Giovanni in questa mail. Al
codice presente in *cd_diparti *è associato sempre lo stesso nome di
dipartimento in *dipartimen*, quindi da quella aggregazione avrei 5
geometrie ognuna con valori aggregati di quei campi.

> Ciao.
> Chiedo alcune informazioni sui dati
> Tu vuoi dissolvere una serie di geometrie in base ad un campo con valore
> comune (cd_diparti), ma i valori degli altri campi sono diversi?
> intendo dire: hai una situazione del genere?
> cd_diparti ogc_fid
> dipartimen
> Pippo
> 1
> Qui
> Pippo 2
> Qui
> Pippo 3
> Qui
> Pluto
> 4
> Quo
> Pluto 5
> Quo
> Paperino
> 6
> Qua
> il campo ogc_fid contiene la chiave primaria della tabella con la
> geometria?

Ciao Marco, come ho risposto a Sandro per ogni singolo valore di *cd_diparti
*c'è uno ed uno solo in *dipartimen*, quindi non sono diversi. Puoi vederlo
tu stesso se scarichi il file allegato alla prima mail. Il campo *ogc_fid *è
chiave primaria.

Massimiliano,

> occhio ai dettagli, a volte sono assolutamente critici.
> i due dialetti SQL supportati rispettivamente da PostgreSQL e da SQLite
> si assomigliano, ma non sono affatto identici.
> l'implementazione delle clausole GROUP BY e' uno dei punti in cui si nota
> maggiormente la diversitra' tra i due: su SQLite e' decisamente flessibile
> e molto pratica da usarsi, mentre su PostgreSQL e' molto piu' rigida e
> pedante.
> scendendo nei dettagli, SQLite non ti impone mai il vincolo per cui tutte
> le colonne presenti nel dataset devono essere obbligatoriamente definite
> nella GROUP BY oppure devono essere il risultato di una funzione di
> aggregazione. Viceversa per PostgreSQL il vincolo e' stringente.
> nota: inserire "ogc_fid" (che si suppone sia una PK) tra i risultati
> senza citarlo nella GROUP BY non ha senso logico; SQLite accetta
> tranquillamente questa condizione, ma poi scoprirai che nel
> resultset di ritorno ci troverai semplicemente un valore pescato
> a casaccio tra tutti quelli che presentano il medesimo valore
> per "cd_diparti".
> ciao Sandro

Ciao Sandro, ho notato che i due hanno linguaggi diversi per certi aspetti.
Vorrei fare in modo però di poter distribuire il geodatabase in SpatiaLite
a fine lavoro e non come un insieme di shp suddivisi in cartelle, per
questo cerco di fare attenzione alla "compatibilità" tra i due. Non so però
se è una strada perseguibile. Potrei esportare tutto come file backup di
PostGIS ma il fatto è che il ricevente non ha nè competenze GIS nè
dimestichezza con i database. Gli sto creando delle stampe e per
completezza oltre ai file immagine alla fine volevo dargli anche il
geodatabase da cui ho creato quelle stampe.
Come ho detto a Marco *ogc_fid *è chiave primaria. Avevo notato un po' di
tempo fa che nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
tabella sorgente, id assegnato poi random.

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

> On Wed, 13 Dec 2017 12:13:37 +0100, Massimiliano Moraca wrote:
>
>> Buongiorno,
>> in QGIS con un virtual layer scrivendo questa query:
>>
>> *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM
>>> dipartimentiGROUP BY cd_diparti;*
>>>
>>
>> Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite.
>>
>> La stessa query in PostGIS mi genera invece questo errore:
>>
>> *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire nella
>>> clausola GROUP BY o essere usata in una funzione di aggregazioneLINE 3:
>>> ogc_fid, ^SQL state: 42803Character: 39*
>>>
>>
>>
> Massimiliano,
>
> occhio ai dettagli, a volte sono assolutamente critici.
> i due dialetti SQL supportati rispettivamente da PostgreSQL e da SQLite
> si assomigliano, ma non sono affatto identici.
>
> l'implementazione delle clausole GROUP BY e' uno dei punti in cui si nota
> maggiormente la diversitra' tra i due: su SQLite e' decisamente flessibile
> e molto pratica da usarsi, mentre su PostgreSQL e' molto piu' rigida e
> pedante.
>
> scendendo nei dettagli, SQLite non ti impone mai il vincolo per cui tutte
> le colonne presenti nel dataset devono essere obbligatoriamente definite
> nella GROUP BY oppure devono essere il risultato di una funzione di
> aggregazione. Viceversa per PostgreSQL il vincolo e' stringente.
>
> nota: inserire "ogc_fid" (che si suppone sia una PK) tra i risultati
> senza citarlo nella GROUP BY non ha senso logico; SQLite accetta
> tranquillamente questa condizione, ma poi scoprirai che nel
> resultset di ritorno ci troverai semplicemente un valore pescato
> a casaccio tra tutti quelli che presentano il medesimo valore
> per "cd_diparti".
>
> 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
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

a.furieri

Re: ST_Union e PostGIS

On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
> comunque un id dalla tabella sorgente, id assegnato poi random.
>

Massimiliano,

stai ben attento perche' qua rischi di combinare un bell'arrosto.

1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
tabella sorgente"

esatto, e' proprio cosi': per la precisione ti chiede di
specificare quale sia il nome della colonna-VIEW che riporta
il ROWID che identifica la riga della tavola-input che
fornisce la geometria presente nella View.
Corollario: una Spatial View di SpatiaLite non puo' mai
fornire una geometria che sia il risultato di una funzione
o il frutto di una aggregazione.
_DEVE_ necessariamente essere una geometria presa tal
quale da una delle tavole di input della View, senza che
intervenga nessuna manipolazione di sorta.
e la colonna "rowid" presente nella Spatial View deve
consentire di tenere coerentemente in synchro le righe
della tavola-madre con il suo eventuale Spatial Index.

2. "id assegnato poi random"

assolutamene _NO_ !!!!
non puo' essere random, _DEVE_ identificare esattamente
la riga della tavola che fornisce la geometria (ergo, o
si tratta di una PK oppure in forma piu' geerica di un
ROWID).
e c'e' un motivo assolutamente stringente per imporre
questo vincolo: altrimenti lo Spatial Index (che e' sempre
basato sulla tavola primaria e non sulla View) impazzisce,
e fornira' risultati padellati di pura fantasia con
risultati folli e potenzialmete devastanti.
in buona sostanza, se nella colonna ROWID della Spatial
View fai in modo che ci finiscano "valori random" stai
facendo tutto il possibile per massacrare la logica di
funzionamento dello Spatial Index.
per inciso, ti ricordo che su SQLite/SpatiaLite lo
Spatial Index R*TRee non e' affatto un "indice", ma e'
semplicemente un'ulteriore tavola, anzi per l'esattezza
e' una VirtualTable.
funziona, e funziona pure in modo molto efficiente, ma
esige lo scrupoloso rispetto di tutta una serie di vincoli
basati sullo scrupoloso rispetto dei JOIN relazionale
basati sul ROWID, altrimenti salta tutto per aria.

hint: ma perche' vuoi usare proprio una Spatial View ?
nel tuo caso, se ho capito bene il problema, sarebbe molto
piu' opportuno materializzare ancora un'altra tavola, p.es.:

CREATE TABLE dipart2 AS
SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
FROM dipartimenti
GROUP BY cd_diparti;
SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
SELECT CreateSpatialIndex('dipart2', 'geometry');

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

Re: ST_Union e PostGIS

La facevo facile quindi io Sandro.. :|

hint: ma perche' vuoi usare proprio una Spatial View ?
> nel tuo caso, se ho capito bene il problema, sarebbe molto
> piu' opportuno materializzare ancora un'altra tavola, p.es.:

Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica
ogni tanto capita che mi venga chiesto di spostare un villaggio da una
categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego
meglio. Il file in questione è solo un estratto depurato di tutta una serie
di informazioni(per motivi di privacy relativa al progetto) che rientrano
in una decina di colonne. Ad esempio:

Nome|Colore|tipo|area
A|rosso|tipo1|10
B|verde|tipo2|100
C|blu|tipo1|3
D|rosso|tipo1|450
E|blu|tipo3|753

Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento per
tipo con una sommatoria delle aree per tipo, con la view mi basta cambiare
il dato nella tabella sorgente per avere attivo l'automatismo; altrimenti
dovrei creare una nuova tabella ogni volta.

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

> On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
>
>> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
>> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
>> comunque un id dalla tabella sorgente, id assegnato poi random.
>>
>>
> Massimiliano,
>
> stai ben attento perche' qua rischi di combinare un bell'arrosto.
>
> 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
> tabella sorgente"
>
> esatto, e' proprio cosi': per la precisione ti chiede di
> specificare quale sia il nome della colonna-VIEW che riporta
> il ROWID che identifica la riga della tavola-input che
> fornisce la geometria presente nella View.
> Corollario: una Spatial View di SpatiaLite non puo' mai
> fornire una geometria che sia il risultato di una funzione
> o il frutto di una aggregazione.
> _DEVE_ necessariamente essere una geometria presa tal
> quale da una delle tavole di input della View, senza che
> intervenga nessuna manipolazione di sorta.
> e la colonna "rowid" presente nella Spatial View deve
> consentire di tenere coerentemente in synchro le righe
> della tavola-madre con il suo eventuale Spatial Index.
>
>
> 2. "id assegnato poi random"
>
> assolutamene _NO_ !!!!
> non puo' essere random, _DEVE_ identificare esattamente
> la riga della tavola che fornisce la geometria (ergo, o
> si tratta di una PK oppure in forma piu' geerica di un
> ROWID).
> e c'e' un motivo assolutamente stringente per imporre
> questo vincolo: altrimenti lo Spatial Index (che e' sempre
> basato sulla tavola primaria e non sulla View) impazzisce,
> e fornira' risultati padellati di pura fantasia con
> risultati folli e potenzialmete devastanti.
> in buona sostanza, se nella colonna ROWID della Spatial
> View fai in modo che ci finiscano "valori random" stai
> facendo tutto il possibile per massacrare la logica di
> funzionamento dello Spatial Index.
> per inciso, ti ricordo che su SQLite/SpatiaLite lo
> Spatial Index R*TRee non e' affatto un "indice", ma e'
> semplicemente un'ulteriore tavola, anzi per l'esattezza
> e' una VirtualTable.
> funziona, e funziona pure in modo molto efficiente, ma
> esige lo scrupoloso rispetto di tutta una serie di vincoli
> basati sullo scrupoloso rispetto dei JOIN relazionale
> basati sul ROWID, altrimenti salta tutto per aria.
>
> hint: ma perche' vuoi usare proprio una Spatial View ?
> nel tuo caso, se ho capito bene il problema, sarebbe molto
> piu' opportuno materializzare ancora un'altra tavola, p.es.:
>
> CREATE TABLE dipart2 AS
> SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
> FROM dipartimenti
> GROUP BY cd_diparti;
> SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
> SELECT CreateSpatialIndex('dipart2', 'geometry');
>
> ciao Sandro
>
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

Andrea Peri

Re: ST_Union e PostGIS

Infatti queste cose non sono facili per niente.
Però il tuo approccio è sano.
Ovvero hai d lle specifiche e stai valutando come fare per ottenere il
sistema nell'ansia completezza.
Ora che conosci meglio i limiti di un determinato stack tecnologico puoi
decidere se introdurre nel tuo sistema infrastrutturale dei cambiamenti che
superino i limiti identificati oppure cambi qualcosa nellonstack.

Sempre meglio che partire mettendo in piedi un sistema che abbozza il
funzionamento rimandando certi studi a quando non è più differisce e solo a
quel momento scoprire i limiti e non sapere come fare a risolverli.

Il 13 Dic 2017 3:19 PM, "Massimiliano Moraca" <[hidden email]>
ha scritto:

> La facevo facile quindi io Sandro.. :|
>
> hint: ma perche' vuoi usare proprio una Spatial View ?
> > nel tuo caso, se ho capito bene il problema, sarebbe molto
> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
>
>
> Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica
> ogni tanto capita che mi venga chiesto di spostare un villaggio da una
> categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego
> meglio. Il file in questione è solo un estratto depurato di tutta una serie
> di informazioni(per motivi di privacy relativa al progetto) che rientrano
> in una decina di colonne. Ad esempio:
>
> Nome|Colore|tipo|area
> A|rosso|tipo1|10
> B|verde|tipo2|100
> C|blu|tipo1|3
> D|rosso|tipo1|450
> E|blu|tipo3|753
>
> Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento per
> tipo con una sommatoria delle aree per tipo, con la view mi basta cambiare
> il dato nella tabella sorgente per avere attivo l'automatismo; altrimenti
> dovrei creare una nuova tabella ogni volta.
>
> Il giorno 13 dicembre 2017 14:56, <[hidden email]> ha scritto:
>
> > On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
> >
> >> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
> >> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
> >> comunque un id dalla tabella sorgente, id assegnato poi random.
> >>
> >>
> > Massimiliano,
> >
> > stai ben attento perche' qua rischi di combinare un bell'arrosto.
> >
> > 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
> > tabella sorgente"
> >
> > esatto, e' proprio cosi': per la precisione ti chiede di
> > specificare quale sia il nome della colonna-VIEW che riporta
> > il ROWID che identifica la riga della tavola-input che
> > fornisce la geometria presente nella View.
> > Corollario: una Spatial View di SpatiaLite non puo' mai
> > fornire una geometria che sia il risultato di una funzione
> > o il frutto di una aggregazione.
> > _DEVE_ necessariamente essere una geometria presa tal
> > quale da una delle tavole di input della View, senza che
> > intervenga nessuna manipolazione di sorta.
> > e la colonna "rowid" presente nella Spatial View deve
> > consentire di tenere coerentemente in synchro le righe
> > della tavola-madre con il suo eventuale Spatial Index.
> >
> >
> > 2. "id assegnato poi random"
> >
> > assolutamene _NO_ !!!!
> > non puo' essere random, _DEVE_ identificare esattamente
> > la riga della tavola che fornisce la geometria (ergo, o
> > si tratta di una PK oppure in forma piu' geerica di un
> > ROWID).
> > e c'e' un motivo assolutamente stringente per imporre
> > questo vincolo: altrimenti lo Spatial Index (che e' sempre
> > basato sulla tavola primaria e non sulla View) impazzisce,
> > e fornira' risultati padellati di pura fantasia con
> > risultati folli e potenzialmete devastanti.
> > in buona sostanza, se nella colonna ROWID della Spatial
> > View fai in modo che ci finiscano "valori random" stai
> > facendo tutto il possibile per massacrare la logica di
> > funzionamento dello Spatial Index.
> > per inciso, ti ricordo che su SQLite/SpatiaLite lo
> > Spatial Index R*TRee non e' affatto un "indice", ma e'
> > semplicemente un'ulteriore tavola, anzi per l'esattezza
> > e' una VirtualTable.
> > funziona, e funziona pure in modo molto efficiente, ma
> > esige lo scrupoloso rispetto di tutta una serie di vincoli
> > basati sullo scrupoloso rispetto dei JOIN relazionale
> > basati sul ROWID, altrimenti salta tutto per aria.
> >
> > hint: ma perche' vuoi usare proprio una Spatial View ?
> > nel tuo caso, se ho capito bene il problema, sarebbe molto
> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
> >
> > CREATE TABLE dipart2 AS
> > SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
> > FROM dipartimenti
> > GROUP BY cd_diparti;
> > SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
> > SELECT CreateSpatialIndex('dipart2', 'geometry');
> >
> > 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

Andrea Peri

Re: ST_Union e PostGIS

Scusate per l ' autocorrettore di Android. Ma all' incirca si capisce....

Il 13 Dic 2017 4:35 PM, "Andrea Peri" <[hidden email]> ha scritto:

> Infatti queste cose non sono facili per niente.
> Però il tuo approccio è sano.
> Ovvero hai d lle specifiche e stai valutando come fare per ottenere il
> sistema nell'ansia completezza.
> Ora che conosci meglio i limiti di un determinato stack tecnologico puoi
> decidere se introdurre nel tuo sistema infrastrutturale dei cambiamenti che
> superino i limiti identificati oppure cambi qualcosa nellonstack.
>
> Sempre meglio che partire mettendo in piedi un sistema che abbozza il
> funzionamento rimandando certi studi a quando non è più differisce e solo a
> quel momento scoprire i limiti e non sapere come fare a risolverli.
>
>
> Il 13 Dic 2017 3:19 PM, "Massimiliano Moraca" <
> [hidden email]> ha scritto:
>
>> La facevo facile quindi io Sandro.. :|
>>
>> hint: ma perche' vuoi usare proprio una Spatial View ?
>> > nel tuo caso, se ho capito bene il problema, sarebbe molto
>> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
>>
>>
>> Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica
>> ogni tanto capita che mi venga chiesto di spostare un villaggio da una
>> categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego
>> meglio. Il file in questione è solo un estratto depurato di tutta una
>> serie
>> di informazioni(per motivi di privacy relativa al progetto) che rientrano
>> in una decina di colonne. Ad esempio:
>>
>> Nome|Colore|tipo|area
>> A|rosso|tipo1|10
>> B|verde|tipo2|100
>> C|blu|tipo1|3
>> D|rosso|tipo1|450
>> E|blu|tipo3|753
>>
>> Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento
>> per
>> tipo con una sommatoria delle aree per tipo, con la view mi basta cambiare
>> il dato nella tabella sorgente per avere attivo l'automatismo; altrimenti
>> dovrei creare una nuova tabella ogni volta.
>>
>> Il giorno 13 dicembre 2017 14:56, <[hidden email]> ha scritto:
>>
>> > On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
>> >
>> >> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
>> >> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
>> >> comunque un id dalla tabella sorgente, id assegnato poi random.
>> >>
>> >>
>> > Massimiliano,
>> >
>> > stai ben attento perche' qua rischi di combinare un bell'arrosto.
>> >
>> > 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
>> > tabella sorgente"
>> >
>> > esatto, e' proprio cosi': per la precisione ti chiede di
>> > specificare quale sia il nome della colonna-VIEW che riporta
>> > il ROWID che identifica la riga della tavola-input che
>> > fornisce la geometria presente nella View.
>> > Corollario: una Spatial View di SpatiaLite non puo' mai
>> > fornire una geometria che sia il risultato di una funzione
>> > o il frutto di una aggregazione.
>> > _DEVE_ necessariamente essere una geometria presa tal
>> > quale da una delle tavole di input della View, senza che
>> > intervenga nessuna manipolazione di sorta.
>> > e la colonna "rowid" presente nella Spatial View deve
>> > consentire di tenere coerentemente in synchro le righe
>> > della tavola-madre con il suo eventuale Spatial Index.
>> >
>> >
>> > 2. "id assegnato poi random"
>> >
>> > assolutamene _NO_ !!!!
>> > non puo' essere random, _DEVE_ identificare esattamente
>> > la riga della tavola che fornisce la geometria (ergo, o
>> > si tratta di una PK oppure in forma piu' geerica di un
>> > ROWID).
>> > e c'e' un motivo assolutamente stringente per imporre
>> > questo vincolo: altrimenti lo Spatial Index (che e' sempre
>> > basato sulla tavola primaria e non sulla View) impazzisce,
>> > e fornira' risultati padellati di pura fantasia con
>> > risultati folli e potenzialmete devastanti.
>> > in buona sostanza, se nella colonna ROWID della Spatial
>> > View fai in modo che ci finiscano "valori random" stai
>> > facendo tutto il possibile per massacrare la logica di
>> > funzionamento dello Spatial Index.
>> > per inciso, ti ricordo che su SQLite/SpatiaLite lo
>> > Spatial Index R*TRee non e' affatto un "indice", ma e'
>> > semplicemente un'ulteriore tavola, anzi per l'esattezza
>> > e' una VirtualTable.
>> > funziona, e funziona pure in modo molto efficiente, ma
>> > esige lo scrupoloso rispetto di tutta una serie di vincoli
>> > basati sullo scrupoloso rispetto dei JOIN relazionale
>> > basati sul ROWID, altrimenti salta tutto per aria.
>> >
>> > hint: ma perche' vuoi usare proprio una Spatial View ?
>> > nel tuo caso, se ho capito bene il problema, sarebbe molto
>> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
>> >
>> > CREATE TABLE dipart2 AS
>> > SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
>> > FROM dipartimenti
>> > GROUP BY cd_diparti;
>> > SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
>> > SELECT CreateSpatialIndex('dipart2', 'geometry');
>> >
>> > 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

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

Tra l'altro noto che le VIEW rendono il caricamento dei dati in QGIS un
processo molto lento, cosa che non avviene nelle table.

Il giorno 13 dicembre 2017 15:19, Massimiliano Moraca <
[hidden email]> ha scritto:

> La facevo facile quindi io Sandro.. :|
>
> hint: ma perche' vuoi usare proprio una Spatial View ?
>> nel tuo caso, se ho capito bene il problema, sarebbe molto
>> piu' opportuno materializzare ancora un'altra tavola, p.es.:
>
>
> Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica
> ogni tanto capita che mi venga chiesto di spostare un villaggio da una
> categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego
> meglio. Il file in questione è solo un estratto depurato di tutta una serie
> di informazioni(per motivi di privacy relativa al progetto) che rientrano
> in una decina di colonne. Ad esempio:
>
> Nome|Colore|tipo|area
> A|rosso|tipo1|10
> B|verde|tipo2|100
> C|blu|tipo1|3
> D|rosso|tipo1|450
> E|blu|tipo3|753
>
> Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento
> per tipo con una sommatoria delle aree per tipo, con la view mi basta
> cambiare il dato nella tabella sorgente per avere attivo l'automatismo;
> altrimenti dovrei creare una nuova tabella ogni volta.
>
> Il giorno 13 dicembre 2017 14:56, <[hidden email]> ha scritto:
>
>> On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
>>
>>> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
>>> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
>>> comunque un id dalla tabella sorgente, id assegnato poi random.
>>>
>>>
>> Massimiliano,
>>
>> stai ben attento perche' qua rischi di combinare un bell'arrosto.
>>
>> 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
>> tabella sorgente"
>>
>> esatto, e' proprio cosi': per la precisione ti chiede di
>> specificare quale sia il nome della colonna-VIEW che riporta
>> il ROWID che identifica la riga della tavola-input che
>> fornisce la geometria presente nella View.
>> Corollario: una Spatial View di SpatiaLite non puo' mai
>> fornire una geometria che sia il risultato di una funzione
>> o il frutto di una aggregazione.
>> _DEVE_ necessariamente essere una geometria presa tal
>> quale da una delle tavole di input della View, senza che
>> intervenga nessuna manipolazione di sorta.
>> e la colonna "rowid" presente nella Spatial View deve
>> consentire di tenere coerentemente in synchro le righe
>> della tavola-madre con il suo eventuale Spatial Index.
>>
>>
>> 2. "id assegnato poi random"
>>
>> assolutamene _NO_ !!!!
>> non puo' essere random, _DEVE_ identificare esattamente
>> la riga della tavola che fornisce la geometria (ergo, o
>> si tratta di una PK oppure in forma piu' geerica di un
>> ROWID).
>> e c'e' un motivo assolutamente stringente per imporre
>> questo vincolo: altrimenti lo Spatial Index (che e' sempre
>> basato sulla tavola primaria e non sulla View) impazzisce,
>> e fornira' risultati padellati di pura fantasia con
>> risultati folli e potenzialmete devastanti.
>> in buona sostanza, se nella colonna ROWID della Spatial
>> View fai in modo che ci finiscano "valori random" stai
>> facendo tutto il possibile per massacrare la logica di
>> funzionamento dello Spatial Index.
>> per inciso, ti ricordo che su SQLite/SpatiaLite lo
>> Spatial Index R*TRee non e' affatto un "indice", ma e'
>> semplicemente un'ulteriore tavola, anzi per l'esattezza
>> e' una VirtualTable.
>> funziona, e funziona pure in modo molto efficiente, ma
>> esige lo scrupoloso rispetto di tutta una serie di vincoli
>> basati sullo scrupoloso rispetto dei JOIN relazionale
>> basati sul ROWID, altrimenti salta tutto per aria.
>>
>> hint: ma perche' vuoi usare proprio una Spatial View ?
>> nel tuo caso, se ho capito bene il problema, sarebbe molto
>> piu' opportuno materializzare ancora un'altra tavola, p.es.:
>>
>> CREATE TABLE dipart2 AS
>> SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
>> FROM dipartimenti
>> GROUP BY cd_diparti;
>> SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
>> SELECT CreateSpatialIndex('dipart2', 'geometry');
>>
>> ciao Sandro
>>
>>
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

Massimiliano Moraca

Re: ST_Union e PostGIS

In reply to this post by Andrea Peri

Ciao Andrea,
il fatto è proprio questo, vorrei appunto evitare di trovarmi a cose fatte
con un problema da gestire. Credo che ora che tutto è in fase di startup
ancora protrei ovviare a problemi che prevedo ci saranno; per quelli che
non prevedo amen! :D

Il giorno 13 dicembre 2017 16:35, Andrea Peri <[hidden email]> ha
scritto:

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

Sandro Santilli-2

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

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. Per l'aggiornamento
"automatico" potresti usare dei trigger (almeno in PostGIS, non so
in Spatialite).

--strk;
_______________________________________________
[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

Re: ST_Union e PostGIS

Stavo provando con l'opzione filtri di QGIS facendo prima il duplicato del
layer in TOC. Però vedo che se attivo una sessione di editing sul layer da
cui è nato il duplicato non posso modificarlo. Uso QGIS 2.18.13

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. Per l'aggiornamento
> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
> in Spatialite).
>
> --strk;
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

a.furieri

Re: ST_Union e PostGIS

In reply to this post by Massimiliano Moraca

On Wed, 13 Dec 2017 16:38:22 +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.
>

Massimiliano,

nota bene: su SQLite (come su tantissimi altri DBMS) le VIEW sono
oggetti READ_ONLY; cioe' roba che puoi interrogare, ma che non
potra' mai essere modificata.

c'e' un unico modo per ottenere su SQLite una VIEW che supporti
gli aggiornamenti, e consiste nel riuscire a definire sapientemenre
un sofisticato waltzer ben orchestrato tutto basato sui TRIGGER.

riassunta all'osso la logica e' questa:
- ciascuno di questi triggers deve intercettare gli eventi
di tipo INSERT/UPDATE/DELETE che possono interessare la View
- dopo di che il trigger provvede ad lanciare una seconda
INSERT/UPDATE/DELETE che questa volta avra' come target
la/e tavola/e che stanno sotto alla View.

stringendo: se tutti i triggers sono scritti dal Dio dello
SQL in persona sara' comunque un processo abbastanza lento,
perche' quella che apparentemente sembra una banale INSERT
finisce per diventare materialmente una catena piu' o meno
ramificata di ulteriori INSERT.
ma se (come non pare affatto improbabile) i triggers sono
scritti "alla garibaldina" senza curarsi troppo delle
ottimizzazioni (magari da qualche tool automatico e cieco),
allora potrebbe facilmente diventare un processo decisamente
_MOLTO_ inefficiente.

l'approccio dei data-providers di QGIS e' spesso ingannevole;
ti presentano sempre ed in tutti i casi una specie di
"modello uniforme", che magari funziona anche (seppure a volte
in modo decisamente avventuroso, rischioso e border-line),
ma non ti dicono mai se quel determinato tipo di operazioni
in relazione ad uno specifico DBMS e' piu' o meno sensato.

io posso solo darti il mio personalissimo parere maturato
in base ad una certa conoscenza dei meccanismi di SQLite;
io personalmente mi guarderi bene dal mettere in piedi
un baraccone basato su Views che consentano le scritture
e gli aggiornamenti tramite triggersi.
ptrei prendere in considerazione l'idea solo se qualcuno
mi tenesse una pistola puntata alla tempia :-D

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

a.furieri

Re: ST_Union e PostGIS

In reply to this post by Sandro Santilli-2

On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:

> 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. Per l'aggiornamento
> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
> in Spatialite).
>

Strk,

mi hai letto nel pensiero ;-)
SQLite offre un supporto molto efficiente per i Triggers.

[1] https://www.sqlite.org/lang_createtrigger.html

Se Massimiliano se la sente non sarebbe per nulla difficile
aggiornare automaticamente la tavola aggregata ogni volta
che viene modificata la tavola madre.

ok, richiederebbe la scrittura di un po' di codice SQL a
supporto di qualche Trigger da impiantare da zero.
ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
e robusto di quel che puo' ottenere automaticamente dai vari
tool di QGIS basati sulle improbabili Spatial Views "updatable"
che sono semplicemente un tentativo decisamente estremo per
cercare di nascondere "sotto al cofano" tutte le numerose
differenze di architettura che ci sono tra PostgreSQL e
SQLite.

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

Marco Li Volsi

Re: ST_Union e PostGIS

metto un po' di carne al fuoco... ma usare le Materialized View in
PostgreSQL ?

Il 13/12/2017 17:35, [hidden email] ha scritto:

> On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:
>> 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. Per l'aggiornamento
>> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
>> in Spatialite).
>>
>
> Strk,
>
> mi hai letto nel pensiero ;-)
> SQLite offre un supporto molto efficiente per i Triggers.
>
> [1] https://www.sqlite.org/lang_createtrigger.html
>
> Se Massimiliano se la sente non sarebbe per nulla difficile
> aggiornare automaticamente la tavola aggregata ogni volta
> che viene modificata la tavola madre.
>
> ok, richiederebbe la scrittura di un po' di codice SQL a
> supporto di qualche Trigger da impiantare da zero.
> ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
> e robusto di quel che puo' ottenere automaticamente dai vari
> tool di QGIS basati sulle improbabili Spatial Views "updatable"
> che sono semplicemente un tentativo decisamente estremo per
> cercare di nascondere "sotto al cofano" tutte le numerose
> differenze di architettura che ci sono tra PostgreSQL e
> SQLite.
>
> 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

Re: ST_Union e PostGIS

In reply to this post by a.furieri

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

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

Non ho una grande esperienza in SQL e ci sono cose avanzate, come i
TRIGGER, che mi sono ignote....

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

> On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:
>
>> 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. Per l'aggiornamento
>> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
>> in Spatialite).
>>
>>
> Strk,
>
> mi hai letto nel pensiero ;-)
> SQLite offre un supporto molto efficiente per i Triggers.
>
> [1] https://www.sqlite.org/lang_createtrigger.html
>
> Se Massimiliano se la sente non sarebbe per nulla difficile
> aggiornare automaticamente la tavola aggregata ogni volta
> che viene modificata la tavola madre.
>
> ok, richiederebbe la scrittura di un po' di codice SQL a
> supporto di qualche Trigger da impiantare da zero.
> ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
> e robusto di quel che puo' ottenere automaticamente dai vari
> tool di QGIS basati sulle improbabili Spatial Views "updatable"
> che sono semplicemente un tentativo decisamente estremo per
> cercare di nascondere "sotto al cofano" tutte le numerose
> differenze di architettura che ci sono tra PostgreSQL e
> SQLite.
>
> ciao Sandro
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

Massimiliano Moraca

Re: ST_Union e PostGIS

In reply to this post by Marco Li Volsi

Intendi questa:
https://www.postgresql.org/docs/9.6/static/rules-materializedviews.html

Il giorno 13 dicembre 2017 17:41, Marco Li Volsi <[hidden email]>
ha scritto:

> metto un po' di carne al fuoco... ma usare le Materialized View in
> PostgreSQL ?
>
>
>
> Il 13/12/2017 17:35, [hidden email] ha scritto:
>
>> On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:
>>
>>> 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. Per l'aggiornamento
>>> "automatico" potresti usare dei trigger (almeno in PostGIS, non so
>>> in Spatialite).
>>>
>>>
>> Strk,
>>
>> mi hai letto nel pensiero ;-)
>> SQLite offre un supporto molto efficiente per i Triggers.
>>
>> [1] https://www.sqlite.org/lang_createtrigger.html
>>
>> Se Massimiliano se la sente non sarebbe per nulla difficile
>> aggiornare automaticamente la tavola aggregata ogni volta
>> che viene modificata la tavola madre.
>>
>> ok, richiederebbe la scrittura di un po' di codice SQL a
>> supporto di qualche Trigger da impiantare da zero.
>> ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
>> e robusto di quel che puo' ottenere automaticamente dai vari
>> tool di QGIS basati sulle improbabili Spatial Views "updatable"
>> che sono semplicemente un tentativo decisamente estremo per
>> cercare di nascondere "sotto al cofano" tutte le numerose
>> differenze di architettura che ci sono tra PostgreSQL e
>> SQLite.
>>
>> 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
>>
>
> _______________________________________________
> [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
>

Consulente GIS, Formatore, Blogger e Ciclista Urbano email: info@massimilianomoraca.it cell: 333 5949583 (lun-ven, 9.00-18.00) website: massimilianomoraca.it

Marco Li Volsi

Re: ST_Union e PostGIS

Si, intendo proprio quella, comunque serve un trigger sulla tabella
originaria per ordinare il lancio del refresh della vista materializzata
stessa. La logica sarebbe sempre la stessa, inoltre una vista
materializzata non è altro che una particolare tabella che memorizza,
oltre ai dati generati dalla query, anche la query utilizzata per
generarla (le prestazioni sarebbero le stesse di una tabella normale).

Se vuoi usare PostGIS si potrebbe seguire questa strada, ovviamente se
serve un database enterprise nel tuo progetto.

Il 13/12/2017 17:47, Massimiliano Moraca ha scritto:

> Intendi questa:
> https://www.postgresql.org/docs/9.6/static/rules-materializedviews.html
>
> Il giorno 13 dicembre 2017 17:41, Marco Li Volsi
> <[hidden email] <mailto:[hidden email]>> ha scritto:
>
> metto un po' di carne al fuoco... ma usare le Materialized View in
> PostgreSQL ?
>
>
>
> Il 13/12/2017 17:35, [hidden email] <mailto:[hidden email]> ha
> scritto:
>
> On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote:
>
> 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. Per l'aggiornamento
> "automatico" potresti usare dei trigger (almeno in
> PostGIS, non so
> in Spatialite).
>
>
> Strk,
>
> mi hai letto nel pensiero ;-)
> SQLite offre un supporto molto efficiente per i Triggers.
>
> [1] https://www.sqlite.org/lang_createtrigger.html
> <https://www.sqlite.org/lang_createtrigger.html>
>
> Se Massimiliano se la sente non sarebbe per nulla difficile
> aggiornare automaticamente la tavola aggregata ogni volta
> che viene modificata la tavola madre.
>
> ok, richiederebbe la scrittura di un po' di codice SQL a
> supporto di qualche Trigger da impiantare da zero.
> ma alla fine otterebbe qualcosa di sicuramente piu' efficiente
> e robusto di quel che puo' ottenere automaticamente dai vari
> tool di QGIS basati sulle improbabili Spatial Views "updatable"
> che sono semplicemente un tentativo decisamente estremo per
> cercare di nascondere "sotto al cofano" tutte le numerose
> differenze di architettura che ci sono tra PostgreSQL e
> SQLite.
>
> ciao Sandro
> _______________________________________________
> [hidden email] <mailto:[hidden email]>
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> <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
>
>
> _______________________________________________
> [hidden email] <mailto:[hidden email]>
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> <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
>
>