-----Original Message-----
From: Giovanni Mascellani [mailto:g.mascellani@gmail.com]
Sent: 01 December 2008 21:14
To: gfoss@faunalia.com; Simone Gadenz
Subject: Re: [Gfoss] Utilizzo dei dati OSM per fini operativi in ambito di gestione dei disastri e delle emergenze
Scusami, probabilmente io non sto capendo bene quale è la tua posizione in tutto questo.
Il giorno lun, 01/12/2008 alle 14.24 +0100, Simone Gadenz ha scritto:
Condivido con voi il pensiero che nessun produttore di dati certifica
cio' che vende al 100% e che anche TA e similari hanno disclaimer.
Quando noi creiamo una mappa, scriviamo nel disclaimer che I dati sono
TA, sta a Teleatlas tutelarsi per eventuali problemi che nascono da
quelli. In questo caso siamo comunque sicuri che chi ha raccolto dati
non aveva nessun interesse a introdurre degli errori per influenzare
operazioni di soccorso, ed inoltre non essendo modificabili fa si che
una volta verificati per una zona non si debbano ricontrollare di
nuovo la volta successiva.
Non credo che Teleatlas debba tutelarsi da un bel niente, perché non ha fornito alcuna garanzia nei dati. Per cui distribuire dati come buoni perché sono stati messi in piedi da Teleatlas non ti protegge da nessuna lamentela che potresti avere.
Inoltre, è secondo me del tutto arbitrario ammettere che i dati siano corretti solo perché sono stati forniti da Teleatlas. Ci possono essere sia easter egg (errori volontari fatti per scoprire le copie di dati) che errori o trascuratezze di Teleatlas nel rilevamento.
NESSUNO DICHIARA CHE I DATI SIANO CORRETTI DA NESSUNA PARTE. DICHIARA CHE I DATI SONO TELEATLAS O SIMILARI. lORO HANNO I PROPRI DISCLAIMER E/O MECCANISMI DI PROTEZIONE DA LAMENTELE O PROCEDIMENTI LEGALI.
I MECCANISMI DI CONTROLLO DI TELEATLAS DI SICURO NON SONO IL TIPO DI ERRORI CUI MI RIFERIVO, NON CREDO CHE L'ERRORE DI TELEATLAS SIA STATO INSERITO UN ANNO FA CON L'INTENTO DI INFLUENZARE I MOVIMENTI DI UN CONVOGLIO DI VIVERI O DI UN TEAM DI SOCCORSO O DI UNA PATTUGLIA IN UNA ZONA COLPITA DA DISASTRO O IN UN'AREA DI CRISI. SU OSM QUESTO E' POSSIBILE.
Concordo su l'opinione chee persone in ambito di disastro sappiano
come muoversi e siano abituati a lavorare in un clima di incertezza.
I dati OSM sono per loro disponibili dal sito OSM e quindi sono in
grado di recuperarli e usarli a loro discrezione.
Spesso in questo scenario I team contribuiscono attivamente a
integrare I dati su OSM, anzi dalle esperienze che conosco sono gli
unici dati OSM di cui gran parte delle missioni in "zone pericolose"
si fidano. Questo e' l'approccio utilizzato in zone come WestBank,
Iraq, etc...
Questo e' una cosa che pero' non permette di utilizzare I dati di zone
dove si va per la prima volta.
Beh, si può fare, a patto di prendere questi dati con le molle. Del resto, se sono gli unici dati disponibili, è meglio che niente.
CERTO, QUESTI SONO DISPONIBILI AI TEAM DIRETTAMENTE CHE SE VOGLIONO LI USANO SENZA BISGONO DEL NOSTRO INTERVENTO
Ma, come dicevo all'inizio, forse mi è poco chiara la tua posizione: tu devi cercare dei dati in generale che possano essere utilizzati in missioni di soccorso, oppure, assunto che dati non certificati si possono trovare in ogni caso, hai strettamente bisogno di dati certificati in qualche modo (in modo da poter assorbire eventuali denunce, danni di immagine e assimilabili), e quindi è questo che stai cercando di capire come fare?
LA MIA POSIZIONE E' QUELLA PER CUI DEVO CERCARE DATI CHE POSSANO ESSERE UTILIZZATI PER SUPPORTO A EMERGENZE. PER NOI, E RIPETO PER NOI, AVERE UNA 'CERTIFICAZIONE' SU QUESTI DATI E' UN REQUISITO. I NOSTRI PRODOTTI HANNO LA NOSTRA CERTIFICAZIONE E VUOL DIRE CHE CREDIAMO IN TELEATLAS MA NON IN OSM ALLO STATO ATTUALE
In quest'ultimo caso la soluzione è semplice, ossia difficile: devi trovare qualcuno che te li certifichi (OSM non lo può fare, e dubito che con Teleatlas la cosa sia semplice). Ma non credo ci sia tanta gente disposta a farlo.
Nel primo caso, i dati ci sono e sono pronti (forse si può anche confrontare i dati attuali con lo storico nel database, per capire se ci potessero essere stati recenti vandalismi). Chi li usa deve sapere che non sono del tutto affidabili. Non riesco a capire se questa è una soluzione del tuo problema o no, oppure se stai cercando una soluzione migliore.
QUESTO ERA PROPRIO IL PUNTO. LA DOMANDA E' SE OSM, GODENDO DI FINANZIAMENTI, POTESSE CREARSI UNA STRUTTURA DI CONTROLLO E MODERAZIONE.
Sono anche daccordo che uno dei valori aggiunti di OSM sia la
possibilita' di collaborare e migliorare il database in tempo reale.
Una struttura colalborativa testata e funzionante a disposizione degli
utenti. Ma questo vantaggio e' allo stesso tempo un limite per la
sicurezza.
Forse è vero, ma probabilmente si tratta dell'unica soluzione possibile.
Il nostro contesto e' leggermente diverso:
- prendiamo I dati di OSM di un'area che non conosciamo
- li integriamo con altri dati o con informazioni in tempo reale
(news, messaggi dal campo, tracce GPS, ecc)
- li usiamo per fare situazion maps o logistic maps sulle quali
apponiamo il nostro logo e quindi la nostra certificazione.
- mandiamo queste mappe in giro e vengono utilizzate dai team ma poi
finiscono nelle mani di politici, giornalisti, etc.
Perché questo è un problema?
PERCHE' CERTIFICHIAMO IL PRODOTTO DERIVATO MA NON VOGLIAMO CERTIFICARE I DATI. ALLO STESSO TEMPO NON VOGLIAMO SCRIVERE, EHI GUARDATE VI DIAMO QUESTA SITUATION MAP MA POTREBBE ESSERE ANCHE UNA GRANDE CAGATA.
In questo scenario siamo noi che dobbiamo capire quanto I dati siano
buoni, ed e' quello che facciamo con le fonti che abbiamo a
disposizione. In alcuni casi non abbiamo proprio possibilita' di farlo
e non possiamo contare su dati dei quali non conosciamo pressoche'
niente o di cui non e' possibile certificare l'origine. In entrambe I
casi non possiamo accollarci il rischio di certificare dati che non
consociamo. Quindi il discorso della certificazione dal nostro punto
di vista non sarebbe un modo di rendere I dati migliori su OSM, ma di
renderli per noi utilizzabili in tutti I contesti.
Ancora non sono sicuro di aver capito bene: vuoi dire che il meccanismo che hai detto prima andrebbe bene soltanto in alcuni casi, cioè quando avete la possibilità di controllare i dati prima, giusto? Ma non mi è chiaro in quali contesti un team di soccorso abbia la possibilità di controllare i dati geografici che sfrutti prima di andare in missione.
AREE MAPPATE IN PRECEDENZA, O CONTROLLATE IN PRECEDENZA, O MAPPATE DA ORGANIZZAZIONI PER NOI AFFIDABILI, O DERIVATE DA IMMAGINI SATELLITARI AGGIORNATE, O CONTROLLATE IN PRECEDENZA DA CONTATTI CHE MANTENIAMO SUL TERRITORIO,ECC...
Stiamo discutendo con alcuni membri di OSM italia su una possibile
soluzione da implementare entro il prossimo anno. L'idea di base e'
quella di avere un subset di dati isolato dalla comunita' online per
gestire l'emergenza. I dati aggiornati sarebbero resi disponibili alla
comunita' a emergenza finita.
Di nuovo non capisco come mai abbiate necessità di mantenere dei dati isolati dalla comunità (per altro, perdendo gli aggiornamenti che nel frattempo la comunità potrebbe costruire). Perché c'è bisogno di segretezza durante una missione? Ma sopratutto il vero problema è: come potrebbe questo risolvere il problema della certificazione?
SI UNO DEI PROBLEMI E' LA SEGRETEZZA DEI DATI, DURANTE L'EMERGENZA CI SONO INFORMAZIONI CHE NON POSSONO ESSERE RESE PUBBLICHE PER UN'AMPIA SERIE DI MOTIVI. L'ALTRO E' LA CERTIFICAZIONE ALL'ORIGINE DEL DATO. SOLO UTENTI CHE CONOSCIAMO, CHE ABBIAMO FORMATO POSSONO INSERIRE I DATI E QUESTO RENDE I DATI AFFIDABILI E CREDIBILI.
Se qualcuno ha idee o suggerimenti e' il benvenuto alla discussione.
Ci provo! Trovo veramente grande motivo di orgoglio per OSM ed in generale per i dati liberi che siano praticamente l'unica possibilità in molti casi per gestire situazioni difficili e molto importanti, per cui mi piacerebbe trovare la soluzione migliore per farlo!
BENE! TI TENGO AGGIORNATO CON GLI SVILUPPI.
Ciaociao, Gio.
--
Giovanni Mascellani <g.mascellani@gmail.com> Pisa, Italy
Web: http://giomasce.altervista.org
SIP: g.mascellani@ekiga.net
Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70)
