2015-08-16

SmartRoadSense - Rilievo dello Stato delle Strade

Scalinata o Strisce Pedonali ?


Vi siete mai trovati davanti un percorso di questo genere ?   No ?!?   In questo caso verrebbe da chiedervi:  "In che mondo vivete ?"  :)

In realtà, purtroppo, concretamente in Italia, per varie ragioni, ma anche e soprattutto per incuria, lo stato delle strade è quello che vediamo nella foto, mediamente.  Tanto è vero, che le "Strisce a guscio di tartaruga" sono diventate ormai una consuetudine, quando poi sono visibili, le strisce stesse, e non cancellate dal tempo.

Cosa fare per migliorare lo stato delle cose ?   Vari tentativi sono stati fatti: denunce, foto, servizi televisivi, articoli su giornali.   Ma nulla.  Chi è delegato a risolvere queste situazioni sembra essere inamovibile.

Alcuni siti internet sono stati dedicati a raccogliere le denunce, le foto, gli articoli.  Nulla.

Allora, passiamo ad un'altra tecnica, più massiva e meno sporadica.   Se non bastano poche centinaia o di migliaia di foto, passiamo a documentare estesamente tutte le strade italiane.  Che dire:  non lo fa già OpenStreetMap ?  No.  OpenStreetMap vi dice dove stanno le strade e come si chiamano, ma non vi dice in che stato di manutenzione si trova quel determinato tratto stradale.

Ma allora, diciamo di più:  documentiamo lo stato di un punto ogni venti metri di tutte le strade italiane.

Esagerato ?  E chi potrebbe fare una cosa del genere ?  Non ci credete ?   Allora guardate l'immagine qui sotto.


Si tratta di SmartRoadSense.it  un sito web che visualizza la mappa dello stato di manutenzione delle strade italiane.  Si tratta di un progetto, lanciato nel 2013, della Scuola di Scienze e Tecnologie dell'Informazione dell'Università di Urbino e dell'Associazione Culturale NeuNet.  Il gruppo di ricerca, coordinato da Alessandro Bogliolo, è composto da Alessandro Aldini, Giacomo Alessandroni, Alberto Carini, Saverio Delpriori, Valerio Freschi, Lorenz Cuno Klopfenstein, Emanuele Lattanzi, Gioele Luchetti, Brendan D. Paolini e Andrea Seraghiti.

http://smartroadsense.it/about.html

Attualmente (ferragosto 2015) siamo arrivati a 1 milione e 1298 punti.  Considerando che si tratta di un punto ogni 20 metri, possiamo dire di aver tracciato più di 20 mila km.

"Noi" chi ?   NOI.  Ovvero noi tutti che possediamo un'auto ed uno SmartPhone, per ora solo con Android  (ma mi dicono "presto" anche con iOS).   Comunque, se avete "solo" un iPhone, fatevi prestare uno adatto da un amico, e portatelo in macchina con voi, e raccontategli quello che vi ho appena detto, e contribuite così ad estendere la mappa  SmartRoadSense  anche nei vostri dintorni.

Il nostro destino è nelle nostre mani  :)

Ah, dimenticavo:  cosa bisogna installare sul telefonino ?  L'applicazione  "SmartRoadSense", che potete trovare nello store "Google Play"Non costa nulla,  ma varrà molto.


Una volta installata l'app sul telefonino, accendete il GPS, mettete il telefonino sul cruscotto della vostra auto e... partite  :)

E' tutto quello che dovete fare, oltre a guidare la vostra macchina, non badando al telefonino, ma alla strada davanti a voi (dato che dovrete guardare le buche).

L'applicazione memorizzerà un valore da zero a sette corrispondente ai sobbalzi subiti dall'accelerometro del telefonino, uniti al valore di posizionamento GPS.

Il video che segue (tratto dal blog di SmartRoadSense), illustra tutto il processo.

 [  http://smartroadsense.it/blog/it/video-clip/  ]

Divertente ?  Quando viaggiate, registrate il più possibile, magari tenendo collegato il telefonino alla presa di corrente (ovviamente, il GPS consuma energia ...).

Ogni 15 minuti, l'applicazione tenterà di trasmettere i dati al server SmartRoadSense, ma in caso di insuccesso, continuerà ad accumulare dati e lo farà più tardi, appena possibile.

A questo punto vi lascio, per farmi un giro in macchina  ;)

Dimenticavo ancora:  io ho scritto un plugin per QGIS, che si chiama, per l'appunto, SmartRoadSense,  e non fa altro che rendere disponibili tutti i dati anche all'interno del vostro GIS open source preferito, in modo che possiate fare statistiche sullo stato stradale dei vostri dintorni, e magari controllare se oggi, hanno finalmente messo a posto quel tratto di strada che vi interessa.





Tramite QGIS SmartRoadSense plugin è possibile visualizzare i dati in maniera tematica, evidenziando le strade "problematiche", e con l'ausilio di Go2streetView plugin (di Enrico Ferreguti) è possibile visualizzare l'immagine di quel tratto di strada segnalato da pallini rossi (valore di rugosità maggiore di due).   Grande !

Parleremo prossimamente con maggiore dettaglio sia di SmartRoadSense, e delle sue evoluzioni, che del plugin Go2streetView , che se ancora non avete installato, vi consigliamo di fare al più presto, e che vi riserva molte piacevolissime sorprese.



A presto !   E buon viaggio.

BobMaX


Per saperne di più:

PDF "SmartRoadSense: Collaborative Road Surface Condition Monitoring"
 
http://smartroadsense.it/
http://smartroadsense.it/about.html
http://informatica.uniurb.it/smartroadsense/
https://trasferimentotec.wordpress.com/2015/02/25/smartroadsense-unapplicazione-per-la-qualita-delle-strade/

2015-08-09

Intervista a Paolo Cavallini

Paolo Cavallini e Roberto (BobMaX) Angeletti

Ciao Paolo,


dopo qualche tempo, ritorno alla mia proposta di una tua intervista per il mio blog.

Quella che segue è una lista di domande riguardanti il software libero geografico, e altro, a cui, magari sotto l'ombrellone, come un cruciverba, puoi rispondere a tempo perso.


Paolo Cavallini:

Ola. Ecco qua. Chiedi pure, se del caso approfondiamo.”


Prima domanda:  “Con l'uscita della versione  QGIS 2.10  "Pisa"   siamo arrivati alla maturità (intesa come professionalità) del noto software geografico libero e open source.  Pensi che sia una versione abbastanza italiana e "a piombo" (per prendere spunto dalla verticalità della famosa Torre) ?”

:)


Risposta di Paolo Cavallini:

L'esperienza ci dice che ogni versione segna un importante passo in avanti nella funzionalità e stabilità di QGIS. Quindi certo, QGIS Pisa è uno strumento professionale, maturo quanto lo si può essere in questa fase, certamente meno di quanto lo sarà la prossima versione. Ovviamente i problemi e le cose da fare non mancano, quindi invito tutti a partecipare, come meglio possono: c'è spazio per tutti - e non è una frase di circostanza, provare per credere!

QGIS nasce da una comunità veramente internazionale, e prevalentemente europea. L'Italia ha sempre avuto un ruolo rilevante nello sviluppo di QGIS, ma l'unica cosa più italiana in questa versione rispetto alle altre è il ricordo di uno splendido incontro di sviluppatori, avvenuto nella tenuta di San Rossore, accanto a Pisa, nel 2010.”


Seconda domanda: “Riprendendo una frase di Eric Raymond:  "Release early, release often",  pensi che sia sempre vero questo,  oppure a volte bisognerebbe meditare di più su una singola release ?”


Risposta di Paolo Cavallini:

Annosa questione: è chiaro come qualunque scelta in questo campo sia il risultato di un compromesso, e sia perciò destinata a scontentare una parte dell'enorme massa di utenti di QGIS. Credo che la soluzione attuale (una nuova versione ogni 4 mesi, per chi ama ed ha bisogno delle novità, e una versione con supporto a più lungo termine) sia un compromesso molto ragionevole, che consente a tutti di trovare una soluzione adeguata.
Piuttosto, trovo bizzarro che in Italia grandi enti ed aziende, che usano QGIS su centinaia di postazioni, non si preoccupino minimamente di migliorarne ulteriormente la stabilità, ridurre il numero di bugs, aggiornare la documentazione e la traduzione, e altre attività simili, che renderanno l'uso di QGIS ancora più piacevole. Paragono questo con il circolare con la macchina senza copertura assicurativa: apparentemente si risparmia, ma in caso di problemi la situazione diventa complicata. Con un piccolo investimento in questo senso avremo pubblicazioni frequenti, e un eccellente controllo di qualità.”


Terza domanda: “Perchè il software (specie quello geografico) deve essere "open" ?”

Risposta di Paolo Cavallini:

Tutto il software deve essere libero semplicemente per mantenere la
massima libertà nella società.
I motivi pratici sono sempre gli stessi che racconto da anni (si
invecchia!):
* Motivi economici
  * costo totale più basso
  * le risorse vanno sul territorio
  * uso legale = più opportunità
  * facile estensione del GIS ad un più vasto numero di utenti
* Motivi commerciali
  * indipendenza dalle scelte del fornitore
  * no lock-in
  * no monopoli = maggiore competizione
  * no spese per la gestione delle licenze
* Motivi tecnici
  * principio “evolutivo”
  * sicurezza: no trojan, virus, e codice maligno
  * standard aperti: interoperabilità, persistenza del dato
  * personalizzazioni più facili
  * meno barriere all'entrata
* Motivi didattici
  * gli stessi programmi possono essere usati a scuola e a casa, senza
oneri per le famiglie
  * si promuove una cultura della legalità
  * è più facile usare hardware vecchio (riduce quindi il digital divide
fra gli studenti)
  * lo studente può analizzare il funzionamento interno, non solo le
interfacce
* Motivi strategici
  * mantenimento delle competenze nazionali
  * esternalizzare settori strategici è un rischio (perché comportarsi come una colonia?)”


Quarta domanda: “Cosa ne pensi dei brevetti ?  Favoriscono o bloccano l'innovazione ?  A volte è necessario registrare qualcosa ?”


Risposta di Paolo Cavallini:

Non sono esperto di processi industriali, quindi non mi pronuncio sulla possibile utilità dei brevetti in campi diversi da quello di cui mi occupo. Certamente accettare i brevetti nel software è inappropriato, in quanto costituirebbe un potente freno all'innovazione, ed un enorme aiuto alle grandi aziende software, tutte più o meno monopoliste nei relativi settori. Per chi vuole saperne di più, suggerisco la lettura di
https://fsfe.org/campaigns/swpat/swpat.it.html e di molti altri articoli in rete.”


Quinta domanda:  “Qual è la ragione del successo di Quantum GIS ?”


Risposta di Paolo Cavallini:

Credo che sia la sua struttura estremamente aperta e democratica, senza un deus ex machina, e la comunità molto accogliente: il numero degli sviluppatori continua ad aumentare, perché partecipare al progetto è divertente e produttivo. E con gli sviluppatori aumentano le funzioni disponibili, che attirano sempre nuovi utenti. Tutti gli utenti possono dire la loro, e le decisioni risentono positivamente dell'apporto di
molti punti di vista diversi.
Anche la facilità con cui si possono aggiungere funzionalità tramite lo sviluppo e l'installazione dei plugins gioca sicuramente un ruolo.”


Sesta domanda:  “Quanto sono importanti i plugin python  per Quantum GIS ?”


Risposta di Paolo Cavallini:

Come ho appena detto, sicuramente moltissimo! Abbiamo più di 500 plugins disponibili, da quelli semplicissimi, che aggiungono una nuova funzione tramite il click su un pulsante, ad ambienti di lavoro veri e propri, come ad esempio il plugin per la classificazione semi automatica dell'uso del suolo, o molti altri.
E fa piacere vedere che fra gli sviluppatori di plugins, molti sono italiani.”


Settima domanda: “Perchè esiste la fase di approvazione di un plugin ?  In cosa consiste?  Da cosa ci si protegge ?”

Risposta di Paolo Cavallini:

Nella gestione dei plugins, come in altri aspetti della vita di QGIS, siamo lentamente passati da una condizione molto anarchica, fortemente destrutturata, ad un maggior coordinamento. Il fine principale di questa operazione è innalzare la qualità dei plugins, convincendo gli sviluppatori ad uniformarsi a degli standard di base, molto semplici, e importanti per gli utenti.
Durante la fase di approvazione, verifico (talvolta con l'aiuto di altri appartenenti alla comunità di sviluppo) che le informazioni essenziali siano corrette (nome, descrizione, repository, bugtracker, ecc.), che il plugin funzioni, almeno nelle sue linee essenziali, segnalo eventuali bugs, invito a spiegare la differenza con altri plugin simili, consiglio di unire gli sforzi, quando appropriato, con gli sviluppatori di plugin simili, chiedo che vengano installati al posto giusto nell'interfaccia, dove appropriato suggerisco di trasformarli in subplugin di Processing, e do una rapida occhiata al codice.
Tutto questo credo sia molto utile per garantire agli utenti una migliore usabilità, e devo dire che molti sviluppatori apprezzano il mio lavoro, peraltro completamente volontario.”


Ottava domanda:  “Pensi si potrebbe migliorare il supporto di python in QGIS ?  Esempio:  installazione librerie,  "SandBox"  (isolamento)”

Risposta di Paolo Cavallini:

In effetti, poter installare con facilità librerie addizionali che possano rendersi necessarie, anche in sistemi operativi poco furbi, sarebbe un bel passo avanti. Ci sono però una serie di possibili effetti negativi che vanno valutati con attenzione. Probabilmente il passaggio a Python 3, che dovrà avvenire in tempi ragionevoli, sarà l'occasione per valutare di nuovo questa opportunità.”



Nona domanda: “Non pensi si dovrebbe inserire un menu 3D ?   A quando il supporto di OpenGL e le coordinate 3D ?”


Risposta di Paolo Cavallini:

Le geometrie 3D sono già parzialmente supportate nella versione 2.10, e lo saranno in modo completo nel prossimo futuro, probabilmente già dalla versione 2.12.
Per quanto riguarda la visualizzazione, già oggi ci sono delle possibilità interessanti, specialmente tramite il plugin QGIS2Threejs e ovviamente tramite il tuo VTerrain.
Ci sono da aspettarsi novità nel futuro, soprattutto grazie al supporto di OpenGL in Qt5, a cui abbiamo iniziato a migrare.”


Decima domanda:  “Cosa ne pensi dei metodi di finanziamento preventivo ?   Possono essere utili oppure si può rischiare di vincolare troppo il software libero alle richieste ?   Si diventerebbe troppo simili al sw proprietario ?”


Risposta di Paolo Cavallini:

Sono completamente favorevole a qualunque forma di finanziamento. Penso che anche in questo caso, avere molti soggetti coinvolti, ognuno con le proprie priorità, garantisca un risultato migliore per tutti.
Il software proprietario funziona in modo molto diverso: non c'è infatti una relazione diretta fra i bisogni reali degli utenti e il lavoro degli sviluppatori, ma tutto è mediato dal marketing, che spesso rende il processo meno lineare.”



Roberto Angeletti:OK.  Penso che dieci domande siano un bel numero. Salutiamo Paolo ringraziandolo per la sua disponibilità.

Paolo Cavallini: “Saluti, e Happy QGISsing!”




A presto

Roberto (BobMaX) Angeletti   (l'autore di qualche plugin ed entusiasta sostenitore del sw libero)







2015-03-30

OpenDataLazio - presentazione a Formia il 9 aprile 2015



Verrà presentato a Formia il 9 aprile 2015 il portale OpenData del Lazio.  

11.30 - 14.00 | Laboratorio sui dati del portale 

a cura di Dante Chiroli, LAit S.p.A. e Roberto Angeletti, Open Street Map Gaeta
La conoscenza del territorio inizia con una buona mappa. E una buona mappa si realizza con una serie di tecniche applicate ad una serie  di dati in relazione tra loro.  Quali tecniche?  Quali dati ?  Quantum GIS (QGIS) è un software libero per la visualizzazione ed il trattamento di dati geografici. I partecipanti al laboratorio saranno messi in grado di visualizzare all'interno di  QGIS  i dati grafici territoriali presenti sul   portale OpenDataLazio e di OpenStreetMap e di eseguire elaborazioni tematiche di classificazione e stampe utili nella professione e nello studio del territorio.

con Dante Chiroli, Lait S.p.A
  • Interfacce CKAN 
  • Esempi d’accesso ed elaborazione dei dati aperti 
con Roberto Angeletti, Open Street Map Gaeta
  • OpenStreetMap :  La libera mappa del mondo - I dati del Lazio
  • Visualizzare i dati del Portale OpenDataLazio su Quantum GIS (QGIS)




A presto

BobMaX

Link utili:     dati.lazio.it

http://www.digitalchampions.it/archives/blog/la-sfida-tecnologica-e-culturale-degli-open-data-e-il-portale-del-comune-di-formia/

http://saperi.forumpa.it/story/110667/datalab-lazio-tour-oltre-100-partecipanti-al-primo-incontro-del-progetto-open-data

http://www.gazzettinodelgolfo.it/formia-open-data-lazio-tour-ecco-i-materiali-utili-per-approfondire/#.VTKk6nqmkVo

https://dati.lazio.it/documents/10181/109642/6_ANGELETTI_Formia09042015.pdf/29c1ce11-8cfc-4861-80da-d85dd6b9ca9b

Video Gaeta

Piano regolatore di Palermo su OpenStreetMap
http://opendatasicilia.it/2015/02/23/il-piano-regolatore-di-palermo-opendata/

2015-01-06

GEarthView 2.0 - plugin per QGIS




--------------------------------
GEarthView 2.0 version :
--------------------------------
GEarthView plugin displays QGis view and features with attributes (taken from the selected layer) into GoogleEarth.

Install, before, the following python libraries: 

twisted\ Twisted-13.0.0-py2.7-win32  
( https://pypi.python.org/pypi/Twisted/13.0.0 )
twisted.zip

zope\ zope.interface-3.6.0-py2.7-win32  
( https://pypi.python.org/pypi/zope.interface/3.6.0 )
zope.zip

New in 2.0 version:
1) It moves the QGIS window according with GoogleEarth view
2) It displays in QGIS XYZ coodinates from GoogleEarth view center
3) It puts a new point in GoogleEarth view center containing a QrCode
4) It puts the GoogleEarth view center points in QGIS 


tested on Windows, MacOSX and some Ubuntu Linux... 

(of course, GoogleEarth need to be installed, before ! If not, this plugin is completely unuseful :)


------------------------------
GEarthView 2.0.5 version :
--------------------------------
GEarthView plugin visualizza in GoogleEarth la vista di QGis e gli elementi vettoriali con attributi (presi dal livello selezionato).

Novità della versione 2.0.5 :

0) Ruota la vista di QGIS (2.8) seguendo quella di GoogleEarth
1) Sposa la vista di QGIS (2.8) seguendo quella di GoogleEarth
2) Visualizza in QGIS le coordinate XYZ del centro di GoogleEarth
3) Inserisce un nuovo in GoogleEarth view center contenente un QrCode e DateTime
4) Aggiunge in QGIS il punto di GoogleEarth view center con le coordinate 3D
5) La funzione PasteFromGE copia elementi da GoogleEarth anche raggruppati in cartelle, e anche se contemporaneamente punti, linee e poligoni insieme.   Vengono creati in QGIS tre livelli, ognuno per tipo


Link Utili:

Come installare i moduli python

Un tutorial in italiano su GEarthView 1.07  plugin

Un tutorial brasiliano su GearthView 1.07 plugin nel sito GeoFumadas

Un esempio di utilizzo di GEarthView nella produzione di dati da rilasciare ad un cliente 

http://www.tysmagazine.com/cuales-son-los-5-complementos-de-qgis-que-deberias-conocer/

2014-12-31

Raspberry PI - Un Lampone sotto l'Albero


Vi racconto una storia.  Questa è la vera storia di come sono entrato in contatto con un "lampone di genio"  :)

Tutto è cominciato in libreria, in quella all'interno di una stazione.  Il mio treno era incredibilmente arrivato in anticipo, e quindi avevo tempo per fermarmi un attimo a guardare il reparto "Informatica", sempre più pieno di libri su MacOSX e Linux, e sempre meno di "Finestre".

In un angolo, una pila di libri bianchi e neri, con una macchia rossa e verde:  "Raspberry PI".    Ne prendo uno, di libro, e comincio a sfogliarlo.  Parla di una scheda, simile ad Arduino, io credevo, ma fatta in Inghilterra.

Bah, penso, ci siamo fatti clonare l'idea della scheda tuttofare.   Sto per riporre il libro, però mi guardo intorno.  Ci sono altri libri sul Raspberry.  Anche troppi.  

Allora, apro di nuovo il "mio" libro e guardo meglio:  connettore di rete, due porte USB,  uscita video HDMI, connettore Input/Output,  e "udite udite" lettore SD come Hard Disk !!!

Semplicemente Geniale !    Si tratta di un computer completo su una "carta di credito"  :)

Lo voglio.  Il libro, intendo, per il momento.   Scelgo nella pila di libri identici quello che ha la copertina meno rovinata, più liscia, più bella.    E' una mia fissazione.

Vado velocemente in cassa.  Il libro costa quasi come il computer di cui parla.  Venti euro ben spesi.

Proprio così:  un computer da venti euro (circa).   Possibile ?   Lo vedremo.

Esco dalla libreria e poi dalla stazione.  Sta leggermente piovendo, e così prendo l'ombrello dentro la mia borsa.  Apro l'ombrello e appendo la busta di carta contenente il mio bel libro ed il quotidiano gratuito al manico a gancio dell'ombrello.  Sono entusiasta della copertina del libro, lucida e perfetta.  :)

Un colpo di vento rovescia l'ombrello e mi costringe a chiuderlo.  E a saltare sul marciapiede, perché un autobus arriva verso di me.   Ufffff.   Scampata bella.

Ma mi manca qualcosa.   Il libro !  La busta dov'è ?   Torno indietro sui miei passi.   Ecco il marrone della mia busta di carta in mezzo all'incrocio,  tutta strapazzata.    Raccolgo triste il mio pacco, bagnato e stropicciato, e guardo al suo interno, aspettandomi di vedere il disastro che poteva aver fatto la ruota doppia di un autobus che vi era passato sopra.

Intatto.  Il libro era intatto.  Con la sua copertina lucida rispecchiava la mia faccia allucinata e bagnata.

Solo qualche buchetto quasi invisibile.  Solo la costola del libro, che riportava qualche scanalatura in più.  Un autobus non aveva scalfito l'integrità dell'oggetto, né il suo prezioso contenuto.

Inutile dirvi che la sera stessa avevo ordinato via internet il mio Rasperry PI.  Il computer, questa volta.

:)


La storia continua …  su   http://unlamponesottolalbero.blogspot.it


A presto

BobMaX




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.