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.

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.

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.

Mi spiego con un esempio classico: selezionare tutti i punti di un layer che cadono all’interno del perimetro di un poligono presente in un altro layer. E’ un’operazione tipica dei GIS, e presente in tutti database con estensione spaziale.

In MySQL basta lanciare una query spaziale di questo tipo:

SELECT * FROM poligoni as g1, punti as g2 WHERE Contains(g1.geometry,g2.geometry) = 1

Purtroppo però l’output non è costituito da tutti i punti contenuti nel perimetro di mio interesse, ma da tutti quelli contenuti nel rettangolo che lo include. Quest’ultimo è il classico Bounding Box, o come si definisce in ambiente MySQL Minimal Bounding Rectangles (MBR). Nel manuale online è riportato:

The OpenGIS specification defines the following functions. They test the relationship between two geometry values g1 and g2.

Questo dovrebbe garantire che l’output della funzione Contains() sia relativo al perimetro dell’oggetto “target”, ma poco più avanti si legge:

Currently, MySQL does not implement these functions according to the specification. Those that are implemented return the same result as the corresponding MBR-based functions.

Immagino che i GeoSpatial Developers abbiano diverse frecce al loro arco per superare questo problema, così come ne esisteranno diverse lato utente. Una potrebbe essere quella di non usare questo database server e fare tutto con PostGIS, Oracle Spatial, Spatialite, ecc., ma è troppo facile e non sempre si può scegliere.

Io ho pensato a GDAL/OGR ed alle sue utility per oggetti vettoriali, ed alla possibilità (che esiste dalla versione 1.10 della libreria) di usare il dialetto SQLite/Spatialite. Questo dialetto estende di molto quello che queste utility fanno (egregiamente) di default, ovvero eseguire delle query sql all’interno di un comando; ad esempio:

ogrinfo province.shp province -sql "SELECT nome FROM province WHERE ID_PRO = 2"

Con il dialetto SQLite/Spatialite ho a disposizione anche le funzioni per verificare relazioni spaziali tra oggetti, anche per quelle basi dati che non prevedono intrinsecamente la possibilità di farlo, proprio come MySQL spatial.

Andando nel concreto dovrei scrivere una cosa di questo tipo:

ogrinfo MYSQL:"mydb,user=myuse,password=mypwd,port=3306" -dialect sqlite -sql "SELECT *FROM poligoni as g1, punti as g2 WHERE Contains(g1.geometry,g2.geometry) = 1"

La sorpresa è che, nonostante si dichiari nella stringa il “dialetto” sqlite, si ottiene sempre come output quello relativo ai punti contenuti nel bounding box del perimetro di interesse. E’ un baco? Nella documentazione di OGR si legge:

All OGR drivers for database systems: MySQL, PostgreSQL and PostGIS (PG), Oracle (OCI), SQLite, ODBC, ESRI Personal Geodatabase (PGeo) and MS SQL Spatial (MSSQLSpatial), override the OGRDataSource::ExecuteSQL() function with dedicated implementation and, by default, pass the SQL statements directly to the underlying RDBMS. In these cases the SQL syntax varies in some particulars from OGR SQL. Also, anything possible in SQL can then be accomplished for these particular databases. Only the result of SQL WHERE statements will be returned as layers.

Ma si legge anche:

The SQLite dialect may be used with any OGR datasource, like the OGR SQL dialect. It is available through the OGRDataSource::ExecuteSQL() method by specifying the pszDialect to “SQLITE”. For the ogrinfo or ogr2ogr utility, you must specify the “-dialect SQLITE” option.

La soluzione l’ho trovata in un test stupido che ho voluto fare: accedere alla fonte MySQL non direttamente, ma tramite il Virtual Format di OGR, che in qualche modo astrae l’accesso al formato di input.

A partire quindi da una fonte MySQL costruita secondo le specifiche del Virtual Format e salvata come “test.vrt”:

<ogrvrtdatasource>
<ogrvrtlayer name="poligoni">
<srcdatasource>MYSQL:mydb,user=myuser,
password=mypwd,port=3306,host=127.0.0.1
</srcdatasource>
<srclayer>poligoni</srclayer>
<geometrytype>wkbPolygon</geometrytype>
<layersrs>epsg:4326</layersrs>
</ogrvrtlayer>
<ogrvrtlayer name="punti">
<srcdatasource>MYSQL:mydb,user=myuser,
password=mypwd,port=3306,host=127.0.0.1
</srcdatasource>
<srclayer>punti</srclayer>
<geometrytype>wkbPoint</geometrytype>
<layersrs>epsg:4326</layersrs>
</ogrvrtlayer>
</ogrvrtdatasource>

Posso ad esempio lanciare:

ogrinfo test.vrt -dialect sqlite -sql "SELECT *FROM poligoni as g1, punti as g2 WHERE Contains(g1.geometry,g2.geometry) = 1"

Il risultato ottenuto sarà così quello desiderato e l’output corrisponderà a tutti i punti che ricadono nel perimetro di interesse. Nell’immagine di sotto, ho raccontato il tutto in modo visuale.

Concludo sottolineando  quanto siano interessanti, utili, belle e di alto livello professionale alcune delle dinamiche delle comunità open source. Ho segnalato quello che a me sembrava un baco alla lista GDAL – DEV. Non solo ho ottenuto subito delle risposte che mi hanno consentito di capirne molto di più, ma si sono messi già al lavoro sia in termini di codice che di documentazione. Un semplice “grazie” sembra veramente poco.

Questo post è dedicato a Flaviano, un mio amico che grazie anche ad alcuni tips & tricks su GDAL/OGR ha trovato un bel posto di lavoro in Qatar

L'articolo Laddove non può MySQL spatial, arriva la coppia GDAL – Spatialite è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

E’ stata per me – che facevo purtroppo soltanto il bravo presentatore – un’esperienza entusiasmante. I “fantastici 4” di cui sopra sono riusciti a descrivere la loro esperienza di didattica in un MOOC (massive open online course) in modo interessante e molto variegato. La buona riuscita si deve a tre aspetti principali:

• la passione  (in questo caso per la geomatica)
• le storie professionali profondamente diverse di ognuno dei quattro
• la prorompente bella umanità dei protagonisti

E’ un video un po’ lungo (poco più di un’ora), ma è un crescendo che è una delle migliore testimonianze che io abbia visto su questo tipo di corsi online (lo so, il mio giudizio in questo caso vale poco). Averli ascoltati prima, ed avendo avuto in testa alcune delle loro parole dopo, mi è venuta una gran voglia di mettermi in gioco, di imparare, di condividere quanto appreso e di passare questo entusiasmo a qualcun altro.

Sembra sia stato un corso veramente ben pensato, e questo ovviamente è in qualche modo propedeutico. Ma le modalità di fruizione, l’interazione “massiva” con gli altri utenti da tutto il mondo, i criteri di valutazione e i tempi di fruizione sono altri aspetti importanti che rendono questo tipo di didattica molto soddisfacente.

Per preparare bene l’intervista è stata creata una piccola rassegna stampa, resa disponibile a tutti i partecipanti. Fornisce altri spunti di riflessione e dati sulla valutazione dei MOOC (non soltanto di natura geomatica). La trovate qui.

Oggi un amico – che l’ha visto in diretta – mi ha scritto che questo hangout “poteva tranquillamente essere preso per un servizio RAI (Storia)”. E’un giudizio molto di parte, ma più passano le ore, più sento di avere contribuito a creare qualcosa d’importante e non soltanto per questo settore.

In ultimo, un grosso grazie ai “fantastici 4”, ed al loro essere persone. E’ la cosa che personalmente mi ha arricchito di più.

Buona visione

L'articolo Quanto è bello parlare di didattica, condivisione, esperienza e voglia di apprendere è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Avrei voluto partecipare e prendermi il “pezzo di carta”, ma non ci sono riuscito. Dai commenti al post, e da altri segnali, ho capito di essere riuscito a stimolare l’interesse di altri. In particolare mi sono caduti sotto gli occhi questo lungo pezzo di Giuseppe, questo commento di Fabio ed il tweet di sotto di Lucio.

@MapRevolution class has been great, looking forward to other similar experiences. Have fun & beer in Germany

— Lucio (@zioluc) August 26, 2013

Ho pensato allora di scrivergli, e proporgli di fare una piccola tavola rotonda online, in cui racconteranno la loro esperienza e si confronteranno su questa. Mi hanno risposto da subito in modo positivo e lunedì 23 settembre alle 21:00 faremo un hangout in realtime, che verrà ospitato su GEO+, la bella comunità sulla geomatica che si sta sviluppando in modo molto interessante su Google+ (ma questo è un altro post ).

Sarà qualcosa di molto informale, che nasce da questi belli e inaspettati “effetto domino” che nascono facilmente in rete. Giuseppe, Fabio e Lucio, il “pezzo di carta” se lo sono presi, ma la cosa per me più interessante è avere constatato come tre persone diverse per formazione, professione e interessi siano “caduti” dentro lo stesso corso. Questo avviene in tutte le aule (virtuali e non),  ed a maggior forza in MOOC, ma i tre punti di vista differenti saranno un bel valore aggiunto per la narrazione dell’esperienza.

Ma chi sono Giuseppe, Fabio e Lucio?

Giuseppe Borruso, ricercatore universitario in Geografia Economica appassionato di Scienza dell’Informazione Geografica, co-fondatore di Geog-An-Mod (Geographical Analysis, Urban Modeling, Spatial Statistics). Appasionato di Mountain Bike, Nuoto e Sax.

Fabio Malfatti, etnoantropologo specializzato in storia orale, saperi tradizionali e gestione sostenibile del territorio. Geografia e mappe sono una passione e uno strumento di ricerca. Speleologo e alpinista.

Lucio Beltrami, laurea in architettura, gestore di dati per Seat Pagine Gialle a Torino. Interessi: Cartography, Camera, Cinema, Comics, (urban) Cycling.

Sarà l’occasione anche per testare una modalità di comunicazione, che speriamo possa dare la stura ad atri incontri di questo tipo. Sarebbe bello infatti replicare tanti James Fee, e fare i geohangout anche in Italia.
Sarà in real-time e sarà possibile anche ricevere domande e commenti. L’orario forse non è dei migliori, ma era l’unico che mettesse d’accordo gli studenti del corso. In ogni caso verrà tutto registrato e sarà visibile successivamente in qualsiasi momento.

Ci “vediamo” allora il 23!

Gianluca Calabretta: ingegnere ambientale alla ricerca della mappa perfetta. Attualmente si aggira circospetto tra enti pubblici, ed istituti di ricerca. Triste caso di avvelenamento neonatale da cartografia. Segue con disincanto tecnologia e fumetti. Fuori orario e’ possibile che lo vediate correre.

L'articolo Parliamo del primo MOOC su mappe e cartografia? è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Oggi parte il primo corso su Coursera dedicato alle mappe, dal titolo “Maps and the Geospatial Revolution“, il cui docente - Anthony C. Robinson - è (guarda caso) della stessa università.

“Coursera” non credo abbia bisogno di presentazioni, è una di quelle cose che capita di citare quando si vuole evidenziare il bello del web. E’  una società di formazione in partnership con le migliori università e organizzazioni di tutto il mondo, per offrire corsi on-line gratuiti e per tutti. Sul loro sito si legge:

We envision a future where everyone has access to a world-class education that has so far been available to a select few. We aim to empower people with education that will improve their lives, the lives of their families, and the communities they live in.

Qualche giorno fa ho fatto 40 anni e mi sembra un momento della vita molto bello. Questo corso mi fa tornare indietro di 20 anni, alla voracità di conoscenza un po’ irrazionale e poco analitica, ma anche alla bocca amara fatta per certi brutti sapori e ai crampi per mancanza di materia prima (parlo solo di conoscenza ).
L’andy di 20 anni fa sarebbe stato felice di poter disporre di un corso di questo tipo e di avere una banda internet che consentisse di usufruire di servizi di questo tipo; l’Andrea di oggi si iscrive sapendo di non avere il tempo libero e leggero di quegli anni, e spera di poter arrivare in fondo.

Non so dirvi quanta qualità ci sarà, ma mi sembrava utile darne notizia e seguire la Rivoluzione Geospaziale.

L'articolo Le “Mappe e la Rivoluzione Geospaziale”: mi sento di nuovo un ventenne è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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

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

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

L'articolo Cosa è l’OGC? (di ritorno dalla conferenza OpenGeoData) è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

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.

L'articolo Lezioni online per spiegare scienza e tecnologia è apparso originariamente su TANTO. Rispettane le condizioni di licenza.