[Talk-it] R: Utilizzo dei dati OSM per fini operativi in ambito digestione dei disastri e delle emergenze

[Fabrizio Carrai]

Concordo con quello detto da Giovanni, ma aggiungo qualche commento

> -----Messaggio originale-----
> Da: talk-it-bounces at openstreetmap.org
> [mailto:talk-it-bounces at openstreetmap.org]Per conto di Giovanni
> Mascellani
> Inviato: sabato 29 novembre 2008 0.02
> A: openstreetmap list - italiano
> Oggetto: Re: [Talk-it] Utilizzo dei dati OSM per fini operativi in
> ambito digestione dei disastri e delle emergenze
> 
> 
> Il giorno gio, 27/11/2008 alle 11.50 +0100, Elena of Valhalla ha
> scritto:

[...]
> 
> Stante questa situazione, credo che a questo punto la cosa migliore sia
> cercare di capire cosa può essere meglio per le applicazioni di cui hai
> bisogno. In particolare, devi capire se è proprio vero che avere dati
> non garantiti è come non averli. Tu stesso dicevi su gfoss.it (e mi
> sembra del tutto logico) che lavorando in situazioni di emergenze si sa
> che non si è in condizioni ottimali, e che quindi i dati a disposizione
> potrebbero non essere perfetti, che serve un po' di flessibilità.
> 
> Non so come vanno queste cose, ma ho la sensazione che, comunque, avere
> dei dati non del tutto affidabili sia meglio che non averne per nulla,
> se non altra per rendersi conto della situazione (a patto che si sappia
> che i dati potrebbero essere sbagliati, e quindi ci si regoli di
> conseguenza). 

Penso che in queste situazioni è importante CONOSCERE IL LIVELLO DI
CONFIDENZA che si ha con i dati, qualunque esso sia: nullo, basso, discreto,
totale, certificato da un ente esterno, etc...
Il personale che opera in emergenza può quindi regolarsi di conseguenza. Per
confidenze basse prenderà i dati solo come pura indicazione, prestando
massima attenzione all' impostazione dell'operazione.
In caso di dati affidabili, la loro concentrazione potrà essere rivolta
altrove.

> Inoltre, tipicamente in una situazione di emergenza i dati
> geografici cambiano, indipendentemente dal fatto che siano garantiti o
> no. E, come sottolineava EdoM su gfoss.it, si può assumere che i dati
> siano inaffidabili fino alla prima volta che ci si passa e si controlla
> se sono giusti o no.

E' il classico caso delle emergenze in caso di disastri ambientali:
terremoti, smottamenti od altro possono cambiare l'assetto (magari
certificato)  del giorno prima.

> 
> Più in generale, quando bisogna lavorare in cattive condizioni credo che
> ogni cosa possa essere d'aiuto, compresi dati non certificati. In questa
> prospettiva è importante sapere che i dati potrebbero essere sbagliati,
> ma questo non equivale a mettere un disclaimer. Equivale piuttosto ad
> avere persone formate a lavorare in condizioni di emergenza e capaci di
> valutare il da farsi a partire dalle informazioni che hanno, cose che mi
> auguro sia un requisito al quale si presti attenzione nell'ambito che
> descrivi.
> 
> Non so se quello che ho detto si adatta alla tua situazione, perché
> forse non l'ho intesa bene.
> 
> > > [...]
> > > Pensate possa esserci una soluzione per uscire da questa 
> situazione? Ogni
> > > suggerimento/commento e' benvenuto.
> > 
> > tempo fa su questa mailing list sono state fatte alcune proposte,
> > tipicamente incentrate sul blocco delle modifiche di aree o vie
> > considerate "finite": lo svantaggio di queste proposte e`
> > fondamentalmente che ostacola il processo naturale di controllo di
> > molti tipico di OSM e di conseguenza potrebbe perfino peggiorare la
> > qualita` globale dei dati
> 
> Secondo me l'idea di bloccare delle zone è sbagliata, perché snatura il
> fondamento di libertà che c'è nel progetto. Su Wikipedia alcune volte si
> bloccano delle voci, ma questo in genere (per quanto ne so io) avviene
> per gravi motivi, ad esempio reiterate violazioni di NPOV, frequenti
> abusi o discussioni particolarmente feroci. Sarebbe bello evitarle su
> OSM, visto che noi non dovremmo avere particolari problemi di NPOV!

Invece che a "bloccare" o "osservare" una zona, si potrebbe pensare ad un
tag di "Grado di affidabilità" ?
Ogni contribuente in grado di confermare la correttezza di un dato può
andare ad aumentare l' indice di cui sopra.
Decrementi dell' indice indicherebbero dubbi sulla validità dell'
informazione.


> 
> L'idea però non è del tutto da buttare, secondo me: l'inserire dei
> metadati di gestione del progetto è in realtà una buona idea, che
> meriterebbe di essere implementata e sfruttata. Piuttosto che marcare
> una zona come "bloccata" sarebbe meglio marcarla come "osservata" da
> qualcuno, il che vuol dire che quel qualcuno si impegna a controllare
> che non succedano cose strane. Un programma automatico lo avvertirebbe
> (c'è già qualcosa che fa questo passaggio[1]) e lui si impegna a
> controllare entro un tempo ragionevole le modifiche e intervenire nel
> caso ci fosser problemi.
> 
>  [1] http://www.itoworld.com/product/osm
> 
> Ovviamente questo non aggiungerebbe responsabilità legali né al progetto
> né all'osservatore, ma il fatto di avere queste informazioni
> permetterebbe di capire su quali aree verosimilmente si può fare
> maggiore affidabilità e su quali meno (una stima di quanto un
> osservatore sia affidabile si può fare sul numero dei suoi edit, ma
> forse si possono inventare anche criteri migliori).
> 
> > secondo me due possibilita` sono:
> > 
> > * un fornitore di dati certificati basati su OSM, che si fa pagare per
> > il servizio e di conseguenza e` reponsabile economicamente in caso di
> > dati sbagliati
> 
> Credo che questa sarebbe la panacea per Simone. Il grosso problema è
> trovare qualcuno che sia disposto a garantire.

Vedi sopra: sarebbe la community stessa a farlo.
> 
> > * un sistema di produzione di snapshot stabili, sempre controllati
> > dalla comunita`, sulla quale ci sia ragionevole certezza di non avere
> > errori grossolani inseriti malevolmente, ma nessuna garanzia ne'
> > assunzione di responsabilita` economica
> > 
> > * l'uso dei dati cosi` come sono, dopo aver controllato personalmente
> > l'assenza di errori grossolani, contando sul sistema attuale di
> > controllo
> 

[...]

	Fabrizio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5040 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20081130/369ea7e6/attachment.bin>