4 opérateurs de covoiturage (Ecolutis, Roulez malin, Covivo, Covoiturage.com) se sont réunis pour concevoir et expérimenter un protocole d’échanges de données du covoiturage.
Baptisé RDEX (Ridesharing Data EXchange), ce standard a pour vocation de faciliter les échanges de données de covoiturage afin de mutualiser les centaines de services existants en France et en Europe.
Complètement ouvert, ce standard a été conçu pour permettre une interactivité sans dépendance à la mode des réseaux P2P. Il ne s’agit pas de rejoindre un groupe de partage de données, mais de construire des accords bilatéraux entre plate-formes.
Ainsi une entreprise régionale pourrait signer un accord exclusif avec le conseil général de son territoire, tandis que le conseil général en question pourrait souhaiter collaborer avec les départements limitrophes par ailleurs.
100% décentralisé, ce protocole ne s’appuie sur aucune infrastructure commune. Il s’agit d’un modèle d’échange de données et non d’une délégation Entièrement sécurisé, ce protocole n’échange aucune donnée personnelle sans l’accord de l’utilisateur.
Prêt pour l’open data, il a été conçu avec la nécessité d’ouvrir les données.
Si elles le souhaitent, les collectivités pourront ainsi très facilement ouvrir leurs données covoiturage.
Roulez Malin, Ecolutis, Covoiturage.com et Covivo ont participé à la rédaction des spécifications et sont en mesure d’intégrer ce protocole.
Vous pouvez télécharger les spécifications du protocole RDEX : Specification_RDEX1_0
La masse critique est un des enjeux des services de covoiturage. Tout ce qui peut permettre d’augmenter le nombre d’annonces disponibles sur un territoire est une bonne nouvelle pour le succès du covoiturage. Nous sommes 4 à nous être mis d’accord, car il fallait bien commencer.
Toutefois notre démarche est collaborative et nous serions ravis d’être rejoint par tous les acteurs volontaires, petits, grands, locaux ou internationaux, afin de faire progresser ce standard.
Olivier Demaegdt – Ecolutis
Le covoiturage étant un service public géré par des opérateurs privés, il était nécessaire que la saine concurrence n’entrave pas l’efficacité du service.
Olivier Branellec – Roulez Malin.
Ce protocole permettant la mutualisation des bases de données est une opportunité pour le développement du covoiturage.
Dans le cadre de notre plateforme européenne de covoiturage, nous souhaiterions utliser le format RDEX.
Malheureusement, après lecture de la documentation, nous voyons déjà quelques incompatibilités avec l’intégration de la spécification RDEX :
1. [Départ, Arrivée] Code INSEE obligatoire :
Ce code ne semble disponible que pour des villes françaises.
Aussi un trajet Bruxelles-Amsterdam ne peut respecter la spécification.
Ne faudrait-il pas lever cette contrainte afin d’élargir la spécification vers une dimension européenne ?
2. [Autres informations] Distance du trajet obligatoire et durée du trajet obligatoire :
Il est difficile de déterminer la distance et/ou la durée du trajet.
Quelques services en ligne permettent de le faire gratuitement, mais leurs limites sont vite atteintes.
Aussi, il est possible de souscrire à des services payants, mais cela restreint immédiatement la liste des sites ayant accès à ces technologies et ainsi la liste des trajets disponibles pour l’utilisateur final.
Ne faudrait-il pas lever ces contraintes afin de rendre la spécification accessible au plus grand nombre de sites ?
3. [Trajet ponctuel] Date de trajet :
Lors de très grands trajets, dans le but d’atteindre le plus de coivoitureurs possible, nous permettons au coivoitureur de définir une date de départ/retour sur plusieurs jours.
Est-il possible d’ajouter un(des) champ(s) permettant d’étaler le départ/retour d’un trajet ponctuel sur plusiquers jours ?
Merci pour vos réponses.
Voici plusieurs remarques pleines de bon sens.
Pour le code insee, bien entendu, il faut que nous supprimions le caractère obligatoire.
Pour les dates, vous proposez des annonces sur plusieurs jours ou juste la recherche ?
Pour la durée et la distance, je pense qu’il suffit aussi de rendre cela non obligatoire.
Ci-dessous, mes explications sur les dates des trajets ponctuels.
Lors de la saisie de trajets à caractère exceptionnel, nous permettons aux covoitureurs d’étaler leur départ sur plusieurs jours.
Par exemple, quelqu’un peut définir un trajet de Paris vers Berlin, en tant que passager, en précisant qu’il souhaite partir entre le samedi 9h et le dimanche 16h.
Malheureusement, cet interval de date ne peut pas être modéliser avec la spécification actuelle.
Merci
Et comment sont défini vos champs dans ce cas ?
De notre coté, nous avons une date et une tolérance.
Basiquement : nous avons une date début, une heure début, une date fin et une heure fin.
Merci
Propositon d’authentification et de structuration des web services
Ci-joint une proposition pour l’authentification et de structuration des web-services pour l’envoi du message voir aussi pour l’échange d’offre et demande.
Ca semble complet et carré. Cela nous permettra d’aller plus loin si nécessaire.
Merci de vos commentaires.
StructureAnnonce.pdf
Modification structuration des données suite à remarques
Ci-dessous la structuration des données Offres et de Demandes de covoiturage prenant en compte les remarques ci-dessus.
apiRDEXv0.1.pdf
N’hésitez pas à faire vos commentaires sur cette structuration.
Elle sera intégrée à la v1.1 dès que la structuration des données « Message » aura été déterminée.
Ajouter des champs « étapes possibles » ?
Bonjour a tous et bravo pour l’initiative!
Il me semblerai utile de rajouter a la specification les étapes possibles lors d’un trajet, associées aux couts eventuels depuis chaque ville étape définie! Ca augmenterait certe la complexité du systeme en créant un tableau des couts, a deux entrées, mais les sites qui implémentent ce genre de fonctionnalités semblent apporter un meilleur matching entre passagers et conducteurs.
Dans le meme ordre d’idées, l’ajout d’un champ « détour maximal », en kms, avec eventuellement un champs « surcoût au km » permettrait a un site implémentant un systeme géographique d’offrir le même genre de fonctionnalités.
Aussi, dans le format du message, un champ « position actuelle » et « départ immediat? » permettrait d’implémenter l’alerte des conducteurs en temps réel, et de concurencer ainsi l’auto stop!
Merci de votre attention,
Olivier B.
Plutot que de focaliser sur un format (XML) il aurait été interessant de définir un modèle de données non lié à un format : par exemple un vocabulaire RDF international du co-voiturage.
Cela permet ensuite :
– d’avoir une API qui peut accepter différentes sérialisation (XML, mais aussi JSON ou Turtle)
– de ne pas réinventer la roue au niveau des references (code insee + autres pays , cf commentaires ci-dessus), en permettant aux partenaires de se référer directemen à une référence existante, comme des URI DBPedia ou Geonames
– d’ouvrir encore plus la porte à la réutilisation de ces données, puisqu’à partir d’un vocabulaire RDF public, elles peuvent être réutilisées par tout autre système, qu’il connaisse « RDEX » ou pas…
A votre disposition si vous souhaitez discuter de tout cela…