Blog de JonathanMM

Archive pour janvier 2012

Bonjour à tous,

je vais continuer ma petite série d’article sur mes projets en vous parlant d’OpenTimeDataBase. J’avais déjà fait un petit article pour son lancement, mais vu que ça fait, ba, euh, déjà plus de 6 mois, je vais donc faire un petit bilan, et en profiter pour mettre quelques notions techniques.

Tout d’abord, les relevés. C’est la source brut du site, celle qui permet de construire des choses par dessus. Dans la table, elle est stocké en dur : C’est-à-dire que si on met que le train est un RER D, dans la base, il est noté RER D, et non pas l’identifiant d’une ligne nommé RER D qui se trouverait dans une autre table. J’ai voulu avoir ce principe pour simplifier au maximum la prise de relevé, et ne pas la rendre dépendante d’autre chose. De plus, quand on fait un relevé, en réalité, on en fait deux. En effet, le système va enregistrer une note pour le départ, et une pour l’arrivé, en recopiant tous les autres champs. Cela permet pour les étourdis comme moi de ne rentrer que l’aller ou le retour, vu que l’autre a été oublié d’être relevé. J’ai également, suite à une idée qui m’a été donné sur twitter (décidément ), mis en place un bot qui permet de faire des relevés via twitter. Le système fonctionne via un système d’abréviation qu’il faut tout d’abord configurer en twittant, et qui permet de faire des relevés complets en moins de 50 caractères. Il permet de plus de modifier son relevé, chose que l’on ne peut pas faire via le site, puisque sur ce dernier, les relevés ne nécessitant pas d’authentification, il n’est pas possible de savoir si celui qui veut le modifier est vraiment l’auteur ou pas.

Pour l’instant, c’est ce que sait faire le site. Il y a également l’autre partie du site, son but initial, qui était de produire des tables horaires qui seraient exploitable. Bon, vu que la SNCF est sur le point de libérer ses données, ce dernier point est devenu un peu useless. Néanmoins, j’ai décidé de terminer son codage puisqu’il peut tout de même servir à tout d’abord structurer les données des relevés mais aussi mettre en avant si des unités (train, bus) sont systématiquement en retard. L’algorithme utilisé a été conçu selon des relevés personnels, sur 2 années de trains que j’ai pris chaque jour pour aller en cours, et dont j’avais fait un relevé à chaque fois sur le D-Collector, l’outil de statistique de l’association SaDur, association des usagers du RER D (dont j’en fait parti). Il m’a donc permis de faire des constatations : Un train peut partir en avance, c’est rare, mais ça existe, donc l’algorithme doit éliminer ces quelques points particuliers. Un train, ça peut être souvent en retard, plus qu’être à l’heure, donc se baser sur l’heure où il y a le plus de point n’est pas la bonne solution. J’ai donc adopté un compromis entre les deux : Pour un train, dans une gare, on commence par trier dans l’ordre décroissant les horaires qu’on a récupéré via les relevés et on leur affecte un poids qui vaut leur nombre d’occurrence + la somme des nombres d’occurrences des horaires supérieurs ou égales à elle-même, et à la fin, on ne conserve que la donnée ayant le plus fort poids. Par exemple, imaginons qu’un train est 1 fois en avance d’une minute, 3 fois à l’heure, 5 fois en retard d’une minute, 6 fois en retard de 2 minutes, 5 fois de 3 minutes, 2 fois de 4 min et 1 fois de 5, on aura comme poids : 5 ? 2, 4 ? 5, 3 ? 13, 2 ? 20, 1 ? 24, 0 ? 25, -1 ? 24. Il vaut ce qu’il vaut cet algorithme, mais sur les cas testé, j’ai toujours eu le bon résultat

Pour pouvoir faire ce travail, il faut néanmoins lié chaque relevé à une unité, ce qu’est invité la personne qui fait un relevé juste après l’avoir entrer (enfin, sera invité très prochainement ). La structure de cette partie de la BDD est assez simple, une table pour les pays et ville, une pour les réseaux, une pour les lignes (pour résoudre le problème des lignes de bus 100 de deux compagnies différentes), une pour les services, et une pour les unités donc. À notre que les services sont liés à une autre table, services_details, qui a pour but de décrire les règles d’un service, une règle étant sous la forme : période de validité, jours de la semaine concerné (+ fêtes + lendemain de fêtes), et si c’est une exception au service ou pas. Enfin, il y a une table qui lie les arrêts aux lignes, et une autre pour la desserte, calculé comme précédemment.

Pour terminer, un petit bilan de ce projet. Et il est plutôt négatif. Nous ne sommes que 2-3 utilisateurs différents à avoir mis des relevés, pour un total de 262 relevés inscrits. Le problème est que le projet est assez titanesque et ne correspond pas à un réel besoin des utilisateurs. Je pense donc faire un fork de mon propre projet pour créer un projet annexe, mais reposant néanmoins sur OpenTimeDataBate. Ce sera une sorte de « Mon OTDB » où on pourra déposer un relevé (qui sera publié sur OpenTimeDataBase) mais qui sera relié à l’horaire théorique de l’unité, ce qui permettra de connaître le retard de la dite unité. On pourra donc avoir des stats du retard des transports que l’on utilise
Si vous avez la moindre question ou suggestion, n’hésitez pas