10 gennaio, 2012 | di Pietro Blu Giandonato

Il “sottotitolo” di TANTO, così come concepito da Andrea ormai più di 6 anni fa, è “le cose che ci piacciono”. Nel nostro blog ormai scriviamo quasi esclusivamente di geomatica, intesa in tutte le sue accezioni, e in verità ero piuttosto scettico se pubblicare questo articolo proprio su TANTO. Ma poi mi sono ricordato che Gerlando aveva narrato la sua esprienza di comunicatore sempre qui, nel non molto lontano 2009. E del resto si tratta sempre di entropia, che tra l’altro è la categoria più numerosa dei nostri post.

Un impulso ulteriore a decidere di pubblicarlo qui (attenzione, prima ancora che una redazione noi siamo un gruppo di amici, quindi le decisioni le prendiamo sempre di comune accordo, compresa la scelta degli articoli) è stato il recente lancio di Planet GIS Italia, che mi ha “costretto” a sostituire in Google Reader il feed di Blog GIS Italia v. 3 proprio con quello nuovo di zecca di PGI.

Andiamo al dunque…

Una delle nostre necessità primarie quotidiane è informarci. Lo facciamo in molti modi differenti, da molte fonti differenti, su molti media differenti.

La radio ad esempio ci può accompagnare in svariati momenti della giornata. Per me è irrinunciabile ad esempio la mattina ascoltare su Rai Radio 3 Prima Pagina, e quando posso Radio3 Scienza, Tutta la città ne parla o ancora la trasmissione di Oscar Giannino su Radio24. Per fortuna ci sono i podcast, per ascoltare le puntate che ci perdiamo.

Ma quando si parla di blog, siti web, liste e gruppi di discussione, allora le cose diventano più complicate. Bisogna dedicargli del tempo, stando davanti al computer, o anche sullo smartphone, sebbene il piccolo schermo metta a dura prova le nostre diottrie e il touchscreen la pazienza delle nostre dita. Comunque sia, si tratta di tempo che viene ritagliato durante le nostre giornate incasinate, tra lavoro e impegni familiari.

Voglio qui condividere la mia esperienza di come ho organizzato quell’oretta in totale che riesco a dedicare a questa fondamentale, irrinunciabile parte della giornata.

Per domare le decine e decine di feed RSS ai quali sono abbonato, ma soprattutto non cadere nel panico dovuto ai 1.000 e passa nuovi item quotidiani che essi generano, uso da anni ormai Google Reader. A mio avviso, nonostante con l’ultima revisione Google lo abbia menomato pesantemente, eliminando la possibilità di condividere con i propri contatti le nostre letture e dirottando il traffico su Google Plus – che per inciso non m’ha preso e forse mai mi prenderà -, io lo trovo ancora il miglior strumento web per leggere in maniera organica i feed.

Naturalmente, molte delle cose che troviamo interessanti le condividiamo spontaneamente con i nostri contatti – una volta anche su Google Reader – via email, su Twitter, Facebook, Linkedin e ogni altro sistema sociale che frequentiamo.

Devo però fare un inciso fondamentale, ormai espleto circa il 50% delle mie attività digitali quotidiane (tra le altre consultare email, navigare sul web, gestire gli impegni, usare i social network, e ovviamente informarmi) sul mio smartphone. L’altro 50% del lavoro – su PC – riguarda l’uso di GIS, la scrittura di documenti di lavoro e di articoli per i blog, più altre attività “pesanti” meno ricorrenti. Essermi organizzato su piattaforma mobile mi consente di non rimanere ogni sera dalle 2 alle 3 ore davanti al computer per organizzare il lavoro (email, programmazione attività, ecc.), sacrificando il resto delle ancora più importanti attività sociali: dedicarsi alla famiglia, agli amici… e a sé stessi.

Il mio workflow informativo 2.0 parte dunque da Google Reader, nel quale butto qualunque feed RSS, dai siti web, ai blog, alle mailing list che non frequento assiduamente, finanche ai Pipes di Yahoo che uso per fare piccoli “mashup informativi”, come questo che si basa su quest’altro. Ma ovviamente mi avvalgo di una serie di applicazioni sia mobili che web per ottimizzare al massimo il tutto.

Per esprimervi in maniera chiara il workflow che ho messo a punto, e in modo sistemico i link tra le varie applicazioni da me utilizzate, ho creato una semplice mappa mentale con il fantastico servizio web popplet. La vedete qui sotto.

Gli strumenti del mestiere…

Descriverò ora gli attrezzi con i quali ho costruito il workflow, si tratta di tre applicazioni per Android e altrettanti servizi web. Si potrebbe costruire un processo analogo anche su piattaforma iOS – suggerisco infatti allo scopo alcune app alternative – ma francamente non so quanto potrebbe funzionare, visto che sul sistema operativo mobile Apple manca una delle “funzioni killer” invece da sempre disponibile su Android: l’onnipresente menu “share”. Con esso è infatti possibile inviare qualunque contenuto ad altre applicazioni, consentendo una piena interoperabilità tra di esse.

• gReader • applicazione Android – free
A mio avviso è un lettore di Google Reader molto migliore dell’applicazione di Big G; possiede molte più funzioni, tra le quali la customizzazione dell’interfaccia, ma ovviamente è una questione di gusti. Ecco come lo uso. Quando trovo un item così interessante da volerlo leggere più tardi, in genere vorrei anche metterlo tra i miei bookmark, perciò lo invio al mio account delicious. Per fare questo mi è sufficientemente marcarlo “starred”, e un’apposita “ricetta” che ho creato sul servizio web ifttt (descritto oltre) preleva il flusso dei miei starred item e li trasforma in bookmark su delicious, taggandoli con “ifttt”, “googlereader” e “nome_feed”. Periodicamente vado a “curare” questi bookmark su delicious, li leggo e se ne vale la pena li conservo, taggandoli opportunamente e magari mettendoli in uno stack. C’è anche il modo di conservare – sempre su delicious – le letture in maniera privata, marcandole con un apposito tag, qui la ricetta su iftt. Quando invece una lettura mi sembra degna di condivisione, se voglio twittarla subito la mando a Tweedeck (vedi più avanti) mediante il menu “share” di Android, altrimenti a Buffer (ne parlo dopo) se voglio programmarne la diffusione su Twitter o Facebook in orari differenti.
Input: feed RSS. Output: starred items verso Delicious, shared verso Tweetdeck o Buffer.
Alternativa iOS: Feeddler

• Buffer • applicazione Android e servizio web - freemium
Si tratta di un formidabile servizio basato su web che consente di creare uno stack di tweet e aggiornamenti Facebook programmabili ad orari definiti dall’utente. La sua versione free consente di gestire fino a 3 distinti account Twitter e/o Facebook e di pubblicare fino a 10 elementi al giorno. Poichè (co)gestisco diversi account Twitter, riesco ad aggirare questo limite mediante BirdHerd, un ulteriore servizio sempre basato su web del quale parlerò più avanti. Buffer mette a disposizione anche un’app Android – sempre free – integrata nel fantastico menu “share” di Android, che consente di gestire lo stack editando i singoli elementi precedentemente creati e il loro ordine di pubblicazione.
Input: shared da gReader. Output: verso i miei account Twitter e Facebook, verso BirdHerd via DM.
Alternativa iOS: Buffer

• Tweriod • servizio web - freemium
Per usare al meglio Buffer e programmare i tweet e gli aggiornamenti in modo tale da ottenere la massima attenzione dai nostri follower, ci viene in supporto Tweriod. Si tratta di un servizio web in grado di analizzare l’attività degli account di chi ci segue su Twitter e da ciò suggerirci le fasce orarie migliori per pubblicare i nostri tweet, affinché ottengano la massima visibilità. Per ottenere l’analisi sarà sufficiente loggarsi a Tweriod con l’account Twitter dal loro sito web.
Input: account Twitter. Output: fasce orarie ottimali per twittare.

• Tweetdeck • applicazione Android e servizio web – free
A mio avviso il miglior client per Twitter – consente di postare anche su Facebook – in circolazione. Potentissime le sue funzioni, tra le quali cito ad esempio la possibilità di gestire svariati account Twitter e cinguettare lo stesso messaggio anche da più di uno, scheduling dei tweet, possibilità di gestire alert differenti per le singole colonne (le timeline degli account, degli hashtag, delle ricerche, delle citazioni). Che si può desiderare di più?
Input: da gReader.  Output: account Twitter o Facebook.
Alternativa iOS: Tweetdeck.

• ifttt ovvero “if this then that” • servizio web – free
Si tratta di una geniale applicazione web che consente di “mettere internet al lavoro per te”, parafrasando il loro slogan. Permette di interconnettere numerosi canali web, tra i quali proprio Google Reader, Buffer, delicious, Twitter, e feed RSS, ma la lista aumenta sempre più. Descriverlo qui sarebbe riduttivo, vi invito vivamente ad aprire un account e dare spazio alla fantasia. In questo contesto, io lo uso come già anticipato per creare dei nuovi bookmark in delicious dagli item starred di Google Reader.
Input: da Google Reader. Output: verso delicious.

• BirdHerd • servizio web – free (per ora)
@aborruso molto tempo fa introdusse noialtri TANTI all’uso di BirdHerd per aggiornare direttamente dai nostri rispettivi account Twitter quello di TANTO (@twanto). Una volta loggati su BirdHerd con l’account Twitter di gruppo, è possibile aggiungere i “contributori” (fino a un massimo di 10) ciascuno dei quali sarà poi in grado di pubblicare i tweet semplicemente inviando un DM all’account di gruppo stesso. Il messaggio verrà infine twittato, completato alla fine dalla firma del contributore. Qui un esempio. Quando dunque da gReader trovo un link interessante che voglio twittare come @twanto o @planetek o @altrageologia, mi sarà sufficiente mandare ai rispettivi account un DM con Tweetdeck o Buffer, il resto verrà da sé.
Input: da Buffer o Tweedeck. Output: verso account Twitter di gruppo.

In conclusione, chi come me consuma gran parte delle informazioni su piattaforma mobile, costruendo un workflow ben congegnato può al tempo stesso informarsi in maniera dinamica nell’arco della giornata (es. tempi morti durante le attese), condividere le cose ritenute più interessanti con i propri follower sui social network e conservarle sempre in maniera sociale con delicious. Tutto direttamente dal nostro smartphone, che la sera – assieme al PC – potremo tenere spento, e dedicarci alle altre cose – non digitali – che ci piacciono TANTO…

Posted in Entropia | No Comments »

14 febbraio, 2011 | di Alessio Di Lorenzo

Questo articolo nasce dall’idea di aprire una finestra su quella branca della geomatica che si occupa della condivisione e diffusione in rete dell’informazione geografica, comunemente indicata col termine webmapping e spesso protagonista su questo blog.
Prima di entrare nel vivo del discorso, però, vorrei precisare che quello proposto è il mio personale punto di vista, costruito nel tempo in base alla mia esperienza professionale in questo campo. Esistono altri strumenti e approcci diversi rispetto a quello che vedremo nel corso dell’articolo, quindi, come sempre, ogni commento sarà ben accetto e spunto di ulteriore riflessione.

Sicuramente si parla di una delle specializzazioni dei Sistemi Informativi Geografici che negli ultimi anni si sono trasformate più velocemente, complice l’evoluzione del World Wide Web e delle tecnologie legate ad esso. Si tratta, inoltre, di una materia fortemente interdisciplinare in quanto, a prescindere dall’ambito nel quale l’applicazione di webmapping verrà impiegata (turismo, analisi ambientale, monitoraggi di vario genere, ecc.), a monte ci sono le competenze di almeno quattro figure professionali differenti che comprendono l’esperto di GIS, il Database administrator, lo sviluppatore e il sistemista.

Ho pensato di scrivere un articolo come questo perché spesso mi capita di avere a che fare con persone interessate ad avvicinarsi a questo mondo o semplicemente curiose di sapere “cosa c’è sotto” ma messe in seria difficoltà dalla quantità, eterogeneità e frammentazione delle informazioni disponibili in rete.
Tutto ciò, insieme all’esistenza di una moltitudine di soluzioni software, di tanti standard reali e de facto, di moltissime filosofie e approcci diversi, crea un labirinto intricato in cui è facile smarrirsi specialmente se si è agli inizi.

La cartografia su internet diventa popolare

Un grande contributo all’esplosione della cartografia su internet è arrivato da alcune applicazioni web basate su mappe, come Google Maps, Google Earth, Yahoo! Maps, Virtual Earth (ora noto come Bing Maps), comparse relativamente pochi anni fa e divenute di massa nel giro di pochissimo tempo.
Lungi dall’essere delle applicazioni GIS in senso stretto, hanno comunque il merito di saper mostrare la forza del punto di vista spaziale: ogni oggetto, se collocato nello spazio geografico, viene arricchito con nuove informazioni intrinseche nella sua localizzazione e nella relazione con gli altri oggetti che si trovano nelle sue vicinanze.
La potenza espressiva della cartografia su internet, per la prima volta sotto gli occhi di tutti e non dei soli addetti ai lavori, ha dato un importante input per il cambio di passo che ha condotto alle moderne applicazioni di webmapping.
Certamente questa direzione si è potuta intraprendere anche grazie all’aumento delle capacità di elaborazione dei browser e alla crescita degli strumenti e delle tecnologie per lo sviluppo delle applicazioni web, alcuni dei quali ideati e rilasciati dagli stessi soggetti titolari delle famose mappe online (si pensi, ad esempio, alle API di Google Maps).
Le vecchie cartografie web, oltre ad essere accessibili a pochi, richiedevano spesso tempi di caricamento lunghi o l’installazione di plug-in sulla macchina dell’utente. Le recenti applicazioni di webmapping, invece, beneficiano di uno spiccato livello di interattività e reattività, caratteristiche tipiche delle applicazioni Web 2.0 che sfruttano tecnologie come AJAX e si integrano alla perfezione nell’ecosistema del web moderno, composto da social network, feed RSS e servizi di varia natura.

Standard è bello… e pratico

Una ulteriore spinta alla diffusione di questa nuova generazione di applicazioni di webmapping è venuta dall’affermarsi di standard aperti, documentati e condivisi messi a punto dall’Open Geospatial Consortium (OGC).
Le maggiori case produttrici di software GIS, nonché le comunità open source con i loro innumerevoli progetti, hanno implementato nei loro prodotti il supporto ai principali standard OGC (WMS, WFS, WCS, ecc.) favorendo l’interoperabilità. Chi progetta e sviluppa applicazioni di webmapping oggi ha la possibilità di mescolare risorse disponibili in rete e risorse locali, di utilizzare tecnologie e piattaforme differenti in grado, però, di scambiare informazioni grazie al rispetto degli standard e di ottenere così degli efficacissimi mash-up tramite i quali diffondere l’informazione spaziale.

Lato server

A prescindere dai dati, preferibilmente mantenuti in un RDBMS spaziale (come PostGIS o Oracle Spatial), salvo situazioni particolari un’applicazione di webmapping ha generalmente bisogno di due componenti che operano sul server: il web server e il map server.
Il web server, come Apache, solo per citare il più diffuso e più famoso, è l’ambiente che renderà possibile la pubblicazione del lavoro e accoglierà le richieste provenienti dall’applicazione client (quella con cui l’utente interagisce) per passarle al map server. Quest’ultimo, per dirla in maniera molto sintetica, interpreta tali richieste e produce di conseguenza degli output (le mappe) che vengono spedite al client di nuovo attraverso il web server. Ovviamente questo è uno schema generale ed anche se formalmente corretto (ricalca il funzionamento di UMN-MapServer, che è uno dei map server più validi e versatili), occorre tenere presente che ogni software appartenente a questa categoria ha le proprie modalità specifiche di azione. Geoserver ed ArcGIS Server sono altri due ottimi esempi, il primo è gratuito ed open source, come lo è anche UMN-MapServer, mentre l’altro è un prodotto proprietario distribuito da ESRI.
Prima di chiudere la breve panoramica sugli strumenti lato server, è bene ricordare che nel caso delle applicazioni di webmapping più avanzate è necessario avere a disposizione anche un linguaggio di programmazione (Java, PHP, Python, ecc.) per organizzare la logica di business, cioè l’insieme degli algoritmi che gestiscono lo scambio di informazioni tra il client e la banca dati. UMN-Mapserver, ad esempio, è completo di API (Application Programming Interface) per i principali linguaggi di programmazione, mentre ArcGIS Server propone due ADF (Advanced Development Framework) per Java e .Net.

Lato client

Il client, come anticipato nel precedente paragrafo, è quella parte dell’applicazione con cui l’utente finale interagisce. Questo “strato” ha, perciò, un ruolo fondamentale nel decretare il successo o insuccesso dell’intera applicazione. Senza un client efficace che metta in risalto gli strumenti più importanti offerti all’utente e lo prenda quanto più possibile per mano nel compiere le operazioni che lo porteranno ad ottenere la risposta desiderata (un’estrazione di dati tramite interrogazione, l’analisi di una determinata variabile ambientale, ecc.), si rischia seriamente di vanificare gli sforzi profusi nella progettazione e implementazione del database e degli algoritmi lato server.
E’ ovvio che, pur progettando un client ideale, non è sempre possibile raggiungere la massima facilità di utilizzo, poiché tutto è influenzato dal numero delle funzionalità offerte, dalla loro complessità, dal tipo di utenti a cui ci si rivolge e da diversi altri fattori. Tuttavia un’interfaccia utente intuitiva è il risultato a cui si dovrebbe tendere quando si inizia a progettarla.

Come si realizza il client? Le soluzioni sono tantissime, dai template html di UMN-Mapserver, ai framework in PHP come p.Mapper (sempre per UMN-Mapserver) che mettono a disposizione un client con dei moduli dinamici lato server (PHP MapScript), a librerie Javascript come OpenLayers, di cui si è spesso parlato qui su TANTO.
Personalmente preferisco l’ultima soluzione in quanto costruire il proprio client da zero usando una libreria Javascript (OpenLayers non è l’unica), sebbene possa essere inizialmente più laborioso rispetto alla configurazione di un framework come p.Mapper, presenta degli indubbi vantaggi.
Sorvolando sulla valenza didattica del costruire una ad una le funzioni attivate dai vari tasti di una toolbar, ci si rende conto della bontà della scelta quando quello che offre un framework out of the box non basta più e si deve procedere ad un lavoro di personalizzazione/integrazione. Spesso modificare il comportamento di un software complesso, legato ad una specifica piattaforma (UMN-MapServer e PHP MapScript, nel caso di p.Mapper), che comprende numerosi script interconnessi tra loro richiede uno sforzo ben superiore a quello necessario per scrivere da zero una nuova funzione che faccia uso di una classe della libreria OpenLayers (oppure delle API di Google Maps o ArcGIS Server).
Un altro vantaggio – sempre nel caso in cui si scelga di lavorare con Javascript – è che si semplifica di molto l’integrazione nell’interfaccia di librerie per la costruzione di Rich Internet Application (RIA), come jQuery, Dojo, Mootools, YUI o ExtJS, ottime per la creazione di tutti quei piccoli espedienti che rendono il client efficace (nell’accezione usata in precedenza). C’è davvero l’imbarazzo della scelta.

Considerazioni conclusive

Come dicevo in apertura, ci si può discostare anche di molto da quasi tutti gli strumenti elencati e da questo approccio senza per questo sbagliare. Tuttavia nelle prime fasi è utile individuare e chiarire dei concetti specifici, imparare a padroneggiare gli strumenti per muoversi con disinvoltura e poi, in seguito, avventurarsi e testare soluzioni alternative e sempre più originali. In ogni caso alcuni punti, come la creazione di un client intuitivo o il rispetto degli standard, hanno una valenza generale e andrebbero sempre tenuti in debita considerazione a prescindere dalle scelte che si opereranno. Non mi resta che augurare buon divertimento a tutti.

Posted in Didattica | 28 Comments »

12 luglio, 2010 | di Antonio Falciano

E’ appena trascorso un mese dall’entrata in esercizio del primo portale Open Data italiano, dati.piemonte.it, il quale è stato accolto favorevolmente dagli entusiasti sostenitori italiani del movimento Open Data ed addirittura classificato come portale governativo di prima categoria dal gruppo PSI (Public Sector Information) della Commissione Europea, in quanto garantisce l’accesso diretto ai dati, analogamente a data.gov.

Pur trattandosi di una versione beta, rappresenta indubbiamente una pietra miliare che dimostra la fattibilità dell’Open Data anche in Italia, nonostante le difficoltà di cui si accennava in questo recente post.

Ma vediamo in dettaglio di cosa si tratta. La pagina di accesso al portale si presenta con una grafica semplice ed accattivante su cui campeggia in primo piano il principio di fondo dell’iniziativa, una vera e propria dichiarazione di intenti in perfetto stile Government 2.0 ed in completo accordo con il senso della Direttiva 2003/98/CE del Parlamento europeo:

I dati pubblici sono di tutti
I dati in possesso della Pubblica Amministrazione sono un patrimonio informativo prezioso per la società e l’economia. La Regione Piemonte intende metterli a disposizione di cittadini e imprese per stimolare un nuovo rapporto fra pubblico e privato e favorire lo sviluppo di iniziative imprenditoriali.

A valle di questa esaltante premessa, seguono immediatamente pochi ma efficaci menù che rimandano ai contenuti del portale, dopodiché si va direttamente al sodo, accedendo direttamente ad un piccolo assaggio dei dati grezzi finora messi a disposizione, ad un estratto delle discussioni più recenti nel blog ed, infine, ad una sezione dedicata al riuso dei dati pubblici, dotata di una presentazione multimediale esplicativa sull’argomento.

Curiosando all’interno della sezione Dati, è possibile osservare che:

• al momento sono presenti solo alcuni set di dati, tuttavia assicurano che a questi se ne aggiungeranno progressivamente degli altri, anche su richiesta degli utenti;
• i dati grezzi sono descritti da metadati (informazioni sui dati);
• sono resi disponibili in formato CSV e, di conseguenza, sono consultabili mediante un qualsiasi editor di testo;
• sono aggregati a scala provinciale e, talvolta, comunale;
• è facile verificare come siano indicizzati nei principali motori di ricerca e quindi siano di facile reperibilità anche all’esterno del portale;
• infine, sono corredati di un contratto di licenza in cui si afferma chiaramente che la Regione Piemonte ne detiene la titolarità e ne “autorizza la libera e gratuita consultazione, estrazione, riproduzione e modifica [...] da parte di chiunque vi abbia interesse per qualunque fine, ovvero secondo i termini della licenza Creative Commons – CC0 1.0 Universal” (dominio pubblico).

Benissimo! Siamo certamente ancora distanti dalla mole impressionante di contenuti presenti in data.gov e data.gov.uk, tuttavia sono largamente rispettate in sostanza le indicazioni del Manifesto stilato da The Guardian, contenente a mio avviso un insieme minimo di principi pienamente condivisibile.

Il rilascio dei dati grezzi prodotti dalla PA – in formato aperto e con licenze che ne consentono il riuso – può produrre effetti benefici tanto nella trasparenza dei processi decisionali delle amministrazioni, quanto nella qualità dei servizi e nell’economia immateriale che vi ruoterebbe attorno. In particolare, i raw data costituiscono una risorsa dall’enorme potenziale nascosto, che è possibile far venire allo scoperto sfruttando le relazioni esistenti tra i dati in maniera originale e creativa in fase di produzione di nuovi servizi, magari ottenendo applicazioni assolutamente impensabili da parte degli stessi produttori di dati.

TANTO si occupa ormai da diverso tempo di sensibilizzare i suoi lettori verso l’utilizzo creativo ed appassionato dei vari strumenti del web 2.0 disponibili in rete, sottolineando come essi possano rappresentare un importante mezzo di sviluppo e di crescita sia per chi si occupa di geomatica, che per l’intera collettività. A tal fine, mi piace riportare alcuni stralci di un commento di Pietro Blu Giandonato relativo a questo interessante post:

esiste ormai sul web una messe di strumenti, applicazioni, servizi, fonti di dati formidabile, che sta crescendo vertiginosamente, e della quale non resta altro che coglierne le opportunità a piene mani. [...] In un paio d’ore, tra progettazione e realizzazione, è possibile tirare su un mashup potente, semplice e veloce per mettere in strada dati reperiti altrove da più fonti, o addirittura originali! [...] E’ necessario cambiare il paradigma della geomatica in Italia, passando dal GIS come unico strumento per la rappresentazione e gestione dei dati, arrivando a una sorta di “cloudmapping” realizzato con le decine di strumenti web 2.0 che esistono in giro. Una strada peraltro che richiede essenzialmente fantasia, creatività e intuito, che permette di costruire grandi cose con piccole azioni. Il problema è ovviamente immaginarle…

Così, mi sono chiesto: è possibile visualizzare i raw data piemontesi all’interno di una piccola applicazione di web mapping facendo in modo che i risultati delle interrogazioni siano dei bei grafici, piuttosto che noiosi numeri? Certamente! Ho scelto quindi i dati relativi alle dotazioni ICT presso i cittadini e ne ho effettuato il download accettandone le condizioni di utilizzo. Trattandosi di dati in forma tabellare, li ho semplicemente importati all’interno di un foglio di calcolo di Google Docs e poi pubblicati in modo tale che “chiunque abbia accesso a Internet possa trovarli e visualizzarli“, ottenendo la struttura seguente:

I dati prescelti possono essere analizzati secondo differenti chiavi di lettura (query). Ad esempio, è possibile risalire alle dotazioni ICT per provincia e per anno, così come alla singola dotazione per provincia negli anni 2005-2009. Mi sono posto pertanto il seguente obiettivo: individuare lo strumento web 2.0 più agevole per interrogare la tabella come all’interno di un database, in modo da poter estrarre di volta in volta solo i dati necessari per ottenere il grafico corrispondente ad una particolare query. Dopo vari tentativi con Yahoo! Pipes ed YQL (Yahoo! Query Language), peraltro abbastanza ben riusciti (li trovate qui), ho individuato nel Query Language delle Google Visualisation API un’alternativa relativamente semplice ed efficiente, tale da scongiurare la necessità di dover configurare un web server e risolvere le beghe informatiche dovute alle cross-domain restrictions. Si tratta praticamente delle stesse API che consentono di ottenere dei grafici a partire dai dati.

A proposito della componente geografica, ho deciso di utilizzare come client OpenLayers (di cui si parla spesso qui su TANTO) per via della sua enorme versatilità e semplicità d’uso, un servizio TMS (Tile Map Service) di OpenStreetMap come layer di base ( i “linked data” per eccellenza!), ed i confini ISTAT delle province reperibili qui, utilizzabili per scopi non commerciali a patto di citarne la fonte. Questi ultimi sono stati convertiti nel formato GML ed opportunamente trasformati nel sistema WGS84 (EPSG:4326).

In definitiva, il funzionamento dell’applicazione è molto semplice ed intuitivo: scelta una delle opzioni (query) poste in basso, per interrogare una delle province piemontesi occorre semplicemente cliccare sulla corrispondente entità vettoriale che la rappresenta in mappa. Comparirà successivamente un popup contenente la denominazione della provincia, il titolo del grafico ed il grafico stesso (dotato di legenda, se necessaria). Questo è il mashup risultante:

Per concludere, ho alcune interessanti novità da segnalare. Nel frattempo, negli altri Paesi il modello di Open Government procede inesorabilmente la sua marcia. In particolare, nel Regno Unito è stata appena istituita una Commissione per la Trasparenza nel Settore Pubblico con il compito di guidare l’agenda sulla Trasparenza del Governo, rendendola un elemento cardine di ogni sua attività e assicurando che tutti i Dipartimenti presso Whitehall rispettino le scadenze fissate per il rilascio di nuovi dataset pubblici. Inoltre, è responsabile della definizione di standard sui dati aperti per l’intero settore pubblico, recependo ciò che è richiesto dal pubblico e assicurando l’apertura dei dataset più richiesti. Un primo importante compito della Commissione attualmente in itinere consiste nella definizione dei Principi di Trasparenza dei Dati Pubblici mediante il diretto coinvolgimento degli utenti.

Un’altra novità di rilievo è la nascita del portale italiano CKAN, un progetto ad opera della Open Knowledge Foundation. Si tratta di un catalogo di dati e contenuti aperti creato allo scopo di facilitarne la ricerca, l’uso e il riuso, al quale è possibile contribuire liberamente, fornendo informazioni sulle banche dati (metadati), quali l’URL della risorsa, l’autore e il soggetto che detiene la titolarità dei dati, la versione e la licenza d’uso.

Sempre in Italia, un’altra notizia che fa ben sperare: il Ministro per la Pubblica Amministrazione e l’Innovazione, durante un’intervista a Frontiers of Interaction 2010, ha annunciato la creazione di un data.gov italiano entro la fine dell’anno. In particolare, la pubblicazione dei dati pubblici dovrebbe servire da contromisura ai fenomeni di corruzione legati agli appalti. Finalmente!

Posted in Dati | 7 Comments »

25 aprile, 2010 | di Alessio Di Lorenzo

Tempo fa scrissi un articolo su ArcGIS Server 9.3 soffermandomi sui servizi REST e le API Javascript ed accennando al fatto che ESRI mette a disposizione delle estensioni per le API di Google Maps e per quelle di Bing Maps.
Ultimamente ho lavorato un po’ con le prime e ne ho avuto complessivamente una buona impressione. Tuttavia, durante lo sviluppo, ho riscontrato un problema nella misurazione delle distanze e delle aree che merita di essere messo in evidenza, soprattutto perché gli esempi della documentazione ESRI non lo fanno a dovere ed anzi, secondo me, risultano leggermente fuorvianti.
Terminata la premessa, prima di andare avanti con l’articolo, voglio ringraziare Domenico Ciavarella, che mi ha dato un supporto fondamentale per arrivare ad una soluzione che altrimenti starei ancora cercando.

La proiezione di Google Maps

Google Maps, Bing Maps ed altri provider (come OpenStreetMap, Yahoo e, di recente, la stessa ESRI) utilizzano una proiezione nota come Spherical Mercator, derivata dalla proiezione di Mercatore. Il codice EPSG ufficiale è 3785, anche se prima della sua definizione molti software hanno utilizzato l’ufficioso 900913. L’identificativo per i software ESRI, tra cui ovviamente ArcGIS Server, è invece 102113.
Questa proiezione considera la Terra come una sfera e consente di includerne completamente la superficie all’interno di un quadrato.
Quando però si rappresenta una superficie curva su di un piano, come un foglio di carta o il monitor di un computer, si introducono delle deformazioni. In questo caso, man mano che ci si allontana dall’equatore le aree cartografate subiscono un pesante stiramento sia in senso verticale che orizzontale e diventano, quindi, via via più esagerate verso i poli (la Groenlandia, per esempio, sembra più grande dell’Africa). Questa proiezione evidentemente non è fatta per minimizzare la deformazione delle aree (la proiezione di Mercatore è conforme infatti), ma risulta vantaggiosa per l’uso attraverso il web perché consente di applicare un modello efficiente di tassellamento e caching.

Il problema…

Ammettiamo di voler creare un’applicazione di webmapping con le sopracitate estensioni delle API Javascript di ArcGIS Server per Google Maps.
La prima cosa da fare è creare un mapservice in grado di esporre i nostri dati spaziali con la medesima proiezione delle basi cartografiche di Google. Come spiegato nel post dedicato ad ArcGIS Server (linkato all’inizio di questo articolo) un mapservice “aggancia” e pubblica un progetto redatto in ArcMap (il classico .mxd), quindi basta assegnare al dataframe del progetto il sistema di riferimento appropriato (che si trova nella lista dei sistemi proiettati, alla voce WGS 84 Web Mercator, con identificativo 102113), salvare il tutto e pubblicarlo con ArcGIS Server. Niente di difficile insomma.
Focalizziamoci ora sullo sviluppo del client: tra i tanti strumenti che oggi ci si aspetta di trovare in una applicazione WebGIS ci sono i “righelli” che consentono di disegnare spezzate e poligoni e di misurarne poi lunghezza ed area. ESRI lo sa, ed ha giustamente incluso un esempio per mostrare come creare questi tool nella documentazione delle sue API.
Abbiamo detto però che l’uso della proiezione Spherical Mercator provoca una deformazione crescente man mano che ci si spinge verso i poli e, tracciando una spezzata per misurare un oggetto al suolo di dimensioni note, come uno stadio di calcio, ci si accorge dell’inghippo: è più lungo di quanto dovrebbe essere (circa 146 metri invece di 105-110).
L’esempio fornito da ESRI non considera la deformazione e può indurre gli sviluppatori all’errore. E’ vero che una persona con le adeguate conoscenze di geomatica può arrivare ad intuire il rischio insito nell’uso della proiezione di Google, ma è anche vero che il webmapping è terra di confine tra “gissologi” e sviluppatori informatici “puri”, senza particolari cognizioni tipiche del mondo gis. Non è per nulla detto, quindi, che chi sviluppa abbia i mezzi per immaginare il problema prima di averci sbattuto il muso e personalmente credo che aver pubblicato un esempio del genere nella documentazione ufficiale, senza neanche accennare alla questione della deformazione, sia stata una leggerezza.

…e la soluzione

Non molto tempo fa sul blog di ArcGIS Server è comparso un interessante post che mette in evidenza il problema della misurazione delle distanze e spiega come comportarsi per risolverlo.
Il servizio che in ArcGIS Server è incaricato di calcolare lunghezze ed aree, il Geometry Service, è in grado di svolgere diverse altre operazioni, tra cui la proiezione al volo delle geometrie.
Il “trucco” consiste nel riproiettare la geometria tracciata dall’utente nel sistema di riferimento più adatto alla zona mappata prima di effettuarne la misurazione e stampare a schermo il risultato.
Purtroppo lo snippet di codice fornito da ESRI è pronto all’uso solo per le API Javascript, mentre per le estensioni di Google Maps bisogna fare da soli e il discorso è un po’ meno semplice.
Al posto di questa funzione:

var sr = new esri.SpatialReference({wkid:32610});
geometryService.project([graphic], sr, function(projectedGraphic) {
geometryService.areasAndLengths(projectedGraphic, function(result) {
var perimeter = result.lengths[0];
var area = result.areas[0];
});
});

abbiamo bisogno di questa:

var geometryService = new esri.arcgis.gmaps.Geometry("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer");
function calculateLengths() {
//Parametri per la riproiezione
var params = new esri.arcgis.gmaps.ProjectParameters();
params.geometries = [polyline];
params.inSpatialReference  = 4326;
params.outSpatialReference = 3004; //Gauss-Boaga fuso Est
//Riproiezione e funzione di callback
geometryService.project(params, getLengths);
}
function getLengths(projectResults){
var url = "http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer/lengths";
var parameters = {
polylines: projectResults.geometries,
sr: 3004
};
esri.arcgis.gmaps.JSONRequest(url, test, parameters);
}
function test(result) {
alert(result.lengths[0]+" m");
}

Ho realizzato un veloce esempio che mostra i risultati ottenuti dal codice proposto da ESRI nella propria documentazione a confronto con quelli ottenuti dalla riproiezione con il Geometry Service e dalle semplici API di Google Maps, che hanno dei metodi propri per la misura di linee e poligoni.

Posted in Didattica | 4 Comments »

1 marzo, 2010 | di Alessio Di Lorenzo

Era da un po’ che avevo in mente di dedicare un articolo a jQuery, finalmente – complici l’influenza che mi ha tenuto a riposo forzato e l’ispirazione tratta da Linfiniti – sono riuscito nell’intento.

Per chi non lo sapesse, jQuery è un framework Javascript open source molto potente, caratterizzato da una sintassi snella e di facile comprensione.
Il framework è rilasciato con doppia licenza: MIT e GPL.
I motivi per usare jQuery nei propri progetti non mancano di certo: comunità attiva, disponibilità di molti temi e ottimi plugin, compatibilità e leggerezza sono i primi che mi vengono in mente.

In questo articolo vedremo come costruire una mappa online sfruttando jQuery UI e OpenLayers.
Il risultato della “fusione” è un client dotato di funzionalità di base come zoom, pan, misurazione delle distanze e vari layer di sfondo intercambiabili.
Si tratta, in pratica, di un template da cui partire per sviluppare applicazioni di web-mapping vere e proprie.

Per creare il client dell’esempio abbiamo bisogno di:

• OpenLayers
• jQuery UI, pensato per creare widget personalizzati con jQuery
• jQuery UI.Layout, un plugin ispirato al border layout di ExtJs
• qTip, un plugin per modellare dei tooltip avanzati

Ho già raccolto il tutto in questo archivio .zip. Qui dentro, oltre alle librerie, si trova la totalità dei file che compongono il client. Vi basta quindi cliccare sul link per avere il template sul vostro computer, pronto all’uso e/o ad essere trasformato come volete.
Vi invito però a dare lo stesso un’occhiata alla pagina di download di jQuery UI: noterete che è possibile modificare radicalmente il pacchetto prima di scaricarlo. Potete includere le sole componenti utili ai vostri scopi e scegliere tra vari temi già pronti o uno composto da voi con ThemeRoller.
Io ho fatto solo qualche semplice modifica al tema UI-Darkness (in questo periodo non mi piacciono i bordi arrotondati…) ma, come dicevo, si può fare molto di più. Provare per credere.

Ora un po’ di anatomia.
Scompattato l’esempio, è bene posare lo sguardo su alcune delle directory e dei file compresi al suo interno.

jsLib

E’ la directory contenente tutte le librerie elencate in precedenza, necessarie al funzionamento del template.

index.html

Nella sezione header sono referenziate le librerie utilizzate, i fogli di stile e i file javascript.
Nel body è possibile notare che l’attributo class di molti degli elementi della pagina (div, button, span, ecc.) è parecchio popolato. Questo è il metodo con cui jQuery UI e jQueryUI.Layout si “ancorano” alla pagina web.
Per comprendere meglio vi rimando alla pagina degli esempi di jQuery UI.Layout e a questo articolo che spiega in maniera egregia la composizione della toolbar e dei suoi pulsanti.

jsFunc/mappa.js

Contiene la mappa realizzata con OpenLayers.
Nella funzione di inizializzazione (initMap) richiamata al caricamento della pagina, ci sono, tra le altre cose, i controlli collegati ai bottoni della toolbar.

jsFunc/layout.js

In questo script, con poco più di 40 righe di codice, jQuery UI e i suoi plugin definiscono Il layout dell’applicazione, il tema, il comportamento e l’aspetto di bottoni e tooltip.

Css/style.css

A parte qualche piccola “frivolezza” come queste (a mio giudizio) bellissime icone, in questo foglio di stile sono descritte le regole fondamentali per la corretta presentazione del layout e della toolbar creati tramite jQuery UI.

Ecco, questo è grossomodo ciò che bisogna sapere per iniziare a studiare i mille modi di mescolare le potenzialità di jQuery a quelle di OpenLayers.
Fondamentale, come sempre, è il ricorso alla documentazione ufficiale dei vari progetti e al supporto offerto dalla comunità.
Per chiudere segnalo anche due guide in italiano, estremamente ben fatte ed utilissime per avvicinarsi a jQuery e jQuery UI. Entrambe sono firmate HTML.it:
Guida a jQuery
Guida a jQuery UI

Posted in Didattica | 10 Comments »