Architektur.tex

\section{Grundlagen}
\subsection{Analyse Datenbank BVG}
Die BVG nutzt für die Persistierung der Daten, inklusive der Prozessdaten, ein Datenbanksystem der Firma Oracle. Es werden bei der BVG zwischen zwei verschiedenen Systemen unterschieden. Zum Einen gibt es die sogenannte SC05 Schnittstelle. Diese enthält Prozessdaten der aktuellen Betriebslage. Dazu zählen unter anderem Positionen von Bussen und deren Verspätung (vgl.: "`Die Prozessdatenschnittstelle (SC05) spiegelt die aktuelle Situation im RBL wider."' \cite[S. 4]{SC05}).
Zum Anderen gibt es die SC51 Datenbank, entwickelt von der Firma Alcatel. Diese Schnittstelle enthält unterschiedlichste Daten für die Durchführung des öffentlichen Nahverkehrs der BVG. Darunter fallen Informationen zu Linien (Bus und Bahn), Informationen über deren Routen mittels geografischer Koordinaten und vieles mehr. 
Für die Analyse dieser relationalen Datenbanken waren jeweils Dokumentationen und ein Dump der Datenbank zur Verfügung.
 
Der erste Schritt bei der Analyse bestand darin, die Dumps der Oracle Datenbanken zu importieren, um anschließend Zugriff auf die Tabellen und deren Daten zu erlangen. Für den Import fiel die Entscheidung für das Tool "`OraDump to MySQL"' (vgl. \cite{OraDump}).
Mit diesem Tool ist es möglich ein Oracle Datenbank Dump in eine MySQL Datenbank zu importieren. Vorteil dieser Methode ist, das auf bestehende Kenntnisse im Umgang mit MySQL zurückgegriffen werden kann. Im folgenden wurde mittels der Schnittstellendokumentation die Struktur der Datenbank analysiert. Im Fokus dieser Analyse stehen die Routen Information aus der SC51 und die Positionsdaten der Fahrzeuge aus der SC05 Schnittstelle. Bei der Analyse haben sich folgende Datenbanktabellen als wertvoll gezeigt. 
 
Die Tabelle \code{CM\_VEHICLE\_POSITION} aus der SC05 Datenbank enthält Informationen zu der aktuellen geografischen Position mittels Latitude und Longitude, der Abweichung vom Sollfahrplan in Sekunden, sowie eine Zuordnung zu einer Route. Um einen Omnibus auf einer Route einzuordnen, gibt es eine endliche Menge von geografischen Punkten. Zu all diesen Punkten ist ein zeitlicher und örtlicher Abstand bekannt (siehe SC51). Zu jedem Fahrzeug ist der letzte passierte Punkt der Route referenziert (\code{LAST\_POR\_ORDER}). Der prozentuale Abstand zum Folgepunkt auf einer Route ist ebenfalls in der Relation durch die Spalte \code{REL\_LNK\_DISTANCE} gegeben.

Für die Zuordnung der Fahrzeuge aus der Tabelle \code{CM\_VEHICLE\_POSITION} zu einer Route und einem Kurs gibt es in der SC05 Datenbank zwei Tabellen. Zum Einen hat die Tabelle \code{CM\_ACCT\_COURSES} die Aufgabe, ein Fahrzeug einem Kurs zuzuordnen. Zum Anderen wird durch \code{CM\_ACCT\_JOURNEY} ein Bus einer Route zugeordnet. Somit können die \code{POINTS\_ON\_ROUTE} einem Fahrzeug zugeordnet werden.

Die Datenbank SC51 beinhaltet Tabellen für die Linien (\code{LINES}). Eine Linie ist im Kontext der BVG zum Beispiel die konkrete Buslinie X11. Jede Linie besteht aus mehren Fahrten, hier \code{COURSES\_ON\_JOURNEY} genannt. Zu einem Kurs gehören Informationen wie Startzeit, Endzeit und eine Kursnummer, die nur im Kontext einer Linie eindeutig ist.

Die geografischen Informationen zum Routenverlauf werden in den Tabellen \code{ROUTE}, \code{POINTS\_ON\_ROUTE} und \code{NETWORK\_POINTS} verwaltet. Zu einer Buslinie können verschiedene Routen gehören. Diese Routen sind in der Tabelle \code{ROUTE} zu finden. Dafür enthält auch diese Relation zusätzlich ein Feld \code{Description} (Beispieldaten: Falkensee, Bahnhof->S+U Rathaus Spandau). Die Tabelle \code{POINTS\_ON\_ROUTE} koordiniert die Punkte einer Route, indem jeder Punkt einen Laufnummer hat (\code{POR\_ORDER}). Um den zeitlichen und örtlichen Abstand zwischen zwei Punkten zu ermitteln, wird die Relation \code{LINKS} verwendet. Die Tabelle \code{NETWORK\_POINTS} enthält abschließend die eigentlichen geografischen Punkte in der Form Latitude und Longitude.

In der Abbildung \ref{img:db-bvg} sind die Zusammenhänge der einzelnen Datenbanktabelle von SC05 und SC51 zu sehen. Dabei handelt es sich lediglich um einen Auszug der relevanten Daten für das zu entwickelnde System.

\begin{figure}[H]
	\centering
	\includegraphics[width=15cm]{res/BVG-DB.png}
	\caption{Datenbank Schema aus SC05 und SC51}
	\label{img:db-bvg}
\end{figure}

\subsection{Open Street Map}
Die für dieses Projekt benötigten Geodaten zu den Routen aller Busse der Berliner Verkehrsbetriebe stammen von OpenStreetMap.
OpenStreetMap ist ein freies Projekt unter der Open Database License, welches Geodaten sammelt und zur freien Nutzung in einer Datenbank speichert (vgl.: \cite{osm}). Das Projekt wurde im Juli 2004 ins Leben gerufen. Seit April 2006 ist ein Gremium, die OpenStreetMap Foundation, für das Projekt verantwortlich. Ziel ist das "`Erzeugen, Verteilen und Vergrößern eines geographischen Datenbestandes sowie dessen freie Bereitstellung zum allgemeinen Gebrauch.'' (vgl.: \cite{osm-was}).

Der Zugang zu den Daten erfolgt über die OSM API. Zum Zeitpunkt des Erstellen dieses Dokumentes ist die API in der Version 0.6 (vgl.: \cite{osm-api-6}). Eine ausführliche Dokumentation wird auf openstreetmap.org zur Verfügung gestellt (siehe \cite{osm-wiki}). Jedem auf OSM gespeichertem Objekt wird eine Basiseigenschaft (Attribut) zugeordnet, welche wiederum durch eine festgelegte Datenrepräsentation ausgedrückt wird. Die Liste der Attribute (Map Features) befindet sich auf der Dokumentation (siehe \cite{osm-feature}).

Für dieses Projekt ist insbesondere das Map Feature "`Route'' von interesse (vgl.: \cite{osm-route}). Die Spezifikation für bestimmte Routen erfolgt über eine Sammlung von Key/Value Paaren. So sind Busrouten der Berliner Verkehrsbetriebe Relationen mit folgenden Eigenschaften:
\begin{lstlisting}
["type"="route"]["route"="bus"]["operator"="Berliner Verkehrsbetriebe"]. 
\end{lstlisting}

Für das Suchen, Anzeigen und Downloaden von bestimmten Relationen wird Overpass turbo (vgl.: \cite{overpass}) empfohlen, ein webbasiertes Datensammelwerkzeug für OSM. Overpass turbo zeigt Resultate einer Anfrage auf einer interaktiven Karte und erlaubt den Download der Daten in unterschiedlichen Formaten. In diesem Projekt wurde GeoJSON benutzt (siehe \ref{sec:geojson}). Eine ausführliche Beschreibung der Overpass API findet sich in der Dokumentation von OSM (vgl.: \cite{osm-overpass}). DIe Listings \ref{listing:osm1} und \ref{listing:osm2} zeigen Beispielhafte Anfragen, wie sie auch für das Projekt verwendet werden.

\begin{lstlisting}[caption=Overpass Query für alle Busrouten der Berliner Verkehrsbetriebe, label=listing:osm1]
[out:json][timeout:25];
(
  // query part 
  relation["type"="route"]["route"="bus"]["operator"="Berliner Verkehrsbetriebe"];
);
// print results
out body;
>;
out skel qt;
\end{lstlisting}

\begin{lstlisting}[caption=Overpass Query für die Straßenbahnroute der Linie 67 der Berliner Verkehrsbetriebe, label=listing:osm2]
[out:json][timeout:25];
// gather results
(
  // query part
  relation["type"="route"]["route"="tram"]["ref"=67]["operator"="Berliner Verkehrsbetriebe"];
);
// print results
out body;
>;
out skel qt;
\end{lstlisting}

\subsection{GeoJson} \label{sec:geojson}
Die Routeninformationen zu den Buslinien wurden über die OSM API im GeoJSON Format gesammelt.
GeoJSON ist ein offenes Format um geographische Daten zu repräsentieren. Es basiert auf dem JSON Format, der JavaScript Object Notation, und wurde im August 2016 als RFC 7946 veröffentlicht (vlg.: \cite{geojson}) . GeoJSON erlaubt folgende geometrische Typen:
\begin{itemize}
    \item{Point: definiert durch Koordinaten (Lat, Long). Beschreiben beispielsweise Adressen}
    \item{LineString: Sammlung von Punkten, welche verbunden beispielsweise Straßen und Flüsse repräsentieren}
    \item{Polygon: mehrere miteinander verbundene Punkte wobei der erste und letzte Punkt identisch sind. Beschreiben z.B. Ländergrenzen}
    \item{MultiPoint: mehrere nicht verbundene Punkte}
    \item{MultiLineString: bestehen aus 1 bis n LineStrings. Werden benutzt wenn zu einer Relation mehrere LineStrings existieren die dieser zugeordnet sind. z.B. unterschiedliche Fahrtstrecken für eine Buslinie.}
    \item{MultiPolygon: zur Darstellung von komplexen Flächen benützt zB bei geographisch getrennt liegenden Flächenstücken welche einer Relation angehören.}
\end{itemize}

Die in diesem Projekt benutzte Daten zum repräsentieren der Routen bestehen aus MultiLineStrings. Ein GeoJSON hat ein Eltern Objekt, welches üblicherweise ein Collection Objekt ist. Listing \ref{listing:geosjon}  ist ein verkürztes Beispiel der Daten für die Straßenbahn Linie 27 der BVG. Der Ausschnitt zeigt ein feature Objekt des Eltern Objektes (FeatureCollection). Das Feature besitzt mehrere Properties (Eigenschaften) und eine Geometry. Diese ist ein MutliLineString, also eine Sammlung von Punkten welche verbunden die Route der Tramlinie 27 repräsentieren.

\begin{lstlisting}[caption=Beispiel Relation Route 27, label=listing:geosjon]
{ "type": "Feature",
      "properties": {
        "@id": "relation/2077646",
        "from": "Krankenhaus Köpenick",
        "name": "Straßenbahnlinie 27: Krankenhaus Köpenick => Weißensee, Pasedagplatz",
        "network": "Verkehrsverbund Berlin-Brandenburg",
        "operator": "Berliner Verkehrsbetriebe",
        "ref": "27",
        "route": "tram",
        "to": "Weißensee, Pasedagplatz",
        "type": "route"
      },
      "geometry": {
        "type": "MultiLineString",
        "coordinates": [
          [
            [13.5939995, 52.4385062], ..., [13.5921062, 52.4388869]
          ]
        ]
      }
}
\end{lstlisting}

\section{Komponenten}
Die entwickelte Anwendung ist ein verteiltes System welches aus drei Komponenten besteht. Einem Server mit REST API zum Senden und Empfangen der Daten, einer MySQL Datenbank zum Speichern der Daten und einer Android Applikation zum Sammeln der Positionsdaten und der Visualisierung der relativen Zeitabstände zwischen der Fahrzeugen einer Buslinie.

\begin{itemize}
\item{Das Senden und Empfangen aller Daten geschieht über die üblichen HTTP Methoden (POST, GET, PUT, DELETE). Das Format des Playloads ist JSON. Die Entscheidung für einen REST basierten Service und gegen eine SOAP Implementierung hatte mehrere Gründe. REST benutzt die gängigen HTTP Methoden und ist leichter zu implementieren. Zudem ist, wegen des zusätzlichen Overhead an Daten bei SOAP, die Größe eines Responsedokumentes bis zu 18\% größer und die Dauer eines Request-Response-Zyklus länger. SOAP hat auch serverseitige Nachteile, da sich die Verarbeitungszeit der Anfragen durch das erforderliche verpacken jeder Antwort in ein neues SOAP-Dokument deutlich erhöht. (vgl.: \cite{soap}) Die Dokumentation zur verwendeten REST API findet sich im Anhang \ref{sec:apiref} dieses Dokumentes.
Alle Berechnungen der Daten (mappen der Positionsdaten auf die Route, berechnen der relativen Zeitabstände) werden Serverseitig erledigt. Für eine detaillierte Beschreibung der Berechnungen siehe \ref{sec:funktionsweise} Funktionsweise.}

\item{Das Persistieren der Daten geschieht auf einer relationalen MySQL Datenbank. Alle Positionsdaten und die Fahrzeit der einzelnen Fahrzeuge werden dauerhaft gespeichert und dienen als Referenzwerte für die Berechnung der Zeitabstände. Bei einem ausreichend großen Datenbestand ist es dann auch möglich Vorhersagen zu bestimmten Tageszeiten zu treffen und ein mögliches Auftreten von Bus bunching zu erkennen und diesem rechtzeitig entgegenzuwirken.
Eine Beschreibung des Datenbankschemas findet sich unter \ref{sec:datenbankschema} Datenbankschema Server.}

\item{Die Android Applikation dient sowohl dem Sammeln der Positionsdaten der Fahrzeuge, als auch der Visualisierung der relativen Abstände. Das senden der GPS Koordinaten erfolgt in einem regelmäßigen Abstand von 10 Sekunden. Die Daten werden an der Server geschickt und in der Datenbank abgelegt. Da die GPS Koordinaten nicht genau auf der definierten Route liegen, werden sie serverseitig auf die nächste Koordinate der Route gemappt. Die korrigierten Koordinaten und die berechneten Abstände werden als Antwort zurück zur App geschickt, wo es zwei Möglichkeiten der Darstellung gibt. Einerseits eine Anzeige der Zeitabstände zu den Fahrzeugen direkt vor und hinter dem eigenen oder eine Anzeige auf der Kartenview mit Anzeige aller Fahrzeuge einer Route an ihrer Aktuellen Position}
\end{itemize}

\section{Datenbankschema Server}\label{sec:datenbankschema}
Für die Persistierung der Daten des Servers wurde eine relationale Datenbank gewählt. Speziell für die Implementierung wird eine MySQL Datenbank gewählt. Um auf die Datenbank aus Java zuzugreifen, wird der Java Database Connector (JDBC) verwendet.

In der Datenbank werden Daten der Route und deren Geometrien aus OSM gespeichert. Dafür gibt es die Tabellen \code{Route}, \code{MultiLineString} und \code{LineString}. Die Relation \code{Route} enthält Informationen über die Liniennummern (\code{rel}), Start- und Zielhaltestelle (\code{from}, \code{to}). Zudem sind Informationen über das Verkehrsunternehmen (\code{operator}, Beispiel: BVG) und den Verkehrsverbund (\code{network}, Beispiel: VBB) vorhanden. Die Eigenschaft \code{type} entscheidet über den Typ der Geometrie einer Route. Die eigentliche Information über die Geometrie befindet sich als String in der Tabelle \code{MultiLineString} oder \code{LineString}. Ein solcher MultiLineString kann beispielsweise wie folgt aussehen: 
\begin{lstlisting}
MultiLineString((13.6920278 52.4516269, 13.6923877 52.4515733, 13.6926666 52.4515393, ...))
\end{lstlisting}

Um Aussagen über die Geschwindigkeit von Fahrzeugen auf einer Route treffen zu können, wurden im Vorfeld Testfahrten gemacht. Die gesammelten Daten während dieser Testfahrten sind in den Tabellen \code{Journey} und \code{MeasurePoint} persistiert. Die Tabelle \code{Journey} beschreibt eine spezielle Fahrt zu einer Uhrzeit auf einer Route. Die Messwerte, also die GPS Position eines Fahrzeugs und Zeitstempel, werden zu einer Fahrt in der Relation \code{MeasurePoint} gespeichert. Bei den GPS Daten handelt es sich um die ungeglätteten Daten, das hei{\ss}t also, dass die GPS Daten nicht zwingend auf der Route liegen.

In der Tabelle \code{Vehicle} werden die aktuellen Informationen zu den Fahrzeugen gespeichert. Dafür enthält die Tabelle Informationen zu GPS Position (geglättet), einen Zeitstempel und die Route eines Fahrzeuges. Jedes Fahrzeug wird über einen Unique Identifier identifiziert (\code{ref}).

Um diese Fahrzeugdaten historisch zu persistieren, gibt es zusätzlich  zu \code{Vehicle} die Relation \code{VehicleHistory}. In dieser Tabelle existiert die gleiche Struktur wie \code{Vehicle}. Zusätzlich gibt es noch einen künstlichen Primärschlüssel, um jede Zeile eindeutig zu identifizieren. Somit ist es möglich zu jedem Zeitpunkt herauszufinden, auf welcher Route und an welcher Stelle ein Fahrzeug zu einem Zeitpunkt war.

Die Abbildung \ref{img:db-server} visualisiert die erstellte Datenbankstruktur mit den Relationen und deren Beziehungen für den Server.

\begin{figure}[H]
	\centering
	\includegraphics[width=15cm]{res/Server-DB.png}
	\caption{Datenbank Schema Server}
	\label{img:db-server}
\end{figure}