diff --git a/content/post/project-public-transit-map-matching-with-graphHopper.md b/content/post/project-public-transit-map-matching-with-graphHopper.md
index 5c8c198..b84b23c 100644
--- a/content/post/project-public-transit-map-matching-with-graphHopper.md
+++ b/content/post/project-public-transit-map-matching-with-graphHopper.md
@@ -11,37 +11,39 @@ draft: true
# Contents
-1. Introduction
-1. Our map matching approach
- 1. Finding Candidates
- 1. Path finding between candidates
- 1. Hidden Markov Model HMM
- 1. Turn restrictions
-1. Evaluation
- 1. Metrics
- 1. Results Stuttgart
- 1. Results Victoria-Gasteiz
-1. Further research
+1. [Introduction](#introduction)
+1. [Our map matching approach](#approach)
+ 1. [Finding Candidates](#finding-candidates)
+ 1. [Path finding between candidates](#path-finding-between-candidates)
+ 1. [Hidden Markov Model HMM](#hidden-markov-model)
+ 1. [Turn restrictions](#turn-restrictions)
+1. [Evaluation](#evaluation)
+ 1. [Metrics](#metrics)
+ 1. [Results Stuttgart](#results-stuttgart)
+ 1. [Results Victoria-Gasteiz](#results-victoria-gasteiz)
+1. [Further research](#current-problems-and-further-research)
-# Introduction
+# Introduction
-*TransitRouter* is a web tool for generating shapes of GTFS feeds for bus routes using the map matching approach described in the paper [Hidden Markov Map Matching Through Noise and Sparseness](https://www.ismll.uni-hildesheim.de/lehre/semSpatial-10s/script/6.pdf).
+*TransitRouter* is a web tool for generating shapes of GTFS (*General Transit Feed Specification*) feeds for bus routes using the map matching approach described in the paper [Hidden Markov Map Matching Through Noise and Sparseness](https://www.ismll.uni-hildesheim.de/lehre/semSpatial-10s/script/6.pdf).
*TransitRouter* uses the OSM routing engine [GraphHopper]() and a modified version the [GraphHopper Map Matching library]() that enables turn restrictions and tries to prevent inter hop turns.
-*GraphHopper* is a fast and memory efficient routing engine written in Java. It has built in support for different weighting strategies (e.g. fastest and shortest path routing), turn restrictions (based on OSM meta data) and turn costs and most important the ability to specify custom routing profiles. As public transit has quit different traffic rules we created a specialized *bus profile*.
+*GraphHopper* is a fast and memory efficient routing engine written in Java. It has built in support for different weighting strategies (e.g. fastest and shortest path routing), turn restrictions (based on OSM meta data), turn costs and most important the ability to specify custom routing profiles. As public transit has quite different traffic rules we created a specialized *bus profile*.
The quality of the results are compared with the original GraphHopper Map Matching library (*GHMM*) and [*pfaedle*](https://github.com/ad-freiburg/pfaedle) a similar tool developed by the chair of Algorithms and Data Structures at the university of Freiburg.
-# Approach
+# Approach
Given a trip \\(T\\) with a ordered sequence of stations \\(S = (s_0, s_1, s_2, ..., s_n)\\) we want to find its path \\(P\\) through our street network graph \\(G=(V, E)\\).
First we discuss how we can find possible candidates in G for every \\(s_i\\) and how we find a path between candidates. Then how we can find the most likely sequence of candidates and finally how we enable turn restrictions.
+
+Stations \\(s_0, s_1, ..., s_6\\). Red: candidates within radius \\(r\\) around \\(s_i\\). Blue: Path of the bus.
-## Finding candidates
+## Finding candidates
The GPS positions of our stations might not be accurate so we cannot use them directly to find our path.
For each station \\(s_i\\) we want to find a set of possible candidates \\(C_i\\). To construct \\(C_i\\) we use the following approach:
@@ -50,21 +52,21 @@ For every edge \\(e_j \in E\\) within a radius \\(r\\) around \\(s_i\\) calculat
Note that we could have used *orientation less* candidates consisting only of the projection \\(p_{i,j}\\) but we need the direction to enable turn restrictions which we will see at a later point.
-
-## Path finding between candidates
+
+## Path finding between candidates
As a path finding strategy either shortest or fastest routing can be used. Note that turn costs do not work properly with shortest routing because of the way GraphHopper calculates the turn penalties.
For feeds with short distances between stations shortest routing might produce better results that fastest routing. An example can be seen in the evaluation chapter.
We use our own public transit optimized bus profile for *TransitRouter* and *GHMM*.
-## Hidden Markov Model *HMM*
+## Hidden Markov Model *HMM*
To find the most likely sequence of candidates we use a Hidden Markov Model (*HMM*) with our stations \\(s_i\\) as observations and our candidates \\(C_i\\) as observations. The approach is based on the paper [Hidden Markov Map Matching Through Noise and Sparseness](https://www.ismll.uni-hildesheim.de/lehre/semSpatial-10s/script/6.pdf).
Given a optimal sequence of candidates we construct our final path \\(P\\) by combining the paths between the candidates in our sequence.
-### Emission probability
+### Emission probability
The emission probability \\(p(s_i | c_i^k)\\) describes the likelihood that we observed \\(s_i\\) given that \\(c_i^k\\) is a matching candidate.
We use the great circle distance \\(d\\) between the station\\(s_i\\) and its candidate node \\(c^i_k\\) and apply a weighting function with the tuning parameter \\(\sigma\\).
@@ -74,7 +76,7 @@ $$p(s_i | c_i^k) = \frac{1}{\sqrt{2\pi}\sigma}e^{0.5(\frac{d}{\sigma})^2}$$
-### Transition probability
+### Transition probability
For the transition probability \\(p(c_i^k \rightarrow c_{i+1}^j)\\) describes the likelihood that our next state will be \\(c_{i+1}\\) given our current state is \\(c_i^k\\).
We use the distance difference \\(d_t\\) between the great circle distance of the two stations \\(s_i, s_{i+1}\\) and the length of the road path between the two candidates \\(c_i^k, c_{i+1}^j\\) and apply out weighting function with tuning parameter \\(\beta\\).
@@ -85,7 +87,7 @@ $$p(c_i^k \rightarrow c_{i+1}^j)=\frac{1}{\beta}e^{\frac{d_t}{\beta}}$$
-## Turn restrictions
+## Turn restrictions
For our bus routes we want to prevent forbidden and unlikely turns. GraphHopper has built in support for turn restrictions based on osm meta data and for turn costs. But if we calculate the path between candidates only using there position we run into the problem of inter hop turns.
Consider the following example:
@@ -100,32 +102,32 @@ When we combine the most likely paths \\(P_i\\) to get the whole path \\(P\\) we
-# Evaluation
+# Evaluation
We evaluate *TransitRouter* and *GHMM* on the GTFS feeds of Stuttgart (S) and Victoria-Gasteiz (VG) with both fastest and shortest routing and following tuning parameters:
$$\sigma=10, \\: \beta=1.0, \\: \text{candidate search radius } r = 10$$
-## Metrics
+## Metrics
To evaluate the quality of our generated shapes we use three different metrics where we compare a generated path P with the corresponding path Q of the ground truth.
-### Average Frèchet Distance \\(\delta_{a_F}\\)
+### Average Frèchet Distance \\(\delta_{a_F}\\)
We split the paths \\(P\\) and \\(Q\\) into an equal number of segments such that the segments in \\(P\\) have a length of 1m. Then \\(\delta_{a_F}\\) is the average of the Frèchet Distance between the segments in \\(P\\) and \\(Q\\).
-### Percentage of unmatched hop segments \\(A_N\\)
+### Percentage of unmatched hop segments \\(A_N\\)
A *hop segment* is the path between two station / hops.
A *hop segment* is mismatched its Frèchet Distance is \\(\geq\\) 20m.
$$A_N = \frac{\text{\#unmatched hop segments}}{\text{\#hop segments}}$$
-### Accuracy
+### Accuracy
The accuracy is the percentage of trips that are below a given threshold of \\(A_N\\).
-### Percentage of length of unmatched hop segments \\(A_L\\)
+### Percentage of length of unmatched hop segments \\(A_L\\)
$$A_L = \frac{\text{length of unmatched segments}}{\text{length ground truth}}$$
-## GraphHopper Map Matching base line
+## GraphHopper Map Matching base line
The GraphHopper Map Matching (*GHMM*) library is a one to one implementation of [Hidden Markov Map Matching Through Noise and Sparseness](https://www.ismll.uni-hildesheim.de/lehre/semSpatial-10s/script/6.pdf).
To be used as a base line we removed the filtering of close observations described in chapter 4.1 as this removes consecutive stations that are to close to one another. To compare the speed with *TransitRouter* we made the implementation thread safe to allow parallel execution.
@@ -136,7 +138,7 @@ The differences to TransitRouter are:
- no support for inter hop turn restrictions
-## Stuttgart
+## Results Stuttgart
Average Frèchet Distance \\(\delta_{a_F}\\) histogram
@@ -151,7 +153,7 @@ Percentage of length of unmatched hop segments \\(A_L\\)
-## Victoria-Gasteiz
+## Results Victoria-Gasteiz
Average Frèchet Distance \\(\delta_{a_F}\\) histogram
@@ -169,7 +171,7 @@ Percentage of length of unmatched hop segments \\(A_L\\)
-## Current problems and further research
+## Current problems and further research
### Inter-hop turn restrictions are not properly reflected in the HMM
GraphHopper uses a time based penalty to prevent unnecessary turns but this is not reflected in our transition weight function where we only use the distance of our path. So inter hop turns are not always prevented.
diff --git a/static/img/project_public_transit_map_matching/street_graph.png b/static/img/project_public_transit_map_matching/street_graph.png
new file mode 100644
index 0000000..3b86727
Binary files /dev/null and b/static/img/project_public_transit_map_matching/street_graph.png differ
diff --git a/static/img/project_public_transit_map_matching/street_graph.svg b/static/img/project_public_transit_map_matching/street_graph.svg
new file mode 100644
index 0000000..d3c6ce1
--- /dev/null
+++ b/static/img/project_public_transit_map_matching/street_graph.svg
@@ -0,0 +1,336 @@
+
+