Visualizzare gli spostamenti in bicicletta in area urbana: un approccio “ad hoc”

Dal 1 Aprile al 31 Ottobre 2019 si è svolta la seconda edizione del progetto “Cambiamo Marcia” organizzato dal comune di Cesena, che ha permesso a più di 300 cittadini di ricevere un incentivo pari a 0.25€ al chilometro sugli spostamenti in bici nei percorsi casa-lavoro.

L’obbiettivo dell’Amministrazione Comunale in questa seconda edizione era duplice: da un lato diffondere una buona pratica di mobilità attiva, dall’altro raccogliere informazioni quantitative sui percorsi più frequentati dai ciclisti, e visualizzarle su mappe web facilmente condivisibili.

Wecity, come partner tecnologico del progetto, era già in grado di registrare e validare i percorsi compiuti dagli utenti, anche grazie all’esperienza maturata in diversi altri progetti simili, sia pubblici che privati.

Il secondo obbiettivo però presentava una serie di difficoltà non banali che, vista la nostra propensione a complicarci la vita, ci sono risultate immediatamente irresistibili.

In questo post raccontiamo come sono state realizzate alcune delle visualizzazioni messe a disposizione dell’Amministrazione Comunale.

Il primo ostacolo: il map-matching

Quando si hanno a disposizione dati GPS relativi a diversi percorsi, l’approccio più comune è disegnare mappe come quella qui sotto.

Lottando direttamente i dati grezzi (ovviamente anonimizzati) si possono ottenere centinaia di linee che forniscono una informazione qualitativa sul numero di passaggi in un determinato lasso di tempo.

Più sono le linee, maggiore sarà lo spazio che occupano sullo schermo, creando un effetto estetico per cui in corrispondenza degli assi stradali più trafficati le linee diventano più grosse e più scure.

Si possono poi impiegare ulteriori effetti come le mappe di calore o “heatmap“. Purtroppo però, in questo modo non abbiamo nessuna informazione numerica relativamente ad una determinata via, ne tanto meno ad un tratto di via.

Qui è dove entra il gioco il map-matching.

Il map-matching consiste nell’abbinare una serie di coordinate geografiche ad un modello topologico del mondo reale, tipicamente un sistema GIS.

Con un esempio, trasformare la linea gialla nella linea verde, come nell’immagine sottostante.

Perchè il map-matching è così importante? Perchè le tracce GPS, una volta trasformate, diventano perfettamente sovrapponibili e quindi sommabili, generando le informazioni numeriche desiderate.

Inizialmente abbiamo optato per algoritmi di map-matching già disponibili sul mercato, utilizzabili in modalità SAAS. Ma ci siamo subito accorti di un problema: sono tutti ottimizzati per l’automobile!

In pratica, quando diamo in pasto all’algoritmo una serie di coordinate GPS, e nessuna di queste coordinate è realmente sull’asse stradale (anzi può capitare che un punto sia molto vicino ad una via che in realtà non è stata percorsa), l’algoritmo capisce che l’utente non puo essere passato attraverso gli edifici come un fantasma, e deve decidere che strada ha percorso.

Nel farlo, l’algoritmo applica parametri tipicamente automobilistici: scelta del percorso più scorrevole, niente inversioni a “U” o cambi di carreggiata (cosa che una bici può tranquillamente fare in corrispondenza di striscie pedonali) o di circolazione contromano (a volte ammessa per la bici, a volte no. Ma non è questo l’argomento di oggi).

A questo punto abbiamo quindi deciso di sviluppare da zero un algoritmo di map-matching che avesse in testa principalmente il ciclista.

Dopo diverse settimane di sviluppo, siamo arrivati ad una prima versione soddisfacente, con la quale abbiamo mappato un primo campione di circa 100.000 viaggi, su 4 città diverse, con un’accuratezza del 92% circa.

Il secondo ostacolo: il grafo stradale

Studiando il primo campione, ci siamo accorti che l’accuratezza di cui sopra calava sempre nelle stesse zone di una determinata città, e che molto spesso tali zone coincidevano con le più importanti piazze cittadine.

In pratica, l’algoritmo non riusciva a tracciare il percorso di un utente attraverso la piazza, che è probabilmente il luogo pedonale/ciclabile per eccellenza, anche in città non particolarmente bike-friendly.

In altre parole, la piazza non esiste nel modello logico usato dall’algoritmo. E di nuovo, il motivo è l’approccio automobilistico. Risulta tutto molto chiaro osservano la mappa sottostante.

Poichè Piazza del Popolo, a Cesena, è pedonale, il grafo si interrompe e le 8 strade che si affacciano sulla piazza sono trattate come dei vicoli ciechi.

Una cosa simile avviene in corrispondenza di strade troppo strette per essere carrabili, passaggi porticati, ecc: insomma tutti quei luoghi che rendono meravigliosi e intriganti i centri storici delle città.

La soluzione in questi casi è aggiungere i tratti mancanti, collegando ogni punto a tutti gli altri così da rendere possibili tutti i flussi di bici attraverso la piazza.

Poichè non è pensabile di scovare manualmente, per ogni città, le parti di grafo mancanti, abbiamo utilizzato la perdita di accuratezza dell’algoritmo come campanello di “allarme”, per poi generare automaticamente per ogni zona il reticolo mancante.

La cosa interessante è che questo approccio mette in luce anche le cosidette “linee del desiderio”, o “desire lines”, su cui scriveremo presto un post dedicato.

Con questa correzione al grafo stradale, la performance dell’algoritmo di map-matching è passata dal 92 al 98,8%, relegando gli errori a situazioni marginali.

Visualizzazioni statiche

Ora abbiamo tutto ciò che ci serve: i dati grezzi dei percorsi, il grafo stradale originale, e le correzioni “ciclistiche” per tener conto della peculiarità di questi spostamenti.

Introduciamo 2 ultime correzioni, eliminando i primi e gli ultimi metri percorsi dall’utente, che quindi parte e arriva dall’incrocio più vicino alla partenza e all’arrivo, per questioni di privacy.

Il risultato è che ora è possibile sovrapporre alle singole tracce GPS il flusso ciclistico per ogni elemento del grafo stradale.

Passando il mouse sulle linee rosa, è possibile vedere l’informazione numerica, in questo caso relativa sia al numero di passaggi complessivi, sia al numero di utenti unici che l’hanno percorsa nel periodo di tempo considerato.

I cursori sulla destra permettono di filtrare gli assi stradali in base ai valori di cui sopra.

A partire da qui, è possibile sviluppare dashboard ancora più analitiche per lo studio dei flussi di traffico, oppure generare visualizzazioni animate con un obiettivo principalmente comunicativo.

Visualizzazioni animate

Nelle visualizzazioni animate serve ovviamente un dato in piu: il tempo.

Per rendere l’animazione fluida occorre manipolare ulteriormente i dati, in modo da far coincidere sullo stesso frame il maggior numero di segmenti da animare nello stesso istante.

Il risultato è la mappa sottostante. Una volta premuto play, si può giocare con la velocità di animazione cambiando il numero di fianco all’icona-missile, in basso a destra.

Inoltre trascinando i due cursori sotto agli istogrammi, è possibile aumentare o diminuire l’arco temporale plottato.

La mappa animata ha un valore principalmente comunicativo e non analitico: tuttavia è in grado di visualizzare in modo chiaro e intuitivo alcuni elementi importanti come la distribuzione spaziale e temporale dei viaggi, l’ora di punta, il bacino di partenza e di arrivo, ecc.

Conclusioni

Wecity si è dotata di un approccio completamente in-house che, a partire da dati grezzi relativi a spostamenti ciclistici in area urbana, genera informazioni numeriche rigorose sugli assi stradali della città, visualizzabili attraverso mappe statiche e dinamiche interattive e condivisibili via web.

Ci piacerebbe mettere a disposizione questo approccio anche per altre realtà: se sei un urban planner, un consulente per la mobilità, o un assessore ai trasporti e vuoi saperne di più, mettiti in contatto con noi e facci sapere cosa ne pensi!