Rapport de TER : Collecte de médias géo-localisés et recherche de points d intérêt avec l algorithme Mean Shift Martin PUGNET Février 2014

Transcription

1 Rapport de TER : Collecte de médias géo-localisés et recherche de points d intérêt avec l algorithme Mean Shift Martin PUGNET Février 2014 résumé : Ce projet a pour but de récupérer des données géolocalisées d un réseau social de partage d image appelé Flickr, afin de pouvoir analyser les points d intérêts et les trajectoires courantes. On expliquera l utilisation de l algorithme meanshift pour la recherche des points d intérêts, et l utilisations de toutes les API nécessaires pour obtenir les informations et visualiser les résultats. mots-clés : Flickr, géolocalisation, meanshift, clustering. 1 Introduction Dans le cadre du projet de recherche de master 1 Informatique, j ai choisi d effectuer un projet concernant la collecte de données géolocalisées, et leur analyse. Ce projet a été proposé par l équipe DM2L 1 du LIRIS. Mes encadrants étaient Marc PLANTEVIT et Mehdi KAYTOUE. Le projet global était de récupérer des données géolocalisées de plusieurs réseaux sociaux (tels que twitter, trafic,...), concernant la ville de Lyon, pour pouvoir appliquer ensuite des algorithmes en combinant certaines de ces données entre elles. Dans ce projet, ma partie de travail consistait à récupérer des données depuis le réseau social Flickr 2, déterminer comment les stocker, trouver des points d intérêt et définir les trajectoires des utilisateurs. 2 Collecte des données La première étape du projet a été la constitution d un jeu de données sur lesquelles je pourrais tester et vérifier les algorithmes de détection de points d intérêts et de trajectoires. J ai utilisé les outils fournis par Flickr pour récupérer les données et je les ai stockées dans une base de données locale sur laquelle j étais libre de faire tous les tests nécessaires. Dans cette partie, je vais aborder les détails sur la récupération des données et leur stockage, ainsi que les problèmes que j ai rencontré et que j ai résolu. 2.1 Flickr Une API 3 est mise à disposition par Flickr et permet de faire des requêtes sur les photos selon plusieurs critères. Les informations qui nous intéressent sur les photos sont : les dates de prise et de publication de la photo, les tags associés (utile pour la description en intention des points d intérêts), l utilisateur l ayant (utile pour l élaboration des trajectoires par la suite), la description, la géolocalisation. Nous avions le choix entre l utilisation de l API fournie par Flickr, ou l utilisation de programmes plus faciles à utiliser, mis à disposition par la communauté, pour récupérer les données. La première partie de mon travail a donc été de voir si certains de ces outils pouvaient nous servir pour récupérer toutes les informations dont nous avions besoin. J ai donc testé plusieurs programme dont un en C# qui permettait 1. Data Mining and Machine Learning 2. Réseau social de partage d images créé en 2004, ayant environ 1 million de photos ajoutées par jour 3. Application programming interface : interface de programmation 1

2 de faire une recherche selon une zone géographique, et qui permettait aussi d avoir accès à toutes les informations nécessaires. J ai utilisé cet outil, pour gagner du temps en récupérant les données. Pour la récupération des données déjà présentes sur Flickr, il a fallut tester plusieurs paramètres, comme par exemple spécifier une zone géographique à l aide des longitudes et latitudes minimum et maximum, cela correspondrait donc à une zone rectangulaire, ou encore spécifier un centre et un rayon, ce qui correspondrait à un cercle. Ces deux requêtes ne nous retournaient pas forcément les mêmes photos. J ai donc du combiner les deux recherches. De plus, d autres problèmes sont apparus au fur et à mesure que j utilisai cette API, notamment le fait qu à chaque fois il y avait de moins en moins de photos résultant des requêtes. Une solution a été de reparcourir les photos récupérées, et de refaire une requête par utilisateur (en gardant les contraintes géographiques). Le problème reste le même pour la récupération périodique des nouvelles photos. Il nous fallait donc un programme qui récupère les photos selon la zone géographique, ou selon le rayon, et ensuite regarder si les utilisateurs n avaient pas pris encore d autres photos. Le programme sera identique au programme de récupération déjà utilisé, si ce n est que la date de publication des photos sera prise en compte, pour pouvoir récupérer uniquement les nouvelles photos. Enfin, une autre problématique de la récupération de données était l utilisation du fil public de Flickr, qui nous retournait un flux de données selon certains paramètres. Cela nous aurait permis de récupérer les photos en temps réel (L API de twitter imposait un délai avant que les tweets soient disponibles sur le système de récupération en temps réel). J ai donc essayé d utiliser cette méthode pour récupérer uniquement les photos de Lyon. Le problème était que nous ne pouvions pas effectuer une recherche selon la localisation des photos (ce n est pas permis par Flickr). En effet, si l on veut récupérer des photos prise à Lyon, il faudrait définir les tags (ou les combinaisons de tags) qui sont utilisés uniquement dans Lyon. La difficulté réside dans le fait qu il faudrait récupérer les tags de toutes les autres villes et ainsi définir ceux qui ne sont utilisés qu à Lyon. Néanmoins, cette méthode n est pas utilisable dans le cas de la seule ville de Lyon, et nous avons donc abandonné cette idée. A la place, on a créé un programme qui se lancera périodiquement et qui regardera les nouvelles publications. 2.2 Cassandra La question du stockage des données s est posée au début du projet pour l utilisation d une base de données NoSQL 4. L estimation du nombre de photos étant très important ( photos sur 3 ans), nous nous sommes finalement décidés à l utiliser. Si on compte le fait qu on ait un programme fonctionnant tous les jours pour récupérer de nouvelles photos, et si on prévoit d adapter le stockage à plusieurs villes, on aurait énormément de données, et donc il nous faudrait une base de donnée efficace pour pouvoir les analyser. Le choix s est donc porté vers Cassandra 5, qui est une base de données qui était déjà utilisée par d autres parties du projet (notamment la partie récupérant des données de Twitter). Le fonctionnement de cette base de données est un peu différent du fonctionnement des autres bases de données. La syntaxe ressemble au SQL, mais quelques outils manquent. Par exemple il n existe aucun moyen de trier des données et de faire de regroupement selon les valeurs de certaines colonnes. On ne peut pas non plus filtrer en utilisant des inégalités. Le fonctionnement pour l insertion simple de données et la lecture simple étant par contre identique, j ai donc pu utiliser rapidement cet outil pour sauvegarder les données. Cependant, étant donné les soucis de groupements de données, la plupart des traitements sont faits par des scripts en Python. 4. Base de données non relationnelle, plus efficace dans le cas de nombreuses données 5. http ://cassandra.apache.org/ Rapport de TER de Martin PUGNET 2

3 Pour ce qui est du stockage des données, toutes les données des photos sont stockées dans la même table, et on stocke toutes les informations nécessaires, citées plus haut. L identifiant utilisé est celui de la photo retournée par Flickr, ce qui nous permet de n avoir aucun problème de doublons tant que la base de Flickr reste cohérente. Enfin, l analyse des données ne modifie pas du tout cette table. Celle ci possède un accès en lecture dont elle se sert donc uniquement pour construire d autres tables, contenant les points d intérêts, l historique des utilisateurs, les trajectoires connues ou encore les liens entre chaque photo et chaque point d intérêt. 3 Analyse des données Dans cette partie, la problématique était de trouver, à partir d un jeu de données assez conséquent (ici photos distinctes), des points d intérêts correspondant aux zones de densités. Je vais donc commencer par expliquer comment les points d intérêts ont été trouvés, comment ils ont été décrits et comment j ai pu vérifier si ils étaient judicieux. Pour cette partie je me suis beaucoup servi de l article [1] 3.1 Decouverte des points d intérêts Par la suite, nous aurons besoin de détecter des groupes de données, afin de pouvoir les différencier entre elles. C est le but du clustering. Celui ci permet de classifier les données selon certains critères. Ici nous allons effectuer un clustering par densité, ainsi, chaque regroupement correspondra à une zone d intérêt, et son centre sera le point d intérêt final. L utilisation de clustering basé sur densité nous permet de détecter des formes non-convexes, ce qui n est pas le cas des autres types de clustering. Comme on peut l observer sur la figure 1, les algorithmes meanshift et DBscan détectent parfaitement le cercle, alors que les autres algorithmes ont du mal. Figure 1 Distinction des formes de clusters Après avoir stocké toutes les données déjà présentes sur la ville de Lyon dans Flickr, mon but a été de les analyser afin de trouver les points d intérêts de la ville. Pour cela, j ai essayé plusieurs algorithmes comme DBScan (figure 2.A) ou meanshift (figure 2.B), qui sont des algorithmes de recherche de densité. Le but est de trouver les zones à forte densité, ainsi que leurs centres, afin de pouvoir déterminer le point d intérêt. Pour tester ces algorithmes, j ai utilisé une librairie 6 appelée SciKit 7, qui est très détaillée, et qui fournit des implémentations de meanshift et de DBscan. 6. Ensemble de fonctions 7. scikit-learn.org/ Rapport de TER de Martin PUGNET 3

4 Figure 2 Résultats des recherches de densité, DBscan à gauche, meanshift à droite Après plusieurs essais de paramétrages des algorithmes, je me suis rendu compte que DBscan n allait pas convenir au projet. En effet, il avait tendance à toujours regrouper des zones plutôt proches, qui auraient dues être dissociées. Pour donner un exemple concret, on avait toujours Fourvière liée à la place Bellecour et à l hôtel de ville, ce qui devrait compter comme plusieurs points d intérêts (figure 2.A). Du coté de meanshift, il y avait également des problèmes. L algorithme trouvait des points d intérêts pour toutes les photos solitaires (ou ayant peu de voisins). Heureusement, cela dépendait du paramétrage de meanshift, j ai donc pu utiliser cet algorithme afin de détecter des points d intérêts (figure 2.B). DBscan commence son traitement selon un ensemble de points sur un plan.il les classe selon trois catégories : ceux ayant plus d un certain nombre de voisins (Core points), ceux ayant plus d un certain nombre de voisins mais étant proche d un core point (border points), les autres. Ensuite, pour chaque membre de la liste de Core points, il leur associe leurs voisins. Dans le cas où il rencontre un border points voisin d un Core points, il assimile également les voisins de ce border points, et ainsi de suite. Pour le cas de Meanshift, celui ci commence avec un certain nombre de points, soit fixés, soit calculés par la fonction. Ensuite, une fois choisi, il regarde tous les points de sa zone de recherche (figure 3 A), et se déplace sur le centre de tous les points (figure 3 B). Il recommence ensuite (figure 3 C) jusqu à trouver stabilité (figure 3 D). Dans ce cas, tous les points par lesquels il est passé sont donc des points appartenant à son groupe de points. Figure 3 Figure d explications de meanshift Rapport de TER de Martin PUGNET 4

5 Concernant la fonction que j utilisai, plusieurs paramètres existaient concernant l appel de meanshift. Le premier paramètre est la bandwidth, qui correspond au rayon de voisinage à utiliser dans l algorithme. En utilisant les coordonnées GPS, la valeur correspond à environ 100 mètres d après [2]. Nous avons donc utilisé cette valeur qui nous semblait acceptable pour détecter les points d intérêts. Un autre des paramètres étaient les seeds, qui correspondent aux points de départ de l algorithme. Pour cela, j ai laissé la fonction générer les seeds selon les données. Un autre paramètre, cluster all, nous permet uniquement de relier toutes les photos à un cluster et n a aucun lien sur la durée d exécution de la fonction, ni sur les clusters obtenus. Le seul changement était donc que toutes les photos sans point d intérêt sont liées au plus proche. Afin d éviter de fausser les résultats dans l analyse des trajectoires, j ai mis ce paramètre à faux. Enfin le dernier paramètre était le paramètre min bin freq qui correspond à la taille minimum d un cluster. Ainsi, en la fixant à 15, j ai obtenu un filtre pour ne conserver que les points d intérêts significatifs (avant on avait un point d intérêt pour chaque photo isolée). Cela a permis de réduire de beaucoup le nombre de points d intérêts (voir 4 A), de plus son utilisation rendait l algorithme plus rapide (voir 4 B). Figure 4 Paramètres de Meanshift Concernant le traitement des données, tout se faisait en python. La première étape du traitement a été de projeter mes coordonnées GPS en coordonnées planaires, afin de mieux évaluer les distances. La projection était une projection vers Lambert 2 étendu 8. Pour ce faire, j utilisai l outil Convers3 9, qui me fournissait une librairie en C# pour transformer les coordonnées. Les points étaient ensuite traités par le programme python, qui en retirait les points d intérêts. L un des soucis de cette méthode est qu on perdait le sens du paramétrage de meanshift. En effet, après la transformation, on avait du mal à savoir à quelle distance réelle correspondait le paramètre que nous fixions pour exécuter meanshift. Ayant trouvé une publication d un projet similaire effectué sur les villes de Londres et de Paris qui n utilisait pas de projection planaire [2], j ai essayé en utilisant les coordonnées GPS non modifiées, ce qui nous à permis de paramétrer meanshift pour avoir un rayon de 100 mètres dans sa recherche de voisins. 3.2 Caractérisation des points d intérêts Enfin, après avoir pu trouver les points d intérêt que nous voulions, il a fallut les décrire. Pour effectuer cela, je me suis servi des tags liés aux photos. J ai utilisé un élément python me permettant de compter le nombre d occurrences de chaque tag (en enlevant les accents et les majuscules), ensuite j ai pu les trier par nombre d occurrences et donc afficher les 10 tags les plus occurrents pour chaque point d intérêt. Le premier problème que j ai eu a été le fait que, pour chaque point d intérêt, on retrouvait toujours le tag Lyon, ou France. J ai donc modifié cela pour compter le pourcentage d apparition de ce tag pour ce point d intérêt, comparé au pourcentage d apparition du tag sur tous les points d intérêts. Cela m a permis de 8. projection planaire utilisée pour la France 9. http ://vtopo.free.fr/convers3.htm Rapport de TER de Martin PUGNET 5

6 ne trouver que les tags les plus significatifs des zones voulues. Un autre problème a été le nombre de tags correspondant aux noms des appareils photos, ou encore à des données d applications. Ceux utilisés par d autres applications ont pu être rapidement détectés, les autres non. Il arrive donc encore qu un point soit décrit en partie par une marque d appareil photo. La question de l utilisation des descriptions s est aussi posée. On s est alors rendus compte que moins d un quart des photos avait une description de saisie, et que cela serait beaucoup moins significatif que les tags. On compte photos n ayant aucun tag de saisis sur les photos qu on a pu récupérer. Sur les mêmes photos, on en compte n ayant aucune description. Étant donnée la difficulté d analyser la description, dans laquelle il faut exclure tous les mots ne décrivant pas la photo, l intérêt de l analyse des descriptions est très réduit. La description effectuée actuellement en cherchant le tag le plus fréquent pourrait être une recherche de motifs (c est à dire à une recherche des combinaisons fréquentes de tags) de taille 1. On peut également réfléchir à une recherche de motif de plus grande taille, afin de pouvoir décrire plus précisément un point. Pour ce faire, il faudrait rechercher la fréquence des combinaisons de tags. Elles devraient néanmoins être de taille raisonnable pour ne pas nous retrouver avec des combinaisons ayant soit une fréquence de 1 soit une fréquence de 0. Il faudrait donc déterminer la taille des combinaisons adéquates et ensuite calculer toutes les combinaisons de tags. Pour ce qui est du filtre effectué pour conserver l unicité d un tag pour un point d intérêt donné, celui ci devrait être adapté pour filtrer l unicité d une combinaison. Cette étape de fouille de données est également utile dans le cas des trajectoires. On pourrait faire une recherche de motifs discriminants par exemple pour pouvoir trouver les trajectoires fréquemment utilisées. 3.3 Visualisation des résultats Après avoir calculé les points d intérêts, le meilleur moyen pour vérifier les données était de les projeter sur une carte. Pour ce faire, je disposai d un exemple utilisant l API de Google Maps, sur laquelle je pouvais placer des points. Mes centres d intérêts étant calculés par python, j ai modifié mon programme pour que celui ci modifie une page html, me permettant de transmettre donc leurs coordonnées. Ensuite, je demande à la page de s ouvrir. Sur cette page, j ai réglé la coloration des points pour que celle ci dépende du point d intérêt auquel il est relié. J ai ensuite ajouté le fait qu on puisse visualiser les tags récurant en cliquant sur chaque points d intérêts, ou encore visualiser la photo en cliquant sur chaque point secondaire. La différence entre les deux est signifiée par l utilisation d une autre icône (voir 5 A). Ceci était réalisable quand j effectuai mes tests sur peu de données (3000 lignes sur l exemple), mais passé les données, je ne pouvais pas afficher tous les points, et je me contentais donc juste d afficher les points d intérêts (voir 5 B). On pourrait également afficher un échantillon de photos autour de chaques points d intérêts, la limitation venait seulement du temps de chargement de la page, et du fait que le navigateur ne supportait pas la lourdeur de cette page lorsque j affichais toutes les photos. 4 Construction et visualisation des trajectoires 4.1 Stockage des points d intérêts La première étape pour la construction des trajectoires a été de reconstruire une base de donnée permettant de stocker des points d intérêts, de stocker des historiques d utilisateurs et ensuite de calculer des trajectoires. Pour ce qui est du stockage des points d intérêts, une première version supprimait tous les points déjà trouvés et recréait les nouveaux à chaque exécution du script. Ceci ne convenait pas dans le cas où on voulait exécuter le script pour un mois en particulier, puis pour un autre pour voir les variations des Rapport de TER de Martin PUGNET 6

7 Figure 5 Visualisation des zones d intérêts et des points d intérêts points d intérêts dans une année. La nouvelle base est donc construite sur le principe que tous les anciens points d intérêt sont sauvegardés, tout comme toutes les anciennes trajectoires. Ainsi, lors d un stockage de points d intérêts, on stocke également les filtres utilisés lors de la recherche et la date du moment où ces points ont été générés. Ensuite, dans les scripts que j ai fait pour récupérer les trajectoires, je regarde uniquement les derniers points d intérêts, et avec, je créé les trajectoires. Pour pouvoir récupérer une des dernières trajectoires générées, ou simplement pour différencier les lots de trajectoires, il suffit de regarder à quel point d intérêt elle est associée pour avoir sa date de génération et les filtres sur les données utilisées. Ainsi, on pourra toujours récupérer d anciens points d intérêts, ou d anciennes trajectoires. Les photos peuvent être liées à plusieurs points d intérêts, puisqu on en garde un historique, j ai donc créé une table faisant le lien entre une photo et les différents points d intérêts associés. Là encore, on peut aussi trouver leur dernier point d intérêt, et les afficher en fonction. 4.2 Élaboration des trajectoires Avant de générer les trajectoires des utilisateurs, la première question que j ai eu à me poser était de savoir si cela allait être pertinent, selon le nombre d utilisateurs ayant plusieurs photos. En effet les trajectoires auraient été inutiles dans le cas où on aurait eu que quelques utilisateurs qui postaient plus d une photo. J ai donc du regarder la taille des trajectoires. Le premier élément indiquant la pertinence de nos trajectoires a été le nombre d utilisateurs distinct qui était de 3000 utilisateurs environs, sur photos, ce qui fait un très grand pourcentage d utilisateurs ayant pris plusieurs photos, et donc des possibilités d obtenir beaucoup de trajectoires. Pour vérifier cela, j ai fais une courbe de répartition des nombres de trajectoires selon leurs tailles (voir 6). On peut observer que presque toutes les trajectoires font une taille de moins de 5, il ne faut donc pas s attendre à avoir des trajectoires très grandes. Une fois toutes ces données stockées, un script python se charge de faire un historique de tous les points d intérêts par lesquels un utilisateur est passé. Comme on dispose de toutes les données nécessaires quand on génère les points, le traitement ce fait à ce moment là. Lors du parcours des points d intérêts, on regarde toutes les photos qui lui sont associés. Ensuite, on récupère les photos et on stocke dans une table, en base de données, l utilisateur ayant pris la photo, la date de prise et le point d intérêt associé. Ceci nous permet donc de constituer un historique des zones visitées par un utilisateur donné. Ensuite, un traitement est effectué sur ces données afin de détecter les trajectoires, sans avoir besoin de les lier à un utilisateur en particulier. Le traitement est le suivant : on récupère l historique de chaque utilisateur. Lors de son parcours, on vérifie la différence de temps entre deux prises de photos (la durée ne doit pas être supérieure à un jour). Lors de ce traitement, on doit aussi vérifier les points d intérêts afin de Rapport de TER de Martin PUGNET 7

8 Figure 6 Répartition des trajectoires selon leur taille supprimer les doublons et de ne pas avoir de trajectoires lorsqu un utilisateur à pris ses photos au même endroit. Une autre vérification est faite sur la longueur des trajectoires. Ainsi, on stocke uniquement les trajectoires ayant un certain nombre de points (dans les tests, j ai exécuté ce script en ajoutant toutes les trajectoires de deux points minimum). Ainsi, on se retrouve avec des listes de points ordonnés, étant tous différents et ayant tous un jour maximum d écart entre eux. Ces informations sont ensuite stockées dans une table de trajectoire. Chaque ligne de notre table de trajectoire a un numéro d étape, ce qui nous permet d ordonner les passages. Le couple (numéro trajectoire, numéro étape) est donc unique. Une fois cette base constituée, je me suis encore servi de l API de google maps afin de les visualiser. Pour cela je me suis servi d un objet polyline, qui permet de tracer des droites sur la carte. Une des visualisations que j ai effectué est la visualisation de toutes les trajectoires générées (voir 7). Cette visualisation était assez lisible dans le cas où le script était exécuté sur lignes. Dans le cas de lignes comme on avait à la fin, la carte est surchargée et on aperçoit difficilement les différentes trajectoires. J ai donc ajouté un moyen de sélectionner une trajectoire pour la changer de couleur et donc pouvoir l observer. Lors de cette visualisation, on pouvait déjà se rendre compte de plusieurs points de passages plus forts que d autres. Une autre visualisation que j ai pu faire est une visualisation de point à point (voir 8). J ai décomposé toutes les trajectoires en mouvement d un point à un autre, afin de voir la fréquence des déplacements. Chaque flèche de trajectoire était plus ou moins épaisse, ceci dépendant du nombre d occurrence de ce déplacement. Pour effectuer cela, j ai donc créé un tableau à deux dimensions, qui correspondrait à une matrice d adjacence dans le cas de graphes. Ainsi, on aurait chaque point d intérêt qui serrait un nœud d un graphe. La valeur de chaque case c[i][j] correspond au nombre d occurrences du chemin de taille 1 partant de i et allant jusqu à j. Pour constituer cette matrice, on décompose toutes nos trajectoires en chemins de taille 1. Une fois cette matrice effectuée, pour avoir une visualisation utilisable, il faut modifier les couleurs des flèches pour que la flèche allant de i vers j n ai pas la même couleur que celle allant de j vers i, il faut ensuite voir laquelle est la plus petite (afin de faire que la plus petite soit dessus l autre, pour pouvoir visualiser les deux flèches). Tous ces traitements sont faits en python, et sont ensuite transmis à une page qui affiche les lignes grâce à du javascript. Rapport de TER de Martin PUGNET 8

9 Figure 7 Trajectoires élaborées à partir de photos, avec une trajectoire de taille 3 sélectionnée Enfin, L utilisation prévue sur ces données par la suite serait d effectuer une fouille afin de pouvoir déterminer les trajectoires fréquentes. Pour faire cela, il faudrait regarder les combinaisons de points d intérêts fréquents, tout en vérifiant leur ordre. Figure 8 Deuxième visualisation avec les trajectoires par nombre d utilisateurs les ayant effectuées 5 Conclusion Par la suite, le programme de récupération des données de Flickr devrait donc être mis en place sur un serveur de l équipe DM2L, et devrait donc alimenter leur base de donnée cassandra quotidiennement des nouvelles photos postées. Les données déjà récupérées sur lesquels j ai fait mes tests vont également être importées sur leur base. La construction des trajectoires sera ensuite utilisée pour faire de la recherche de motifs, afin de détecter des tendances, et d autres analyses seront effectuées sur une combinaison de ces données avec celles d autres réseaux sociaux afin de faire des démonstrations des algorithmes mis au point par l équipe. D un point de vue apport personnel, je dirais que ce projet m a permis d apprendre le python et l utilisation d une base de données NoSQL, et aussi que ce projet m a permis de voir un peu plus le fonctionnement d une équipe de recherche et de voir un peu plus les problématiques de la fouille de données. Rapport de TER de Martin PUGNET 9

10 Références [1] Y. Cheng, Mean shift, mode seeking, and clustering, Pattern Analysis and Machine Intelligence, IEEE Transactions on, vol. 17, no. 8, pp , [2] Z. Yin, L. Cao, J. Han, J. Luo, and T. S. Huang, Diversified trajectory pattern ranking in geo-tagged social media., in SDM, pp , SIAM, Rapport de TER de Martin PUGNET 10