Ciao a tutti,
ho notato un piccolo problema con l’accoppiata QGIS-Spatialite.
Se creo un nuovo layer geometrico spatialite e successivamente aggiungo dei campi utilizzando:
ALTER TABLE xxx ADD column yyy TEXT
la nuova colonna non viene vista da QGIS. Ho provato facendo un vacuum del DB, riavviando QGIS ma nisba.
Qualcuno conferma il problema o è una cosa mia locale ?
grazie mille
Luca
Aggiungo che ho notato che la tavola vectro_layers_field_infos in effetti non è stata aggiornata con i nuovi campi. Devo farlo manualmente ?
Luca
Il giorno 17 luglio 2014 14:14, Luca Lanteri <mescal72@gmail.com> ha scritto:
Ciao a tutti,
ho notato un piccolo problema con l’accoppiata QGIS-Spatialite.
Se creo un nuovo layer geometrico spatialite e successivamente aggiungo dei campi utilizzando:ALTER TABLE xxx ADD column yyy TEXT
la nuova colonna non viene vista da QGIS. Ho provato facendo un vacuum del DB, riavviando QGIS ma nisba.
Qualcuno conferma il problema o è una cosa mia locale ?grazie mille
Luca
probabilmente legato a questo:
http://hub.qgis.org/issues/8923
Il giorno 17 luglio 2014 14:17, Luca Lanteri <mescal72@gmail.com> ha scritto:
Aggiungo che ho notato che la tavola vectro_layers_field_infos in effetti non è stata aggiornata con i nuovi campi. Devo farlo manualmente ?
Luca
Il giorno 17 luglio 2014 14:14, Luca Lanteri <mescal72@gmail.com> ha scritto:
Ciao a tutti,
ho notato un piccolo problema con l’accoppiata QGIS-Spatialite.
Se creo un nuovo layer geometrico spatialite e successivamente aggiungo dei campi utilizzando:ALTER TABLE xxx ADD column yyy TEXT
la nuova colonna non viene vista da QGIS. Ho provato facendo un vacuum del DB, riavviando QGIS ma nisba.
Qualcuno conferma il problema o è una cosa mia locale ?grazie mille
Luca
Il 17/07/2014 14:29, Luca Lanteri ha scritto:
probabilmente legato a questo:
che dice una triste verita': il supporto a SpatiLite in QGIS ha bisogno di cure ed
affetto; la situazione si e' venuta complicando, fra versioni diverse, vari modi di
accedere al DB, duplicazione di plugins, ecc., e nessuno ha affrontato il problema
alla radice, mettendo a pulito il tutto.
volontari?
saluti.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
On Thu, 17 Jul 2014 14:14:13 +0200, Luca Lanteri wrote:
Ciao a tutti,
ho notato un piccolo problema con l'accoppiata QGIS-Spatialite.
Se creo un nuovo layer geometrico spatialite e successivamente
aggiungo dei campi utilizzando:ALTER TABLE xxx ADD column yyy TEXT
la nuova colonna non viene vista da QGIS. Ho provato facendo un vacuum
del DB, riavviando QGIS ma nisba.
Qualcuno conferma il problema o è una cosa mia locale ?
Ciao Luca,
il dataprovider di QGIS impone l'obbligo di comunicare in
anticipo svariate informazioni relative al layer al momento
in cui viene aperto / connesso:
- il tipo delle geometrie
- il relativo srid
- il total extent
- il numero complessivo delle features
- l'esatto data-type per ciascuna colonna/attributo; ed e'
proprio qua che casca l'asino 
notoriamente SQLite e' stato volutamente progettato ed
implementato in modo tale che tutte le colonne (eccetto
quelle usate per le Primary Keys) siano assolutamente
"typeless"; insomma il modello concettuale alla base di
SQLite e quello supportato da QGIS qua fanno completamente
a pugni, siamo esattamente agli antipodi.
conseguenza pratica:
--------------------
per riuscire a passare a QGIS tutte le informazioni di
cui ha tassativamente bisogno per riuscire a gestire il
layer, occorre fare un "full tablescan" esplorativo
(lettura di tutta la tavola dalla prima fino all'ultima
riga), in modo tale da valutare dinamicamente i contenuti
effettivi.
ovviamente un approccio cosi' semplicistico funziona bene
solo per datasets "giocattolo" (max qualche migliaia di
righe); se provi ad aprire un dataset "tosto" con milioni
di righe il "full tablescan" preliminare porterebbe via
sicuramente molti minuti ... forse addirittura decine di
minuti ... e questo accadrebbe tutte le volte che QGIS
prova a stabilire una connessione con quella tavola/layer.
approccio piu' "smart":
-----------------------
SpatiaLite gestisce semi-automaticamente tutta una serie
di meta-tavole che contengono dei riepiloghi statistici;
in questo modo basta salvare una volta per tutte il
risultato del "full tablescan", e tutte le connessioni
successive avverrano in modo istantaneo, anche per tavole
contenenti milioni di righe.
per rendere ancora piu' "smart" l'approccio, spatialite
intercetta tramite triggers tutti gli eventi SQL che possono
alterare il contenuto di una tavola (INSERT/UPDATE/DELETE);
e quindi e' perfettamente in grado di sapere se/quando le
statistiche "congelate" siano ancora valide oppure richiedano
di essere aggiornate.
QGIS comunque adotta sempre l'approccio OPTIMISTIC: se
le statistiche esistono, usa comunque quel che trova fidandosi
che sia sempre valido; se vuoi puoi comunque chiedere
di aggiornare le statistiche non piu' valide; c'e' un
apposito pulsantino nel dialog box di connessione dei layers.
------------------
e finalmente arriviamo all'ALTER TABLE ADD COLUMN
a differenza di INSERT/UPDATE/DELETE, questo evento non
e' intercettabile tramite triggers SQL.
e quindi le statistiche continuano ad apparire valide,
anche se di fatto non coprono la colonna aggiunta in
seguito.
eccoti spiegato perche' non riesci a vedere la nuova
colonna che hai aggiunto: accade perche' non e' descritta
nel riepilogo statistico, mentre il dataprovider di
QGIS si basa solo sui riepiloghi per determinare
quale sia la struttura della tavola layer.
soluzione:
----------
p.es. puoi usare la versione test di spatialite_gui
http://www.gaia-gis.it/gaia-sins/windows-bin-x86-test/spatialite_gui-1.8,0-devel-win.x86.7z
dopo di che esegui questi due statements SQL:
SELECT InvalidateLayerStatistics('mio_layer');
SELECT UpdateLayerStatistics('mio_layer');
se invece hai a disposizione solo versioni precedenti
che non supportano InvalidateLayerStatistics(), puoi
comunque aggirare l'ostacolo in quest'altro modo:
UPDATE geometry_columns_statistics
SET last_verified = NULL
WHERE f_table_name = 'mio_layer';
SELECT UpdateLayerStatistics('mio_layer');
in entrambi i casi otterrai sempre il medesimo
effetto; tutte le statistiche di supporto per
quella tavola/layer verranno prima invalidate,
e quindi successivamente aggiornate.
e finalmente anche la colonna che hai aggiunto
con la ALTER TABLE ADD COLUMN risultera' visibile
anche a QGIS
ciao Sandro
Il 17/07/2014 14:50, a.furieri@lqt.it ha scritto:
p.es. puoi usare la versione test di spatialite_gui
http://www.gaia-gis.it/gaia-sins/windows-bin-x86-test/spatialite_gui-1.8,0-devel-win.x86.7zdopo di che esegui questi due statements SQL:
SELECT InvalidateLayerStatistics('mio_layer');
SELECT UpdateLayerStatistics('mio_layer');se invece hai a disposizione solo versioni precedenti
che non supportano InvalidateLayerStatistics(), puoi
comunque aggirare l'ostacolo in quest'altro modo:UPDATE geometry_columns_statistics
SET last_verified = NULL
WHERE f_table_name = 'mio_layer';
SELECT UpdateLayerStatistics('mio_layer');
Basta eseguire questo in una qualsiasi shell SQL, o c'e' bisogno di spatialite_gui?
Saluti, e grazie.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
Grazie Alessandro e Paolo per le risposte sempre esustive.
Io alla fine ho risolto con:
UPDATE geometry_columns_statistics set last_verified = 0;
SELECT UpdateLayerStatistics(‘geometry_table_name’);
lanciato da una qualsiasi shell
non so quanto corretto formalmente ma fuziona.
Il giorno 17 luglio 2014 14:55, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 17/07/2014 14:50, a.furieri@lqt.it ha scritto:
p.es. puoi usare la versione test di spatialite_gui
http://www.gaia-gis.it/gaia-sins/windows-bin-x86-test/spatialite_gui-1.8,0-devel-win.x86.7zdopo di che esegui questi due statements SQL:
SELECT InvalidateLayerStatistics(‘mio_layer’);
SELECT UpdateLayerStatistics(‘mio_layer’);se invece hai a disposizione solo versioni precedenti
che non supportano InvalidateLayerStatistics(), puoi
comunque aggirare l’ostacolo in quest’altro modo:UPDATE geometry_columns_statistics
SET last_verified = NULL
WHERE f_table_name = ‘mio_layer’;
SELECT UpdateLayerStatistics(‘mio_layer’);Basta eseguire questo in una qualsiasi shell SQL, o c’e’ bisogno di spatialite_gui?
Saluti, e grazie.–
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
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.
666+40 iscritti al 5.6.2014
On Thu, 17 Jul 2014 14:55:37 +0200, Paolo Cavallini wrote:
Basta eseguire questo in una qualsiasi shell SQL, o c'e' bisogno di
spatialite_gui?
come per tutte le funzioni SQL non importa minimamente
quale tool di frontend si usa.
l'unica cosa rilevante e' che sotto ci sia la libreria
della versione giusta, cioe' libspatialite 4.2.0
ciao Sandro
On Thu, 17 Jul 2014 14:58:07 +0200, Luca Lanteri wrote:
Grazie Alessandro e Paolo per le risposte sempre esustive.
Io alla fine ho risolto con:
UPDATE geometry_columns_statistics set last_verified = 0;
SELECT UpdateLayerStatistics('geometry_table_name');lanciato da una qualsiasi shell
non so quanto corretto formalmente ma fuziona.
certo che funziona; sostanzialmente e' equivalente
a questa che ti suggerivo per le vecchie versioni
che non supportano la InvalidateLayerStatistics()
UPDATE geometry_columns_statistics
SET last_verified = NULL
WHERE f_table_name = 'mio_layer';
SELECT UpdateLayerStatistics('mio_layer');
giusto per cercare il peluzzo nell'uovo; la tua
versione usa zero invece di NULL (non e' formalmente
pulistissimo, ma comunque funziona)
la differenza sostanziale e' che la tua "ammazza"
tutte le statistiche, non solo quella della
tavola incriminata.
se tu puta caso ti trovassi a lavorare p.es. con
un DB da 5GB e passa, la differenza nel siccessivo
tempo di ricalcolo delle statistiche potrebbe
anche essere un'oretta abbondante 
ciao Sandro
ottimo, mi segno la query aggiornata!
La mia versione l’avevo trovata in http://hub.qgis.org/issues/8923.
grazie mille
Luca
Il giorno 17 luglio 2014 15:43, <a.furieri@lqt.it> ha scritto:
On Thu, 17 Jul 2014 14:58:07 +0200, Luca Lanteri wrote:
Grazie Alessandro e Paolo per le risposte sempre esustive.
Io alla fine ho risolto con:
UPDATE geometry_columns_statistics set last_verified = 0;
SELECT UpdateLayerStatistics(‘geometry_table_name’);lanciato da una qualsiasi shell
non so quanto corretto formalmente ma fuziona.certo che funziona; sostanzialmente e’ equivalente
a questa che ti suggerivo per le vecchie versioni
che non supportano la InvalidateLayerStatistics()UPDATE geometry_columns_statistics
SET last_verified = NULL
WHERE f_table_name = ‘mio_layer’;
SELECT UpdateLayerStatistics(‘mio_layer’);giusto per cercare il peluzzo nell’uovo; la tua
versione usa zero invece di NULL (non e’ formalmente
pulistissimo, ma comunque funziona)
la differenza sostanziale e’ che la tua “ammazza”
tutte le statistiche, non solo quella della
tavola incriminata.
se tu puta caso ti trovassi a lavorare p.es. con
un DB da 5GB e passa, la differenza nel siccessivo
tempo di ricalcolo delle statistiche potrebbe
anche essere un’oretta abbondanteciao 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.
666+40 iscritti al 5.6.2014
Concordo a pieno con te!
Spatialite è per me una componente fondamentale di QGIS: in diversi casi l’utilizzo di SL per me è stato risolutivo e non ho trovato strumento migliore per affrontare determinati problemi. Recentemente, purtroppo, mi pare che però il supporto di SL in QGIS sia diminuito rispetto al passato. Come fai notare tu ci sono almeno 3-4 strumenti diversi per gestire i dati in SL ed ognuno fa bene alcune cose e peggio altre. DB Manager e Spatialite-gui in questo momento sono il mio riferimento. Sarebbe interessante riuscire a fondere insieme i due strumenti in un unico strumento potente e flessibile.
Ci sono poi diverse cose che richiedono una conoscenza sopra la media per utilizzare SL con profitto: il mio problema ne è un esempio lampante. Un problema tutto sommato banale mi ha portato via parecchio tempo. Per fortuna che in lista il supporto è sempre on-line !
Detto questo come al solito servirebbero tempo e risorse (umane ed economiche) per lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque interessante capire se sta ancora bollendo qualcosa in pentola e se c’è ancora interesse a lavorare su questi temi.
Qualcuno ha news in merito ?
a presto
Luca
Il giorno 17 luglio 2014 14:32, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Il 17/07/2014 14:29, Luca Lanteri ha scritto:
probabilmente legato a questo:
che dice una triste verita’: il supporto a SpatiLite in QGIS ha bisogno di cure ed
affetto; la situazione si e’ venuta complicando, fra versioni diverse, vari modi di
accedere al DB, duplicazione di plugins, ecc., e nessuno ha affrontato il problema
alla radice, mettendo a pulito il tutto.
volontari?
saluti.Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
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.
666+40 iscritti al 5.6.2014
Il 18/07/2014 11:56, Luca Lanteri ha scritto:
Concordo a pieno con te!
Detto questo come al solito servirebbero tempo e risorse (umane ed economiche) per
lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque interessante capire
se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a lavorare su
questi temi.
Qualcuno ha news in merito ?
Non sono a conoscenza di investimenti significativi in questo senso, purtroppo.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
.... a parte una serie di novità presenti nella 4.2
Luca,
dai un'occhiata alla pagina
https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=version+4.2.0
ai "new XML processing tools" (pensa alla possibilità di importare in
DBMS un qualsiasi XML, es.: uno stesso progetto QGS, poterlo
modificare e poi riesportare).
oppure alla pagina
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0+functions
al "building/updating a MetaCatalog" (per derivare informazioni su
tutti i valori assunti da qualsiasi attributo di una qualsiasi tabella
del tuo DBMS).
Un'altro strumento interessante è il Dataseltzer
https://www.gaia-gis.it/fossil/dataseltzer/index
e
https://www.gaia-gis.it/fossil/dataseltzer/wiki?name=user_guide
ciao,
Maurizio
Il 18/07/14, Paolo Cavallini<cavallini@faunalia.it> ha scritto:
Il 18/07/2014 11:56, Luca Lanteri ha scritto:
Concordo a pieno con te!
Detto questo come al solito servirebbero tempo e risorse (umane ed
economiche) per
lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque
interessante capire
se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a
lavorare su
questi temi.
Qualcuno ha news in merito ?Non sono a conoscenza di investimenti significativi in questo senso,
purtroppo.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
_______________________________________________
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.
666+40 iscritti al 5.6.2014
Grazie per le notizie positive su SL.
Per chiarire: la mia valutazione si riferiva all'integrazione QGIS-SL, non a questo
secondo. Credo che una migliore integrazione sarebbe molto utile per tutti.
Saluti.
Il 18/07/2014 20:41, Maurizio Trevisani ha scritto:
.... a parte una serie di novità presenti nella 4.2
Luca,
dai un'occhiata alla pagina
https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=version+4.2.0
ai "new XML processing tools" (pensa alla possibilità di importare in
DBMS un qualsiasi XML, es.: uno stesso progetto QGS, poterlo
modificare e poi riesportare).oppure alla pagina
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0+functions
al "building/updating a MetaCatalog" (per derivare informazioni su
tutti i valori assunti da qualsiasi attributo di una qualsiasi tabella
del tuo DBMS).Un'altro strumento interessante è il Dataseltzer
https://www.gaia-gis.it/fossil/dataseltzer/index
e
https://www.gaia-gis.it/fossil/dataseltzer/wiki?name=user_guideciao,
MaurizioIl 18/07/14, Paolo Cavallini<cavallini@faunalia.it> ha scritto:
Il 18/07/2014 11:56, Luca Lanteri ha scritto:
Concordo a pieno con te!
Detto questo come al solito servirebbero tempo e risorse (umane ed
economiche) per
lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque
interessante capire
se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a
lavorare su
questi temi.
Qualcuno ha news in merito ?Non sono a conoscenza di investimenti significativi in questo senso,
purtroppo.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
_______________________________________________
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.
666+40 iscritti al 5.6.2014
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
Ciao Maurizio, in effetti anch’io notavo (e mi chiedevo il motivo) del rallentamento nell’integrazione di SL in QGIS, non tanto nello sviluppo di SL stesso che da quanto mi dici tu, e già mi diceva Alessandro tempo fa, sembra vispo !
Aiutami a capire, da utente di SL alle prime armi quale sono: con gli “XML processing tools” non solo puoi fare il parsing di un file xml per controllarne la validità, ma puoi anche scomporre il file xml in un database, modificarlo con sql e poi riesportarlo in xml ? Oppure ho capito male ?
grazie mille delle info
Luca
Il giorno 18 luglio 2014 20:41, Maurizio Trevisani <maurizio.trevisani@gmail.com> ha scritto:
… a parte una serie di novità presenti nella 4.2
Luca,
dai un’occhiata alla pagina
https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=version+4.2.0
ai “new XML processing tools” (pensa alla possibilità di importare in
DBMS un qualsiasi XML, es.: uno stesso progetto QGS, poterlo
modificare e poi riesportare).oppure alla pagina
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0+functions
al “building/updating a MetaCatalog” (per derivare informazioni su
tutti i valori assunti da qualsiasi attributo di una qualsiasi tabella
del tuo DBMS).Un’altro strumento interessante è il Dataseltzer
https://www.gaia-gis.it/fossil/dataseltzer/index
e
https://www.gaia-gis.it/fossil/dataseltzer/wiki?name=user_guideciao,
MaurizioIl 18/07/14, Paolo Cavallini<cavallini@faunalia.it> ha scritto:
Il 18/07/2014 11:56, Luca Lanteri ha scritto:
Concordo a pieno con te!
Detto questo come al solito servirebbero tempo e risorse (umane ed
economiche) per
lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque
interessante capire
se sta ancora bollendo qualcosa in pentola e se c’è ancora interesse a
lavorare su
questi temi.
Qualcuno ha news in merito ?Non sono a conoscenza di investimenti significativi in questo senso,
purtroppo.
Saluti.Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
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.
666+40 iscritti al 5.6.2014
On Tue, 22 Jul 2014 00:01:22 +0200, Luca Lanteri wrote:
Aiutami a capire, da utente di SL alle prime armi quale sono: con gli
"XML processing tools" non solo puoi fare il parsing di un file xml
per controllarne la validità, ma puoi anche scomporre il file xml in
un database, modificarlo con sql e poi riesportarlo in xml ? Oppure ho
capito male ?
Luca, hai capito perfettamente bene.
grazie agli investimenti di Regione Toscana nell'ultimo anno
spatialite si e' notevolmente irrobustita e sta diventato un
tool discretamente potente e certamente molto flessibile per
la gestione avanzata e sofisticata di datasets decisamente
pesanti ed assai complessi (svariate decine di GB, centinai
di layers, milioni e milioni di features, regole complesse
da rispettare e verificare etc)
paradossalmente SpatiaLite sta anche attraversando un periodo
decisamente felice sul versante delle nuove piattaforme ultra
light (Android etc), dove evidentemente le sue doti di estrema
leggerezza e semplicita' rendono facile per moltissimi
sviluppatori di apps (anche completamente a digiuno dei
rudimenti piu' basilari del GIS "classico") affrontare con
successo quelle problematiche di tipo GeoSpatial che stanno
diventando sempre piu' pervasive nei settori piu' disparati
anche grazie alla sempre crescente disponibiiita' di
GeoOpenData.
insomma, i due estremi opposti in questo caso si toccano;
la medesima architettura pare essere ragionevolmente in
grado di adattarsi flessibilmente tanto alle trappolette
portatili dotate di risorse HW misurate col contagocce
quanto agli ambienti piu' muscolosi tipici delle workstations
e dei servers.
venendo allo specifico XML
gia' fin dalla precedente versione 4.1.0 spatialite ha
pienamente integrato la poderosa libxml2, e quindi ora
offre molti strumenti completamente SQL-based utili per
lavorare con documenti XML generici
p.es. e' supportata pienamente la validazione formale dei
documenti XML rispetto agli schemi XSD, e' ben integrato
il linguaggio standard XPATH per l'analisi degli alberi
XML etc
in particolare vengono supportati in modo piu' specifico
e mirato i formati XML-like di maggior interesse GeoSpatial:
- metadati ISO 19115 (Inspire)
- stili SLD/SE (RasterSymbolizer etc)
- reader WFS e WMS
i nuovi XML tools introdotti dalla 4.2.0 (in via di rilascio
a brevissimo) ora consentono anche di mappare completamente
un qualsiasi documento XML (ma anche una serie di documenti,
se sono tutti basati sul medesimo schema XSD) all'interno
di un unico DBMS sqlite/spatialite.
dopo di che a partire da questo punto ciascuno sara' poi
evidentemente libero di sfruttare a fondo tutte le infinite
potenzialita' di elaborazione tipiche del linguaggio SQL
insomma, avendo come pre-requisito i necessari skills SQL,
diventa poi ragionevolmente semplice scriversi tutti gli
SQL scripts necessari per validare, verificare, correggere,
integrare etc il dataset di partenza; fino eventualmente ad
arrivare a riespotare nuovamente il DBMS con i contenuti
finali sotto forma di un nuovo documento XML corrispondente
allo schema di origine.
se a tutto questo ci aggiungi poi il fatto che spatialite
integra direttamente al suo interno tutta una serie di
strumenti che consentono di esportare ed importare molti
tra i formati dati di piu' ampia diffusione (SHP, DBF, XLS,
DXF, TXT, WFS etc) ecco che alla fine abbiamo una piattaforma
autonoma, leggera ma ragionevolmente completa che consente
di affrontare con successo le piu' svariate categorie di data
processing (sia Geo che non-Geo) basandosi esclusivamente su
SQL come linguaggio standard.
scordati del tutto il mondo "vita facile" tipico degli ambienti
GUI click-click-click; qua siamo a pieno titolo in un ambiente
tipicamente "da sviluppatori" e che richiede sicuramente robuste
competenze di tipo informatico generale prima ancora che di
tipo piu' speficamente GeoSpatial.
ma che magari ti fara' scoprire quanto e' possibile spingersi
lontano utilizzando esclusivamente le mille potenzialita' che
ti offre il portentoso SQL (probabilmente il piu' bistrattato
ed il meno compreso tra tutti i linguaggi di prgrammazione che
siano mai stati inventati)
ciao Sandro