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

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

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

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

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

In pratica, ho effettuato le seguenti operazioni:

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

Figura 1 – Adjust n points to polygon

Figura 2 – Layer di punti casuali

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

Figura 3 – Trasformazioni realizzate (Autore: Andrea Borruso)

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

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

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

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

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

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

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

Aggiornamento del 09/02/2013

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

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

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

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

Sono ancora aperte le iscrizioni alle Quinte Giornate Italiane di gvSIG, completamente gratuite, ed è richiesta solo la compilazione dell’apposito formulario. E’ possibile condividere le vostre esperienze professionali partecipando anche come relatori. Occorre semplicemente inviare un riassunto (abstract) al seguente indirizzo email: giornate.italiane@gvsig.org entro il 23 maggio 2012 (consultare le norme per le presentazioni). Affrettatevi!

L'articolo Quinte Giornate Italiane di gvSIG a Como è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

In particolare, Andrea ci mostrava come configurare Open++ in modo da “automatizzare” l’utilizzo di alcune utility dello swiss knife geospaziale per eccellenza: la libreria GDAL. Cercheremo pertanto di ottenere lo stesso risultato di allora, utilizzando stavolta l’ultima release di Open++ (v. 1.5.1).

Partiamo innanzitutto dal notare che la struttura della finestra di dialogo di Open++ è leggermente cambiata rispetto al passato. In luogo della scheda Language, ora ne sono presenti altre due: Install/Uninstall e About. Tralasciando l’ovvio significato di quest’ultima, la scheda Install/Uninstall è stata introdotta in sostituzione del vecchio installer, rendendo quindi l’applicazione portabile (può essere eseguita su una semplice chiavetta USB). La scheda principale (Commands) è apparentemente rimasta invariata rispetto al passato. Tuttavia, come ci fa notare Chiara (una lettrice che di recente ha commentato il post di Andrea, sollevando il problema), qualcosa è cambiato nella versione 1.5.1 (probabilmente anche prima): si tratta essenzialmente delle variabili utilizzabili nella casella di testo in cui andiamo a configurare i nostri comandi e, in particolare, quella degli argomenti (Arguments), come mostrato nella figura seguente.

Tali variabili, per quanto siano di una chiarezza quasi disarmante, risultano però meno flessibili da gestire rispetto alle versioni precedenti specie quando, come nel caso delle utility della libreria GDAL, il nostro comando accetta due o più parametri basati sul nome del file in ingresso. Fortunatamente, ci viene in soccorso l’unica FAQ presente nell’help file di Open++ (abbastanza criptico, in verità…) in cui è mostrato l’utilizzo di un ciclo for in linguaggio batch all’interno degli argomenti. Dunque, se è possibile usare il linguaggio batch, è altrettanto possibile usare anche i parametri batch e trarne così beneficio nel gestire i nomi dei file con o senza le loro estensioni. Ovviamente un ciclo for è applicabile anche su un singolo file e quindi il gioco è fatto!

Andando al sodo, per prima cosa consiglio di aggiungere la cartella dei binari di GDAL (o di FWTools, se preferite) all’interno della variabile PATH di sistema. Così potrete facilmente eseguire qualsiasi tool di GDAL all’interno di una qualsivoglia cartella, senza la necessità di dover riscrivere il suo percorso. In questo altro post sempre di Andrea (lo “swiss knife” di TANTO ) è descritto come fare. Nel seguito, assumerò che lo abbiate fatto.

Quindi aggiungiamo un separatore delle opzioni di menù nella scheda Commands di Open++ e proviamo a configurare l’utility relativamente più semplice tra quelle trattate da Andrea: gdalinfo. Per prima cosa, scriviamo “GDALinfo” come titolo. Poi, trattandosi di una utility che si esegue da riga di comando, il programma da utilizzare sarà %ComSpec%, ovvero il nome della variabile di ambiente usata da Windows per indicare l’interprete da linea di comando (CLI), solitamente cmd.exe. Fin qui nulla di nuovo rispetto al post di Andrea. Negli argomenti, invece, scriveremo:

/k gdalinfo %FilePaths%

La spiegazione è piuttosto semplice: /k significa che vogliamo mantenere la finestra aperta dopo l’esecuzione del comando (altrimenti non riusciremmo a leggere le informazioni), gdalinfo è il nome dell’eseguibile dell’utility e, quindi, %FilePaths% è una variabile che rappresenta il vettore dei percorsi dei file passati come parametro. La directory di lavoro coincide con la directory del file stesso (%FileDir%), scegliamo eventualmente un’icona per rappresentare il comando, associamo il comando al singolo file e, infine, esplicitiamo le estensioni possibili del file in ingresso. Nulla di trascendentale, verrebbe da pensare.

Le cose si complicano, invece, quando andiamo a mettere in pratica l’esempio di Andrea relativo a gdal_translate. La procedura è sostanzialmente identica al caso precedente, ad eccezione dell’argomento. Tuttavia, come anticipavo in precedenza, ci viene ottimamente in soccorso l’unica FAQ a disposizione. E, pertanto, l’argomento da scrivere per convertire in formato JPEG sarà:

/c for %i in (%FilePaths%) do start gdal_translate -of JPEG %~nxi %~ni.jpg

che, in pratica, significa che per tutti i file contenuti nel vettore dei percorsi %FilePaths% (nel nostro caso, contiene un unico percorso in quanto selezioneremo un unico file) esegue il comando gdal_translate -of JPEG %~nxi %~ni.jpg, dove %~nxi è il nome compreso di estensione del raster sorgente, mentre %~ni è il nome privo di estensione del raster di destinazione, seguito poi da .jpg.

E non è ancora tutto! Visto che usiamo un ciclo for come argomento e che Open++ prevede l’associazione dei suoi comandi anche ad un insieme di file, possiamo quindi rendere la conversione in JPEG in modalità batch. A tal fine, creeremo sostanzialmente una copia del Convert to JPEG in cui aggiungeremo solo il termine (batch) alla fine del titolo e poi cambieremo l’opzione Associate with da Single File a Multiple File. Possiamo quindi selezionare più file raster e da menù contestuale scegliere l’opzione Convert to JPEG (batch) per avere la conversione in blocco di tutti i file selezionati. E’ quindi adesso facile definire altri comandi di conversione verso altri formati raster supportati da GDAL …e non solo!

Per i più pigri, ecco il file di configurazione OpenXX.ini dei comandi descritti in precedenza. Basta copiarlo nella cartella contenente Open++, eseguirlo …et voilà …si otterrà la stessa identica configurazione. Si tratta di un metodo semplice e rapido per condividere le proprie raccolte di comandi con i colleghi.

Una nota a margine: in caso si decida di definire comandi per effettuare operazioni di coordinate, occorre aggiungere alla variabile PATH di sistema anche il percorso della cartella di GDAL (o eventualmente della libreria proj.4) che contiene le definizioni dei vari sistemi cartografici definiti da EPSG.

Infine, un grosso ringraziamento a Chiara per averci costretti a rivalutare un post obsoleto.

L'articolo GDAL in due clic con Open++ è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Abbiamo preso a cuore questo progetto poiché rappresenta, a nostro modesto avviso, una sintesi non tecnica particolarmente efficace a livello divulgativo che descrive ottimamente quello che è il mondo delle tecnologie geospaziali che ci piace tanto …e non solo! Ci ha offerto infatti innumerevoli spunti di riflessione, ponendoci davanti diversi interrogativi. Dove saremmo ora se John Snow non avesse disegnato la sua mappa leggendaria, ponendo così le basi per l’analisi spaziale in senso moderno? A quale destino ancor più amaro sarebbe andato incontro Haiti dopo l’immane catastrofe del terremoto del 2010, se non fossero esistiti il progetto OpenStreetMap e i suoi contributori provenienti da ogni angolo del mondo? Gli abitanti di Kibera avrebbero oggi a disposizione fondamentali servizi laddove prima non c’erano, se non fosse stata messa in campo l’iniziativa meravigliosa di Map Kibera? E ce ne sarebbero tanti altri…

Un viaggio durato un paio d’anni, ma che certamente non si esaurisce qui. L’epilogo del quarto ed ultimo episodio (di cui finalmente abbiamo terminato la traduzione dei sottotitoli e che vi riproponiamo in questo post) condensa tutto il senso di quanto ci siamo detti finora e quanto ancora deve venire:

Questa tecnologia sta cambiando il modo in cui guardiamo il mondo. Stiamo acquisendo la comprensione basata sulla localizzazione di qualsiasi cosa sul pianeta rendendola ora quasi tangibile. [...] La geografia e la scienza stanno per fare la differenza. Aiuteranno i governi a prendere decisioni migliori, aiuteranno le persone a imparare cose in modi nuovi, aiuteranno i cittadini a comprendere il loro governo e mettersi in gioco, contribuiranno a salvare il mondo.

Non ci resta che attuarla questa rivoluzione giorno dopo giorno, cercando di disseminare in maniera capillare questa nuova forma di consapevolezza, a partire dai banchi di scuola per finire a quelli di chi ci governa, e immaginando nuovi possibili utilizzi di queste tecnologie al servizio dell’intera umanità. L’evoluzione dell’homo geographicus si trova ancora sul ramo ascendente della sua parabola, per cui abbiamo ancora tanta strada da percorrere…

…la rivoluzione geospaziale continua!

L'articolo La rivoluzione geospaziale continua! è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Anche TANTO dice no al bavaglio alla rete! Seguiamo insieme “La notte della rete”, una 4 ore no-stop in cui si alterneranno cittadini e associazioni in difesa del web, politici, giornalisti, cantanti, esperti. L’evento sarà in diretta streaming a partire dalle 17:30. L’hashtag Twitter è #notterete.

Tutti noi crediamo che il diritto di autore vada rispettato e tutelato come parte integrante della persona e del diritto di espressione.

Proprio in relazione a tali valori non può essere accettato né il principio, né il modus operandi della detta delibera che, lungi dal tutelare veramente il diritto di autore, mina seriamente, dal punto di vista sostanziale e dal punto di vista formale, i diritti inviolabili dell’individuo.

Di seguito, per chi volesse farsi una idea sulla questione, vi segnaliamo i seguenti link:

• Cosa c’è da sapere sulla Delibera 668/2010 dell’AGCOM e il diritto d’autore: A chi si applica, come ci si può difendere, cosa succede per i siti esteri.
• Agorà digitale

L'articolo La notte della Rete è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

L'articolo Programma delle Quarte Giornate Italiane di gvSIG è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Il primo capitolo dal titolo “Mapping the Road to Peace” sostiene la necessità di avere gli “occhi della nazione” (USA) puntati sui “cattivi” e di utilizzare la geospatial intelligence per intercettare sul nascere le crisi internazionali. Ma soprattutto ricorda quello che è stato il primo impiego di successo delle tecnologie geospaziali nelle trattative diplomatiche durante il conflitto della Bosnia-Erzegovina, a metà degli anni Novanta.

Il secondo capitolo “Waging Modern War” si occupa di strategia e mission planning nella guerra moderna di precisione. Descrive l’impiego nelle missioni militari della tecnica “BuckEye Terrain Visualization” che raccoglie, elabora e trasmette dati del terreno ad elevata risoluzione mediante una camera elettro-ottica e un sensore LIDAR al fine di individuare la posizione degli IED (Improvised Explosive Devices), una continua minaccia anche per le missioni di pace molto difficile da scovare, come purtroppo ci ricorda la triste cronaca di questi giorni. Si parla anche di human geography, ovvero degli aspetti sociali, culturali, economici, ecc. calati direttamente sulla geografia fisica, la cui rappresentazione su mappa è in grado di facilitare la comprensione da parte dei militari della complessità di Paesi come l’Afghanistan.

Nel terzo capitolo “Serving & Protecting”, invece, si illustra come le tecnologie geospaziali possano costituire un valido strumento di supporto alle attività delle forze dell’ordine. Ad esempio in caso di una rapina in banca, è possibile calcolare in tempo reale le isocrone sulla rete stradale e quindi circoscrivere il perimetro entro il quale ricercare i criminali e posizionare i posti di blocco. E’ mostrato come l’impiego congiunto di un criminologo e dei GIS possa consentire l’individuazione della correlazione esistente tra gli hotspot di particolari tipologie di crimini avvenuti in una determinata area e la loro posizione, permettendo quindi una migliore dislocazione delle pattuglie a disposizione, specie se l’area da controllare è molto estesa. Si parla inoltre dell’uso del braccialetto elettronico in California come deterrente per chi ha commesso reati di natura sessuale e viene rilasciato in libertà condizionata.

L’ultimo capitolo “Staying Safe” ci pone un interrogativo: disporre di un GPS nel proprio telefono cellulare può essere utile in caso di emergenza per le forze dell’ordine, ma cosa succede se chi controlla è ad esempio uno stalker? Il progresso che scaturisce dall’uso delle tecnologie geospaziali presenta quindi un duplice aspetto. Da un lato, bisogna saper cogliere tutti i benefici che ne possono derivare. Dall’altro, occorre ricordarsi che la tecnologia può essere oggetto di abuso e quindi occorre saperla gestire.

the more data that’s available out there
the more transparent the world becomes

Oggi è possibile tenere traccia delle persone, che lo sappiano oppure no. Ma si tratta davvero di un’invasione della privacy o solo dell’affermazione di una tecnologia irreversibile e al tempo stesso sempre più irresistibile? Chissà cosa ne pensa la gente…

L'articolo Il lato oscuro della Rivoluzione Geospaziale è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Dal 19 al 21 aprile 2011, si terranno le “Quarte Giornate Italiane di gvSIG” presso l’Auditorium della Regione Autonoma Friuli Venezia Giulia, in via Volturno a Udine.

L’incontro, organizzato dalla Direzione centrale delle risorse rurali, agroalimentari e forestali della Regione Autonoma Friuli Venezia Giulia, dal Dipartimento di Scienze della Vita dell’Università degli Studi di Trieste e dall’Associazione gvSIG, con il patrocinio di Cartesio dell’Università degli Studi di Udine, dell’Istituto Nazionale di Oceanografia e di Geofisica Sperimentale – OGS, della Provincia Autonoma di Bolzano/Bozen, della Comunità Montana della Carnia e del Comune di Tavagnacco, è un interessante punto d’incontro e di scambio di esperienze tra gli utilizzatori italiani e quelli dell’Europa centrale. Sono infatti previste numerose presentazioni internazionali.

E’ già possibile inviare le proposte di comunicazione presso il seguente indirizzo email: giornate.italiane@gvsig.org (consultare le Norme per le presentazioni). Termine per il ricevimento dei riassunti delle presentazioni: mercoledì 16 marzo 2011.

L’iscrizione alle Quarte Giornate Italiane di gvSIG potrà avvenire a partire dal 16 febbraio 2011.

Saranno illustrate le novità della versione desktop 1.11, delle estensioni per il laser scanning e 3D, e della versione 1.0 per palmare, come nel corso delle 6e Giornate tenutesi a Valencia nel dicembre 2010.

Saranno inoltre presentate applicazioni di interesse regionale, nazionale ed europeo in materia di urbanistica, telerilevamento, idrologia, didattica…

Giornate Italiane di gvSIG

L'articolo Quarte Giornate Italiane di gvSIG è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Cos’è JEQL?

JEQL è un Query Language sviluppato in Java, dove la “E” può assumere i seguenti significati:

• Extended, poiché implementa un numero sempre crescente di estensioni che lo rende più potente nel processamento dei dati rispetto alle tante versioni e dialetti SQL esistenti;
• Embeddable, in quanto il motore di JEQL può essere integrato all’interno di altre applicazioni, in modo da essere utilizzato come query language per modelli di dati tabellari;
• ETL, essendo l’Extract/Transform/Load il caso d’uso ideale di JEQL;
• Efficient, dato che garantisce velocità di sviluppo ed esecuzione.

JEQL è dunque un linguaggio di scripting che consente il processamento di strutture di dati tabellari, compresi quelli geografici vettoriali. Fin qui nulla di nuovo, probabilmente penseranno i lettori esperti dei possenti RDBMS con estensione spaziale (PostgreSQL + PostGIS, Oracle Spatial, MySQL, ecc.) o del più leggero e, al tempo stesso, molto versatile SpatiaLite. Analogamente a quest’ultimo, JEQL non richiede l’installazione di un server database e ciò, assieme al fatto che è un linguaggio di scripting, rappresenta un grosso vantaggio in termini di portabilità. Si pensi ad esempio alla replicazione della configurazione di un DBMS a distanza di parecchio tempo oppure alla condivisione di uno script con un nostro collega. Inoltre, anche la velocità di sviluppo e di esecuzione rappresentano dei non trascurabili punti di forza. Naturalmente, esistono anche dei task non coperti da JEQL per i quali un RDBMS è insuperabile.
Quali tipi di dati è in grado di utilizzare? Oltre ai classici tipi Java (interi, stringhe, double) e le date, JEQL supporta anche le geometrie JTS e un vasto repertorio in continua crescita di funzioni spaziali, costruttori di predicati e funzioni di aggregazione, che lo rendono uno strumento particolarmente adatto per il processamento di dataset spaziali. Inoltre, è in grado di accedere in lettura e scrittura a diversi formati di dati (CSV, DBF, SHP, KML) e database compatibili con JDBC (Java Data Base Connectivity).
L’installazione di JEQL è molto semplice: nei sistemi operativi Windows, basta scompattare il pacchetto di installazione (è appena stata rilasciata la versione 0.9) in una cartella con percorso non contenente spazi ([JEQL_HOME]) ed aggiungere nella variabile PATH di sistema il percorso [JEQL_HOME]\bin. Manca, tuttavia, uno script shell o qualcosa di analogo per Linux, che tuttavia non dovrebbe essere difficile da produrre.
L’apprendimento del linguaggio JEQL è abbastanza rapido, soprattutto per chi possiede già dei rudimenti di SQL, ed è facilitato dall’interprete che guida l’utente nell’individuazione e nella correzione degli errori. Il pacchetto di installazione è inoltre corredato da una lista di unit test, ovvero gli stessi esempi basilari utilizzati in fase di collaudo del codice. La documentazione rappresenta invece una delle poche note dolenti, essendo ancora un work in progress, nonostante la presenza di alcuni illuminanti esempi applicativi, diversi post su Lin.ear Th.inking e una mailing list dedicata, oltre alla indiscutibile cortesia e competenza dello sviluppatore.
Attualmente JEQL è rilasciato con doppia licenza: freeware e “commerciale”. Quest’ultima per consentirne l’integrazione all’interno di software commerciali (…e in quelli open source?).

Un esempio applicativo: worldAirRoutes.jql

Nel seguito, si cercherà di fornire un saggio delle potenzialità di JEQL, proponendoci le stesse finalità del post citato in precedenza, ovvero disegnare le rotte aeree a scala globale secondo linee ortodromiche, piuttosto che linee rette, con tutti gli accorgimenti del caso al fine di ottenere una buona resa grafica. Ci cimenteremo passo dopo passo con le fasi di importazione e normalizzazione dei dati di interesse fino al raggiungimento dello scopo. I dati utilizzati nell’applicazione sono:

• airport.dat
• routes.dat
• TM_WORLD_BORDERS_SIMPL-0.3.zip

In particolare, i primi due sono parte degli open data del progetto OpenFlights, rilasciati con Open Database License (Odbl), mentre lo shapefile semplificato dei world borders (a proposito della loro qualità, si consiglia la lettura di questo post e successivi) è rilasciato da thematicmapping.org con licenza Creative Commons CC-SA.
Dopo aver installato JEQL 0.9, creiamo una cartella, vi collochiamo i dati appena scaricati (scompattando naturalmente lo zip file) e vi definiamo inoltre un semplice file di testo (worldAirRoutes.jql) nel quale andremo a scrivere il nostro codice.
Il primo passo dell’applicazione consiste nell’importazione dei dati relativi agli aeroporti (airport.dat), tenendo presente che i file .dat in esame sono in formato CSV:

// Read data from CSV
CSVReader airports file: "airports.dat";
numAirports = select count(*) from airports;
Print "Number of airports to clean: " + val(numAirports);
Print airports limit: 10;

Salviamo lo script, apriamo il prompt dei comandi e collochiamoci nella directory che lo contiene. Per eseguirlo occorre digitare jeql worldAirRoutes.jql e premere il tasto Invio. Successivamente, nel prompt dei comandi comparirà qualcosa del genere:

Number of airports to clean: 6344
col1:String, col2:String, col3:String, col4:String, col5:String, col6:String, col7:String, col8:String, col9:String, col10:String, col11:String
1 Goroka Goroka Papua New Guinea GKA AYGA -6.081689 145.391881 5282 10 U
2 Madang Madang Papua New Guinea MAG AYMD -5.207083 145.7887 20 10 U
3 Mount Hagen Mount Hagen Papua New Guinea HGU AYMH -5.826789 144.295861 5388 10 U
...

La prima cosa che scopriamo è che le colonne della tabella “airports” sono identificate come “col1, col2 … colN”, sebbene il file CSV sia sprovvisto delle relative intestazioni dei campi (per la descrizione dei quali si rimanda a questa pagina), e che i campi sono considerati tutti di tipo String. Procediamo quindi con la normalizzazione dei dati degli aeroporti, selezionando i dati di nostro interesse:

// Select airports data with valid IATA airport code
airports2 = select
  col2 as name,
  col3 as city,
  col4 as country,
  col5 as code,
  col7 as lat,
  col8 as lon
  from airports
  where RegEx.matches(col5,'[A-Z]{3}');

E’ interessante notare che:

• per definire gli alias dei campi di una tabella è utilizzata la parola chiave as, così come avviene solitamente in molte versioni di SQL, tuttavia si tenga presente che in JEQL il suo uso è a discrezione dell’utente;

• nella clausola where è utilizzata la funzione RegEx.matches (campo, espressione regolare) in modo da selezionare mediante una semplice espressione regolare tutti e soli gli aeroporti con codice IATA composto da tre lettere maiuscole, in base allo standard ufficiale dell’International Air Transport Association (IATA).

Occorre, inoltre, verificare la presenza di eventuali codici IATA duplicati, in modo da essere certi dell’univocità del campo “code”, al fine di utilizzarlo poi come chiave esterna nelle operazioni di join con la tabella delle rotte aeree (routes.dat), come si vedrà nel seguito.

// Find duplicate IATA airport codes in airports data
duplicateCodes = select *
  from (select code, count(code) as numOccurrences
    from airports2
    group by code) as duplicates
  where numOccurrences > 1;
Print duplicateCodes;

A fronte di tale verifica, si riscontra un unico codice duplicato (“TCG”). Avvalendoci dell’ausilio della banca dati ufficiale è possibile risolvere tale ambiguità, scartando l’aeroporto di Tocache (Cina) al quale è stato erroneamente attribuito questo codice. A tal fine, la clausola where della prima select diventa:

  where RegEx.matches(col5,'[A-Z]{3}')
  and col3!="Tocache";

E’ dunque possibile commentare il codice relativo alla ricerca dei duplicati (“//” commenta una singola riga, mentre “/* … */” tutto il codice tra essi compreso – non a caso, come nel linguaggio Java) e verificare la bontà dei risultati fin qui ottenuti, visualizzando eventualmente i primi dieci record della tabella “airports2”.

// Check intermediate results
numAirports2 = select count(*) from airports2;
Print "Number of airports without duplicates: " + val(numAirports2);

Omettendo per brevità la visualizzazione del contenuto delle tabelle, otteniamo:

Number of airports without duplicates: 5023

Successivamente, si procede all’importazione e normalizzazione dei dati relativi alle rotte aeree (routes.dat). In particolare, selezioniamo i codici IATA degli aeroporti di origine e destinazione relativi a ciascuna rotta aerea, e li combiniamo in un’unica stringa in modo da poter escludere le rotte duplicate mediante l’operazione di raggruppamento (group by). Da queste stringhe è poi possibile recuperare nuovamente i codici dai quali sono stati ottenuti. Inoltre, definiamo una chiave primaria “rid” tramite la funzione rownum() che restituisce il numero di riga.

// Read data from CSV
CSVReader routes file: "routes.dat";
numRoutes = select count(*) from routes;
Print "Number of routes to clean: " + val(numRoutes);
	
// Select routes data removing duplicates
routes2 = select
  rownum() as rid,
  String.substring(routeCode, 0, 3) as fromCode,
  String.substring(routeCode, 3, 6) as toCode
  from (select
    //col3 as fromCode,
    //col5 as toCode,
    col3+col5 as routeCode
    from routes
    order by routeCode asc) as routesWithDuplicates
  group by routeCode;
	
// Check intermediate results
numRoutes2 = select count(*) from routes2;
Print "Number of routes without duplicates: " + val(numRoutes2);

ottenendo:

Number of routes to clean: 64114
Number of routes without duplicates: 36004

Il task successivo consiste nell’associare ad ogni rotta aerea le coordinate dell’aeroporto di partenza e di quello di destinazione, scartando le coordinate con valore null e validando quelle che non lo sono, facendo ancora una volta ricorso alle espressioni regolari.

// Extract origin airport data
fromAirport = select
  rid,
  fromCode,
  name as fromName,
  city as fromCity,
  country as fromCountry,
  lat as fromLat,
  lon as fromLon
  from routes2
  left outer join airports2
  on routes2.fromCode == airports2.code;
	
// Extract destination airport data
toAirport = select
  rid,
  toCode,
  name as toName,
  city as toCity,
  country as toCountry,
  lat as toLat,
  lon as toLon
  from routes2
  left outer join airports2
  on routes2.toCode == airports2.code;
	
// Join the last two tables (removing records with null coords)
troute = select fromAirport.*, toAirport.* except rid
  from fromAirport
  join toAirport
  on fromAirport.rid==toAirport.rid
  where not Val.isNull(fromLat) and not Val.isNull(fromLon) and not Val.isNull(toLat) and not Val.isNull(toLon);
	
// Check if coords are valid
troute2 = select *
  from troute
  where RegEx.matches(fromLat,'-?((([0-9]|[1-8][0-9])(\.[0-9]*)?)|(90))')
  and RegEx.matches(fromLon,'-?((([0-9]|[1-9][0-9]|1[0-7][0-9])(\.[0-9]*)?)|(180))')
  and RegEx.matches(toLat,'-?((([0-9]|[1-8][0-9])(\.[0-9]*)?)|(90))')
  and RegEx.matches(toLon,'-?((([0-9]|[1-9][0-9]|1[0-7][0-9])(\.[0-9]*)?)|(180))');
	
// Check intermediate result
numRoutes3 = select count(*) from troute2;
Print "Number of routes without duplicates and with valid coords: " + val(numRoutes3);

che ci restituisce:

Number of routes without duplicates and with valid coords: 35475

Un altro aspetto degno di nota è l’utilizzo della parola chiave except nella select della tabella “troute”. Si tratta di un’estensione solitamente assente nei vari linguaggi SQL che ci consente di selezionare tutti i campi di una particolare tabella ad eccezione di un campo.
Infine, selezioniamo i dati da cui poter derivare le geometrie delle rotte aeree e rappresentarle graficamente (da qui in poi, il codice è quello del Dr JTS con qualche piccolo adattamento):

// Convert coords from string to double
trte = select fromCity, toCity,
  Val.toDouble(fromLon) fromLon, Val.toDouble(fromLat) fromLat,
  Val.toDouble(toLon) toLon, Val.toDouble(toLat) toLat
  from troute2;
	
// Split geodetic arcs and calculate lengths
tlines = select fromCity, toCity, line, len
  with {
    line = Geodetic.split180(Geodetic.arc(fromLon, fromLat, toLon, toLat, 2));
    len = Geom.length(line);
  }
  from trte order by len desc;
	
// Interpolate line color and fix line width
tplot = select line,
  Color.interpolate("ffffff", "00aacc", "0000ff", len / 50.0 ) lineColor,
  0.2 lineWidth
  from tlines;
	
// Import shapefile data
ShapefileReader tworld file: "TM_WORLD_BORDERS_SIMPL-0.3.shp";
	
// Select geometries and define line and fill colors
tworldLine = select GEOMETRY, "222222" lineColor from tworld;
tworldFill = select GEOMETRY, "333333" fillColor from tworld;
	
// Plot routes with world landmasses
width = 1800;
Plot width: width height: width / 2
  extent: LINESTRING(-180 -90, 180 90)
  data: tworldFill
  data: tplot
  data: tworldLine
  file: "routes.png";
	
// Plot routes without world landmasses
Plot width: width height: width / 2
  extent: LINESTRING(-180 -90, 180 90)
  data: tplot
  file: "routes_only.png";

Qui è possibile effettuare il download dell’intero script. Infine, si mostrano le due immagini risultanti in cui sono rappresentate le rotte aeree rispettivamente con e senza i world borders. In particolare, le rotte sono disegnate in ordine di lunghezza decrescente, utilizzando un colore interpolato in base alla lunghezza, per cui spiccano le rotte più brevi con colore più chiaro. Anche nella seconda immagine, è possibile rilevare con buona approssimazione i limiti di molte terre emerse.

Come giustamente afferma Martin Davis, dalla densità delle rotte aeree che si percepisce nelle immagini si evince come agli europei piaccia molto volare. Ma neanche quelli delle East Coast scherzano!

Conclusioni

L’esempio applicativo appena mostrato esprime già molte delle potenzialità offerte da JEQL, e i comandi attualmente disponibili sono molto numerosi (basta digitare jeql -man per scoprirlo!). JEQL offre inoltre anche la possibilità di estendere le sue funzionalità tramite un’interfaccia di programmazione (API), non ancora documentata, tramite la quale creare nuovi comandi e funzioni da poter utilizzare all’interno dei nostri script. Non nascondiamo la speranza, in parte malcelata dallo stesso Martin Davis, che un domani si possa usufruire di una doppia licenza open source/commerciale, che permetta di contribuire alla crescita della libreria con nuovi plugin e una migliore documentazione di tutte le caratteristiche offerte.

Ringraziamenti

Desidero ringraziare Giovanni Allegri, non solo per il proficuo scambio di idee avvenuto dietro le quinte, ma anche per aver sollecitato il rilascio della nuova release (0.9) di JEQL, senza la quale non sarebbe stato possibile riprodurre l’applicazione, e naturalmente Martin Davis, il padre di questo formidabile linguaggio, per aver ispirato questo post.

L'articolo JEQL: un linguaggio di scripting geospaziale con la E maiuscola è apparso originariamente su TANTO. Rispettane le condizioni di licenza.

Trenta anni fa non esisteva ancora il Sistema Nazionale di Protezione Civile, così come lo conosciamo oggi, e si nominò un Commissario Straordinario allo scopo di fronteggiare l’emergenza e coordinare i soccorsi delle popolazioni interessate dal terremoto, che entrò in servizio solamente 24 ore dopo la catastrofe. Gli eventi sismici molto recenti verificatisi in Abruzzo (aprile 2009) e ad Haiti (gennaio 2010), così come altre calamità naturali, dimostrano come la celerità degli interventi durante le prime ore di soccorso sia fondamentale nel salvataggio di vite umane. Una risposta tempestiva e efficiente della Protezione Civile può fare la differenza, ma tutto ciò non può e non deve bastare.

“L’Italia è un paese di santi, poeti, navigatori…” e purtroppo anche di terremoti. Basti pensare che nell’arco di un mese si verificano generalmente diverse centinaia di eventi sismici che interessano la quasi totalità del nostro Paese (si salvano la Sardegna e la penisola salentina), dei quali fortunatamente la maggior parte è percepita solo a livello strumentale e non dalla popolazione. Dobbiamo pertanto saperci convivere proprio come avviene in altri paesi evoluti, come il Giappone o la California, senza farci cogliere del tutto impreparati, come avveniva in passato.

La comunità scientifica internazionale allo stato attuale non ha ancora individuato un modello attendibile di predizione dei terremoti, pur essendo attivi promettenti filoni di ricerca basati sullo studio dei precursori sismici, anche mediante l’impiego di immagini telerilevate. Premesso ciò, il migliore approccio possibile da seguire consiste nella mitigazione del rischio sismico attraverso la corretta applicazione delle norme sulle costruzioni e l’adozione di criteri costruttivi tali da scongiurare il pericolo di crollo degli edifici, tenendo conto della mappa di pericolosità sismica del territorio nazionale – una delle più avanzate in Europa – e recependo gli studi di microzonazione sismica all’interno degli strumenti urbanistici comunali, in modo da disincentivare il più possibile l’edificazione nei siti potenzialmente oggetto di fenomeni di amplificazione locale. L’insieme di questi strumenti di rilevante importanza preventiva può essere inoltre utilizzato per trasmettere alla popolazione le nozioni di base del rischio sismico, ovvero una maggiore consapevolezza del fenomeno in modo da poterlo affrontare correttamente.

Diffondere informazioni scientifiche aggiornate e tali da consentire una conoscenza approfondita del territorio è il miglior strumento per avviare strategie di prevenzione e riduzione dei rischi naturali.

E quale occasione migliore per apprendere questi concetti, se non in tenera età? Assolutamente in questa direzione vanno alcune iniziative dell’INGV (Istituto Nazionale di Geofisica e Vulcanologia) finanziate dal Dipartimento nazionale della Protezione Civile. Mi riferisco in particolare al progetto EDURISK, nato circa una ventina di anni fa ad opera di un gruppo di ricercatori del GNDT (Gruppo Nazionale per la Difesa dei Terremoti, confluito nel 2001 nell’INGV), che coinvolge esperti nel settore dello studio e della riduzione dei rischi naturali, dei vari settori disciplinari attinenti (geologia, sismologia, pericolosità sismica, ingegneria sismica, sismologia storica, psicologia dell’emergenza), uno staff di progettazione educativa proveniente dall’editoria scolastica e multimediale, autori di libri per ragazzi, disegnatori, illustratori, fumettisti ed esperti di didattica. L’obiettivo principale del progetto EDURISK consiste nel mettere in campo i ricercatori, la scuola e tutti i cittadini, coinvolgendoli in un progetto di formazione e scoperta del rischio sismico. In particolare, il frutto di tale iniziativa consiste nella pubblicazione di libri, opuscoli e dvd a supporto del progetto formativo di diffusione delle conoscenze sul rischio sismico e vulcanico (materiale didattico). Il progetto è, inoltre, presente nei principali social network (Facebook, Twitter, Anobii e YouTube). Per ulteriori dettagli, si rimanda direttamente al portale del progetto. Di recente, EDURISK ha prodotto la docufiction “Non chiamarmi Terremoto”, che affronta temi quali la prevenzione, il rispetto per le norme sismiche e i comportamenti corretti da tenere in emergenza. Nel seguito, è possibile visionarne l’anteprima e questo è il sito dell’iniziativa.

Clicca qui per vedere il video incorporato.

D’altro canto, anche lo stesso INGV è presente su Twitter e YouTube. Nel primo caso si tratta di un servizio sperimentale di informazione sui terremoti in Italia (e non solo), mentre il canale su YouTube, molto interessante, prevede periodicamente degli aggiornamenti e la descrizione dell’attività sismica in corso, anche per spiegare alcuni aspetti della ricerca che viene svolta dai ricercatori dell’INGV.

Recentemente, qui su TANTO si scongiurava l’eventualità che il prof. Boschi, presidente dell’INGV, adottasse politiche restrittive sul rilascio dei dati di competenza dell’Istituto. E’ auspicabile, inoltre, che si continui nella direzione già abbondantemente tracciata nella diffusione capillare delle informazioni. Solo così si potrà contribuire efficacemente al raggiungimento di una sempre maggiore consapevolezza e conoscenza del fenomeno terremoto da parte dei ricercatori, dei tecnici e della popolazione.

L'articolo Una cultura diffusa di prevenzione e riduzione del rischio sismico è apparso originariamente su TANTO. Rispettane le condizioni di licenza.