Project

General

Profile


Extrait du rapport final : Partie Front-End


Du cahier des charges aux spécifications

Plusieurs points importants en lien avec l'application Front-End1 ont été établis lors de la création du cahier des charges :

  • analyse et surveillance en temps réel de la mobilité des personnes et des véhicules ;
  • faciliter les tâches de sécurité des organisateurs d'évènements ;
  • possibilité d'afficher des données prédites à l'avance, comme par exemple la congestion d'une route .

Il a également été décidé que l'accomplissement de ces différents points devra s'effectuer à l'aide d'une carte permettant de visualiser plusieurs données utiles, comme par exemple la vitesse moyenne des véhicules présents sur une route ; la manipulation de cette carte devra être aisé, rapide et les informations renvoyées par celle-ci claires.

La HEIG-VD a exprimé par la suite les données qu'elle souhaiterait pouvoir visualiser sur cette carte réalisée par la HE-Arc Ingénierie :

  • la vitesse routière, ponctuelle et/ou sa variation au fil du temps ;
  • la densité routière, ponctuelle et/ou sa variation au fil du temps (parfois appelée flux routier dans d'autres documents) ;
  • le taux de congestion, ponctuel et/ou sa variation au fil du temps.

Naviguer vers le cahier des charges complet

Des informations obtenues du cahier des charges fut réalisé un état de l'art pour mieux comprendre quels étaient les éléments essentiels d'une visualisation réussie d'une carte contenant plusieurs types de données à afficher. Afin de réduire le nombre de sites et d'applications à tester, le corpus de test fut volontairement restreint à ceux et celles qui ressemblaient de base au projet CrowdStreams, c'est-à-dire qui permettaient la visualisation de données sur une carte ; les choix plus « globaux », comme celui de la carte à utiliser, seront effectués plus tard dans le projet et décrits plus loin dans ce document.

Les résultats obtenus par cette étude sont unanimes : la méthode la plus efficace — ou du moins, la plus adoptée — est celle de surligner la carte par des données colorisées selon une échelle avec une portée de couleurs intuitives pour l'utilisateur : du rouge au vert. Le surlignage le plus récurrent se trouve être celui des routes pour indiquer le trafic routier, un type de surlignage directement en lien avec le projet CrowdStreams. Un échantillon des cas étudiés utilise également des marqueurs pour indiquer des données en des lieux précis, mais là encore on retrouve pour la plupart un code couleur allant du rouge au vert.

On retrouvera également dans certains cas une barre de défilement — ou autre système similaire — permettant la manipulation du temps auquel on souhaite visualiser les données, plutôt que de n'avoir que la possibilité de visualiser les données à partir du temps courant.

Naviguer vers l'état de l'art complet

Suite à la confirmation de la HEIG-VD pour partir sur une solution similaire aux cas ci-dessus, plusieurs choix technologiques étaient à prendre. Le plus rapide ayant été pris était la décision de partir sur une application web, réalisée en JavaScript2 ou autre langage compilé en JavaScript, le principal d'une telle application étant sa portabilité : l'utilisateur doit simplement être muni d'un navigateur Internet à jour.

2 autres choix étaient toutefois encore à faire : celui du framework3 JavaScript à utiliser et celui de l'API4 pour la visualisation et la manipulation de cartes. Pour chacun des cas, une solution open source5 et gratuite était souhaitée.

« Quel framework utiliser pour le développement de l'application ? »

L'application web sera amené à réaliser de nombreuses opérations nécessitant contrôle sur l'ensemble du document de la page. L'utilisation d'un framework fut préférée à une simple API ou à un code « maison » afin de faciliter le développement de cette application (et de rester dans de bonnes pratiques de programmation). Parmi les frameworks les plus populaires, 3 propositions ont été retenus et comparées.

  1. AngularJS
    Le nouveau framework de Google, ni lourd ni léger, très jeune mais dont l'utilisation et la popularité ont explosées.
     
  2. Backbone.js
    Léger et efficace, comporte de nombreux plugins et une grande communauté.
     
  3. Ember
    Le plus lourd des 3, mais beaucoup plus complet sans plugins et orienté productivité du développeur.

Ember ne fut au final que peu convainquant pour ce projet. Le plus grand travail de ce projet sera la manipulation d'une carte, qui sera principalement gérée par l'API choisie plus bas. Ce qui était principalement souhaité était l'obtention d'une structure dans le code avec des fonctions utiles pour manipuler le document de la page sans trop de difficultés, et sans entraver la productivité du développeur.

Le choix final se sera porté AngularJS, de part son excellent compromis fonctionnalités et rapidité d'apprentissage. L'engouement soudain des développeurs à vouloir utiliser ce framework fut également un plus dans le choix.

« Quelle API utiliser pour la visualisation et la manipulation de cartes ? »

Parmi les différentes APIs disponibles pour la visualisation et la manipulation de cartes, 2 ont été retenues et comparées plus en détail.

  1. OpenLayers
    Très complet mais également lourd ; contient de nombreuses fonctionnalités peu souvent utilisées.
     
  2. Leaflet
    Plus léger, plus performant et plus simple d'utilisation qu'OpenLayers, au prix de fonctionnalités plus restreintes.

Après quelques tests, il a été déduit que l'API Leaflet comportait tout ce dont le projet avait besoin, et qu'il n'était pas nécessaire d'employer une plus grosse API telle qu'OpenLayers.

Ce seront finalement le framework AngularJS et l'API Leaflet qui seront choisis comme étant les choix les plus appropriés au projet. Leaflet utilisera OpenStreetMap comme fournisseur de données cartographiques.

Naviguer vers la comparaison des technologies complète

Tous les choix ayant été faits, des spécifications plus techniques ont pu être établies selon ce qui avait déjà été discuté auparavant. Plusieurs maquettes furent réalisées, en gardant à l'esprit les solutations des différents sites et des différentes applications déjà existantes, vus lors de l'état de l'art. Au final, l'apparence de l'application Front-End de CrowdStreams sera basé selon les maquettes dans le menu déroulable ci-dessous :

On réeffectuera par ailleurs une étude sur les principes de la visualisation lors de la rédaction des spécifications. Celle-ci confirmera le choix du projet sur l'utilisation du surlignage en couleur pour indiquer des données sur une carte. D'autres options pour la représentation des données sur une carte seraient disponibles si par exemple on souhaitait afficher plusieurs types de données en même temps (taille, texture, orientation, etc.), mais ce ne sera pas nécessaire pour les premières version de l'application.

Naviguer vers les spécifications techniques complètes

Evolution des versions de développement

Note : selon la gestion sémantique de version6 version 2, une version de développement ne possède pas de version majeure ; son premier chiffre est toujours '0'. Un logiciel avec une version de développement est en général utilisable, mais ne contient pas l'intégralité des fonctionnalités désirées ou celles-ci ne sont pas encore fixées et testées pour d'éventuels utilisateurs finaux. Ce projet étant une preuve de concept sans réels utilisateurs finaux, il ne possède que des versions de développement.

Version 0.1

Plusieurs extraits de données furent fournis en exemples par la HEIG-VD :

  • des données statiques permettant de visualiser le centre routier de Varsovie ;
  • des données sur le temps pour l'affichage dynamique d'informations pour les routes ci-dessous ainsi que de plusieurs voitures.

Le rôle principal de cette version 0.1 est d'effectuer une première extraction et utilisation de ces données et de les présenter sur une carte de manière simplifiée, le but étant surtout d'obtenir des résultats. Plusieurs interactions possibles ont été introduites dans cette première version :

  1. chargement des données fournies, nécessaire pour un quelconque affichage ;
  2. choix de quel type de données afficher (toutes les routes, uniquement les routes avec des données sur le temps, toutes les voitures) ;
  3. changement du temps représenté par la carte, modifiant les informations indiquées par la carte ;
  4. affichage des détails (console JavaScript) d'une route ou d'une voiture en cliquant dessus.

Dans cette version, les routes ne possédant pas de données sur le temps sont affichées en bleu, la couleur par défaut donnée par l'API Leaflet. Les autres routes virent du rouge au vert :

  • le rouge indique une route dont le trafic est bloqué, dont les voitures sont à l'arrêt ;
  • le vert indique une route dont le trafic est fluide, dont les voitures roulent à la vitesse maximale.

Un code couleur similaire s'applique également pour les voitures : rouge pour une voiture à l'arrêt, vert pour une voiture roulant à 60km/h.

Parfois, des routes ou des voitures apparaissent en cyan ou une autre couleur proche. Cette situation arrive :

  • pour les routes lorsque les voitures dépassent sa vitesse maximale ;
  • pour les voitures lorsqu'elles dépassent 60km/h.

La version 0.1 de CrowdStreams a remis plusieurs aspects du projet en question, notamment le chargement des données et l'affichage de celles-ci.

On peut constater lors de l'activation de l'affichage de toutes les routes un chargement important dans l'application, donnant l'impression qu'elle a gelé pour au moins 5 secondes. Ceci n'est pas dû au chargement des routes depuis leur fichier texte, qui se fait une seule fois et en moins de 2 secondes sur un ordinateur aux performances modestes, mais bien à leur affichage sur la carte. La technologie qu'utilise l'API Leaflet pour l'affichage d'objets sur une carte est le SVG7, dont les performances pour l'ajout et le retrait chutent drastiquement en cas de nombreux objets ajoutés/retirés. Les autres actions de la carte, comme se déplacer ou faire un zoom, prennent également plus de temps à s'effectuer en cas d'affichage d'un nombre élevé d'objets.

Un autre problème fut détecté dans le chargement des routes. Ce dernier est négligeable pour cette version, mais pas pour les versions futures qui contiendront nettement plus de données à charger : le lien entre les routes et leurs nœuds. Les positions de latitude et de longitude pour les routes sont données au moyen de nœuds qui contiennent cette information. Or, les routes ne contiennent que l'identifiant de leurs nœuds, et non leur position. En conséquence :

  • soit on charge l'intégralité des nœuds pour pouvoir les indexer, puis on les lie à leurs routes lorsqu'on charge ces dernières ;
  • soit on charge les nœuds «à la volée» en même temps que leurs routes, mais cela implique d'effectuer pour chaque route une recherche intégrale dans les nœuds.

La 1ère option serait trop gourmande en mémoire pour une application pouvant contenir « le monde entier » et la 2e trop lente.

D'autres détails et améliorations possibles furent également relevés de cette première version, mais les 2 problèmes les plus conséquent sont ceux indiqués ci-dessus. Un document à part présente plus en détails cette version, ainsi que ses problèmes et ses propositions d'ajouts de la HE-Arc Ingénierie pour la HEIG-VD.

Naviguer vers les détails de la version 0.1 et de ses éventuels patchs
Naviguer vers les propositions d'ajouts post-version 0.1
Naviguer vers la démonstration en ligne de la version 0.1

Version 0.2

Suite à la création de la version 0.1, une séance plénière fut organisée, réunissant les principaux acteurs de la HEIG-VD et de la HE-Arc Ingénierie afin de discuter du développement de la version 0.2. Les principaux points ressortis étaient les suivants :

  • commencer à utiliser le service web REST8 d'INUIT pour récupérer les données à afficher sur la carte — l'application finale devrait de toute manière l'utiliser et cela facilitera l'ajout de données à tester ;
  • ajouter la gestion du temps, de manière « libre » pour pouvoir naviguer dans le temps ou en temps réel ;
  • permettre le suivi d'une ou plusieurs voitures avec la gestion du temps (automatiquement déplacer la carte si une voiture suivie en sors) ;
  • ajouter la gestion des simulations &mdash on souhaite pouvoir les gérer dans l'application, elles n'étaient pas juste là pour différencier les exemples de données ;
  • ajouter un graphique pour pouvoir visualiser les données dans le temps d'une route ou d'une voiture ;
  • la HEIG-VD regardera pour lier les nœuds avec leurs routes respectives pour éviter un des problèmes décrits dans la version 0.1 ;
  • la HE-Arc Ingénierie regardera si le service web REST d'INUIT contient les données nécessaires pour le fonctionnement correct de l'application Front-End.

En plus de ceci, la HE-Arc Ingénierie décida d'implémenter un système de chargement bloc par bloc à la carte, éliminant ainsi l'effet de gel provoqué par le chargement d'un nombre conséquent d'objets en même temps.

Naviguer vers le procès-verbal de la séance plénière du 25 septembre 2015

La version 0.2 de CrowdStreams remplit la plupart de ces nouveaux points discutés, l'exception étant le suivi d'une ou plusieurs voitures. Son apparence change en plusieurs points par rapport à la version 0.1. De nouveaux moyens d'interactions ont été implémentés :

  1. contrôle du zoom supplémentaire, en plus de la roulette de la souris ;
  2. choix de quel type de données afficher, déjà présent dans la version 0.1 mais avec un menu plus concis ;
  3. choix de quelle simulation utiliser avec un rechargement automatique des données ;
  4. ajout d'un texte d'explication simple, mais indispensable ;
  5. ajout de barres de chargement pour garder l'utilisateur informé de l'état de la carte ;
  6. changement du temps représenté par la carte, déjà présent dans la version 0.1 mais avec de meilleurs contrôles dont la gestion du temps.

D'autres différences à noter sont le changement de couleur des routes n'ayant pas de données en gris (moins tapant que le bleu par défaut) et la possibilité d'afficher les données sur le temps d'une route ou d'une voiture en cliquant dessus. L'affichage de ces données se fait au moyen d'un graphique créer à l'aide de l'API Google Chart.

La version 0.2, contrairement à la 0.1, ne sera pas suivie par une séance plénière. La HEIG-VD indiquera les nouveautés à ajouter à l'avenir après avoir testé la nouvelle version, et souhaitera une séance après une réorganisation de leur côté. Le développement de la version 0.3 à alors directement commencé sans séance au préalable.

Naviguer vers les détails de la version 0.2 et de ses éventuels patchs
Naviguer vers la démonstration en ligne de la version 0.2

Version 0.3

En plus de rajouter la dernière fonctionnalité manquante demandée depuis la réalisation de la version 0.1, à savoir le suivi d'une ou plusieurs voitures, d'autres demandes et informations de la HEIG-VD avaient été ajoutées par email :

  • la possibilité d'afficher les détails d'un objet sur la page et non la console JavaScript ;
  • la gestion d'une nouvelle donnée introduite dans le service web REST d'INUIT : la densité routière ;
  • la possibilité de couper le chargement automatique sans devoir enlever l'affichage des routes et/ou des voitures.

Ces différentes fonctionnalité ont été introduites dans la version 0.3 de CrowdStreams :

  1. affichage des données directement sur la page au moyen d'une bulle d'informations, en plus des données de la console JavaScript ;
  2. possibilité de charger les routes de plusieurs manières : sans données sur le temps, avec leur vitesse routière ou avec leur densité routière ;
  3. possibilité de désactiver le chargement automatique des données afin d'éviter des chargements trop longs ;
  4. affichage d'une nouvelle barre de chargement unifiée par rapport à la version 0.2 qui enchaînait plusieurs barres de chargement (1 par type de données à charger).

L'apparence visuel de la version 0.3 change peu par rapport à celle de la version 0.2, et ne doit son incrémentation de version que par un changement majeur dans le code.

La sortie de la version 0.3 fut suivie d'une séance plénière, comme pour la version 0.1. La version 0.2 n'ayant pas eu de séance, elle fut également un sujet dans cette séance. Les principaux points ressortis étaient les suivants :

  • quelques améliorations visuelles seraient souhaitées :
    • ajouter des légendes aux graphiques en bas de page ;
    • améliorer la compatibilité de l'application entre les navigateurs (problèmes d'affichage sous Safari et Firefox) ;
    • remettre dans la version 0.3 les indicateurs de chargements présents dans la version 0.2 (qu'est-ce que la carte est en train de charger&nbsp?) ;
  • améliorer la gestion des chargements trop volumineux et des opérations trop lourdes :
    • automatiquement mettre en pause le chronomètre lors de chargement&nbps;;
    • désactiver le chargement automatique de données au-delà d'un certain seuil de zoom ;
    • annuler le chargement des données au-delà d'un certain volume (l'utilisateur se déplace très rapidement et sans interruptions dans des zones inexplorées auparavant) ;
  • afficher une barre de zoom, comme dans Google Maps.

La HEIG-VD émettait également le souhait de pouvoir afficher des prédictions : des données prédites, calculées à l'avance de leur côté et dont l'affichage sur l'application Front-End était désiré. L'implémentation n'était pas encore nécessaire, mais les spécifications quant à ces prédictions étaient à mettre en place à partir de la version 0.3. En plus de ceci, elle précisa que le temps indiqué dans les données sur le temps fournies par le service web REST d'INUIT n'était pas un timestamp9, mais bel et bien un simple temps. Une gestion de la date côté client sera à implémenter.

Naviguer vers le procès-verbal de la séance plénière du 11 décembre 2015

Tous les points énumérés ont été réalisés dans le patch de version 0.3.1, à l'exception de l'annulation du chargement des données au-delà d'un certain volume. En l'état, permettre une annulation de chargement de données prendrait passablement de temps, et a été éventuellement mise de côté pour une prochaine version ou patch de version.

Naviguer vers les détails de la version 0.3 et de ses éventuels patchs
Naviguer vers les propositions d'ajouts post-version 0.3
Naviguer vers la démonstration en ligne de la version 0.3


TODO « Epilogue » : v0.4 (v1.0) ? A compléter une fois la version sortie !
Conversion NPM avec Browserify, prédictions, annulation des chargements conséquents...


1 Ce qui est visible et manipulé par les utilisateurs finaux dans une application. Ce terme s'oppose au Back-End : ce qui est « caché » pour les utilisateurs.

2 Langage de programmation utilisé par les développeurs web pour la création de sites web dynamiques.

3 En programmation, un framework est un ensemble d'outils permettant de structurer un projet et d'en faciliter le développement dans son intégralité. Plus lourd qu'une API et possède des contraintes d'utilisation.

4 Collection d'outils simplifiant des tâches de développement, comme l'affichage d'une carte. Plus léger qu'un framework et en général sans contraintes d'utilisation.

5 Dont les sources sont ouvertes ; on possède la liberté de lire et d'étudier le code. Attention toutefois : un code open source n'est pas implicitement libre d'utilisation et/ou de modification (on parlerait alors de code « libre » — « free » en anglais).

6 http://semver.org/spec/v2.0.0.html (original), http://semver.org/lang/fr/spec/v2.0.0.html (français « Google Traduction », préférer l'original)

7 Format d'image où cette dernière n'est pas directement stockée, mais où l'on va stocker des informations permettant de la reconstruire, indépendamment de sa taille. Cela permet d'obtenir des images nettes, quelque soit leur taille.

8 Un service web permet de mettre à disposition des outils en ligne par Internet. REST est un style d'architecture à suivre pour réaliser un tel service, souvent comparé (à tort) avec SOAP.

9 Temps écoulé depuis le 1er janvier 1970 à minuit UTC, en une unité. Généralement le nombre de secondes (UNIX timestamp) mais les millisecondes voire même les nanosecondes sont parfois utilisées.