Turb(l)o(g)
Opendata avec les pieds
| Tweet |  |
Crédit photo : Mista.Boos
Depuis que je me suis mis à raildar.fr, j’écume pas mal de sources en matière d’opendata (en plus des autres). Et plus ça va plus je suis énervé.
Je vais donc commencer par établir une banalité sans nom qui devrait être à la base de toute réflexion opendata :
Ne cherche pas à savoir, connaitre ou comprendre ce que vont faire les gens avec tes informations pour tenter de les mettre en forme, contente toi de publier tout ce dont tu disposes de la façon la plus fine et rangée possible.
Mes recherches du moment concernent les réseaux de transport. Nous avons (heureusement) quelques normes, par exemple GTFS qui permet de décrire un réseau de transport, ses arrêts, ses lignes, les dessertes, etc. De ce coté là, tout est à peu près carré, si on oublie l’encodage et la casse des infos (par exemple, à la SNCF, les TER et Intercités sont correctement écrits dans 99% des cas. Les transiliens, par contre, toutes les gares ou presque sont en majuscule, c’est du plus bel effet.)
L’intérêt de tout ça est clairement orienté outils de recherche d’itinéraire et/ou de gares. Tu veux de l’info live sur les retards ou annulations ? Passe ton chemin.
Et puis, il y a les autres. De petits réseaux (comme CTS à Strasbourg ou Tisséo à Toulouse) qui font de l’opendata (c’est tout à leur honneur), et qui en plus fournissent de l’info live sur les problèmes (on se croirait en plein rêve)… sauf que… sauf que.
Ils ont commencé par se demander ce que les gens allaient faire avec. Et qu’ont-ils pensé ? Que les gens allaient vouloir connaitre les prochains transports dispo à un arrêt donné, ils ont donc tous les deux fait des méthodes pour leur API qui permettent de savoir qu’il va y avoir 2 tram ces 10 prochaines minutes à tel arrêt. Des identifiants par véhicule ? Non. Leur position actuelle, même approximative ? Non. Un lien entre les véhicules annoncés à l’arrêt et les lignes de transport déclarées ? Aucun.
SUPER, MERCI, mais cette info là, on la trouve déjà sur votre site et sur la demi douzaine d’autres médias que vous mettez à disposition. On innove comment ? Ben on n’innove pas.
Maintenant, je vais vous faire le quart d’heure consulting opendata gratuit. Ouais, c’est 100% cadeau !
Chacun de vos véhicules de transport (métro, bus, tram, train, tgv, avion, tube à air comprimé, pigeon voyageur, …) a, chez vous, en interne :
- un identifiant
- un endroit et une heure de départ (éventuellement corrigée par une heure réelle de départ)
- des endroits et des heures de passages (éventuellement corrigées également)
- un endroit et une heure d’arrivée (de même)
- une position instantanée (possiblement approximative)
Vous pouvez ensuite rajouter tout un tas d’infos autour, à votre convenance, mais ça, là, c’est LA BASE à fournir, par exemple, en JSON :
{
id: « 5467347 »,
type: « tramway »,
from: { type: « gare », name: « L’arrêt en bas de chez moi », lat: 47.345, lng: 5.563, theo_at: 1389188929, real_at: 1389190452},
to: { type: « gare », name: « L’arrêt au bout de la rue », lat: 46.345, lng: 5.643, theo_at: 1389189120, real_at: 1389191200 },
via: [ { type: … },{type: …}],
current_pos: { lat: 47.990, lng: 5.590 }
}
Avec ça, n’importe qui d’à peu près normalement constitué peut déterminer dans combien de temps un moyen de transport sera à quel arrêt pour faire un joli tableau horaire à l’arrêt de bus en bas de chez lui. Mais il peut aussi (par exemple) faire une carte avec tous les véhicules représentés, faire des stats sur les endroits posant des problèmes de circulation dans la ville, savoir s’il ne peut pas courir au coin de la rue pour attraper le bus qui passe par là plutôt qu’ailleurs, développer une appli qui réagira automatiquement quand un utilisateur sera dans tel ou tel bus, etc.
Y’a des jours, franchement, je me demande si les gens font pas de l’opendata parce que le chef a dit que c’était hype et qu’il fallait le faire mais on s’assure quand même de faire le truc le plus inutile possible, histoire que ça serve pas vraiment.
Parce que espères que les entreprises ou les administrations publiques vont mettre gracieusement à disposition de l’humanité entières des informations formatées de telle façon qu’elle serait correctement exploitable et qui permettrait donc de prouver qu’elles ne sont pas fiables, ne rendent pas le service attendu ou demandé correctement, ou pire dans une société capitaliste telle que la nôtre, permettrait de créer de la valeur ajoutée et même de la vendre sans qu’il prélève leur dime au passage (surtout si en plus ces données permettent d’exploiter leurs faiblesses pour faire de l’argent, là, c’est la honte totale) ?
L’Open-Data est sans conteste une belle idée, mais… les barrières à franchir pour qu’elle se concrétise pleinement sont autant technique que mental et il va y avoir un énorme travail à fournir pour faire évoluer tout cela dans le bon sens.
Je vais me permettre de nuancer un peu.
L’opendata en France, c’est très récent à l’échelle des systèmes d’information. Les premiers c’était Rennes et c’était en 2010.
La SNCF c’était il y a à peine un an et demi.
Évidemment que pour nous ça semble très long, mais faut imaginer la gueule des projets informatique chez eux, la gestion de projet et les contraintes à cause des 10 boites de presta qui interviennent.
Critiquons pour qu’ils s’améliorent, mais ne sous-estimons pas la volonté sincère de faire de l’OpenData (bon… y’a des exceptions la RATP je doute bien plus que pour la SNCF).
Ensuite, ils publient essentiellement ce qu’ils ont. Si leurs données en interne sont pas terribles, ben elles ne le seront pas non plus en opendata.
C’est d’ailleurs un des arguments envers l’opendata : en se forçant à exposer publiquement ses données, ça permet d’améliorer — itérativement — la qualité des données internes.
Pour ce qui est du temps réel, ce n’est pas si simple que tu penses. Prenons le ferroviaire : la branche voyage s’intéresse à la « tranche » (en gros le wagon) où sera assis le passager. L’exploitation s’intéresse au « train » (en gros la locomotive qui fait bouger le tout). Entre les TGV qui se séparent, les changement locomotive diesel vers électrique, les rebroussement, etc. Il y a une relation N:M entre tranche et train. La notion même « identifier un véhicule » est compliquée ! Très concrètement, les données Infolignes sont issues de l’agrégation de 4 (quatre) sources de données différentes.
Ensuite tu râles parce que tu veux la position de ton train, parce que t’as une vision très carto issue de raildar et du coup des API style « prochain départ » n’ont pas d’intérêt.
Pourtant moi si sur mon téléphone je veux qu’il bippe 5 minutes avant le passage du bus pour aller travailler, je serais horrifié d’avoir une liste de véhicules. J’en aurais rien à foutre de savoir si je prends le bus 34567887654 ou le bus 465765678-NNDV. Et le traitement de passer des véhicules aux prochains passages serait trop pénible. Pourquoi devoir me taper les 1000 bus de la RATP dans un flux de 1Mo alors que je veux juste deux int.
En gros, tu commence par signaler à juste titre qu’il ne faut pas préjuger de l’utilisation, tout proposant une utilisation finalement assez précise. Et non, je ne pense pas que ce soit trivial de passer de la vision véhicule à la vision arrêt (même si évidemment, c’est plus simple dans un sens que dans l’autre…).
Mais le fond du problème, c’est que concrètement, les entreprises n’ouvrent que ce que leur système d’information permet d’ouvrir sans toucher à leur SI existant. Tout a toujours été conçu autour du panneau « prochains départs », aussi bien auprès de la SNCF que des transporteurs urbains. C’est donc une évidence que tout leur SI soit orienté d’une telle manière.
Et puis dernièrement, s’il te plait, quand tu fais du consulting, invite les gens à utiliser des formats standarts qui ont connu le feu, pas un format ad-hoc ;)
Le gros problème avec le cas particulier des bus est d’ordre juridique : très souvent on ne peut pas ouvrir les données : Soit parce qu’on ne saît pas à qui elles appartiennent (collectivité ou société privée qui rempli la délégation de service publique), soit parce qu’on est sûr qu’elles appartiennent à la société privée. Et elle n’est pas soumise à l’obligation d’ouverture.
J’avais essayé de faire une carte en pseudo-temps réel en estimant grossièrement la position de chaque tramway en me basant sur le temps d’attente, mais je n’ai jamais réussi à faire des calculs corrects : https://strasweb.fr/opendata/API_CTS/
@BaN : il suffit qu’il soit inscrit dans le marché ou la DSP : « les données seront ouverte en opendata », fin du problème :)
@Rudloff : tu as butté sur quoi ? la détermination de l’unicité des vehicules ? Si je regarde ton URL t’as l’air de l’avoir par contre t’as un réel soucis de positionnement avec tes bus qui volent au dessus des maisons ^^
Je ne partage pas totalement ton point de vue. Pour moi raildar est un outil très sympa et très visuel mais ça reste à mon sens plus un POC qu’un réel outil utilisable au quotidien pour savoir quand va passer ton train.
On pourra dire que je ne suis pas totalement objectif sachant que je travaille sur l’outil permettant de calculer la donnée pour un des deux « petits » réseaux cités dans l’article mais je ne suis pas certain que l’attente du client lambda soit de pouvoir visualiser où se trouve son bus, ce qui l’intéresse c’est plutôt quand il va arriver.
Pour ce qui est de la notion de véhicule physique, la encore sur du transport urbain ça n’est pas aussi simple que ça. Un bus peut très bien effectuer une course sur une ligne commerciale et la suivante sur une autre ligne. Lorsqu’on attend un bus, quel est l’intérêt de savoir ou se trouve le bus qui n’est pas encore sur sa ligne ?
Également en cas d’incident, le régulateur essayera d’assurer un départ de bus annoncé au client mais pas forcément avec le bus prévu.
Certaines données existent donc mais sans les explications qui vont bien, elles apporteraient plus d’incompréhensions qu’autre chose.
Le fait que le POC actuel n’ai que peu d’utilité au quotidien ne préjuge pas de ce qu’il sera capable de faire plus tard, note :))
Je dis juste que lorsqu’on fait de l’opendata, il convient de penser d’abord aux données qu’on a et qu’on peut publier avant de penser à ce que les gens feront avec.
Pour le cas précis des véhicule, je pensais pas nécessairement au véhicule lui même (encore que, c’est déjà un bon moyen d’identification et ça permettrait de sortir des stats marrantes) mais plutôt à son identifiant de circulation sur une ligne donnée. Y’a quand même pas que la SNCF qui colle des numéros à ses trains et à ses bus, si ? :)
Je ne te dis pas le contraire, juste qu’il faut bien commencer par quelque chose ;-) Et si ce quelque chose peut déjà couvrir 90% du besoin …
Pour identifier un bus en circulation on à son numéro de parc (le bus physique), son numéro de service (ce que doit faire le bus dans une journée) et éventuellement un autre id si le véhicule fait des courses sur plusieurs lignes au cours de son service.
Ce serait super chouette de les avoir dans l’API :)
Juste une petite précision, dans le cas de la SNCF le numéro de train n’est pas vraiment l’identifiant d’une circulation (c’est déjà pas vraiment l’identifiant d’un train…), en effet tu as une relation N N entre les numéros de train et les circulations.
Une circulation peut avoir plusieurs numéro de train à cause de la parité, et des bi-tranches.
Un numéro de train peut correspondre à plusieurs circulation à cause des bi-tranche, du fait que différent transporteurs peuvent avoir le même numéros de train pour des circulations différentes (Infoligne doit déjà filtrer sur les compagnie SNCF et Thalys donc c’est peu visible) et deux circulations de modes différents (au sens ferrés ou pas) peuvent avoir le mêmes numéro.
Et même sans tomber dans un des cas précédent un même numéro ne correspond pas forcément exactement à la même circulation tous les jours: desserte en plus ou en moins, horaire théorique légèrement différent.
La SNCF (TER et Voyage) te présente des numéros de train car c’est leurs moyen d’organiser et présenter leurs offre et donc ce qu’ils vendent.
Oui, en associant au codeTrain supplémentaire dispo dans les API on s’en sort à peu près. Reste que ça fait le job quand on prend la problématique sous l’angle de l’objet circulant plutôt que sous l’angle de l’endroit ou il s’arrête.
L’API est orientée clients : on leur donne un horaire de passage à un arrêt quel que soit le service qui va couvrir la course.
En pratique si il y a des manœuvres de régulation, ça n’est pas le service prévu qui assurera la course mais ça c’est transparent pour le client. Je comprends ton point de vue, mais il faut avouer que c’est pas non plus courant comme besoin :)
Zut, je croyais que les API étaient orientées développeurs et créateurs de solutions ^^
Normalement c’est fait pour récupérer des infos utiles aux gens, pas pour que les développeurs se fassent plaisir ;-)
ah mes balises sont parties du coup :-)
Avis externe: Je ne prends pas les bétaillères. Par contre, dans un futur qui j’espère sera poche, je serais assez content que l’ordinateur de bord de ma bécane me conseille de rerouter si un bus vient de se déclarer en panne sur mon itinéraire. Ou simplement prendre une route plus tôt que prévue parce qu’un bus va décharger au moment précis ou j’arriverais devant son arrêt. Il me l’affichera probablement sur l’afficheur rétinien de mon casque :) C’est certain, on n’a pas encore de matrice de circulation, mais ça ressemble assez aux prémices. Ça a le mérite d’exister et d’être donc susceptible de s’améliorer. Tout ça pour vous dire merci de vous occuper de ce sujet qui est tellement loin de mes centres d’intérêt aujourd’hui, mais le deviendra certainement demain :).
La CTS expérimente en ce moment une API JSON. Par contre, ça renvoie toujours que les passages à un arrêt et un temps donnés.
Je met mon petit grain de sel dans le débat. Pour le UK, et Londres en particulier, il existe un sites très pratique : https://traintimes.org.uk/ avec un espace d’URL très bien fait pour avoir les horaires et les infos.
Pour les bus : https://traintimes.org.uk/map/london-buses/#2
Pour les trains : https://traintimes.org.uk/map/#bhm
Pour les métros :
https://traintimes.org.uk/map/tube/
Leave your response!
Dossiers
Derniers articles
Licence
Les contenus de ce blog sont, hors citations et images, sous licence Creative Common BY
Identité Ğ1
Catégories
Archives
Tags
Les autres
Mon bordel à moi
Recherches
Commentaires
Articles les plus commentés