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 »

All’uscita del primo bell’episodio di Geospatial Revolution Project qualcosa mi aveva lasciato perplesso, ma non capivo cosa. Dopo qualche ora e qualche email (un ringraziamento particolare a Sergio Calabrese) ho realizzato che gli “mancava la parola”. Un prodotto di divulgazione così ben fatto, che merita la diffusione nelle scuole, sarebbe stato ancora più efficace se corredato dai sottotitoli in lingua originale. Nei giorni successivi molti utenti hanno scritto alla Pennsylvania State University per sollecitare la pubblicazione dei sottotitoli, ed dopo poche settimane erano presenti sul canale ufficiale di YouTube. Ma l’appetito viene mangiando.

La presenza dei sottotitoli infatti ci ha fatto venire subito la voglia di tradurli in italiano. Abbiamo scritto ai responsabili del progetto per chiedere “ufficialmente” di farlo e dopo qualche ora abbiamo ricevuto un’email dai toni molto gentili e con in allegato il file .xml con i sottotitoli in inglese. Lo abbiamo tradotto ed oggi finalmente è possibile “leggerlo” in italiano (anche qui sotto).

Un’ultima annotazione  forse un po’ autocelebrativa (mi scuso): fa un certo effetto essere in questo elenco, che inizia con la “A” di ASPRS Foundation e finisce con la “W” di Where 2.0.

Posted in Didattica | 4 Comments »

Python (http://python.org) è un linguaggio di programmazione di alto livello, adatto ai più svariati obiettivi di programmazione. Viene usato per applicazioni web e desktop, giochi, programmazione scientifica, utility e anche per porzioni di sistemi operativi.
Anche chi ha la necessità di sviluppare delle applicazioni in grado di leggere, scrivere, analizzare ed elaborare dati ed informazioni spaziali, troverà in Python un compagno di viaggio piacevole, eclettico e ricco di pregi. Chi lavora in questo contesto e segue il mondo della programmazione, sa che si tratta di un linguaggio che sta diventando tra i più diffusi, sia nel mondo proprietario che in quello open-source, con a disposizione numerose librerie ad hoc.
Anche per questo, penso sia arrivato il momento (anzi mi sento in grande ritardo) di scrivere un post che fornisca gli strumenti per iniziare a “sporcarsi le mani”.
In linea teorica è possibile scrivere da zero codice Python che consenta di manipolare dati spaziali. Per fortuna esiste – tra le tante librerie disponibili –  il binding Python di GDAL/OGR; per iniziare è molto più comodo appoggiarsi sulle spalle di questo gigante.
Due annotazioni prima di passare agli aspetti pratici:

• questo post consentirà di configurare Python e GDAL/OGR in ambiente Windows. Confido in qualche collega della redazione per scrivere le istruzioni utili per altri sistemi operativi
• verrà descritta una delle tante modalità possibili per configurare l’ambiente

Procedura

Installare GDAL per Python su Windows è un processo semplice, che può essere portato fino in fondo, seguendo la seguente procedura:

• Scaricare l’installer di Python dal sito ufficiale – http://www.python.org/download/ – ed installarlo. E’ possibile scaricare diverse release; noi abbiamo effettuato i nostri test con gli installer della 2.6.x
• Installare GDAL/OGR per Windows
  • Scaricarlo da http://download.osgeo.org/gdal/win32/. Abbiamo utilizzato il file “gdalwin32exe160.zip” che si trova nella cartella “1.6”.
  • Decomprimere questo file in una cartella del vostro PC. L’abbiamo estratta in C:\ ed abbiamo quindi creato la cartella C:\gdalwin32-1.6.
  • Aggiungere la cartella di GDAL che contiene gli eseguibili (“C:\gdalwin32-1.6\bin” nel nostro caso) alla variabile di ambiente  “Path”.
    • Aprire il “Pannello di controllo” di Windows
    • Fare click su Sistema (se usate la visualizzazione per categorie, “Prestazioni e manutenzione” e poi “Sistema”).
    • Fare click su Avanzate
    • Fare click su “Variabili d’ambiente”.
    • Cercare la voce “Path” tra le “Variabili di sistema” e cliccare su Modifica.
    • Fare click sulla cella “Valore variabile”, andare in fondo alla riga, aggiungere un “;” ed inserire il percorso completo della cartella “bin” della vostra installazione di GDAL (C:\gdalwin32-1.6\bin nel nostro caso).
    • Fare Click su OK.
      
  • Aggiungere “GDAL_DATA” come nuova variabile d’ambiente.
    • Fare click su “Nuovo” nella finestra “Variabili d’ambiente”.
    • Inserire “GDAL_DATA” nel campo “Nome variabile”.
    • Inserire il percorso completo della cartella data di GDAL nel campo “Valore variabile” (nel nostro caso “C:\gdalwin32-1.6\data”).
    • Fare click su “OK”. Aggiungeremo più avanti altre variabili d’ambiente, quindi potete tenere aperta questa finestra di dialogo.
      

• Installare PROJ.4 per Windows. E’ un pacchetto necessario per potere gestire le proiezioni ed i sistemi di coordinate.
  • Scaricare PROJ.4 da http://download.osgeo.org/proj/. Il file binario per Windows – proj446_win32_bin.zip – non è aggiornatissimo, ma non è un problema.
  • Decomprimere questo file in una cartella del vostro PC, ad esempio in “C:\proj”.
  • Aggiungere la cartella “bin” di PROJ.4 (“C:\proj\bin” nel nostro caso) alla variabile di ambiente “Path”. Per farlo dovete seguire gli stessi passi visti sopra per la cartella “bin” di GDAL, ed aggiungere stavolta “C:\proj\bin”.
  • Aggiungere “PROJ_LIB” come nuova variabile d’ambiente. Dovete seguire le stesse istruzioni usate per la variabile “GDAL_DATA”, ma il nome della variabile è stavolta “PROJ_LIB”, ed il valore è il percorso completo della cartella “nad” contenuta in  PROJ.4 (C:\proj\nad nel nostro caso).
  • Copiare il file “proj.dll” dalla cartella “bin” di PROJ.4 alla cartella bin di GDAL. Nel nostro caso da “C:\proj\bin\” a “C:\gdalwin32-1.6\bin\”.
• Installare il binding per Python di GDAL
  • Scaricare la versione appropriata alla vostra release di Python da http://pypi.python.org/simple/GDAL/.  Il file più aggiornato, compatibile con la versione 2.6.X di Python, è “GDAL-1.6.1.win32-py2.6.exe”.
  • Fare doppio click sul file, e completare la procedura di installazione
• Riavviare il sistema.

Al riavvio avrete a disposizione un sistema in cui sarà possibile scrivere codice SPAZIALE (nel senso di bel codice  ).

Ciao mondo

Il codice sottostante lo potrete usare come test “Ciao Mondo”, e verificare la procedura seguita.

# importazione dei moduli
import sys
try:
  from osgeo import ogr
except:
  import ogr
	
# apertura di uno shapefile in lettura
driver = ogr.GetDriverByName('ESRI Shapefile')
fn = 'C:/nomefile.shp'
dataSource = driver.Open(fn, 0)
	
# verifica dell'esistenza del file
if dataSource is None:
  print 'Il file ' + fn + ' non esiste'
  sys.exit(1)
	
# accesso al layer
layer = dataSource.GetLayer()
	
# conteggio delle feature
numFeatures = layer.GetFeatureCount()
print 'Numero di feature: ' + str(numFeatures)
	
# estensione del layer
extent = layer.GetExtent()
print 'Estensione:', extent
print 'Coordinate vertice in alto a sinistra:', extent[0], extent[3]
print 'Coordinate vertice in basso a destra:', extent[1], extent[2]

L’output sarà qualcosa di simile a quanto riportato sotto:

Numero di feature: 33
Estensione: (280151.67957063887, 294843.14350770513, 4210159.3865045626, 4220843.5284850718)
Coordinate vertice in alto a sinistra: 280151.679571 4220843.52849
Coordinate vertice in basso a destra: 294843.143508 4210159.3865

Buone letture

La procedura descritta in questo post è quasi una traduzione dell’eccellente documento scritto da Chris Garrard: “Installing GDAL manually”. Il dott. Garrard cura un corso denominato “Geoprocessing with Python using Open Source GIS“, di cui trovate online il materiale didattico (slide, esercizi e codice); è stato per me illuminante per fare i primi passi e consiglio a tutti i novizi di leggerlo: ASSOLUTAMENTE DA NON PERDERE (si, sto urlando).
Per chi non ha mai scritto codice Python, e non ne ha alcuna conoscenza, la pietra miliare è (per me) “Pensare da informatico“.

Buoni propositi

Il desiderio mio (e credo dei colleghi della redazione) è quello di non lasciare questo post da solo. Nel 2011 vorrei mettergli accanto dei fratellini; non saranno magari dei ricchi tutorial, ma la coppia GIS & Python sarà uno dei temi che terremo sotto osservazione e di cui daremo nota nel blog e/o soltanto nei canali Twitter e Facebook.

Buona scrittura

Posted in Didattica, osgeo | 2 Comments »

Oggi ricade il trentennale del terremoto del 23 novembre 1980, noto anche come il “terremoto dell’Irpinia” , i cui effetti devastanti colpirono una vasta area dell’Italia meridionale, posta a cavallo delle province di Avellino, Salerno e Potenza, mietendo quasi 3000 vittime. Tra le immagini indelebili ancora scolpite nella mia memoria di potentino vi è quella dell’orologio del Palazzo del Governo a Piazza Mario Pagano che si è fermato alle 19:34, l’ora esatta in cui la terra ha cominciato a tremare per 90 interminabili secondi. Quel quadrante rotto rappresenta l’emblema di una profonda ferita che ancora oggi non si è rimarginata del tutto.

Trenta anni fa non esisteva ancora il Sistema Nazionale di Protezione Civile, così come lo conosciamo oggi, e si nominò un Commissario Straordinario allo scopo di fronteggiare l’emergenza e coordinare i soccorsi delle popolazioni interessate dal terremoto, che entrò in servizio solamente 24 ore dopo la catastrofe. Gli eventi sismici molto recenti verificatisi in Abruzzo (aprile 2009) e ad Haiti (gennaio 2010), così come altre calamità naturali, dimostrano come la celerità degli interventi durante le prime ore di soccorso sia fondamentale nel salvataggio di vite umane. Una risposta tempestiva e efficiente della Protezione Civile può fare la differenza, ma tutto ciò non può e non deve bastare.

“L’Italia è un paese di santi, poeti, navigatori…” e purtroppo anche di terremoti. Basti pensare che nell’arco di un mese si verificano generalmente diverse centinaia di eventi sismici che interessano la quasi totalità del nostro Paese (si salvano la Sardegna e la penisola salentina), dei quali fortunatamente la maggior parte è percepita solo a livello strumentale e non dalla popolazione. Dobbiamo pertanto saperci convivere proprio come avviene in altri paesi evoluti, come il Giappone o la California, senza farci cogliere del tutto impreparati, come avveniva in passato.

La comunità scientifica internazionale allo stato attuale non ha ancora individuato un modello attendibile di predizione dei terremoti, pur essendo attivi promettenti filoni di ricerca basati sullo studio dei precursori sismici, anche mediante l’impiego di immagini telerilevate. Premesso ciò, il migliore approccio possibile da seguire consiste nella mitigazione del rischio sismico attraverso la corretta applicazione delle norme sulle costruzioni e l’adozione di criteri costruttivi tali da scongiurare il pericolo di crollo degli edifici, tenendo conto della mappa di pericolosità sismica del territorio nazionale – una delle più avanzate in Europa – e recependo gli studi di microzonazione sismica all’interno degli strumenti urbanistici comunali, in modo da disincentivare il più possibile l’edificazione nei siti potenzialmente oggetto di fenomeni di amplificazione locale. L’insieme di questi strumenti di rilevante importanza preventiva può essere inoltre utilizzato per trasmettere alla popolazione le nozioni di base del rischio sismico, ovvero una maggiore consapevolezza del fenomeno in modo da poterlo affrontare correttamente.

Diffondere informazioni scientifiche aggiornate e tali da consentire una conoscenza approfondita del territorio è il miglior strumento per avviare strategie di prevenzione e riduzione dei rischi naturali.

E quale occasione migliore per apprendere questi concetti, se non in tenera età? Assolutamente in questa direzione vanno alcune iniziative dell’INGV (Istituto Nazionale di Geofisica e Vulcanologia) finanziate dal Dipartimento nazionale della Protezione Civile. Mi riferisco in particolare al progetto EDURISK, nato circa una ventina di anni fa ad opera di un gruppo di ricercatori del GNDT (Gruppo Nazionale per la Difesa dei Terremoti, confluito nel 2001 nell’INGV), che coinvolge esperti nel settore dello studio e della riduzione dei rischi naturali, dei vari settori disciplinari attinenti (geologia, sismologia, pericolosità sismica, ingegneria sismica, sismologia storica, psicologia dell’emergenza), uno staff di progettazione educativa proveniente dall’editoria scolastica e multimediale, autori di libri per ragazzi, disegnatori, illustratori, fumettisti ed esperti di didattica. L’obiettivo principale del progetto EDURISK consiste nel mettere in campo i ricercatori, la scuola e tutti i cittadini, coinvolgendoli in un progetto di formazione e scoperta del rischio sismico. In particolare, il frutto di tale iniziativa consiste nella pubblicazione di libri, opuscoli e dvd a supporto del progetto formativo di diffusione delle conoscenze sul rischio sismico e vulcanico (materiale didattico). Il progetto è, inoltre, presente nei principali social network (Facebook, Twitter, Anobii e YouTube). Per ulteriori dettagli, si rimanda direttamente al portale del progetto. Di recente, EDURISK ha prodotto la docufiction “Non chiamarmi Terremoto”, che affronta temi quali la prevenzione, il rispetto per le norme sismiche e i comportamenti corretti da tenere in emergenza. Nel seguito, è possibile visionarne l’anteprima e questo è il sito dell’iniziativa.

D’altro canto, anche lo stesso INGV è presente su Twitter e YouTube. Nel primo caso si tratta di un servizio sperimentale di informazione sui terremoti in Italia (e non solo), mentre il canale su YouTube, molto interessante, prevede periodicamente degli aggiornamenti e la descrizione dell’attività sismica in corso, anche per spiegare alcuni aspetti della ricerca che viene svolta dai ricercatori dell’INGV.

Recentemente, qui su TANTO si scongiurava l’eventualità che il prof. Boschi, presidente dell’INGV, adottasse politiche restrittive sul rilascio dei dati di competenza dell’Istituto. E’ auspicabile, inoltre, che si continui nella direzione già abbondantemente tracciata nella diffusione capillare delle informazioni. Solo così si potrà contribuire efficacemente al raggiungimento di una sempre maggiore consapevolezza e conoscenza del fenomeno terremoto da parte dei ricercatori, dei tecnici e della popolazione.

Posted in Didattica | 4 Comments »

Ormai il racconto a puntate sulla rivoluzione geospaziale curato dalla Penn State University sta diventando un appuntamento per noi irrinunciabile. Per il primo episodio sono intanto disponibili i sottotitoli.

Non ci sarebbe nulla da dire di più che: guardatelo e godetevelo, ma ci piace comunque sottolineare brevemente alcune delle cose più belle e interessanti che vengono mostrate in questo secondo episodio.

Capitolo 1 – “Creating an interactive City”, ovvero di come Portland sia diventata una delle città più “digitali” degli USA, con ingenti investimenti nelle tecnologie geospaziali e l’iniziativa “civicApps” (se avete tempo vale la pena un suo approfondimento) con la quale i cittadini hanno la possibilità di segnalare mediante dispositivi mobili (scatta una foto, localizzala e commenta) situazioni che necessiterebbero di un intervento da parte del Comune. O ancora di come l’augmented reality consenta agli utenti del trasporto pubblico di Portland di essere costantemente aggiornati sugli orari di arrivo dei mezzi.

Nel Capitolo 2 – “Powering Business” un importante corriere afferma come sia fondamentale risparmiare anche un solo miglio di strada, per poter ottimizzare al massimo i costi. E’ per questo che hanno ingaggiato matematici e statistici per poter trovare modi e metodi per definire le rotte che ogni mezzo percorre quotidianamente. E in questo processo, ovviamente, le applicazioni GIS di tracking e routing hanno un ruolo fondamentale.

Avevamo già destato l’attenzione sul fatto che il futuro della medicina è nella geografia, e nel Capitolo 3 – “Finding a Healthy Future” viene dimostrato come l’analisi geografica dei bisogni delle persone, della loro salute e della disponibilità ad esempio di supermercati che vendano “cibi salutari” siano strettamente connesse. Senza trascurare le opportunità di sviluppo economico che l’analisi spaziale porta nella localizzazione di nuovi negozi.

Concludo con una frase di Cowen:

Nuove persone, nuove organizzazioni stanno costruendo applicazioni che non avremmo mai immaginato prima.

Applicazioni – ma soprattutto persone – che stanno crescendo in numero, e che sempre più ci stupiranno…

Posted in Didattica | No Comments »