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

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

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

Cosa è GTFS, ready, set, go

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

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

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

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

Come funziona

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

Requisiti

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

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

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

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

Lo script sfrutta queste applicazioni:

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

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

Usare lo script

Questa la modalità attuale di utilizzo:

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

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

Alcune note

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

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

Gli output

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

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

Perché

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

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

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

URL (che mi sono stati) utili

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

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

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

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

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

Contribuire

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

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

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

Le API e la “vita” dei dati

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

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

Qualche esempio di query:

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

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

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

Open Data Day

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

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

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

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

Ne riparlerò in un altro post.

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

Buona lettura!

P.S. molto interessante questo recente articolo – Riviste open access in Italia: stato dell’arte - ovviamente in open access

City, Territory and Architecture Editor-in-Chief: Giovanni Maciocco Society affiliation: Università degli Studi Sassari, Italy With its focus on the pluralism of positions and project perspectives regarding the city, territory and architecture, this journal aims to open up an interdisciplinary debate on the relational nature of projects for spaces where people settle and interrelate.

Future Cities and Environment Editor-in-Chief: Saffa Riffat Society affiliation: World Society of Sustainable Energy Technologies Considering research in the areas of transport, urban planning, architecture and design, and energy and infrastructure, Future Cities and Environment publishes fundamental and applied research, critical reviews and case studies. This includes experimental development, demonstration and computer modelling.

International Journal of Disaster Risk Science Indexed by Thomson Reuters Editor-in-Chief: Yanhua Liu and Roger Kasperson International Journal of Disaster Risk Science publishes high-quality research articles addressing theoretical and methodological issues in disaster science, emergency response technology, disaster risk management, and large-scale disaster risk governance.

L'articolo Segnalazione: riviste in open access sui Sistemi Informativi Geografici è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Introduzione

Tra gli strumenti esposti da Google Drive c’è Sheet, un foglio elettronico online ricco di funzioni, molto usato per le professioni e gli utilizzi più svariati.

I fogli creati fungono spesso da “contenitori” di dati, che fanno da sorgente a grafici, mappe, infografiche e applicazioni di svariata natura

L’accesso a Sheet si può eseguire tramite le API ufficiali di interrogazione. Nella documentazione ufficiale è indicato come generare un output, come generarne uno filtrato, come impostare i formati di output, come usarlo come un database relazionale su cui fare delle query SQL con aggregazione, calcoli, ecc.. Sul web, oltre alla guida dedicata, numerosi tutorial ed esempi.

Si tratta di operazioni semplici, con possibilità di uso molto ricche, per uno strumento che è comunque “per tutti“. Nella mia esperienza da formatore ho riscontrato però che per alcuni, la costruzione di una query non è di immediato apprendimento.
Questo post nasce proprio allo scopo di presentare uno strumento che consente di superare questi ostacoli: il buon vecchio Guardian Datastore Explorer di Tony Hirst.

Lo strumento

Il Guardian Datastore Explorer è un vecchietto arzillo: fa la sua prima apparizione nel lontanissimo 2009, un’altra era (non c’era ad esempio Instagram).
Sono due le caratteristiche principali che lo rendono molto interessante:

• consente facilmente di costruire in modo guidato un’interrogazione su uno Sheet di GDrive;
• è molto didattico. Utilizzandolo si impara ad usare il linguaggio di query e dopo poco tempo si impareranno a scrivere stringhe di interrogazione in autonomia con un semplice editor di testo.

E’ uno strumento web ed il suo URL è http://ouseful.open.ac.uk/datastore/gspreadsheetdb4.php.

Come si usa

Predisposizione del foglio Google Drive Sheet

E’ propedeutico avere un account su Google Drive. E poi è necessario avere un foglio elettronico con cui testare il Guardian Datastore Explorer: per le spiegazioni successive verrà utilizzato questo, con i musei del territorio comunale fiorentino.

Si tratta di dati aperti presenti sul portate dati.gov.it. Lo sottolineo perché un’altra cosa abilitata dagli open data è la didattica.

La prima cosa da fare con il foglio elettronico, è crearne una copia:

Fatta la “vostra” copia, è necessario impostarne la condivisione (tasto “Condividi” o “Share” in alto a destra), e fare in modo che (1) chiunque abbia l’URL del foglio, (2) possa visualizzarlo.

Poi si dovrà pubblicare sul web:

In questo video la sequenza della procedura sopra descritta:

La condivisione e la pubblicazione sul web sono necessarie perché il Guardian Datastore Explorer è utilizzabile soltanto con fogli pubblicamente accessibili.

Costruzione della query sul del foglio elettronico

La prima cosa da fare è ricavare il codice identificativo del foglio. Si trova all’interno dell’URL dello sheet ed è facilmente indetificabile.
Ad esempio nell’URL sottostante l’ID del foglio è quello in grassetto:

http://docs.google.com/spreadsheets/d/1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg/edit#gid=108845820

Quindi in questo caso è “1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg“.

Poi c’è aprire la pagina web del Guardian Datastore Explorer e (1) inserire l’ID del foglio e (2) fare click su “Preview table headings”. In questo modo l’interrogazione è stata attivata e come risultato vengono visualizzate le (3) intestazione delle colonne del foglio.

Subito dopo si può andare a pescare dati (“Go Fish” scrive l’autore) e iniziare a imparare come usare questo linguaggio di interrogazione, tramite la tabella di esempi riportata sul sito. Leggendola si vede che a tutti gli effetti si tratta un classico SQL (Structured Query Language). Qualche esempio:

Nella pagina trovate molti altri esempi.

Un’interrogazione che si potrebbe fare sul foglio dei musei di Firenze potrebbe essere quella per cui applichiamo questi filtri:

• Soltanto le colonne A, B, E, F, G, H, I e K;
• i soli musei a Est della “Cappella Brancacci”;
• solo quelli Statali;
• solo quelli che hanno un numero di telefono associato;
• ordinati da Nord verso Sud.

Prima di costruirla, un breve video che illustra una prima query più semplice, in modo da prendere confidenza con lo strumento: le sole colonne “latitude” e “longitude”, dove la “latitude” è maggiore di 43.77 e tutto ordinato per longitudine crescente.

Fatta la query, poco sopra i risultati di output, tre righe di testo molto interessanti:

La prima è proprio la query che abbiamo costruito, secondo il linguaggio delle API di Google Drive:

select%20A%2CB where B%20%3E%2043.77 order by A asc 

Nella stringa ci sono dei caratteri che ne rendono poco “leggibili” alcune parti: select A,B where B > 43.77 order by A asc si comprende meglio. In realtà la prima è il risultato dell’encoding dei caratteri della seconda. Questa è una procedura necessaria perché l’interrogazione viene lanciata tramite un URL, e in questo alcuni caratteri non sono consentiti. Nel nostro caso lo spazio deve essere codificato in “%20″, la “,” in “%2C”, il “<” in “%3E”.

La seconda contiene due hyperlink, a due dei formati di output possibili di una query fatta su Google Drive Sheet: l’HTML e il CSV. Il secondo è forse il formato più comodo per chi dovrà utilizzare i risultati di un’interrogazione per creare grafici, mappe e infografiche.

Questo ad esempio l’hyperlink per l’output in CSV:

http://spreadsheets.google.com/tq?tqx=out:csv&tq=select%20A%2CB%20where%20B%20%3E%2043.77%20order%20by%20A%20asc&key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg

Se lo separiamo in blocchi, si evidenziano elementi interessanti:

• tqx=out:csvserve per impostare il formato di output;
• tq=select%20A%2CB%20where%20B%20%3E%2043.77%20order%20by%20A%20asc per dichiarare la query;
• key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg per dichiarare l’ID del foglio.

La terza riga un segnalibro che consente di aprire il Guardian Data Explorer con e fargli lanciare la query appena eseguita. E’ un modo per salvare l’interrogazione costruita.

Adesso siamo in grado di costruire la query indicata a inizio paragrafo:

• Soltanto le colonne A, B, E, F, G, H, I e K -> select A,B,E,F,G,H,I,K
• i soli musei a Est della “Cappella Brancacci” -> where B > 11.2438292167895
• solo quelli Statali -> AND I matches 'Statale'
• solo quelli che hanno un numero di telefono associato -> AND H !=""
• ordinati da Nord verso Sud -> order by A desc

select A,B,E,F,G,H,I,K where B > 11.2438292167895 AND I matches 'Statale' AND H !=\"\" order by B desc 

Per potere usare questa query è necessario eseguire la codifica dei caratteri in modo che possa essere inserita in un URL. Il risultato (mille strumenti online per farlo, uno è questo) dell’endoding è:

select%20A%2CB%2CE%2CF%2CG%2CH%2CI%2CK%20where%20B%20%3E%2011.2438292167895%20AND%20I%20matches%20%27Statale%27%20AND%20H%20!%3D%22%22%20order%20by%20B%20desc 

E’ possibile usare allora questa stringa per creare l’URL che esegue l’interrogazione di sopra e che produce come un risultato un file CSV:

http://spreadsheets.google.com/tq?tqx=out:csv&tq=select%20A%2CB%2CE%2CF%2CG%2CH%2CI%2CK%20where%20B%20%3E%2011.2438292167895%20AND%20I%20matches%20%27Statale%27%20AND%20H%20!%3D%22%22%20order%20by%20B%20desc&key=1nS167pnytroD9SQWi0BUa_eFaeCwuWOk1_0GvsBFmsg

Il file scaricato sarà apribile con qualsiasi editor di testo, e qualsiasi foglio elettronico.

Usare l’output di una query per costruire una mappa online

Come già scritto sopra, il risultato di una di queste query può essere usata per visualizzare i dati in differenti modi. Uno è una mappa online (deformazione professionale).

Il dataset di esempio si presta, perché contiene la latitudine e la longitudine di ogni museo. Uno strumento free e open-source molto comodo per generare mappe da output di questo tipo è uMap. Tra i formati di input supportati proprio il CSV; l’unico requisito è che nel file CSV siano presenti le colonne denominate “latitude” e “longitude“.

La cosa interessante è che la mappa online sarà live e ogni aggiornamento fatto nel foglio elettronico, produrrà un aggiornamento della mappa. Questo avviene perché tutte le volte che verrà visualizzata, verrà lanciata una nuova query.

Nel video sottostante è illustrato come creare una mappa online live a partire proprio dall’URL soprastante, che produce in output un CSV.

Considerazioni finali

Il Guardian Datastore Explorer non è un query builder particolarmente potente ed elegante, ma è sicuramente uno strumento che rende semplice l’avvicinamento al Query Language di Google Drive Sheet.

Sopratutto fa comprendere che si tratta di un linguaggio semplice, e dopo poco tempo anche i novizi scriveranno le query “a mano” senza più usarlo. Bastano concetti di base di SQL, sapere fare l’encoding dei caratteri e leggersi la documentazione

L'articolo Guardian Datastore Explorer: per costruire query su fogli elettronici Google Drive è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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

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

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

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

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

Avere l’elenco di tutti i record del server

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

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

Tutti i record all’interno di una determinata area

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ma ci sono diverse altre caratteristiche interessanti rese disponibili da queste tecnologie e che molto spesso ignoriamo, la cui conoscenza ci consente di accedere ad un numero molto più ampio di informazioni e dati. Tutto questo oggi è a maggior forza interessante, grazie alle politiche Open Data realizzate da molte Pubbliche Amministrazioni e anche perché dal 19 marzo 2013i ”tutti i dati e documenti che le pubbliche amministrazioni pubblicano con qualsiasi modalità, senza l’espressa adozione di una licenza d’uso, si intendono rilasciati come dati aperti (open data by default)” (cit. dati.gov.it, mentre dal punto di vista normativo si tratta dell’articolo 52, comma 2 del CAD).

In questo post sottolineerò alcuni elementi relativi all’accesso ai dati tramite query via interfaccia REST (più propriamente tramite API REST).

Introduzione

Le API REST di ArcGIS – REST è l’acronimo di Representational State Transfer - forniscono una semplice interfaccia di accesso web ai server cartografici di questa casa software, sia ai dati/servizi che ad alcuni processi. Il tutto è quindi accessibile tramite una serie di URL gerarchici, che identificano ciò a cui si vuole accedere. L’URL di default di accesso ha di _default _questa struttura:

http://<host>:/arcgis/rest/services

Ad esempio quello della Regione Siciliana è questo:

http://map.sitr.regione.sicilia.it/ArcGIS/rest/services

E aprendo l’indirizzo sono elencati dati e servizi disponibili in questo server.

La documentazione ufficiale generale è molto ricca e vasta e non aggiungerò altri dettagli generici.

A seguire invece alcuni esempi di query  via ArcGIS REST API, in modo da apprezzarne la ricchezza e le modalità di accesso.

Interroghiamo una risorsa

Per gli esempi di questo articolo farò riferimento alla Regione Umbria, che ha aperto da poco i suoi dati cartografici. Dal suo portale open data possiamo leggere l’URL pubblico del server ArcGIS.

Si legge

http://geo.umbriaterritorio.it/arcgis/

Bisogna aggiungere (vedi sopra) “rest/services/” e abbiamo

http://geo.umbriaterritorio.it/arcgis/rest/services/

A questo punto non resta che sfogliare un po’ la directory pubblica e scegliere un layer su cui eseguire una query. Userò il dataset dei “NUMERI CIVICI”, che si raggiunge facendo click su Public > ECOGRAFICO_CATASTALE_WGS84 (MapServer) > NUMERI CIVICI.

Scorrendo la pagina verso il basso è visibile il tasto “Query“, tramite il quale è possibile interrogare il dataset.

Per lanciare la prima interrogazione devo inserire almeno un criterio di ricerca. Ad esempio il numero civico con “ID=1″ (ogni elemento ha sempre un identificativo numerico associato). La pagina html con il risultato dell’interrogazione mi fornisce informazioni sia sugli attributi che sulla geometria dell’elemento.

Posso fare allora una query per attributo: tutti gli elementi che contengono nel campo “DESCR_S49″ la stringa “CORPOSANO”. Nell’interfaccia leggiamo che ci sono 47 record che soddisfano questa condizione e l’output è in HTML. Ci sono però altri formati di output tra cui KML e JSON; questo l’output in JSON della stessa query.

Questi due formati quindi mostrano nei fatti, come una query REST su server ArcGIS sia un’ulteriore modalità di accesso al dato grezzo.

Query spaziale

E’ possibile eseguire anche delle interrogazioni spaziali di complessità variabile. Ad esempio posso estrarre tutti i civici che ricadono tra queste coordinate 12.384356,43.108511,12.388869,43.110765 (<xmin>,<ymin>,<xmax>,<ymax>).

Posso farne il download con GDAL/OGR (vedi sotto) e ottenere rapidamente i dati in formato spaziale e al contempo visualizzarne rapidamente una loro rappresentazione.

Accesso tramite GDAL/OGR a una query

La libreria GDAL/OGR ha i driver di accesso in lettura e scrittura al formato GeoJSON. Uno degli output delle query di sopra è proprio JSON e questa libreria lo riesce a leggere nativamente proprio come GeoJSON.

L’ultima query si effettua chiamando questo lungo URL:

http://geo.umbriaterritorio.it/ArcGIS/rest/services/Public/ECOGRAFICO_CATASTALE1_WGS84/MapServer/0/query?geometry=&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=DESCR_S49+LIKE+%27%25CORPOSANO%25%27&time=&returnCountOnly=false&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=&outFields=*&f=pjson

Nell’indirizzo di sopra sono visibili tutti i parametri disponibili per effettuare un’interrogazione, ma sopra abbiamo valorizzato soltanto la stringa di testo da ricercare in un determinato campo (parametro “where”) e il formato di output (parametro “f”). Questo URL fa da source per GDAL/OGR. Se voglio avere tutte le informazioni su questa sorgente di dati vettoriali userò il classico ogrinfo:

ogrinfo -ro "http://geo.umbriaterritorio.it/ArcGIS/rest/services/Public/ECOGRAFICO_CATASTALE1_WGS84/MapServer/0/query?geometry=&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=DESCR_S49+LIKE+%27%25CORPOSANO%25%27&time=&returnCountOnly=false&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=&outFields=*&f=pjson" OGRGeoJSON

“OGRGeoJSON” è per GDAL/OGR il nome predefinito del layer di una sorgente GeoJSON. “-ro” perché imposto l’accesso in sola lettura.

Se voglio convertire in ArcView Shapefile l’output di questa query userò ogr2ogr:

ogr2ogr CORPOSANO.shp "http://geo.umbriaterritorio.it/ArcGIS/rest/services/Public/ECOGRAFICO_CATASTALE1_WGS84/MapServer/0/query?geometry=&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=DESCR_S49+LIKE+%27%25CORPOSANO%25%27&time=&returnCountOnly=false&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=&outFields=*&f=pjson" OGRGeoJSON

Come esempio, riporto qui il download fatto con GDAL/OGR nei formati ArcView Shapefile, GeoJSON e KML.

Web mapping a partire da query

Queste query possono essere visualizzate in maniera molto efficace anche in un’interfaccia di web mapping. Sia a partire dal salvataggio dell’output, che tramite chiamata diretta in realtime. La cosa è inoltre resa semplice da una bella libreria rilasciata in open source da ESRI e basata su Leaflet: http://esri.github.io/esri-leaflet.

La query di sopra (quella sulla stringa “CORPOSANO”) ad esempio si può rappresentare rapidamente come sotto (click qui per aprire a schermo intero).

Il codice lo trovate qui: https://github.com/tanto/arcgisqueryrest/blob/gh-pages/index.html

Alcune note in conclusione

Sono rimasto molto in superficie, ma l’intento è quello di mostrare un punto di ingresso poco noto e utile, visto il sempre maggior numero di dati spaziali oggi disponibili e aperti. Di default l’output di queste _query _è limitato a 1000 risultati, quindi è necessario “ciclare” le chiamate. Ad esempio per ID a gruppi di 1000 record:

• inizio con la condizione OBJECTID>=1 and OBJECTID<=1000;
• poi OBJECTID>=1001 and OBJECTID<=2000;
• e così via …

Il totale (190140 record), da conoscere prima di fare partire il ciclo, si ricava ad esempio con questa query. Ci sono altri modi per ciclare tra i record, questo è solo un esempio.

L’accesso REST è molto utile anche con sorgenti di tipo raster, ma magari lo scrive qualcun altro, in un altro post .

L’URL con struttura “http://<host>:/arcgis/rest/services” è quello di default. Chi gestisce il server potrebbe usare uno schema diverso.

Questo post è dedicato al giovane Padawan “Flavio“, che mi ha fatto scoprire questa pagina e ha dato la stura alla stesura di questo testo.

Non mi RESTa che augurarvi un buon 2015!

L'articolo Take the best, use the REST è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Fornire gli strumenti per dare una risposta, significa fare una buona informazione civica, un obiettivo alto e stimolante per chi gestisce la cosa pubblica, ma che alle volte non è nemmeno abbozzato.

Per valutare il mio rischio devo rispondere almeno ad altre due domande:

• vivo vicino ad un rischio naturale?
• se sì, quanto è elevato?

I contenuti utili a definire la cosa sono disponibili, ma non permettono di passare dalla propria e personale conoscenza del territorio alla sua rappresentazione istituzionale.

Ho concentrato la mia ricerca sul rischio idrogeologico e sono “caduto” in questo articolo del Giornale di Sicilia: nella mia regione ci sarebbero 22 mila aree a rischio.
Il progetto di riferimento è il PAI (Piano di Assetto Idrogeologico), “lo strumento conoscitivo, normativo e tecnico-operativo mediante il quale sono pianificate e programmate le azioni, gli interventi e le norme d’uso riguardanti la  difesa dal rischio idrogeologico del territorio siciliano“.
Il sito web ufficiale è http://www.sitr.regione.sicilia.it/pai/, tenuto aggiornato nel tempo e ricco di pagine contenenti numerosi allegati (essenzialmente file PDF, compressi in file .zip). Mi aiuta a rispondere alle questioni poste sopra?

Non credo, salvo non conoscere ad esempio i nomi dei bacini idrografici locali, cosa ignota al 99 % delle persone che frequento. Ma anche sapendo il nome del bacino – ad esempio “Torrente Saponara, Area Territoriale tra i bacini T.te Saponara e F.ra Niceto” – ci si trova davanti a barriere di comunicazione come quella dell’immagine di sotto.

Qual è il significato del nome di questi file? Ne apro qualcuno, guardo un po’ dentro e cerco di capire? Non credo possa essere così, e sicuramente non può essere solo così.

Dati come questi devono essere pubblicati anche in maniera immediatamente comprensibile e leggibile da tutti: me, mia mamma, un giornalista, un pittore, un tecnico comunale, mio nipote il grande, il vicino di casa e financo da Gerlando.
Solo come esempio, per quell’insieme di persone che ha accesso al web, una semplice mappa come questa dà un’informazione che è subito comprensibile ad una platea vasta: dovo sono le aree a rischio frana in Sicilia, e qual è il grado di rischio.

Non scrivo tutto questo per fare una critica al PAI, è un progetto che non conosco e che immagino essere di qualità.

La barriera non è la presenza/assenza delle informazioni ma il loro scarso grado di utilizzabilità civica. Sarebbe auspicabile una collaborazione con la cittadinanza per trovare le modalità per superarla. Il risultato può essere proprio una mappa facilmente comprensibile da tutti.
Si tratta di un problema molto più semplice di quello del rischio idrogeologico, cionondimeno affrontarlo e risolverlo sarebbe una scelta politica con benefici a catena per tutti.

Invito la Regione Siciliana a costruire sul tema del rischio idrogeologico (e sul rischio in generale) una strategia di comunicazione e di informazione civica di qualità, senza barriere e ad ampio spettro.
Ad aprire di più e meglio i dati relativi, in modo che possano essere realizzate analisi e rappresentazioni del tema che oggi nemmeno immaginiamo. La carta interattiva di sopra, è stata implementata grazie a 2 servizi aperti: quello messo a disposizione dal Geoportale Regione Siciliana (special thanks ad Agostino) e l’ortofoto RealVista.

Una delle conseguenze dell’apertura dei dati è proprio quella di creare le precondizioni per raccontare meglio il proprio il territorio, in ciò per cui brilla e in ciò per cui è a rischio.
E io di queste storie vorrei poterne leggere tante.

NdR: questo articolo è pubblicato anche sul blog di Open Data Sicilia.

L'articolo Il rischio idrogeologico, la Regione Siciliana e l’informazione civica è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Le cose avvengono grazie al tempo che spendiamo per queste, alla crescita personale, all’evoluzione del contesto, agli incontri fatti, alla qualità delle persone. E questo è un anno che non dimenticherò.

Ringrazio l’Ing. Salvatore Cirone (dirigente dell’”Area 2 Interdipartimentale Sistemi Informativi Geografici, Infrastruttura Dati Territoriali Regionali e Cartografia”) e l’Ing. Agostino Cirasa (funzionario presso gli stessi uffici) per il dialogo di queste settimane e per l’immediata disponibilità all’autorizzazione, e Simone Cortesi che mi ha insegnato a passare la cera.

I servizi WMS da sfruttare per il ricalco, e i relativi metadati, dovrebbero essere quelle elencati qui: http://goo.gl/Hefwor

Qui invece la copia della lettera di autorizzazione. Tutto questo si innesta in un percorso iniziato proprio con OpenStreetMap qualche anno fa, e che sarà probabilmente soltanto una delle tappe previste in termini di apertura dei dati geografici da parte della Regione Siciliana.

L'articolo La Regione Siciliana autorizza il ricalco in OpenStreetMap sulle ortofoto di sua proprietà è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Lo spunto di partenza di oggi è lo stesso di allora: creare per il mio smartphone una copia della cartografia digitale dell’isola, in modo che sia disponibile anche offline, visto che in loco la connettività è scarsa.
Sono passati sei anni, un’enormità dal punto di vista tecnologico, e le modalità per farlo sono adesso davvero tante. Anche per questa ragione non parlerò di soluzioni, ma darò spazio a quello che è un vero e proprio scoop giornalistico: l’isola di Linosa deve essere spostata!

Scopro questa cosa incredibile il 18 agosto, data del mio arrivo sul posto. Nelle prime ore noleggio uno scooter, sistemo i bagagli in casa e subito voglio fare il punto mappa. Perché l’alloggio è in una zona per me nuova, perché voglio scegliere dove fare il primo bagno, perché mi voglio fare un’idea della viabilità, ecc.
Accendo il ricevitore GPS del mio smartphone, aspetto che venga calcolata la mia posizione, faccio partire la mia app e mi rendo subito conto di essere stato spostato a est di diverse decine di metri. Perché “carta canta”, non ci sono dubbi, e se il mio smartphone mi fa vedere il pallino in una certa posizione, sarà il mio maledetto telefonino “roottato” che funziona male. Ho pensato anche che il problema fosse della mia cartografia, ma avevo generato di proposito due basi offline, da due fonti diverse (Bing Maps di Microsoft e OpenStreetMap, e su entrambe riscontravo lo stesso problema.
Riavvio il telefonino, salgo sulla moto per fare un primo giro, arrivo sul lungo mare, rifaccio il test precedente e non cambia nulla.

Preso dalla sconforto decido di fare una passeggiata e registrare un tracciato GPS, in modo che di ritorno a Palermo possa fare con calma un po’ di verifiche e capire che strani dati produce il mio cellulare (si usa più questa parola?). A registrazione terminata, voglio essere sicuro che tutto sia stato archiviato correttamente, apro la mia app di tracking in una zona coperta da connessione web e scopro che tutto sembra tornare a funzionare. Ma c’è una differenza, la mappa di base stavolta è quella del Geoportale della Regione Siciliana: che siano le altre basi il problema?

Ho potuto verificare la cosa, alcuni giorni fa, al ritorno da Linosa. Avevo infatti bisogno di una connessione e di un personal computer.
Ho creato una vista cartografica (leaflet.js + Plugins by Pavel Shramov + Leaflet.Sync) in cui mettere a confronto i tre layer cartografici citati, sui quali ho sovrapposto la registrazione del mio percorso GPS, che ho usato un po’ come cartina al tornasole.

Come si vede dallo screenshot di sopra, la traccia GPS (in blu) è correttamente posizionata sul base della Regione Siciliana, mentre è spostata di diverse decine di metri a est su Bing Maps. E lo stesso (vedi sotto) vale per OpenStreetMap.

Non poteva essere diversamente perché i dati OpenStreetMap derivano (almeno per la gran parte) probabilmente da un tracciamento sulla base Bing. La Microsoft infatti ha concesso da tempo il ricalco sul proprio layer satellitare per l’arricchimento del database OSM, ma qui purtroppo è entrato in gioco la propagazione dell’errore: la base Bing è (qui a Linosa) “registrata” male, e qualsiasi prodotto derivato erediterà questo problema.

La vista cartografica dinamica interattiva con cui potrete testare la cosa in autonomia è accessibile qui: http://tanto.github.io/spostalinosa/
Ho inserito anche un pinpoint fisso a centro mappa, in modo da fare anche confronti a occhio tra un elemento individuato sulle due tavole.

Non ho idea di come sia possibile che i dati della multinazionale contengano questo errore, ma di certo “c’è da spostare Linosa”. A chi mi posso rivolgere per segnalare la cosa?
I dati OpenStreetMap saranno corretti in pochissimo tempo, per quelli di Bing temo ci vorrà più tempo: che grande cosa che è la “mappa liberamente modificabile dell’intero pianeta“!

Ho fatto leggere il post in bozza a questa redazione e a qualche altro amico. Sono usciti molti spunti “vicini” al bel post di Sergio, di cui un po’ questo è un figlio casuale, e anche uno dei mille “casi d’uso”.
Voglio concludere proprio con tre elementi che ho raccolto:

• la mappa non è il territorio (me l’ha detto tempo fa Franco Farinelli e me l’ha ripetuto in questi giorni napo);
• la cartografia della PA italiana è spesso di alto livello, è una grande risorsa e bisogna liberarla. Alla mia regione chiedo di lavorare sul passaggio ad una licenza che consenta pienamente il riuso dei dati, dalla attuale CC BY-SA 3.0 IT a una CC BY 4.0;
• in ultimo l’invito a non credere acriticamente né ai nostri strumenti, né ai dati a cui accediamo tramite questi, ad alzare la testa dallo smartphone e camminare un po’ più con lo sguardo aperto e rivolto in tutte le direzioni (lo so, lo so, si vede che è un’autocritica ).

NdR: questo di Linosa non è un caso unico e isolato. Sembra che anche Matera sia da spostare.

L'articolo Si avverte la gentile clientela che c’è da spostare un’isola è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Il caso d’uso: le strade e la loro manutenzione

Immaginate di essere i gestori del network della rete stradale della vostra città e di volere utilizzare QGIS (insieme ad altri strumenti) per farlo. Avete quindi un layer cartografico con tutte le strade (e i relativi attributi) e la necessità di associare a questo il dataset delle manutenzioni che vengono realizzate nei vari componenti della rete.

A seguire vedremo come gestire la cosa con QGIS, le relazioni e con il comodo supporto delle maschere di input personalizzabili.

Chiavi e relazione

Per mettere in relazione il dataset delle manutenzioni con quello delle strade, potrete usare il meccanismo classico delle chiavi.

Il layer delle strade sarà caratterizzato da un campo con un codice identificativo numerico univoco per ogni strada – la chiave primaria - denominato nell’esempio di questo post “pkuid”.

Il database delle manutenzioni – che è una semplice tabella senza alcun attributo spaziale – è composto dai campi “PK_UID”, “data”, “responsabile”, “compagnia”, “note”; aggiungeremo un campo che contenga il codice identificativo della strada a cui la manutezione è riferita. Questo campo farà da chiave esterna e si chiamerà “ce_pkuid”.

Il nostro modello prevede, per semplicità, che ad ogni strada sia possibile associare una o più manutenzioni; una classica relazione 1:N impostata sulle due chiavi numeriche di cui sopra.

Layer

Il layer delle strade ha la struttura sottostante, in cui sono stati introdotti dei campi per raccogliere il nome della Via, il relativo tipo (Corso, Viale, Via, ecc.) e il codice identificativo comunale.

Quello delle manutenzioni conterrà un codice identificativo numerico univoco per ogni elemento, un campo in cui inserire la data dell’intervento di manutenzione, il nome del responsabile, il nome della compagnia incaricata e un campo per le note.

Definire la relazione

La relazione tra i due dataset si definisce a livello di “Proprietà di progetto”. Aperto il tab Relations si farà click su “Add Relation” e si imposteranno i seguenti parametri:

• Name, per dare un nome alla relazione;
• Referencing Layer (Child), per il nome del layer che contiene la chiave esterna;
• Referencing Field, per il nome della chiave esterna;
• Referencing Layer (Parent), per il nome del layer che contiene la chiave primaria;
• Referencing Field, per il nome della chiave primaria;
• Id, che viene usato internamente da QGIS, deve essere univoco e fa da indice della tabella di relazione tra chiave primaria e chiave esterna.

A relazione definita, questa apparirà nella finestra di dialogo:

Moduli

Una volta definita la relazione, se ne avrà evidenza anche nel modulo di inserimento/modifica degli attributi del dataset delle strade. La visualizzazione a moduli in QGIS è molto utile per alcuni task di verifica ed inserimento dei dati, ed è molto personalizzabile.

La tabella della manutenzioni sarà visibile in un widget del modulo dello strade, e sopra questa saranno visibili cinque pulsanti:

1. la matita, per attivare la modifica della tabella delle manutenzioni;
2. il “+” per aggiungere un nuovo record alla tabella, che di default verrà associato all’elemento attivo del layer “strade”;
3. il tasto “x” per cancellare il record selezionato della tabella “manutenzioni”;
4. il tasto “catenella” che aprirà una nuova finestra di dialogo con il quale associare qualsiasi manutenzione presente alla strada corrente;
5. il tasto “rompi catenella” che rimuoverà l’associazione tra la manutenzione selezionata e la strada corrente;
6. ed infine, a destra, ci sono due pulsanti per passare dalla vista “tabella” a quella modulo.

Anche per il dataset delle manutenzioni è possibile attivare il modulo di inserimento/modifica degli attributi, in modo che dia conto visivamente della relazione con il layer delle strade.

A partire dalle proprietà del layer manutenzioni, bisognerà modificare il widget del campo che fa da chiave esterna.

E scegliere come tipo di widget “Relation Reference”, utilizzando i parametri visibili nella figura sottostante:

Una volta scelto questo speciale widget, sarà possibile leggere la relazione tra i due layer anche nel modulo delle manutezioni:

Note finali (riferimenti, file esempio e video demo)

Questo articolo è quasi una traduzione di questo di Matthias Kuhn. Sono caduto nel suo bel blog, perché tra i tipi di widget accessibili nelle proprietà dei campi di un layer ho scoperto il tipo “Relation Reference”. A me era completamente ignoto; ho provato a cercare nella documentazione, senza però trovarne traccia. Il post di Matthias mi è sembrata una piccola perla e ho creduto utile clonarlo.

Da qui potrete scaricare un file di progetto d’esempio basato su QGIS 2.2 e come formato dati su SpatiaLite. Questo ultimo farà da contenitore unico sia del file spaziale (le strade), che della tabella delle manutenzioni.

Nel progetto, per i due moduli, ho impostato altri widget diversi da quello di default (“Line edit”); alcuni sono di grande comodità come quello per il campo “data” delle manutenzioni (widget di tipo “Calendar”), o l’elenco controllato del campo “Tipo” (widget di tipo “Value map”) del layer delle strade.

Per chi vuole vedere la cosa in azione ho preparato un piccolo video, che non ha alcuna pretesa didattica. Vuole essere soltanto una carrelata visuale rapida di alcune delle cose descritte in questo post.

Un’ultima annotazione finale: il caso d’uso descritto è molto semplificato e non tiene conto di tutte i requisiti di un’applicazione complessa come la gestione di un network stradale. Mi è stato utile come esempio per scrivere di QGIS, relazioni, moduli e widget.

NdR: Salvatore Fiandaca, prendendo spunto da questo post, ne ha creato una sorta di versione aggiornata che trovate qui. Ringraziamo Totò e consigliamo la lettura

L'articolo QGIS, relazioni, moduli e widget, illustrati con un semplice caso d’uso è apparso originariamente su TANTO. Rispettane le condizioni di licenza.