Comment y aller

Le but est de fournir des itinéraires en se basant sur des paramètres externes la position de départ, la
position d’arrivée et la charge que l’utilisateur porte, et des paramètres internes qu’on récupérer au
fur et à mesure de l’exécution à savoir le temps de départ et les conditions météorologiques dans la
zone de déplacement.

Les hypothèses :

 On doit être capable de manipuler (ajout/suppression/ modification) les données des

moyens de transports.
 On doit fournir plusieurs alternatives à l’utilisateur.
 On doit avoir la capacite de modifier l’algorithme qui fournit les résultats.

Les solutions disponibles :

 L’utilisateur des apis de directions disponible et qui coute chère, et qui ne prennent des
paramètres comme la météo, et si on affecte les filtres après l’appel au API, on risque d’avoir
une liste vide au cas ou il y a un moyen principale dans le résultat fourni par l’API et qui dans
notre cas ne satisfait pas une certaine contraintes, Aussi l’utilisation des API existantes, nous
ne donne pas une visibilité que ce soit sur les données ( pas de modification ) et aussi pas
possible d’implémenter le temps de départ comme variable.
 Implémenter le système de données dans le backend et implémenter le system de calcul
(choix adopté)

Les choix de technologies :

Les calculs sur les réseaux de moyens de transports sont basés sur la théorie des graphes, en
appliquant des algorithmes de plus court chemin et des plusieurs court chemin
(notre cas), pour cela on a prévu une architecture
Les sources de données des transports :
Parmi les exigences c’est d’avoir un système qui peut être rempli automatiquement via une
plateforme (dans notre cas on a utilisé Openstreetmap, une plateforme open source), aussi d’avoir
une manipulation sur ces données (qui, parfois, contiennent de erreurs). Et Avoir la possibilité
d’ajouter les données manuellement
Le calcul :
Pour les itinéraires fournis par google map ou d’autre solution pour les transports, ils utilisent des
algorithmes de calculs de plus court chemin, avec des serveurs très puissants pour garantir une durée
de calcul optimale, avec un pré-traitement du graphe pour avoir une liste des couples (aller ->
arrivée) déjà calculées, et qui sont envoyées à l’utilisateurs directement.

Dans notre cas, on va utiliser des algorithmes proposes par la base de données neo4j.

La conception de système de
données :
Les données fournies par OSM sont en générale pas organiser.

Le but est de rendre ces informations sous une format qu’on peut utiliser pour faire les calculs, et
aussi être modifiable à travers l’interface de data management.

Image données stockées dans MongoDB et après elles seront converties en des données stockées sur
Neo4j pour faciliter les manipulations et les calculs :

On a utilisé les classes suivantes pour modéliser les traitements de données venantes de OSM 
MongoDB  Neo4j

Insertion de données:
1. Le traitement se fait en 5 phases :
2. Le choix de la ville
 3. La répartition de la ville en des petits morceaux qui contiennent des sommets < 5000
sommets (contrainte posée par OSM)
a. Récupération du fichier. OSM
b. Conversion en GeoJSon
c. Traitement Regex
d. Récupérer une liste de moyens dans ce morceau
e. Filtrer les duplicates de la liste et l’ajouter dans la liste des « Features ».
4. Pour chaque « Features » on récupère les sommets et après les WayPoints (les points de
passage entre les stations qui aide à dessiner les Polylines).
5. Les données de format OSM (NODE et WAY) => (Station et Relation).
6. Lier les stations avec les points de passages (WayPoints)

« Indication sur le problème de liaison » inverser l’ordre et checker … Problème existe à ce point.

Insertion manuelle :

On créer les stations, pour faciliter l’insertion de cette donnée et pour éviter d’avoir un ajouter d’un
même sommet plusieurs fois,

1- on ajoute les types (Type : BUS ou Covoiturage)

2- on ajoute les spécifications (Type : Covoiturage, Spécification : George X11)

3- on ajoute les stations, et dans l’ajout des stations on affecte pour le départ et l’arrivée une liste
des moyens qui passe par ce stations (dans notre cas, Type Covoiturage, Spécification : George X11)

4- Après c’est l’ajout de la relation :

Dans l’ajout de la relation on a plusieurs paramètre faite pour traiter toute sorte de données de
moyens (au cas ou on a besoin d’ajouter un métro manuellement, ou un service de vélo ) on a un cas
diffèrent de celui de covoiturage ( seul départ -> seul arrivée ), alors que le métro ( plusieurs départ,
plusieurs arrivées), une variable d’horaires pour moyens qu’on des horaires, si c’est désactivée on le
considère comme tjrs disponible ( après ca peut être pour les moyens de transports non réguliers,
avec un système de Machine Learning pour fournir une prévision sur le temps d’attente)

On a un moyen X qui passe par 4 stations (A, B, C et D)

On a la possibilité de modifier l’ordre de stations

B -> A -> D -> C

La possibilité de récupérer les points de passage (WayPoints)

On a programmé un service de direction dans le backend, et qui fournit les WayPoints pour chaque
sous-relations- peut-être plus tard il sera complètement autonome – basé sur les Routing-machine.

La raison pour laquelle on a stocke les WayPoints dans l’étape de l’ajout de la relation, c’est pour
éviter d’utiliser les requêtes de directions à chaque fois l’utilisateur demande les directions (raison de
cout)

Les domaines :

Les repositives :
On implémente les interfaces existantes dans les bibliothèques, pour gérer les données.

Ex : On manipule des documents de MongoDB, pour cela on implémente l’interface MongoDB

Pour les objets de Neo4j, on implémente l’interface Neo4j.

Les Services :
Pour chaque utilisation de la base de données, on crée les fonctions qui utilisent les « Repository » et
qui sont utiles pour l’exécution de notre backend.

Cela se fait en deux phase :

Prototypages de fonctions : Service XXXX interface

L’implémentations des fonctions : une classe qui implémente l’interface

Migration :
Récupérer les documents qui contiennent les données des moyens de transports (Stations et
Relation) et créer des sommets (Node) et des relations (Edge).

Les contraintes :

La charge et la météo dans les positions de départ et d’arrivée, pour ça on a utilisé le service gratuit
OpenWeather qui a travers des apis qui prennent la localisation comme paramètre nous donne les
informations suivantes :

En utilisation les descriptions, on peut filtrer les résultats des calculs.

La même chose pour la charge.

Installation :
Pour exécuter vous devez installer :

Maven, Docker, Docker Compose, Angular.

Tutorial pour Angular : https://cli.angular.io/

Tutorial pour Docker : https://docs.docker.com/install/linux/docker-ce/ubuntu/

Tutorial pour Docker Compose : https://docs.docker.com/compose/install/

Tutorial pour maven : https://linuxize.com/post/how-to-install-apache-maven-on-ubuntu-18-04/

Les commandes à exécuter pour tester le projet  :

A l’intérieur du dossier « resttest » qui correspond à l’interface :

On n’exécute :

ng serve

--------------

Après, Il faut ouvrir le projet Java.rar,

Il faut exécuter :

mvn Package

Pour créer le fichier exécutable, avec lequel on va créer l’image docker à l’aide de la commande :
dans le dossier Target :

docker-compose up --build --force-recreate --renew-anon-volumes

Une fois tous les services s’exécutent.

On Peut visiter le Lien

http://localhost:4200/

Pour visualiser l’interface de gestion de données et pour faire le test, elle ne contiendra pas des
informations.

Pour cela il faut visiter le lien

http://localhost:8080/setup

Pour charger les fichiers JSON en base de données (ceci est fait pour éviter d’avoir une base de
données vides dans la première exécution, vu qu’on utilise une dans un containeur de docker)
Une fois terminé, l’interface : http://localhost:4200/

Les informations de la villes paris :

L’entête de la page :
Add Type : pour ajouter un nouveau type de moyen de transport.

Add Station : Pour ajouter une station personnalisée.

Add Relation : Pour ajouter un moyen de transport, et ses informations (les points de passage, durée,
cout.)

Relations : pour afficher tous les moyens de transports disponibles dans la ville.

Station : pour afficher toutes les stations dans la ville.

Auto-OSM : cette option prend, un code de la forme. Qui contient les Id des
moyens dans transport dans la plateforme Openstreetmap (Open DATA), qui "123652",
{
nous aide à remplir la base de données automatiquement
"features": [
"1253894",
Search : Pour faire les tests. "1253898",
"1253899",
Mais avant de faire les tests on doit visiter la Page de Migration : "1253900",
]
}

On doit, convertir les données (documents : MongoDB => graph : Neo4j)

On clique sur 1, on attend, et après on clique sur 2

Vous pouvez déplacer les curseurs de départ et d’arrivée.

Search :
Le résultat :
Pour visualiser les bases de données :

MongoDB : http://localhost:8081/

Username : root

Password : nooneknows

Neo4j : http://localhost:7474/

Username : neo4j

Password : nooneknows