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

Giovanni Mascellani g.mascellani at gmail.com
Fri Nov 28 23:01:39 GMT 2008


Il giorno gio, 27/11/2008 alle 11.50 +0100, Elena of Valhalla ha
scritto:
> anche OSM ha in un certo senso un sistema di "certificazione" di
> qualita`, nel senso che la qualita` dei dati e` controllata
> continuamente da tutti i contributori, con risultati che, per le zone
> coperte, sono empiricamente pari o addirittura migliori a quelli
> offerti dalle mappe comunemente disponibili al pubblico
> 
> quello che OSM non ha e` una _garanzia_ sulla certificazione, ovvero
> la possibilita` nel caso in cui i dati non corrispondano, di rifarsi
> economicamente su qualcuno

Io non ho idea di come sia l'offerta commerciale in merito a garanzie
sui dati geografici. Però Simone stesso ammetteva che in genere i dati
di qualità migliore disponibili sono quelli di OSM.

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

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!

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.

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

In ogni caso mi sembra che si ritorni all'impossibilità di avere
garanzie legali / economiche. Ma dato che tale impossibilità non mi
sembra eludibile, credo che sia meglio investire sulla capacità di
utilizzare dati inaffidabili, piuttosto che sulla necessità di avere
dati "affidabili".

Spero che qualcosa di quello che ho scritto sia utile!

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

Web: http://giomasce.altervista.org
SIP: g.mascellani at ekiga.net
Jabber: g.mascellani at jabber.org / giovanni at elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 315 bytes
Desc: Questa ? una parte del messaggio	firmata digitalmente
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20081129/a1893b9e/attachment.pgp>


More information about the Talk-it mailing list