Real Time Transport Challenge

image0

Sponsor: U-Hopper / Thinkin

Nell’ambito dei trasporti pubblici, per comprendere appieno le dinamiche di afflusso dei passeggeri sugli autobus e quindi ottimizzare il numero di corse e i tragitti, è importante sapere il numero di passeggeri per linea durante la giornata. Una società di trasporti pubblici di una città che U-Hopper non è autorizzata a rivelare (a scanso di equivoci, la città non è comunque Trento), è interessata pertanto a verificare se sia possibile stimare il numero di passeggeri a bordo di un autobus sulla base del numero di dispositivi (smartphone, essenzialmente) rilevati a bordo dell’autobus stesso tramite opportuni sensori. Una procedura di rilevazione di questo tipo presenta alcuni vantaggi rispetto a metodologie più tradizionali: per esempio, rispetto alla rilevazione manuale, non richiede l’impiego a tempo pieno di un addetto su ogni autobus che conteggi il numero di passeggeri a bordo nel corso tragitto; rispetto invece a una misurazione effettuata tramite controllo dei dati delle obliteratrici, una rilevazione tramite sensori consente di stabilire non solo quando un passeggero salga sull’autobus ma anche quando ne discenda.
Al riguardo, la società si è rivolta a U-Hopper per la programmazione e installazione dei sensori e, una volta acquisiti i dati, per la messa a punto di un procedimento (algoritmo) in grado di analizzare le misurazioni per effettuare una stima del numero di passeggeri. Per calibrare il sistema, la società di trasporti pubblici ha messo a disposizione di U-Hopper le rilevazioni del numero di passeggeri compiute manualmente da alcuni addetti a bordo degli autobus - questi ultimi ovviamente muniti anche di sensore - di varie linee urbane durante alcune giornate.
U-Hopper ha già provveduto a realizzare quanto richiesto dal cliente, ma in futuro potrebbe risultare utile produrre visualizzazioni grafiche per mettere in evidenza regolarità nell’affluenza dei passeggeri (pattern) tramite uno strumento che risulti facilmente comprensibile per qualunque interlocutore. Si richiede quindi di visualizzare il numero di device rilevati mediamente giorno per giorno sulle diverse linee nelle varie fasce orarie, comparandolo eventualmente con le rilevazioni manuali. Per aumentare la fruibilità, si potrebbe creare un’apposita interfaccia utente stile chatbot che consenta di scegliere per es. quale fascia oraria evidenziare.

a. Analisi

Esplorare i dati per individuare a quali linee urbane si riferiscano le misurazioni, in quali giorni siano state effettuate e in quali fasce orarie (ovviamente gli autobus non circolano per tutte le 24 ore) - in questa fase occorrerà procedere a una conversione del timestamp in modo che giorno e ora siano leggibili.

b. Preparazione

Importanti operazioni di pulizia sono state già svolte da U-Hopper, come la rimozione preliminare dai dati dei segnali spuri, cioè dei segnali provenienti da device non appartenenti a passeggeri dell’autobus (per esempio, il device dell’autista, quello del guidatore e/o passeggero dell’auto che transita a fianco dell’autobus, etc.).

Quello che dovrete fare voi sarà segmentare dei dati in modo che siano raggruppati in base alla linea dell’autobus e alla fascia oraria. Dato che i sensori effettuano rilevazioni a intervalli di qualche secondo, è naturale che il device di ogni passeggero compaia ripetutamente fintanto che il passeggero sia a bordo dell’autobus e di questo aspetto occorrerà tener opportunamente conto.

c. Visualizzazione

c.1 Utilizzo linee

Per ogni linea di autobus si potrebbero produrre una o più visualizzazioni grafiche (tabella, istogramma, diagramma a torta, etc.) relative alla frequentazione dell’autobus nelle varie fasce orarie delle diverse giornate (si potrebbe considerare un intervallo temporale di un’ora, per esempio), mettendo in evidenza quanto sia stato utilizzato l’autobus in ogni fascia rispetto alla media giornaliera della linea. Una visualizzazione di questo tipo sarebbe per esempio utile alla società di trasporti per verificare se sia il caso di intensificare - o rarefare - il numero di corse rispetto alla prassi attuale, tenuto anche conto delle variazioni di affluenza nei giorni festivi rispetto ai feriali.

c.2 Differenze dati device / registrazioni manuali

Siccome non tutti i passeggeri dispongono necessariamente di un device, i numeri nelle visualizzazioni relative alle rilevazioni dei sensori non coincideranno con gli analoghi numeri che si potrebbero ottenere a partire dalle misurazioni manuali. Cionondimeno, un confronto tra i picchi rilevati in un caso e nell’altro potrebbe essere utile a segnalare eventuali anomalie/malfunzionamenti dei sensori (peraltro nuovi) o blackout, aiutando così U-Hopper o la società dei trasporti stessa a procedere con le necessarie verifiche e, nel caso, a intervenire opportunamente.
Si potrebbero quindi produrre visualizzazioni analoghe a quelle cui si fa riferimento nella sezione d.1, impiegando però i dati ottenuti tramite le misurazioni effettuate manualmente dagli addetti della società di trasporti, così da procedere poi al confronto qui sopra descritto.

d. Interfaccia interattiva

Presentare il tutto in un chatbot o sito, includendo elementi interattivi: per esempio, un utente potrebbe inserire la linea urbana, il giorno della settimana e la fascia oraria e vedersi restituito il corrispondente numero di device rilevati, nuovamente evidenziato in maniera diversa a seconda di quanto elevato o basso sia il numero di device rapportato alla media giornaliera.

e. Inferenza

Se vi avanza tempo, come extra guardate cosa si può inferire solo analizzando la distribuzione dei picchi nell’arco di una singola giornata. Potreste avanzare ipotesi sulla tipologia di area urbana servita dalla varie linee di autobus: per esempio, picchi al mattino presto e in tarda mattinata potrebbero far ipotizzare che la linea urbana in esame serva dei poli scolastici, picchi al mattino presto e nel tardo pomeriggio porterebbero invece a credere che la linea urbana serva aree di uffici e/o industrie. Provate quindi a realizzare una tabella che metta in corrispondenza le fermate con il tipo di luogo.

Dataset

I dataset sono forniti da U-Hopper. Per i dati completi chiedere a david.leoni@unitn.it

Vi verranno forniti due file, Rilevazioni_sensori.csv e Rilevazioni_manuali.csv

Le rilevazioni - sia tramite sensori che tramite addetti della società - sono state effettuate su tre linee urbane di un Comune (che deve rimanere anonimo) nel corso di tre distinte giornate durante una settimana del mese di novembre dell’anno scorso. Più precisamente, il file con le rilevazioni dei sensori e quello con le misurazioni manuali contengono circa 110000 e 5300 righe rispettivamente, per un totale di circa 2.5 Mb e 210 Kb di memoria. Le rilevazioni coprono le fasce orarie dalle 5-6 del mattino (circa) fino alle 20-21 (circa), eccezion fatta per una linea di bus che, in due delle tre giornate in questione, ha dati solo tra le 5 e le 10 per un giorno e tra le 6 e le 16 per l’altro.

Rilevazioni_sensori.csv

Righe: 110000

Dimensione: 2.5 Mb

Colonne:

  • Line: linea di autobus della rete urbana

  • Timestamp: timestamp dell’istante in cui la rilevazione è stata effettuata

  • ID Device: id del device rilevato (opportunamente anonimizzato)

Esempio:

Line    Timestamp           ID_Device
11      1542859801.14977    53c5a73e-b1a3-5618-81f2-ec0d8a24cb10
11      1542859805.09879    53c5a73e-b1a3-5618-81f2-ec0d8a24cb10
11      1542860008.60541    0d36bc0a-c1c9-535a-92fe-187dcb670dc4
6       1542861382.94801    538072a4-722b-5e5a-afdd-46bcd9626245
6       1542861384.6065     5656b67a-67d3-5b31-8e53-637b1ef501e7
6       1542861384.89655    7493648b-4eef-5029-bfe3-f363aae59c2d

Rilevazioni_manuali.csv

Righe: 5300

Dimensione: 210 Kb

Colonne:

  • linea dell’autobus

  • timestamp

  • Passengers: numero di passeggeri presenti sull’autobus una volta terminate le operazioni di salita e discesa a una fermata (è qui utile specificare che gli addetti hanno proceduto alla rilevazione alla ripartenza dell’autobus da ogni fermata)

  • Gone_up: numero di passeggeri saliti alla fermata

  • Gone_down: numero di passeggeri discesi

Esempio:

Line    Timestamp   Passengers  Gone_up Went_down
6       1542870352  17          2       1
6       1542870960  12          0       2
6       1542871204  11          3       0
9       1542873885  5           0       0
9       1542873976  0           0       5
9       1542874068  18          18      0