//
hop, un article
Points de vue, Projets

Réutiliser des données du réseau Star

Bonjour !

Vous vous trouvez sur l’ancien blog du collectif Open Data Rennes. Ses archives restent en ligne, mais nous nous trouvons à présent sur www.cod-rennes.fr.

A très bientôt !

Le Service des transports en commun de l’agglomération rennaise, que je vais appeler le réseau Star, a commencé à ouvrir ses données vers le 1er Mars 2010. En tant que membre du collectif et usager quotidien du métro et des bus de Rennes, ces données m’intéressent. En tant que développeur (web, mais pas que), c’est plutôt le transport de ces données qui m’intéresse.

Et c’est ce dont je suis venu vous parler aujourd’hui : comment ces données se retrouvent dans nos téléphones, dans les applications de développeurs indépendants, voire le plus souvent complètement bénévoles (oui, je pense à l’excellente application Android de Yan Bonnel (et le compte twitter associé @TransportRennes)). Plus exactement, je vais vous parler de ma propre expérience, cela devrait vous donner un aperçu du travail que cela représente, et des difficultés rencontrées.

Si vous n’êtes pas développeur, j’essaie dans la suite de l’article de rester dans la vulgarisation, j’espère donc rester assez accessible. Mon but est de transmettre mes impressions sur mon expérience avec les données, en ajoutant le temps que cela m’a pris. N’hésitez pas à poser des questions en commentaire !

Où sont les données ?

Première question à se poser : où sont les données ? Non, la réponse n’est pas si simple que ça, parce que les données ne sont pas à un seul et même endroit. Le bon point, c’est que les données sont référencées à la même adresse : sur le site officiel data.keolis-rennes.fr. Mais il y a les données à télécharger, et les données de l’API.

Télécharger n’est pas encore réutiliser

Celles à télécharger sont dans un format normalisé par Google : le format GTFS. C’est une bonne et une mauvaise nouvelle. La bonne, c’est que c’est un format ouvert et relativement bien documenté, donc après quelques heures de lecture de la documentation, un développeur peut comprendre comment interpréter les fichiers. Si vous savez vous servir d’un tableur, vous pouvez ouvrir ces fichiers aussi (avec le mode CSV), et vous en sortir avec quelques bons filtres.

La mauvaise nouvelle, c’est que ce format est vu du point de vue du transporteur. C’est à dire que si vous cherchez à adopter le point de vue d’un usager, vous n’allez pas arriver bien loin. Ce qui est un peu dommage, parce que le but de ces données, quand même, c’est d’être finalement présentées par le développeur aux usagers. Orienter la structure des données vers la vision des usagers, c’est faciliter le travail des développeurs (sauf si vous voulez développer un système pour le transporteur).

Bon, pour comprendre, rien ne vaut un exemple : un usager voudra savoir si une ligne de bus peut l’emmener de l’arrêt de bus A à l’arrêt de bus B. Il regarde la fiche d’une ligne, et voit que c’est possible, parce que la fiche lui donne toute la liste des arrêts, dans l’ordre.

Le format GTFS n’a pas de concept de « fiche de voyage type ». Il propose l’ensemble des voyages complets (chacun part à telle heure, termine à telle heure, et passe par A, B, C, D, E, etc. dans un ordre précis). Mais il ne permet pas facilement de savoir quels sont les arrêts de bus d’une ligne.

C’est tout à fait logique du point de vue du transporteur, mais c’est un vrai casse-tête pour le développeur qui veut présenter l’information aux voyageurs.

En bonus point, nonobstant une qualité générale plutôt bonne, il y a des incohérences dans les données fournis dans ces fichiers par Keolis.

Deux trajets peuvent indiquer la même direction dans le même sens (c’est à dire qu’ils viennent par le même côté de la ligne, et dans le même ordre), mais ils ne partent pas toujours du même endroit. Pourtant, si vous lisez la seule donnée disponible à ce sujet, vous allez faire comme moi : vous tromper et obtenir une fausse analyse des données.

Un autre soucis que j’ai remarqué : pour un usager, globalement, un bus a trois types de journées de circulation. Les journées de la semaine (lundi au vendredi), le Samedi, et enfin le Dimanche et jour férié. Il y a un fichier pour ça dans le format GTFS, mais il est très mal exploité par Kéolis. Il n’y a pas de service type pour 5 jours, un pour le samedi, un pour le dimanche et jours fériés, et d’autres pour les cas spécifiques. À la place, il y a plusieurs fois le même service par jour de circulation. Cela créé des « faux » doublons dans la base, et si vous recherchez la performance, il faut, là encore, faire un travail long et coûteux supplémentaire.

Heureusement, vous pouvez quand même déterminer quels sont les trajets types en poussant vos analyses avec de gros traitements un petit peu plus lourd (à programmer et à exécuter). Autant vous dire que ce n’est pas pour nous rendre la tâche facile.

La faute à qui ? Un peu à GTFS, mais l’utilisation par Kéolis n’est vraiment pas optimale (même si je veux bien croire qu’il y a un effort fourni, j’ai pu en discuter rapidement avec l’ingénieur qui travaille sur le sujet pour Kéolis).

API mon amour

Une autre partie des données est disponible via une API. Ce qui est bien, car cela permet d’obtenir des données en temps réel : prochain passage, disponibilité des vélos, etc. Le soucis, de mon point de vue (d’usager et de développeur), c’est que cette API n’est ni complète ni bien documentée.

Attention, je ne critique pas ici ni l’intention ni l’ouverture des données via une API. C’est une bonne idée et je remercie Rennes, Star et Kéolis de proposer cette API. Mais en tant que développeur, je suis souvent frustré par ce que j’ai à ma disposition.

J’ai d’ailleurs écrit un petit article sur un sujet bien précis au sujet des API : « Pour qui sont les API ? ». Cet article fait suite à la rencontre qui s’est tenue à la Cantine Numérique Rennaise en décembre dernier. Lors de cette rencontre, j’ai présenté mon travail à quelques autres développeurs sur les données.

Travailler avec les données.

Une fois les données en main (façon de parler), j’ai beaucoup travaillé à les rendre réutilisables (pour moi entre autres). Tout d’abord j’ai commencé par l’API, en proposant un client python (pour développeur). Sur la douzaines d’heures que cela représente, je me suis confronté à plusieurs problèmes :

  • L’API est mal documentée. Certes il y a toutes les méthodes appelables, mais la présentation des paramètres, leur usage, etc. est très peu voire parfois pas du tout expliqué. J’ai dû passer plusieurs heures à comprendre comment faire certains appels, pourtant relativement simples une fois le tout posé à plat. Pour l’exemple, ma documentation du client pour Le Velo Star, et la documentation de la méthode principale côté API Kéolis.
  • Détail supplémentaire, la langue de la documentation est un mélange entre l’anglais et le français, ce que je trouve pour le moins surprenant, et ne me donne pas confiance en ce que je lis.
  • L’API ne retourne pas d’erreur lorsqu’il ne peut pas y avoir de contenu. Ce n’est pas normal : si je demande la ligne de bus 7814, je demande une ligne qui n’existe pas, mais l’API ne m’informe pas de mon erreur. Cela peut paraître anecdotique, mais cela induit, encore une fois, un manque de confiance dans les résultats obtenus.
  • En fonction du format de sortie demandé (JSON ou XML), les données ne sont pas toujours identiques. J’ai eu l’occasion de remonter une erreur sur l’API temps réel pour le bus (et elle a été corrigée). C’est inquiétant, parce qu’une API en laquelle on ne peut pas avoir confiance nuit à la qualité générale. S’il y a une erreur sur un cas, rien ne dit qu’il n’y en a pas pour d’autres.
  • Quelques soucis de latences, d’autres soucis avec les formats, les paramètres, la clé de l’application qui passe en clair dans l’url, etc. mais ça devient vraiment très technique.

Mais mon plus gros problème a été le suivant : L’API ne dispose pas de toutes les données. Il faut coupler les appels avec une analyse et un traitement des données à télécharger. Autant dire qu’il est impossible de se reposer naïvement sur une seule source de données.

Objectifs et réalisations

À l’origine je souhaitais simplement tester l’API, comprendre son fonctionnement, et pourquoi pas, proposer un client en python complet, pour que d’autres développeurs puissent, sereinement, reposer toute leur application sur ce client. Lorsque je me suis rendu compte que toutes les données n’étaient pas dans l’API, et qu’une bonne partie devaient être récupérer dans le flux GTFS, je me suis posé quelques questions.

Et j’ai foncé tête baissée dans un WE (environ 16h sur deux jours) de développement de scripts, d’analyses, de traitements et de formatages des données. J’ai ensuite continué quelques jours de plus (environ 20h de plus) à développer un concept d’API REST autour des données complètes (pour information, c’était mi-Décembre 2012).

En un peu moins d’une semaine de travail (aux 35h et des poussières), j’ai obtenu une API qui présente les données statiques du réseau de bus de Rennes, avec ses arrêts de bus, ses lignes, ses trajets et ses heures de passage, le tout avec des données liées les unes aux autres, une structure plus à plat et plus facile à comprendre.

Bref, quelque part, j’ai refait le travail de Kéolis avec ses propres données. Et je ne sais pas quoi en faire.

La motivation après le premier effort

Au début j’étais très motivé. Le sujet me passionne toujours autant aujourd’hui, mais après une semaine de développement, je ne suis plus trop sûr de vouloir continuer.

Parce que si mon objectif de base est à peu près atteint (un client python fonctionnel, bien que largement améliorable), je sens bien qu’il y a beaucoup plus que ça à faire. Et une partie de mon travail d’analyse et de réflexion, je ne suis pas complètement certain que c’est à moi de le faire.

Je m’explique.

Je pense qu’il faut un juste milieu. D’un côté il y a une API et des données à télécharger. De l’autre il y a des développeurs. Je veux bien travailler pour créer des outils pratiques pour les développeurs : client python, php, java, ou que sais-je encore. Je veux bien travailler pour rendre la vie plus facile aux développeurs, avec des outils d’analyses des requêtes, un vérificateur, etc.

Mais je ne veux pas refaire le travail de Kéolis, c’est à dire, refaire une API complète. Peut-être que je vais y venir quand même. Peut-être que d’autres développeurs vont trouver l’idée intéressante finalement, et je les invite à me contacter. Peut-être que, dans tout ça, il y a quelque chose « en plus » à faire, que je n’ai pas vu, pas compris, pas utilisé.

Le premier effort était super, et mes résultats sont très satisfaisants. Aujourd’hui, ma motivation fait défaut face à ce que je considère comme un service à moitié rendu – et je me demande si cela ne soulève pas non plus la question de cette notion de « service rendu » – et des attentes que cela provoque !

J’ai beaucoup d’autres choses à dire sur ces données, notamment sur ce que l’on peut faire avec, ce dont je n’ai pas parlé ici. Mais pour le moment, j’en suis là, avec mes interrogations d’usager et de développeur. Avec mon temps libre vaguement réduit et mes différents projets.

Le mieux peut-être maintenant, c’est de faire comme je le disais le 19 décembre dernier en introduction : discutons !

Edit : Petite annexe sur le « coût » de développement.

Publicités

Discussion

12 réflexions sur “Réutiliser des données du réseau Star

  1. (on écrit « Keolis Rennes », et pas « Kéolis »)

    On peut aussi argumenter que ce n’est pas le métier du transporteur de fournir une API, et il y a une certaine difficulté à fournir des données cohérentes quand celles-ci sont issues de différents SI qui n’ont rien à voir avec GTFS ou un autre format standard (et encore, je préfére GTFS à du XML). Il suffit de voir les discussions sur les libellés des voyages, différents entre SIV, GTFS et d’autres.
    Mais on s’en sort pas si mal par rapport à d’autres villes.

    GTFS est relativement simple et pour cela, effectivement, ils ont adopté le fait qu’une ligne de transport va dans un sens ou l’autre, point, donc effectivement, les exceptions, les prolongations, les branchements alternatifs, sont difficiles à trouver et présenter. En même temps, multiplier les noms de lignes pour différencier les trajets n’est pas pour autant aisé (et d’ailleurs, cela tend à disparaitre sur le réseau de Rennes. On a perdu les 10a/10b, reste juste les 11/67 et compagnie pour les soirs et dimanches, et dans les flux, celles-ci sont liées aux lignes « principales »).

    Pour les jours de circulation, cela parait simple pour l’usager (et les fichers papiers), mais au final pas tant que ça semble-t-il, mais cela est sans doute lié aux sources des données. À noter que lors des périodes de vacances, on retombe bien, en général, sur des calendriers Semaine/Samedi/Dimanche (encore que, le calendrier des données de Noël était… particulier). Et certains utilisateurs des données (TransportRennes le fait, il me semble, je le fais pour ma part en tout cas) ont ajouté une passe d’analyse des trajets pour regrouper (dans la mesure du possible) les trajets en calendriers « classiques ».

    Un argument sorti (pour le temps réel du moins) sur le fait que l’API renvoie du vide si les paramètres sont non-cohérents (id de ligne/stop invalide) était le côté performance. (on en fait ce qu’on veut, hein).

    La clé en clair dans l’URL… et bien, malheureusement, il n’y a pas 36000 solutions pour ce genre de choses. On ne va pas non plus se mettre à faire du chiffrement asymétrique pour consulter des données ouvertes. (Note: le même principe est utilisé par d’autres fournisseurs de services web: Google, etc… même si souvent, ceux-ci permettent de lier cela à un domaine, ce qui est ok pour le monde du web, moins pour les mobiles).

    Pour ce qui est de l’API qui ne dispose pas de toutes les données, je suis entièrement d’accord, j’en ai encore fait la remarque la semaine dernière. Et oui, la manière qu’a Keolis Rennes de mettre en place celles-ci est parfois déroutante. On est dans une démarche ouverte, mais ce qui est ouvert est surtout ce que eux utilisent déjà, avec une abstraction plus ou moins forte de leurs sites, donc sans forcément répondre aux besoins des développeurs externes, d’où souvent les échanges qui se finissent en « pourquoi ça ressemble à ça ? Parce que c’est ce qui est sur le site web ».
    Mais en même temps, cela ne leur rapporte rien (directement), donc on peut difficilement trop tirer sur la corde.

    Je ne sais pas si tu vas avoir beaucoup d’echos de développeurs, de nos jours. Pour l’intégration des données GTFS, pour ce qui est de nourrir le syndrome NIH, il y a eu (autant que je sache) au moins 3 projets Java (dont au moins 2 encore actif), 1 Python (mort?), 1 Ruby (actif) en OpenSource, plus quelques morceaux à gauche à droite. Il n’y plus grand signe de vie sur les forums et plus de concours pour motiver les gens (il suffit de compter les applications à jour).
    (accessoirement, l’API Keolis est « facile » à utiliser. Jouer avec les horaires d’ouverture de Vivre à Rennes est quand même beaucoup plus amusant).

    Publié par seb | 22 janvier 2013, 10:46
    • > On peut aussi argumenter que ce n’est pas le métier du transporteur de fournir une API

      Euh… oui ? C’est pour ça qu’il est passé par un prestataire, dont c’est le métier. Si mon avis personnel est plutôt en faveur d’une capitalisation en interne sur ce genre de développement, je comprends tout à fait l’aspect pragmatique d’externaliser ce travail à quelqu’un de plus spécialisé, et donc, de censément plus compétent.

      Et comme c’est Rennes qui paye Keolis Rennes pour ce genre de service – qui peut bien payer le presta de son choix – et donc, nos impôts, oui, je suis plutôt regardant sur la qualité. Qualité qui peut être demandé par contrat, etc.

      Donc cet argument (déjà entendu trop souvent) ne me semble pas vraiment pertinent.

      > Mais on s’en sort pas si mal par rapport à d’autres villes.

      Oui et ? Mon propos n’est pas dans la comparaison avec d’autres villes. J’estime que l’expérience d’une ville peut servir à d’autres, et si une ville peut faire mieux que Rennes grâce à ça, tant mieux !

      > GTFS est relativement simple et pour cela, effectivement, ils ont adopté le fait qu’une ligne de transport va dans un sens ou l’autre, point

      Deux choses là dedans, parce que je pense qu’on peut compléter.

      1/ GTFS est simple dans son format (ce ne sont que des fichiers CSV finalement), mais suppose tout un schéma de données bien particuliers. Il n’est pas non plus très compliqué, mais il impose quand même une structure à suivre.

      Son avantage est qu’il permet une grande liberté, et bien qu’il soit clairement orienté transporteur, il peut tout à fait permettre une approche « voyageur », en théorie.

      2/ Avec la notion de « route » (la ligne de bus, comme la 1, 2, 3, etc.) Le format GTFS ne dispose pas du concept de « direction », mais seulement de « trajet », avec deux informations : un sens (0 ou 1, pour le concept d’aller-retour), et un nom de trajet (utilisée pour les données du Star comme étant la « direction »).

      Mon soucis ici est qu’en cherchant à présenter une information à destination des usagers du réseau de transport, cela gène le travail des développeurs.

      Exemple : au lieu d’utiliser « L | Destination » (destination « usager »), mettre « L | Destination (Départ) » aurait été suffisant.

      Au passage, ajouter « L | » est complètement superflus, puisqu’un trajet est toujours lié à une ligne de bus.
      C’est un problème très différent des séparations de lignes en 10a, 10b, etc.

      > Un argument sorti (pour le temps réel du moins) sur le fait que l’API renvoie du vide si les paramètres sont non-cohérents (id de ligne/stop invalide) était le côté performance. (on en fait ce qu’on veut, hein).

      Je sais, et je ne suis pas d’accord avec cet argument. Cela explique pourquoi, mais ne justifie ni n’excuse pas. Où est le problème de performance ? On peut faire beaucoup de choses, et vérifier dans une table qui fait moins de 200 lignes si une liste d’élément existe, ce n’est pas vraiment « contre-performant ».

      Mauvais choix techniques ? Mauvaise système ?

      Je n’en sais rien, mais ça ne m’empêche pas de trouver cela anormal.

      > La clé en clair dans l’URL… et bien, malheureusement, il n’y a pas 36000 solutions pour ce genre de choses.

      La plus simple serait de ne pas en avoir. Et je ne vois pas de justification qui tiennent la route très longtemps pour conserver cette clé.

      La sécurité ? Qu’est-ce que ça change si quelqu’un fait un DDoS avec une clé ou avec 50 différentes ? Ce qui compte c’est l’IP de l’utilisateur. La clé ne protège de rien.

      La performance ? Vous l’évoquiez justement juste avant. La clé doit être :

      * transmise par l’appelant
      * récupérée par l’API
      * lu et vérifié par l’API
      * les erreurs doivent être traitées, etc.

      Un simple « provider_url » ou quelque chose du genre aurait été, à mon avis, amplement suffisant pour les statistiques. Cela aurait permis, entre autre chose, de spécifier une version de l’application, etc.

      Mieux encore : utiliser des headers HTTP qui sont là pour ça ! Par exemple, le User-Agent et consort.

      > Mais en même temps, cela ne leur rapporte rien (directement), donc on peut difficilement trop tirer sur la corde.

      Ce n’est pas la question. J’espère pouvoir dépasser cette question de « C’est en open-data, alors pas de plainte ». Ou de « les gens en veulent toujours plus ».

      La démarche est ouverte oui. Les échanges fréquents avec les CM de @starbusmetro montre un réel intérêt pour les usagers, pour ce que font les rennais de leurs transports en commun – et entre autre, des données ouvertes.

      Je ne « demande » rien. Je pose des questions. Encore une fois, je ne vais pas mesurer la qualité de quelque chose à la médiocrité du reste. Ou me complaire dans une quelconque comparaison.

      > Il y a eu (autant que je sache) au moins 3 projets Java (dont au moins 2 encore actif), 1 Python (mort?), 1 Ruby (actif) en OpenSource

      Pour Rennes peut-être. La dernière fois que j’ai cherché GTFS et Django, je suis tombé sur plusieurs projets qui avaient l’air encore en forme. 🙂

      > (accessoirement, l’API Keolis est « facile » à utiliser. Jouer avec les horaires d’ouverture de Vivre à Rennes est quand même beaucoup plus amusant).

      Et bien, si vous avez un retour là dessus, n’hésitez pas à nous écrire / à le publier. 🙂

      Publié par Exirel | 22 janvier 2013, 9:55
      • > Euh… oui ? C’est pour ça qu’il est passé par un prestataire, dont c’est le métier.

        Sauf que le prestataire, on lui a donné des briques (des APIs et des données existantes), qu’on lui a dit d’en faire quelque chose de vaguement consommable par le monde extérieur, mais ça ne veut pas dire pour autant que le budget (dans tous les sens du terme) pour ce prestataire était suffisant pour remettre à plat de multiples SI de différentes sociétés (il faudrait un témoignage des gens concernés, mais de ce que j’ai cru entendre, tout le bazar OpenData, c’est pas juste un export ou une surcouche d’une seule source).

        (après, si toutes les boîtes qui ne faisaient pas de qualité coulaient, il ne resterait plus grand monde sur la place)

        > Et comme c’est Rennes qui paye Keolis Rennes pour ce genre de service – qui peut bien payer le presta de son choix – et donc, nos impôts, oui, je suis plutôt regardant sur la qualité. Qualité qui peut être demandé par contrat, etc.

        À voir ce que contient le contrat actuel en question. Et la priorité de tels services vis à vis du reste.
        (déjà qu’on n’a pas des pneus neige sur les bus, alors une API Rest, hein…).

        > [GTFS] et bien qu’il soit clairement orienté transporteur,

        Oui, euh, il est surtout orienté Google, hein. C’est pas un consortium de transporteurs et d’offices publics qui s’est réuni pour pondre ça (non, eux ils ont pondu Neptune…). Donc pragmatique (et bon, parfois un peu trop lié à un modèle de base).

        > Avec la notion de « route »[…] Le format GTFS ne dispose pas du concept de « direction », mais seulement de « trajet », avec deux informations : un sens […] et un nom de trajet …

        C’est du chipotage sur le terme ? Le « sens » se nomme « direction_id » tout de même.

        (à noter d’ailleurs que ce champ direction_id fut longtemps sans valeur dans les données GTFS et que sa valeur finale est minime, en dehors des terminus, mais c’est une autre histoire).

        Après, oui, headsign et direction sont liés. Ce qui peut sembler logique.

        > Mon soucis ici est qu’en cherchant à présenter une information à destination des usagers du réseau de transport, cela gène le travail des développeurs.

        Non, le problème, c’est qu’ils ont extrait une donnée brute et ne l’ont pas filtrée suffisamment. Cf la discussion sur les données temps réel et l’écart de ces libellés avec ce qui se trouve dans les données GTFS « pas les mêmes sources ».

        Après, on pourrait aussi rediscuter des noms (longs) des lignes, qui sont… longs. Trop, souvent.

        > Exemple : au lieu d’utiliser « L | Destination » (destination « usager »), mettre « L | Destination (Départ) » aurait été suffisant.

        Euh, là, je vois pas l’intérêt ? En plus concret, ça donne quoi ?
        Parce que les headsign de GTFS doivent +/- correspondre aux girouettes des bus. Mais on va pas raconter leur vie, que ce soit dans ces dernières que dans les données.

        Certains développeurs, d’ailleurs, en ont déjà trop fait par le passé: Vas-y que je prend le premier/dernier arrêt du trip pour donner l’info utilisateur. Saut que parfois, ce genre de choses est trop précis pour l’utilisateur lambda (surtout quand les données sont traitres et incluent des éléments pas forcément commerciaux).

        > C’est un problème très différent des séparations de lignes en 10a, 10b, etc.

        Oui et non, parce que c’est une demande récurrente. Actuellement, une même ligne peut avoir des trajets différents dans la même direction (au sens GTFS). Comment présenter la liste des arrêts proprement à l’utilisateur ? En séparant par trajet ? En regroupant tous les arrêts de la ligne ? Dans ce cas, dans quel ordre ? (parce que sur un trip x, on peut avoir les arrêts A-B-C, mais en y, avoir A-C, etc…). Mais on ne va pas non plus présenter 2 lignes différentes pour 4 trajets par semaine ?

        > [ les résultats vides ] Je sais, et je ne suis pas d’accord avec cet argument.

        Je ne le suis pas non plus, ça tombe bien.

        > La plus simple serait de ne pas en avoir. Et je ne vois pas de justification qui tiennent la route très longtemps pour conserver cette clé.

        Une raison ? Faire des stats (voire limiter des abus), tout simplement. Et cela peut très bien n’avoir aucun ou peu d’impact sur les performances (hors vérification même).
        Et puis bon, faut aussi regarder la manière dont cela s’est passé et les différentes licences qu’on a pu voir s’appliquant aux données.

        > Mieux encore : utiliser des headers HTTP qui sont là pour ça ! Par exemple, le User-Agent et consort.

        Ah non, pitié! On voit ce que ça donne dans la vraie vie: un bordel.

        Sans compter qu’en usage web… 20000 UA différents pour la même appli web (qui pourrait générer de la charge/des erreurs, whatever…).

        Mettre en HTTP-basic ? Bof…
        Le Referer ? Oui et non.

        > Ce n’est pas la question. J’espère pouvoir dépasser cette question de « C’est en open-data, alors pas de plainte ». Ou de « les gens en veulent toujours plus ».

        Il n’est pas question de ne pas pouvoir se plaindre, mais de se modérer, de remonter les demandes et de voir les choses évoluer (et c’est moi qui dit ça…).

        > Pour Rennes peut-être. La dernière fois que j’ai cherché GTFS et Django[…]

        Oui, c’est ce que je dis, NIH.
        (mon excuse à moi est que j’avais un squelette d’appli avant que quoi que ce soit ne soit ouvert ici).

        Publié par seb | 22 janvier 2013, 11:22
      • > (il faudrait un témoignage des gens concernés, mais de ce que j’ai cru entendre, tout le bazar OpenData, c’est pas juste un export ou une surcouche d’une seule source).

        Il y a une partie côté Keolis Rennes – qui est nécessaire pour fournir une partie du GTFS au passage, donc ce n’est pas perdu – et le reste est à base d’analyse de fichiers uploadés par Keolis Rennes sur le serveur de l’API.

        > (déjà qu’on n’a pas des pneus neige sur les bus, alors une API Rest, hein…).

        Relisez un peu mon article, vous verrez que faire cette API Rest ne m’a pas pris tant de temps que ça (à l’échelle d’un projet qui peut durer sur 3, 6, 12mois). Et je suis seul, donc pas aidé par d’autres personnes.

        Peut-être qu’une option, justement, c’est d’aider Keolis Rennes à prendre en main le code source, à l’installer sur leurs machines, et à diffuser l’API avec leurs ressources ? Après tout, si tout passe en open-source (faut juste que je nettoie deux trois trucs), rien ne les en empêche.

        Ce qui revient à répondre à votre « se modérer, de remonter les demandes et de voir les choses évoluer ».
        Ayant travailler sur les données, je me permets d’en dire ce que j’en pense, me sentant concerné.

        > C’est du chipotage sur le terme ? Le « sens » se nomme « direction_id » tout de même.

        Bien que synonyme, ce sont deux choses un peu différente. C’est l’intérêt d’avoir deux mots différents.

        > Non, le problème, c’est qu’ils ont extrait une donnée brute et ne l’ont pas filtrée suffisamment.

        Elle n’est pas brute ! Elle a déjà été travaillée pour en arriver à ce formatage. J’en ai discuté avec eux déjà.

        > Parce que les headsign de GTFS doivent +/- correspondre aux girouettes des bus.

        Vous pensez trop « affichage », et pas assez « analyse » des données. Vous avez fait (comme d’autres) un superbe travail d’analyse des données, en cherchant à déterminer quels étaient les « trajets types », ie. qui ont la même direction, le même sens, les mêmes arrêts et dans le même ordre.

        Mais au lieu d’analyser une flopé de trajet, un simple « GROUP BY » en SQL devrait être suffisant pour récupérer, pour une ligne donnée, tous les trajets types. Les cas spéciaux (un arrêt sauté à une heure précise, etc.) ne seraient alors plus que des exceptions, et seraient donc beaucoup plus triviaux à interpréter.

        Le soucis avec une analyse des données telle que vous la faites, c’est qu’elle est source d’erreurs et de faux-positifs/négatifs.

        Enfin, c’est bien ce que je reproche à l’usage du format : orienté vers l’usager, pas le développeur. L’usager, pourtant, n’ira jamais utiliser le fichier GTFS pour utiliser le bus. C’est mon propos.

        >> [GTFS] et bien qu’il soit clairement orienté transporteur,
        > Oui, euh, il est surtout orienté Google, hein

        Il est orienté transporteur, dans le sens, avec la vision d’un transporteur : il gère des lignes avec des trajets, chacun unique, identifié, avec des horaires précises, etc.
        C’est ce que j’entends par « orienté transporteur ».

        >> Sans compter qu’en usage web… 20000 UA différents pour la même appli web (qui pourrait générer de la charge/des erreurs, whatever…).

        Heh, vous réfléchissez en tant que navigateur, ce qui n’est pas le contexte d’une API comme celle-là : ce n’est pas un navigateur qui va appeler l’API, c’est un client bien particulier, avec un script bien particulier (voire de serveur à serveur, etc.). Et ce n’était qu’un exemple comme un autre. Rien n’empêche d’utiliser aujourd’hui une clé différente par application, voire vous pouvez récupérer 5 ou 6 clés différentes, et les utiliser les unes après les autres avec le même script. L’API ne bronchera pas un seul instant.

        Ensuite, je n’ai parlé que de statistique comme usage intéressant, qui peut donc être obtenu par bien d’autres choses qu’une « clé » plus ou moins unique pour une application.

        Cette clé est inutile. 🙂

        > Mettre en HTTP-basic ? Bof…
        > Le Referer ? Oui et non.

        On parle d’une API HTTP là. Alors utiliser HTTP, je ne vois pas en quoi c’est un mal.
        Parce que si à la place cela revient à utiliser la query string du GET (ou du POST, pour ce que ça change…), je ne vois pas bien la différence.

        Bref. Je vais m’arrêter là, j’ai fait à peu près le tour de la question – et nous devenons AMHA trop technique pour ce blog. 🙂

        Publié par Exirel | 23 janvier 2013, 12:13
      • > > […]tout le bazar OpenData, c’est pas juste un export ou une surcouche d’une seule source).
        > Il y a une partie côté Keolis Rennes – qui est nécessaire pour fournir une partie du GTFS au passage, donc ce n’est pas perdu – et le reste est à base d’analyse de fichiers uploadés par Keolis Rennes sur le serveur de l’API.

        Ce que je veux dire, pour les données GTFS, c’est que (je peux me tromper là-dessus, mais c’est ce que j’avais cru lire entre les lignes), les données sont générées par Keolis Rennes mais sont issues de différentes sources, parce que Keolis Rennes a aussi ses propres prestataires transports qui géreraient eux-mêmes leurs plannings, d’où, par le passé, des erreurs subtiles qui ne touchaient qu’un segment des données. Et c’est sans compter d’autres organismes (Rennes Métropole et toutes les villes constituantes par exemple, pour le mobilier).

        > Peut-être qu’une option, justement, c’est d’aider Keolis Rennes à prendre en main le code source

        Mais le veulent-ils seulement ?
        Ils ont une plateforme existante, des évolutions potentielles à venir, ça ne veut pas dire pour autant qu’ils voudraient y mettre le budget pour repartir de (+/-) zéro (tout en maintenant l’existant, parce que legacy).

        > [GTFS] Enfin, c’est bien ce que je reproche à l’usage du format : orienté vers l’usager, pas le développeur.

        Est-ce qu’il existe un format plus adapté ? Utilisable et non-chimèrique ? Neptune (urgh) ?

        Mais attention, à un moment donné, il faut savoir faire des concessions (techniques ou non) pour pouvoir mettre quelque chose dehors, même si parfois le cahier des charges peut sembler, aux yeux du puriste, obsolète ou idiot (aka, puis-je utiliser une API Rest avec un client flash 9, etc…).

        > Ayant travailler sur les données, je me permets d’en dire ce que j’en pense, me sentant concerné.

        On te voit pas assez sur le forum, dans ce cas 🙂

        > Heh, vous réfléchissez en tant que navigateur, ce qui n’est pas le contexte d’une API comme celle-là

        Elle est mal fichue pour cela (j’attends toujours mon callback), mais on peut très bien l’utiliser en API json classique dans un navigateur.

        Publié par seb | 24 janvier 2013, 6:03
      • > Mais le veulent-ils seulement ?

        Aucune idée, discussion ouverte, etc. 🙂

        > > [GTFS] Enfin, c’est bien ce que je reproche à l’usage du format : orienté vers l’usager, pas le développeur.
        > Est-ce qu’il existe un format plus adapté ? Utilisable et non-chimèrique ? Neptune (urgh) ?

        Si vous me relisez, je ne parle pas du format mais de son *usage*. Et je trouve que l’usage qui en est fait n’est pas le plus pratique.

        > On te voit pas assez sur le forum, dans ce cas 🙂

        Forum qui m’a semblé relativement amorphe, et pas du tout pratique pour la discussion.
        Je souhaite en tout cas intéresser d’autres personnes que celles uniquement sur ledit forum.

        > mais on peut très bien l’utiliser en API json classique dans un navigateur.

        Je n’en vois pas spécialement l’intérêt pour autre chose que de la consultation anecdotique pour du test ou autre. Le cross-domain ne fonctionnant pas avec les requêtes ajax, il faut bien avoir un client de l’API côté serveur.

        Donc on sort encore une fois, du navigateur.

        Publié par Exirel | 24 janvier 2013, 8:01
      • > Si vous me relisez, je ne parle pas du format mais de son *usage*. Et je trouve que l’usage qui en est fait n’est pas le plus pratique.

        Hormis la gestion du calendrier, je ne pense pas que l’usage fait par Keolis Rennes du format GTFS sorte de l’ordinaire, donc je serais curieux de savoir de quelle manière (en pratique) ils pourraient améliorer cela.
        Mais en restant dans le cadre du format, j’ai un peu de mal à voir quel retournement de situation serait possible.

        > Forum qui m’a semblé relativement amorphe, et pas du tout pratique pour la discussion.

        Moins pratique qu’un blog? Certainement plus lisible en tout cas! Après, il n’est pas exempt de reproches (entre recherche et historique…) mais il a l’avantage de centraliser l’information et que les gens concernés y répondent, ce qui est quand même un point essentiel.

        > Le cross-domain ne fonctionnant pas avec les requêtes ajax, il faut bien avoir un client de l’API côté serveur.

        Il fonctionne. Mais pas dans tous les navigateurs.
        (D’où me remarque sur le callback, qui était une demande que j’avais faite, il y a bien longtemps, mais qui a priori n’a jamais été implémentée.)

        Après, l’intérêt est de faire travailler le client, économiser des ressources et faciliter l’accès. Il suffit d’une page web sur un serveur « bête » pour pouvoir faire quelque chose de ces données. C’est le but, non ?

        Publié par seb | 24 janvier 2013, 9:23
  2. Est-ce qu’on peut avoir la liste des bus à venir à un arrêt donné et à l’heure courante avec ton API ? Par exemple, savoir à Beaulieu Chimie quand est-ce que va passer le prochain bus de la ligne 4 à 21h00.

    Publié par David | 22 janvier 2013, 9:00
    • Avec ce que j’ai fait, oui. Globalement, les données ne sont pas très compliquées : il n’y a que des lignes, des arrêts, des trajets, et des horaires de passages liant un peu le tout.

      (et j’interprète le « à 21h00 » comme étant « après 21h00 » ou « à partir de 21h00 ». 🙂

      Publié par Exirel | 22 janvier 2013, 9:09
      • Cool ! Mais comment on télécharge le code ? Je n’ai vu aucun lien sur les sources sur la page https://star-api.readthedocs.org/fr/latest/

        Publié par david | 23 janvier 2013, 10:06
      • Tiens marrant, j’ai oublié de mettre le lien sur la doc. Ma faute, toutes mes excuses, je donne généralement le lien vers le repo bitbucket en général : https://bitbucket.org/exirel/star_api

        Cependant, ce client là n’est pas pour *mon* API, mais pour l’API actuelle, officielle, et maintenue par Keolis Rennes donc celle-ci : http://data.keolis-rennes.com/

        Et pour le coup, vous ne pourrez pas demander le prochain passage à une heure arbitraire, mais seulement « les prochains passages », avec l’API temps réel.

        Pour *mon* API, je ne l’ai pas encore diffusée, vu que j’ai encore du boulot dessus, et que je ne suis pas sûr d’avoir le temps de le faire tout de suite. Notamment parce que cela demande beaucoup de boulots sur les fichiers GTFS, d’analyses, de compréhensions, et de mise en forme des données.

        Publié par Exirel | 23 janvier 2013, 11:13

Rétroliens/Pings

  1. Pingback: Question subsidaire sur la réutilisation des données Star « Open Data Rennes - 22 janvier 2013

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :