Introduzione

Anni fa ho creato un aggregatore di feed RSS, con l’obiettivo di raccogliere le notizie provenienti dai blog italiani a tema GIS. L’ho fatto come “utilizzatore finale” (giuro che non è satira politica), per avere una fonte unica – e in particolare un solo feed RSS – da cui leggere notizie a tema. Gli associai anche un nome di fantasia: Blog GIS Italia.
Successivamente, quando TANTO era ancora un blog monoautore, l’ho inserito nel flusso di notizie di una delle colonne laterali del blog, e nel tempo ne ho curato (malamente) la manutenzione, l’aggiornamento del “motore” e quello delle fonti.

La sua ultima versione – che con un tocco di presunzione avevo classificato come “0.3” – era basata su Yahoo! Pipes e ne sfruttava pochissime funzioni (soltanto un po’ di regex sul titolo delle sorgenti degli RSS).

E’ uno strumento che mi è sempre stato utile, su cui desideravo investire un po’ di nuove risorse e dare finalmente vita alla versione “0.4”. Il momento è arrivato e nasce oggi, come progetto della redazione di TANTO, “Planet GIS Italia 0.4” (ebbene sì un nome un po’ diverso).

Planet GIS Italia 0.4

E’ una finestra sul mondo delle tecnologie e della cultura geospaziali, un punto di accesso e di scoperta centralizzato. Nulla di nuovo.

Esistono infatti già diversi aggregatori legati al mondo dei GIS. Tre esempi noti:

1. Planet OSGeo, is a window into the world, work and lives of OSGeo members, hackers and contributors;
2. Planet Geospatial, is a window into the world of geospatial technology;
3. geoblogger.eu, is a feed aggregator of European geo-blogs and should serve as index and leverage networking for geo-minded people in that region.

Il nome è cambiato perché sono cambiati i criteri di selezione: ci sembrava riduttivo quello di aggregare “soltanto” le notizie/post/articoli provenienti dal mondo dei blog. Sono la fonte principale, ma non sono l’unica, né sempre la più ricca.
Ogni aggregatore sottostà a dei criteri di selezione, e quello principale di Planet GIS Italia (da qui in poi PGI) è “spaziale”: i contributi raccolti vengono dal nostro Paese (non sempre in senso stretto). Un altro criterio è ovviamente quello tematico.
Il risultato è un sito snello, un piccolo “televideo” tematico, che per scelta editoriale non ingloba interamente i post originali, ma soltanto una piccola parte.

Una piccola/grande novità di questo aggregatore, che lo differenzia ad esempio dai tre famosi di cui sopra, è il suo essere “geografico” non soltanto per i temi trattati, ma anche nel suo “cuore”. Infatti sugli elementi dei feed RSS sorgenti viene eseguita una procedura di geoparsing, con l’obiettivo di estrarre le informazioni spaziali eventualmente presenti in essi. Si tratta essenzialmente di una “caccia al
toponimo” che (se va a buon fine) consente di arricchire il dato originale con un’informazione che inizialmente (quasi sempre) non era presente: la posizione sulla Terra.

Uno degli output è ovviamente una mappa, in cui vengono raccolti – ed eventualmente aggregati in cluster – gli elementi archiviati in PGI.

Non crediamo però che l’elemento geografico sia il più importante. Ci piace infatti pensare che questo spazio possa essere soprattutto una fonte di scoperta e un ponte tra persone, esperienze e professionalità. Nel lavoro di redazione, nel raccogliere e proporre gli elementi da aggregare qui, noi stessi abbiamo letto per la prima volta dell’esistenza di alcuni siti, abbiamo appreso nuovi concetti e siamo entrati in contatto con delle belle persone.

Come funziona Planet GIS Italia

Planet GIS Italia è basato su MANAGING NEWS, un motore open source per l’aggregazione di notizie con le seguenti caratteristiche di base:

• Aggrega da sorgenti RSS/Atom a scelta
• Mostra le notizie come lista o su una mappa
• Consente di eseguire delle ricerche
• Da la possibilità di raggruppare le notizie in canali
• Esegue il geotagging delle notizie
• Espone i contenuti raccolti via RSS (e GeoRSS)
• Consente di condividere i contenuti su Facebook, Twitter o per email

Managing News è un prodotto (da febbraio del 2011) di Phase2 Technology, basato a sua volta su una personalizzazione di alto livello di Drupal 6, con alle spalle moduli che ci piacciono tanto, tra i quali OpenLayers. Il gruppo che ha originariamente sviluppato il prodotto è quello (fantastico) di Development Seed (per inciso una delle più belle homepage di tutti i tempi), e se ne ha evidenza nell’uso di MapBox come layer di base dell’interfaccia cartografica.

Il servizio di geoparsing è basato su Yahoo! Placemaker, un servizio che consente di sviluppare applicazioni location-aware, identificando i luoghi presenti in contenuti non strutturati (feed, pagine web, news, aggiornamenti di stato, ecc.) e restituendo i metadati geografici correlati.
Ad ogni luogo individuato viene associato un identificatore univoco WOEID (Where On Earth Identifiers), un tipo (una categorizzazione di base, per definire ad esempio se il luogo è una città o uno stato), un nome “formale” ed una coppia di coordinate.

Immaginiamo ad esempio che su su Planet GIS Italia venga raccolto il seguente contributo:

“Opendata, donazioni, Baviera: conti e racconti”

Il motore di PGI lo invia a Yahoo! Placemaker che lo processa e gli restituisce (se viene individuato un luogo) queste informazioni:

• woeId : 2345482 → gli associa un ID
• type : State → lo classifica
• name : Bavaria, DE → gli associa un nome formale
• centroid → ne restituisce la posizione del centroide

• latitude : 48.9172
• longitude : 11.408

Questo è l’output completo che viene restituito. Se volete “giocarci” un po’, lo strumento più comodo e didattico è sicuramente la console YQL. Da questo link potrete aprirla precaricata con una query sintatticamente corretta e basata sulla stringa di sopra (una volta aperta la pagina, dovrete fare click sul tasto “TEST” che si trova sotto la query).

Se il processing geografico restituisce valori, questi vengono associati agli elementi dei feed in due modalità principali:

• l’associazione di un tag con il nome del/i toponimo/i individuati (vedi immagine sottostante)
• l’associazione di una (o più) coppia di coordinate in modo da poter rappresentare la notizia su una mappa

Le notizie per le quali non è individuato un luogo vengono inserite comunque nel sito, ma non potranno essere mappate. Se le fonti originarie contengono però nativamente delle informazioni geografiche in forma di GeoRSS, queste vengono utilizzate automaticamente per posizionare la notizia sulla mappa, anche nel caso in cui il geoprocessing non abbia prodotto risultati.

Con in nomi dei luoghi e con le lingue le cose però non sono così facili. Perché c’è Prato e anche prato. Grazie a PGI ho scoperto anche che c’è una destinazione di viaggio a Hong Kong che da molto fastidio all’analisi dei testi italiani: “Che Ha”. Ma mi fermo perché il tema è molto specialistico, ed è necessaria un’altra penna e un altro post.

Per familiarizzare con l’interfaccia del sito abbiamo preparato una breve videoguida, che ne illustra le caratteristiche principali.

Sui feed

Se fai una indagine su tre classi dell’ultimo anno delle superiori, su 70 studenti di 18 anni nessuno sa cos’è Google Reader, 2 si informano in rete sui siti dei grandi giornali, e 70, cioé tutti usano Facebook.[1]

Un po’ tutti noi di TANTO siamo Feed RSS/Atom dipendenti. Se ne può “fare uso” nelle modalità più svariate, e l’elenco delle ricette che trovate sul meraviglioso ifttt ne è una prova. Purtroppo sono forse ancora visti (e utilizzati) come strumento di nicchia, mentre dovrebbero essere quasi per definizione uno strumento “pop”.

Anche i colossi dell’informatica ci mettono lo zampino, e in browser come Mozilla Firefox e Google Chrome il tasto per iscriversi ad un feed non fa parte della dotazione standard, ma è attivabile soltanto tramite un’estensione.

Un po’ di cura dovremmo mettercela anche noi che creiamo e diffondiamo RSS: i feed di TANTO ad esempio non superano ancora la validazione W3C. Costruendo questo spazio ho constatato anche che alcuni grossi siti del settore pubblicano i loro RSS con un corredo povero di informazioni (senza alcun tag e/o categorie).

Sorpresa e serendipità

If we’re going to encourage more innovation, it’s not enough for us to just dig in and work harder. We also need to encourage surprise and serendipity. We need to play each other’s instruments.[2]

Due delle emozioni tipiche nella quotidiana lettura dei feed RSS/Atom, sono per noi della redazione di TANTO lo spunto per farvi e farci dei grandi auguri per l’anno che verrà. Sorpresa e serendipità non bastano da soli a rendere un anno migliore di un altro, ma possono essere una delle scintille per fare partire quelle reazioni a catena che nel 2011 non si sono innescate.

Buon anno a tutti!

L'articolo Auguri da un nuovo pianeta è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Questo post nasce a seguito della sollecitazione a descrivere le modalità con cui abbiamo elaborato il modello per l’individuazione della rete strategica in condizioni di esercizio. E’ la naturale continuazione del mio precedente “Definizione di una rete stradale strategica di ambito provinciale” che invito a leggere per maggiore chiarezza, in quanto alcuni passaggi comuni alle due analisi sono stati descritti nel primo post con maggiore dettaglio.

Ricordo comunque, a titolo di completezza, alcuni concetti generali.

Lo scopo dell’analisi è stato quello di definire, all’interno dei 1400 Km della rete viaria della Provincia di Bologna, tre categorie di importanza funzionale indicative della rilevanza strategica di un tronco stradale.

La definizione di una rete strategica è finalizzata a garantire un livello di servizio dell’infrastruttura stradale adeguato alla sua funzione, a programmare e gestire la manutenzione dell’infrastruttura stradale sul territorio provinciale in maniera mirata e a ottimizzare le risorse disponibili per gli interventi definendo priorità e fornendo supporto nella definizione dei piani triennali dei lavori.

L’individuazione della rete strategica viene effettuata tenendo conto di due diversi scenari:

• scenario di servizio: valuta la funzionalità richiesta all’infrastruttura in condizione di normale esercizio;

• scenario di emergenza: valuta la funzionalità richiesta all’infrastruttura nella condizione di emergenza legata ad un evento sismico.

Nel caso dell’analisi in condizioni di esercizio si è tenuto conto dei flussi di traffico e lo studio dei percorsi (routing) ha valutato i percorsi tra centroidi di attrazione e generazione di spostamento secondo la relazione residenti-edificato, residenti-imprese e caselli autostradali-edificato.

L’analisi GIS utilizza:

• una mappa di densità dei residenti ottenuta dal dato geometrico dalle sezioni di censimento ISTAT;
• una mappa di densità delle imprese ottenuta della banca dati della Camera di Commercio georeferenziata;
• una mappa di densità dell’edificato ricavata secondo quanto descritto in questo post.

Queste mappe raster vengono filtrate utilizzando un valore minimo di soglia che permetta di identificare un numero di “isole” ritenuto rappresentativo del contesto provinciale mediante un’analisi qualitativa. Di queste isole vengono poi calcolati i baricentri passando per la trasformazione in poligoni. I baricentri, assieme agli accessi ai caselli autostradali, rappresentano i centroidi dell’analisi dei percorsie sono costituiti da:

• 48 centroidi di aree ad elevata densità residenziale, ottenuti elaborando le sezioni relative all’ultimo censimento della popolazione, che definiremo centroidi residenti
• 61 centroidi di aree densamente edificate, ottenuti elaborando la densità edilizia calcolata dai dati catastali secondo la metodologia proposta da questo post, che definiremo centroidi edificato
• 46 centroidi di aree ad elevata presenza di imprese ottenuti elaborando i dati della Camera di Commercio di Bologna georiferiti, che definiremo centroidi imprese
• 24 accessi ai caselli autostradali

Individuati i centroidi di generazione/attrazione degli spostamenti vengono definite nel modello le regole secondo le quali il software deve calcolare i percorsi di collegamento che sono rappresentati dalla seguente matrice.

Per ogni relazione è espresso un parametro di calcolo utilizzato dall’algoritmo di routing del software:

• 1C, 5C numero di connessioni del centroide di generazione degli spostamenti con i più prossimi punti di attrazione degli spostamenti, es. tra centroidi residenti e centroidi edificato e è indicato 5C, cioè il centroide di ogni area ad elevata densità residenziale deve raggiungere il centroide delle cinque aree densamente edificate più prossime.

• TB calcolo del percorso utilizzando il percorso più breve in termini di tempo.

Ad ogni arco stradale è attribuito un peso basato sul numero dei percorsi, tra quelli calcolati, che lo utilizzano, la parte relativa al calcolo dei percorsi a questo punto è conclusa. Si opera l’estrazione del grafo delle strade provinciali dal grafo complessivo.

Oltre ai percorsi, per il calcolo della categoria di importanza funzionale, in condizioni di esercizio, delle strade provinciali, sono utilizzati anche i dati sui flussi di traffico che provengono da Mobiliter, il sistema di consultazione dei flussi online della regione Emilia-Romagna. I dati forniti sono rilevati da circa 40 postazioni, in funzione 24 ore su 24, installate sulle strade provinciali. Questi dati di flusso sono integrati dai dati rilevati in fase di definizione del quadro conoscitivo del Piano della Mobilità Provinciale.

I dati relativi ai flussi di traffico sono stati inseriti come attributi nel grafo provinciale a livello di singolo arco stradale. Sono state individuate tre classi di traffico attraverso un’analisi di significatività statistica (Jenks). La scelta dei valori di soglia, operata secondo questo metodo, consente di determinare classi di aggregazione (classe 1, 2 e 3) con i valori di gruppo più simili e che massimizzano le differenze tra le classi stesse.

Il calcolo dell’indice di importanza funzionale, basato sulle classi di traffico e sul peso determinato dall’analisi dei percorsi, è stato effettuato in maniera diversificata tra le strade di pianura e quelle collinari o montane. Si è operata una distinzione basata sulla definizione geografica di pianura come territorio compreso al di sotto della quota di 200 m s.l.m. Lo scopo di questa differenziazione, che si traduce nella creazione di due sub-grafi, è quello di amplificare l’importanza funzionale delle strade appenniniche, cioè quelle poste a 200 m s.l.m., che presentano in termini di flussi di traffico un’importanza spesso secondaria. Tale scelta si è concretizzata nel calcolo dell’indice di importanza funzionale che segue la logica di seguito descritta.

Una volta calcolato l’indice di importanza funzionale nel contesto di pianura ed in quello appenninico si può riunificare il grafo. L’indice di imporanza funzionale che ogni arco si trova come attributo viene normalizzato a 100 e vengono individuate tre categorie di importanza funzionale mediante l’analisi di significatività statistica di Jenks.

Quello che si ottiene è un grafo che presenta per ogni singola strada provinciale diversi tratti con categoria di importanza funzionale diversa. Con un’analisi qualitativa si operano delle scelte per attribuire le categorie di importanza funzionale in maniera più continua ad interi tratti di strada.

Un’illustrazione interessante può essere quella di un utilizzo “pratico” della rete strategica in condizioni di esercizio quale la valutazione dell’indice di equilibrio nell’attività di pulizia della neve. Si calcola per ogni arco stradale l’indice di servizio, cioè il rapporto tra il numero dei mezzi ed il percorso assegnato (es. 1 mezzo / 15 Km = 0.067). Il valore dell’indice di servizio, attraverso l’analisi di significatività di Jenks, viene classificato in tre classi: massimo (classe 1), medio (classe 2) e minimo (classe 3) servizio. Successivamente per ogni arco si confronta la classe di servizio con la categoria di importanza funzionale in condizioni di esercizio. Gli scenari possibili sono i seguenti.

La mappa dell’indice di equilibrio risultante è la seguente.

Mappa dell'indice di equilibrio nella pulizia neve

Spero di essere riuscito nell’intento di esemplificare il flusso di lavoro seguito. Invito chi possa essere interessato all’argomento a contribuire, chiedere informazioni o criticare utilizzando i commenti

L'articolo Definizione di una rete stradale strategica di ambito provinciale in condizioni di esercizio è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Questo post nasce dal mio desiderio di condividere e discutere un’approccio metodologico, in termini di analisi GIS, per me relativamente nuovo nell’ambito del mio lavoro presso il Servizio Manutenzione Strade della Provincia di Bologna. Il lavoro da cui è tratta la metodologia descritta in questo post è stato svolto a quattro mani con il mio collega Pierluigi Tropea le cui competenze in ambito strutturale e manutentivo, complementari alle mia esperienza in ambito GIS, ci hanno permesso di conseguire un risultato, secondo me, interessante.

Lo scopo dell’analisi è stato quello di definire, all’interno dei 1400 Km della rete viaria della Provincia di Bologna, tre categorie di importanza funzionale indicative della rilevanza strategica di un tronco stradale.

La definizione di una rete strategica è finalizzata a garantire un livello di servizio dell’infrastruttura stradale adeguato alla sua funzione, a programmare e gestire la manutenzione dell’infrastruttura stradale sul territorio provinciale in maniera mirata e a ottimizzare le risorse disponibili per gli interventi definendo priorità e fornendo supporto nella definizione dei piani triennali dei lavori.

L’individuazione della rete strategica viene effettuata tenendo conto di due diversi scenari.

• Scenario di servizio: valuta la funzionalità richiesta all’infrastruttura in condizione di normale esercizio.

• Scenario di emergenza: valuta la funzionalità richiesta all’infrastruttura nella condizione di emergenza legata ad un evento sismico.

Le modalità utilizzate per definire la categoria di importanza funzionale di una strada variano a seconda dello scenario di analisi. Si parte in entrambi i casi dall’analizzare le densità di residenti, edificato ed imprese. Nel caso dello scenario di emergenza le densità vengono amplificate in base ad una funzione esponenziale di pericolosità sismica definita sul territorio attraverso l’accelerazione sismica di picco al suolo e la probabilità di superamento di un determinato sisma di riferimento.

Lo scopo di questa amplificazione è tenere conto del maggiore danno atteso in aree a maggiore sismicità potenziandone virtualmente i recettori di soccorso.

Nel caso dello scenario di esercizio si tengono in considerazione anche i flussi di traffico e l’analisi dei percorsi (routing) valuta i percorsi tra centroidi di attrazione e generazione di spostamento secondo la relazione residenti-edificato e residenti-imprese. La metodologia per individuare i centroidi analizzati in questo scenario è la medesima di quella sotto riportata per lo scenario di emergenza.

L’analisi GIS utilizza una mappa di densità dei residenti ottenuta dal dato geometrico dalle sezioni di censimento ISTAT; una mappa di densità delle imprese ottenuta della banca dati della Camera di Commercio georeferenziata; una mappa di densità dell’edificato ricavata secondo quanto descritto in questo post. Queste mappe raster che sono amplificate dalla funzione di pericolosità sismica nel caso dello scenario di emergenza, vengono filtrate utilizzando un valore minimo di soglia che permetta di identificare un numero di isole ritenuto rappresentativo del contesto provinciale mediante un’analisi qualitativa. Di queste “isole” vengono poi calcolati i baricentri passando per la trasformazione in poligoni.

I baricentri rappresentano i centroidi della nostra analisi. Questi centroidi ed i punti che rappresentano l’ubicazione delle industrie a rischio rilevante sono, nell’analisi dei percorsi (routing), i punti verso i quali veicolare, attraverso il grafo stradale, i mezzi provenienti dai centri di offerta di soccorso.

Nel complesso l’analisi GIS, per lo scenario di emergenza, si articola in quattro punti.

Punto 1 – Individuazione dei punti da cui, nel modello, si origina l’offerta di soccorso nel territorio provinciale a cui ho accennato poco sopra.

• 16 caserme dei Vigili del Fuoco

• 40 presidi ospedalieri

• 24 accessi ai caselli autostradali

• Interporto di Bologna

Punto 2 – Individuazione dei recettori che fanno richiesta di soccorso che nel modello deve essere veicolato attraverso il grafo stradale che comprende l’intera rete stradale presente sul territorio provinciale.

• 48 centroidi di aree ad elevata densità residenziale, ottenuti elaborando le sezioni relative all’ultimo censimento della popolazione, che definiremo centroidi residenti

• 61 centroidi di aree densamente edificate, ottenuti elaborando la densità edilizia calcolata dai dati catastali secondo la metodologia proposta da questo post, che definiremo centroidi edificato

• 46 centroidi di aree ad elevata presenza di imprese ottenuti elaborando i dati della Camera di Commercio di Bologna georiferiti, che definiremo centroidi imprese

• 23 industrie a rischio rilevante

Punto 3 – Definite le origini e le destinazioni vengono definite nel modello le regole secondo le quali il software deve calcolare i percorsi di collegamento. Le relazioni variano a seconda dello scenario di riferimento analizzato, quelle utilizzate per lo scenario di emergenza sono rappresentate dalle seguente matrice.

Per ogni relazione è espresso un parametro di calcolo utilizzato dall’algoritmo di routing del software:

• 1C, 2C, 3C numero di connessioni del centroide di richiesta di soccorso con i più prossimi punti di offerta di soccorso della relazione, es. tra industrie a rischio rilevante e presidi ospedalieri è indicato 3C, cioè un’industria a rischio deve essere raggiunta dai tre più prossimi presidi ospedalieri

• TB calcolo del percorso utilizzando il percorso più breve in termini di tempo

Il risultato è una mappa in cui ad ogni elemento (arco) del grafo stradale sono sovrapposti n archi stradali relativi ai percorsi calcolati secondo la logica descritta.

Percorsi di collegamento tra centroidi di offerta e ricezione di soccorso

La legenda dei percorsi tra punti di offerta di soccorso ed i recettori può essere così esplicitata.

Offerta di soccorso

PS presidi ospedalieri

VVF caserme dei Vigili del Fuoco

CS accessi ai caselli autostradali

IP interporto di Bologna

Recettore di soccorso

IR industrie a rischio rilevante

ED centroidi di aree densamente edificate

RR centroidi di aree ad elevata densità residenziale

AZ centroidi di aree ad elevata presenza di imprese

A questo punto, ad ogni arco stradale, viene attribuito un indice di importanza funzionale basato sul numero dei percorsi, tra quelli calcolati, che lo utilizzano. Il valore dell’indice è poi normalizzato a 100.

Punto 4 - Si stabiliscono delle classi di aggregazione di valore dell’indice di importanza funzionale. Sono state definite tre classi individuando i valori di soglia attraverso un’analisi di significatività statistica (Jenks) dei valori dell’indice di importanza funzionale degli archi del grafo stradale. La scelta dei valori di soglia, operata secondo questo metodo, consente di determinare classi di aggregazione (categoria 1, 2 e 3) con i valori di gruppo più simili e che massimizzano le differenze tra le classi stesse.

L’analisi operata fino ad ora ha preso in considerazione l’intero grafo stradale provinciale: autostrade, tangenziali, strade statali, strade provinciali e strade comunali. La “nostra” rete strategica deve contenere solo le strade provinciali che vengono quindi estratte dal grafo complessivo.

Quello che si ottiene è un grafo che presenta per ogni singola strada provinciale diversi tratti con categoria di importanza funzionale diversa. Con un’analisi qualitativa si operano delle scelte per attribuire le categorie di importanza funzionale in maniera più continua ad interi tratti di strada.

Rete strategica delle strade provinciali

La mappa sopra riportata rappresenta il risultato complessivo dell’analisi con la rappresentazione delle strade provinciali secondo le tre categorie di importanza funzionale:

1. categoria – massima importanza strategica

2. categoria – media importanza strategica

3. categoria – minima importanza strategica

da un punto di vista statistico il risultato è il seguente.

Statistica dei Km di strade provinciali per categoria

Le percentuali sono espresse in termini di Km sui 1400 km complessivi di strade provinciali.

Mi auguro che questo post possa essere di stimolo alla nascita di un confronto sulla metodologia utilizzata, cosa importante per evidenziare i punti di debolezza ed avere utili spunti.

L'articolo Definizione di una rete stradale strategica di ambito provinciale è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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.

L'articolo Parliamo di webmapping è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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

L'articolo Python e GIS con GDAL/OGR: configurare l’ambiente di lavoro su windows è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Oggi inizia il FOSS4G 2010, e purtroppo io non ci sarò

Scrivo questo post per fare un “in bocca al lupo” a tutti i partecipanti: a quelli che rendono vivo questo mondo, a quelli che non finiscono mai di regalarci nuovi strumenti e/o di migliorare quelli esistenti, a quelli che producono dei fantastici materiali didattici, a quelli che combattono per la valorizzazione ed una maggiore distribuzione dei dati liberi, a quelli che rispondono ad un messaggio di una mailing list alle 3 di notte, a quelli che ci mettono entusiasmo, tempo e professionalità, a quelli che impareranno qualcosa di nuovo ed avranno una nuova luce negli occhi. A tutti loro grazie!

A chi (come me) non ci sarà non resta che farsi rodere dall’invidia , leggere il programma della conferenza, scorrere l’elenco delle presentazioni, dei poster, dei workshop e dei tutorial, e soprattutto “giocare” con il fantastico live DVD preparato per l’occasione (io vado a scaricarlo).

Oppure molto più semplicemente seguire l’onda e scoprire cosa dice e fa la gente intorno a #foss4g2010.

L'articolo Oggi inizia il FOSS4G 2010: in bocca al lupo a tutti! è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Il sistema GIS Cloud (beta) comincia a far parlare di sé.

GIS Cloud – General from GIS Cloud on Vimeo.

Si tratta di un sistema di cloud computing dedicato a servizi webgis che, in linea col concetto di “software as a service” , permette di sfruttare risorse hardware a software distribuite per realizzare servizi GIS online.
Tra le numerose funzionalità, offre la possibilità di creare progetti online, di caricare, gestire, editare, esportare, ecc. dati raster e vector di tutti i principali formati noti. Oltre a diverse librerie proprietarie, GIS Cloud si appoggia anche a GDAL e OGR, a garanzia di un’alta interoperabilità.

I layer, una volta caricati e impostati,  possono essere pubblicati sia tramite il loro flash viewer, che coe servizi WMS/WFS, nonché di fungere da client di servizi OGC, offrendo così la possibilità di realizzare anche mashup e servizi a cascata. Non poteva mancare il supporto ai servizi Openstreetmap, Google Maps, e simili.

Sono presenti inoltre alcuni semplici strumenti di analisi GIS e statistica, come esempio delle ulteriori funzioni che saranno rese disponibili in futuro…

Insomma, un oggetto da tenere d’occhio. In attesa di ricevere il vostro Free Account (che offre tutte le funzionalità ma in un ambiente non dedicato, con risorse condivise tra tutti gli utenti gratuiti e quindi non garantite) vi invito a fare un giro tra i video della loro sua gallery.

L'articolo GIS Cloud – il cloud computing per il webgis è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

GIScover è molto popolare tra gli appassionati di outdoor e GPS come il sottoscritto. Nato come mashup di Google Maps per condividere i propri itinerari, attraverso lo scambio di tracce GPS, si è gradualmente evoluto in una realtà più complessa ed in direzioni complementari.

In particolare ho trovato interessante l’utilizzo dell’User-Generated Content o UGC per proporre un servizio commerciale e personalizzato alle autorità turistiche locali.

Per capire meglio la realtà imprenditoriale che c’è dietro ho preferito quindi la forma dell’intervista, scritta e video, chiedendo direttamente al fondatore, Massimo Nicolodi, qualcosa di più sulla sua creatura.

Lorenzo Perone – Cos’è GIScover?

Massimo Nicolodi - GIScover è un punto d’incontro per appassionati di viaggi itineranti e di attività outdoor. L’obiettivo principale è quello di fornire una banca dati di tour e tracce GPS accessibile gratuitamente da chiunque e da ovunque.

Per gestire la grande quantità di dati è stato creato un motore di ricerca potente, ma facile ed intuitivo nell’uso, capace di reperire velocemente i tour ricercati.

Tutti gli utenti del sito possono registrarsi e scaricare i tour gratuitamente.
Ad oggi abbiamo 6640 tour per una distanza di 367538 Km ed un dislivello in salita di 11032 km.

LP – Quando è nato GIScover?

MN – Nel 2004.

LP – Perché è nato GIScover?

MN – ll team di GIScover è formato da grandi viaggiatori ed amanti di sport estremi. Negli ultimi anni le tecniche e gli equipaggiamenti sportivi sono cambiati e si sono evoluti, ma due cose sono rimaste costanti: pianificare un nuovo viaggio è ancora una cosa difficile che richiede tempo e dedizione e, nonostante questo, l’eventualità di perdersi nei posti che andiamo a visitare è un’eventualità da non escludere.

Quando cominciai ad utilizzare i primi ricevitori GPS nelle mie avventure mi resi subito conto di come questo piccolo apparecchio tecnologico poteva cambiare la mia vita. Portarlo sempre con me nelle escursioni sulle alte vie delle Dolomiti, significava avere una garanzia di soccorso in caso di necessità ed inoltre era la garanzia di non perdere più la rotta. Il GPS aveva un’interfaccia semplice e poteva comunicare con il PC. In questo modo potevo salvare ed archiviare i percorsi effettuati e potevo caricare le nuove tracce da percorrere recuperate attraverso amici e conoscenti.

Da qui il passo a capire che anche altri appassionati delle Dolomiti come me potevano essere interessati a questi scambi è stato breve.

In poco tempo l’idea ha preso forma: perché non costruire, in collegamento con le autorità turistiche locali, un servizio di informazioni complesso capace di promuovere le zone meno conosciute turisticamente e di fornire un nuovo valore all’esperienza di chi si reca in questi posti? E perché non utilizzare un portale Web, con un motore di ricerca avanzato, per rendere accessibile a chiunque le informazioni in modo semplice, veloce ed economico?

LP – Quante persone hanno collaborato alla nascita di GIScover?

MN – Eravamo in 10.

LP – Chi erano i protagonisti delle escursioni? Voi? Dei vostri amici? Un’associazione sportiva alla quale vi eravate affiliati?

MN – Appassionati di outdoor, io e mia moglie, amici. Abbiamo iniziato a mappare le principali ciclabili del trentino, le altevie delle dolomiti e percorsi di MTB tra cui le Transalp da Mittenwald al Garda (ne ho concluse 5).

LP – Che tecnologie utilizza Giscover?

MN – PHP, MySQL, Google Maps, Drupal. Nella nuova versione integreremo anche Open Street Map con scambio di tracce.

LP – Quanti utenti ha oggi GIScover?

MN – Circa 16.00.

LP – Come ha fatto GIScover a catalizzare la massa critica di percorsi che gli ha permesso di diventare così popolare?

MN – Siamo stati i primi a scambiare le tracce gratuitamente e abbiamo iniziato con bellissimi tour di sci alpinismo e mountain bike.

LP – Cosa sono gli ecopunti?

MN – Sono dei punti attribuiti agli utenti in base ai chilometri di percorsi caricati e che traduciamo in buoni sconto per acquisto di GPS e software dal nostro sito.

LP – Il compenso in ecopunti per i percorsi inseriti è stato efficace?

MN – E’ stato particolarmente stimolante per alcuni rilevatori che hanno svolto un lavoro incredibile.

LP – C’è qualche utente che ha raggiunto livelli di retribuzione tali da fare acquisti importanti?

MN – Qualcuno ha ricevuto dispositivi GPS pagati con il sudore e gli ecopunti.

LP – Quante sono le persone attualmente impiegate in GIScover? Che profili hanno?

MN – Ci sono attualmente 5 sviluppatori, collaborano inoltre fotografi e web designer.

LP – GIScover mostra attualmente una trasversalità di servizi (shop, corsi, servizi di geolocalizzazione, servizi di web-gis di supporto al marketing territoriale) quali sono quelli trainanti da un punto di vista economico?

MN – I principali settori di riferimento sono il turismo, la pubblica amministrazione e l’educazione.

Sviluppiamo soluzioni geoweb, Content Management System (CMS – Drupal), Customer Relationship Management (CRM – http://www.giscover.info/prodotti_servizi).

Abbiamo richieste da diverse località turistiche di aggiungere ai loro siti web delle funzionalità geoweb per promuovere i principali punti di interesse ed itinerari sul loro territorio. A questo proposito stiamo introducendo il concetto del GPS Guided Tour.

La presenza di GPS sui telefoni di nuova generazione sta accellerando la diffusione e la richiesta di queste tecnologie, di conseguenza noi stiamo investendo in ricerca e sviluppo sul settore mobile (Nokia, iPhone e Andorid).

Abbiamo iniziato un’attività di collaborazione con editori, in particolare segnalo la collaborazione con Ediciclo, editore specializzato nella pubblicazione di guide escursionistiche e per il cicloturismo. Stiamo accompagnando le ultime pubblicazioni con tracce GPS per agevolare i lettori nell’individuazione dei percorsi.

LP – C’è un sito/progetto italiano a cui ti sei ispirato o che ti piace particolarmente?

MN – I miei riferimenti sono wikipedia, flickr, google maps e youtube.

La nuova versione di GIScover che stiamo sviluppando ne permetterà una facile integrazione con funzioni simili.

LP – Quali sono i temi su cui state investendo e che pensate possano diventare economicamente rilevanti per la vostra azienda?

MN – Turismo, annunci classificati, pubblica amministrazione, educazione, mobilità e trasporto pubblico, sicurezza in montagna, applicazioni per mobile (Symbian, iPhone, BalckBerry e Android), canali tematici per i geocontenuti.

LP – Ci sono delle attività, diverse da GIScover, in cui siete coinvolti in questo momento e di cui vuoi parlarci?

MN – Un progetto al quale tengo particolarmente è “Scuola Web 2.0 – Esplora e Racconta” che è stato approvato e finanziato dalla Fondazione della Cassa di Risparmio di Trento. E’ un progetto rivolto al mondo dell’educazione con scuole medie e secondarie del trentino ed alcune facoltà universitarie. E’ prevista inoltre la partecipazione di enti per beni culturali, turismo ed innovazione tecnologica.

http://tinyurl.com/y9gx8yw - http://tinyurl.com/yc8mlle - http://tinyurl.com/y8dmvyn

LP – Ci puoi segnalare alcuni case history degli ultimi progetti realizzati o in via di sviluppo?

MN – BusFinder, sistema integrato per la mobilità

http://tinyurl.com/ybtyvh9 – http://tinyurl.com/y9mbymy

MN – Ed alcuni siti di cui abbiamo realizzato la parte di geoweb.

Percorsi Outdoor – www.giscover.com

La via del Brenta – http://laviadelbrenta.it/

Progetto turistico Sardegna – tancasabertas.net

Prototipo Route Planner ATAF Firenze – http://ataf.giscover.com/map

MN – Ti segnalo anche dei link ad applicazioni e tecnologie che ci sembrano molto interessanti.

Boston MBTA Planner - esempio di routeplanner al quale ci stiamo ispirando.

Google Maps per Mobile – qui è possibile richiedere fermate e linee da punto a punto anche per trasporto pubblico, provatelo su Firenze!

Digital Signage e automation – azienda con cui collaboriamo per sistemi di digital signage e broadcasting localizzato. Sono tra i maggiori produttori al mondo di display per outdoor e sistemi bancomat. Possono produrre anche distributori di biglietti e schede magnetiche.

Google Transit – elenco delle città che offrono informazioni e orari per trasporto pubblico. Speriamo di poter aggiungere anche la regione Abruzzo.

Terravision – sito interessante per organizzare vacanze “fly and ski” e turismo estivo e attivo (bici escursionismo ecc…).

Val Venosta – Itinerari turistici in bici + treno.

Val Pusteria – Itinerari in bici.

L'articolo Intervista a Massimo Nicolodi creatore di giscover.com è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

C’era bisogno dell’ennesimo progetto GIS open-source? Non bastavano i veterani QGIS e GRASS e la numerosa schiera dei più giovani uDIG, GvSIG, OpenJUMP, MapWindow solo per citare i più famosi? Ma certo che no! Open source in open minds ci piace dire da queste parti…

E allora senza indugi vediamo di che si tratta.

Intanto il nome del software Whitebox – affermano al Centro di Idrogeomatica dell’Università di Guelph, Canada – è ispirato alla filosofia della trasparenza, base dell’open source. Sembra abbiano scoperto l’acqua calda, e invece qualcosina in più la danno. In ogni tool che compone il GIS c’è un bel pulsantino che mostra il codice usato per realizzarlo. Più trasparente di cosi! Didatticamente costituisce un enorme valore aggiunto, anche dal punto di vista dello sviluppo.

E si spingono anche più oltre… pare Whitebox sia autenticamente estensibile. E’ possibile infatti creare nuovi tool ad hoc in relativamente pochi passaggi usando un wizard di scripting per Python o Visual Basic/C# , tra l’altro convertendo il codice da un linguaggio all’altro! Leggete qui e qui. C’è anche la possibilità di creare delle finestre per gestire i nuovi tools, mediante un dialog designer.

E’ possibile scaricare il codice sorgente del software – distribuito con licenza GPLv3 – o già compilato, pronto per essere utilizzato senza doverlo installare, ma solo su Windows. Non parlano sul sito di portabilità su Linux, ma chi è più esperto di me potrà valutarlo grazie al sorgente. E magari farcelo sapere qui su TANTO

Andiamo avanti con la prova out of the box.

Già dagli screenshot sul sito è intuibile come Whitebox sia un GIS prettamente, anzi esclusivamente raster. Non è possibile in alcun modo poter importare dati vettoriali, e questo è un primo punto dolente. Si propone dunque essenzialmente come un tool per grid e image analysis. Una volta lanciato infatti notiamo nella essenziale interfaccia, sulla sinistra, i tools organizzati ad albero, raggruppati per ambito operativo (Conversion e Data Import/Export, Hydro Tools, Image processing, ecc.). Molto molto spartano.

I dati raster utilizzabili sono in formato proprietario (*.dep) ma ci sono due tool di import grid da ASCII (*.txt) e da floating ESRI (*.flt). Punto e basta. Provo dunque a importare un pò di dati, sia da ASCII che da floating ESRI. Ho fatto tentativi con dati con differenti dimensioni e risoluzioni, ma in alcuni casi sono venuti fuori errori di varo genere, tra millantati formati ASCII non riconosciuti e “division by zero”. Insomma, non molto affidabile il modulo di importazione. Seconda – grossa – nota dolente.

Passiamo alla mappa, carico i grid *.dep che sono riuscito a importare ed eccoli là, uno dopo l’altro impilati in ordine di caricamento. Naturalmente è possibile scegliere diverse palette di colori, definendone anche l’estensione dei valori da rappresentare. Una funzione utile è quella di poter impostare ogni layer come componente RGB o CMY, allo scopo ad esempio di ottenere visualizzazioni in falsi colori di singole bande spettrali sovrapposte. La gestione delle palette rimane comunque molto limitata, non è ad esempio possibile impostare un colore trasparente per alcuni valori come “no data”.

Non è poi possibile poter gestire la disposizione dei singoli layer nella mappa, spostandoli in posizioni e ordine differenti a seconda delle necessità. Si può comunque impostare la loro trasparenza.

Per valutare la performance dei tool di raster processing, mi sono cimentato in una classica watershed analysis. Partendo da un DEM con risoluzione 25 metri, ho riempito i sink con l’apposito tool, successivamente creato le grid di direzione e accumulo di flusso, infine applicato il tool di delimitazione automatica dei bacini. Il risultato non è stato molto entusiasmante, come vedete qua sotto, ma forse sono stato un pò frettoloso io nell’individuare i pour point, ovvero le sezioni di chiusura dei bacini stessi.

In conclusione, il progetto Whitebox è molto giovane, sviluppato al momento sembra dal solo e volenteroso John Lindsay, e questo può giustificare i numerosi – ma non tragici – punti di debolezza del software. Speriamo qualcun’altro lo affianchi e contribuisca al miglioramento della “scatola trasparente”.

D’altro canto i punti forza di Whitebox sono la sua semplicità di utilizzo, l’estensibilità mediante wizard per la costruzione di nuovi tool ad hoc, la disponibilità degli strumenti di raster analysis più comuni, portatile su dischi USB (occupa solo 23 MB) senza doverlo installare, tutte caratteristiche che ne fanno un ottimo software GIS didattico.

Insomma, il ragazzo si farà, anche se ha le spalle strette…

L'articolo Ci mancava solo il GIS trasparente… è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Ieri sono stato al GISDay di Palermo, e noi di TANTO siamo stati tra gli organizzatori. Per l’occasione Franco Farinelli ci ha concesso una bella intervista, che pubblichiamo qui in esclusiva (mi sento Bruno Vespa). Mi piace raccontarvi del “viaggio” che ci ha portato sino a qui.

Poco più di un mese fa ho scritto un post sul mio primo “incontro” con il prof. Farinelli. E’ stato un contributo che mi ha riservato diverse soddisfazioni, la più importante delle quali è stata riscontrare l’effetto di disturbo positivo che ha provocato tra i lettori. Se ne ha un’evidenza tra i commenti al post, ma lo ho avuta anche a voce ed in chat.
Nelle settimane successive sono stato coinvolto nell’organizzazione di questo GISDay, e nella prima riunione si cercava con difficoltà di definire il taglio da dare alla giornata; la cosa era complicata dal fatto che non ci si conosceva bene tra tutti i partecipanti. Poi qualcuno dice: “bello il post su Farinelli”. Ci siamo guardati negli occhi ed abbiamo capito di avere fatto il primo piccolo grande passo. Poco dopo: “Andrea, ma perché non invitiamo Franco Farinelli??” (“argh” ho pensato io). Ma l’effetto domino non è finito.
Racconto infatti di questa proposta via email agli altri autori di TANTO, ed uno di loro (preferisco mantenere la privacy) mi racconta che l’avrebbe incontrato in presenza da lì a pochi giorni, per provare a coinvolgerlo in maniera più diretta su questo blog. Partiva quasi un’operazione di accerchiamento.
Rompo allora gli indugi e mi metto in contatto con Franco Farinelli. Mi dice subito di non poter essere con noi in presenza, ma di essere disponibile per un’intervista a distanza.

L’intervista è stata fatta. Avremmo voluta farla in diretta ieri, ma abbiamo preferito registrala il 17 per evitare qualsiasi inaspettato problema tecnico (“il bello della diretta”).

Ringrazio molto il prof. Farinelli per la sua disponibilità, ma sopratutto ed ancora una volta, per avere stimolato delle sane reazioni chimiche tra i presenti in sala. Spero che vi faccia lo stesso effetto, e mi piacerebbe che lasciaste qui traccia delle vostre sensazioni.

Buona visione

L'articolo In esclusiva per TANTO: intervista a Franco Farinelli è apparso originariamente su TANTO. Rispettane le condizioni di licenza.