Il GTFS è un formato nato per definire orari e informazioni geografiche legate a reti pubbliche e private di trasporto. E’ nato in sintesi estrema (qui più dettagli) come side project di un dipendente di Google che nel 2005 stava cercando un modo per standardizzare l’importazione di dati di questo tipo in Google Maps. Non c’era ancora uno standard in questo settore, e nel tempo il GTFS è diventato il formato di riferimento, grazie anche all’uso diffuso e alla sua documentazione.

Si tratta di una collezione di file CSV (con estensione .txt) – da un minimo di 6 a un massimo di 13 – archiviati all’interno di un file zip, le cui specifiche sono documentate qui: https://developers.google.com/transit/gtfs/reference/

Per varie ragioni è un formato con cui ho spesso a che fare, ed è stato di ispirazione per creare uno script che ho scritto durante le bellissime olimpiadi di Rio e che ho chiamato GTFS, ready, set, go.

Cosa è GTFS, ready, set, go

È uno script bash che fa essenzialmente una cosa: trasforma i file txt del GTFS in formati pronti per essere usati meglio e subito, sopratutto in applicazioni spaziali. Nel dettaglio:

• scarica una sorgente dati GTFS e ne converte i file txt in tabelle di un DBMS con estensione spaziale e in particolare in formato spatialite (evviva Alessandro Furieri e tutti quelli che si prendono cura di spatialite);
  • trasforma in layer cartografici le tabelle delle fermate e delle rotte (stops e routes);
  • genera alcuna tabelle utili a creare un report sul file della reti di trasporti preso in esame;
• esporta in formato GeoJSON e KML la tabella delle rotte e quella delle fermate;
• genera un report in formato HTML e Markdown utili a dare una visione d’insieme dei dati in esame (al momento è ancora minimale e in bozza) .

Nulla di complesso e nulla di nuovo. Ci sono già altre modalità e prodotti per fare cose simili, ma sono scritti in linguaggi che non conosco (ad esempio in Go), richiedono l’installazione di un database server o non spazializzano database sqlite (come il mio amato GTFSDB) o sono procedure (semplici) da svolgere “a mano” e quindi a rischio sempre di qualche errore e con perdite di tempo (come ad esempio questa).

Qui il repository su GitHub: https://github.com/ondata/gtfsreadysetgo

Come funziona

Si tratta di uno script in cui ho messo in fila i comandi utili al mio obiettivo finale, costruendo una (sorta di) macro in cui sfrutto le caratteristiche del bash e alcune utility/applicazioni utili per arrivare al risultato atteso. Queste ultime sono al momento un requisito per lo script, e quindi una piccola barriera ad un utilizzo immediato: le ho utilizzate perché mi hanno consentito di non scrivere “vero” codice, perché “fanno” nella sostanza tutto loro.

Requisiti

Avere un sistema operativo in cui è possibile lanciare uno script bash, quindi ovviamente i sistemi Linux, quelli Mac e anche quelli Windows. Su quest’ultimo apro una piccola parentesi.

Per lanciare uno script bash su Windows – sino a poco tempo fa – era necessario installare “cose” come Cygwin.

Cygwin è una distribuzione di software libero, sviluppata originariamente da Cygnus Solutions, che consente a diverse versioni di Microsoft Windows di svolgere alcuni compiti in maniera esteticamente e funzionalmente simile ad un sistema Unix (da Wikipedia).

Dall’ultimo aggiornamento di release di Windows 10 (l’anniversary update di agosto 2016) è possibile utilizzare nativamente bash anche in Windows, tramite l’applicazione denominata “Bash in Ubuntu on Windows”; “GTFS ready set go” l’ho scritto e testato per intero in ambiente Windows 10, anche per provare questa novità introdotta in questo recente aggiornamento, che rende la comodità e la potenza di fuoco di bash sempre più trasversali.

Lo script sfrutta queste applicazioni:

• GDAL – Geospatial Data Abstraction Library >= 2.1, che viene usato essenzialmente per le operazioni di creazione, importazione e esportazione delle risorse;
• spatialite, che viene sfruttato per fare query spaziali e come uno dei formati di archiviazione e output;
• unzip, per decomprimere il GTFS sorgente;
• curl, per il download del file GTFS;
• csvtk, per convertire in formato Markdown alcune delle tabelle create;
• pandoc, per convertire il report Markdown anche in formato HTML.

E infine vengono utilizzate gli straordinari grep e sed, che sono sempre presenti in ambienti in cui è possibile lanciare uno script bash.

Usare lo script

Questa la modalità attuale di utilizzo:

• scaricare (o clonare) il repository e decomprimere in una cartella il file zip scaricato;
• dare allo script .sh i permessi di esecuzione;
• aprirlo con un editor di testo e cercare la variabile URLGTFS;
• sostituire l’URL presente con l’URL di un feed GTFS di proprio interesse (un comodo archivio di GTFS è TransitFeeds) come ad esempio quello di Madrid https://servicios.emtmadrid.es:8443/gtfs/transitemt.zip;
• salvare e lanciare lo script via shell.

Qui sotto la replica di quanto descritto nei punti di sopra.

Alcune note

Lo script può essere migliorato e di molto. Per questa ragione inserisco alcune importanti note:

• lo script non fa la verifica dei requisiti software (vedi sopra), quindi se non soddisfatti andrà in errore;
• lo script è utilizzabile al momento soltanto con i GTFS che contengono anche la tabella shapes, che è opzionale per il formato GTFS, quindi non sempre presente;
• lo script non fa alcuna verifica di consistenza dei dati (per la quale è possibile utilizzare FeedValidator;
• lo script crea e cancella file e cartelle nella cartella in cui viene eseguito.

Gli output

Sopra ho già fatto riferimento agli output. Nel repository oltre allo script è stata creata la cartella output_example_folder per mostrare nel concreto quali siano gli output prodotti. A seguire l’elenco dei vari output con i relativi URL, in modo da potersi fare un’idea più concreta:

• feed_gtfs.sqlite download, ovvero il file GTFS trasformato in formato SpatiaLite, in cui le tabelle stops e routes sono state trasformate in layer spaziali;
• routes.geojson (visualizzazione e download), il file in formato GeoJSON per le rotte;
• routes.kml (download), file in formato KML per le rotte, visualizzabile in Google Earth (ed in altri client);
• stops.geojson (visualizzazione e download), il file in formato GeoJSON per le fermate;
• stops.kml (download), file in formato KML per le fermate, visualizzabile in Google Earth (ed in altri client);
• la cartella report(visualizza), che a sua volta contiene:
  • report.md, il file con il report in formato Markdown (visualizza)
  • report.html, il file con il report in formato HTML (vista codice e rendering HTML);
  • tutte le tabelle usate per costruire i report, in formato CSV e Markdown.

Perché

GTFS, ready, set, go nasce come conseguenza di #openamat, un’iniziativa civica (ancora in corso) per chiedere a AMAT (la municipalizzata comunale di Palermo che gestisce il trasporto pubblico) di pubblicare i dati relativi ai trasporti pubblici in formato aperto ed in tempo reale.

Dopo 6 mesi senza aggiornare i dati, AMAT ha pubblicato a luglio del 2016 tre aggiornamenti di GTFS in 15 giorni e avevo bisogno di uno script per poter usare e visualizzare subito questi dati.

Lo rendo pubblico perché penso possa essere utile anche ad altri.

URL (che mi sono stati) utili

• The OpenPlans Guide to GTFS Data;
• osm_users_stats_italian_province;
• GTFS-Training-Materials;
• GTFSDB;
• Extracting GTFS data using JEQL;
• TransitFeed library.

L'articolo GTFS, pronti, partenza, via … è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Nasce da una sperimentazione fatta a San Francisco, città con più di 30 agenzie di trasporto pubblico, un numero crescente di servizi privati, il carpooling, ecc.. L’obiettivo era proprio quello di mettere a rete tutti questi dati e catalogare le informazioni su autobus, treni, tram, traghetti anche le funivie e renderli interrogabili come se fossero in un unico database.

Tutto talmente bello, che dopo la sperimentazione “locale” è partito il progetto globale, con l’obiettivo di mettere a catalogo file GTFS da tutto il mondo.
La scelta del formato file di input è caduta proprio su General Transit Feed Specification, oggi lo standard di fatto per questo tipo di dati, usato da Google Maps, Microsoft Bing Maps, Apple Maps, ecc. Molti operatori di servizi di trasporto pubblicano i dati in questo formato, e molti innovatori civici hanno creato questi file per le loro città.

Ma si tratta di risorse che per lo più fluttuano nel web spesso come elementi separati. Transitlad, ancora invero in uno stato iniziale, mira a diventare un centro di gravità per questi dataset, completamente aperto in termini di licenza di software e di dati.

Contribuire

Uno dei modi per contribuire al progetto, lanciato da poco, è quello di inviare una nuova sorgente di dati GTFS, in modo che possa essere integrata al catalogo generale, che oggi comprende più di 70 risorse.
Farlo è molto semplice: a partire da questo wizard dove viene richiesto essenzialmente di inserire l’URL della sorgente dati, il tipo di licenza con cui sono pubblicati ed alcune informazioni anagrafiche del mittente.
Il dataset, a quel punto, viene sottoposto ad una verifica e dopo qualche giorno verrà inserito in catalogo.

Un po’ per testare l’oggetto, un po’ perché mi sembra un gran bella idea – non nuova, ma mai pienamente realizzata – mi sono messo all’opera e nel catalogo Trantit.land oggi sono in eleno le “nostre”:

• Palermo;
• Napoli;
• Roma;
• Trento.

Le API e la “vita” dei dati

I dati, come dice spesso chi fa didattica su questi temi, sono come la farina e l’acqua: materia prima con cui c’è chi farà torte e chi “busiate” (io non ho dubbi).

A Transit.land hanno impastato tutto e invece hanno tirato fuori delle API, rendendo l’interrogazione del loro catalogo un processo semplice, comodo e che potenzialmente potrà produrre diversi effetti a cascata.

Qualche esempio di query:

• Tutte le fermate di un operatore
  • https://transit.land/api/v1/stops?servedBy=o-s-aziendanapoletanamobilit
• Tutte le rotte di un operatore
  • https://transit.land/api/v1/routes?operatedBy=o-s-aziendanapoletanamobilit
• Tutte le fermate nel raggio di 500 metri da un punto di coordinate note
  • https://transit.land/api/v1/stops?lon=14.231413&lat=40.835970&r=500
• Tutte le fermate comprese in un rettangolo di coordinate note
  • https://transit.land/api/v1/stops?bbox=14.231413,40.835970,14.239355,40.842158
• Tutte le fermate in cui un certo tag è valorizzato (in questo caso ingresso con sedia a rotelle) in una certa area
  • https://transit.land/api/v1/stops?tag_key=wheelchair_boarding&bbox=-122.4183,37.7758,-122.4120,37.7808
• Tutte le fermate che ricadono nella via che ha come OSM ID il valore 395047052 (Corso Vittorio Emanuele a Napoli)
  • https://transit.land/api/v1/stops?tag_key=osm_way_id&tag_value=395047052
• Tutti i dati su una determinata rotta
  • https://transit.land/api/v1/routes?identifier=gtfs://f-s-anm~it/r/100475194
• Tutte le rotte comprese in un rettangolo di coordinate note
  • https://transit.land/api/v1/routes?bbox=14.231413,40.835970,14.239355,40.842158
• Tutti i dati di un oggetto con un determinato Onestop ID
  • https://transit.land/api/v1/onestop_id/r-sr607-c18

Ma sono solo alcuni esempi e le chiamate disponibili sono molte di più:
https://github.com/transitland/transitland-datastore#api-endpoints

I risultati sono esposti con una paginazione di 50 in 50.

Open Data Day

Sabato 5 marzo 2016 è l’Open Data Day, e una delle sedi sarà la città di Napoli.

Il bello è che sino a 15 giorni fa i dati sui trasporti di questo comune non erano disponibili ed oggi, solo per il fatto di essere stati pubblicati in formato aperto e documentato sono pure accessibili tramite API. Questo è stato possibile grazie anche a Ilaria Vitellio che si è spesa personalmente con la pubblica amministrazione locale, che ha risposto prontamente ed ha pubblicato questi dati.

In bocca al lupo allora a Ilaria ed a tutti i presenti a Napoli, che avranno a disposizione nuova farina e nuovi mattarelli.

In chiusura una nota personale. Anche i dati sulla mia città, Palermo, sono presenti nel catalogo e quindi accessibili via API, ma purtroppo valgono per fare qualche demo di qualità.
Si tratta di dati aggiornati a fine dicembre, in cui non è contemplata la nuova rete tranviaria e tutti i grossi cambiamenti che la rete ha subito tra fine 2015 e inizio 2016.
E’ un fatto grave, specie per una città ricca di turisti come Palermo e con grossi problemi di traffico autoveicolare, che non siano ancora disponibili dati aggiornati sui trasporti pubblici.

Ne riparlerò in un altro post.

L'articolo Transitland, per mettere insieme e “dare vita” ai dati sui trasporti è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Impostazione lato server: ona.io

Giuseppe: Proponiamo di partire da qui, dal “lato server”, dal momento che è la prima cosa che si va a vedere perché bisogna registrarsi: https://ona.io/join

Una volta registrati, si può impostare un nuovo progetto e scegliere il livello di ‘privacy’. La pagina iniziale è la seguente (con il nome che avete scelto al posto di triestegeo, ovviamente).

Dal sito alla voce ‘add form’ è possibile caricare il questionario/form impostato come file XLS, che nelle righe sotto vi spieghiamo come preparare.

Le ‘form’ saranno i questionari e la scheda di acquisizione dati, che successivamente verrà visualizzata sul vostro smartphone o tablet.

Sarà possibile preparare più progetti e specificare il livello di ‘privacy‘, ovvero se progetto ‘pubblico’ o ‘privato’. Ona.io consente diverse possibilità: nel caso di un profilo ‘pubblico’ non vi sono fee da pagare, mentre per alcuni profili privati o con più restrizioni all’utilizzo, è prevista una quota da versare.

Il ‘lato server’ sarà il ‘contenitore’ dei dati, il luogo dove questi saranno conservati una volta caricati, e dove sarà possibile effettuare delle operazioni, quali visualizzazione tabulare o sotto forma di mappa, dove sarà possibile caricare eventuali file multimediali (come ad esempio immagini o video registrati) nonché dei report sulle attività (es. delle statistiche sulle acquisizioni di dati, ecc.) e scaricare i dati in vari formati una volta raccolti.

Dal ‘lato server’ è possibile anche accedere alla WebForm, ovvero dalla finestra (su pagina web) da cui caricare i dati (qualora non si disponga di un dispositivo mobile adatto).

Ovviamente il passaggio necessario, prima di tutto ciò, è l’impostazione del questionario o form, ovvero il ‘cuore’ di tutto il sistema di raccolta dati!

Impostazione del questionario/form con un file Excel

Viola: la form contenente il questionario da caricare sul server per cominciare la raccolta è un file Excel (quindi con estensione .xls) che deve essere formato obbligatoriamente da due fogli di lavoro, denominati ‘survey’ e ‘choices’, cui si può affiancare a discrezione dell’utente un ulteriore foglio di lavoro rinominato ‘settings’. Nel foglio ‘survey‘ c’è la griglia di domande e informazioni da raccogliere, impostate in ordine ben preciso. Sono presenti varie colonne, di cui le principali (ed obbligatorie) sono:

• Type
• Name
• Label

In ‘type’ si individua il tipo di inserimento (output) richiesto all’utente che compila la form relativa ad ogni domanda: testo, orario, numeri interi, coordinate, selezionare una o più opzioni da una scelta di risposte, coordinate GPS, immagini, audio, video e così via.

Nella colonna ‘name‘ si inserisce un nome con cui poter identificare la singola domanda, specificata poi per esteso come si vuole venga visualizzata nella compilazione del questionario colonna ‘label’. I dati verranno visualizzati con questo nome identificativo quando li si andrà a sfogliare dal sito internet.

Qualora si vogliano porre domande con risposte già preimpostate, è necessario inserire “select_one” se l’utente ha la possibilità di selezionare solo una risposta, oppure “select_multiple” se può sceglierne più di una, seguito dal ‘nome’ che identifica il gruppo di domande. Nel nostro caso si era deciso di avere informazioni sull’affluenza all’evento o nel locale di riferimento, con possibilità di scegliere tra ottima, buona, discreta o scarsa, e per quanto riguarda la presenza di free wifi si poteva di selezionare tra le due reti pubbliche, Eduroam e TriesteFreeSpots, oppure la presenza di una rete aperta del locale in cui ci si trova.

Spesso le immagini valgono più di mille parole e quindi guardate un po’ come abbiamo impostato noi il primo foglio di lavoro.

Il campo ‘type’ per inserire il ‘datetime’ o solo ‘time’ o ‘date’ per permettere di capire gli orari e le date in cui si compila il questionario è molto comodo perchè questa informazione viene rilevata in maniera automatica.

Nel momento in cui si inserisce ‘geopoint’ per rilevare la propria posizione GPS, l’operazione può richiedere anche un paio di minuti (all’inizio) per essere abbastanza accurata, è normale. Se avete fretta, potete attendere che il fumetto vi dia indicazioni sulla precisione della rilevazione, cliccare su Registra Localizzazione e continuare a compilare il modulo fino a salvarlo; poi l’applicazione permette di modificare in seguito la posizione semplicemente spostando un puntino sulla mappa andando su “Edit data”.

È possibile anche impostare delle domande concatenate con una delle domande precedenti, ma questa funzione è stata assimilata solo dopo. Esempio: nel nostro caso era possibile fare le domande in riga 9 e 10 di specificazione su nome e copertura wi-fi solo se prima l’utente aveva selezionato ‘si’ alla domanda in riga 8, che richiedeva di dire se c’era un free wi-fi nelle vicinanze. Bisognava allora inserire una colonna denominata ‘Relevant’ accanto a ‘Label’ in corrispondenza di tali righe con campo ${si_no} = ‘si’, dove $ sta per ‘selected’ seguito tra parentesi graffe il nome della lista di risposte relative alla domanda (nel nostro caso si_no) seguito da un simbolo di “uguale” (‘=’) e dalla risposta tra apici singoli (”).

Nel secondo foglio di lavoro vanno inserite le griglie di risposte possibili alle varie domande a risposta multipla: il link con il primo foglio è dato dal nome della lista delle risposte inserito nella colonna ‘type’ dopo la dicitura select_one (oppure multiple), che viene ripetuto nel secondo foglio in prima colonna, chiamata ‘list name’.

È utile anche perché è possibile così evitare di riscrivere opzioni di risposta inserite già in altre liste, potendo riferirsi alla stessa: il più semplice esempio è dato dalle risposte come “si” o “no”. Se la lista di risposte si chiama si_no, è possibile inserire due domande del tipo select_one [si_no], con nome ed etichetta diverse, scrivendole nel foglio choices una volta sola.

A questo punto, se si vuole è possibile aggiungere un altro foglio denominato ‘settings‘, dove inserire due colonna, ‘form_title’ e ‘form ID’, tramite cui è possibile denominare il questionario: in assenza il questionario avrà lo stesso nome dato al file xls che verrà caricato sul sito.

‘Lato applicazione mobile’: GeoODK Collect e WebForm

Giuseppe: Il terzo componente del sistema è quello ‘mobile‘, ovvero relativo alla raccolta vera e propria dei dati.

Una volta scaricata l’applicazione GeoODK Collect, ricordiamoci che è solo nel Play Store, la schermata iniziale è la seguente.

Per partire con la raccolta bisogna modificare le impostazioni preimpostate e caricare la form che ormai abbiamo già messo sul server. E’ necessario innanzitutto premere l’icona delle impostazioni (Settings) e poi General Settings, selezionare ‘altro server’, modificando l’URL preesistente con il server utilizzato per caricare i dati sul web, https://ona.io/nome_progetto/.

Tornando nelle impostazioni precedenti è necessario poi cliccare su ‘form management’, dove compariranno tutte le form create dal proprio account nel server e selezionare quella che ci interessa. Dopo aver premuto “prendi selezionato” e aver dato l’invio cliccando su “ok”, si ha in memoria la form “vuota” e si possono raccogliere i dati andando sull’icona ‘collect data’ e selezionando la form appena scaricata.

La app dà la possibilità di fare una serie di operazioni: modificare i dati delle form già compilati e salvati (edit data), spostare la posizione dei rilevamenti qualora non fossero abbastanza accurati, eliminare form (delete data) e, infine, inviare i dati al server (send data). Quest’ultima operazione è quella che ‘vuota’ dei dati il nostro dispositivo mobile: ricordiamo, infatti, che l’iniziativa ODK nasce per scopi ‘sociali’ e umanitari, ed è pensata pertanto per raccogliere dati anche in assenza di una copertura di rete, con pertanto la possibilità di inviare i dati soltanto una volta in cui questa sia resa disponibile.

Viola: Gli stessi dati possono essere raccolti anche tramite una webform, ovvero una pagina web dove sono riportate i medesimi quesiti della form, solo organizati ovviamente con un layout diverso. Perché usare questo strumento anziché l’app? per 3 motivi:

1. Per i pigri che non vogliono installare l’app ma operare da browser;
2. Per i possessori di dispositivi non-Android (Windows Phone e iPhone)
3. Più semplicemente per chi ha magari acquisito dei dati ‘su carta’ e vuole ‘buttarli dentro’ a una banca dati comodamente seduto alla scrivania.

Attenzione che però non tutti i browser funzionano bene! Se vi interessa acquisire immagini, video o audio ci sono alcune limitazioni: serve il browser Chrome, se poi avete un iOS potete averle solo tramite un browser che si chiama Puffin! Comunque la rilevazione di tutti gli altri campi sarà possibile

Giuseppe: Se siete curiosi di provare GeoODK e a inserire qualche dato, provate con il progetto ‘Trieste Free Wifi Movida’! Si è concentrato sulla città di Trieste e per ora è terminato (Viola ha finito la tesi di laurea magistrale, e quello era l’oggetto della ricerca!), però potete provare a inserire dei dati sul wifi e sull’affollamento dei locali nella vostra città (magari mandateci un’email così mostriamo qualche elaborazione!). Potete farlo tramite la webform su Enketo qui sotto:Anche in questo caso è possibile sia inviare i dati immediatamente (‘submit‘ a fine acquisizione) o rimandare in un secondo tempo (e selezionare ‘save as draft‘).

https://rmvfk.enketo.org/webform

Oppure, dopo essersi installati GeoODK, andare su “Settings”, sotto “General Settings” scegliere il server “Altro” e inserire https://ona.io/triestegeo.

Su “Form Management” (sempre sotto ‘settings’) selezionare la form “Trieste_FreeWiFi_Movida”

A questo punto è possibile raccogliere dati e inserirli nel database creato per questa form (ovviamente la procedura sarà la medesima quando avrete creato il vostro progetto in Ona e caricato una o più form)!

La nostra Viola ha preparato anche un video su Youtube con una panoramica su come impostare la form su GeoODK e iniziare ad acquisire i dati! https://www.youtube.com/watch?v=EP2PA5ysyEk

Altre applicazioni

Viola: Questa applicazione è stata utilizzata anche per raccogliere dati sull’affluenza a due eventi cittadini, TriesteNext (weekend dedito alla divulgazione scientifica e dimostrazioni nell’ambito accademico organizzati dall’Università di Trieste) e FuoriRegata (serie di eventi lato terra che si svolgono la settimana precedente alla Barcolana). Con uno stand di ‘geografi’ capeggiati dal qui presente Giuseppe, sempre a Trieste Next 2015, abbiamo poi presentato due attività permesse dalla customizzazione di questa applicazione: una per ‘mappare’ la provenienza dei visitatori a Trieste Next e un’altra per la mappatura delle zone problematiche legate all’accessibilità e alle barriere architettoniche della città di Trieste.

Appena pronti vi segnaleremo i collegamenti ai lavori che sono stati realizzati su questi progetti!

Conclusioni – altri sviluppi

Per i nostri progetti di mobile data collection abbiamo scelto la base di Open Data Kit per strutturare il sistema di raccolta dati, accompagnato all’app per dispositivo mobile GeoODK. In realtà GeoODK non è l’unica app che lavora in questo sistema. ODK Collect e Kobo sono due app che si basano sulla medesima architettura per la raccolta dei dati, consentendo anche la gestione di dati geolocalizzati.

(https://play.google.com/store/apps/details?id=org.odk.collect.android&hl=it; https://play.google.com/store/apps/details?id=org.koboc.collect.android&hl=it)

L’unico problema in questi due esempi è dato dal fatto che solo dati puntuali possono essere acquisiti durante una ‘campagna’ e possono essere visualizzati e modificati solo dopo averli scaricati su server.

Nel caso di GeoODK invece funzioni di visualizzazione e di editing dei dati possono essere fatte già da dispositivo mobile prima di caricarli sul server.

Un altro elemento importante, che tuttavia stiamo appena testando, è dato dal fatto che GeoODK consente di acquisire dati anche sotto forma di polilinea o poligono, oltre che punti (v. sopra il riferimento alle funzioni Geopoint, Geotrace e Geoshape). In questo caso, tuttavia, al momento le soluzioni lato server come ona.io non supportano la gestione di tale dato, per cui si rende necessario installare localmente ODK Aggregate, ovvero il server di aggregazione dei dati da dispositivo mobile. Siamo in fase ‘work in progress’ anche noi, speriamo di riuscire a testare anche questa soluzione!

Per qualsiasi approfondimento non esitate a contattarci! Saremo felici di rispondere e approfondire gli argomenti!

Pensato e scritto da Giuseppe Borruso

Nasco geografo economico, mi interesso di Geographic Information e di Smart Cities. Attratto dalle tecnologie ICT e dall’innovazione, ma sempre con l’uomo al centro. Professore di Economic Geogrphy, GIS e Geografia delle Reti. Presidente del Comitato Scientifico dell’Associazione Italiana di Cartografia. Nel tempo libero, poco, running o MTB

Pensato e scritto da Viola Defend

Fresca fresca di laurea magistrale in Scienze Aziendali, ho scoperto “all’ultimo minuto” una passione per Smart Cities, GIS e Citizen science, di cui ho scritto per il lavoro di tesi. Sono fermamente convinta che non esistano Smart Cities senza Smart Citizens e che la tecnologia sia un mezzo e non un fine per migliorare le città.

L'articolo Raccolta dati per tutti: GeoODK e smartphones per sensori urbani (parte II) è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Sappiamo che tali iniziative sono possibili in misura sempre maggiore grazie a delle “rivoluzioni” che ci hanno coinvolto molto da vicino e relativamente molto recenti. L’aumento della velocità di trasmissione dati su Internet, l’abbassamento dei costi legati alle tecnologie ICT, la disponibilità di sistemi di localizzazione GNSS (GPS e altri) a basso costo e di buona precisione (almeno per applicazioni diverse da quelle geodetiche!) e lo sviluppo di smartphone e Social Network hanno senz’altro reso più facile e veloce l’interazione tra individui dotati di dispositivi “smart”, tra loro e con piattaforme di condivisione di dati e informazioni.

Questo è senz’altro vero, ma iniziare a raccogliere dati geolocalizzati in maniera ordinata e sistematica e c ondividerli alla fine del processo richiede nella maggior parte dei casi un po’ di doti di programmazione o quanto meno di familiarità avanzata con strumenti di tipo informatico.

Tale premessa è alla base di quanto abbiamo cercato di sviluppare, a partire dall’estate del 2015, con i ragazzi dell’insegnamento di Geografia delle Reti, nell’ambito dei Corsi di Laurea Magistrali in “Scienze Economiche” e “Scienze Aziendali ” dell’Università di Trieste.

L’idea di partenza era quella di sperimentare modalità di crowdsourcing nell’acquisizione di dati geografici relativi a fenomeni urbani su piattaforme una soluzione senza costi di licenza e con un limitato ricorso a doti di programmazione.

Viola: Oltre ad una soluzione a basso costo e di relativa semplicità nell’impostazione del questionario, volevamo uno strumento che, oltre
a poter registrare dati sotto forma di punti, polilinee o poligoni, avesse queste caratteristiche:

• relativa applicazione scaricabile (gratuitamente) su smartphone;
• permettesse la compilazione del questionario anche in caso di assenza di rete;
• permettesse di caricare un numero molto elevato di risposte da vari dispositivi (o comunque un numero in linea con le nostre esigenze);
• fosse compilabile via sito web (in caso di problemi di compatibilità con il sistema operativo del telefono o in presenza di qualche buon’anima ancora dotata di Nokia 3310 come arma di battaglia!)

Potrebbero sembrare delle premesse un po’ pretenziose ma dopo varie ricerche, qualche decina di download (wi-fi permettendo) a causa di una rete casalinga un po’ ballerina, qualcosa abbiamo trovato.

Ci siamo imbattuti nella “galassia” di Open Data Kit, un progetto “open” che consente l’impostazione di sistemi client-server di raccolta
e archiviazione di dati da parte di operatori sul campo tramite dispositivi mobili.

Dal sito (https://opendatakit.org/) si legge che ODK (dove ODK sta per Open Data Kit, nel caso ve lo stiate chiedendo) è un “free and open-source set of tools which helps organizations author, field, and manage mobile data collection solutions“, che consente di:

• costruire una form (o “questionario”) di raccolta dati;
• raccogliere dati su di un dispositivo mobile;
• aggregare i dati raccolti su di un server ed estrarli in formati utilizzabili.

Giuseppe: Open Data Kit inizialmente si è sviluppato basando su Google la gestione del proprio “lato server”, dopodiché si è affrancato dal mondo ”commerciale” basandosi soprattutto su architetture open source.

Il sistema richiede diversi elementi, esemplificati nell’immagine qui sotto, da integrare.

Innanzitutto una form, ovvero il questionario da sviluppare.

Una ‘piattaforma’ per la raccolta dei dati: qui ci viene in aiuto enketo.org per la realizzazione di una webform compilabile da (virtualmente) qualsiasi dispositivo, oppure un’app da caricare su dispositivo mobile. Diverse app sono state sviluppate: ODK Collect e KoBo Collect, solo per citarne un paio, soprattutto nell’ambito di progetti a contenuto umanitario o sviluppati apposta per scopi educativi.

Un server, ovvero un sistema centralizzato in cui salvare i dati immessi. Senza ricorrere a un nostro server si può fare riferimento alle piattaforme ODK aggregate e Ona.io.

Viste le applicazioni alternative basate sulla stessa base ODK, abbiamo scelto GeoODK perché ci è sembrata la più semplice e completa, perché consente anche la modifica dei dati prima dell’upload su una base cartografica digitale e di caricare sul dispositivo dei layer geografici ad hoc (non necessariamente le basi di sfondo tipo OpenStreetMap) – funzionalità non implementata nell’esempio che abbiamo riportato in questo report.

Il Sistema ODK (Open Data Kit) e le sue componenti

Inutile dire che, per i nostri scopi, l’attenzione era rivolta alla raccolta di dati georeferenziati, sfruttando il GPS interno per geolocalizzarsi. Il
sistema ‘ODK’ offre numerose app già pronte utili per la raccolta dei dati, come ODK Collect e KoBo collect. Queste tuttavia consentono soltanto di caricare dati geografici sotto forma di punti (coppie di coordinate) e hanno un’interfaccia molto semplice e tutto sommato limitata, senza grandi possibilità di editing e visualizzazione dei dati sul dispositivo mobile.

Viola: L’applicazione scelta è stata GeoODK, dove il “Geo” sta per Geographical (Open Data Kit), sviluppata sempre a partire dalla piattaforma ODK, ma con un’attenzione maggiore al lato geografico.

In particolare consente varie cose in più rispetto a ODK, ovvero:

• è più semplice;
• consente di visualizzare e modificare i dati prima dell’upload su una base digitale sullo smartphone o tablet;
• consente di caricare localmente dei layer geografici ad hoc (non necessariamente le basi di sfondo tipo OpenStreetMap) – funzionalità non implementata nell’esempio riportato;
• consente di registrare, anche tramite form, dati sotto forma di punti, polilinee o poligoni (funzioni “geopoint”, “geotrace” e ”geoshape”).

GeoODK permette di strutturare un questionario tramite un semplice file Excel (se vedete la parola “form” più avanti non vi spaventate, ci riferiamo a questo) e qualche piccola accortezza, fornendo già sia la propria applicazione mobile sia una soluzione “lato server” per l’aggregazione dei dati, individuata inizialmente in Formhub, dopodiché (a causa della sua lentezza e dell’abbandono da parte degli sviluppatori) trovata nella piattaforma ona.io (anche questa in seguito non più disponibile completamente free). L’alternativa “locale” rimane sempre ODK Aggregate, da installare su di un proprio server.

Mentre la seconda soluzione è più laboriosa, richiedendo di caricare ODK Collect sul proprio server (per il momento ci stiamo pensando ma non abbiamo ancora messo in pratica di sfruttare il server dell’Università di Trieste e il nostro adorato informatico A.P.), Formhub era già bello e pronto e richiedeva solo l’iscrizione (ovviamente gratuita) dell’utente. Problema incontrato già al momento della scelta di utente e password: il server faceva venire i sudori freddi. Era in sovraccarico un buon 70-80% delle volte in cui ci si connetteva e si aveva bisogno di lui. Qualche settimana fa poi il server non è definitivamente più aggiornato dall’organizzazione che se ne occupava quindi ve lo sconsigliamo proprio.

Il sito web http://geoodk.com/tutorials.php contiene un buon videotutorial su come impostare i diversi elementi di un progetto di Mobile Data Collection, presentati al GIS Day 2014. Da quello siamo partiti per il nostro lavoro, e qui sotto cerchiamo di sintetizzarlo un po’ a un pubblico italiano.

Dopo un paio di mesi di stress ed incubi causati dai continui problemi di sovraccarico di Formhub, a settembre il magico prof (Giuseppe) ha trovato un nuovo server su cui caricare i dati. Stesso layout di Formhub, stesse funzioni… la copia conforme ma rapidissima: Ona.io.

Così, un’altra registrazione più in là siamo finiti su un altro server felici e contenti come pasque. Escludendo il fatto che il primo ottobre hanno rilasciato una nuova piattaforma dal diverso layout per cui abbiamo avuto entrambi un colpo al cuore…temevamo di aver perso tutto!

In realtà abbiamo scoperto che dal 21 ottobre cambiano i termini di utilizzo e, in verità, il sito è stato migliorato e con le attuali condizioni è possibile avere un account gratuito caricando fino a 15 questionari e ricevendo fino a 500 risposte al mese, che tutto sommato – poi dipende dall’uso che si vuole fare- sono un buon numero.

LA SETTIMANA PROSSIMA IL SEGUITO …

Pensato e scritto da Giuseppe Borruso

Nasco geografo economico, mi interesso di Geographic Information e di Smart Cities. Attratto dalle tecnologie ICT e dall’innovazione, ma sempre con l’uomo al centro. Professore di Economic Geogrphy, GIS e Geografia delle Reti. Presidente del Comitato Scientifico dell’Associazione Italiana di Cartografia. Nel tempo libero, poco, running o MTB

Pensato e scritto da Viola Defend

Fresca fresca di laurea magistrale in Scienze Aziendali, ho scoperto “all’ultimo minuto” una passione per Smart Cities, GIS e Citizen science, di cui ho scritto per il lavoro di tesi. Sono fermamente convinta che non esistano Smart Cities senza Smart Citizens e che la tecnologia sia un mezzo e non un fine per migliorare le città.

L'articolo Raccolta dati per tutti: GeoODK e smartphones per sensori urbani (parte I) è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

La sintassi di base per leggere le informazioni da queste fonti è:

ogrinfo -ro -al -noextent CSW:http//catalogo.it/csw

L’utility di riferimento è ogrinfo, e sono a disposizione quindi tutte le altre opzioni del comando.

I cataloghi CSW sono un po’ come quei cassetti pieni di calzini in cui, in occasione di una importante ricorrenza, cerchiamo quelli lilla a pois bianchi (sono an pendant con l’ultima nostra meravigliosa giacca), ma per troppa abbondanza e varietà non riusciremo mai a trovare. Bisogna anche saper cercare

OGR è l’ultimo arrivato tra gli strumenti di accesso e ricerca. Ecco qualche semplice esempio, basato sul catalogo del Repertorio Nazionale dei Dati Territoriali (RNDT).

Avere l’elenco di tutti i record del server

ogrinfo -ro -al -noextent CSW:http://www.rndt.gov.it/RNDT/CSW -oo MAX_RECORDS=100

Sul catalogo RNDT sono presenti più di 17000 record, quindi la risposta al comando sarà “lunga”. L’opzione MAX_RECORDS fissa il numero massimo di record che è possibile ricevere ciclicamente durante una chiamata. Nell’esempio di sopra, per 17000 record quindi 170 cicli, ognuno composto da 100 record di output.

Tutti i record all’interno di una determinata area

ogrinfo -ro -al -noextent CSW:http://www.rndt.gov.it/RNDT/CSW -spat 12 35 15 38 -oo MAX_RECORDS=100

Ogni record di un catalogo CSW è associato ad un’estensione geografica. Inserendo il parametro -spat si impostano le coordinate del boundig box (xmin ymin xmax ymax, in EPSG:4326) all’interno del quale si vuole eseguire la ricerca: in risposta si avranno tutti i record ricadenti in quell’area.

Tutti i record che contengono una determinata parola (stringa di testo) in uno dei campi esposti dal catalogo

ogrinfo -ro -al -noextent CSW:http://www.rndt.gov.it/RNDT/CSW -where \"abstract LIKE '%geologia%'\" -oo MAX_RECORDS=100

In questo modo si cercheranno tutti i record che contengono la parola “geologia” nel campo “abstract”. Ad oggi sono 31.

Gli altri campi che è possibile sfruttare per fare ricerche sono:

• identifier (String)
• other_identifiers (StringList)
• type (String)
• subject (String)
• other_subjects (StringList)
• references (String)
• other_references (StringList)
• modified (String)
• abstract (String)
• date (String)
• language (String)
• rights (String)
• format (String)
• other_formats (StringList)
• creator (String)
• source (String)

Tutti i record che contengono una determinata stringa in un campo qualsiasi

ogrinfo -ro -al -noextent CSW:http://www.rndt.gov.it/RNDT/CSW -where \"anytext LIKE '%frane%'\" -oo MAX_RECORDS=100

La stringa cercata è “frane”, e si ottengono 52 record.

Tutti i record della ricerca precedente ma in formato ISO 19115/19119

ogrinfo -ro -al -noextent CSW:http://www.rndt.gov.it/RNDT/CSW -where \"anytext LIKE '%frane%'\" -oo OUTPUT_SCHEMA=gmd -oo MAX_RECORDS=100

L’output in questo caso è secondo lo schema descritto qui http://www.isotc211.org/2005/gmd. Se invece si scrive OUTPUT_SCHEMA=csw, sarà secondo queste specifiche http://www.opengis.net/cat/csw/2.0.2.

Tutte le altre novità su GDAL/OGR 2.0.0 le trovate sintetizzate nel post di Even Rouault e purtroppo il catalogo RNDT non è ancora nel registro INSPIRE!

L'articolo GDAL-OGR per accedere a cataloghi geografici (CSW) è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Sono più di tre anni che uso geopaparazzi, cioè fin dalla sua nascita con i suoi bachi e i suoi problemi. Mi sento onorato di aver contribuito allo sviluppo di questo software, sia pure in modo passivo, nel senso che non ho scritto neppure una linea di programma ma ho testato il software in lungo e in largo per i miei bisogni di turista fai da te.

Due anni fa, durante una vacanza in un’isola greca con mia moglie, seguendo con la cartina del luogo un sentiero segnato male ci siamo persi.

Fortezza di Antimachia a Karadameno, Isola di Kos. Geopaparazzi su HTC Wildfire.

Erano le tre del pomeriggio e c’era il sole, ma … fortunatamente avevo scattato molte foto e aiutandomi un po’ con le immagini e un po’ con il ricordo dell’orografia del luogo riuscimmo, per altra via e con tre ore aggiuntive, a ritornare al luogo di partenza. Mi dissi: mai più dovrà ripetersi un caso analogo!

E da quel giorno geopaparazzi mi segue ovunque.

Vi scrivo alcuni accadimenti banali, ma credo significativi, per far capire ai vostri lettori eventualmente interessati come sia utile questo strumento.

• Mia moglie ed io per i nostri viaggi ci affidiamo regolarmente al sito booking.com. Di solito sono abbastanza precisi, ma… vi lascio intendere dalla email che mia moglie ha mandato al sito durante le vacanze:

“Gentili Signori, siamo utenti di booking.com e abbastanza soddisfatti del servizio che viene riservato. Tuttavia abbiamo un’osservazione da fare: essendo dotati di GPS per rintracciare agevolmente la struttura dove andremo a pernottare, abbiamo rilevato che le strutture alberghiere a Kalymnos -vedi hotel Panorama- ed a Astypalaia  -vedi studio Ixthioessa- ma anche altre di cui abbiamo verificato la posizione (vista mare studios: sulla vostra mappa è segnalato in collina ed invece è a un centinaio di metri dal porto), sono segnalate nelle vostre mappe a distanze variabili da 500 a 1000 metri rispetto alla posizione reale. E’ importante che le coordinate GPS corrispondano alla posizione reale della struttura perchè è anche in base alla posizione della stessa che si fa la scelta.
Ixthioessa ad Astypalaia: sulla Vs. mappa: lat 36.54874  lon 26.35278  a noi risulta lat: 36.54978 lon: 26.35557
Vi chiediamo di verificare e rettificare le posizioni.
Cordiali saluti luciana a.”

• Quest’estate ero a cercar funghi con un gruppo di amici; all’ora di tornare alla base l’opinione sulla via del ritorno da prendere non era esattamente condivisa: alcuni dicevano “di qua” altri “di là”. Prendemmo una delle due direzioni e, fatti pochi metri, il mio amico geopaparazzi mi mostrò che la direzione era sbagliata. Ovviamente la rettifica fu immediata e alcuni amici si mostrarono interessati a quello strumento.

Al ritorno verso l’albergo, guidati da geopaparazzi, nella Barcellona notturna.

• Ero in ferie con mia moglie a Barcellona (ebbene sì, sono spesso in giro perchè sono in pensione da dodici anni ormai) per la prima volta, e visitando la città è difficile rendersi conto di quanto passi velocemente il tempo se non quando si accendono le illuminazioni stradali e improvvisamente ci si sente sperduti. Naturalmente in una città non c’è rischio di perdersi (taxi e indirizzo dell’albergo risolvono tutti i casi) ma l’idea di vedere anche aspetti della città notturna ci piaceva e così ci permettemmo una serata tarda in luoghi qualsiasi con la certezza che geopaparazzi ci avrebbe riportati a casa. In albergo mia moglie mi disse “regala 50€ per una pizza a chi ha sviluppato quel marchingegno (proprio così disse: marchingegno!)” e così feci: non succede spesso che una donna apprezzi così apertamente certa tecnologia ….

• Un amico camminatore con poca esperienza delle montagne del meranese mi chiese un giorno di indicargli un bel percorso in alta quota. Stavo per raccontargli una delle mie gite, quando mi venne l’illuminazione. “che cellulare hai?” gli chiesi. Mi fece vedere un HTC. “Magnifico” dissi. E gli spiegai come scaricare Geopaparazzi, come vedere i percorsi in Google Earth, ecc. ecc.. “Ti manderò via e-mail le istruzioni per usare quel software insieme al file del percorso che stavo per raccontarti. Se avrai problemi, telefonami”. Ci lasciammo così e gli inviai quanto promesso. Era un mercoledì (lo ricordo perchè la storia è recente) e il lunedì successivo mi arrivò una sua e-mail carica d’entusiasmo sia per il luogo visto che, soprattutto, per la semplicità con cui aveva potuto seguire il percorso.

Potrei raccontare ancora per molto, ma credo di aver superato il limite di tolleranza di ogni buon lettore “scientifico”.

Nel frattempo il mio hardware si è evoluto. L’HTC era troppo lento e spesso “crashava” per la mia impazienza a spostare le mappe sul monitor. In giugno 2013 mi sono regalato un Samsung Galaxy Note2 N7100: una bomba!!! Ci ha accompagnati ad Astypalea (Grecia) senza un attimo di incertezza. Sarà la ns. guida fino a quando… non sarà diventato troppo lento anche lui.

Ci sono ancora alcune cose che mi piacerebbe veder fare a geopaparazzi ma mi rendo conto che non posso sempre chiedere e mai dare. Sono sicuro, tuttavia, che l’autore di geopaparazzi continuerà, come nel passato, a curare lo sviluppo e la manutenzione di questo software che ormai chiamo “geofriend” e prima o poi i miei desideri saranno esauditi perchè saranno diventati necessità per molti.

Per finire un consiglio ai turisti fai da te: è sempre bene viaggiare anche con una cartina della zona, oltre che con geopaparazzi: qualche volta batterie e/o satelliti giocano brutti scherzi…

Grazie per l’ospitalità sul Vostro guest post e per la vostra attività su TANTO.

L'articolo Geopaparazzi e il turismo fai da te è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

iD Editor

Da alcuni giorni, come reso noto dalla notizia di lancio, sulle pagine di OpenStreetMap è attivo un nuovo strumento per l’editing online delle mappe. L’ultimo arrivato, nella grande famiglia degli editor per OSM, sia chiama iD e andrà ad affiancare il buon vecchio Potlach, noto a chiunque abbia fatto un po’ di inserimenti e di modifiche sui dati OSM.

Si tratta di uno strumento che, a fronte della leggerezza e della chiarezza a livello di interfaccia utente, nasconde una discreta dose di tecnologia, tutta Open Source, nata dal lavoro volontario di alcuni sviluppatori, e proseguita con un notevole sostegno economico (parte dei 545.000 $ offerti dalla Knight Foundation), sotto il coordinamento di MapBox.

L’aspetto più evidente di iD, e che ne ha motivato la realizzazione, è un approccio “assistito” all’editing. Ogni azione viene guidata tramite suggerimenti e le scelte degli oggetti, e delle relative proprietà, da associare agli elementi geometrici inseriti, viene semplificata con l’ausilio di moduli d’inserimento intuitivi e facilmente comprensibile anche ai meno esperti, lasciando tuttavia la libertà di integrare le informazioni di base con tag più avanzati.

Ma cos’è che ha spinto la Knight Foundation e MapBox a finanziare questo progetto? La notizia ha colto l’attenzione anche di testate giornalistiche non del settore quali Mashable e TechCrunch, ed entrambi hanno voluto sottolineare la sfida alle altre realtà commerciale del mapping online, Google in primis. In effetti la mossa operata con l’introduzione di iD ha reso ancor più evidente il mix di qualità del progetto OpenStreetMap : open data, strumenti tecnologici efficaci e robusti, crowdsourcing a scala globale, opportunità commerciali. Le ho elencate in quest’ordine non per caso.

La scelta, operata fin dall’inizio, di associare al dato OSM una licenza aperta (inizialmente CC-BY-SA, poi trasformata in ODbL) è stata senz’altro il carburante che ha dato il via al tam-tam globale, garantendo agli utenti una totale trasparenza sull’impiego dei dati liberamente forniti. Questa caratteristica, oltre ad essere motivante per molti utenti, è unica tra i progetti di mapping crowdsourced a scala globale (Google Map Maker, per dirne uno, i dati se li tiene ben stretti!).
La totale trasparenza e il pubblico dominio hanno fornito una forte spinta motivazionale, tanto all’utente amatore quanto agli sviluppatori e ai sistemisti. Lo sviluppo di un set di tecnologie ben focalizzate ed efficaci in grado di gestire tutte le fasi di vita del dato, e di intercettare e rispondere ad un’utenza estremamente variegata (dall’azienda, all’operatore in aree di emergenza, al byker appassionato), ha avviato il circuito virtuoso. Ecco che dal computer di Steve Coast, OSM ha invaso il mondo.
Con quali soldi è stato possibile realizzare tutto ciò, e chi sostiene oggi OSM? Qui sta l’emblematicità di OSM, e che io ritrovo esemplificata nella nascita di iD: un progetto nel quale tutti possono trarre benefici, dagli utenti appassionati alle aziende (fino alla scala di Foursquare, Evernote, MapQuest, la stessa MapBox e tante altre). E più tutti ne traggono beneficio, più ognuno è disposto a contribuire: l’utente a mappare, l’azienda a fare il proprio business col supporto dei dati OSM e a sostenere il progetto (se l’azienda è saggia e lungimirante!). OSM sarà un caso un po’ unico, soprattutto di questa portata, ma dimostra, insieme ad altri progetti simili (basta pensare a Wikipedia) che è un processo realizzabile e sostenibile, con un modello di business non utopico.

In sintesi, e semplificando un po’, un buon editor rende la vita più semplice all’utente, e magari ne attrae di nuovi -> MapBox può contare su una maggiore base di contributori e di dati -> MapBox sostiene lo sviluppo di iD

Chissà se un giorno riusciremo a innescare un processo virtuoso simile anche per gli Open Data in Italia

Buona mappatura a tutti con iD!

Giovanni Allegri
Segui @_giohappy_

L'articolo Il nuovo editor per OpenStreetMap, esempio di un processo virtuoso è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Considerato che ogni volta che scrivo la parola INSPIRE mi tremano le mani e ogni volta che ne parlo mi trema la voce, è stata un’esperienza interessante, anche al fine di smitizzare e abbattere alcuni muri, nonché confermare alcune assurdità che la complessità degli standard porta inevitabilmente con sé.

La certezza che ora ho è che la migrazione di dati verso gli schemi INSPIRE è una procedura molto complessa, ma non impossibile, e che richiede freddezza nella preparazione e personale capace e aggiornato da un punto di vista tecnico.

Io in generale non credo ai software dall’unico pulsante magico.

Credo però nel senso di una procedura guidata. Credo in un software che possa semplificare i passaggi importanti di tale procedura, supportando soprattutto la leggibilità degli schemi di dati e la consistenza delle mappature che si vanno ad operare.

Humboldt & Hale

Il software che ho avuto modo di testare (e poi anche estendere) si chiama Humboldt Alignment Editor (Hale per gli amici) e nasce da un progetto europeo che ha coinvolto 26 partner fra il 2006 e il 2011 (fra i quali gli italiani di CNR-IREA, GISIG, Telespazio e dell’Università di Roma). Il progetto Humboldt si è occupato principalmente dell’armonizzazione dei dati a livello europeo. Data la moltitudine e diversità dei dati presenti nelle varie organizzazioni europee, naturalmente non si trattava di re-inventare la magia nera, bensì di creare strumenti che potessero supportare il processo di implementazione.

Dal progetto Humboldt è nato il Data Harmonization Panel (DHP), una piattaforma di esperti nell’armonizzazione dei dati spaziali. Lo stesso DHP si pone tutt’oggi due importanti obiettivi:

• lo sviluppo ed il supporto degli strumenti sviluppati in Humboldt
• il supporto di un framework di formazione

Del progetto Humboldt oggi viene sviluppato in modo attivo praticamente solo la componente Hale. Il progetto è rilasciato con licenza Free ed Open Source alla community per facilitarne l’interazione ed il miglioramento.

E’ proprio la natura open del progetto che mi ha portato prima ad avvicinarmi a Hale attraverso FreeGIS e poi, in un secondo momento, quando ho avuto il piacere di essere chiamato a svilupparne alcune funzionalità nel team geospaziale del Fraunhofer IGD (attuale centro di coordinamento del progetto).
E’ stata questa collaborazione che mi ha ispirato a scrivere un articolo riguardante Hale in modo da renderlo un pochino più noto al di fuori della cerchia accademica e dei progetti europei.

Ma bando alla storia e passiamo alla parte pratica.

Utilizzare Hale

Per mostrare il funzionamento di base di Hale mi rifarò in parte al progetto FreeGIS usando i dati della Provincia di Bolzano e descritti nel eGeo, il geoportale della provincia. Mi riferirò in particolare al set di dati di quello che è definito in INSPIRE RoadLink dello schema dei TransportNetwork.

Per chi volesse cimentarsi, è possibile scaricare Hale dall’area di download del sito del progetto per i sistemi operativi più diffusi.

Una volta lanciato, Hale si presenta in questo modo:

Le parti più importanti sono indubbiamente le viste dello Schema explorer e dell’Alignment.

Hale è stato concepito per mappatura di strutture di dati molto complesse, fra schemi di dati xml come lo possono essere ad esempio gli schemi CityGML. Il nostro esempio non renderà onore a questo potenziale, in questa sede si vuole piuttosto introdurre lo strumento in generale.

Definire lo schema di arrivo

La prima cosa da definire, è lo schema verso il quale si desidera mappare lo schema dei dati originali. Nel nostro caso si parla di dati del TransportNetwork, quindi è necessario caricare lo schema xml del RoadTransportNetwork di INSPIRE. Tale schema è scaricabile qui.

Una volta scaricato sul proprio disco rigido, è possibile importarne la definizione dal menu di import attraverso l’operazione target schema:

definendo poi nella procedura guidata il file da importare:

per poi trovarsi lo schema visualizzato nella sua struttura ad albero in Hale:

Da poco sono stati aggiunti alcuni schemi preconfigurati legati a INSPIRE, che si possono trovare nella tab denominata presets. Nel nostro caso lo schema di interesse è presente:

Definire lo schema di partenza

La definizione dello schema di partenza può essere una procedura semplice o molto complessa, dipendentemente dal formato in cui si sono mantenuti i propri dati (e questa è indubbiamente una scienza a parte). Hale permette l’import dello schema da file, ma anche da servizi WFS. Per set di dati molto semplici è possibile generare uno schema estraendolo da shapefile.

Come per il target schema, partendo nuovamente dal menu di import, procediamo ad importare il source schema:

per trovarci con la seguente situazione:

Nell’immagine la selezione è stata poi posizionata sui due tipi da mappare.

Come mappare gli schemi

Mappatura del tipo

La prima operazione da fare, è quella della mappatura dei tipi principali, in questo caso V_WEGE_IMS_TUN_FREEGIS verso il RoadLink INSPIRE.
Il dato di partenza pero’ contiene tutto il transport network (strade, ferrovie, etc), quindi bisogna procedere a creare una regola per estrarre solo le strade.

Con un GIS questa operazione è abbastanza triviale. In uDig l’operazione può essere fatta con il linguaggio CQL (Constraint Query Language).

Ad esempio ponendo delle condizioni sul campo giusto possiamo isolare le ferrovie:

oppure, cosa necessaria al nostro esempio, le strade:

Il motivo per il quale vi cito uDig è duplice. Perché è il GIS con il quale lavoro e che supporto in modo attivo, ma anche perché Hale supporta lo stesso identico linguaggio CQL.

E’ quindi possibile creare un condition context:

usando come condizione esattamente la stringa testata in uDig:

A questo punto Hale crea un nuovo tipo in base alla condizione imposta e sarà quello che verrà mappato attraverso un’operazione di Retype:

Una volta conclusa la procedura guidata, la mappatura sarà visualizzata nello schema explorer e nella vista dell’Alignment:

Mappatura degli attributi

Non voglio tediarvi con la descrizione dei vari attributi, quindi riassumerò solo alcune operazioni che si possono applicare per la mappatura degli attributi

Formattazione di stringhe

Permette di concatenare le stringhe dei diversi campi dello schema di partenza e delle costanti aggiunte manualmente per creare una stringa nello schema di arrivo:

Appena applicata la mappatura, viene visualizzata nella Alignment View e la vista delle proprietà ci fornisce una descrizione dell’operazione applicata:

Classificazione

La classificazione è forse una delle operazioni più importanti, permette di mappare classi di valori.

Un esempio molto semplice è la mappature fra dei valori interi 0/1 al loro booleano nello schema di arrivo:

Mappatura della geometria

E’ possibile eseguire la mappatura di geometrie:

Il tipo nel nostro caso è lo stesso, quindi una operazione di rename è sufficiente:

Non mi spingo oltre con la descrizione del processo di mappatura. Accenno solo al fatto che è possibile utilizzare anche degli script, cioè dei frammenti semplificati di programmi, che rendono possibili trasformazioni personalizzate molto complesse.

Controllo mappatura e trasformazione dati

Una volta conclusa la mappatura, la vista delle trasformazioni è quello che fa per noi. Ci permette di dare una controllata finale al grafico della trasformazione

e la possibilità di caricare un set di dati per eseguire una trasformazione secondo la mappatura precedentemente prodotta.

La procedura di import dei dati è simile a quella degli schemi, selezionando source data come tipo di import:

Il file da importare nel caso di questo esempio è lo stesso usato per definire lo schema:

Una volta importato il dato, viene visualizzato nella parte bassa dell’applicativo un set di esempio di dati originali e trasformati. Questo è molto utile per avere un idea dell’effettiva bontà della mappatura:

E’ infine possibile esportare il dato trasformato in formato GML, come richiesto da INSPIRE. Dal menu di export

è possibile accedere alla procedura guidata che definisce il formato di output e poi esegue l’operazione di export:

Conclusioni

Non è facile scrivere un breve articolo riguardante strumenti così complessi. Me ne sono reso conto in modo sempre più decisivo durante la stesura di questo articolo.

Spero comunque di essere riuscito a suscitare interesse per Hale.

Spero che sia evidente l’importanza di avere uno strumento aperto e trasparente in processi di questo tipo. Personalmente starei attento a generare dipendenze da software chiusi e proprietari in processi complessi quali la migrazione dei dati. Queste procedure infatti si protraggono anche per parecchio tempo; non di rado passano per sperimentazioni, tentativi e possibili cambi di attori. Un software aperto a tutti – invece – permette maggiore autonomia e dà la possibilità, volendo, di seguire i processi a tutti i livelli desiderati. Non va dimenticato che in questi contesti è spesso necessario adattare lo strumento a casi specifici, quindi avere la possibilità di estenderlo e modificarlo può essere una carta vincente.

Spero infine che sia chiaro che la trasformazione di dati fra schemi non è una cosa impossibile (in caso la fatica sta nell’apprendere gli schemi INSPIRE). Ci sono strumenti validi a supporto e Hale - a mio avviso - è uno fra questi. Esorto le amministrazioni a cercare gli esperti dei dati sul proprio territorio e non affidarsi a softwarehouse che promettono il fatidico pulsante magico… non è realistico. I professionisti locali del settore conoscono bene lo stato dei dati e le reali problematiche ad essi legati e nessuno più di loro desidera che i dati migrati siano della giusta qualità.

Infine, ai temerari e amanti del genere lascio il link al video informativo reso disponibile dal DHP, nel quale vengono introdotti i tutorial inseriti dentro a Hale sotto forma di procedure guidate, che ne facilitano l’apprendimento.

L'articolo Parlando di INSPIRE: di Humboldt & Hale è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Era un periodo tutt’altro che ideale, stavo faticando a preparare la presentazione per il GFOSS day, che si sarebbe tenuto solo pochi giorni dopo.

Ma considerato che la mia presentazione avrebbe tentato di fare una sorta di cronologia del mercato mobile e il punto riguardo alla questione Android e GFOSS, non potevo ignorare una questione che ritengo cambierà le sorti dello spatial sul mobile. Quindi passai qualche notte a integrare SpatiaLite in Geopaparazzi.

Durante la presentazione  che diedi alla conferenza:

mostrai solo una schermata nella quale Geopaparazzi dialogava con papà Furieri, chiedendogli delle trasformazioni di coordinate (si veda slide 50).

Ma da quel momento in poi non sono più riuscito a smettere di pensare al formato raster+vettoriale per lo scambio di dati fra sistemi operativi e dispositivi diversi.

Con SpatiaLite sarebbe stato finalmente possibile visualizzare nelle mappe di Geopaparazzi non solo punti e linee semplici, ma anche poligoni e grandi set di dati. Gli indici spaziali sarebbero stati d’aiuto, ne ero sicuro.

Quindi iniziammo ad implementare un nuovo piano in Geopaparazzi: il piano dei dati di tipo SpatiaLite.

E i primi risultati, usando i dati del progetto Natural Earth erano promettenti:

Natural Earth in Geopaparazzi

In itinere producemmo anche un breve tutorial per sviluppatori che volessero cimentarsi. Lo potete trovare qui.

Testammo la nuova versione su diversi dispositivi e in campo per un lavoro nelle paludi finlandesi, mentre validavamo i limiti dei bacini estratti durante le analisi idrolo-geomorfologiche. E visto che funziono’ cosi’ bene, decidemmo di rilasciare la versione, anche se non la si può ancora definire ottimizzata.

La seguente schermata mostra la sovrapposizione di una mappa di orienteering finlandese con i risultati delle analisi idrologiche: i limiti del bacino e i corsi d’acqua vecchi, nuovi e quelli estratti:

Mappe raster e vettoriali finlandesi

Avete notato la nuova icona sotto le icone di zoom? Quello e’ il pulsante per interrogare i dati. E’ possibile tracciare un rettangolo con le dita e l’applicazione mostra gli attributi degli oggetti compresi:

Interrogazione degli attributi su dati vettoriali

Questo ovviamente apre un nuovo mondo per Geopaparazzi ma in generale per lo sviluppo mobile geospaziale.

Un ringraziamento speciale va a Sandro per l’aiuto con l’ottimizzazione delle query spaziali e il supporto nello sviluppo praticamente in tempo reale.

Questa indubbiamente e’ la novità maggiore di Geopaparazzi 3.4.0, ma in realtà ve ne e’ una seconda abbastanza importante. In questa release e’ supportata anche la lettura di tag RFID via tecnologia NFC oppure bluetooth. La funzionalità e’ stata esposta all’utente all’interno delle schede personalizzate:

Scheda di rilevamento di tag RFID

E’ possibile inserire nelle schede un pulsante per la lettura del tag. Premendo il pulsante, si apre la schermata di scansione:

Schermata di scansione tag RFID via NFC oppure bluetooth

E’ possibile leggere i tag RFID sia attraverso la funzionalità NFC del dispositivo, ma anche attraverso antenne esterne collegate via bluetooth.

Una volta che l’id del tag e’ stato letto, il campo della scheda verrà compilato.

Una nota dolente dell’aggiunta di Spatialite deriva dal fatto che il pacchetto Geopaparazzi cresce da meno di 2 megabyte a più o meno 9 megabyte. Non abbiamo dubbi riguardo al fatto che tutti gli utenti saranno comunque contenti, vista la fantastica aggiunta.

Credo sia tutto per questa release. Speriamo possiate apprezzarla!

E’ possibile scaricare Geopaparazzi da:

la documentazione utente per questa versione e’ disponibile nel WIKI del sito principale.

L'articolo Rilasciato Geopaparazzi 3.4.0! Diamo il benvenuto ai fratelli di Spatialite è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Arrivati sul luogo, inizio però a sudare freddo: in prossimità del punto in questione ci sono infatti non uno, ma quattro tralicci. Su quale eseguire il rilievo? Non avevamo infatti informazioni sulla precisione delle coordinate ed inoltre sulla base fotografica che avevo consultato prima di partire i 4 tralicci erano pressoché invisibili. Ho provato quindi a rileggere la base fotografica sul campo e – a ben guardare – qualche pixel grigio che rappresentava i tralicci lo vedevo, ma le mie coordinate non corrispondevano in modo inequivocabile con nessuno di questi. Ne potevamo scartare certamente due su quattro, ma non c’era da stare allegri.
Decido allora, per disperazione e senza alcuna vera idea alle spalle, di lanciare geopaparazzi sul mio smartphone Android, e di leggere la base OpenStreetMap in corrispondenza della mia coppia di coordinate. Ingrandisco un po’ la vista e ”Resta di stucco: è unbarbatrucco”, sulla base OSM sono presenti i tralicci dell’alta tensione. Guardo un po’ meglio e le mie coordinate corrispondono esattamente ad uno dei 4 tralicci (sono i 4 quadratini bianchi che ho cerchiato in rosso). A quel punto è tornata la serenità e ci siamo messi a lavorare!!

Sto un po’ semplificando, ma non romanzando. Quanto visto sulla base OpenStreetMap non ci dava infatti alcuna vera certezza, perché non avevamo informazioni su precisione ed accuratezza delle coordinate a disposizione e la corrispondenza del punto mappa con la base OSM poteva essere assolutamente casuale. Di più, non avevamo sul campo nemmeno il tempo di verificare la bontà del dato vettoriale riportato su OSM. Avevamo però finalmente un riferimento di massima confortante, da usare per fare altre verifiche che ci dessero la certezza dell’oggetto da rilevare.
OpenStreetMap è stato quindi uno degli strumenti di lavoro di quella giornata.

Tutto questo è avvenuto grazie a diversi fattori, resi possibili e/o in qualche modo alimentati dalla cultura e dalla comunità che sta dietro ad OSM e da alcuni dei pilastri su cui si poggiano il mondo dell’open-data e dell’open-source.
OpenStreetMap è infatti “un progetto che crea e fornisce dati cartografici [...] liberi e gratuiti a chiunque ne abbia bisogno. Il progetto è stato avviato perché la maggior parte delle mappe che si credono liberamente utilizzabili, hanno invece restrizioni legali otecniche al loro utilizzo e ciò ne impedisce l’uso per scopi produttivi, creativi o inattesi.”
Oggi sembra tutto un po’ scontato, ma è stato il prerequisito che mi ha fatto pensare che potesse avere un senso leggere la base OSM; soprattutto per ciò che riguarda l’inatteso. Che cosa ci fanno infatti i tralicci dell’alta tensione in una base cartografica globale e non specialistica?
Una delle cose belle di OpenStreetMap è la libertà di inserire teoricamente qualsiasi strato informativo. I grossi provider di web-mapping forniscono dei servizi eccellenti da molti punti vista, ma gli strati informativi (tolti quelli di base) sono pochi. Ci sono infatti numerose informazioni sulle attività commerciali sparse nel territorio, perché si tratta di servizi orientati al business e alla pubblicità (delle Pagine Gialle globali) ed è raro trovare layer che non producano per gli stessi fornitori – in modo diretto o indiretto – un tornaconto economico. SuOSM invece chiunque può aggiungere qualcosa: gli alberi delle strade di Berna, sapere dove sono le Antilopi allo zoo di Berlino o per l’appunto i tralicci dell’alta tensione in provincia di Trapani. Ma bisogna essere un po’ fissati!
Scherzo, ma quando ho visto apparire i tralicci sulla mappa mi sono chiesto cosa porti un utente a mappare cose come queste. La risposta non è semplice e le ragioni possono essere le più varie. Sicuramente in OpenStreetMap viene sollecitata l’attitudine ad occuparsi del proprio “quartiere”, inserendo ad esempio i giornalai, le panchine, i cinema, i monumenti, i giardini pubblici, i sensi di marcia delle strade, ecc., delle aeree che si conoscono meglio; è un po’ come riempire di fiori le aride aiuole sotto casa. Tutto questo quasi sempre con il desiderio di eguagliare o superare altri utenti. Alle volte è soltanto il piacere di derivare dei dati (ad esempio da una foto aerea): si inizia da un traliccio, ci si prende gusto e si continua perché è molto piacevole “disegnare il mondo” e buttare un sassolino (anche molto più di uno) nel più grosso progetto di cartografia partecipata al mondo. Gli utenti attivi di OpenStreetMap sono pochi rispetto al numero totale, ma quando si inizia a mappare è difficile non essere presi da istinti monomaniaci. Cartografare su OSM è addictive, provate.
Dovevo anche, per la mia serenità, verificare qualità ed accuratezza del dato di quello specifico traliccio. Il database di OpenStreetMap non solo è predisposto per archiviare numerose informazioni sui dati inseriti, ma consente a chiunque di accedervi e di consultare alcuni metadati, come il nome dell’autore. Ed allora scoprire ad esempio che il traliccio in questione era stato caricato da David Paleino è stato un attimo. Gli ho scritto per saperne di più, soprattutto sapere da dove avesse derivato i dati. Mi ha risposto immediatamente e con la disponibilità e gentilezza che conoscevo già, fornendo informazioni per me fondamentali. Tutto questo è stato possibile soltanto perché il dato era corredato da informazioni liberamente accessibili.
L’entusiasmo e la competenza di David da soli non sarebbero bastati per tracciare i tralicci. Ha potuto farlo perché aveva le foto aeree di base da cui ricavare queste informazioni, ed in particolare perché il S.I.T.R. Sicilia consente di derivare dati dalle ortofoto regionali fornite in WMS. Queste foto hanno una risoluzione di 0.25 m. ed i tralicci si vedono molto bene (vedi foto sotto). Senza cartografia di base è molto difficile produrre dati derivati, e per fortuna l’attenzione al tema degli opendata geografici e sempre maggiore. In questo campo il movimento OpenStreetMap è sicuramente tra i pionieri.

Ho voluto raccontarvi questa storia, per le sue dimensioni e per la sua concretezza. Si tratta infatti di qualcosa di piccolo, nulla rispetto (ad esempio) all’adozione di OSM da parte di foursquare, ma che mi ha cambiato una giornata di lavoro.

L'articolo OpenStreetMap come compagno di lavoro è apparso originariamente su TANTO. Rispettane le condizioni di licenza.