[Gfoss] QspatiaLite 5.0.3

Grazie per l'aiuto Sigfrido.

Purtroppo pero' il problema non si risolve neanche con l'operatore CAST. Il campo di uscita continua ad essere non specificato, impedendomi una visualizzazione corretta in QGIS :frowning:

Massimo

Ciao Massimo,

prova con la conversione di tipo (casting) esplicita, ovvero

CAST(espressione AS INTEGER)

Sig

Il giorno mar, 24/01/2012 alle 14.26 +0100, Massimo Paone ha scritto:

2) Una delle query che sto sperimentando (un raggruppamento su
posizioni geografiche in modo da avere in uscita una somma di una
variabile numerica per ogni posizione) a partire da una join tra 3
tabelle di input, fornisce in output una view spaziale corretta ma con
un problemino: il campo su cui sommo non e' piu' un numerico (INTEGER)
come in partenza, bensi' non ha tipo specificato, e non capisco
perche'. Forse c'e' un modo per forzare a numerico questo risultato?

Ciao Massimo,

in effetti cercando in rete sembra che QGIS non sia l'unico ad avere
problemi con i tipi per i campi calcolati nelle view sqlite.

Tuttavia con ogr2ogr (versione di sviluppo) è possibile convertire in
shapefile la vista senza perdita di informazioni:

ogr2ogr -overwrite -f "ESRI ShapeFile" -a_srs EPSG:3003 -sql "select
OGC_FID as id, somma, GEOMETRY from myview" . db.sqlite -nln myview

La vista myview è definita come
CREATE VIEW myview as
select ogc_fid, geometry, cast(isolatoid + civicoid as integer) as somma
from carrai

Il campo somma figura correttamente come numerico(integer) nello
shapefile.

Ho provato a questo punto ad aggiungere la vista in QGIS come layer OGR
(file, tipo spatialite) anziché come layer spatialite, ma senza
successo, permangono gli stessi problemi.

Dal momento che GDAL/OGR lavora correttamente con la view e QGIS no,
penso ci siano gli estremi per aprire un ticket, però lascio la parola
ai più esperti.

Buon lavoro

Sig

Il giorno mer, 25/01/2012 alle 14.19 +0100, Massimo Paone ha scritto:

Grazie per l'aiuto Sigfrido.

Purtroppo pero' il problema non si risolve neanche con l'operatore CAST. Il
campo di uscita continua ad essere non specificato, impedendomi una
visualizzazione corretta in QGIS :frowning:

Massimo

> Ciao Massimo,

> prova con la conversione di tipo (casting) esplicita, ovvero

> CAST(espressione AS INTEGER)

> Sig

Il giorno mar, 24/01/2012 alle 14.26 +0100, Massimo Paone ha scritto:
>
> 2) Una delle query che sto sperimentando (un raggruppamento su
> posizioni geografiche in modo da avere in uscita una somma di una
> variabile numerica per ogni posizione) a partire da una join tra 3
> tabelle di input, fornisce in output una view spaziale corretta ma con
> un problemino: il campo su cui sommo non e' piu' un numerico (INTEGER)
> come in partenza, bensi' non ha tipo specificato, e non capisco
> perche'. Forse c'e' un modo per forzare a numerico questo risultato?
>

Ulteriore controllo: l'uso dell'operatore CAST non ha influenza
sull'output con OGR2OGR, ovvero GDAL riconosce correttamente il tipo
anche senza ricorrere all'uso di CAST nella view.

Sig

Il giorno gio, 26/01/2012 alle 11.57 +0100, Luca Sigfrido Percich ha
scritto:

Tuttavia con ogr2ogr (versione di sviluppo) è possibile convertire in
shapefile la vista senza perdita di informazioni:

ogr2ogr -overwrite -f "ESRI ShapeFile" -a_srs EPSG:3003 -sql "select
OGC_FID as id, somma, GEOMETRY from myview" . db.sqlite -nln myview

La vista myview è definita come
CREATE VIEW myview as
select ogc_fid, geometry, cast(isolatoid + civicoid as integer) as somma
from carrai

Giusto un paio di chiarimenti di base per quanto
riguarda la corretta gestione delle Spatial Views
di SpatiaLite; basati su di un esempio facilmente
replicabile, cosi' tutto e' piu' chiaro (spero ...)
useremo spatialite_gui per predisporre il DB.

a) importiamo gli SHP dei confini amministativi ISTAT:

http://www.istat.it/it/files/2011/04/reg2011.zip
http://www.istat.it/it/files/2011/04/prov2011.zip
n.b.: usiamo regioni e province perche' sono meno
numerose, e la query girera' snella e veloce senza
richiedere ottimizzazioni complicate.

b) a questo punto creiamo la VIEW:
   
CREATE VIEW regioni AS
SELECT r.ROWID AS ROWID, r.cod_reg AS cod_reg,
  r.nome_reg AS nome_reg, Count(*) AS nro_prov,
  r.Geometry AS Geometry
FROM reg2011 AS r
JOIN prov2011 AS p ON (p.cod_reg = r.cod_reg)
GROUP BY r.cod_reg;

*** un paio di punti da notare con cura:
*** SQLite esige che tutte le colonne della VIEW
*** abbiano un nome esplicito [.. AS cod_reg]
*** puo' sembrare sciocco, ma solo in questo modo
*** si ottiene una definizione "pulita".
***
*** ed occorre necessariamente inserire (esplicitamente)
*** il riferimento al ROWID della tavola che contiene
*** la Geometria (altrimenti SpatiaLite non sara' poi
*** in grado di utilizzare lo Spatial Index, se esiste)

c) infine occorre registrare la VIEW nella apposita tavola
   di metadati (views_geometry_columns):

INSERT INTO views_geometry_columns
  (view_name, view_geometry, view_rowid,
   f_table_name, f_geometry_column)
VALUES ('province', 'Geometry', 'ROWID',
  'reg2011', 'Geometry');

d) fatto: potete finalmente aprire QGIS e connettere la
   VIEW "regioni" che apparira' come qualsiasi altro layer.

====

per quanto mi riguarda personalmente non ho idea se i vari
plugin per QGIS come Qspatialite e/o DB Manager implementino
il supporto che consente di definire nel modo corretto le
Spatial Views di SpatiaLite.
eventualmente contattate i rispettivi sviluppatori e/o
aprite un ticket su QGIS.

ciao Sandro

Ciao Sandro,

grazie per i chiarimenti!

Se dopo aver caricato la vista regioni in QGIS (occhio che nel tuo
codice usi 'province' invece di 'regioni' nella insert in
views_geometry_columns come nome della view) visualizzi le proprietà del
layer, noterai che la colonna nro_prov ha Type vuoto.

Invece OGRINFO funziona correttamente.
ogrinfo -so istat.sqlite regioni
ti dirà, in fondo, nro_prov: Integer (0.0)

Se provi a modificare la vista aggiungendo un cast:
...
  r.nome_reg AS nome_reg, cast(Count(*) as float) AS nro_prov,
...

QGIS risponde sempre con type vuoto per n_prov, ogrinfo invece dice
giustamente:

nrro_prov: real(0.0)

Ma a parte questo la tavola degli attributi del layer si vede
correttamente.

L'altro errore riportato in precedenza (i valori dei campi "ERROR") era
nel mio caso dovuto ad un non corretto popolamento di
views_geometry_columns (che tra l'altro ho scoperto ora essere case
sensitive, ovvero se metti geometry invece di GEOMETRY la vista non
viene elencata in QGIS).

Grazie ancora e buon lavoro

Sig

Il giorno gio, 26/01/2012 alle 12.57 +0100, a.furieri@lqt.it ha scritto:

Giusto un paio di chiarimenti di base per quanto
riguarda la corretta gestione delle Spatial Views
di SpatiaLite; basati su di un esempio facilmente
replicabile, cosi' tutto e' piu' chiaro (spero ...)
useremo spatialite_gui per predisporre il DB.

a) importiamo gli SHP dei confini amministativi ISTAT:

http://www.istat.it/it/files/2011/04/reg2011.zip
http://www.istat.it/it/files/2011/04/prov2011.zip
n.b.: usiamo regioni e province perche' sono meno
numerose, e la query girera' snella e veloce senza
richiedere ottimizzazioni complicate.

b) a questo punto creiamo la VIEW:
   
CREATE VIEW regioni AS
SELECT r.ROWID AS ROWID, r.cod_reg AS cod_reg,
  r.nome_reg AS nome_reg, Count(*) AS nro_prov,
  r.Geometry AS Geometry
FROM reg2011 AS r
JOIN prov2011 AS p ON (p.cod_reg = r.cod_reg)
GROUP BY r.cod_reg;

*** un paio di punti da notare con cura:
*** SQLite esige che tutte le colonne della VIEW
*** abbiano un nome esplicito [.. AS cod_reg]
*** puo' sembrare sciocco, ma solo in questo modo
*** si ottiene una definizione "pulita".
***
*** ed occorre necessariamente inserire (esplicitamente)
*** il riferimento al ROWID della tavola che contiene
*** la Geometria (altrimenti SpatiaLite non sara' poi
*** in grado di utilizzare lo Spatial Index, se esiste)

c) infine occorre registrare la VIEW nella apposita tavola
   di metadati (views_geometry_columns):

INSERT INTO views_geometry_columns
  (view_name, view_geometry, view_rowid,
   f_table_name, f_geometry_column)
VALUES ('province', 'Geometry', 'ROWID',
  'reg2011', 'Geometry');

d) fatto: potete finalmente aprire QGIS e connettere la
   VIEW "regioni" che apparira' come qualsiasi altro layer.

====

per quanto mi riguarda personalmente non ho idea se i vari
plugin per QGIS come Qspatialite e/o DB Manager implementino
il supporto che consente di definire nel modo corretto le
Spatial Views di SpatiaLite.
eventualmente contattate i rispettivi sviluppatori e/o
aprite un ticket su QGIS.

ciao Sandro

On Thu, 26 Jan 2012 14:21:09 +0100, Luca Sigfrido Percich wrote

Se dopo aver caricato la vista regioni in QGIS ... visualizzi le
proprietà del layer, noterai che la colonna nro_prov ha Type vuoto.

e questa e' una delle anomalie / specificita' tipiche
di SQLite :smiley:
in questo DBMS le colonne non hanno nessun data-type;
le dichiarazioni di data-type hanno solo un mero
valore "cosmetico", ma non hanno nessuna conseguenza
funzionale (tranne che nel caso delle Primary Keys).

quindi l'unico criterio solido ed affidabile per
determinare il data-type di una colonna e' quello
di farsi una bella query esplorativa basata sui
valori reali, non sulle dichiarazioni.
e.g. (sempre tornando al solito esempio di prima):

SELECT DISTINCT TypeOf(cod_reg),
  TypeOf(nome_reg), TypeOf(nro_prov)
FROM regioni;

... e ti lascio immaginare la velocita' quando
la tavola contiene svariati milioni di righe :stuck_out_tongue:

il data-provider SpatiaLite per QGIS prova semplicemente
a determinare il data-type in via speditiva, cioe'
analizzando la dichiarazione formale della table/view:

PRAGMA table_info(regioni);

ma come puoi facilmente verificare con spatialite_gui,
in questo caso la colonna "nro_prov" non ha nessun
data-type, proprio in quanto corrisponde al risultato
di una funzione di aggregazione.
in altre parole: SQLite e' in grado di andare a
ripescarsi la definizione iniziale della colonna che
appare in una View se la colonna appartiene ad una tavola.
ma se una colonna deriva da un calcolo/espressione e/o
funzione, allora il data-type resta graziosamente
indefinito.

e con questo spero di avere soddisfatto almeno alcune
delle tue piu' morbose curiosita' :wink:

ciao Sandro