Mettre à disposition le SAEIV sous un format standard

[kalon33]

Bonjour,

Actuellement la réutilisation des données du SAEIV est très complexe pour donner des indications avance/retard par rapport aux horaires théoriques, de par le fait que WMS/WFS est un format de SIG et pas de transport en commun. Ce qui diminue malheureusement grandement les possibilités de réutilisation, vu qu'il est compliqué de faire correspondre ces données avec les données théoriques des fichiers GTFS déjà mis en ligne.

Serait-il possible de mettre à disposition ces données SAEIV dans un format standard de type SIRI ou GTFS-RT (qui sont les normes dans ce domaine) ?

C'est dommage que vous passiez beaucoup de temps à mettre à disposition ces infos et qu'au final elles soient difficilement réutilisables...


Merci d'avance.

[Sébastien Cart-Lamy]

Bonjour,
SIRI n'est malheureusement pas un standard... mais une norme de fait. De plus, elle est variable selon l'éditeur de la solution qui l'utilise.

Quant à GTFS, ce n'est pas un standard au sens ISO ou autre organisme de normalisation international, mais seulement pour Google (qui n'est pas encore un organisme de normalisation reconnu).

Nous préférons opter pour des réels standards ouverts, sachant que dans le transport, une fois retiré SIRI et GTFS, il n'y a plus grand chose...

Pour ce qui est de diminuer les possibilité de réutilisation, ce n'est pas vrai : un outil GTFS ne pourra bien entendu pas lire nativement ces données, mais tous les autres outils conformes aux norme OGC, qui jusqu'à présent ne pouvaient pas lire les données transport, peuvent désormais le faire.

À noter que le GTFS théorique que nous mettons en ligne nous est transmis par Keolis, et nous le posons tel quel. Le SAEIV Bus, quand à lui, est issu en direct de nos systèmes, d'où la différence. Avec le SAEIV Bus, vous n'avez plus besoin des horaires théorique GTFS (sauf pour les prévisions supérieures j+1)

L'utilisation de ces normes n'interdit pas de faire les même choses qu'avec du GTFS / SIRI, elles proposent même bien plus d'information (comme les informations géographiques).

[kalon33]

Bonjour,

Je regrette, le GTFS, qui a effectivement été élaboré par Google au départ, est aujourd'hui utilisé par la vaste majorité des applications de calcul d'itinéraires : navitia (la solution de keolis d'ailleurs !), moovit, thetransitapp, OpenTripPlanner (un projet libre), transports bordeaux (appli conseillée par la TBC...)... et j'en oublie des centaines un peu partout dans le monde. Ce format d'API, parce qu'il ne s'interface pas facilement avec le GTFS, ne facilite pas la réutilisation.

Le ministère de l'écologie et du développement durable, lui même, fournit des outils qui fonctionnent avec SIRI et GTFS : http://www.chouette.mobi/ qu'ils considèrent comme des normes http://www.chouette.mobi/pourquoi-irys/.

Il n'y a qu'à regarder le nombre d'applications qui ont intégré le SAEIV depuis sa sortie en bêta et le nombre de participations dans ce forum... Ce n'est absolument pas trivial de ne considérer le GTFS que certaines fois (selon les jours), selon les réseaux, etc... Surtout que limiter une planification d'itinéraire uniquement à la journée en cours, a fortiori en multimodal, est pour moi absurde. Si aucun réseau ne fait comme les autres, le multimodal ne restera qu'un mythe, ou alors à portée des seules applications portées par des équipes de dizaines de développeurs... et pas du bénévole.

Encore une fois, les outils SIG (ou aux normes OGC) et les outils transports utilisent des formats différents aux finalités différentes.

Merci d'harmoniser vos pratiques avec les autres...

Bien cordialement.

[Sébastien Cart-Lamy]

Merci pour votre point de vue sur le sujet. Si vous pensez que SIRI est une solution urgente à court terme, vous pouvez développer une interface avec notre OpenData (le modèle et les WebServices le permettent). Nous nous ferons un plaisir d'ajouter votre application sur la page dédiée à cet effet sur la plateforme - même si actuellement les exemples d'autres OpenData diffusant sous cette norme sont rares. À noter que les schémas XSD de SIRI datent de 2013, et la norme devrait devenir européenne en 2015 : http://www.normes-donnees-tc.org/category/siri/.

Concernant les horaires du jour, le sujet est pertinent, et la solution proposée n'est pas le fruit du hasard. La bêta (ouverte depuis seulement 6 jours), est une période d'échange permettant de discuter sur des sujet comme celui-ci. J'ai créé topic dédié aux prévisions d'horaires : http://data.lacub.fr/forum/viewtopic.php?f=8&t=128

[kalon33]

Justement,

Comme cela va devenir la norme, autant prendre de l'avance et proposer ce format... Pour ma part, je n'ai pas les compétences techniques pour développer une telle appli, d'où mon agacement.

En fait, le coeur du problème pour moi, c'est que j'ai besoin de faire un lien GTFS -> API temps réel, comme tout logiciel de calcul d'itinéraire (et pas de fiche horaire temps réel), pour lequel ce mapping est INDISPENSABLE. Et pour cela, j'ai besoin que les identifiants des voyages (trips_id, en lien avec le calendrier horaire), des arrêts (stops_id), et des lignes (routes_id) soient communs entre les deux. Je pense que c'est possible, puisque le SAEIV a de toute manière besoin de comparer avec les horaires théoriques pour signaler une avance ou un retard de x secondes. Mais il faudrait que ces identifiants soient identiques, au pire qu'une table de comparaison soit disponible et publique.


Merci de voir si quelque chose est possible de ce côté.

[Sébastien Cart-Lamy]

Je vous rejoint sur le fait que les id GTFS et SAEIV ne sont pas les mêmes, ce qui est problématique. La difficulté est la suivante :

GTFS vient du logiciel de modélisation du réseau de Keolis (HASTUS).
Le SAEIV vient du logiciel industriel de gestion du temps réel. Celui-ci consomme les données issues d'Hastus (suite à des imports), mais du coup utilise une numérotation complètement différente.

Nous n'avons la main sur aucun des deux logiciels.

Il faut voir comment on peut faire un rapprochement entre les deux. Je crée un topic dédié à cela : http://data.bordeaux-metropole.fr/forum/viewtopic.php?f=8&t=129