-
Notifications
You must be signed in to change notification settings - Fork 0
/
StMo_Analysekonzept.Rmd
239 lines (158 loc) · 13.5 KB
/
StMo_Analysekonzept.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
---
title: "StMo Analysekonzept"
author: "Corinna Grobe"
date: "2020-07-27"
output:
html_document:
df_print: paged
toc: true
toc_float:
collapsed: true
smooth_scroll: true
number_sections: true
fig_width: 8
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE,
warning = FALSE,
message = FALSE)
```
```{r libraries, echo = TRUE, include=FALSE, eval = TRUE, message = FALSE}
# session info
# -- R version 4.0.2 (2020-06-22)
# libraries
library(tidyverse) # Version ‘1.3.0’
library(dplyr) # Version ‘0.8.5’
library(ggplot2) # Version ‘3.3.0’
library(readxl) # Version ‘1.3.1’
library(stringr) # Version '1.4.0'
library(statR)
```
# Business Understanding
Die Kurzzeitprognose des Verkehrsaufkommens ist weithin als ein wichtiges Element intelligenter Verkehrssysteme (ITS) anerkannt, da die Genauigkeit der Prognosemethoden bis zu einem gewissen Grad die Leistung der Echtzeit-Verkehrssteuerung und des Verkehrsmanagements bestimmt. Im Rahmen eines beim Tiefbauamt des Kantons Zürich (TBA) laufenden Projekts sollen die Echtzeit-Daten der Verkehrsmessstellen auf Zürcher Kantonsstrassen als Open Government Data (OGD) zur freien Nutzung zugänglich gemacht werden. Die Analyse verschiedener Prognosemethoden soll ein potentieller Grundstein für mögliche nachfolgende Anwendungen sein.
## Ziel
Ziel ist es, diejenige Vorhersagemethode auszuwählen, welche unter Verwendung von historischen Messstellendaten am besten geeignet ist kurzzeitige Prognosen des Verkehrsaufkommens zu leisten.
## Fragestellung
Welches ist die am besten geeignete Verkehrsprognose-Methode für kurzzeitige Verkehrsprognosen im Zürcher Kantonsstrassennetz?
## Abgrenzungen
(1) Vorhersagehorizont: Kurzzeit → Verkehrsaufkommen (flow) mit Zeithorizont 1 Stunde
(2) Umfang der Vorhersage: Statisch → Zwei feste Messstellen auf Zürcher Kantonsstrassen
(3) Umwelt: Kantonsstrassen → nicht städtisch, aber auch nicht Autobahn
(4) Zielvariable: *flow* (Fahrzeuge/Stunde) auch bekannt als *intensity*
(5) Prädiktoren: Monat, Wochentag (Mo-So), Stunde vom Tag (24h), Feiertage und Ferien*
* In einem umfassenderen Modell könnten noch Baustellen und meteorologische Faktoren eingeschlossen werden
## Schlüsselpersonen & Risiken
### Schlüsselpersonen
**Dateneigentümerin:** Derzeit sind die Verkehrszähldaten einzig über die Besitzerin der Messtellen, dem Tiefbauamt des Kantons Zürich (TBA), zu beziehen. Die Dateneigentümerin ist somit die erste Schlüsselperson. Sie stellt die technische Infrastruktur, Datenerhebung sowie Datenlieferung bereit.
**Fachexperten:** Aufgrund ihrer Feldexpertise nehmen die Verkehrsdatenerfassung und die Gebietsleitung beim TBA ebenfalls Schlüsselrollen ein. Ihre tiefgreifenden Kenntnisse der Messstationen, der Messstellengebiete sowie der technischen Besonderheiten sind für ein solides Datenverständnis unabdingbar. Hinzukommt das Statistische Amt Kanton Zürich, welches seine Data Science Kompetenz in die Datenaufbereitung und Modellierung einbringt.
### Organisatorische Risiken
Es handelt sich um ein amtsübergreifendes Projekt zwischen dem Tiefbauamt und dem Statistischen Amt Kanton Zürich. Eine kollaborative Zusammenarbeit und kontinuierlicher Austausch sind zwingend nötig.
### Technische Risiken
**Messung:** Das grösste technische Risiko liegt in der Datenerhebung. Nur möglichst kontinuierlich erfasste Verkehrszähldaten erlauben eine gute Prognose. Technische Unterbrüche, Baustellen oder andere Störungen beeinträchtigen die Datenqualität und damit die Prognosegenauigkeit.
**Skalierbarkeit:** Bei einer Anwendung der Methode auf Echtzeit-Daten wächst die Datenmenge rasch an und erfordert ein Datenmanagement und eine Datenverarbeitung mit Big Data-Verfahren sowie entsprechende Speicher- und Rechenkapazitäten.
## Erfolgskriterien
**Accuracy:** In der Regel wird die Genauigkeit einer Vorhersage durch eine Statistik gemessen.
(1) **AIC** Im Modellvergleich dient der AIC als Kriterium für den Goodness-of-fit.
(2) **MAPE** Der MAPE dient zur Beurteilung der Genauigkeit der Vorhersage, ausgedrückt als mittlerer absoluter prozentualer Fehler aus.
**Rechnerischer Aufwand:** Die verwendete Methode soll einen überschaubaren (geringen) rechnerischen Aufwand erfordern und eine einfache Implementation erlauben.
## Zielgruppe
Die Echtzeit-Daten der Verkehrsmessstellen im Kanton Zürich sollen unter dem OGD Datenstandard frei verfügbar gemacht werden. Die Beurteilung möglicher Prognosemodelle für diese Verkehrszähldaten soll primär **(1) der interessierten OGD-Community** als Grundlage für die Erstellung möglicher Applikationen dienen. Darüber hinaus kann die Arbeit auch **(2) in der Planung von Echtzeit-Verkehrssteuerungssystemen und dem Verkehrsmanagement** dienen.
# Data Understanding
**Datenverfügbarkeit:**
Insgesamt stehen die Verkehrszähldaten von 15 MIV-Messtellen im Grossraum Zürichsee für den Zeitraum 1.1.-30.6.2020 sowie der Vorjahresperiode zur Verfügung. Gemessen wird das Total an Fahrzeugen in 15-Minuten-Intervallen. In jedem Zeitintervall werden die gezählten Fahrzeuge zusätzlich nach zehn Fahrzeugkategorien unterschieden. Ausserdem liegen Angaben zur Fahrtrichtung sowie bei mehrspurigen Strassen zur Spur vor. Keine Angaben liegen vor zur Geschwindigkeit.
Informationen zu den Prädiktoren, Wochentag, Stunde vom Tag, Feiertag / Ferien sowie Baustellen oder andere Unterbrüche, werden entweder mit den Verkehrszähldaten geliefert oder lassen sich anhand dieser ergänzen.
Somit ist ein ausreichende Datengrundlage gegeben, um verschiedene Modell zu erstellen und zu testen.
**Quantitative und qualitative Aspekte:**
+ Genügend grosser Pool an Messstationen, um für die Modellanpassungen solche ohne Messunterbrüche auswählen zu können.
+ Der Trainingsdatensatz (jan-Jun. 2019) umfasst lediglich die ersten sechs Monate des Jahres. Es liegt somit kein Jahresrhythmus vor und der prospektive Einsatz des Modells ist somit limitiert.
+ Beim Test-Datensatz (Jan.-Jun. 2020) kommen ab Mitte März, also mit Beginn der ausserordentlichen Lage aufgrund der Corona-Pandemie, stark abweichende Messungen auf. Das Testen des Modells bietet sich somit nur für die Monate Januar und Februar 2020 an.
+ Feier- und Ferientage sind selbst innerkantonal nicht immer deckungsgleich. Ja nach Standort der Messstation gelten also ggf. andere Feiertage. Es ist kein OGD-Datensatz solcher Daten bekannt, so dass Feier- und Ferientage manuell ergänzt und angepasst werden müssen.
## Rechtliches & Finanzielles
Es handelt sich um frei verfügbare, nicht personenbezogen Daten. Aspekte des Datenschutzes sind somit nicht relevant, ebensowenig müssen keine kostenpflichtigen Daten hinzugekauft werden.
# Data Preparation
**Missing Values**
Fehlende Werte können verschiedene Ursachen haben: Baustellen, technische Störungen und Unterbrüche.
Es wird keine Imputation der fehlenden Werte vorgenommen.
1) Fehlende Werte können immer wieder vorkommen und sollten darum Teil des Modells sein.
2) Mit Imputation wird das Modell ggf. eher schlechter, da es nicht mehr modelliert, was die aktuelle Situation ist.
**Ausreisser**
Besonders tiefe oder hohe Werte, die nur einmalig oder kurzzeitig vorkommen, lassen sich im Idealfall aufgrund von Baustellen oder technischen Störungen erklären. Solche erklärbaren Ausreisser werden wie Missing Values behandelt.
**Saisonalität**
Saisonalität entsteht zum einen, als dass es jährlich wiederkehrende Ereignisse wie Feiertage und Ferien gibt. Zum anderen durch die Wochentage: Wochenenden weichen erkennbar vom Muster der Arbeitstage ab. Diese Formen der saisonalen Muster müssen im Modell berücksichtigt werden.
## Variablen: Standardisierung, Transformation, Aggregation und Selektion
**Messstation:** Name und Nummer der Messstation.
**Datum:** Das Datum wird als `as.POSIXct` im Format `"%Y-%m-%d %H:%M:%S"` gespeichert.
**Monat**: Der Monat als eigene Variable, um den Einfluss von einer Saisonalität, z.B. durch Ferien, nachverfolgen zu können.
**Wochentag:** Der Wochentag wird dem Datensatz als neue Variable hinzugefügt und aus dem Datum extrahiert: Konvertierung von Datum in `as.Date`. Dabei ist Montag als erster Tag der Woche definiert.
**Stunde:** Stunde vom Tag.
**Total Fahrzeuge:** Die Messswerte sind in der Variable `flow`als Stundensumme angegeben. Eine Unterschiedung in Fahrzeugkategorien ist nicht notwendig und der Datensatz wird um die 10 Variablen zur Fahrzeugkategorie reduziert. Bei mehrspurigen Strassen werden die Spuren, die in die gleiche Richtung führen, kumuliert.
**Feiertag:** Eine binär mit `1` für Ja / `2` für Nein kodierte Variable, welche dem Datensatz hinzugefügt wird.
**Schulferien:** Eine binär mit `1` für Ja / `2` für Nein kodierte Variable, welche dem Datensatz hinzugefügt wird.
```{r messstationen, echo = FALSE, include=FALSE}
# Data set for 2019
miv_2019 <- readr::read_csv("./miv.csv")
miv_train_day <- miv_2019 %>%
group_by(date) %>%
# Calculate response variable daily sum of flow
summarise(flow_daysum = sum(flow)) %>%
ungroup() %>%
# Adding explanatory variables month, weekday, holiday and schoolholiday
mutate(month = as.numeric(strftime(date, "%m")),
weekday = strftime(date,'%A'),
weekday_num = as.numeric(strftime(date,'%u')),
holiday = case_when(date == "2019-01-01" ~ 1,
date == "2019-01-02" ~ 1,
date == "2019-04-19" ~ 1,
date == "2019-04-22" ~ 1,
date == "2019-05-01" ~ 1,
date == "2019-05-30" ~ 1,
date == "2019-06-10" ~ 1,
TRUE ~ 0),
schoolholiday = case_when(date >= "2019-01-01" & date <= "2019-01-05" ~ 1,
date >= "2019-04-22" & date <= "2019-05-04" ~ 1,
date >= "2019-02-09" & date <= "2019-02-24" ~ 1,
TRUE ~ 0),
sqrt_flow = as.integer(sqrt(flow_daysum))) %>%
dplyr::select(date, weekday, weekday_num, month, flow_daysum, sqrt_flow, holiday, schoolholiday)
```
```{r rbind, echo = FALSE}
head(miv_train_day)
```
```{r, include = FALSE, echo = FALSE}
holiday_2019 <- miv_train_day %>% filter(holiday == 1)
xmin <- as.Date(c("2019-01-01", "2019-02-09", "2019-04-22"))
xmax <- as.Date(c("2019-01-05", "2019-02-24", "2019-05-04"))
ymin <- c(-Inf, -Inf, -Inf)
ymax <- c(Inf, Inf, Inf)
schoolholiday_2019 <- data.frame(xmin, xmax, ymin, ymax)
```
```{r,echo=FALSE}
ggplot(miv_train_day, aes(date, flow_daysum)) +
geom_rect(data=schoolholiday_2019, inherit.aes=FALSE,
aes(xmin=xmin,xmax=xmax,ymin=ymin,ymax=ymax), fill = "lightgreen", alpha=0.6) +
geom_line() +
geom_point(holiday_2019, mapping = aes(x = date, y = flow_daysum), color = "red") +
theme_stat() +
labs(title = "Verkehrsaufkommen 2019",
subtitle = "Messstelle Nr. 109, Tageswerte, Jan-Jun. 2019",
caption = "Rote Punkte = Feiertage, Grün = Schulferien",
y = "Anzahl Fahrzeuge",
x = NULL)
```
# Modelling
**Modellselektion**
Lineare Regression: Modellierung basiert auf den Beobachtungen und einem Fehlerterm. Das Modellieren mit Zeitreihen bedingt, dass der Prozess stationär ist, d.h. Saisonalität muss mit modelliert werden.
Für die zyklischen Effekte aus den Wochen-, Feier- und Ferientagen werden in einem GAM cyclical smooth terms angewendet.
```{r}
mgcv::gam(flow_daysum ~ s(month, bs = 'cc', k = 6) + weekday + holiday + schoolholiday, data = miv_train_day, method = "REML")
```
## Analytische Verfahren anwenden
--> siehe "StMo Analysekonzept - Modellanpassung"
# Evaluation
Obwohl das Modell simpel ist, hat sich gezeigt, dass es schnell recht gute Resultate liefern kann. Gerade auch beim Modellieren der Trends über's Jahr hinweg, funktioniert das Modell gut.
Schwächen zeigt das Modell in Wochen mit einem "unerwartet" hohem resp. tiefen Verkehrsaufkommen. Für diese Fälle muss dem Modell ein Korrekturfaktor hinzugefügt werden. Dieser könnte bspw. aus den Residuen geschätzt werden. Wird das Modell in einem Pool von Messstellen angewendet, könnte der Faktorterm für die vergangene Periode über verschiedene Messstellen gepoolt werden. **Das Pooling von vergleichbaren Messstellen im Modell könnte eine erste Weiterentwicklung des Modells sein.**
**Geeingnetheit des Modells zur Beantwortung der Fragestellung:**
Das Modell zeigt die lokalen Effekte an einer stationären Stelle und für eine Stunde/Tag im Messstellennetz. Um aber Aussagen über Stationen in der Peripherie oder gar das ganze Netz treffen zu können, benötigt es zum einen Echtzeitdaten. Erst so können auch Aussagen über den `flow` an vor- und nachgelagerten Messstellen getroffen werden. Mit Stunden- oder Tageswerten lassen sich auf Basis einer Station keine Prognosen zum Verkehrsaufkommen an anderen Stationen machen. **Die Anpassung des Modells mit Echtzeitdaten und für die Peripherie der Messstationen könnte eine zweite Weiterentwicklung des Modells sein.**
# Deployment
Im Betrieb wird es primär um die Pflege des Modells gehen. Das Modell mit den aktualisierten Daten regelmässig evaluiert, angepasst und neu gerechnet. Hierfür ist ein geeigneter Rhythmus zu definieren.
Damit das Modell z.B. in intelligenten Verkehrssystemen (ITS) eingesetzt werden kann, muss es adaptiv gestaltet sein. Das heisst, es müssen Schnittstellen für die aktuellen Daten geschaffen werden, diese müssen Prozessiert und die Vorhersagen an das ITS zurückgespielt werden. Ein solches Setup ist besonders bei Echtzeitdaten relevant.