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.

1. 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!).
2. 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!

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

Il 23 febbraio di quest’anno, in occasione del primo  Open Data Day italiano, ho assistito alla presentazione della strategia Open Data del Comune di Palermo.
Sono andato con entusiasmo all’incontro, ma sono tornato a casa pieno di dubbi, perché in quell’occasione ho avuto la sensazione che di strategia ce ne fosse poca, e che il Comune stesse realizzando l’apertura dei dati detenuti con poca consapevolezza.

Non è stato presentato un documento sulle linee guida, né tantomeno è stata annunciata una sua imminente realizzazione. Non è stata data alcuna comunicazione sugli investimenti ed il budget messo a disposizione per il mantenimento e l’ulteriore sviluppo del piano inerente la liberalizzazione dei dati. Sono state accennate, peraltro in modo molto generale, un paio di evoluzioni possibili del progetto, ma senza associarle ad una scadenza temporale, e non definendone le modalità di realizzazione.

Si è ancora in tempo per fare, ad esempio, queste due attività di divulgazione:

• esplicitare ai cittadini l’intero iter  che si vuole seguire, definendo con chiarezza: cosa ci si aspetta di ottenere; quali impegni concreti prende l’amministrazione; a quali vincoli le decisioni sono sottoposte (normativi, finanziari, istituzionali, ecc.);
• fornire tutte le informazioni necessarie affinché la partecipazione dei cittadini si possa basare su una conoscenza approfondita dei temi oggetto di discussione e non su semplici sensazioni;

Sono due punti “rubati” da un bell’articolo di Claudio Forghieri. L’articolo parla d’altro, di crowdsourcing applicata alla Pubblica Amministrazione, ma contiene diversi spunti utili per il tema degli OpenData, sia per i decisori che per i cittadini.

Discutere di dati aperti significa parlare di trasparenza dell’attività della P.A., ma anche e soprattutto, in questo momento di crisi, di opportunità per i cittadini, per gli sviluppatori, per le aziende.
Come detto, dalle istituzioni ci si aspetta, quanto meno, che venga tracciata una road map da seguire (si confronti, ad esempio, i  principi chiave sugli open data del Comune di Milano con la  sezione opendata del Comune di Palermo), ma anche che le stesse istituzioni interagiscano con la società civile (cittadini, aziende, ecc.).
Le due aspettative sono state finora entrambe disattese.

A distanza di due mesi da quella presentazione, non riscontro evidenze che migliorino questo quadro e navigando sul sito saltano subito agli occhi questi elementi:

• dal giorno del lancio non sono stati pubblicati nuovi dataset. Se ne ha evidenza nel box “Ultimi dataset” presente sulla pagina web del Comune dedicata agli Open Data;
• non è stato inserito un motore di ricerca dedicato, né tantomeno i dati sono pubblicati in modo da “essere facilmente identificabili in rete, grazie a cataloghi e archivi facilmente indicizzabili dai motori di ricerca” (vademecum OpenData);
• alcuni dati sono pubblicati in formato proprietario (ad esempio il formato .rar);
• i dataset non sono strutturati in modo tale da essere presentati in maniera sufficientemente granulare, così che possano essere sempre utilizzati dagli utenti per integrarli e aggregarli con altri dati e contenuti in formato digitale (Project Work Open Government Data)
  
• i dataset hanno un corredo scarso di metadati descrittivi;
• soltanto due dataset sono stati fatti confluire verso  dati.gov.it, il Portale nazionale dei dati aperti.

Ho scritto quattro email al Comune di Palermo e non ho mai avuto alcuna risposta. Nel giorno della presentazione era stato chiesto ai presenti di vivere in modo partecipato l’iniziativa, e che i responsabili del Comune sarebbero stati in ascolto e lieti di ricevere contributi dai cittadini. Sulla sezione del sito dedicata si legge: “Se vuoi proporre la pubblicazione di ulteriori dati interessanti e/o per eventuali segnalazioni contattaci“.

L’esperienza professionale e umana mi ha avvicinato molto al mondo degli Open Data. Per tale ragione scriverò a seguire anche alcune cose un po’ più “tecniche” e specifiche, perché l’esperienza è anche un grande supporto alla comunicazione. Partirò proprio dalle email che ho inviato.

Nella prima scrivevo “[...] solo per consigliarvi di non usare il formato .rar per i file compressi, in quanto è un formato proprietario [...].” Come detto, oltre a non ricevere alcuna risposta, i file .rar continuano ad essere presenti nel sito (ad esempio qui).
Nella seconda, in riferimento al dataset “PERIMETRAZIONE CIRCOSCRIZIONI COMUNALI“, scrivevo: “[...] è presente una grave lacuna: manca il file con la definizione del sistema di coordinate.[...]“. Il dataset è ancora sprovvisto di questa informazione fondamentale.
Nella terza segnalavo che il dataset “ELEZIONI AMMINISTRATIVE 2012 - AFFLUENZA ALLE URNE” non fosse scaricabile. Da qualche giorno è possibile farne il download.
Nell’ultima, un po’ più complessa, facevo notare come il dataset “TURISMO - ELENCO DEI SITI TURISTICI VISITABILI” contenesse alcuni errori. Questi sembrano stati corretti, ma l’ho scoperto per caso oggi.

Suggerisco al comune di creare un sistema di feedback, al limite anche automatico, altrimenti qualsiasi sistema di segnalazione non ha quasi alcuna utilità funzionale e sostanziale.

Quest’ultimo dataset è quello più scaricato, quello che sembra più interessante per gli utenti del sito. Incuriosito dal numero di download l’ho scaricato ed ho provato a farci qualcosa, con l’obiettivo di testare concretamente l’efficacia di questa azione e di restituire anche qualcosa indietro.

Il dataset dei siti turistici visitabili della città di Palermo

Palermo è una città con un centro storico molto grande (in alcune classifiche è riportato come il più grande d’Europa). E’ quindi di elevato interesse turistico e ricca di siti visitabili. Pubblicare in Open Data questo dataset è un’ottima scelta, perché si presta potenzialmente ad uno degli scopi principali di questo tipo di azione: il riuso da parte di cittadini, professionisti e aziende. Una persona, infatti, potrebbe scaricare questi dati e farne ad esempio una app per smartphone, utile a chiunque voglia scoprire questa bella città. Realizzarla in più lingue, metterla in vendita in uno store dedicato, guadagnare il giusto e contribuire a rendere Palermo più fruibile.

Il dataset relativo è così descritto sul sito:

La tabella contiene i dati relativi ai siti turistici visitabili in città. Sono distinti il tipo sito, la denomianzione del sito, la descrizione, l’indirizzo, info, orario di accesso al sito, note relative all’orario di accesso al sito, l’eventuale necessità di biglietto di ingresso con i relativi costi ed esenzioni, contatto mail, sito web dedicato, note per eventuali visite guidate ove possibile, informazioni sull’accessibilità.

La descrizione, a parte un piccolo errore di battitura (“denomianzione” per “denominazione”), è chiara e abbastanza autoconsistente. Del dato originale però non sappiamo altro, salvo il suo formato (.csv) e il nome del responsabile (Dott. Eliana Calandra).
Sono presenti in realtà altre informazioni – come ad esempio la “Data di creazione” – ma non riguardano il dato originale, e lo descrivono soltanto in relazione alla sua pubblicazione nella sezione Open Data del sito del Comune.
L’assenza di informazioni fondamentali sul dataset e propedeutiche affinché il dato possa essere realmente usato e abbia un valore concreto, ne sminuisce fortemente il valore e la sua usabilità, vanificando, di fatto, lo scopo per il quale è stato pubblicato.
Ad esempio, uno di questi è l’indicazione della data di aggiornamento: quando è stato redatto questo archivio?
Un dataset turistico deve essere recente ed aggiornato per avere valore, infatti cambiano con una certa frequenza elementi informativi come: costi di eventuali biglietti ingresso, orari di apertura, numeri di telefono, ecc..
Altra informazione omessa nella pubblicazione del dataset è quella relativa alla scelta progettuale che c’è alle spalle dell’archivio. Contiene 100 siti. Viene da domandarsi: sono tutti quelli visitabili in questa città? Se non lo sono, che filtro è stato applicato? Sono 100 perché si è filtrato soltanto in base a “chiese e oratori” (59), “musei e gallerie d’arte” (26) e “ville e giardini” (15)? Perché ci sono siti di Bagheria e non di altri comuni?

Il dataset analizzato si presta alla rappresentazione cartografica, ma non contiene le coordinate dei vari siti contenuti. Tuttavia è presente l’indirizzo ed è su questo che ho eseguito un’operazione di geocoding.

Prima di farlo però, l’ho analizzato un po’ più nei dettagli. A seguire alcuni degli elementi riscontrati:

• l’anno di costruzione dei siti è inserito nel campo “Nome del sito”. In questo modo è un’informazione poco utilizzabile. Sarebbe preferibile inserirla in un campo dedicato (l’ho fatto). Che questo numero presente nel campo sia l’anno di costruzione è una mia deduzione, ma non posso esserne certo.
• ci sono due righe per la “Chiesa di S. Maria in Valverde (1633)”. L’unica differenza sembra l’indirizzo, ma tutti gli altri dati sembrano coincidenti.
• ci sono 8 strutture in cui non è inserito il numero di telefono. Per un dataset di questo tipo è una grave lacuna; basti pensare che mancano quelli dell’Orto Botanico e della Cappella Palatina.
• il campo “info” contiene essenzialmente i numeri di telefono, ma mescolati alle volte con elementi altrettanto utili come “Sito è visitabile solo in occasione di mostre e/o eventi” o “Chiusa per restauro”. Penso che sarebbe preferibile creare un campo “telefono”, distinto da un generico “info”.
• il campo “indirizzo email”, importantissimo a fini turistici, non è mai valorizzato. In realtà lo è una sola volta, nel caso della “Chiesa di S. Cristina La Vetere (1174)”, ma è stato scambiato con il valore contenuto nel campo “sito web” (l’ho modificato).
• gli URL dei siti web sono inseriti di solito con questa struttura ” www.nomesito.it“. Alcuni record però sono difformi (“http://www.nomesito.it” o ad esempio “web:  www.nomesito.it”). Li ho uniformati alla struttura  www.nomesito.it
• nel campo “descrizione del sito” è possibile leggere sia “chiesa” che “Chiesa”, “Cappella” e “cappella”; ho uniformato i nomi di categoria in minuscolo.
• solo la “Cattedrale” ha informazioni sull’accessibilità. Mi sembra un’informazione propedeutica per qualsiasi dataset di informazioni su siti turistici.
• sono presenti numerosi spazi doppi, ed alcuni caratteri di tabulazione, che non hanno ragione di essere presenti, e che disturbano la gran parte delle eleborazioni automatiche via software.
• il nome via corretto per “Corso Vittorio Emanuele” dovrebbe essere “Via Vittorio Emanuele”.

Fatta questa rapida analisi del dato, sono passato a fare il geocoding sfruttando le  API dedicate di Google. Queste consentono con una chiamata in HTTP, partendo da un indirizzo postale, di avere restituito (tra le altre cose) latitudine e longitudine dell’indirizzo. Per conoscere, ad esempio, quelle di “Via Terrasanta 82, Palermo” lancerò questo URL:

http://maps.googleapis.com/maps/api/geocode/xml?
address=Via%20Terrasanta%2082,%20Palermo&sensor=false

L’output in questo caso è in XML e tra le informazioni che mi vengono restituite ci sono proprio quelle che cerco, latitudine e longitudine:

<location>
<lat>38.1303072</lat>
<lng>13.3445130</lng>
</location>

Ma si tratta soltanto di uno strumento e come tale ha anche lui i suoi problemi. Due esempi tra tanti:

• non sono presenti nel database di Google tutti i numeri civici, come ad esempio “Piazza Casa Professa, 21″ o “Piazza S. Valverde, 3″. Il problema è risolvibile integrando gli strumenti di Google a quelli di Bing Maps, Pagine Gialle, OpenStreetMap, e lo sarà ancora di più quando il comune pubblicherà in Open Data il dataset del viario e dei numeri civici.
• in Google Maps si legge “Via Nasi Nunzio, 18, Palermo” e non “Via Nunzio Nasi, 18, Palermo”, e si inverte il classico ordine “Nome Cognome”

Il problema principale legato alla geocodifica è che però la metà dei siti sono associati ad indirizzi senza numero civico, e quindi non è possibile ricavarne la posizione automaticamente. Questa è una lacuna che non è del dato in quanto tale, ma un vero e proprio “vuoto toponomastico”: non esiste un numero civico per ogni ingresso ad un edificio di una città.
Il lavoro che ho fatto è quindi incompleto, perché per questa demo mi sono fermato a ciò che era possibile automatizzare.

L’analisi e la pulizia dei dati, così come il geocoding sugli indirizzi, li ho fatti con un bellissimo software open-source multipiattaforma, che nasce proprio per ripulire i dati e derivare nuove informazioni:OpenRefine (spero di scriverci un tutorial quanto prima).

Ricavate le coordinate dei siti, ho pensato subito di pubblicare i dati online, realizzando una piccola applicazione di webmapping a solo scopo dimostrativo, che mostrasse quanto fosse semplice realizzare un prodotto gradevole, utile, moderno, i cui costi fossero soltanto legati al tempo di sviluppo.
Ho utilizzato infatti soltanto software open-source. L’ho fatto per ragioni di personale comodità, in quanto sono quelli che utilizzo maggiormente, ma anche per la grande qualità e per le funzioni disponibili.

Da OpenRefine ho estratto un file .csv, che ho convertito in GeoJSON con l’utility ogr2ogr messa a disposizione dalla libreria GDAL. Il GeoJSON è un formato ormai “classico” nel mondo del web-mapping e nativamente supportato da Leaflet, la meravigliosa libreria usata per fare questa piccola applicazione di cartografia online.
E’ molto bella perché ben documentata, di semplice utilizzo, ricca di feature e (come dicevo anche prima) moderna. Due prove evidenti sono la leggibilità della  mappa prodotta su dispositivi mobili, e la possibilità (tramite plugin) di aggregare in cluster indicatori di posizione molto vicini. Nella mappa infatti tutte le volte che ad un certo livello di zoom gli indicatori sono troppo vicini, e quindi poco leggibili, vengono raggruppati in un simbolo circolare, con sovrimpresso un numero che indica da quanti elementi è formato; al click sul simbolo, si avvierà automaticamente lo zoom sulla mappa, e verranno mostrati tutti gli elementi che compongono il gruppo.

Prima di scegliere questo dataset e questo output, ho navigato un po’ nella sezione OpenData del sito del Comune, ho trovato limitante l’assenza sul sito di un motore di ricerca dedicato che mi consentisse, ad esempio, di filtrare soltanto i dati pubblicati in formato .shp (un classico formato cartografico). Ne ho costruito uno con Google Custom Search Engine (che il Comune usa per l’intero sito), con il quale posso risalire rapidamente ai soli dataset pubblicati in questo formato (basta inserire “shape” come parola chiave) o ai cinque in .csv (usate “csv” in questo caso).

Infine ho pubblicato tutto in un  minisito dedicato, realizzato con  Twitter Bootstrap, dove troverete:

• una pagina di introduzione;
• una pagina con un’anteprima della mappa;
• una pagina con la  mappa a schermo intero, molto leggibile anche da smartphone e tablet;
• l’elenco degli  strumenti principali che ho usato;
• l’elenco dei dati che ho utilizzato, sia gli originali, che quelli rielaborati;
• il motore di ricerca descritto sopra;
• dei doverosi ringraziamenti.

In conclusione

Mi rendo perfettamente conto che è facile fare critiche.
Ed è per questo che ho voluto concretamente indicare cosa ci si aspetta dalle Istituzioni quando queste dicono di “fare Open Data”. Per la stessa ragione ho voluto mettere in piedi un esempio di applicazione costruita a partire dai dati pubblicati dal Comune, una piccola cosa concreta.

L’operazione di trasparenza, innanzitutto, prende le sue mosse da una progettualità, che anch’essa deve essere correttamente descritta ed esplicitata: quali sono le finalità, quali sono le linee guida, quali sono le modalità operative, qual è il budget a disposizione, quali sono le evoluzioni e gli incrementi previsti, quali sono le modalità comunicative.
In secondo luogo, è necessario avere cura di rendere disponibili dati di qualità.
Il valore del dato aperto risiede nell’accuratezza dello stesso e nella sua ri-usabilità.
Non è solo un problema di trasparenza della P.A..
Non è solo una questione etica per cui è giusto che il lavoro della P.A. e le informazioni dalla stessa raccolte e detenute vengano poi restituite ai cittadini ed agli utenti che sono i contribuenti.
Non si tratta soltanto di correttezza metodologica e/o scientifica per cui ci si aspetta che l’elaborazione del dato avvenga secondo determinati criteri e standard elevati.

Dati di qualità, e solo questi, consentono di assolvere alla funzione per cui essi sono raccolti e pubblicati: è un problema economico, nel senso di  utilizzo delle risorse per soddisfare al meglio bisogni individuali e collettivi.
Un dato aggiornato ed accurato consente il suo utilizzo nei modi più svariati.
David Miller, Sindaco di Toronto, ebbe a dire: “una volta liberati i dati, non c’è limite a quello che le persone possono farci“.

Per questo ritengo che pubblicare un tweet come questo ” Trasparenza e innovazione. Palermo VII in Italia.”

Trasparenza e innovazione. Palermo VII in Italia. Presto una App ufficiale mail.ufficistampa.org/pipermail/comu…

— Comune di Palermo (@ComunePalermo) April 23, 2013

oltre che non corretto (perché si riferisce solo alla quantità di dati) non ha senso. Quantità senza qualità non serve a nulla.
Nello stesso tweet leggo con piacere di una App ufficiale. Peccato non averla agganciata ad una gara tra sviluppatori/progettisti, per la migliore applicazione costruita a partire da dati pubblicati (anche) in Open Data.

Qualche giorno addietro ho condiviso su twitter un articolo:  Open Data in Agriculture and Why It Matters. Una frase di questo articolo, che parla del valore degli Open Data nell’agricoltura, mi ha colpito: “ottimizzare il processo decisionale“.
Se l’Amministrazione apre e diffonde la propria conoscenza (i dati dalla stessa detenuti) otterrà un sicuro ritorno in termini di produttività e di partecipazione della cittadinanza, in termini di ricerca e di innovazione. Tutti elementi, questi che sospingono, specialmente in questi momenti di crisi, la crescita economica e sociale di una collettività.

Gli open data sono una opportunità per il Paese. Si tratta di crederci (la P.A. ci deve credere). Leggere in un recentissimo comunicato stampa che “Il nuovo Statuto del Comune si ispirerà ai principi della trasparenza e della partecipazione e su riconoscimento, tutela e valorizzazione dei beni comuni“, mi deve fare pensare che questa amministrazione ci vuole credere. Ma questo lo diranno i fatti.

Così come devo  supporre e voglio sperare che i dataset a disposizione del Comune non abbiano le stesse caratteristiche di quello descritto in questo post. Viceversa gli amministratori di questa città non avrebbero gli strumenti adeguati per gestirla bene.

Alla presentazione della strategia Open Data del Comune di Palermo è stato chiesto alla cittadinanza di contribuire all’apertura dei dati. Giusto!
A due mesi della detta presentazione vorrei, provocatoriamente, parafrasare (ribaltandola) la famosa frase di J.F.Kennedy: “non chiedetevi cosa possono fare i cittadini per l’apertura dei dati, chiedetevi cosa deve fare l’Amministrazione per produrre dati di qualità.“

L'articolo #OpenData #Palermo: alcune osservazioni dopo due mesi è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Tre i temi principali che, in questa prima fase, vorremmo trasformare in azione:

• Formazione – iniziative formative a medio, lungo termine riguardanti la formazione su specifiche questioni di fondo (metadati, INSPIRE, standard, soluzioni tecnologiche, ecc.).
• Informazione – iniziative di tipo divulgativo (filmati didattici e di promozione), così come webinar di taglio informativo su argomenti di approfondimento.
• Buone prassi – segnalazione e report di iniziative e progetti riguardanti geoportali e portali open data, standard, apertura e liberazione di dati (ma non solo) che possono essere prese a modello.

Pensiamo sia necessario il contributo di molti, sia in termini di contenuti che di modalità di azione. Per questa ragione abbiamo pensato di creare uno spazio in cui ognuno potrà proporre, condividere, commentare e valutare in modo costruttivo idee utili sul tema.

E’ stata aperta una community su ideascale (geodatiliberi.ideascale.com), non vi resta che aprire un account e cominciare a proporre e interagire con gli altri. Troverete le tre categorie di cui sopra nelle quali inserire le idee e proposte, in modo tale da rendere il tutto più organico. A supporto di questo ideario, è stata creata anche una mailing list.

Perché OpenGeoData non sia soltanto un obbligo normativo, una moda o un sfogo per il “geogeek“.

immagine realizzata a partire dalla foto di Diego Dalmaso

Insieme a :

• Un blog di Alternativa Geologica
• Kartoblog
• GeoSDI
• FreeGIS
• RNDT social
• GISInfrastrutture
• GEOforUS
• GeoWebLogIt
• OKFN Italia
• massimozotti.it
• GeoPortale Provicia di Trapani
• Geofunction
• Rivista GEOmedia
• Blog Planetek
• Cesare Gerbino GIS Blog
• Unless
• geometrisalernitani

L'articolo Raccogliamo le idee per i GeoDati liberi è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

• ho avuto la possibilità di avere un quadro di quello che avviene sul tema in Italia;
• ho incontrato persone che troppo spesso incrocio soltanto virtualmente (napo, Massimo Zotti, GimmiGIS, Antonio Rotundo, Giovanni Biallo, …) ;
• ho stretto la mano a Ernesto Belisario, Martin Koppenhoefer e Gianluca Vannuccini;
• ho preso una pausa contro il “logorio della vita moderna”, fatta anche di chiacchiere e birra con il presidente.

Cosa voglio di più? In realtà avrei proprio voluto incontrare un lucano, ma questa è un’altra storia ed è un po’ “up, close and personal”.

La nostra relazione aveva come obiettivo quello di proporre (ed in un certo senso anche quello di verificarne l’esigenza) un’azione per la crescita della consapevolezza del valore degli OpenGeoData, che contribuisca a fare in modo che non rimangano soltanto un obbligo di legge, una moda e uno sfogo per (geo)geek. Non conoscevo i contenuti delle presentazioni degli altri relatori, ma ascoltandoli ho compreso chiaramente che si trattava di un’esigenza condivisa da molti e sono tornato a Palermo “forte” di diversi riscontri.

Ieri pomeriggio però mi ha preso un po’ lo sconforto. Volevo raccogliere degli elementi, per costruire un elenco commentato di casi tipo di “pregio”, da usare come strumento divulgativo classico. Ho consultato alcuni siti web di importanti comuni del Nord e del Sud Italia, concentrandomi sulla sezione geografica dei dataset disponibili e due elementi mi sono saltati agli occhi.
Il primo è un errore, anzi come diceva la mia professoressa di Matematica “un orrore”, ma per fortuna molto poco diffuso: layer cartografici in formato .shp non accompagnati da file .prj. Non può bastare – come avviene – scrivere nella pagina di descrizione dello specifico dataset “Sistema di riferimento UTM ED50”. Fatto il download del dato (che contiene i soli .shp, .shx e .dbf) il virus ha iniziato già a diffondersi: io infatti magari passerò il file .zip ad un mio collega senza precisargli il sistema di coordinate letto nella pagina, ed in due passaggi ho compromesso in modo grave la qualità del dato.

Il secondo purtroppo è qualcosa di molto diffuso e ha radici che non riguardano gli OpenGeoData, ma che in questo contesto fanno tanto “male”. Ho aperto diversi dataset spaziali scaricabili in formato .shp, ne ho fatto il download e ho visualizzato in un client le tabelle associate. Mi sono trovato davanti nomi di campo di questo tipo: “AFFIDARE_A”, “TIPO_MANU1”,  “ARRE_GESTI” e anche il meraviglioso “GIANCARLO”. Il formato .dbf – con tutti i suoi limiti – ci mette il suo, ma pubblicare un dato, senza accompagnarlo con un file che ne descriva nel dettaglio il contenuto informativo, mi pare un “non senso” e mi fa pensare ad un paio di indimenticabili caffè bevuti in case in cui i barattoli di sale e zucchero non avevano etichette.

Il primo elemento è per fortuna poco diffuso e di soluzione banale, perché esistendo già uno standard per descrivere il sistema di coordinate di un file .shp, si possono implementare delle semplici procedure di controllo.

Il secondo è molto più complicato perché da anni tutti noi produciamo file .shp, ma senza porci il problema di descriverne il contenuto informativo e stavolta in un solo passaggio impoveriamo il valore del nostro dataset.

Andare verso le 5 stelle dei Linked Open Data e verso INSPIRE in qualche modo risolverebbe problemi di questo tipo, ma ad oggi la gran parte degli OpenGeoData vengono pubblicati principalmente in modalità più “semplici” e penso sia necessario trovare una “cura” prima possibile.

Che ne pensate?

Foto di jlib

L'articolo 2013, anno degli OpenGeoData? L’entusiasmo (mio) è calante è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Voglio invece presentarvi subito e in modo sintetico, un lavoro che abbiamo fatto alcune settimane fa, e che ci ha dato lo spunto per l’intervento presentato a Roma. Si tratta di un lavoro di sottotitolazione e traduzione in italiano di un video semplice, breve ed efficace che illustra cosa sia l’OGC. Un lavoro simile a quello fatto per Geospatial Revolution Project, ma in quel caso ci occupammo soltanto della traduzione. Stavolta invece, a partire da un file senza correlazione tra testi e tempo, abbiamo prima sottotitolato in lingua originale il video, e poi lo abbiamo tradotto. Tutto questo si deve anche ad un bel dialogo instaurato con l’OGC, che ringraziamo anche per i toni e i modi con cui si è rivolto a noi.

Farlo è stato ancora una volta molto divertente. Il risultato è visibile facendo prima click sull’immagine sottostante e selezionando poi “Italiano” tra i sottotitoli.

In ultimo un doveroso grazie anche a Antonio Falciano che è stato essenziale per realizzare il lavoro sul video.

L'articolo Cosa è l’OGC? (di ritorno dalla conferenza OpenGeoData) è 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.

• un’applicazione web: http://www.pcn.minambiente.it/wctsclient/
• un servizio WCTS: http://www.pcn.minambiente.it/GN/wps.php?lan=it

Per ulteriori approfondimenti circa le premesse e i dettagli tecnici, si consiglia la lettura di questo articolo sulla rivista Geomedia.

Benissimo! “Lasciamoci INSPIR(ar)E” dunque, parafrasando il titolo di un gran bel post di Pietro Blu Giandonato di qualche anno fa… E cosa avviene a livello regionale? In verità, esiste già qualche servizio analogo, tra cui:

• Regione Lombardia: http://www.cartografia.regione.lombardia.it/geoportale/ptk
• Regione Liguria: http://www.cartografia.regione.liguria.it/template4.asp?itemID=4005&level=2&label=Trasformazione%20coordinate
• Regione Sardegna: http://www.sardegnageoportale.it/strumenti/conversionecoordinate.html
• Regione Basilicata: http://rsdi.regione.basilicata.it/web/guest/servizio-wcts
• Regione Emilia-Romagna: http://geoportale.regione.emilia-romagna.it/it/services/servizi%20tecnici/servizio-di-conversione

Per curiosità, dopo aver letto un post nella lista GFOSS in cui erano segnalate delle inaspettate anomalie, ho deciso di impiegare qualche ritaglio di tempo libero per verificare la bontà del servizio WCTS della mia regione, la Basilicata, rispetto a quello appena reso disponibile dal GN. Nel seguito, non mi addentrerò nella descrizione qualitativa dei servizi (della serie …è più bello, è più brutto, è più veloce, mi chiede l’indirizzo email, ecc.), poiché esula completamente dai miei scopi.

In pratica, ho effettuato le seguenti operazioni:

• ho scaricato i confini amministrativi regionali dal sito dell’ISTAT, definiti in EPSG:23032, e li ho caricati in una vista di gvSIG 1.12, definita nello stesso sistema;
• ho poi selezionato solo la mia regione e applicato l’algoritmo di SEXTANTE “Adjust n points to polygon”, in modo tale da generare un set di 100 punti scelti in maniera casuale contenuti in Basilicata, utilizzando i parametri rappresentati in Figura 1 e ottenendo il risultato in Figura 2;

Figura 1 – Adjust n points to polygon

Figura 2 – Layer di punti casuali

• ho quindi trasformato il layer di punti precedentemente ottenuto, utilizzando sia l’applicazione web del Geoportale Nazionale che quella della Regione Basilicata, rispettivamente dal sistema EPSG:23032 (ereditato dal layer dei confini amministrativi ISTAT) verso EPSG:3004 e EPSG:32633, assumendo per buona ad occhi chiusi la conversione dovuta al passaggio di fuso/zona contenuta in maniera implicita in entrambe le trasformazioni, in quanto si tratta di un’operazione di coordinate che i software e le librerie GIS generalmente affrontano in maniera rigorosa e quindi fuori di discussione. Inoltre, ho trasformato – sempre utilizzando entrambi i servizi – il layer dei punti definito in EPSG:32633 ottenuto dal GN verso EPSG:3004. In definitiva, ho ottenuto tre coppie di layer, ognuna corrispondente ad ogni trasformazione possibile tra i tre sistemi citati e definita in un preciso sistema di destinazione. In Figura 3 sono rappresentate schematicamente le singole trasformazioni realizzate.

Figura 3 – Trasformazioni realizzate (Autore: Andrea Borruso)

• Il passo successivo è stato quello di definire e calcolare dei nuovi campi nelle tabelle associate ai layer ottenuti al punto precedente, contenenti le coordinate nei rispettivi sistemi di appartenenza (esistono diversi modi di farlo in gvSIG: con il “Calcolatore di campo”, con lo strumento “Aggiungi informazioni geometriche”, con “Add coordinates to points” di SEXTANTE …e tanti altri). Ho rinominato tali campi di coordinate in modo da poterli rapidamente associare al CRS di appartenenza, oltre che allo specifico servizio utilizzato. Ad esempio, X3004GN rappresenta la coordinata Est nel sistema EPSG:3004 trasformata dal Geoportale Nazionale, mentre X3004BAS è la corrispondente coordinata trasformata tramite il geoportale lucano.
• A questo punto, essendomi dimenticato di definire un campo identificativo da utilizzare come chiave esterna (in questo caso poco male, essendo i punti reciprocamente abbastanza distanti tra loro), ho eseguito il geoprocesso “Spatial join” per ogni coppia di layer definiti nello stesso CRS, selezionando l’opzione “Usa la geometria più prossima”, in alternativa al classico join tra tabelle. Il risultato di tale operazione è praticamente equivalente a quello del join, ad eccezione del fatto che gvSIG restituisce un campo DIST delle distanze tra le geometrie poste in relazione e, inoltre, il layer ottenuto è salvato su disco.
• Dulcis in fundo, ho calcolato le differenze tra coordinate omologhe al fine di verificare la bontà della trasformazione dei due servizi, assumendo quelle del GN come capisaldi in quanto dovrebbero essere quelle “ufficiali”.

I risultati di tutto l’ambaradan appena descritto, sperando di non avervi fin qui annoiato, sono riportati nella tabella seguente:

Tabella 1 – Statistiche degli scostamenti delle trasformazioni di coordinate del Geoportale della Basilicata (RSDI) rispetto a quelle del Geoportale Nazionale (GN)

A quanto pare, gli scostamenti tra le trasformazioni operate dai due servizi sono piuttosto importanti e, talvolta, addirittura superano il metro e mezzo! Se fossi un topografo, nel dubbio, mi guarderei bene dall’usare uno o l’altro servizio per trasformare i dati di un rilievo ad alta precisione. Ma anche un operatore GIS potrebbe imbattersi in qualche strana incongruenza topologica accostando dati provenienti da fonti (e quindi trasformazioni) diverse. Personalmente mi sarei aspettato differenze al più dell’ordine di un paio di decimetri per coordinata, ipotizzando dietro l’applicazione web del GN l’utilizzo di un unico grigliato comprendente tutta l’Italia a maglia più larga rispetto a quella dei singoli grigliati IGM, piuttosto che un numero elevato di griglie a passo fitto, decisamente più oneroso da gestire lato server.

Dalle statistiche di Tabella 1 chiaramente non si evince quale dei due servizi sia il meno accurato rispetto ai grigliati IGM. Eppure entrambi i servizi dichiarano di utilizzarli! Sarebbe utile, a mio avviso, ripetere lo stesso test con altri servizi WCTS regionali, magari utilizzando i grigliati come termine di confronto.

E’ lecito quindi chiedersi come mai la gestione informatica dei grigliati IGM all’interno di differenti applicazioni web porta a risultati diversi. E’ chiaro che occorrerebbe disporre di un riferimento ufficiale, unico ed inequivocabile.

A tal fine, per fugare ogni dubbio, sarebbe auspicabile il rilascio di un grigliato NTv2, formato ormai gestibile da molti desktop GIS, per ognuna delle possibili trasformazioni che interessano il nostro territorio nazionale. Non parlo necessariamente di quelli che utilizzano i topografi, ma anche solo una versione opportunamente semplificata che consenta di riunificare l’Italia intera, senza perdere eccessivamente in accuratezza. L’esempio lungimirante offerto da Francia, Spagna, Portogallo, Svizzera e Germania dovrà pur significare qualcosa nell’epoca di INSPIRE!

Aggiornamento del 09/02/2013

A seguito dell’aggiornamento ufficioso del servizio di trasformazione di coordinate del GN di cui si è avuta notizia ieri, i contenuti di questo post sono già obsoleti (forse, si tratta di un record per questo blog… ma siam contenti così! )
Ho quindi ricalcolato le medie degli scostamenti tra le trasformazioni dei due geoportali utilizzando lo stesso set di punti casuali. Il risultato è che le medie degli scostamenti sono stavolta sempre inferiori ai 3 cm. Restano tuttavia degli scostamenti max e min ancora consistenti (fino a 85 cm) per la coordinata Est. I valori estremi della coordinata Nord si aggirano invece attorno ai 20 cm, fatta eccezione per la trasformazione da EPSG:23032 a EPSG:32633, dove si superano i 30 cm.

Tabella 2 – Statistiche degli scostamenti delle trasformazioni di coordinate del Geoportale della Basilicata (RSDI) rispetto a quelle del Geoportale Nazionale (GN) – agg. 09/02/2013

Resta, a mio modesto avviso, la necessità di dover rendere congruenti e quindi interoperabili i vari servizi di trasformazione di coordinate regionali con quello nazionale, evitando così l’eventuale disorientamento degli utenti. Inoltre, eviterei l’ulteriore proliferazione di servizi WCTS regionali, a questo punto ridondanti, e favorirei il rilascio e la diffusione dei grigliati NTv2, standard de facto a livello internazionale, almeno relativamente alla componente planimetrica.

L'articolo Sistemi di trasformazione di coordinate e grigliati NTv2 è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Nel tempo queste mattonelle cartografiche sono aumentate a dismisura e ce le troviamo anche in tasca. Penso ai nostri smartphone e al fatto che la quasi totalità delle basi cartografiche delle applicazioni che installiamo in questi sono distribuite a tasselli.

E nel prossimo futuro la diffusione sarà ancora più pervasiva, in quanto passeranno dall’essere consultati quasi esclusivamente tramite servizi/server web, all’essere letti direttamente da un file residente sul nostro terminale. Un esempio per tutti è quello del GeoPackage, un formato standard che l’OGC sta definendo, in cui le basi raster potranno essere archiviate proprio a tasselli. Un po’ come rasterlite di Sandro Furieri, che credo sia in qualche modo lo scheletro portante di questo nuovo formato OGC.

I tasselli sono talmente tanti che ormai spesso trovo negli hard-disk, pen-drive USB, DVD (come sono vecchio!), schede SD, ecc. quelle strane cartelle a loro volta suddivise in decine e decine (nel caso migliore) di sottocartelle, tipiche della struttura di archiviazione su file system di basi dati tassellate e piramidate.

Proprio per questo ho pensato di scrivere un articolo su come accedere ad un archivio cartografico di questo tipo, che in qualche modo è il complementare ad un altro scritto nel lontanissimo 2008 e in cui viene illustrato come tassellare un’immagine.

Come accedere ad un archivio cartografico a tasselli e ricomporlo in un unica immagine georeferenziata?

In sé la cosa sembra ovvia, in quanto si tratta di formati file leggibili da qualsiasi terminale con qualsiasi sistema operativo: parliamo infatti nella stragrande maggioranza dei casi di .jpg e .png. Sfoglio le cartelle, faccio doppio click su una delle immagini e le visualizzo in un attimo. E dove è finita l’informazione geografica?

Se le apro infatti con un visualizzatore di immagini è normale che le uniche coordinate riconosciute siano i pixel, ma se provate ad aprire lo stesso tassello con una applicazione GIS, il risultato non cambia. L’informazione geografica infatti non è presente nemmeno in qualche tag nascosto internamente ai file e quindi non può essere letta. Per assurdo tutti i tasselli sembrano sovrapposti nello stesso punto della terra, ad una sola risoluzione.

L’arcano si risolve proprio nella lettura della struttura della cartella in cui sono archiviati e quindi nella conoscenza dell’indice utilizzato per generare tutti i pezzetti di mondo alle varie scale di ingrandimento. Data infatti una certa modalità di tassellamento, ogni punto della terra è associato ad una certa tessera di questo enorme mosaico, per un certo livello di zoom.

Ma sporchiamoci un po’ le mani. Nell’immagine accanto una cartella di output di un tassellamento, con le sue sottocartelle, che potete scaricare da qui. Se la si sfoglia un po’ e si provano ad aprire i singoli file che troviamo all’interno delle varie cartelle, è evidente che quello che varia per ogni tassello è l’ingrandimento e/o l’area della Terra rappresentata. Posizione e zoom, ovvero x, y e z.

In questo esempio, ed è facile verificarlo in modo empirico, il primo livello di sottocartelle è legato all’ingrandimento: dalla cartella “0″ con la risoluzione più bassa a quella “4″ con quella più alta. All’interno di queste invece le eventuali sottocartelle rappresentano spostamenti lungo l’asse x. Nella figura di sopra quindi le cartelle “NE2_50M_SR_W\1″ e “NE2_50M_SR_W\1\1″ contengono, per il livello di zoom “1″, porzioni di Terra affiancate. La variazione lungo l’asse y è invece resa, per ogni cartella, dal nome del file: il tassello “1.png” sta a Nord di quello “0.png”.

Nella figura sottostante ho schematizzato la cosa, per rendere ancora più leggibile e chiara questa struttura.

Conoscere tutto questo ovviamente non basta a posizionare queste immagini nello spazio, ma soltanto in modo relativo. Per fortuna però il tassellamento viene fatto secondo standard, magari diversi, ma definiti. Quindi se conosciamo (o riconosciamo) lo standard con cui sono state generate le nostre tessere, basterà essere in possesso di un client che sappia leggere questo standard e queste verranno posizionate correttamente nello spazio cartografico. Un po’ come quando accediamo ad un servizio WMS.

La cartella di esempio che sto usando per questo esercizio contiene al suo interno (per fortuna c’è quasi sempre qualcosa di simile) il seguente file .xml.

< ?xml version="1.0" encoding="utf-8"?>
<tilemap version="1.0.0" tilemapservice="http://tms.osgeo.org/1.0.0">
<title>NE2_50M_SR_W</title>
<abstract></abstract>
<srs>EPSG:900913</srs>
<boundingbox minx="-85.05112878000000" miny="-180.00000000000000" maxx="85.05112878000000" maxy="179.99871994141003"></boundingbox>
<origin x="-85.05112878000000" y="-180.00000000000000"></origin>
<tileformat width="256" height="256" mime-type="image/png" extension="png"></tileformat>
<tilesets profile="mercator">
<tileset href="0" units-per-pixel="156543.03390000000945" order="0"></tileset>
<tileset href="1" units-per-pixel="78271.51695000000473" order="1"></tileset>
<tileset href="2" units-per-pixel="39135.75847500000236" order="2"></tileset>
<tileset href="3" units-per-pixel="19567.87923750000118" order="3"></tileset>
<tileset href="4" units-per-pixel="9783.93961875000059" order="4"></tileset>
</tilesets>
</tilemap>

E’ un piccolo tesoro che ci dice quasi tutto della struttura a tasselli che stiamo analizzando:

• la specifica sul formato di tassellamento, ovvero il TMS 1.0 (Tile Map Service) di OSGeo;
• lo Spatial Reference System usato;
• il Bounding Box;
• l’origine del mosaico dei tasselli;
• formato e dimensioni dei tasselli;
• e la risoluzione per ogni livello di zoom.

Non ci resta che trovare un client compatibile con lo standard TMS e provare a leggere questa struttura dati. La scelta va ancora una volta verso il Victorinox delle librerie spaziali, ovvero GDAL/OGR. Sfruttando infatti i minidriver di GDAL, descritti in fondo nella pagina di accesso ai servizi WMS, è possibile accedere direttamente a dati esposti in TMS; sia come che su file system. Prima è però necessario definire un file di configurazione, come descritto nella documentazione di cui sopra e di cui si riporta a seguire un esempio, basato sui dati che sto usando per questo post.

<gdal_wms>
<service name="TMS">
<serverurl>
file://C:/tmp/NE2_50M_SR_W/${z}/${x}/${y}.png
</serverurl>
</service>
<imageformat>image/png</imageformat>
<datawindow>
<upperleftx>-20037508.34</upperleftx>
<upperlefty>20037508.34</upperlefty>
<lowerrightx>20037508.34</lowerrightx>
<lowerrighty>-20037508.34</lowerrighty>
<tilelevel>4</tilelevel>
<tilecountx>1</tilecountx>
<tilecounty>1</tilecounty>
</datawindow>
<projection>EPSG:900913</projection>
<blocksizex>256</blocksizex>
<blocksizey>256</blocksizey>
<bandscount>3</bandscount>
<maxconnections>10</maxconnections>
<cache></cache>
</gdal_wms>

Il file contiene, in modo differente, quasi le stesse informazioni descritte prime per il file .xml. Tra queste:

• il tipo di servizio - <service name>
• l’indirizzo per accedere ai dati - <serverurl>
• il formato immagine della sorgente dati - <imageformat>
• il Bounding Box - <upperleftx>, <upperlefty>, …
• il livello di Zoom con la risoluzione più alta, che ricavo proprio dal file.xml di sopra - <tilelevel>
• lo Spatial Reference System - <projection>
• la dimensione in pixel dei tasselli - <blocksizex>, <blocksizey>

Il valore del parametro ServerUrl – ovvero l’indirizzo della sorgente dati – è di solito quello di un servizio web con una forma di questo tipo: http://myserver.it/NE2_50M_SR_W/${z}/${x}/${y}.png.

Nel caso descritto i dati sono su un hard-disk di un PC e quindi, l’accesso non è in HTTP ma secondo lo schema URI di accesso a file: file://C:/tmp/NE2_50M_SR_W/${z}/${x}/${y}.png (in questo esempio la cartella dei dati è all’interno di “C:\tmp”).
Nell’URI è necessario indicare come è realizzata, in termini di struttura e nomi dei file, la mappatura di x, y e z. Nel caso in esame abbiamo visto che è resa come z/x/y.png, e cosi è stata riportata nel file di configurazione. Bisogna soltanto fare attenzione alla sintassi che prevede l’utilizzo di alcuni caratteri speciali.

Creato il file di configurazione e salvato con nome (ad esempio “input.txt”), non resta che provare a leggere i dati. Il primo passo, un po’ per fare debug è aprire la shell e digitare:

gdalinfo input.txt

Come risultato, se tutto è correttamente configurato, si otterrà:

Driver: WMS/OGC Web Map Service
Files: input.txt
Size is 4096, 4096
Coordinate System is:
PROJCS[\"Google Maps Global Mercator\",
    GEOGCS[\"WGS 84\",
        DATUM[\"WGS_1984\",
            SPHEROID[\"WGS 84\",6378137,298.257223563,
                AUTHORITY[\"EPSG\",\"7030\"]],
            AUTHORITY[\"EPSG\",\"6326\"]],
        PRIMEM[\"Greenwich\",0,
            AUTHORITY[\"EPSG\",\"8901\"]],
        UNIT[\"degree\",0.01745329251994328,
            AUTHORITY[\"EPSG\",\"9122\"]],
        AUTHORITY[\"EPSG\",\"4326\"]],
    PROJECTION[\"Mercator_2SP\"],
    PARAMETER[\"standard_parallel_1\",0],
    PARAMETER[\"latitude_of_origin\",0],
    PARAMETER[\"central_meridian\",0],
    PARAMETER[\"false_easting\",0],
    PARAMETER[\"false_northing\",0],
    UNIT[\"Meter\",1],
    EXTENSION[\"PROJ4\",\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs\"],
    AUTHORITY[\"EPSG\",\"900913\"]]
Origin = (-20037508.340000000000000,20037508.340000000000000)
Pixel Size = (9783.939619140624900,-9783.939619140624900)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-20037508.340,20037508.340) (180d 0' 0.00\"W, 85d 3' 4.06\"N)
Lower Left  (-20037508.340,-20037508.340) (180d 0' 0.00\"W, 85d 3' 4.06\"S)
Upper Right (20037508.340,20037508.340) (180d 0' 0.00\"E, 85d 3' 4.06\"N)
Lower Right (20037508.340,-20037508.340) (180d 0' 0.00\"E, 85d 3' 4.06\"S)
Center      (   0.0000000,   0.0000000) (  0d 0' 0.01\"E,  0d 0' 0.01\"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256

Siamo riusciti a leggere correttamente le informazioni sui nostri dati e non abbiamo avuto nessun errore. A questo punto il comando per la ricomposizione in un’unica immagine georeferenziata è la cosa più ovvia, è gdal_translate:

gdal_translate input.txt output.tif

L’output sarà un unico file geotiff, Mission Accomplished!

Questo ovviamente è un caso semplice, costruito in modo che sia replicabile e didatticamente valido. Nella pratica quotidiana è tutto un po’ più complicato, ma leggendo i riferimenti indicati nell’articolo, documentandosi un po’, sarà possibile replicare la cosa con i propri dati.
La carta di base da cui ho generato i tasselli (che poi ho ricomposto) è la bella “Natural Earth II with Shaded Relief and Water“. E’ rilasciata sotto pubblico dominio e scaricabile da qui.

Con i minidriver di GDAL/OGR si possono fare tante altre cose, come accedere e quindi (volendo) scaricare, i tasselli di Bing Maps e Google Maps, facendo però la giusta attenzione ai termini legali imposti. Inoltre il file di testo di input creato sopra, può essere trascinato in drag & drop su Quantum GIS e visualizzato pochi secondi dopo. Questo sempre grazie all’esistenza degli standard e di GDAL/OGR.

Questo articolo diverrà magari presto “superato” proprio perché l’invasione dei tasselli sarà probabilmente peggiore di un attacco zombie, e saranno pertanto sviluppate modalità di accesso, procedure e interfacce ancora più semplici e trasparenti. Il fatto di poter accedere al basso livello descritto in questo articolo, offre comunque una potenza e una libertà di impieghi che difficilmente si potrà ottenere tramite strumenti di livello più alto.

In ultimo ringrazio Lorenzo Perone che mi ha dato gli stimoli per mettere in linea questi pensieri e questo processo.

L'articolo O che bel tassello marcondirondirondello … è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Il tema della Conferenza è “The Green Renaissance”, che tradotto in “Il Rinascimento Verde” francamente lascia un po’ perplessi. Il comitato organizzatore si è comunque ispirato proprio al movimento rinascimentale, che ha profondamente influenzato la vita intellettuale europea, facendo sentire la sua influenza nell’arte, nella letteratura, nella politica, la scienza, la religione. Analogamente la Direttiva INSPIRE vuole influenzare il modo in cui le informazioni per la gestione del nostro pianeta possono essere condivise e fruite.

L’obiettivo della Conferenza INSPIRE del 2013 è quello di fare un bilancio di questo progresso, scambiando opinioni ed esperienze e su come INSPIRE sta affrontando le sfide passate e le esigenze emergenti, per individuare nuove opportunità e riflettere collettivamente su come potrà evolvere ulteriormente per massimizzare i benefici per la società.

Call per poster e contributi

La call invita a proporre poster e contributi nell’ambito dei tre “pilastri” che il comitato ha individuato, ovvero “Showcase on Environment”, “Capacities” e “Networking”, ciascuno dei quali a sua volta comprende ulteriori topic:

• Showcase on Environment
  • Transport
  • Natural disasters
  • Environmental Protection and Historical Landscape
  • Forestry
  • Environmental impact assessment
  • Integrated spatial assessments
  • Population and eco-systems
  • Land Monitoring
• Capacities
  • Earth Observation (Copenicus [GMES], “GEOSS”..)
  • Lessons learnt and best practice
  • Costs and Benefits of implementing INSPIRE
  • Green economy
  • Public and Private Sector partnerships
  • Technologies required to deliver INSPIRE
  • Multi-disciplinary e-infrastructures
  • Cloud computing
  • Sensors and Sensor web
  • Citizen science/crowd sourcing
  • Linked data and semantic web
  • Capacity Building
• Networking
  • EU Enlargement and Integration
  • EU Location Framework
  • EU Committee of the Regions
  • UN GGIM
  • National and regional initiatives
  • Cross thematic networking
  • eGovernment
  • Open data
  • Greening the information society

E’ inoltre possibile presentare contributi per l’edizione speciale del Internationa Journal of Spatial Data Infrastructure Research (IJSDIR), il termine ultimo per la presentazione del paper completo è il 31 maggio 2013.

Call per workshop

I workshop pre-conferenza si svolgeranno il 23 e 24 giugno, ogni laboratorio o tutorial può essere proposto per una singola sessione di 90 minuti. Il tipico partecipante alla conferenza si registra a massimo quattro workshop e tutorial da 90 minuti durante una singola giornata di seminario. Per tutti i partecipanti alla conferenza, workshop e i tutorial saranno aperti senza alcun costo aggiuntivo, mentre è prevista una tariffa giornaliera per coloro che vorranno frequentare solo i workshop. Chi è interessato a presentare una proposta di workshop o tutorial trova indicazioni specifiche sul sito web della Conferenza.

La deadline per presentare sia paper che workshop è il 1 marzo 2013, mentre per i poster il 29 marzo 2013.

Ultime novità riguardo le specifiche tecniche

Il comitato ci ricorda inoltre che il team del JRC sulle specifiche tecniche e i Thematic Working Group (TWG) stanno lavorando duro per finalizzare la versione 3.0rc3 (release candidate 3) delle specifiche dati dei temi compresi negli Allegati II e III della direttiva INSPIRE.

Questa versione sarà consistente con le bozze di emendamenti alle Implementing Rules per l’interoperabilità dei dataset spaziali e dei servizi attualmente in via di traduzione. I modelli dati corrispondenti e gli schemi xml sono stati già pubblicati (link) mentre le linee guida verranno rilasciate l’anno prossimo, man mano che saranno disponibili. Sarà utile tenere sotto controllo il sito web dedicato agli ultimi documenti (link).

La comunicazione

Noi di TANTO siamo particolarmente attenti agli aspetti della comunicazione che riguardano gli eventi della geomatica, e teniamo a sottolineare che l’hashtag lanciato da @INSPIRE_EU (l’account Twitter ufficiale di INSPIRE) è #inspireeu2013. Esiste anche un account INSPIRE su Storify, che ha raccolto un po’ di tweet e altro materiale riguardante la Conferenza 2012 tenutasi a Istanbul, date un’occhiata qui. Speriamo di poter contribuire attivamente anche noi il prossimo giugno a Firenze.

L'articolo La prima call della Conferenza INSPIRE 2013, che si terrà a Firenze è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

L'articolo Un nostro nuovo lettore! è apparso originariamente su TANTO. Rispettane le condizioni di licenza.