[Gfoss] Viste in Spatialite

Local Chapters GFOSS.it
,
1

Ciao Sandro e ciao a tutti,
la spatial table che ho usato per la geometria funziona correttamente, l'ho
importata da uno shape in un db spatialite direttamente da DB manager in
QGIS.
La query che ho usato per creare la view è questa:

SELECT p.the_geom, s.pkey_spu, s.ubicazione_prov, s.ubicazione_com,
s."ID_SPU", s."coord_X", s."coord_Y", s.mod_identcoord, s.desc_modcoord,
s.quota_slm, s.modo_quota, s.data_sito, s.note_sito
FROM "Sito_puntuale" s
LEFT JOIN ind_pu p ON p."ID_SPU" = s."ID_SPU"

e utilizzando l'opzione "create a view" sempre su db manager, dando per
scontato che la registrasse correttamente.

Inoltre non mi è chiara una cosa al punto 3 della tua risposta: se la
spatial view deve contenere necessariamente un ROWID che corrisponde al ROWID
della spatial table, come posso costruire spatial views con relazioni di 1
a N fra spatial table e tabelle semplici? In questo caso i valori di ROWID
si duplicheranno e non saranno più univoci.

Ad ora non posso condividere il db perchè i dati non sono di mia proprietà,
in caso vedo di reperire qualcosa con dati di mio possesso.

Grazie ancora per l'aiuto

Il giorno 4 giugno 2018 18:17, <a.furieri@lqt.it> ha scritto:

On Mon, 4 Jun 2018 17:55:06 +0200, Alessandro Ciali wrote:

Ciao a tutti, sto riscontrando un comportamento assurdo con le viste
SpatiaLite. Ho creato una vista in un DB SpatiaLite tramite il DB manager
di QGIS, unendo un file puntuale con una tabella tramite un semplice join
con corrispondenza 1 a 1. purtroppo quando carico la vista in QGIS 2.14.17
mi succedono cose strane:
- se clicco con l'identify su una feature, mi vengono restituiti i valori
corretti per i vari campi, ma non si apre la form, pur avendo spuntato la
voce "auto open form" e individuando una sola feature
- se cerco di selezionare una o più features, mi vengono selezionati anche
oggetti al di fuori del rettangolo di selezione, e magari non tutti gli
oggetti all'interno del riquadro vengono selezionati

Il DB spatiaLite l'ho creato da QGIS (create new SpatiaLite Layer), la
vista dal DB manager. Le tabelle spaziali e quelle senza geometrie
sembrano
non avere nessun problema, vengono caricate e visualizzate correttamente
in
QGIS.

tengo a precisare che la stessa procedura (ovviamente la query necessita
di
piccole correzioni) in Postgres mi restituisce viste perfettamente
funzionanti

Qualcuno si è imbattuto in questo problema? Sbaglio qualcosa io o è un
problema di QGIS/SpatiaLite?

ciao Alessandro,

le Spatial Views di SpatiaLite hanno dei requisiti ben precisi e molto
stringenti; se non li rispetti il caos e' assicurato.

1. la colonna Geometry della Spatial View deve corrispondenre esattamente
   ad una colonna Geometry di una delle Spatial Tables subordinate.
2. non sono ammesse funzioni SQL che possano alterare in qualsiasi
   modo la geometria originaria (in altre parole: ST_Transform,
   ST_Union, ST_Difference, ST_Buffer etc sono sempre rigorosamente
   proibite in una Spatial View.
3. la Spatial View deve necessariamente contenere una colonna di nome
   ROWID, che deve coincidere esattamente con il ROWID della Spatial
   Table che fornisce la Geometry.

tutti queste restrizioni sono imposte dalla particolare struttura
dello Spatial Index di SpatiaLite, che non ha nulla a che vedere
con quella adottata da PostGIS.
anche se entrambi producono risultati funzionali praticamente
identici, l'architettura interna e' totalmente diversa.
se la Spatial View non e' stata correttamente definita finisce
che il suo Spatial Index di supporto "impazzisce", con risultati
assolutamente paradossali ed apparentemente sconcertanti.

dal quadro che ci fornisci, questo parrebbe proprio il tuo caso;
molto verosimilmente la tua Spatial View si e' presa un po' troppa
liberta' con lo Spatial Index, ed ora funziona in modo del tutto
inattendibili (piu' o meno a casaccio).

hint: prova a condividere la tua struttura dati, ed in particolare:
- gli statements CREATE TABLE della/e Table(s) che utilizzi nella
  tua Spatial View
- lo statement CREATE VIEW che hai usato
- la registrazione della tua Spatial View che hai inserito nella
  meta-tavola "views_geometry_columns"

se chiarisci meglio tutti questi aspetti potro' darti un parere
piu' mirato e meglio argomentato, e magari anche qualche suggerimento
utile per uscire dal pasticcio.

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

--
Alessandro Ciali

2

On Tue, 5 Jun 2018 12:17:01 +0200, Alessandro Ciali wrote:

Ciao Sandro e ciao a tutti,
la spatial table che ho usato per la geometria funziona correttamente,
l'ho importata da uno shape in un db spatialite direttamente da DB
manager in QGIS.

questa informazione e' del tutto irrilevante.
che la tua View funzioni egragiamente dal mero punto di vista SQL non
implica che lo Spatial Index venga usato in modo consistente dal
data provider, sono due questioni del tutto scorrelate.

La query che ho usato per creare la view è questa:

SELECT p.the_geom, s.pkey_spu, s.ubicazione_prov, s.ubicazione_com,
s."ID_SPU", s."coord_X", s."coord_Y", s.mod_identcoord,
s.desc_modcoord, s.quota_slm, s.modo_quota, s.data_sito, s.note_sito
FROM "Sito_puntuale" s
LEFT JOIN ind_pu p ON p."ID_SPU" = s."ID_SPU"

se non mi passi anche le due CREATE TABLE con cui hai creato sia
"sito_puntuale" che "ind_pu" non posso dirti assolutamente nulla,
perche' mi stai nascondendo il datatype delle colonne, e soprattutto
mi stai nascondendo come sono state definite le PK, che e' l'informazione
assolutamente critica che serve per poter dare una valutazione motivata.

hint: se usi spatialite_gui c'e' una comodissima voce di menu
che ti permette di visualizzare direttamente la CREATE TABLE
con cui e' stata creata ciascuna tavola.

altrimenti lo puoi scoprire facilmente tramite questa query SQL:

SELECT sql
FROM sqlite_master
WHERE type = 'table' AND name = '<nome-della-tavola>';

e utilizzando l'opzione "create a view" sempre su db manager, dando
per scontato che la registrasse correttamente.

quando di fa debugging la prima regola aurea e' di non dare mai nulla
per scontato; occorre sempre verificare.
mi puoi cortesemente dire cosa ti ritorna questa query SQL ?

SELECT *
FROM views_geometry_column
WHERE f_view_name = '<nome-della-tua-view>';

Inoltre non mi è chiara una cosa al punto 3 della tua risposta: se la
spatial view deve contenere necessariamente un ROWID che corrisponde
al ROWID della spatial table, come posso costruire spatial views con
relazioni di 1 a N fra spatial table e tabelle semplici? In questo
caso i valori di ROWID si duplicheranno e non saranno più univoci.

il ROWID presente nella Spatial View non ha alcuna necessita' di essere
univoco a livello della View; serve solo ad assicurare che per ciascuna
Geometry della Spatial View il data provider possa risalire correttamente
alla voce corrispondente dello Spatial Index che supporta la tavola-madre
che fornisce le Geometries alla View.

ciao Sandro

3

Vedo che il campo geometrico è il primo della lista. Premetto che è solo un
dubbio, ma mi pare di ricordare, almeno in tempi passati che qgis avesse
difficoltà a gestire campi oltre quelli di geometria.
Ma forse è una cosa già risolta in versioni più recenti di qgis.

A.

Il Mar 5 Giu 2018, 12:17 Alessandro Ciali <alessandro.ciali@gmail.com> ha
scritto:

Ciao Sandro e ciao a tutti,
la spatial table che ho usato per la geometria funziona correttamente, l'ho
importata da uno shape in un db spatialite direttamente da DB manager in
QGIS.
La query che ho usato per creare la view è questa:

SELECT p.the_geom, s.pkey_spu, s.ubicazione_prov, s.ubicazione_com,
s."ID_SPU", s."coord_X", s."coord_Y", s.mod_identcoord, s.desc_modcoord,
s.quota_slm, s.modo_quota, s.data_sito, s.note_sito
FROM "Sito_puntuale" s
LEFT JOIN ind_pu p ON p."ID_SPU" = s."ID_SPU"

e utilizzando l'opzione "create a view" sempre su db manager, dando per
scontato che la registrasse correttamente.

Inoltre non mi è chiara una cosa al punto 3 della tua risposta: se la
spatial view deve contenere necessariamente un ROWID che corrisponde al
ROWID
della spatial table, come posso costruire spatial views con relazioni di 1
a N fra spatial table e tabelle semplici? In questo caso i valori di ROWID
si duplicheranno e non saranno più univoci.

Ad ora non posso condividere il db perchè i dati non sono di mia proprietà,
in caso vedo di reperire qualcosa con dati di mio possesso.

Grazie ancora per l'aiuto

Il giorno 4 giugno 2018 18:17, <a.furieri@lqt.it> ha scritto:

> On Mon, 4 Jun 2018 17:55:06 +0200, Alessandro Ciali wrote:
>
>> Ciao a tutti, sto riscontrando un comportamento assurdo con le viste
>> SpatiaLite. Ho creato una vista in un DB SpatiaLite tramite il DB
manager
>> di QGIS, unendo un file puntuale con una tabella tramite un semplice
join
>> con corrispondenza 1 a 1. purtroppo quando carico la vista in QGIS
2.14.17
>> mi succedono cose strane:
>> - se clicco con l'identify su una feature, mi vengono restituiti i
valori
>> corretti per i vari campi, ma non si apre la form, pur avendo spuntato
la
>> voce "auto open form" e individuando una sola feature
>> - se cerco di selezionare una o più features, mi vengono selezionati
anche
>> oggetti al di fuori del rettangolo di selezione, e magari non tutti gli
>> oggetti all'interno del riquadro vengono selezionati
>>
>> Il DB spatiaLite l'ho creato da QGIS (create new SpatiaLite Layer), la
>> vista dal DB manager. Le tabelle spaziali e quelle senza geometrie
>> sembrano
>> non avere nessun problema, vengono caricate e visualizzate correttamente
>> in
>> QGIS.
>>
>> tengo a precisare che la stessa procedura (ovviamente la query necessita
>> di
>> piccole correzioni) in Postgres mi restituisce viste perfettamente
>> funzionanti
>>
>> Qualcuno si è imbattuto in questo problema? Sbaglio qualcosa io o è un
>> problema di QGIS/SpatiaLite?
>>
>>
> ciao Alessandro,
>
> le Spatial Views di SpatiaLite hanno dei requisiti ben precisi e molto
> stringenti; se non li rispetti il caos e' assicurato.
>
> 1. la colonna Geometry della Spatial View deve corrispondenre esattamente
> ad una colonna Geometry di una delle Spatial Tables subordinate.
> 2. non sono ammesse funzioni SQL che possano alterare in qualsiasi
> modo la geometria originaria (in altre parole: ST_Transform,
> ST_Union, ST_Difference, ST_Buffer etc sono sempre rigorosamente
> proibite in una Spatial View.
> 3. la Spatial View deve necessariamente contenere una colonna di nome
> ROWID, che deve coincidere esattamente con il ROWID della Spatial
> Table che fornisce la Geometry.
>
> tutti queste restrizioni sono imposte dalla particolare struttura
> dello Spatial Index di SpatiaLite, che non ha nulla a che vedere
> con quella adottata da PostGIS.
> anche se entrambi producono risultati funzionali praticamente
> identici, l'architettura interna e' totalmente diversa.
> se la Spatial View non e' stata correttamente definita finisce
> che il suo Spatial Index di supporto "impazzisce", con risultati
> assolutamente paradossali ed apparentemente sconcertanti.
>
> dal quadro che ci fornisci, questo parrebbe proprio il tuo caso;
> molto verosimilmente la tua Spatial View si e' presa un po' troppa
> liberta' con lo Spatial Index, ed ora funziona in modo del tutto
> inattendibili (piu' o meno a casaccio).
>
> hint: prova a condividere la tua struttura dati, ed in particolare:
> - gli statements CREATE TABLE della/e Table(s) che utilizzi nella
> tua Spatial View
> - lo statement CREATE VIEW che hai usato
> - la registrazione della tua Spatial View che hai inserito nella
> meta-tavola "views_geometry_columns"
>
> se chiarisci meglio tutti questi aspetti potro' darti un parere
> piu' mirato e meglio argomentato, e magari anche qualche suggerimento
> utile per uscire dal pasticcio.
>
> 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

--
Alessandro Ciali
_______________________________________________
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