Qualche giorno fa, mentre sperimentavo alcuni possibili usi pratici dell’applicazione web Bing Maps, mi sono imbattuto in un errore, di quelli apparentemente insignificanti, riguardante l’attribuzione di un toponimo: la SP4 “Strada Panoramica Valle dei Templi” ad Agrigento risultava erroneamente denominata “strada provinciale Serralombardi Scassabarile” (http://binged.it/1aBIn0Y ).
Preso inizialmente dalla curiosità, ho cercato di scoprire l’origine di tale errore o, quanto meno, di individuare la “reale” ubicazione della strada sunnominata.
Dopo alcune sessioni di ricerca attraverso i motori di ricerca di internet ho constatato, con un pizzico di sorpresa, che nella rappresentazione virtuale della toponomastica nazionale sono presenti diverse occorrenze della fantomatica strada provinciale “Serralombardi Scassabarile“.
Se si fosse trattato della via Roma o della piazza Garibaldi, non avrei ovviamente dato peso al fatto. In questo caso, però, la presenza di tante ricorrenze omonime su territori lontani tra loro (province di Pavia, Salerno, Taranto, Vibo Valentia, Brindisi, Foggia, Palermo, Agrigento, Ragusa, etc.) mi è parsa alquanto improbabile.
A questo punto, sono entrato in crisi: l’effetto scatenato in me da tale constatazione può essere forse paragonato a quello che si riscontra in alcuni personaggi pirandelliani, causato da dettagli apparentemente insignificanti (il setto nasale leggermente deviato in “Uno, Nessuno e Centomila”; il passaggio del treno nella novella “il treno ha fischiato” – per fortuna, ci tengo a precisare riguardo al caso mio, l’unico effetto prodotto sono state le considerazioni che ho cercato di esprimere in queste poche righe, senza trascendere oltre).
Come se già non bastasse la vasta schiera di filosofi, i quali con i loro ragionamenti hanno presentato diverse visioni, talora diametralmente opposte di ciò che consideriamo comunemente mondo reale. Adesso ci si mette pure la rete a mettere in crisi la percezione del mondo (per fortuna quello virtuale, in questo caso).
Lo so, non è la prima volta che uno, fidandosi del navigatore satellitare, finisce su un percorso morto o rimane incastrato con l’automobile in un vicolo del centro storico, ma in tali casi si tratta “solo” di carenza di dettaglio o di mancato aggiornamento.
La genesi, invece, dell’anomalia riguardante la Strada provinciale in questione sembrerebbe di tipo diverso: una strana “infestazione” che mette in luce le criticità di una immensa banca dati distribuita, generata e gestita senza regole precise e controlli non sempre efficaci.
Non voglio cimentarmi in tentativi di dare una spiegazione del perché o di come ciò possa avvenire, se tali “semi infestanti” siano introdotti volutamente da qualcuno (teorie complottiste, sabotaggio) o se, più probabilmente, si generino automaticamente per effetto di qualche criticità negli algoritmi che stanno alla base dei motori di ricerca o di popolamento automatizzato delle grosse banche dati: non ne ho le competenze.
Provo, invece, a saltare alle conclusioni, a trovare una morale: qual è l’approccio giusto che dobbiamo avere riguardo alle informazioni che internet ci fornisce?
Ritengo che dobbiamo abituarci a passare da una concezione deterministica ad una probabilistica, prendere coscienza che ogni notizia o informazione ha un suo grado di attendibilità, teoricamente variabile dal valore “0″ (le cosiddette “bufale” e i macroscopici “strafalcioni”) al valore “1″ (informazioni assolutamente veritiere – ma esistono davvero?).
Per poterci orientare correttamente e valutare autonomamente tale grado di attendibilità dobbiamo quindi adottare strategie quali, ad esempio, la consultazione di più fonti (da valutare anch’esse).
Al contempo, tuttavia, non bisogna esagerare, per non rimanere invischiati o troppo rallentati nel tentativo di ricercare la certezza assoluta, che rappresenta, in tale approccio probabilistico, un limite non sempre raggiungibile.
Ma poi, in fondo, chi se ne frega se qualcuno ha sbagliato il nome: a me basta passare da quelle parti al tramonto e godermi lo spettacolo.

Tempio di Giunone Lacinia presso la Valle dei Templi di Agrigento

Tempio di Giunone Lacinia nella Valle dei Templi di Agrigento | fonte  http://www.lavalledeitempli.net


Ho molto pensato se scrivere o no queste poche righe, perché potrebbe sembrare che lo facessi per “sponsorizzare” un progetto che a me piace; alla fine ho deciso che in ogni occasione ci sono i maligni e quelli in buona fede e così vi invio queste mie considerazioni, pensando che apparteniate alla seconda categoria.

Sono più di tre anni che uso geopaparazzi, cioè fin dalla sua nascita con i suoi bachi e i suoi problemi. Mi sento onorato di aver contribuito allo sviluppo di questo software, sia pure in modo passivo, nel senso che non ho scritto neppure una linea di programma ma ho testato il software in lungo e in largo per i miei bisogni di turista fai da te.

Due anni fa, durante una vacanza in un’isola greca con mia moglie, seguendo con la cartina del luogo un sentiero segnato male ci siamo persi.

Fortezza di Antimachia a Karadameno, Isola di Kos. Geopaparazzi su HTC Wildfire.

Fortezza di Antimachia a Karadameno, Isola di Kos. Geopaparazzi su HTC Wildfire.

Erano le tre del pomeriggio e c’era il sole, ma … fortunatamente avevo scattato molte foto e aiutandomi un po’ con le immagini e un po’ con il ricordo dell’orografia del luogo riuscimmo, per altra via e con tre ore aggiuntive, a ritornare al luogo di partenza. Mi dissi: mai più dovrà ripetersi un caso analogo!

E da quel giorno geopaparazzi mi segue ovunque.

Vi scrivo alcuni accadimenti banali, ma credo significativi, per far capire ai vostri lettori eventualmente interessati come sia utile questo strumento.

  • Mia moglie ed io per i nostri viaggi ci affidiamo regolarmente al sito booking.com. Di solito sono abbastanza precisi, ma… vi lascio intendere dalla email che mia moglie ha mandato al sito durante le vacanze:

“Gentili Signori, siamo utenti di booking.com e abbastanza soddisfatti del servizio che viene riservato. Tuttavia abbiamo un’osservazione da fare: essendo dotati di GPS per rintracciare agevolmente la struttura dove andremo a pernottare, abbiamo rilevato che le strutture alberghiere a Kalymnos -vedi hotel Panorama- ed a Astypalaia  -vedi studio Ixthioessa- ma anche altre di cui abbiamo verificato la posizione (vista mare studios: sulla vostra mappa è segnalato in collina ed invece è a un centinaio di metri dal porto), sono segnalate nelle vostre mappe a distanze variabili da 500 a 1000 metri rispetto alla posizione reale. E’ importante che le coordinate GPS corrispondano alla posizione reale della struttura perchè è anche in base alla posizione della stessa che si fa la scelta.
Ixthioessa ad Astypalaia: sulla Vs. mappa: lat 36.54874  lon 26.35278  a noi risulta lat: 36.54978 lon: 26.35557
Vi chiediamo di verificare e rettificare le posizioni.
Cordiali saluti luciana a.”

  • Quest’estate ero a cercar funghi con un gruppo di amici; all’ora di tornare alla base l’opinione sulla via del ritorno da prendere non era esattamente condivisa: alcuni dicevano “di qua” altri “di là”. Prendemmo una delle due direzioni e, fatti pochi metri, il mio amico geopaparazzi mi mostrò che la direzione era sbagliata. Ovviamente la rettifica fu immediata e alcuni amici si mostrarono interessati a quello strumento.

Al ritorno verso l'albergo, guidati da geopaparazzi, nella Barcellona notturna.

Al ritorno verso l’albergo, guidati da geopaparazzi, nella Barcellona notturna.

  • Ero in ferie con mia moglie a Barcellona (ebbene sì, sono spesso in giro perchè sono in pensione da dodici anni ormai) per la prima volta, e visitando la città è difficile rendersi conto di quanto passi velocemente il tempo se non quando si accendono le illuminazioni stradali e improvvisamente ci si sente sperduti. Naturalmente in una città non c’è rischio di perdersi (taxi e indirizzo dell’albergo risolvono tutti i casi) ma l’idea di vedere anche aspetti della città notturna ci piaceva e così ci permettemmo una serata tarda in luoghi qualsiasi con la certezza che geopaparazzi ci avrebbe riportati a casa. In albergo mia moglie mi disse “regala 50€ per una pizza a chi ha sviluppato quel marchingegno (proprio così disse: marchingegno!)” e così feci: non succede spesso che una donna apprezzi così apertamente certa tecnologia ….
  • Un amico camminatore con poca esperienza delle montagne del meranese mi chiese un giorno di indicargli un bel percorso in alta quota. Stavo per raccontargli una delle mie gite, quando mi venne l’illuminazione. “che cellulare hai?” gli chiesi. Mi fece vedere un HTC. “Magnifico” dissi. E gli spiegai come scaricare Geopaparazzi, come vedere i percorsi in Google Earth, ecc. ecc.. “Ti manderò via e-mail le istruzioni per usare quel software insieme al file del percorso che stavo per raccontarti. Se avrai problemi, telefonami”. Ci lasciammo così e gli inviai quanto promesso. Era un mercoledì (lo ricordo perchè la storia è recente) e il lunedì successivo mi arrivò una sua e-mail carica d’entusiasmo sia per il luogo visto che, soprattutto, per la semplicità con cui aveva potuto seguire il percorso.

Potrei raccontare ancora per molto, ma credo di aver superato il limite di tolleranza di ogni buon lettore “scientifico”.

Nel frattempo il mio hardware si è evoluto. L’HTC era troppo lento e spesso “crashava” per la mia impazienza a spostare le mappe sul monitor. In giugno 2013 mi sono regalato un Samsung Galaxy Note2 N7100: una bomba!!! Ci ha accompagnati ad Astypalea (Grecia) senza un attimo di incertezza. Sarà la ns. guida fino a quando… non sarà diventato troppo lento anche lui.

Ci sono ancora alcune cose che mi piacerebbe veder fare a geopaparazzi ma mi rendo conto che non posso sempre chiedere e mai dare. Sono sicuro, tuttavia, che l’autore di geopaparazzi continuerà, come nel passato, a curare lo sviluppo e la manutenzione di questo software che ormai chiamo “geofriend” e prima o poi i miei desideri saranno esauditi perchè saranno diventati necessità per molti.

Per finire un consiglio ai turisti fai da te: è sempre bene viaggiare anche con una cartina della zona, oltre che con geopaparazzi: qualche volta batterie e/o satelliti giocano brutti scherzi…

Grazie per l’ospitalità sul Vostro guest post e per la vostra attività su TANTO.

 


La nostra lingua è molto bella e difficile e la parola ospite ne è un esempio. Viene dal latino hospes e ha significati in qualche modo tra loro opposti, in quanto la parola alludeva soprattutto ai reciproci doveri dell’ospitalità. Ci sono anche altri significati.
In geologia quelli “nordici” sono “i fossili esistenti nelle basse latitudini in seguito a migrazione di fauna dalle zone artiche, in concomitanza alle fasi di espansione glaciale del pleistocene”.
In embriologia è “l’individuo sul quale viene effettuato un trapianto“.
Ed infine in zoologia, “la specie a spese del quale vive un parassita” (per tutti i dettagli, Treccani)

Quali ospiti in TANTO? Gli ultimi non li vorremmo, ma non possiamo essere certi di non incontrarne. Esistono, purtroppo, e non si riconoscono sempre; proveremo a tenerli lontano.

Ci piacerebbe accogliere persone provenienti da altre latitudini di esperienza, che vogliano migrare una tantum in questo territorio con il proprio bagaglio di idee, saperi, professionalità e umanità. Vorremmo ricevere il trapianto di organi per noi nuovi e sconosciuti, ma andranno bene anche altri cervelli, cuori, stomaci e soprattutto occhi, che sapranno guardare vicino e lontano.

Aprire TANTO agli ospiti è un desiderio che abbiamo da tempo, ma è un po’ come quando ci si trova davanti una porta insieme a persone molto gentili: “Vada lei”, “No prego passi lei”, “Ma ci mancherebbe faccia lei il primo passo”, “Guardi insisto è per me un piacere”, ecc.. Finalmente facciamo questo passo.

Qual è l’obiettivo? Banalmente migliorare la qualità dei contenuti. Se ci riusciremo i benefici saranno diversi:

  • Nuove prospettive – Ogni autore porterà il suo punto di vista unico;
  • Nuovi lettori – Ogni autore porterà con sé i propri temi e la propria storia, e inevitabilmente arriveranno nuovi utenti interessati;
  • Nuove connessioni – Con il nuovo ospite si creerà un rapporto nuovo e questo faciliterà le possibilità di fare reciprocamente rete.

Gli ospiti saremo anche noi, nel significato primo della parola, e sarà nostro compito accogliere al meglio in casa le persone che vorranno lasciare un piccolo (e grande) segno qui.

Per proporci un’idea di articolo, inviate un’email al nostro indirizzo di redazione – tanto@spaziogis.it – con l’oggetto “Ospite in TANTO”. Vi risponderemo indicandovi le modalità di partecipazione.

Abbiamo già alcuni guest post in cantina e da tempo. Il primo che verrà pubblicato sarà proprio di un ospite nordico a noi molto vicino, così tanto che un po’ ci emoziona e commuove. Ma visto che è un’avventura nuova anche per noi, è stato quasi naturale iniziare in “famiglia”.

Grazie a chi vorrà cambiare qualche volta latitudine ;)

2013-10-31_17h49_43a


assorpasASSORPAS, l’associazione italiana per i light RPAS annuncia il suo primo workshop nazionale dl titolo La filiera degli APR: criticità ed opportunità del contesto italiano

Gli RPAS (Remotely Piloted Aircraft Systems) altro non sono che i piccoli droni, sempre più diffusi in ambito geomatico. In Italia ENAC li ha denominati APR (Aeromobili a Pilotaggio Remoto). Il workshop si terrà a Roma il prossimo 13 novembre presso il Centro Convegni iCavour.
La manifestazione si svolgerà nell’imminenza del rilascio da parte di ENAC delle norme che regolamenteranno le attività nel nostro paese.
A testimonianza dell’interesse dell’argomento, al workshop è stato concesso il patrocinio di ASITA, AMFM Italia e SGI.

Banner sponsor

La partecipazione è gratuita anche se, a causa del numero limitato di posti disponibili, è richiesta una registrazione via web. Ulteriori informazioni ed aggiornamenti a questa pagina del sito ASSORPAS.
Di seguito il testo del comunicato diffuso da ASSORPAS per annunciare il workshop.

 ______________

 

banner-convegno_tanto

Carissimi amici,

ad un anno dalla sua fondazione, ASSORPAS  organizza un workshop nazionale, aperto a tutti, sullo stato e le prospettive della filiera italiana.

Il workshop si tiene in un momento particolarmente delicato per il futuro del settore, caratterizzato dall’attesa per il rilascio del Regolamento Mezzi Aerei a Pilotaggio Remoto e dall’incertezza su come le nuove norme modificheranno un mercato nato spontaneamente in un contesto privo di regole specifiche.

Un quadro normativo chiaro rappresenta infatti un formidabile elemento di sviluppo e regolazione del mercato ed è importante che esso unisca esigenze legate alla sicurezza a criteri che preservino i punti di forza degli APR nei confronti delle piattaforme aeree tradizionali.

Oltre a costituire occasione di presentazione al pubblico dell’Associazione e delle sue linee strategiche, l’incontro ha lo scopo di delineare un quadro aggiornato della situazione nazionale individuandone le principali criticità, i punti di forza e le prospettive a breve e medio termine.

I principali temi affrontati saranno:

  • la normativa nazionale,
  • la valenza economica della filiera,
  • i principali ambiti applicativi,
  • gli aspetti legali ed assicurativi dell’attività con APR,
  • la percezione e la valenza sociale degli APR.

L’incontro, che prevede relazioni a invito (tra cui quella di ENAC sullo stato del Regolamento) e una tavola rotonda, vedrà la partecipazione di figure provenienti sia dalle componenti interne alla filiera degli APR (produttori di sistemi, di sottosistemi e sensoristica, operatori di servizi) che di quelle ad essi intimamente connesse (operatori assicurativi, mondo accademico, fruitori di servizi).

Il programma di massima è il seguente:

14.00 – 14.30 – Registrazione dei partecipanti
14.30 – 14.45 – Paolo Marras (Presidente ASSORPAS) – Intervento di apertura
14.45 – 15.15 – Ing. Carmine Cifaldi (ENAC)
15.15 – 15.30 – Domande
15.30 – 16.00 – Interventi a invito
16.00 – 16.30 – Coffee break
16.30 – 17.30 – Tavola rotonda sulle prospettive del settore APR, modera Emil Abirascid

E’ richiesta la registrazione via web e, considerata la densità del programma, si richiede la massima puntualità. Ulteriori aggiornamenti sul programma saranno forniti attraverso il sito ASSORPAS.

Un cordiale saluto a tutti

Paolo Marras
Presidente ASSORPAS


MySQL è uno dei più diffusi database server, e non deve stupire che abbia un’estensione spaziale (peraltro attiva di default). Mi stupisce però che le funzioni per testare le relazioni spaziali tra oggetti siano limitate.

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 PostGISOracle 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.

sqlite dialect vs MySQL source

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 :)

NDR: Jukka Rahkonen, uno sviluppatore di GDAL/OGR, mi fa notare che dalla release in trunk r26506 di GDAL e a partire dalle future release stabili ufficiali, non sarà necessario creare alcun file virtuale. Si potrà accedere direttamente alla sorgente MySQL e impostare la proprietà “-dialect” al valore “SQLITE”.


TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.