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.

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.

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.

• map tiles personalizzate
• mappe vettoriali
• migliorie agli strumenti OpenStreetMap
• nuovi tag per la creazione di moduli più complessi e utili
• migliorie nella gestione dei bookmark con avvisi di prossimità agli stessi
• nuove feature di import e export
• esposizione di semplici API che consentono la gestione dei progetti sul web

Per tutti i dettagli vi rimando al post di Andrea ed al wiki del progetto.

L'articolo Rilasciato Geopaparazzi 3 è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Era un bel po’ che aspettavo questa versione, perché è piena di funzionalità che in diversi stavamo aspettando. Vediamone alcune.

1) Supporto Openstreetmap

Questa è molto probabilmente la funzionalità più importante di questa versione. Ora siamo in grado di creare punti di interesse di tipo OSM (Openstreetmap) e sincronizzarli con un account OSM online.

Il primo passo consiste nell’attivazione della funzionalità nelle impostazioni:

Una volta attivo, se viene riavviato geopaparazzi, all’utente verrà chiesto se vuole scaricare le definizioni dei tag OSM. Queste rappresentano la libreria di simboli e descrizioni del tag OSM utilizzati per le varie tipologie di punti.

La vista mappa  mostrerà una piccola icona OSM sull sua destra. Se trascinata, l’applicazione mostra le categorie OSM disponibili:

Se si seleziona una delle categorie, vengono presentati i tag di tale categoria:

Selezionando uno specifico tag, all’utente si apre la sceda di compilazione delle proprietà del tag.

Dalla vista delle categorie è possibile sincronizzare tutti i punti di tipo OSM con il proprio account OSM online. All’utente verrà chiesto di inserire una descrizione per il set di modifiche che sta caricando:

Se nei settaggi utente e password sono state inserite nel modo giusto, geopaparazzi si connetterà a un servizio WPS scritto e reso diponibile da Luca Delucchi. Il WPS caricherà i punti sull’account OSM definito nei settaggi. Ringraziamo Luca, che ha dato grande supporto nel capire le tecnicità in gioco sul lato OSM. Inoltre è stato lui a scrivere il servizio WPS e renderlo disponibile a tutti gli utenti di geopaparazzi e infine ha creato tutte le icone e definizioni dei tag OSM.

2) supporto OGC GeoSMS

Questa versione di geopaparazzi supporta le specifiche OGC GeoSMS. La funzionalità è attiva sia in uscita che per GeoSMS entranti.

Le impostazioni SMS permettono di attivare  ”enable sms catcher”, che gestisce i GeoSMS entranti, mentre l’impostazione del “panic number” verrà usato per spedire messaggi nel formato GeoSMS.

Vediamo prima la spedizione dei GeoSMS. Geopaparazzi nella parte bassa della schermata principale ha una “panic bar”. Da li un utente può spedire un messaggio di richiesta di aiuto. Tale pulsante spedisce un messaggio contenente la posizione assieme ad una richiesta di aiuto secondo le specifiche OGC GeoSMS. Vi è anche un secondo pulsante che può essere utilizzato per spedire messaggi personalizzati. All’utente verrà proposto di inserire un testo da aggiungere al GeoSMS.

Cosa succede quando al telefono arriva un messaggio nel formato GeoSMS? Se la funzionalità è stata attivata nelle impostazioni, geopaparazzi elaborerà il messaggio entrante riconoscendone l’eventuale formato GeoSMS. Notificherà quindi all’utente l’arrivo di tale messaggio:

Dalla notifica sarà poi possibile aprire il GeoSMS con una delle applicazioni in grado di gestire l’infomazione ivi contenuta.

Quindi, selezionando al notifica:

Aprendo il messaggio con una delle applicazioni disponibili mostra che stavamo preparando alcuni screenshot per una presentazione al meeting italiano di utenti GRASS e GFOSS di Trieste:

3) realtà aumentata con mixare

In questa versione abbiamo aggiunto la possibilità di visualizzare i punti di interesse contenuti nella attuale vista di geopaparazzi in mixare. Questa funzionalità è stata descritta in passato in questo articolo.

Il punto di ingresso per la funzionalità è il menu principale della vista mappa:

4) creazione di un progetto nuovo

La creazione di un nuovo progetto ha sempre seguito un workflow poco naturale. Finalmente ora funziona come dovrebbe: all’utente viene chiesto un nome per il nuovo progetto, geopaparazzi crea tale progetto e lo carica.

5) i favoriti

Una cosa che a nostro avviso è sempre mancata, è un modo semplice e veloce per aggiungere dei punti favoriti. Abbiamo quindi aggiunto la possibilità di caricare i punti definiti in un file bookmarks.csv che dovrà essere copiato nella cartella di progetto (di solito geopaprazzi). Se il file è presente e se contiene i punti nella forma

Hotel Trieste, 45.642043,13.780791

Grassday Trieste,45.65844,13.79320

allora tali punti verranno caricati come favoriti.

Questa novità ha avuto come risultato già in fase di testing che ci si trovasse con un gran numero di favoriti e quindi con la necessità di poterli in qualche modo filtrare. E’ stata quindi aggiunto un campo di testo per semplificare la ricerca dei favoriti. Il testo ivi inserito verrà utilizzato per filtrare la lista di favoriti:

6) centra sul gps

Dopo aver rischiato una guida pericolosa per il solo motivo di spostare la mappa per tenere la posizione attuale al centro dello schermo, abbiamo aggiunto la funzionalità di centratura automatica della posizione gps. E’ possibile attivare tale funzionalità nelle impostazioni del gps:

7) grafici dei percorsi migliorati e zoom a selezione

Per ricordare questa funzionalità, ne avevamo già parlato qui.

8) osmdroid non disintegra più le mappe

Alcuni sviluppatori del progetto osmdroid (il motore che geopaparazzi usa per la visualizzazione delle mappe) hanno finalmente risolto il baco per il quale in particolari condizioni di mancanza di memoria, venivano cancellate tutte le mappe dal disco. Questo è stato uno dei bachi peggiori, visto che a diversi utenti era successo di scaricarsi le mappe per un rilievo su una zona e di trovarsi poi in montagna, offline e senza una mappa a disposizione.  Il problema è stato finalmente risolto!!

9) la possibilità di usare la posizione calcolata dalla rete

Ci è stato chiesto diverse volte di attivare la possibilità di sfruttare la rete per la definizione della posizione. Anche se tale posizione può risultare un po’ fuorviante , abbiamo deciso di aggiungere tale funzionalità, che può essere attivata nelle impostazioni del gps. Non è possibile aggiungere note da gps in questa modalità, visto che la posizione può essere sbagliata anche di diverse centinaia di metri. E’ comunque possibile vedere la propria posizione nella vista mappa e inserire note basandosi sulla mappa.

Questa versione nasconde un cambiamento molto importante dal punto di vista tecnico. Il progetto geopaparazzi è stato diviso in due per meglio supportare la riusabilità dei componenti. Molte delle funzionalità sono state messe in una libreria separata. Questo progetto può essere utilizzato per costruire in modo veloce semplici applicazioni.

Abbiamo deciso di rilasciare questa versione, perchè gli srtumenti OSM hanno bisogno di testing e anche la questione della libreria potrebbe avere bisogno di altro testing. Anche la documentazione avrà bisogno di un’aggiornamento. Come al solito ogni aiuto è ben accetto!

Installatevi l’applicazione dal market o scaricatela dalla area di download del progetto. Giocateci, testatela, mandateci commenti e bachi. Se avete domande, venite a trovarci nella mailinglist.

Ma sopratutto, godetevela!

[For an English version of this article, click here]

L'articolo Rilasciato Geopaparazzi 2.6.0 – OSM, Mixare e GeoSMS è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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

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

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

Planet GIS Italia 0.4

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

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

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

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

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

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

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

Come funziona Planet GIS Italia

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

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

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

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

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

“Opendata, donazioni, Baviera: conti e racconti”

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

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

• latitude : 48.9172
• longitude : 11.408

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

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

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

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

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

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

Sui feed

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

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

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

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

Sorpresa e serendipità

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

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

Buon anno a tutti!

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

The time was up to try to develop something on Android. In the past I had tried to develop applications on Zaurus, on Dell Axim, on some Nokia smartphone, but the results had been disappointing every time. There had to be something easier, where one could throw his ideas and make simple applications out of it… in one weekend.

The nerdy Sunday, wakeup call at 6, checking emails with coffe’ and cookies, seemed to be inspiring. A couple of days before an email had arrived about a new book, available in “review-reading” mode as pdf version: Unlocking Android, a developer’s guide by Ableson et alter. I decided to give it a possibility.

Well, I found the book so easy to read through, that I gave the first application a try. I really wanted to create a lightweight application that would help out in field surveys and would have those features, that the tablet pc field mapping application didn’t have. Above all the possibility to record the orientation of the pictures taken during the survey, so that they would show the direction of the snapshot when imported on a map. And I really liked the idea of having a mapping device always in my pocket. The motto has always been: “Gather as much information as you can. Always. The GIS will then help you to sort it out.”

That Sunday experiment went way better than I had ever hoped, by the evening I had great satisfaction with my simple, new and most of all GPS logging application. It was already able to take text notes and track lines. I got really excited about the possibilities to create a small version of BeeGIS… well, at that point I knew the time was up for Geopaparazzi.

From that moment on things went quite smooth. We started developing a simple OpenStreetMap based view, we created an import tool for Geopaparazzi in BeeGIS. We were using it in our daily job, and that was simply awesome. As we usually do at HydroloGIS we open sourced the application and published it on the market, in the hope that people would buy it and through that act support our other open source projects: JGrasstools, JGrass, BeeGIS and uDig.

The first Geopaparazzi

The thing we were most proud of, was that it would handle shooting direction:

The compass tracks the picture shooting direction, when the user keeps the phone in "taking picture" mode.

which, once imported into BeeGIS, would result in geonotes containing the picture and showing through a small arrow the direction in which the photo had been taken:

Geopaparazzi survey data imported into BeeGIS. The small arrows show the direction of the snapshot, the note itself contains the image.

As time passes by and as open source software works, one starts to exploit components other teams are specialized in.

So at some point Geopaparazzi decided to remove the compass view to present the much more user friendly dashboard. The android system makes it very easy to call views from other applications. geopaparazzi therefore chose to present a compass button that calls the compass view from the Status GPS project, which is freely available in the market.

The Status GPS compass view

At that point Geopaparazzi 2 was released, which brought a new, more userfriendly dashboard view:

The main view of Geopaparazzi 2

From the beginning Geopaparazzi only wanted to deal with data collection, which is why with the time the possibilities to describe the data to collect were enhanced. The new form based tags were introduces, through which it is possible to describe the data structure as forms that appear as tag buttons:

The form file description is loaded as a set of buttons that call the actual form

Once the button is pushed, the form is generated from a user created description:

A form, generated on the fly from a user defined text

Geopaparazzi 2 also brought the integration with the osmdroid project, a project that supplies a map view that caches OSM map tiles that can be accessed also in offline mode. This gave the possibility to enhance a bit the usability of the map view, also adding the bookmarks facility:

The osmdroid based map view, with Geopaparazzi's measure tool, bookmarks and notes tools

That more or less brings us to where we are now. Some interest has grown around Geopaparazzi and that makes us very happy.

The  Osaka Water General Service together with the Osaka University has adapted it to use it for the collection of information about water-supply infrastructure to promote post-disaster recovery for water supply under the guidance of Venkatesh Raghavan.

The Japanese localized Geopaparazzi adaption used in the Disaster Management Information System of the city of Osaka

We worked on a customized version of Geopaparazzi to keep waste management information uptodate. Through the trashmapper it is possible to sample and update information out in the field and then syncronize the data with a central database/webgis.

Since in this project the new generation tablets are being used, we got to tweak it for better user experience on tablet screens:

The TrashMapper application that helps collecting data about waste management

Arrived to that point, it was about time to move to the next level. Geopaparazzi has always been a free and open source application. It was sold in the android market but the code has always been accessible. What we want to achieve now that it is a stable product, is to attract some developers to cooperate on the project and enhance its functionalities. That is why from today on Geopaparazzi can be found in the market for free. From today on it is not only free as in speech, but also as in beer.

A few final considerations: the new generation tablets are more or less like pcs and maybe the idea to avoid too much mapping capabilities in Geopaparazzi might be a decision that it is time to review. Maybe instead it is time Geopaparazzi starts to slowly take over the job of old and heavy BeeGIS, with new data and connectivity functionalties and mapping capabilities. The doors are open, even if the main paradigma has to be kept strickt in mind: the tools needs to stay as simple and usable as possible. If you are interested to contribute, feel free to stop by at our mailinglist and have a chat with us. If you want to try it out, simply access the market and search for geopaparazzi.

L'articolo Geopaparazzi, history of a digital mapping kid è apparso originariamente su TANTO. Rispettane le condizioni di licenza.