QspatiaLite 5.0.3
Locked
 
|
Buongiorno a tutti :-)
sto lavorando con Qgis 1.7.1 e plugin QspatiaLite
5.0.3. Ho un paio di domande che spero potranno trovare qui una
risposta:
1) Sto creando delle spatial views con il
plugin QSpatialite in modo da visualizzarle in Qgis come altrettanti layer.
Tutto va bene tranne il fatto che sembra io debba
necessariamente poi salvare la view che visualizzo in Qgis come shapefile
in modo da visualizzare correttamente la tabella degli attributi,
altrimenti (se cioe' mi accontentassi di avere il layer spatiaLite in QGIS)
avrei ERROR su ogni valori di ogni campo.
Nessun problema ma mi chiedevo se fosse
normale.
N.B. Per fare le query di creazione di una
vista spaziale ho scelto l'ultima opzione in basso (la settima) nel combo
box a destra della finestra di QspatiaLite;
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?
Grazie mille anticipatamente!
Massimo
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
ciao Massimo,
Il 24 gennaio 2012 14:26, Massimo Paone <[hidden email]> ha scritto: > Buongiorno a tutti :-) > > sto lavorando con Qgis 1.7.1 e plugin QspatiaLite 5.0.3. Ho un paio di > domande che spero potranno trovare qui una risposta: > > 1) Sto creando delle spatial views con il plugin QSpatialite in modo da > visualizzarle in Qgis come altrettanti layer. [cut] a questo non saprei rispondere: lascio ad altri piu' afferrati. > 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'. credo sia riconducibile al fatto che SQLite (su cui e' basato spatialite) non usa i tipi di dati, cioe' in ogni colonna di una tabella si puo' inserire qualsiasi dato. La dichiarazione del tipo di dato ha solo funzione estetica (nota: ho appreso queste nozioni dalla lettura dello spatialite cookbook :-)). spero aiuti ciao flavio _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
Ciao Flavio,
>> 1) Sto creando delle spatial views con il plugin QSpatialite in modo da >> visualizzarle in Qgis come altrettanti layer. > a questo non saprei rispondere: lascio ad altri piu' afferrati. Questa cosa funziona. Le Spatial views vengono visualizzate in Qgis correttamente (devo solo poi salvarle come shapefiles per avere una tabella attributi funzionante). >> credo sia riconducibile al fatto che SQLite (su cui e' basato spatialite) >> non usa i tipi di dati, cioe' in ogni colonna di una tabella si puo' >> inserire qualsiasi dato. La dichiarazione del tipo di dato ha solo >> funzione estetica (nota: ho appreso queste nozioni dalla lettura dello >> spatialite cookbook :-)). Si', ho letto anch'io l'ottimo cookbook. Solo, ci dev'essere un modo per avere un numerico in output se faccio una somma su un numerico in input.... Altrimenti in QGIS non posso visualizzare il campo ad esempio con dei simboli proporzionali. Certo, potrei creare un altro campo numerico e copiarci dentro i dati, ma mi sembra un passaggio eccessivo. Ci dev'essere qualcosa, tra le mille cose che non so' ancora fare, che mi e' oscuro. Grazie comunque. Massimo ----- Original Message ----- From: "flavio rigolon" <[hidden email]> To: "Massimo Paone" <[hidden email]> Cc: <[hidden email]> Sent: Wednesday, January 25, 2012 8:33 AM Subject: Re: [Gfoss] QspatiaLite 5.0.3 ciao Massimo, Il 24 gennaio 2012 14:26, Massimo Paone <[hidden email]> ha scritto: > Buongiorno a tutti :-) > > sto lavorando con Qgis 1.7.1 e plugin QspatiaLite 5.0.3. Ho un paio di > domande che spero potranno trovare qui una risposta: > > 1) Sto creando delle spatial views con il plugin QSpatialite in modo da > visualizzarle in Qgis come altrettanti layer. [cut] a questo non saprei rispondere: lascio ad altri piu' afferrati. > 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'. credo sia riconducibile al fatto che SQLite (su cui e' basato spatialite) non usa i tipi di dati, cioe' in ogni colonna di una tabella si puo' inserire qualsiasi dato. La dichiarazione del tipo di dato ha solo funzione estetica (nota: ho appreso queste nozioni dalla lettura dello spatialite cookbook :-)). spero aiuti ciao flavio _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
In reply to this post by Massimo Paone
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? > _____________ PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). PRIVACY Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE). _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
In reply to this post by Massimo Paone
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 :-( 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? > _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
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 :-( > > 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? > > > _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
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, [hidden email] 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
|
|
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 :-D 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 :-P 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' ;-) ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |