FIRENZE SAFEROADS · COME FUNZIONA
Analisi storica e pianificazione delle pattuglie
Il cruscotto studia gli incidenti già registrati e cerca la migliore combinazione delle postazioni disponibili per coprire quei luoghi. Attualmente non calcola quanti incidenti avverranno in futuro.
“Se gli incidenti si distribuissero come nel periodo analizzato, dove converrebbe collocare le pattuglie disponibili?”
Questa è un'ipotesi di continuità con il passato, non una previsione verificata. Cambiamenti del traffico, della viabilità o delle abitudini possono modificare la distribuzione futura.
1. Quali dati vengono usati
Il punto di partenza è l'archivio degli incidenti caricato nel cruscotto. Ogni registrazione può contenere data, ora, luogo, coordinate, gravità, mezzi coinvolti e altri elementi, come meteo e violazioni registrate.
I filtri nella barra laterale selezionano il gruppo da analizzare. La pianificazione delle pattuglie usa quel gruppo e lo restringe agli incidenti avvenuti nel turno scelto. Per esempio, se selezioni il 2025 e il turno 07–13, la proposta usa gli incidenti selezionati di quell'anno avvenuti tra le 07:00 incluse e le 13:00 escluse.
Il turno 19–01 comprende anche l'intervallo da mezzanotte alle 00:59. Per la copertura servono coordinate e un orario interpretabile: registrazioni prive di queste informazioni non contribuiscono a quel calcolo.
Se i filtri non trovano incidenti, il risultato resta zero e non vengono proposte postazioni. Il programma non torna automaticamente all'intero archivio.
2. Che cosa significa la mappa di calore
La scheda “Densità Storica Ponderata (KDE)” visualizza le concentrazioni degli incidenti passati. Ogni incidente contribuisce a una zona colorata; la sovrapposizione dei contributi rende visibili gli addensamenti. Gli eventi gravi hanno maggiore peso.
Nella mappa attuale i pesi di intensità sono 1 per i mortali, 0,70 per gli incidenti con feriti e 0,35 per quelli con soli danni. Sono pesi grafici: sono diversi dai punti utilizzati per scegliere le postazioni.
I pulsanti di fascia oraria e categoria coinvolta aggiungono una selezione ai filtri laterali. Le fasce della mappa sono 06–12, 12–18, 18–24 e 00–06; i turni operativi delle pattuglie sono invece 07–13, 13–19, 19–01 e 01–07. Per questo i due risultati non sono direttamente identici.
Un'area più intensa indica una maggiore concentrazione storica ponderata nella visualizzazione. Non significa “qui c'è una probabilità del 70% di incidente” e non dimostra che l'area sia statisticamente significativa.
La visualizzazione usa una mappa di calore smussata nel browser. Aspetto e intensità dipendono anche dallo zoom; non si tratta di una stima di probabilità calibrata su celle di 250 metri.
La mappa di calore (le "macchie colorate") ti dà una visione generale di dove si verificano più incidenti gravi.
Tuttavia, a volte le macchie grandi nascondono i dettagli. Cliccando su Mostra Posizioni Esatte, puoi far apparire (o nascondere) i pallini individuali che rappresentano i singoli incidenti reali sulla strada, in modo da poterli cliccare e analizzare uno per uno.
3. Come si calcola il punteggio storico
Per la pianificazione ogni incidente riceve un numero di punti:
- Mortale: 10 punti.
- Con feriti: 4 punti.
- Con soli danni: 1 punto.
Il punteggio è la somma di questi contributi. Un incidente mortale, due incidenti con feriti e tre con soli danni valgono 10 + 8 + 3 = 21 punti.
Questi pesi privilegiano gli eventi gravi. Sono parametri convenzionali scelti per il cruscotto: non sono costi economici calibrati per Firenze, probabilità o vite salvate. Non vengono aggiunti punteggi di rischio preimpostati per favorire una postazione.
La categoria “con feriti” usata dal calcolo non distingue qui tra feriti lievi e gravi. Un incidente mortale riceve 10 punti per registrazione, non 10 punti per ogni persona deceduta.
4. Come vengono scelte le postazioni
Il metodo segue l'impostazione del problema di massima copertura, chiamato MCLP: scegliere un numero limitato di postazioni per coprire il maggior punteggio storico possibile.
- Si parte da un elenco di postazioni candidate per il turno. L'elenco è predefinito: il sistema non cerca automaticamente nuovi luoghi in tutte le strade di Firenze.
- Si individuano gli incidenti entro 400 metri da ciascuna candidata, misurati in linea d'aria dalle coordinate originali. Il cerchio non misura un percorso stradale o un tempo di intervento.
- Si confrontano tutte le combinazioni ammesse delle candidate, fino al numero di pattuglie richiesto.
- Si escludono combinazioni con postazioni a meno di 700 metri l'una dall'altra. Questo vincolo resta sempre rispettato.
- Si sceglie la combinazione con la maggiore copertura pesata complessiva. Un incidente che ricade in due cerchi viene contato una sola volta. A parità di punteggio, il sistema preferisce assegnare più unità entro il limite richiesto.
Due postazioni possono coprire molti degli stessi incidenti. La combinazione migliore può includere una postazione con meno punti individuali, se aggiunge una copertura utile in un'altra zona.
“Ottimale” significa migliore tra le candidate e con questi parametri. Non significa migliore soluzione possibile per tutta la città, né migliore piano operativo sotto ogni aspetto.
Il numero richiesto è un massimo di unità assegnabili. Se le candidate utili o compatibili sono insufficienti, oppure una diversa combinazione copre più punti con meno postazioni, il sistema può assegnarne meno e mostra un avviso. Non forza postazioni troppo vicine per raggiungere il numero richiesto.
Con cerchi di raggio 400 metri, una distanza di 700 metri tra i centri non elimina ogni sovrapposizione. Il doppio conteggio viene evitato dal calcolo degli incidenti distinti.
5. Come leggere i risultati
La legenda riporta le postazioni assegnate, gli incidenti storici coperti, il totale analizzabile del turno e il punteggio complessivo.
8/8 postazioni; 324/2.644 incidenti storici coperti; punteggio 1.017.
- Le 8 unità richieste sono state associate a 8 postazioni.
- 324 incidenti storici distinti ricadono entro 400 metri da almeno una postazione scelta.
- 2.644 è il totale degli incidenti analizzabili nei filtri e nel turno di quell'esempio, non l'intero archivio.
- 1.017 è la somma dei punti di gravità degli incidenti coperti.
Non significa che 324 incidenti saranno evitati o che verranno salvate 1.017 persone. I numeri cambiano con i dati, i filtri, il turno e le risorse disponibili.
Il punteggio della singola postazione considera gli incidenti nel suo cerchio. La somma dei punteggi individuali può superare quello complessivo, perché il totale complessivo conta ciascun incidente una sola volta.
Le indicazioni sul tipo di controllo sono suggerimenti preimpostati da verificare, non cause dedotte automaticamente da un modello. Le telecamere vicine vengono cercate nel dataset caricato; la loro presenza non garantisce che siano attive, utilizzabili o orientate verso il punto di interesse.
6. Che cosa il sistema non può concludere
- Non prevede il numero di incidenti di domani o la probabilità di un incidente in un luogo.
- Non dimostra un effetto preventivo delle pattuglie. I 400 metri sono un criterio di copertura, non un raggio di deterrenza dimostrato.
- Non stima una riduzione dell'11%. Quel valore era fisso e non viene più presentato come un risultato.
- Non misura il rischio per veicolo o per chilometro. Una strada con più incidenti può anche avere molto più traffico; servono dati di esposizione per confrontare quel rischio.
- Non sostituisce la valutazione operativa. Non verifica automaticamente sicurezza della sosta, percorsi di accesso, disponibilità del personale o altre necessità del turno.
Coordinate errate, dati mancanti e periodi incompleti possono alterare i risultati. Un anno ancora in corso non è direttamente confrontabile con un anno completo senza rendere omogenei i periodi.
Approfondimento: quali metodi sono presenti e quali mancano?
Presenti: selezione dei dati storici, mappa di calore ponderata e ricerca esatta della massima copertura pesata sulle postazioni candidate, con budget massimo di pattuglie e vincolo di distanza.
Getis-Ord Gi* e Z-score: non sono implementati. Servirebbero un'aggregazione spaziale definita, relazioni di vicinato, un calcolo statistico effettivo e una gestione dei confronti multipli. I punteggi storici attuali non sono Z-score.
Reti neurali LSTM: non sono implementate. Selezionare gli incidenti per ora non equivale ad addestrare una rete su serie temporali.
Empirical Bayes: non è implementato. È un metodo di valutazione che combina una previsione di riferimento con la storia osservata; non si ottiene inserendo una percentuale fissa in tabella.
Il nome “Metodologia AI”: identifica questa scheda, ma non prova che il cruscotto utilizzi una rete neurale addestrata o un modello predittivo validato. La definizione corretta del metodo attuale è analisi storica e ottimizzazione della copertura delle pattuglie.
Che cosa servirebbe per una vera previsione e una misura dell'efficacia?
- Definire che cosa prevedere: per esempio il numero di incidenti in una zona e in un intervallo temporale.
- Verificare la qualità dei dati e integrare informazioni pertinenti, come traffico, viabilità, calendario e condizioni ambientali.
- Addestrare un modello su un periodo passato e verificarlo su un periodo successivo non usato per l'addestramento.
- Confrontarlo con metodi semplici di riferimento e misurare errori e incertezza. Una rete LSTM non è obbligatoria: il metodo va scelto in base ai dati e ai risultati.
- Per misurare la prevenzione, registrare i servizi realmente svolti e gli incidenti successivi, usare confronti adeguati e considerare i cambiamenti indipendenti dalle pattuglie.
Una previsione accurata e una riduzione causata da un intervento sono due verifiche diverse. Solo dopo una valutazione adeguata si può riportare una stima di efficacia, insieme alla sua incertezza.
7. Perché è stato scelto questo metodo
La scelta nasce dal controllo del codice e dei dati del progetto. Il cruscotto dispone di incidenti storici, coordinate e un elenco ridotto di postazioni candidate. Queste informazioni permettono di calcolare una copertura controllabile e riproducibile; non bastano, da sole, per dimostrare una previsione futura o l'efficacia delle pattuglie.
La massima copertura è stata adottata perché risponde alla domanda operativa “come distribuire risorse limitate?”. Poiché l'elenco attuale contiene poche candidate, il programma può confrontare tutte le combinazioni ammesse, senza affidarsi soltanto all'ordine dei punteggi individuali.
Questa è una scelta progettuale motivata, non il risultato di uno studio comparativo che dimostri la superiorità del metodo per Firenze. I test eseguiti verificano la correttezza del calcolo, il rispetto dei vincoli e la gestione dei filtri; non sono una validazione predittiva o una sperimentazione di prevenzione.
- 10–4–1: pesi di priorità già presenti nel progetto, mantenuti rendendo esplicito che non sono coefficienti economici ufficiali.
- 400 e 700 metri: parametri operativi già presenti nel progetto, mantenuti per la copertura e il distanziamento. Nessuna fonte qui citata li dimostra ottimali per Firenze.
- Postazioni e tipi di controllo: elenco e suggerimenti ereditati dal progetto, da verificare con gli operatori.
Per calibrare queste scelte occorrono confronti tra pesi e distanze diversi, dati di traffico, conoscenza della rete stradale e verifiche sul campo.
Non si attribuisce più l'implementazione a un framework ibrido “Burdett–Leigh–Lee”: i metodi indicati nella precedente descrizione non erano effettivamente implementati e non è stata documentata una validazione di quel framework su Firenze.
8. Fonti e cosa sostengono realmente
Le fonti seguenti distinguono la base teorica, la documentazione tecnica e i metodi utili per sviluppi futuri. Citare un metodo non significa averlo implementato o validato sul territorio.
- Church, R.; ReVelle, C. (1974). The Maximal Covering Location Problem, Papers in Regional Science, 32, 101–118. Riferimento teorico: scegliere postazioni con risorse limitate per massimizzare la domanda coperta. Nel cruscotto la domanda è costituita dagli incidenti storici pesati; il limite di 700 metri è un vincolo aggiunto dal progetto. Il lavoro non dimostra un effetto preventivo delle pattuglie di Firenze.
- FHWA — Applying Safety Data and Analysis to Performance-Based Transportation Planning, sezione 5. Using Safety Analyses for Planning. Riferimento metodologico: analisi descrittiva, mappe delle concentrazioni e ponderazione per gravità. La sezione EPDO collega i pesi ai costi sociali: non prescrive i pesi 10–4–1 usati qui.
- Leaflet.heat — documentazione ufficiale del componente. Opzioni e intensità della mappa di calore. Riferimento tecnico all'implementazione: descrive raggio grafico, sfocatura e intensità dipendente dallo zoom. Non certifica una probabilità di incidente o una KDE statistica calibrata per Firenze.
- Esri — documentazione ufficiale ArcGIS Pro. How Hot Spot Analysis (Getis-Ord Gi*) works. Riferimento per chiarire il metodo mancante: spiega il confronto statistico locale, Z-score e significatività. È citato per distinguere questa analisi dalla semplice mappa di calore; Gi* non è implementato nel cruscotto.
- FHWA — Road Safety Fundamentals, Unit 4. Solving Safety Problems. Riferimento per valutare l'efficacia: illustra gli studi prima/dopo, i possibili fattori confondenti e il metodo Empirical Bayes. Motiva la necessità di una valutazione prima di attribuire riduzioni agli interventi; non giustifica un −11% fisso.
- Persaud, B.; Lyon, C. (2007). Empirical Bayes before–after safety studies: Lessons learned from two decades of experience and future directions, Accident Analysis & Prevention, 39(3), 546–555. Studio di riferimento per una futura valutazione EB, citato anche nella guida FHWA. Non è una verifica già eseguita su questo progetto.
- scikit-learn — documentazione ufficiale. Cross-validation: evaluating estimator performance — Time series split. Riferimento tecnico per una futura validazione predittiva: verificare un modello temporale su osservazioni successive a quelle usate per addestrarlo. Non implica che il cruscotto utilizzi scikit-learn o che questa validazione sia già stata svolta.
Base della verifica del sistema attuale: lettura del sorgente del progetto, prove del risolutore su casi controllati e confronti con enumerazione indipendente sui dati allegati. Queste evidenze sostengono le affermazioni sul funzionamento del codice, non una promessa di riduzione degli incidenti.