[Gfoss] Libro Bianco per il riutilizzo dell'informazione del settore pubblico

a.furieri a lqt.it a.furieri a lqt.it
Gio 26 Apr 2012 14:06:15 CEST


On Wed, 25 Apr 2012 08:35:11 +0200, Andrea Peri wrote:
> Oppure l'orario dei tram per favorire la vendita di gelati ....
> A quale orario pensa ? Quello salvato nel fogli excel di chi ha
> progettato i tragitti
>

giusto per la precisione: magari bastasse semplicemente un foglio excel
(o equivalente o.s. per non discriminare nessuno) per descrivere 
decentemente
gli orari degli autobus e dei treni :-D
serve piuttosto una marea di dati altamente strutturati, in parte 
tabellari
(orari, calendari) ma in parte anche georeferenziati (posizione delle 
fermate,
rappresentazione dei percorsi).
se non ricordo male, p.es. per descrivere tutta la rete ferro+gomma 
della
Toscana servono diverse decine di GB di dati.

normalmente si usano schemi XML abbastanza complessi: purtroppo non 
esiste
uno standard vero e proprio, o meglio, ne esistono un paio ma sono 
troppo
complicati/astratti e non hanno incontrato buona accoglienza da parte
delle aziende che gestiscono l'esercizio.
un modello dati ragionevole (forse un po' troppo semplificato, ma 
largamente
adottato proprio perche' semplice) e' quello definito da Google 
Transit:
https://developers.google.com/transit/gtfs/reference


> ... e che mai corrisponde al vero perche' sulle
> strade no circolano solo i tram , ma anche tanti altri mezzi
> e vuoi per incidenti, vuoi per traffico, i ritardi sono all'ordine 
> del
> giorno ?
>

questo e' il cosiddetto "orario programmato"; normalmente e' quello 
piu'
largamente utilizzato, proprio perche' e' il modello dati piu' semplice
da gestire praticamente.
ok, non e' il vangelo: ma in condizioni di esercizio normali, ed in
assenza di eventi eccezionali (scioperi, manifestazioni, catastrofi)
e' comunque una base di partenza molto ragionevole e realistica.

considera che in genere i mezzi urbani sono "a frequenza", quindi non
e' tanto rilevante sapere che il bus passa esattamente alle 11.32; il
dato rilevante e' che su quella linea (in media) hai un transito ogni
4 minuti piuttosto che ogni 30 minuti.
i servizi extra-urbani hanno cadenze molto piu' sporadiche: ma soffrono
anche molto meno della congestione del traffico (almeno, in media).


> Oppure a un orario prodotto al volo da un sistema che collegandosi al
> satellite, riceve via GPS la posizione, sulla base della posizione e
> conoscendo la posizione di tutte le altre macchine che circolano,
> calcola al volo il tempo necessario a percorrere il tragitto e ti fa'
> sapere che tra 7 minuti e 23 secondi arriva, per cui puoi comprare il
> gelato oppure bere un caffe. Non puoi mangiare un panino perche' 
> forse
> non ce la farai a terminarlo ?
>

andrea, non e' fantascienza ...
i cosidetti sistemi AVM fanno proprio questo: a bordo di ciascun mezzo
c'e' una centralina GPS, che ogni tot secondi rileva le coordinate e
le trasmette in centrale: spesso inviando un banale SMS
dopo di che in centrale vengono determinati anticipi e ritardi rispetto
al pianificato.
i sistemi piu' sofisticati addirittura sono agganciati in real-time
ad un modello matematico di simulazione del traffico, che si ricalibra 
in
continuazione in base ai ritardi rilevati (insomma, e' il bus stesso 
che
diventa un sensore viaggiante che permette di rilevare ingorghi, 
deviazioni
impreviste etc)

alcune reti urbane si sono attrezzate gia' da oltre dieci anni: p.es. 
proprio
Firenze (se non erro, ATAF e' stata la prima azienda in Italia a 
dotarsi
di un sistema AVM, gia' a partire dalla fine degli anni 90).

il problema vero non e' affatto tecno-informatico: e' piuttosto che poi
comune, provincia, regione, aziende di trasporto, vigili urbani etc 
faticano
a riuscire a costruire una rete efficacemente integrata (e quindi 
realmente
utile per qualsiasi scopo pratico).
proprio perche' ciascuno tende a tenersi belli stretti e sotto chiave i
propri dati, acquisiti con tanta paziente fatica e con onerosi 
investimenti.

Regione Toscana e' stata la prima in Italia (ed una delle prime in EU)
a gestire tutti gli orari pianificati sull'intero territorio regionale,
fin dai primi anni 2000: il sistema RT ha iniziato ad essere 
pubblicamente
consultabile su Google Transit fin dal 2009. e per quanto mi risulta 
sono
in corso svariate iniziative per riuscire finalmente a coprire tutto il
territorio regionale con un unico sistema AVM integrato.

quindi il problema non e' tanto la carenza di dati: i dati ci sono, 
sono
gia' di qualita' elevata, e potrebbero addirittura diventare di 
qualita'
"fantascientifica" nei prossimi anni.
anche i terminali ci sono gia': qualsiasi smart-phone con capacita' di
posizionamento GPS potrebbe integrarsi in mille modi in questo 
contesto,
sia come fruitore di informazioni (condizioni traffico, disponibilita'
parcheggi, orari bus+treno, pianificazione percorsi calibrata sulle
condizioni reali etc) ma anche come "sensore mobile".

a me pare piuttosto che il problema "vero" e' che fino a quando tutta
questa impressionante miniera di informazioni non viene liberamente 
messa
a disposizione di tutti, in modo tale da consentire un'integrazione 
efficace
e tempestiva, ben difficilmente possiamo sperare che nasca un qualsiasi 
tipo
di mercato indotto.

IMHO se mai esiste un esempio evidente di come sia proprio la mancanza
di dati grezzi a dispozione che impedisce lo sviluppo di iniziative
(anche economiche, anche su basi commerciali) e' proprio quello della
mobilita', del traffico e dei trasporti pubblici.
insomma, la cosiddetta info-mobility

ciao Sandro



-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.



Maggiori informazioni sulla lista Gfoss