2014-12-22

"GIS Open Source" - Intervista ad Alessandro Furieri autore di SpatiaLite


"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.



Nessun commento: