Studio di dati per l'analisi delle traiettorie

1. UNIVERSIT`A DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea Magistrale in Ingegneria Informatica
Studio di opendata acquisiti tramite
tecnologie MODE S e ADS-B per
l’analisi delle traiettorie aeree in
ambito europeo
LAUREANDO RELATORE
Paola Bassi Chiar.mo Prof. Lorenzo Castelli
CORRELATORE
Dott. Tatjana Boli´c
Anno Accademico 2016/2017

3. Indice
1 Introduzione 3
1.1 Il traffico aereo . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 La network Opensky 5
2.1 La community e le tecnologie . . . . . . . . . . . . . . . . . . 5
2.1.1 ADS-B e MODE S . . . . . . . . . . . . . . . . . . . . 7
2.2 Il database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Le tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Analisi dei dati 14
3.1 I primi passi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Le analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Scelta dei dati . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Confronto callsign . . . . . . . . . . . . . . . . . . . . . 20
3.2.3 Origine e destinazione . . . . . . . . . . . . . . . . . . 26
3.2.4 Creazione delle traiettorie . . . . . . . . . . . . . . . . 33
4 Clustering e analisi delle traiettorie 35
4.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 DBSCAN e la scelta dei parametri . . . . . . . . . . . 35
4.1.2 Una prima istanza . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Generalizzazione del problema . . . . . . . . . . . . . . 37
4.1.4 Problemi riscontrati . . . . . . . . . . . . . . . . . . . 38
4.2 Analisi delle traiettorie . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Gestione dei dati . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Analisi e risultati . . . . . . . . . . . . . . . . . . . . . 41
5 Conclusioni 48
Bibliografia 49

4. Capitolo 1
Introduzione
1.1 Il traffico aereo
Negli ultimi anni, il volume del traffico aereo europeo ha visto un forte incre-
mento e il numero dei passeggeri `e in costante aumento. Nel 2016, il numero
dei passeggeri transitati in Europa `e stato di 973 milioni [2] e il 2017 ha
visto un incremento del 6.4%[1]. Questa crescita ha definito la necessit`a di
imporre dei vincoli, affinch´e tutto il traffico possa essere gestito nel modo
pi`u efficiente possibile. In linea con le regole imposte dagli enti ATC [16],
le compagnie aeree, molto probabilmente, istituiscono delle regole interne o
impongono delle strategie aziendali, al fine di riuscire ad offrire il servizio
migliore ai propri clienti.
Per avvalorare la tesi appena esposta, si `e deciso di analizzare le traiettorie
aeree e di dimostrare se, per la scelta di quest’ultime, vengono prese delle
decisioni specifiche. Ci`o che rende questo lavoro particolarmente interessante
`e il fatto che per tutte le analisi vengono utilizzati opendata. Questi dati gra-
tuiti sono forniti da OpenSky [4], una community che si occupa di raccogliere
i dati resi disponibili dagli aerei mentre sono in viaggio, grazie all’utilizzo di
tecnologie per la comunicazione (MODE S e ADS-B). Sono stati affrontati i
seguenti punti:
• studio del caso OpenSky e comprensione dei dati disponibili
• analisi e trattazione dei dati
• ulteriore raffinamento dei dati e scelta delle analisi effettuate sulle
traiettorie
3

5. Ad ogni punto `e stato dedicato un capitolo. Nel primo capitolo verr`a spiegato
cos’`e OpenSky, a quale scopo ci `e utile e quali sono i dati che fornisce. Nel
secondo capitolo verr`a chiarito tutto il processo di analisi dei dati e verr`a
fornito un esempio che aiuter`a a capire l’effettiva quantit`a di dati trattata e
il volume del traffico aereo europeo. Nell’ultimo capitolo, verr`a illustrato il
clustering delle traiettorie e verranno descritte le analisi effettuate.
Tutte le analisi sono state fatte utilizzando il linguaggio R e l’ambiente di
sviluppo R Studio [7]. Le elaborazioni sono state effettuate su pc con proces-
sore Intel Core i7-4510U @ 2.00GHz e 8GB di RAM. In alcuni casi le risorse
computazionali si sono rivelate insufficienti ad analizzare l’enorme quantit`a
di dati. Per questo motivo, alcuni passi dell’analisi sono stati eseguiti su dei
sottoinsiemi (poi riagglomerati).
4

6. Capitolo 2
La network Opensky
2.1 La community e le tecnologie
OpenSky si occupa di raccogliere dati di sorveglianza del traffico aereo. Gra-
zie alla sua rete di sensori ADS-B, `e in grado di acquisire ed archiviare i dati
che gli aerei inviano in broadcast e si interessa principalmente dello spazio
aereo europeo, anche se `e in espansione (copre anche buona parte dell’Ame-
rica settentrionale). Nelle figure 2.1, 2.2 e 2.3 viene raffigurata la copertura
dei sensori nel mondo e in Europa e dimostra la significativa espansione di
OpenSky nel corso di un solo anno.
Figura 2.1: Mappatura sensori a settembre 2017
5

7. Figura 2.2: Mappatura sensori in Europa ad ottobre 2016
Figura 2.3: Mappatura sensori in Europa a settembre 2017
6

8. OpenSky inserisce nel suo database i dati cos`ı come vengono ricevuti dai
sensori. Alcuni dei sensori acquisiscono tutti i messaggi MODE S mentre
altri soltanto i messaggi ADS-B (per capire meglio si rimanda il lettore alla
sezione 2.1.1). Oltre al payload (bit utili) dei messaggi MODE S, OpenSky
salva metadati aggiuntivi, come ad esempio timestamps e potenza del segnale.
Il vantaggio di utilizzare i dati di OpenSky, piuttosto che quelli di altri servizi
simili, `e che sono forniti gratuitamente a chiunque voglia fare ricerca. Inoltre,
rispetto ad altri servizi basati su ADS-B (es. FlightRadar24 e FlightAware),
OpenSky fornisce i dati grezzi che sono preziosi per i ricercatori.
2.1.1 ADS-B e MODE S
Il dataset di OpenSky `e stato creato grazie a pi`u di 5 trilioni di messaggi del
tipo ADS-B e MODE S raccolti a partire dal 2013. ADS-B consente agli aerei
di definire la loro posizione e la loro velocit`a usando il GPS. Le informazioni
di posizione sono presenti in messaggi di tipo MODE S extended. MODE
S `e una delle pi`u importanti tecnologie per la gestione del traffico aereo.
Supporta:
• SSR (secondary surveillance radar): questo radar consente di interro-
gare selettivamente o in all-call (cio`e indistintamente) gli aeromobili
mediante segnali radio MODE S . Le informazioni trasferite con questo
tipo di radar sono sequenze da 112 o 56 bit, che contengono istruzioni
per il transponder, il metodo di interrogazione e il codice dell’aereo
interrogato.
• Traffic collision avoidance system (TCAS): `e un dispositivo con la fun-
zione di avvertire i piloti circa la presenza di altri aeromobili equi-
paggiati di transponder operanti nelle vicinanze ed `e basato sul radar
SSR, ma opera indipendentemente dalle attrezzature a terra per fornire
consulenza al pilota su aerei in potenziale conflitto.
• Automatic Dependant Surveillance-Broadcast (ADS-B).
In ADS-B, il transponder MODE S “capta” i messaggi periodici per ricavare:
• posizione
• velocit`a
• identit`a del velivolo e delle stazioni di terra nel suo raggio
7

9. I sensori di OpenSky sono equipaggiati con ricevitori MODE S. OpenSky
raccoglie soltanto i messaggi inviati nel “canale” MODE S a 1090 MHz e
sono chiamati DF(downlink formats) e vengono descritti nella tabella 2.1
DF Informazioni Applicazione
0 altitude anticollisione
4 altitude sorveglianza
5 squawk sorveglianza
11 transponder address sorveglianza
16 altitude, threat resolution anticollisione
17 ADS-B message sorveglianza
18 ADS-B/TIS-B message sorveglianza
19 Military application —
20 altitude, Comm-B sorveglianza
21 squawk, Comm-B sorveglianza
24 ELM trasferimento dati
Tabella 2.1: Descrizione DF
I DF sono sostanzialmente di due tipi: sorveglianza e anticollisione. I primi
vengono utilizzati per il controllo del traffico aereo tramite sensori di terra.
Gli aerei vengono inizialmente acquisiti usando le risposte all-call (DF 11).
Una volta acquisiti, il sensore pu`o richiedere l’altitudine (DF 4, DF 20), il
codice transponder (DF 5, DF 21) e altri dati di sorveglianza e di stato
ricavati da messaggi Comm-B (risposte a 112 bit contenenti 56 bit di dati
utili) (DF 20, DF 21). Il DF 5 contiene un codice di 4 cifre che viene usato
per indicare emergenze e problemi radio e viene assegnato dal controllore
ed inserito dal pilota, detto squawk. Anche DF 17 e DF 18 fanno parte di
questa categoria e rispetto agli altri messaggi, questi non vengono inviati in
seguito ad una interrogazione, ma sono spediti in broadcast (la posizione e
la velocit`a sono inviate due volte al secondo) e sono sufficienti per stabilire:
• posizione (3D)
• velocit`a
• identit`a
• stato operativo
Il tipo di messaggi appena descritto `e detto ADS-B e talvolta pu`o anche es-
sere usato dagli altri aerei per evitare collisioni. Ci sono anche altri messaggi
utilizzati per evitare le collisioni, come specificato poc’anzi; sono messaggi
che vengono scambiati tra gli aerei e i sensori di terra ed anche tra un aereo
8

10. e l’altro. Contengono informazioni sull’altitudine (DF0,16) e altre informa-
zioni utilizzate per risolvere potenziali minacce (DF16). Per essere in grado
di interrogare un aereo, ai transponder viene assegnato un identificatore a
24bit univoco detto indirizzo ICAO che viene assegnati in base al paese di
registrazione dell’aereo. L’indirizzo viene incluso nelle risposte MODE S e
ADS-B e consente di identificare chi invia il messaggio e la provenienza del
velivolo.
L’introduzione appena fatta sulle tecnologie utilizzate dagli aerei e dai sen-
sori, sar`a utile nella comprensione dei dati resi disponibili da OpenSky. Nel
prossimo capitolo verr`a fatta una descrizione dettagliata del database.
2.2 Il database
Il database di OpenSky `e attualmente composto da 9 tabelle ma `e in continuo
aggiornamento. Alcune delle tabelle contengono dati riferiti ai velivoli, men-
tre altre contengono soltanto informazioni sui sensori. Tra le varie tabelle
disponibili, ce n’`e una che raccoglie tutti i dati utili al nostro caso. Inoltre,
come verr`a spiegato nel capitolo 3.1, alcuni dei dati contenuti nelle tabelle
che non sono state utilizzate, non sono, in realt`a, affidabili.
2.2.1 Le tabelle
Di seguito verr`a riportata una descrizione di ognuna delle tabelle sotto elen-
cate.
• acas data4
• allcall replies data4
• rollcall replies data4
• identification data4
• operational status data4
• position data4
• sensor visibility data3
• velocity data4
• state vectors data4
9

11. acas data4
Questa tabella contiene i dati riguardanti il sistema per evitare le collisio-
ni. L’Airbone Collision Avoidance System (ACAS), letteralmente “sistema
per evitare le collisioni in volo”, `e una tipologia di apparato degli aeromo-
bili basati su transponder, usati per avvisare i piloti in caso di possibile o
imminente collisione in volo. Gli avvisi emessi dagli ACAS possono essere
di traffico (Traffic Advisory) o di risoluzione (Resolution Advisory). I pri-
mi indicano sul display dell’apparato la presenza di un traffico in potenziale
conflitto, mentre i secondi suggeriscono al pilota una determinata manovra
in grado di garantire la separazione dagli aeromobili in conflitto di traffico.
allcall replies data4 e rollcall replies data4
Queste due tabelle contengono dati sulle interrogazioni all-call e roll-call. La
stazione di terra (che utilizza la tecnologia MODE S) produce una vasta
gamma di tipi di interrogazioni. Questi tipi possono essere classificati in due
categorie:
• All-call interrogations
• Roll-call interrogations
Tramite le interrogazioni all-call si ottengono risposte da tutti gli aerei nel
proprio raggio, anche se in alcune circostanze gli aeromobili possono essere
“bloccati” a tutte le interrogazioni in modo che non rispondano. Trami-
te le interrogazioni roll-call si possono interrogare aeromobili specifici che
utilizzano tecnologia MODE S utilizzando l’indirizzo univoco a 24-bit (ogni
aeromobile ne possiede uno).
identification data4
Questa tabella contiene dati sul tipo di velivolo, in base al quale, un aereo
pu`o volare in alcuni spazi aerei. Lo spazio aereo `e suddiviso in classi, in base
all’altitudine come raffigurato nella figura 2.4 [9].
10

12. Figura 2.4: Classi dello spazio aereo
Affinch´e un aeromobile sia in grado di volare negli spazi di classe A,B e C
(cio`e compreso tra i 2500 e 10000 piedi) `e obbligato a disporre di attrezzature
ADS-B.
operational status data4
Questa tabella contiene dati sulle condizioni degli aerei. Fornisce informazio-
ni sull’adeguatezza di un aereo ad operare (OK, non OK, adatto per il volo,
adatto per il funzionamento) da un punto di vista operativo. Ad esempio, `e
possibile che un velivolo che da un punto di vista della manutenzione `e abile
a volare, sia tuttavia inadatto ad alcune operazioni, come nel caso di attivit`a
militari per le quali sono necessarie attrezzature particolari.
position data4
Questa tabella contiene dati sulla posizione dei velivoli al momento dell’invio
del messaggio al sensore.
11

13. sensor visibility data3
Questa tabella contiene i dati che identificano i sensori di Opensky e indica
quale volo ha contattato uno dei sensori ed in quale giorno.
velocity data4
Questa tabella contiene i dati sulla velocit`a al momento dell’invio del mes-
saggio al sensore e la possibilit`a di verificare se un volo `e IFR (questo dato
`e molto utile, ma in realt`a ha delle limitazioni come spiegato nel prossimo
capitolo).
state vectors data4
Questa tabella `e la pi`u importante. In questa tabella vengono inseriti dei
record chiamati “state vector” formati da id (indirizzo ICAO + callsign),
informazioni sul tempo e informazioni sullo spazio (posizione, velocit`a, di-
rezione della testa dell’aereo). L’indirizzo ICAO identifica l’aereo in modo
univoco; `e un indirizzo a 24 bit che in genere viene rappresentato in esade-
cimale (6 caratteri). Il callsign, invece, ha bisogno di una descrizione pi`u
accurata. Esistono due tipi di callsign, quelli di immatricolazione e quelli
per i voli di linea. Nella nostra analisi vengono considerati soltanto i voli
con callsign del secondo tipo. Questi callsign sono formati da una prima
parte di tre lettere (codice ICAO) che identifica la compagnia aerea in modo
univoco, mentre la seconda parte `e una stringa alfanumerica solitamente di
tre o quattro caratteri. Ad esempio il volo RYR3195 identifica un volo della
compagnia Ryanair che ha codice ICAO RYR.
OpenSky ha creato questa tabella per accorpare i dati pi`u interessanti e
pi`u completi che hanno a disposizione. Questi dati sono quelli che verranno
utilizzati nelle analisi e ne viene fornita una descrizione pi`u dettagliata:
12

14. Tabella 2.2: Descrizione state vector
time
Contiene l’ unix timestamp per ogni state vector
valido. Si pu`o trovare uno state vector per secondo,
per ogni aereo attivo sotto la copertura OpenSky.
icao24
Contiene l’indirizzo ICAO24 (6 caratteri). Questo
ID cambia soltanto se viene sostituito il transponder,
quindi con grande probabilit`a `e sufficiente
per trovare informazioni su uno specifico aereo.
lat
Contiene l’ultima latitudine conosciuta, dell’aereo.
Le coordinate sono fornite in formato WGS84.
lon
Contiene l’ultima longitudine conosciuta, dell’aereo.
Le coordinate sono fornite in formato WGS84.
velocity Contiene la velocit`a al suolo dell’aereo in m/s.
heading
Rappresenta la direzione in gradi della testa
dell’aereo (nord=0°).
vertrate
Contiene la velocit`a variometrica dell’aereo in m/s.
Un valore negativo indica la discesa dell’aereo, un
valore positivo indica la salita.
callsign
Contiene l’indicativo di chiamata mandato in
broadcast dall’aereo. Molti aerei indicano la
compagnia aerea e il numero del volo nella callsign.
onground Indica se l’aereo invia posizioni da terra o da volo.
alert/spi Sono degli indicatori usati in ATC (Air Traffic Control).
squawk
E’ un altro numero (4 caratteri) utilizzato da ATC
e piloti per scopi di identificazione ed emergenza.
baroaltitude/geoaltitude
Indica l’altitudine dell’aereo. La baroaltitudine `e
l’altitudine misurata con un barometro e dipende da
fattori come il tempo atmosferico.
lastposupdate Questo unix timestamp indica “l’et`a” della posizione.
lastcontact
Questo unix timestamp indica l’istante in cui OpenSky
ha ricevuto l’ultimo segnale dall’aereo. Finch´e l’aereo
si trova nella zona mappata, questo valore non
dovrebbe essere mai pi`u vecchio di 1-2 secondi rispetto
al timestamp dello state vector.
hour
I dati vengono suddivisi in ore, per riuscire ad accedervi
pi`u velocemente. Questo timestamp indica l’ora a cui
appartengono i dati.
13

15. Capitolo 3
Analisi dei dati
L’analisi dei dati `e mirata a capire quali sono effettivamente i dati dispo-
nibili in OpenSky, utili all’analisi finale. Per avere un metro di paragone,
sono stati considerati anche i dati di EUROCONTROL. EUROCONTROL `e
un’organizzazione intergovernativa, civile e militare cui partecipano 41 Stati
europei e di Paesi limitrofi e il cui scopo principale `e di sviluppare e mante-
nere un efficiente sistema di controllo del traffico aereo a livello europeo [17].
Tra le altre cose, raccoglie i dati sui voli, ma l’accesso al database ha delle
limitazioni. EUROCONTROL raccoglie molti tipi di dati diversi, per questo
lavoro sono stati considerati i dati di tipo DDR2.
3.1 I primi passi
Ogni giorno, durante il periodo estivo, in Europa viene pianificata una me-
dia di circa 30 mila voli IFR, con un picco nel fine settimana e nei giorni
festivi. IFR `e l’acronimo di Instrumental Flight Rules; queste, stabiliscono
una serie di norme che permettono ai piloti di volare anche in condizioni di
scarsa visibilit`a. Con una prima analisi si `e cercato di capire la quantit`a di
voli (per singola giornata) “descritti” in OpenSky, senza doversi appoggiare
a dati esterni. Nel database di OpenSky, l’attributo IFR `e presente nella
tabella velocity data4, tuttavia si `e scoperto non essere affidabile; soltanto
una piccola percentuale dei voli, inviano ai sensori questa informazione. A
prova di ci`o `e stato fatto un primo confronto sui dati del giorno 26/05/2017.
Dalla pianificazione di EUROCONTROL risultavano, per questa giornata,
32001 voli, mentre nel database di OpenSky (tra quelli con attributi IFR)
14

16. ne risultavano soltanto 4448, cio`e poco meno del 14%. Per questo motivo
l’unica alternativa `e stata quella di verificare quali tra i voli programmati da
EUROCONTROL, trovavano una corrispondenza in OpenSky.
Dovendo confrontare i due database si sono, innanzitutto, cercati i dati in
comune. Viene riportato un piccolo schema che mette a paragone i campi
principali (quelli effettivamente utili) dei due database.
Tabella 3.1: Confronto dati
EUROCONTROL OpenSky
Flight ID
Non contiene un campo “Flight ID”. I voli
vengono identificati dal campo “icao24”.
Callsign
Questo dato `e in comune ai due database ed
`e l’unico dato che permette di confrontarli in
maniera univoca. Il database OpenSky permette
valore NULL e non c’`e un controllo sulla stringa
(in vari casi `e presente la stringa “00000000”)
quindi il confronto in alcuni casi diventa difficile.
Origin
In questo caso si intende l’aeroporto di origine.
Nel database OpenSky non sono presenti
queste informazioni. Si pu`o ricavare il paese di
origine del volo dalle coordinate. Si considera
il messaggio con valore “time”pi`u piccolo e
dal valore delle coordinate si ricava il paese.
Questo, essendo un dato ricavato potrebbe non
essere corretto. In base alla copertura dei sensori,
il primo messaggio captato potrebbe non
corrispondere all’inizio della rotta.
Destination Vale lo stesso discorso dell’origine.
Date
La data `e presente nel database OpenSky in
formato unix timestamp
Arrival Time
Non `e presente questo dato nel database
OpenSky. Si pu`o provare a confrontare il valore
“time”dell’ultimo messaggio inviato dall’aereo
(nei casi on ground).
Airline
Dal callsign si pu`o ricavare la compagnia aerea.
I primi 3 caratteri vanno confrontati con un
database contenente la lista delle compagnie.
15

17. Aircraft Type
Questo campo non `e presente nel database
OpenSky. Sono disponibili le dimensioni del
velivolo, quindi si pu`o cercare di ricavare la
tipologia, oppure confrontare l’indirizzo ICAO con
qualche database contenente queste
informazioni.
Route Length
Questo campo non `e presente nel database
OpenSky. Si pu`o cercare di ricavare questo dato
ricostruendo l’intera rotta del volo (non sempre
disponibile) e poi valutarne la lunghezza.
Come indicato, oltre la data, l’unico dato in comune `e il callsign che per`o pu`o
essere NULL in OpenSky. Questo significa che potrebbero esserci dei voli i
cui messaggi vengono captati da OpenSky ma che senza identificativo non
possono essere confrontati. Scopriremo nella prossima sezione che al fine del
puro conteggio di voli disponibili, si riuscir`a a trovare qualche corrispondenza
(non univoca) grazie all’indirizzo ICAO a 24bit (icao24). Nonostante sia
soltanto uno il campo in comune, si riesce a fare un buon confronto che
verr`a dettagliatamente spiegato successivamente. Vedremo quali sono state
le scelte nell’eliminazione di dati superflui e quali sono state le integrazioni
di dati esterni, sempre gratuiti.
3.2 Le analisi
L’obiettivo di questa analisi `e di ricavare, a partire dai voli presenti nel da-
tabase DDR2(cio`e quello ricavato da EUROCONTROL), il numero di quelli
presenti anche nel database di OpenSky. L’idea di partenza `e di analizzare
i dati di una singola giornata per capire la quantit`a di voli effettivamente
disponibili. A tale scopo si `e scelto di creare uno script che fornir`a in output:
• Il numero di voli presenti sia in OpenSky che in EUROCONTROL
• La percentuale dei voli di EUROCONTROL presenti anche in OpenSky
Nelle tabelle seguenti viene descritto, passo per passo, il funzionamento dello
script e vengono indicati i risultati ottenuti dall’analisi del giorno 25 agosto
2017 (giorno scelto in modo casuale).
16

18. 3.2.1 Scelta dei dati
Nella prima parte ci si `e concentrati nell’eliminazione dei dati ritenuti inutili
sia nel database di EUROCONTROL che in quello di OpenSky. La scelta
sull’utilit`a dei dati `e stata fatta considerando le future analisi da effettuare
(qualsiasi scelta effettuata verr`a motivata).
EUROCONTROL
File di input:
• 20170825.exp2 contenente tutti i dati sui voli del 25 agosto in un
formato analogo al pi`u conosciuto CSV
• AirlineAirportInDDR2.xlsx (scheda Airline) contenente la lista delle
compagnie che hanno voli in programma. Anche questa fornita da
EUROCONTROL ed `e unica per tutta la stagione “Summer 2017”
Tabella 3.2: Dati EUROCONTROL
Step Descrizione Step
N° voli
eliminati
N° voli
rimanenti
Note
1
Import file
20170825.exp2
36686 N° voli iniziali
2
Eliminazione voli
senza compagnia
aerea e quelli di
compagnie senza
voli programmati
6896 29790
In questo lavoro,
verranno analizzati soltanto i
voli di compagnie pianificate.
Il file AirlineAirportInDDR2
contiene la lista delle compagnie
scheduled. Viene confrontato
il codice ICAO delle
compagnie e vengono
mantenuti soltanto i dati utili.
17

19. Table 3.2 continued from previous page
3
eliminazione voli con
origine o destinazione
“ZZZZ”
1 29789
ZZZZ viene inserito quando
non esiste un codice ICAO
dell’aeroporto di origine/desti-
nazione o quando non
si conoscono alcuni dettagli
del volo. Non si `e interessati
a questo tipo di dato perch´e
non si pu`o sapere se si trova
in Europa.
4
Vengono fusi i voli
con scalo in un
unico volo
588 29201
Verranno successivamente
divisi nell’analisi di origine
e destinazione. Per uniformare
questi dati con quelli di
OpenSky, i voli con scalo
vengono considerati come
singolo volo in modo da
agevolare il confronto tra i dati.
Numero voli utili: 29201
OpenSky
File di input:
• 25agosto.txt di cui la creazione viene spiegata in seguito a questo elenco
• AirlineAirportInDDR2.xlsx (scheda Airline) contenente la lista delle
compagnie che hanno voli in programma (la stessa usata nella sezione
EUROCONTROL)
25agosto.txt `e un file creato tramite un’interrogazione SQL al database di
OpenSky. Il database di OpenSky associa ad ogni record in esso contenuto
(quindi ad ogni messaggio ricevuto dai sensori), un indirizzo icao24 (stringa a
24 bit che identifica univocamente il transponder MODE S di un aeromobile)
ed un callsign (codice la cui prima parte di tre lettere `e il codice ICAO che
identifica la compagnia aerea, mentre la seconda parte `e una stringa alfanu-
merica di uno, due, tre o quattro caratteri). La coppia (icao24, callsign) `e
in grado di identificare univocamente un volo e tramite la query SQL vengo-
no, appunto, selezionate tutte le coppie univoche memorizzate, riferite al 25
18

20. agosto. Il solo icao24 non `e sufficiente perch´e un aereo che effettua un volo
di andata e ritorno ha lo stesso icao24 (e callsign diverso).
Tabella 3.3: Dati OpenSky
Step Descrizione Step
N° voli
eliminati
N° voli
rimanenti
Note
1
Import file
25agosto.txt
103959
Il campo callsign
ammette valore
NULL, quindi il file
contiene anche tutte
le coppie
(icao24,NULL).
2
Vengono eliminati i dati
“sporchi”, cio`e callsign
contenti spazi all’interno
della stringa, callsign<=3
o >=8 (i callsign sono
formati da 3 caratteri
che identificano la
compagnia e altri 2, 3 o 4
caratteri)
2046 101913
3
vengono eliminati (ma
salvati in un altro file
“OpenSkyNULL”) i voli
con callsign NULL o vuoto.
45811 56102
4
viene confrontata la
colonna appena creata
con il file delle compagnie
scheduled e vengono
tenute solo queste
20296 35106
Come per il file di
EUROCONTROL,
vengono tenuti
soltanti i dati di
interesse per analisi
successive.
Numero voli utili: 35106
In seguito a questa prima analisi i dati sono pronti per essere confrontati.
La seconda parte dello script si occuper`a del confronto dei dati e di fornire
l’output.
19

21. 3.2.2 Confronto callsign
In questa parte vengono confrontati i dati precedentemente ricavati. Vengo-
no eseguiti due tipi di confronto: il primo sulla base del callsign, il secondo
sulla base del codice di registrazione (nei casi in cui il callsign `e NULL). Nei
dati di EUROCONTROL questo secondo dato `e disponibile, mentre Open-
Sky non lo fornisce (al momento del laovoro non lo forniva, mentre ad oggi `e
disponibile), per questo motivo viene ricavato grazie ad altre risorse reperi-
bili gratuitamente in rete [5]. In particolare, viene utilizzato il file BaseSta-
tion.xslx contenente, per ogni aeromobile, il codice di registrazione, il tipo
(e il codice del tipo) e la compagnia aerea proprietaria. Questo file `e “una
raccolta” di dati sugli aeromobili. I confronti eseguiti vengono riassunti nelle
tabelle sottostanti.
Primo confronto:
Tabella 3.4: Confronto dati - Prima parte
Step Descrizione Step
N° voli
Eurocontrol
N° voli
OpenSky
N° voli
riscontrati
Note
1
Eliminazione
compagnie
non scheduled
da BaseStation
29201 35106
Vengono eliminati
tutti gli aeromobili
di propriet`a di
compagnie con voli
non programmati
2
Integrazione
dei dati di
OpenSky con
quelli di
BaseStation.
Se l’icao24
corrisponde,
vengono
copiati in
OpenSky il
codice del
tipo di aereo
e il codice di
registrazione
29201 35106
Gli aeromobili
senza corrispondenza
nel file BaseStation
avranno i campi
aggiunti, vuoti.
20

22. 3
Primo
confronto sulla
base del
callsign
29201 35106 22161
Ricavo il numero di
voli presenti sia in
EUROCONTROL
che in OpenSky da
cui posso ricavarne
la percentuale
4
Eliminazione
da entrambi i
database dei
voli non
riscontrati (i
dati eliminati da
EUROCONTROL
vengono tenuti
in memoria per
il secondo
confronto)
22161 22161
A questo punto
vengono salvati due
file contenenti
rispettivamente i
dati utili di
EUROCONTROL e
i dati utili di
OpenSky (salvati
con il nome
(EURO e
OPENSKY). I
file avranno la stessa
dimensione di righe
e conterranno
informazioni sugli
stessi voli.
5
Calcolo della
percentuale
dei voli
presenti in
entrambi i
database
22161 22161
Percentuale: 75.9%
Rapporto tra i voli
utili di
EUROCONTROL
(29201) e i voli
presenti in OpenSky
(22161)
21

23. 6
I voli di
EUROCONTROL
con scalo, che
erano stati fusi
per facilitare il
confronto,
vengono divisi.
22454 22161
I voli descritti nei
due file sono sempre
gli stessi. In
OpenSky i
voli con scalo
verranno divisi
successivamente,
quando si avr`a a
disposizione
l’origine e la
destinazione
Percentuale voli riscontrati dal callsign: 75.9%
Nello schema in figura 3.1 viene riportato uno schema riassuntivo del processo
appena descritto.
22

24. Figura 3.1: Schema riassuntivo del primo confronto
Secondo confronto:
Vengono confrontati il sottoinsieme del file di EUROCONTROL con i voli
non ancora riscontrati, creato allo step 4 della tabella 3.4 e il file Open-
SkyNULL creato allo step 3 della tabella 3.3 al quale vengono integrati dei
dati.
23

25. Tabella 3.5: Confronto dati - Seconda parte
Step Descrizione Step
N° voli
Eurocontrol
N° voli
OpenSky
N° voli
riscontrati
Note
1
Integrazione dei
dati di
OpenSkyNULL
con quelli di
BaseStation
(come step 2
della tabella 3.4).
Vengono
eliminati i voli
senza codice di
registrazione
perch´e non
confrontabili
6747 11515
2
Vengono
confrontati la
compagnia
aerea, il codice
del tipo di aereo
e il codice di
registrazione
6747 11515 1017
La terna confrontata,
non identifica
univocamente un
volo. Un volo di
andata e ritorno sar`a
identificato dalla
stessa terna (`e il
callsign a renderli
univoci). Per essere
sicuri che il volo sia
proprio quello di
EUROCONTROL,
bisognerebbe
analizzare la direzio-
ne di percorrenza
della tratta.
24

26. 3
I file OPENSKY e
EURO creati
allo step 4 della
tabella 3.4,
vengono integrati
con i voli
appena ricavati
dal secondo
confronto
23471 23178
4
Calcolo della
percentuale dei
voli presenti in
entrambi i
database
23471 23178
Rapporto tra i voli
utili di
EUROCONTROL
(29201) e i voli
presenti in OpenSky
considerando anche
i voli con callsign
NULL(23178)
Percentuale dei voli riscontrati: 80.4%
Questo confronto `e da considerarsi corretto, nel senso che sicuramente il volo
riscontrato si trova nel database di OpenSky. Non avendo, per`o, il callsign,
la terna confrontata `e la stessa sia per un volo di andata che per il corri-
spettivo volo di ritorno. In ogni caso, la corrispondenza si aggira attorno al
5% e non avendo il callsign, non si possono integrare i dati di questi voli con
informazioni su origine e destinazione (step successivo), quindi non ha senso
considerarli per le analisi successive.
Nello schema in figura 3.2 viene riportato uno schema riassuntivo del processo
appena descritto.
25

27. Figura 3.2: Schema riassuntivo del primo confronto
3.2.3 Origine e destinazione
In questo caso l’obiettivo `e di riuscire ad associare al maggior numero di voli
l’origine e la destinazione. Sono state considerati due approcci diversi.
26

28. Ricerca da fonti esterni
Nel primo caso, viene utilizzato un file denominato FlightRoute.xlsx creato da
un database gratuito reperibile, anch’esso, in rete [5]. Questo file contiene il
callsign del volo e la rotta comprensiva di eventuali scali. Essendo il callsign,
l’elemento che identifica i voli, tutti i dati precedentemente analizzati, con
callsign NULL non vengono presi in considerazione. Essendo un file gratuito,
di cui non si pu`o essere certi della correttezza del contenuto, verr`a eseguito un
confronto con i campi origine e destinazione del file 20170825.exp2 utilizzato
nella sezione “EUROCONTROL”.
L’input di questo script sono:
• Il file FlightRoute.xlsx
• Il file OPENSKY creato allo step 4 della tabella 3.4
Tabella 3.6: Dati di origine e destinazione
Step Descrizione Step
N° voli
OPENSKY
N° voli
integrati con
FlightRoute
Note
1
Integrazione dei
dati del file
OPENSKY
con i dati di
FlightRoute.xlsx,
confrontando il
callsign
22161 19566
Viene confrontato il
callsign e vengono
copiati nel file OPENSKY
i dati di origine,
destinazione e scalo in
(codice ICAO degli
aeroporti). Viene
creato il file
OPENSKY OD
2
Calcolo della
percentuale dei
voli integrati
Percentuale: 67%
Rapporto tra i voli
integrati (19566) e i
voli totali iniziali di
EUROCONTROL
(29201)
3
Divisione dei voli
con scalo nel file
OPENSKY OD
per uniformarli
con quelli di
EUROCONTROL
20040
27

29. 4
Confronto tra
l’origine e la
destinazione del
file OPENSKY OD
e quella del file
EURO
Questo confronto
viene fatto perch´e,
essendo il file
FlightRoute un file
gratuito, non ci
assicura la
correttezza dei dati.
5
Calcolo della
percentuale dei
voli con origine e
destinazione
corretti in
OPENSKY OD
17765 Percentuale: 60.8%
6
Esportazione dei
file di
EUROCONTROL
e OpenSky dopo
l’analisi
Il file EURO
sar`a un sottoinsieme
di quello iniziale. Il file
OPENSK OD, rispetto
a quello iniziale
(25agosto.txt) `e
integrato con:
compagnia aerea,codice
di registrazione
dell’aeromobile,
codice del tipo di
aeromobile, origine e
destinazione.
Percentuale dei voli di OpenSky di cui si ha origine e destinazione corretti:
60,8%
Sono 17765 i voli di cui si `e trovata origine e destinazione tramite confronto
con il file FlightRoute. Nello schema in figura 3.3 viene riportato uno schema
riassuntivo del processo appena descritto.
28

30. Figura 3.3: Schema riassuntivo della ricerca di origine e destinazione
Ricerca da confronto di coordinate
Il file ICAOexpansion.csv contiene i codici ICAO degli aeroporti e i nomi degli
aeroporti (creato tramite informazioni reperite in rete [15]). A questo file sono
state aggiunte le coordinate degli aeroporti. Tramite le API Google Places
[3] , e il servizio Nearby search requests, si invia una richiesta HTTP al server
29

31. di google Maps fornendo come parametri: le coordinate, il raggio massimo
in metri, la parola chiave “aeroporto”. La risposta fornisce l’aeroporto pi`u
vicino.
In questo caso invece, l’idea `e stata quella di selezionare il primo e l’ulti-
mo messaggio inviato dagli aerei per ogni volo presente sia nel database di
OpenSky che in quello di EUROCONTROL (22161 voli). Dei messaggi se-
lezionati, sono state confrontate le coordinate con le coordinate della lista
degli aeroporti (ICAOexpansion.csv), scegliendo come aeroporto di transito
quello a distanza minima. La distanza tra coordinate necessita di un calcolo
particolare[8].
Siano φ1, λ1, φ2, λ2, la latitudine (φ) e la longitudine (λ) rispettivamente dei
punti A e B; sia ∆λ la differenza tra le due longitudini e ∆σ la distanza
angolare tra i due punti considerati (A,B), la distanza angolare tra A e B `e
data dalla formula:
∆σ = arccos {sinφ1sinφ2 + cosφ1cosφ2cos∆λ}
che fornisce la distanza in radianti o raggi terrestri. Basta moltiplicare il
risultato ( ∆σ ) x 6371 (raggio della Terra arrotondato) per ottenere la
distanza in km. Successivamente `e stato fatto un confronto con i dati del
file EURO (con i codici ICAO degli aeroporti) e si sono ottenuti i seguenti
risultati: Su 29201 voli:
• origine trovata e verificata: 12595
• destinazione trovata e verificata: 12417
• coppie origine-destinazione verificata: 7098
Sono 7098 voli trovati tramite confronto coordinate e vengono salvati nel file
OPENSKY OD2.
Il problema di questo approccio `e identificare i voli con scalo perch´e vanno
selezionati il primo e l’ultimo messaggio in base al callsign (che `e lo stesso per
i voli con scalo). Diventa quindi difficile trovare i valori intermedi. Andrebbe
cercato il minimo nel caso in cui il tempo trascorso dall’ultimo messaggio
sia pari ad un certo valore n. Si otterrebbero probabilmente dei dati errati
a causa dei “buchi” nelle traiettorie presenti nei dati di OpenSky: in alcuni
casi potrebbe trascorrere un certo tempo tra due messaggi, soltanto perch´e
la zona non `e coperta da sensori. Nello schema in figura 3.4 viene riportato
uno schema riassuntivo del processo appena descritto.
30

32. Figura 3.4: Schema riassuntivo della ricerca di origine e destinazione
Unione delle soluzioni
Facendo un confronto tra i due approcci i risultati ottenuti sono i segeuenti:
31

33. • 6109 coppie OD trovate in entrambi i casi
• 11656 coppie OD trovate tramite confronto con file FlightRoute
• 989 coppie OD nuove trovate tramite confronto delle coordinate
Tramite la fusione dei file creati dai due diversi confronti (OPENSKY OD e
OPENSKY OD2) si `e creato il file OPENSKY DEF come mostrato in figura
3.5.
Figura 3.5: Schema riassuntivo della ricerca di origine e destinazione
A questo punto i dati vengono integrati ulteriormente. Ad ogni volo (di
OpenSky) a cui `e stata precedentemente aggiunta l’origine e la destinazione,
viene anche aggiunto il nome dell’aeroporto e le coordinate (in base al codice
ICAO dell’aeroporto). Successivamente, sempre partendo dallo stesso file
vengono forniti in output:
• i voli suddivisi per coppie origine-destinazione (viene indicato il numero
di voli per ogni coppia)
• i voli suddivisi per compagnia e per coppie origine-destinazione (viene
indicato il numero di voli per ogni compagnia e ogni coppia)
• i voli suddivisi per compagnia (viene indicato il numero di voli per ogni
compagnia)
32

34. 3.2.4 Creazione delle traiettorie
I dati di OpenSky di partenza, confrontati finora comprendevano soltanto le
coppie (icao24,callsign). Ad ogni coppia sono in realt`a associati centinaia di
record che per fino a questo punto, non erano necessari. Per la creazione delle
traiettorie, invece, sono necessari ulteriori dati rispetto all’icao24 e il callsign,
quindi si prosegue scaricando tutti i dati di tutti gli aerei, disponibili nella
tabella state vectors data4 del database di OpenSky, per il giorno desiderato.
In realt`a, a causa dell’enorme quantit`a di dati, si `e deciso di seguire le seguenti
regole che portano ad una diminuzione considerevole del volume dei dati:
• vengono esclusi i record con callsign NULL
• vengono esclusi i record con latitudine e longitudine NULL
• viene prelevato soltanto un record ogni 15 secondi (dalle 0.00 alle 23.59)
La quantit`a di dati scaricati per la giornata considerata `e di 4,7GB. Su questi
dati sono state eseguite le seguenti operazioni:
• vengono eliminati i record appartenenti ai voli non presenti nel file
OPENSKY DEF
• vengono uniti i dati di origine e destinazione del file OPENSK DEF,
con quelli appena scaricati (e non eliminati).
In questo modo, per ogni volo di cui `e stata trovata l’origine e la destinazio-
ne, avr`o i dati necessari per tracciare la rotta. I dati necessari per tracciare
la rotta in 2D sono la latitudine e la longitudine che nel database OpenSky
vengono memorizzate seguendo lo standard WGS-84 [18]. Volendo aggiun-
gere la terza dimensione, va considerata anche l’altitudine che viene espressa
in metri nel database OpenSky. In sostanza di tutti i dati forniti da Open-
Sky (colonne: “time”,“icao24” , “lat”, “lon” , “velocity”,“heading”, “ver-
trate”,“callsign” ,“onground” , “alert” , “spi”, “squawk” , “baroaltitude”,
“geoaltitude” , “lastposupdate” , “lastcontact”, “hour”) vengono utilizzati:
• la coppia (icao24,callsign) che identifica il volo
• la latitudine e la longitudine (lat,lon) per tracciare la rotta in 2D
Per tracciare le rotte viene utilizzato il software QGIS [6]. Si pu`o vedere
un esempio di utilizzo nella figura 3.1. In questo caso le traiettorie non
hanno buchi e sono facilmente confrontabili. A parte il tragitto rosso, le
altre traiettorie si suddividono sostanzialmente in 2 tragitti.
33

35. Figura 3.6: Voli Lufthansa tra Francoforte e Berlino (16 voli)
34

36. Capitolo 4
Analisi delle traiettorie
4.1 Clustering
Il clustering, in generale, ha l’obiettivo di raggruppare entit`a con caratteristi-
che simili. In questo caso, si vogliono trovare traiettorie simili, confrontando
la distanza tra i set di punti che le compongono. Il primo passo consiste
nel creare una matrice con le distanze tra tutte le traiettorie. Per calcolare
la distanza tra le traiettorie, viene utilizzata la distanza di Hausdorff grazie
alla quale `e possibile calcolare la distanza tra due sottoinsiemi di uno spazio
metrico. In particolare:
Dato uno spazio metrico X e due sottoinsiemi A, B ⊆ X si definisce distanza
di Hausdorff tra A e B la quantit`a
d(A, B) := max{e(A, B), e(B, A)}
con d(x, A) := inf
y∈A
d(x, y) distanza di un punto dall’insieme A,
ed e(A, B) := sup
x∈A
d(x, B) eccedenza di A su B
Nel caso considerato, i sottoinsiemi sono i set di punti (latitudine, longitudi-
ne) che compongono le tratte.
4.1.1 DBSCAN e la scelta dei parametri
In seguito ad una ricerca nella letteratura, si `e deciso, per effettuare il clu-
stering, di utilizzare l’algoritmo DBSCAN [10] [11] [12] [14] . Il vantaggio di
35

37. utilizzare questo tipo di algoritmo `e di non dover indicare a priori il numero
di cluster. DBSCAN necessita di due parametri: ε (eps) e minPts (oltre che
della matrice delle distanze precedentemente creata).
minPts
minPts `e, banalmente, il numero minimo di punti (in questo caso insieme
di punti definito come traiettoria) richiesti per formare un cluster; `e facile
pensare che questo parametro vada settato a 1. Il fatto di poter settare ad
1 questo parametro `e un vantaggio che permette di creare singoli cluster con
le traiettorie che in un caso generale potrebbero essere considerate rumore.
ε
Ogni velivolo deve avere, attorno a s´e, un margine di spazio libero in cui
nessun altro pu`o volare. Per questo motivo due traiettorie che in teoria
dovrebbero coprire lo stesso identico spazio, nella realt`a possono differire.
A seguito di ci`o, `e stato scelto, in accordo con le regole di sicurezza da
mantenere in volo, di considerare due traiettorie uguali se hanno una distanza
massima di 20km. Sfortunatamente, la distanza tra le traiettorie, calcolata
in precedenza tramite la distanza di Hausdorff, fornisce la distanza Euclidea
(in Degrees). Per questo motivo, affinch´e si possa imporre il vincolo sulla
distanza, bisogna attuare una conversione. Un grado di latitudine `e pari a
110.57km, quindi 1km = ε
110.57km
. Il valore della ε sar`a quindi ε = 20km
110.57km
.
In seguito ad alcuni test e facendo delle ricerche nella letteratura [13] si `e
deciso di rilassare il vincolo dei 20km e si `e scelto un valore di ε=0.3.
4.1.2 Una prima istanza
Per capire bene il funzionamento dell’algoritmo, si `e deciso di iniziare con
un’istanza ridotta (una sola coppia origine-destinazione) del problema. Si `e
scelto il caso decritto nella figura 4.1. Il clustering ottenuto `e il seguente, in
cui in ascissa e ordinata ci sono latitudine e longitudine :
36

38. Figura 4.1: Clustering traiettorie Francoforte-Berlino di voli Lufthansa
4.1.3 Generalizzazione del problema
Dopo aver risolto il problema per un’istanza ridotta del problema, si `e scelto
di generalizzare la soluzione, cercando una clusterizzazione per ogni traiet-
toria. Per clusterizzare le varie traiettorie, si considerano tutte le possibili
coppie origine-destinazione e si esegue l’algoritmo proposto in precedenza. In
caso di necessit`a si possono scegliere soltanto le coppie origine-destinazione
desiderate (questa selezione porta ad un alleggerimento computazionale). Di
seguito i passi
• selezione delle traiettorie percorse da almeno 2 voli
• selezione dei dati (coordinate e callsign) dei voli associati alle traiettorie
selezionate, dal datababse OpenSky
• suddivisione dei dati in base alla coppia origine-destinazione
• creazione di un vettore contenente le matrici delle distanze (una per
ogni coppia OD)
• per ogni coppia OD: applicazione dell’algoritmo DBSCAN
• integrazione del file OPENSKY DEF con il numero del cluster: ad ogni
volo di ogni coppia origine-destinazione viene associato il numero del
cluster
37

39. 4.1.4 Problemi riscontrati
Il fatto di avere dei buchi nelle traiettorie porta ad un errore sulle distanze
tra le varie traiettorie calcolate con la distanza di Hausdorff. Un errore
sulla distanza porta, di conseguenza, ad un probabile errore sul clustering.
Per evitare di utilizzare dati “non corretti” si `e deciso di calcolare, per ogni
traiettoria la distanza tra ogni punto e il suo successivo e di considerare la
distanza massima. Per ogni coppia OD si `e considerata soltanto la traiettoria
con il “buco pi`u grande” e si `e calcolata la percentuale di dati mancanti
rispetto alla lunghezza totale della traiettoria (in km). Quindi:
distanza% = max distanza tra ogni punto e il successivo
lunghezza totale della traiettoria
Si sono eliminati tutti i voli con una distanza% > 20, cio`e se in una traiettoria
manca pi`u del 20% di dati consecutivi rispetto alla lunghezza totale, questa
non viene considerata perch´e potrebbe portare a risultati errati in fase di
clustering.
Viene riportato, in figura 4.2, un esempio di clustering su dati incerti. `E
evidente che non si pu`o conoscere il vero andamento delle traiettorie, quindi,
seppur il clustering potrebbe sembrare ragionevole, non si pu`o essere certi
della validit`a.
38

40. Figura 4.2: Esempio di clustering in presenza di buchi nelle traiettorie
Viene inoltre riportato, in figura 4.3, il caso di un clustering che, “ad occhio”
sembrerebbe errato. In effetti la distanza calcolata tra le traiettorie, a causa
dei buchi, `e maggiore di quella che a traiettorie complete, verrebbe misu-
rata(le traiettorie sembrano pi`u o meno sovrapporsi) e per questo motivo il
clustering fornisce in output due cluster invece del probabile singolo cluster
che logicamente ci si aspetterebbe.
39

41. Figura 4.3: Esempio di clustering in presenza di buchi nelle traiettorie
4.2 Analisi delle traiettorie
Il primo passo per eseguire le analisi desiderate, `e stato quello di prelevare dal
database di OpenSky, tutti i dati necessari. Sono stati presi in considerazione
i voli di Agosto 2017, Settembre 2017 e alcune giornate di Luglio 2017 (dal 20
al 31). La quantit`a di dati scaricata `e stata di circa 400GB (in media per una
giornata i dati sono circa 5,5GB). Con questi dati `e stato possibile effettuare
un analisi storica delle traiettorie. Considerando i dati di una sola giornata,
in molti casi si trova soltanto un volo per coppia origine-destinazione che non
permette di fare alcuna considerazione a riguardo.
40

42. 4.2.1 Gestione dei dati
Vista la mole di dati e le risorse computazionali limitate, si `e deciso di sud-
dividere i dati in gruppi (da 600 coppie origine-destinazinone) e di fare le
stesse analisi nei vari insiemi. Rispetto all’analisi descritta nel capitolo sul
clustering, la strategia seguita `e stata leggermente diversa. In questo caso,
per ogni giornata, sono stati eliminati, sin da subito, i voli con “buchi” nella
traiettoria superiore al 20% dei dati totali. Successivamente si sono aggregati
i dati. Per ogni coppia origine-destinazione rimasta (4794 totali) in seguito
alla scrematura dei dati iniziale:
• sono stati uniti tutti i voli di ogni singola giornata
• `e stato aggiunto l’attributo “data” per poter identificare univocamente,
voli di giornate diverse, con stesso callsign.
Ogni possibile coppia origine-destinazione sar`a composta da decine di voli
(centinaia in alcuni casi). Una volta preparati i dati, `e stato fatto il clustering.
Il primo passo del clustering prevede la creazione della matrice delle distanze.
Per le istanze pi`u piccole, il tempo di computazione `e dell’ordine dei secondi,
per le coppie origine-destinazione pi`u affollate, il tempo cresce notevolmente
(ordine dei minuti) . Per 600 coppie origine-destinazione prese in modo
casuale, il calcolo della matrice delle distanze ha richiesto circa 19 ore. Una
volta in possesso delle matrici, si `e effettuato il clustering come spiegato nel
capitolo 4.1. Dopo aver effettuato il clustering, le coordiante dei voli sono
diventate superflue (se non per le eventuali rappresentazioni grafiche). Per
questo motivo, si `e scelto un solo record per ogni volo al quale, ovviamente,
`e stata precedentemente aggiunta un’indicazione sul cluster di cui fa parte.
Successivamente sono state scelte le analisi da effettuare.
4.2.2 Analisi e risultati
Di seguito l’elenco delle domande che ci si `e posti, in base alle quali sono
state fatte le analisi.
• Lo stesso volo (stesso callsign) esegue la stessa rotta in giornate diverse?
• Esiste una rotta che viene preferita da tutte le compagnie aeree?
• Una certa rotta `e preferita rispetto alle altre, dalla compagnie aeree in
alcuni orari?(mattina, pomeriggio, sera)
41

43. • Il tipo di aereo `e influente sulla scelta della traiettoria? (analisi possibile
nei casi in cui `e disponibile questo dato)
Comportamento di un volo in giornate diverse
Per eseguire questa analisi si `e preso un subset dei dati contenente soltanto il
callsign e il numero del cluster a cui `e stato assegnato il volo. Si `e verificato,
per tutte le traiettorie, se i voli con stesso callsign, in giornate diverse hanno
lo stesso numero di cluster. Inoltre sono stati salvati gli indici delle liste di
matrici che rispettano la richiesta, in questo modo `e semplice ricavare i dati
necessari per disegnare le traiettorie.
La percentuale di voli che hanno eseguito la stessa traiettoria nel corso dei
giorni presi in considerazione, `e pari al 35,13%.
Non `e da escludere che alcuni voli possano aver eseguito una traiettoria
diversa in una sola giornata (trascurabile su grandi numeri).
Da un’ulteriore analisi, si scopre che il 5% dei voli ha preso una sola volta
(in una sola giornata) una traiettoria diversa.
Infine si `e riscontrato che, per il 17,5% dei voli sono state scelte soltanto due
rotte diverse (il 5% precedente, `e un sottoinsieme di questo caso), mentre nel
47,37% dei casi sono state prese pi`u di 2 strade diverse. Un riassunto delle
percentuali `e riportato nel diagramma di figura 4.4
42

44. Figura 4.4: Percentuale voli in base al numero di traiettorie
Di seguito un esempio dei casi sopracitati
Caso con pi`u di 2 rotte diverse. Volo SXS18U da Dusseldorf ad Ankara,
ripetuto 74 volte.
Figura 4.5: Rotte volo SXS18U
Caso con una sola rotta. Volo DLH8WY da Bruxelles a Monaco, ripetuto 24
volte.
Figura 4.6: Rotte volo DLH8WY
Caso con un solo volo con rotta diversa. Volo EWG4N da Monaco ad
Amsterdam ripetuto 61 volte.
43

45. Figura 4.7: Rotte volo EWG4N
Questo ultimo esempio dimostra che in alcuni casi, seppur risulti che per un
volo `e stata percorsa una rotta diversa (tratto verde nella figura), questa si
rivela simile alle altre.
Si conclude che su distanze piccole (es. figura 4.5) e distanze medie (es.
figura 4.6) le compagnie tendono a mantenere le stesse traiettorie, mentre
diventano disuguali su tragitti pi`u lunghi (es. figura 4.4).
Scelta delle rotte da parte delle compagnie
Per ogni coppia origine-destinazione sono stati considerati tutti i voli di tutte
le compagnie aeree. In base al cluster assegnato ai vari voli, si `e calcolata
una percentuale definita sulla quantit`a di volte che una certa traiettoria `e
stata percorsa. La rotta maggiormente scelta, cio`e quella rappresentata dal
cluster pi`u ricco, viene rapportata al numero totale di rotte. Ad esempio,
per una coppia origine-destinazione con 3 cluster di cui il primo contiene 15
voli, il secondo 6 voli ed il terzo 12 voli, si avr`a che la rotta rappresentata
dal primo cluster (quella pi`u ricca) sar`a stata scelta nel 45% dei casi, cio`e
15
15+12+6
% .
I risultati ottenuti sono i seguenti:
• nel 12,5% dei casi la traiettoria scelta `e la stessa per tutte la compagnie
aeree (esiste un solo cluster)
• nel 39,9% dei casi la traiettoria maggiormente percorsa, viene scelta
dall’ 80% al 99,9% delle volte.
44

46. Bisogna notare, inoltre, che nel primo caso ricadono molte coppie origine-
destinazione ricche di voli. Questo risultato `e positivo al fine di riconoscere
eventuali comportamenti, perch´e `e facile aspettarsi che in presenza di pochi
voli si possa avere una sola rotta, mentre non `e cos`ı ovvio per il caso contrario.
Viene riportato un esempio di coppia origine-destinazione nella quale tutte le
compagnie seguono la stessa traiettoria (cio`e il caso appena descritto). Il caso
raffigurato si riferisce alla traiettoria D¨usseldorf-Norimberga. Sono ben 3 le
compagnie aeree (rappresentate da 3 colori diversi) che operano su questo tra-
gitto e i differenti callsign sono 10 (BER47CL, BER5JZ, BER6770, BER6776,
EWG7HW, EWG8CF, EWG91U, GWI7HW, GWI8CF, GWI91U).
Figura 4.8: Voli per la coppia origine-destinazione EDDL-EDDN
Nel 39,9% dei casi, cio`e quando le rotte candidate sono ¿1, si pu`o supporre che
ci sono delle traiettorie migliori, visto che le compagnie tendono a preferirle
rispetto alle altre. Il restante 47.6% non `e di interesse per questa analisi che
mira a capire quali sono le traiettorie maggiormente percorse.
Un ulteriore dettaglio considerato, `e l’orario del volo ed, a tale scopo, sono
state create della fasce orarie. Alla mattina corrisponde la fascia 4-13, al
pomeriggio corrisponde la fascia 14-19, alla sera corrisponde la fascia 19-3.
Per la distribuzione nelle varie fasce, viene considerato l’orario di partenza
dell’aereo. Ci si aspetta che le rotte percorse dipendano anche dall’orario,
visto che nei vari momenti della giornata, il traffico `e molto diverso. La sera il
numero di voli `e inferiore rispetto alle altre due fasce e permette una maggior
libert`a nella scelta della rotta. Un esempio di ci`o che `e appena stato descritto,
viene illustrato nelle figure 4.8 e 4.9. I due casi rappresentati raffigurano i
voli della mattina e della sera della tratta Stoccarda-Adalia e dimostrano il
fatto che la sera le traiettorie sono molto pi`u “rilassate”, mentre durante la
mattina le scelte sono pi`u rigide.
45

47. Figura 4.9: Voli Stoccarda-Adalia nella fascia mattutina
Figura 4.10: Voli Stoccarda-Adalia nella fascia serale
Per ogni coppia origine-destinazione, si sono creati dei sottoinsiemi sulla base
della fascia oraria e sono stati analizzati singolarmente. Per capire se alcune
traiettorie, in alcuni orari, vengono preferite, `e stata calcolata una percen-
tuale simile a quella del caso precedente. Il risultato ottenuto `e che nel 39,8%
dei casi, in una certa fascia oraria, viene scelta la stessa traiettoria da tutti i
voli nella coppia origine-destinazione, mentre nel 7,4% dei casi, la rotta pi`u
affollata viene scelta dall’80% al 99,9% delle volte.
Da questi risultati si pu`o dedurre che, in molti casi, la scelta della traiettoria
dipende dall’orario di pianificazione del volo.
46

48. Traiettorie in base al tipo di aereo
I dati sul tipo di aereo sono stati ricavati dal file BaseStation [5] e non si `e
sicuri che sia disponibile per tutti i voli.
Da questa analisi `e emerso che in alcuni casi, per lo stesso volo (stesso call-
sign), in giornate diverse, vengono utilizzati tipi di aereo differente. Pren-
dendo come esempio uno dei casi gi`a analizzati, illustrato in figura 4.7 (in
cui esiste un solo cluster), sia il volo GWI7HW che il volo GWI91U, utiliz-
zano aeromobili di tipo A320 e di tipo A319, nelle diverse giornate. Questi
due modelli di aereo, seppur diversi, presentano caratteristiche simili, ed `e
normale aspettarsi che non prendano strade differenti.
Un esempio pi`u significativo `e quello del volo Bruxelles - Zurigo illustrato in
figura 4.10. In questo caso, la stessa traiettoria, viene percorsa dalla com-
pagnia Swiss International Air Lines utilizzando ben 5 tipi di aereo diversi:
A319, A320, BCS1, E190, F100. Come si evince nella figura 4.10, non c’`e
una correlazione tra il colore (che indica un tipo di aereo) e la traiettoria. La
”strada” centrale viene percorsa, almeno una volta, da tutte le tipologie di
aereo.
Figura 4.11: Tipi di aereo diverso per lo stesso volo della stessa compagnia
Nel 67,5% dei casi sono stati usati aerei di tipo diverso per percorrere la stessa
traiettoria. Di questi, nel 57,2% dei casi la stessa traiettoria `e stata percorsa
da tutti i tipi di aereo. Le analisi effettuate portano a pensare che il tipo di
aereo non sia un dato importante per la scelta della traiettoria, almeno nel
caso di velivoli con caratteristiche simili e specialmente considerando soltanto
il caso in 2D.
47

49. Capitolo 5
Conclusioni
Dalle analisi effettuate ed in base alle considerazioni fatte finora, si pu`o con-
cludere, che sicuramente alcune delle compagnie seguono delle regole per la
scelta delle traiettorie. In molti casi si `e potuto notare che voli uguali seguono
la stessa traiettoria in giornate diverse, sintomo del fatto che probabilmente
sono state fatte delle pianificazioni.
Tra tutte le possibili rotte, ce n’`e sempre una pi`u conveniente in termini di
costi ed `e ovvio che le compagnie cercheranno sempre di ottimizzare i pro-
pri ricavi. Quando la traiettoria migliore non `e percorribile, bisogna cercare
un’alternativa che non sia troppo sconveniente. Sono molte le variabili in
gioco da dover equilibrare, come ad esempio le tasse (diverse in base ai paesi
sorvolati) e il carburante; inoltre esistono delle zone soggette a restrizioni di
volo, come ad esempio gli spazi militari che possono costringere a scegliere
strade, in alcuni casi, molto pi`u lunghe. Per far s`ı che una compagnia ae-
rea possa essere competitiva sul mercato, sar`a senz’altro importante, fare le
giuste valutazioni al fine di scegliere le traiettorie pi`u vantaggiose.
Tutte le considerazioni sono state fatte grazie all’utilizzo di dati gratuiti. Il
lavoro si poneva come obiettivo anche quello di capire se i dati DDR2 di
EUROCONTROL potessero essere sostituiti dai dati di OpenSky che hanno
libero accesso. Come spiegato nel capitolo dedicato, la raccolta dei dati da
parte dei sensori non avviene sempre nel modo corretto; in molti casi si sono
dovuti scartare dei voli per assenza di dati completi. Ovviamente questo
`e un limite che pu`o essere risolto in parte con l’aggiunta di sensori (resta
il problema delle zone coperte da acqua). In seguito alle analisi che si `e
riusciti a fare, si pu`o sostenere il fatto che per i voli di cui si hanno tutte le
48

50. informazioni (cio`e circa il 60%) i dati di OpenSky sono certamente un’ottima
fonte.
49

51. Bibliografia
[1] Associazione italiana gestori aeropor-
ti. https://www.assaeroporti.com/
aeroporti-italiani-confermato-il-trend-di-crescita-nel-2017.
[2] Eurostat statistics explained. http://ec.europa.eu/eurostat/
statistics-explained/index.php/Air_transport_statistics.
[3] Google maps nearby search. https://developers.google.com/
places/web-service/search#PlaceSearchRequests.
[4] Opensky network. https://opensky-network.org/.
[5] Planeplotter. http://planeplotter.pbworks.com/w/page/
17117301/Databases.
[6] Qgis - applicazione desktop gis. https://www.qgis.org/it/site/.
[7] R studio. https://www.rstudio.com/.
[8] Vialattea - distanza tra coordinate. https://www.vialattea.net/
content/2365/.
[9] J. M. Allen. Automatic dependent surveillance-broadcast (ads-b)
operations. U.S. Department of Transportation Federal Aviation
Administration, 2012.
[10] L. Basora, J. Morio, and C. Mailhot. A Trajectory Clustering Framework
to Analyse Air Traffic Flows. In SIDs 2017, 7th SESAR Innovation
Days, Belgrade, Serbia, Nov. 2017.
[11] P. C. Besse, B. Guillouet, J. M. Loubes, and F. Royer. Review and
perspective for distance-based clustering of vehicle trajectories. IEEE
50

52. Transactions on Intelligent Transportation Systems, 17(11):3306–3317,
Nov 2016.
[12] J.-G. Lee, J. Han, and K.-Y. Whang. Trajectory clustering: A partition-
and-group framework. In Proceedings of the 2007 ACM SIGMOD In-
ternational Conference on Management of Data, SIGMOD ’07, pages
593–604, New York, NY, USA, 2007. ACM.
[13] R. Marcos, O. Garc´ıa-Cant´u, and R. Herranz. A machine lear-
ning approach to air traffic route choice modelling. arXiv preprint
arXiv:1802.06588, 2018.
[14] R. Marcos, O. G. C. Ros, and R. Herranz. Combining visual analytics
and machine learning for route choice prediction. SIDs 2017, 7th SESAR
Innovation Days, 2017.
[15] Wikipedia. Codice aeroportuale icao — wikipedia, l’enciclopedia libera,
2017. [Online; in data 2-marzo-2018].
[16] Wikipedia. Controllo del traffico aereo — wikipedia, l’enciclopedia
libera, 2017.
[17] Wikipedia. Eurocontrol — wikipedia, l’enciclopedia libera, 2017.
[18] Wikipedia. Wgs84 — wikipedia, l’enciclopedia libera, 2017.
51