projet_wdm_m2/rapport/rapport.tex

\documentclass[a4paper, 8pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[francais, english]{babel}
\usepackage[a4paper]{geometry}
\geometry{hmargin=2.5cm,vmargin=1.5cm}
\usepackage{amssymb, amsmath,amsfonts,amsthm,mathrsfs}
\usepackage{hyperref}
\sloppy

\title{\vspace{-2cm}Rapport du projet de \emph{Web Data Management}}
\author{Shendan Jin \& Olivier Marty}
\date\today

\begin{document}

\maketitle

\section{Présentation du projet}

Le but de ce projet est d'utiliser différentes sources d'informations sur
internet qui concernent l'état d'un moyen de transport (lignes de
métro, de train, stations vélo vide ou pleine, ou encore un bouchon sur
l'autoroute (non implémenté)) afin de prévenir l'utilisateur lorsque celui-ci va
les utiliser.

Pour cela on se connecte à son agenda (Google Calendar), et on analyse ses emails
(Gmail) pour prévoir ses déplacements, mais d'autres sources pourrait être
ajoutées, de façon modulaire.
Pour chaque événement, on géolocalise l'adresse avec l'API d'OpenStreetMap,
puis on cherche les moyens de transport utile pour ce rendre à ces coordonnées~:
lignes passant par une station proche, stations de vélos proches...
En cas de problème sur l'un de ces moyens de transport, l'utilisateur est
notifié par le medium de son choix (email, ou sms via l'API de free mobile).

\section{Description globale}

Le projet est divisé en trois principales composantes :

\subsection{La classe Event}

Cette classe représente un événement auquel l'utilisateur va se rendre.
Elle présente quatre attributs : id, date, location, et description.
Les instances sont produites à partir de deux sources : Google Calendar et
Gmail.

Les seuls mails aboutissant à la détection d'un événement sont ceux de la forme :\\
"Rendez-vous\\
le 22/02/2016 08h45\\
à Université Paris Diderot\\
pour le cours de WDM"


\subsection{La classe Source}

Cette classe représente une information provenant d'internet et qui concerne
l'état d'un moyen de transport.
Chaque instance doit fournir la méthode problem() (renvoie true si le moyen de
transport encontre un problème), et les attributs id (identifiant de la source)
et message (descriptif du problème).

Nous avons implémenté plusieurs sources~: l'état des lignes de la RATP, du
Transilien, et le nombre de vélos et de places libres dans les stations de
jcdecaux\_vls (vélos en libre service disponibles dans de nombreuses villes).

\paragraph{ratp\_trafic} Les données sont récupérées en scrapant l'url
\url{http://ratp.fr/meteo/}.
En effet la ratp ne fournit aucune API publique dynamique (l'API statique a
cependant été utilisée pour obtenir la localisation des stations et les lignes
les traversant).

\paragraph{transilien} Les données sont récupérées en scrapant l'url \url{http://www.transilien.com/info-trafic/temps-reel}.
La SNCF fournit une API pour chercher des itinéraires, ou avoir les prochains
horaires, mais pas, à notre connaissance, pour avoir des informations de trafic.

\paragraph{jcdecaux\_vls} Les données sont récupérées via l'API de jcdecaux\_vls
(voir \url{https://developer.jcdecaux.com/#/opendata/vls}).

\paragraph{} L'analyse des fichiers HTML ou JSON téléchargés est effectuée à
l'aide de la bibliothèque Python
\href{http://www.crummy.com/software/BeautifulSoup/bs4/doc/}{BeautifulSoup4}.
Nous avions en premier lieu écrit des transformateurs en xquery pour formatter
toutes les données dans un schéma commun, mais l'utilisation d'un logiciel
externe (Saxon) rendait chaque requête très lente, d'autant que le résultat
n'était pas un objet natif Python.

\subsection{La boucle principale}

Cette boucle articule les différents modules entre eux.
Elle fonctionne à l'aide d'un tas qui contient des instances de la classe Event
représentant les prochains événements dont le programme a connaissance.
De temps en temps, elle appelle les générateurs d'événements (module event) pour
vérifier si de nouveaux événements sont connus.
Lorsqu'un un événement arrive à échéance (dans l'état actuel du code on vérifie une
demi-heure avant l'échéance), on cherche la localisation de l'événement, puis
une liste d'identifiants de sources qui peuvent être utiles pour ce rendre à cet
événement (lignes passant auprès du lieu, stations vélos proches).
Pour cela elle trie les sources pas distance croissante, prend les deux meilleures
ainsi que celles qui sont à une distance comparable (au plus 100 mètres de plus
que la plus petite distance),
puis ne garde que celles qui sont moins de $2$km.
Le module source récolte alors les informations, et si un problème est soulevé
par l'une des sources, une notification est envoyée.


\section{Fichiers python}

Afin d'éxecuter un programme, il faut lancer la commande
\texttt{python3 fichier.py}.
Il faudra peut-être installer les dépendances python :
\texttt{pip3 install -r requirements.txt}

\paragraph{main.py} C'est le programme principal. Lors du premier lancement,
il demandera l'autorisation de se connecter aux API Google Calendar et Gmail.

\paragraph{demo.py} Lance une démonstration qui ignore les événements mais donne les
notifications à partir d'une adresse. Il faut souvent appuyer sur
\texttt{<enter>}

\paragraph{find.py} Ce fichier fournit une aide
pour trouver les identifiants utilisé en interne pour désigner une source.
Il propose une recherche interactive dans les listes téléchargées depuis les
différentes API.

\paragraph{ratp\_preprocessing.py} Les données statiques fournies par la ratp
n'était pas dans un format qui nous convenait, en plus de peser plus de 500Mo~!
Ce fichier extrait de ces données la liste des stations et les lignes les
traversant, le fichier final ne pesant que 500Ko.
L'url ou l'on peut trouver les données brut est indiqué en
commentaire.\\\\


\small{Note: Après l'oral nous avons changé la démo pour afficher une carte avec un marqueur par
source.}

\end{document}