"Libro-Libero"
Incontriamo (
virtualmente ) Alessandro Furieri, Markus Neteler e Paolo
Cavallini, autori del libro "GIS Open Source - GRASS GIS,
Quantum GIS e SpatiaLite - Elementi di software libero applicato al
territorio" ed esponenti del mondo open source geografico
italiano, e poniamo ad ognuno di loro dieci domande, relative al come
è nato e come si è sviluppato il software libero geografico e quali
saranno presumibilmente le direzioni future, nel quadro delle
esigenze e delle ricerche innovative in campo territoriale.
Iniziamo con Alessandro
Furieri, autore di SpatiaLite, piccolo gioiello
italiano dei database spaziali.
SpatiaLite nasce
dal progetto SQLite, un motore di Database Relazionale
mono-utente, singolo file, contenitore di tabelle, comandabile
tramite linguaggio SQL.
SQLite ha avuto un
successo planetario, tanto da essere implementato su tutti i sistemi
operativi, compreso quello di tutti i tipi di cellulari, ed ha
surclassato di lunga misura il programma Access di Microsoft (tra
l'altro esclusivamente presente su Windows).
SpatiaLite è
l'estensione spaziale di SQLite. Anch'esso mono-utente, SpatiaLite è
stato inventato e implementato da Alessandro Furieri, che ne
gestisce lo sviluppo e la distribuzione.
SpatiaLite non è
una versione minimale di un database spaziale, è una versione
completa e con prestazioni ottime, tanto da essere supportato
ormai da tutti i programmi GIS open e non open source.
I comandi SQL in
SpatiaLite sono praticamente gli stessi presenti nelle
versioni più "blasonate", anche commerciali, e le
possibilità di elaborazione sono notevoli, anche se limitate dalla
mono-utenza e dallo spazio disco raggiungibile.
Ma partiamo subito con le
domande.
[da http://www.confsl.org/confsl10/images/stories/foto_furieri.jpg ]
START_OF_INTERVIEW
Domanda
1: Alessandro, partiamo dagli inizi: quando e come ti è venuto
in mente di scrivere un motore spaziale, e perchè "Spatial
is not special" ?
Risposta di Alessandro
Furieri: Tutto inizio' nel modo piu' casuale possibile circa
verso l'anno 2000; fino ad allora non mi era mai capitato di
occuparmi di GIS e di cartografia, anche se avevo comunque maturato
una lunga esperienza nel campo dello sviluppo di software
applicativo.
Quando a partire dal 2000
iniziai a collaborare con l'Osservatorio Trasporti di Regione Toscana
mi trovai improvvisamente a dovermi confrontare con il problema della
rappresentazione cartografica delle reti del trasporto pubblico.
Occorreva georeferenziare
svariate decine di migliaia di paline di fermata e di varianti di
percorso sull'intero territorio regionale, e naturalmente occorreva
anche verificare che quelle rappresentazioni cartografiche
corrispondessero esattamente agli orari di servizio.
I primi tentativi di
affrontare il problema tramite i classici strumenti GIS erano finiti
in un sonoro fallimento dato che si trattava di strumenti decisamente
troppo complessi (e costosi), ma soprattutto perche' pretendevano di
introdurre tecnologie decisamente "aliene" nell'usuale e
ben rodato modo di lavorare dei pianificatori delle reti.
Ecco quindi che parve del
tutto naturale sviluppare una semplice applicazione Windows che
supportava la pianificazione degli orari ma permetteva anche di
disegnare le reti su uno sfondo cartografico; ovviamente era qualcosa
di molto rozzo e per nulla sofisticato, ma ebbe un successo immediato
dato che permise a tutte le aziende di trasporto toscane di gestirsi
direttamente la rappresentazione cartografica completa delle proprie
reti senza dovere stravolgere il proprio modello organizzativo
tradizionale.
Un approccio molto
semplice ed elementare aveva avuto pieno successo la dove invece un
approccio piu' complesso aveva fallito; ecco come nacque
inizialmente il mio interesse verso il mondo GeoSpatial.
A partire da quel primo
esordio un po' casuale poi e' stato del tutto naturale seguire un
percorso evolutivo che ha finalmente portato alla nascita di un vero
e proprio Spatial DBMS conforme agli standard: ma tutto questo e'
avvenuto tenendo sempre ben presente che sforzarsi di mantenere la
complessita' al livello minimo indispensabile molto spesso paga.
Perche' "Spatial
is not special" ? Credo che la risposta sia gia' in quanto
ho detto sopra; esistono moltissimi contesti applicativi che
potrebbero potenzialmente impiegare tecnologie GeoSpatial in modo
utile e produttivo.
Ma per ottenere questo
servono componenti software ben standardizzati e che si possano
integrare molto facilmente con il tipico sw gestionale normalmente
utilizzato.
Il GIS non puo' sempre
essere considerato un mondo a parte con regole e requisiti tutti
speciali; spesso quel che serve realmente sono piuttosto componenti
"normali" che ben si prestino ad una facile integrazione in
modo quanto piu' possibile indolore.
Domanda
2: Perchè la documentazione di SpatiaLite preferisce essere
come un “libro di ricette" ?
Risposta: SQL e'
un ottimo linguaggio di manipolazione dei dati, ed in questo
specifico contesto e' oggettivamente piu' potente di molti altri
linguaggi di programmazione normalmente utilizzati (C/C++, Java,
Python etc).
Troppo spesso pero' SQL
e' circondato da una brutta fama: cervellotico, astruso, troppo
complesso.
L'idea di scrivere il
"libro delle ricette di cucina" e' semplicemente stato un
tentativo per cercare di sdrammatizzare e per dare un taglio tutto
sommato giocoso e per nulla paludato.
Sinceramente sono
abbastanza
soddisfatto del
successo che ha incontrato il
cookbook; mi risulta che
sia stato piu' o meno ufficialmente adottato da diverse Univesita'
tedesche, spagnole, US e sudamericane come testo-base introduttivo
per i corsi di geomatica e di topografia.
Il complimento migliore
me lo ha fatto una specialista inglese di sistemi GIS quando mi ha
scritto due righe che piu' o meno dicevano: "Sandro, mi sto
ancora sbellicando dalle risate. Grazie, non avrei mai immaginato che
studiare lo Spatial SQL potesse anche essere esilarante oltre che
utile".
Domanda
3: Perchè, pur essendo italiano, preferisci parlare in inglese
? La tua mail-list tecnica, "spatialite-users", è in
inglese, anche quando gli utenti sono italiani, come lo sei tu.
Risposta: Dobbiamo
essere molto realisti e pragmatici.
SpatiaLite e' un
progetto
internazionale; la community di SpatiaLite comprende
circa un
migliaio di persone sparse piu' o meno in tutto il mondo: gli
italiani sono solo poche decine.
La scelta dell'inglese
come lingua franca e' una scelta praticamente obbligata in un
contesto di questa natura.
Domanda
4: Quali sono i limiti di SpatiaLite, se ce ne
sono ?
Risposta:
Sicuramente ne esistono almeno un paio. tanto per cominciare
sia SQLite che SpatiaLite sono rigorosamente mono-utente;
quando serve anche supportare la multi-utenza usare SQLite/SpatiaLite
e' decisamente una pessima idea.
L'implementazione degli
indici spaziali e' molto efficiente, ma oggettivamente e'
anche abbastanza "esotica" e costringe ad utilizzare
sintassi SQL piu' complesse di quel che avviene in molti altri
Spatial DBMS.
SQLite offre un ottimo
supporto standard per SQL, ma soffre anche di alcune limitazioni
(peraltro volute, visto che vanno a vantaggio di un'implementazione
molto "light").
Insomma, tanto SQLite
che SpatiaLite cercano sempre di privilegiare la
semplicita',la facilita' d'uso e la leggerezza:
ma a volte questo significa anche dovere accettare qualche
"ruvidita'" e qualche piccola scomodita'; difficilmente una
Panda puo' offire lo stesso comfort che ti aspetti da una Mercedes.
Comunque deve essere ben
chiaro che si tratta di ottimi DBMS per uso personal (a
volte un po' spartani, ma comunque completi) che per definizione non
pretendono affatto di potere operare in contesti piu' articolati
magari di tipo client-server.
Se si parte da questi
presupposti allora si finisce per scoprire che leggerezza e
semplicita' finiscono per portare moltissimi benefici a fronte di
assai scarse rinunce.
Quello che personalmente
definirei un compromesso ben bilanciato ed assai spesso vantaggioso.
Domanda
5: Quali sono le applicazioni più grandi a te note (e
divulgabili) di SpatiaLite ? E quali sono stati finora i "casi
d'uso" più "minimalisti" ? Hai degli esempi ?
Risposta: Immagino
che il "power user" piu' significativo di SpatiaLite
sia Regione Toscana, che da alcuni anni a questa parte la
utilizza in modo molto intensivo in tutti i processi di elaborazione
GeoSpatial che svolge direttamente al proprio interno.
Molto spesso si tratta di
datasets di dimensioni abbastanza rilevanti (decine
di milioni di features, svariati GB di ingombro).
SpatiaLite e'
perfettamente in grado di eleborare in modo rapido,
efficiente ed affidabile anche questi "db-mostro".
Grazie all'utilizzo
massicio di SQL scripts anche molto complessi (persino di molte
migliaia di righe in alcuni casi) diventa molto semplice
automatizzare tutti i processi ripetitivi come p.es. tutti quelli
tipici dei collaudi per accettazione.
Inoltre SpatiaLite
supporta direttamente l'import/export verso i principali formati in
uso nel settore (SHP, DXF, TXT etc) e questo la rende decisamente
molto flessibile e di facile impiego.
Per inciso: regione
toscana usa con pieno successo SpatiaLite anche per pubblicare molti
datasets "pesanti" sul web, visto che in questo contesto e'
richiesta la mera consultazione read-only, e quindi non si pone
nessun problema per gli accessi multipli concorrenti.
Invece per quanto
riguarda i casi d'uso "minimalistici" so per
certo che molte apps per smartphones e tablets iniziano ad usare
sempre piu' spesso SpatiaLite (p.es. GeoPaparazzi).
Ma non mancano neppure i
casi di centraline embedded per il controllo dei cicli semaforici
o dei parchimetri che fanno girare con successo SpatiaLite su
micro-schede integrate formato pacchetto di sigarette che
costano circa 50 euro.
Comunque, il caso
d'uso piu' "speciale" che mi ha maggiormente toccato e'
stato quello di una maestra elementare iraniana (del tutto
priva di qualsiasi competenza informatica) che grazie a SpatiaLite e
Python e' comunque riuscita a realizzare con le sue sole forze un
semplice applicativo didattico perfettamente funzionante per
insegnare la geografia ai bambini utilizzando i pochi vecchi
PC a disposizione della sua scuola.
Un
altro ottimo esempio che
dimostra perche' dopo tutto
"Spatial is not special"
Domanda
6: Secondo te cosa manca a SpatiaLite perchè possa diventare un
"standard de facto" dei sistemi geografici ?
Risposta:
SpatiaLite e' gia' ottimamente integrata in
praticamente tutti i principali strumenti GIS/GeoSpatial open
source, da GDAL a QGIS etc
Mi risulta che sia
persino supportata direttamente dalle versioni piu' recenti di
ArcGIS e pure da FME insomma, una buona
interoperabilita' e' gia' oggi sicuramente possibile, anche
utilizzando strumenti proprietari.
Da qua a diventare
"standard de facto" naturalmente la strada e'
ancora molto lunga e tortuosa. Sospetto fortemente che in
querto campo non contino solo i fattori tecnici; contano certamente
ancor di piu' le scelte di marketing.
Domanda
7: Senza entrare nel merito ( e nei meandri ) della stesura
degli standard, pensi che uno "standard open" sia possibile
?
Risposta: Dietro
al concetto di standard si nascono molte possibili ambiguita';
esistono gli standard "de facto": vedi p.es. l'immortale
Shapefile, che tutto sommato si basa su specifiche molto lasche e
spesso fumose, ma che forse proprio per questo ha avuto un successo
travolgente ed inossidabile nel tempo.
Poi esistono gli standard
formalmente codificati: vedi p.es. GML, WMS, WFS etc; che molto
spesso sono percepiti come esageratamente complessi e che non di rado
contengono "aree grigie" non ben determinate e solo
parzialmente definite che poi di fatto mettono a rischio la reale
interoperabilita' tra componenti di diversa provenienza.
In teoria qualsiasi
standard valido dovrebbe sempre essere "open", nel senso
che dovrebbe essere pienamente trasparente e non dovrebbe mai
contenere tecnologie brevettate o comunque soggette a vincoli
proprietari.
Purtroppo di fatto
avviene che le principali aziende produttrici riescono sempre ad
avere un ruolo determinante nel ciclo di messa a punto degli
standard, e questo non di rado finisce con il reintrodurre dalla
finestra elementi di potenziale ambiguita'.
Sintetizzando; uno
standard ha reale valore solo se e' realmente "universale",
e quindi se e' accettato e supportato efficacemente tanto in ambito
proprietario come in ambito open source, in modo assolutamente neutro
e trasparente.
Purtroppo spesso
(fortunatamente non sempre) interessi commerciali particolari
finiscono per privilegiare le implementazioni non conformi.
Le communities open
source da sole ovviamente non hanno il potere contrattuale necessario
per imporre uno standard.
Domanda
8: Passiamo al futuro-futuribile. A quando
l'implementazione del TIN, come oggetto topologico tridimensionale in
SpatiaLite ? Ti piace la versione del TIN inserita in PostGIS ?
Risposta: Allo
stato attuale non esiste un chiaro modello di riferimento per i TIN;
gli standard OGC/SFS ed ISO/MM coprono solo il caso delle geometrie
"simple features": Point, Linestring, Polygon etc
parallelamente, anche le librerie di supporto (la GEOS in primis)
supportano solo le simple features 2.5D
personalmente non credo
che i tempi siano ancori maturi; ed avventurarci in percorsi
"creativi" in assenza di un chiaro standard universalmente
accettato e di qualsiasi tipo di supporto da parte delle altre
librerire di base pare impresa troppo onerosa e gravata da troppe
incognite.
probabilmente SpatiaLite
finira' certamente per implementare qualche forma di supporto
topologico 2.5D nei prossimi anni, ma temo sinceramente che un pieno
supporto 3D sia ancora poco facilmente conciliabile con tutti gli
altri requisiti standard richiesti ad un qualsiasi Spatial DBMS.
Domanda
9: Pensi verrà mai implementata una tabella delle
caratteristiche grafiche nei database spaziali ?
Risposta: Se per
"caratteristiche grafiche" si intende pieno supporto per
gli stili grafici da utilizzare durante le operazioni di rendering
dei vari layers allora sono felice di dire che questa e' una
caratteristica che SpatiaLite gia' supporta da circa un anno a questa
parte.
Il supporto XML che e'
stato introdotto in SpatiaLite serve proprio a questo; consentire di
inserire direttamente all'interno del DB tutti i documenti XML che
contengono le schede di matadatazione ISO 19115 oppure gli stile
grafici SLD/SE (RasterSymbolizer, PointSymbolizer, LineSymbolizer,
PolygonSymbolizer e TextSymbolizer).
Naturalmente il semplice
fatto di potere caricare gli stili grafici direttamente nel DB poi
serve a ben poco dal punto di vista pratico se nessun applicativo
desktop GIS di tipo tradizionale e' concretamente in grado di
utilizzare utilmente queste informazioni, così come purtroppo accade
oggi.
Ma per esempio
RasterLite2 e' gia' oggi in grado di sfruttare al meglio i
RasterSymbolizers: per esempio e' possibile applicare stili di
aumento e normalizzazione del contrasto per le ortofoto, così come
e' possibile comporre un'immagine a falsi colori a partire da
qualsiasi raster multi-banda (p.es. Landsat); infine e' anche
possibile "colorare" dinamicamente qualsiasi datagrid (DEM,
DSM etc) applicando anche un'eventuale ombreggiatura shaded-relief.
Sono lieto di
annunciare che in un prossimo futuro RasterLite2 sara' certamente in
grado di effettuare direttamente il rendering anche per i layers
vettoriali.
Aspettatevi novità
significative: Spatial SQL sta così per diventare anche un
linguaggio completo e sofisticato per la generazione dinamica di
immagini e di mappe.
Decima
domanda: Le HiperViste. Ovvero le "view" che
richiamano altre view, con funzioni spaziali, dissolve, intersect,
calcolo sommatorie ecc, in modo che al variare delle tabelle base,
variano dinamicamente i risultati. Come sai, si tratta di una
possibilità molto richiesta e molto "succulenta" (per
usare il tuo stesso esempio di cucina). Ci stai pensando ?
Di fatto e' possibile
gia' oggi (almeno in teoria). Bastano abbondantemente i meccanismi
base intrinseci di SQL per ottenere tutto questo.
Gli ostacoli reali sono
di diversa natura. In primis di scarsa efficienza: una lunga catena
di view (che magari richiedano un sacco di operazioni spaziali) e'
un bellissimo meccanismo formale che sulla carta sembra molto
attraente.
Salvo poi magari scoprire
al momento del runtime che i tempi di elaborazione richiesti sono
semplicemente improponibili dal punto di vista pratico.
Magari funziona tutto
bene con qualche semplice dataset con poche centinaia di features, e
poi si scopre inevitabilmente quando si passa nell'ambiente di
produzione (milioni di featurea) che occorrono lunghe ore per
arrivare a visualizzare materialmente i primi risultati.
Naturalmente scrivere una
View anche molto complessa che giri con ragionevole efficacia in modo
altamente ottimizzato e' sicuramente possibile anche in
SQLite/SpatiaLite.
ma richiede certamente
grande esperienza, una paziente calibrazione ed una oculata
pianificazione; insomma, sicuramente non e' qualcosa alla portata di
un end-user generico, e neppure di qualche
tool automatico o
semi-automatico.
Infine va considerato
quello che forse e' l'ostacolo principale; non basta semplicemente
arrivare a scrivere una query SQL molto efficiente. occorre anche che
quella query poi si integri bene nel modello dati supportato dai
principali desktop GIS (magari proprio con QGIS): e qua nascono
ulteriori problemi forse insormontabili.
Tutti i desktop GIS sono
saldamente ancorati al concetto di "layer" basato su
geometrie omogenee e ragionevolmente statiche (il famoso modello
Shapefile, tanto per capirci meglio). Ma tutto questo si concilia
malissimo con gli approcci assai piu' dinamici che potrebbero
scaturire da un approccio tipo HyperView, dove persino il tipo
geometrico o lo SRID potrebbero cambiare capricciosamente durante
l'elaborazione.
Qua il cane si morde la
coda: anche una HyperView puo' ovviamente fornire uno snapshot
"istantaneo" che faccia apparire un quadro statico
on-demand; ma quando sono in gioco milioni di features nulla ci
assicura che il tempo necessario non tenda rapidamente verso
l'infinito.
Concludendo: e' un ambito
opertivo sicuramente affascinante, ma che allo stato attuale possiamo
considerare piu' arte creativa che scienza esatta.
Comunque gli attuali
desktop GIS spesso ma si adattano ad uno scenario di questa natura:
occorrerebbe sicuramente lavorare pesantemente su entrambi i versanti
per potere sperare di arrivare a qualcosa di realmente soddisfacente.
END_OF_INTERVIEW
Ringraziamo Alessandro
Furieri per la sua disponibilità (anche sotto le vacanze di Natale
:) e ... a presto.
