Concordo con quello detto da Giovanni, ma aggiungo qualche commento > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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
<<attachment: winmail.dat>>
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it