Intégration externe - Transports en commun (GTFS)

Développement
1

cover-gtfs
cover-gtfs800×534 25.6 KB

Salut tout le monde !

Après Tisséo pour Toulouse, plusieurs personnes ont des réseaux qui n’ont pas leur intégration dédiée. Plutôt que d’en faire une par ville, voici Transports en commun (GTFS) : les prochains passages à vos arrêts et les perturbations pour n’importe quel réseau publié sur transport.data.gouv.fr. TER et TGV SNCF, Naolib, STAR, TaM, M, Ilévia, Stan… environ 490 réseaux, dont 220 avec du temps réel. Tout vient de l’open data : sans compte et sans clé.

Ce que ça fait

  • Le réseau se choisit depuis Gladys : recherche dans le catalogue national, ou adresse d’un fichier GTFS pour un réseau qui n’y serait pas. Jusqu’à 3 réseaux.
  • Un appareil par arrêt (20 au plus) : pour chaque ligne et direction, les minutes avant le prochain passage et le suivant, les trois prochains passages en texte, et l’info trafic. Le temps réel est utilisé quand le réseau le publie ; un horaire théorique est marqué « ≈ ».
  • Un widget « Prochains passages », un déclencheur « Perturbation sur une ligne suivie » et une action qui prépare une phrase prête à envoyer.

Le truc sympa

À 7 h 45 en semaine → la phrase des prochains passages à mon arrêt sur Telegram
Perturbation sur ma ligne TER → message sur le téléphone avant de partir
Bus à moins de 4 minutes → la lampe de l’entrée clignote

Installation

Gladys 5.1 minimum.

Elle arrive dans le store au prochain passage de l’indexeur. En attendant : Intégrations → Installer depuis GitHub, avec l’adresse GitHub - guim31/gladys-gtfs: Next departures and disruptions for any French public transport network (GTFS / GTFS-RT from transport.data.gouv.fr) in Gladys Assistant · GitHub

  1. Dans Configuration : cherchez votre réseau, ajoutez-le, puis cherchez et ajoutez vos arrêts (par nom ou autour de la maison).
  2. Créez les appareils depuis l’onglet Découverte, puis ajoutez le widget.

Pour Toulouse, Lyon, l’Île-de-France et Bordeaux, les intégrations dédiées (Tisséo, TCL, IDFM, TBM) restent plus complètes : la doc les cite. L’Île-de-France est d’ailleurs trop grosse pour celle-ci.

Petites réserves honnêtes : le temps réel dépend de ce que publie chaque réseau, et il peut peser lourd (jusqu’à environ 100 Mo par heure et par réseau avec un rafraîchissement par minute ; la nuit, une lecture toutes les 15 minutes). Elle a été testée sur les vraies données (SNCF en gare de Nantes, Naolib, Aix-Marseille) dans les conditions du bac à sable de Gladys, avec un pic à 138 Mo de mémoire, mais pas encore dans une vraie instance.

Codée avec l’aide de Claude Code, à partir du code de mon intégration Tisséo. Projet indépendant, non affilié à transport.data.gouv.fr ni aux réseaux.

Dépôt : GitHub - guim31/gladys-gtfs: Next departures and disruptions for any French public transport network (GTFS / GTFS-RT from transport.data.gouv.fr) in Gladys Assistant · GitHub

Dites-moi sur quel réseau vous l’essayez :slight_smile:

2

Hey @guim31 petit coquin :joy:

Et si on faisait ça à l’échelle mondiale ? :

belastungstest_toulouse
belastungstest_toulouse1167×716 32.9 KB

Mon test de charge d’aujourd’hui… et comme j’ai pris Toulouse à cœur ces derniers jours, je suis allé tester à : 64 Boulevard Pierre Semard Toulouse, mieux connu sous le nom de Matabiau.

Et voici le même résultat pour la gare centrale de Heidelberg:

belastungstest_heidelberg
belastungstest_heidelberg1199×724 37.7 KB

Tout y est, les bus urbains (BUS), les lignes de bus interrégionales (COACH), les tramways urbains (TRAM), les trains interrégionaux (FERN), les trains de banlieue (S-BAHN).

Les ferries (FÄHRE) sont également affichés, voici l’exemple de l’Elbphilharmonie à Hambourg:

belastungstest_hamburg
belastungstest_hamburg1021×712 34 KB

et après que quelqu’un m’ait fait remarquer qu’il pourrait y avoir des téléphériques ou quelque chose de similaire:

Voici la ville de Heidelberg avec un funiculaire/téléphérique (FUNICULAR):

belastungstest_seilbahn
belastungstest_seilbahn1033×717 37.3 KB

et que diriez-vous de nos amis nord-américains, voici Québec au Canada:

belastungstest_quebec
belastungstest_quebec1025×720 33.2 KB

1.) Seule une connexion Internet est nécessaire

2.) Aucun téléchargement

3.) Mise à jour contrôlable

4.) Rayon contrôlable

5.) Lieu déterminé par géolocalisation, prévu : indication de la ville

Si tout se passe bien, alors j’aurai terminé les tests aujourd’hui et ensuite, en tant que débutant absolu sur GitHub, je vais me plonger brièvement dans la création d’une intégration externe ou je confierai simplement le projet à quelqu’un qui maîtrise le sujet…

Salutations

Tom

3

Je découvre que les données temps réelles du réseau Ginko de Besançon sont sur cette plate-forme opendata. Je vais tester ton intégration, et si ça marche ça va le faire encore un bricolage node-red que je pourrai supprimer !

4

Alors en fait l’intégration trouve bien le.reseau Ginko bisontin, mais ce sont uniquement les horaires théoriques, au format GTFS.
Les horaires temps réel sont mentionnés sur le site transport.data.gouv.fr, mais dans un format SIRI. Le détail explique que ça passe par une API nécessitant une clé.

Sur le site, il y a ça :

IMG_8439
IMG_84391170×2532 271 KB

Et le détail de l’inteeface SIRI est là : Jeu de données ouvert SIRI - API SIRI pour Réseau urbain Ginko - CU Grand Besançon Métropole

Je dispose d’une telle clé, c’est comme ça que je fait fonctionner mon bricolage node-red.
Tu crois, @guim31, que tu pourrais compléter ton intégration avec ce format ?

5

@StephaneB bien vu, et oui c’est faisable. J’ai regardé : Ginko n’est pas seul dans ce cas, une petite vingtaine de réseaux publient leur temps réel uniquement en SIRI sur transport.data.gouv.fr (Strasbourg, les Pays de la Loire, Idelis, TUB…). Je m’y mets : un champ facultatif pour la clé du réseau, et l’intégration ira chercher les passages en SIRI quand il n’y a pas de GTFS-RT. Tes arrêts restent les mêmes, rien à recréer. Je te fais signe dès que c’est prêt, et ton bricolage Node-RED sera le test parfait ^^

@ruegerth joli test de charge :smiley: Tu passes par quelle source pour avoir l’Allemagne, Hambourg et Québec sans rien télécharger ? Si c’est une API mondiale ouverte, ça m’intéresse, que ce soit pour compléter celle-ci ou pour ton intégration à toi.

6

@StephaneB c’est en ligne : la 1.1.0 lit le temps réel SIRI et SIRI Lite des réseaux qui n’ont pas de GTFS-RT, dont Ginko.

Pour l’activer : dans la configuration de l’intégration, champ « Clés d’API SIRI », ajoute une ligne Ginko = ta-clé. La clé ne sort jamais dans les journaux. Tes arrêts restent les mêmes : les passages suivis s’affichent sans le « ≈ » quand ils sont en temps réel, et les perturbations Ginko alimentent l’info trafic et le déclencheur.

J’ai pu tester depuis chez moi contre les vrais serveurs : celui de Ginko répond bien, mais sans aucun arrêt quand on n’a pas de clé, donc c’est toi qui vas faire le premier vrai essai ^^ Si l’intégration te signale un arrêt inconnu ou une clé refusée, dis-le-moi.

Au passage, ça marche aussi pour une quinzaine d’autres réseaux dans le même cas : les Pays de la Loire (Aléop et les réseaux urbains de l’agrégat), Saint-Brieuc (TUB), plusieurs réseaux de Nouvelle-Aquitaine (Tanlib, Calibus, R’Bus, TuT…), Strasbourg avec une clé CTS… Petite réserve : la plateforme Okina, derrière beaucoup de ces réseaux, n’accepte qu’une requête toutes les 30 secondes environ. Mieux vaut donc y suivre un ou deux arrêts, pas dix.

7

@Guim31 : Regarde ici :joy:

Cordialement

8

Pour tous :

Besançon me donne :

besancon
besancon783×491 61.3 KB

Remarque : je travaille déjà sur un object Object. Les paramètres utilisés sont les suivants :

47.242222°, 6.021389°

Cordialement

Tom