[Gfoss] Utilizzo dei dati OSM per fini operativi in ambito di gestione dei disastri e delle emergenze

[Giovanni Mascellani]

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.

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

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?

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.

> 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?

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

> 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?

> 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!

Ciaociao, Gio.
-- 
Giovanni Mascellani <g.mascellani a gmail.com>
Pisa, Italy

Web: http://giomasce.altervista.org
SIP: g.mascellani a ekiga.net
Jabber: g.mascellani a jabber.org / giovanni a elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        non disponibile
Tipo:        application/pgp-signature
Dimensione:  315 bytes
Descrizione: Questa è una parte del messaggio	firmata digitalmente
URL:         <http://www.faunalia.com/pipermail/gfoss/attachments/20081201/60356f96/attachment-0001.pgp>