Données statiques et temps réel du réseau Astuce Métropole Rouen Normandie MRN

—

Posté le 20 novembre 2025

Discussion close par

Déborah Tourmente le 3 décembre 2025

Mise à jour de l’URL dans agency.txt

Ticks Atoumod

—

Posté le 31 octobre 2025

Discussion close par

Déborah Tourmente le 3 décembre 2025

Chevauchements de trajets avec block_id identique – Offre GTFS

Ticks Atoumod

—

Posté le 14 octobre 2025

Bonjour, Lors de la vérification des données GTFS du réseau Astuce, nous avons identifié un chevauchement horaire entre deux trajets partageant le même block_id, ce qui pose un problème de cohérence dans l’enchaînement des services par un même véhicule. Voici quelques exemples : trip_id = TAE:4511:4009089 → de 20:30 à 21:13 trip_id = TAE:4456:4009089 → de 21:00 à 21:42 TAE:118 REGEN_2967 TAE:4511:4009089 CHAMP DE FOIRE 1 404 0 0 TAE:AUTO_5884869 TAE:118 REGEN_3765 TAE:4456:4009089 THEATRE DES ARTS 0 404 0 0 TAE:AUTO_5884868 Le second trajet démarre à 21:00, soit avant la fin du premier prévue à 21:13. Ce chevauchement rend impossible l’affectation de ces deux trajets à un même véhicule. D’autres trajets sont également concernés par ce type de problème. Veuillez trouver ci-dessous la liste complète des paires de trajets concernés : TNI:11:4014817 → TNI:23:4014817 TNI:11:4014817 → TNI:33:4014817 TNI:3:4014817 → TNI:15:4014817 TNI:3:4014817 → TNI:25:4014817 TNI:5:4014817 → TNI:17:4014817 TNI:5:4014817 → TNI:27:4014817 TNI:7:4014817 → TNI:19:4014817 TNI:7:4014817 → TNI:29:4014817 TNI:9:4014817 → TNI:21:4014817 TNI:9:4014817 → TNI:31:4014817 TNI:15:4014817 → TNI:25:4014817 TNI:15:4014817 → TNI:51:4014817 TNI:15:4014817 → TNI:67:4014817 TNI:17:4014817 → TNI:27:4014817 TNI:17:4014817 → TNI:53:4014817 TNI:17:4014817 → TNI:69:4014817 TNI:19:4014817 → TNI:29:4014817 TNI:19:4014817 → TNI:55:4014817 TNI:19:4014817 → TNI:75:4014817 TNI:21:4014817 → TNI:31:4014817 TNI:21:4014817 → TNI:57:4014817 TNI:21:4014817 → TNI:71:4014817 TNI:23:4014817 → TNI:33:4014817 TNI:23:4014817 → TNI:59:4014817 TNI:23:4014817 → TNI:73:4014817 TNI:51:4014817 → TNI:67:4014817 TNI:51:4014817 → TNI:97:4014817 TNI:53:4014817 → TNI:69:4014817 TNI:53:4014817 → TNI:101:4014817 TNI:55:4014817 → TNI:75:4014817 TNI:55:4014817 → TNI:99:4014817 TNI:57:4014817 → TNI:71:4014817 TNI:59:4014817 → TNI:73:4014817 TNI:67:4014817 → TNI:97:4014817 TNI:67:4014817 → TNI:111:4014817 TNI:69:4014817 → TNI:101:4014817 TNI:69:4014817 → TNI:113:4014817 TNI:71:4014817 → TNI:117:4014817 TNI:73:4014817 → TNI:119:4014817 TNI:75:4014817 → TNI:99:4014817 TNI:75:4014817 → TNI:115:4014817 TNI:75:4014817 → TNI:125:4014817 TNI:101:4014817 → TNI:113:4014817 TNI:101:4014817 → TNI:123:4014817 TNI:97:4014817 → TNI:111:4014817 TNI:97:4014817 → TNI:121:4014817 TNI:99:4014817 → TNI:115:4014817 TNI:99:4014817 → TNI:125:4014817 TNI:111:4014817 → TNI:121:4014817 Pourriez-vous, s’il vous plaît, corriger cette erreur afin de permettre une validation conforme du fichier GTFS ? Bien cordialement,

—

Posté le 21 octobre 2025

Bonjour, Et merci pour cette remontée. Nous vous confirmons que ce point a bien été identifié de notre côté et est actuellement en cours de correction. Avec nos excuses pour la gêne occasionnée, Déborah Tourmente-Ben Achrak pour la Métropole Rouen Normandie

—

Posté le 3 décembre 2025

Bonjour, Nous vous confirmons que la problématique a été corrigée côté TAE ; nous vous laisserons revenir vers nous si toutefois vous rencontriez toujours des soucis. Nous reviendrons vers vous dès que les corrections auront été réalisées également côté TNI. Bien cordialement, Déborah Tourmente-Ben Achrak pour la Métropole Rouen Normandie

Transdev Rouen > Anomalies rencontrées sur le nouveau temps réel

—

Posté le 10 septembre 2025

Bonjour, Je me permets de vous remonter les différentes anomalies constatées avec les nouveaux flux temps réel (celles-ci ne concernent que les lignes exploitées par Transdev Rouen). 1. Véhicule qui "change" de ligne sporadiquement Cause (probable) de l'occurrence : un véhicule sur une ligne A effectue un arrêt à l'arrêt 1 au même moment théorique qu'un véhicule sur une ligne B. Conséquence : le véhicule (= identifié par .vehicle.id) "vole" la course d'un autre véhicule et se retrouve sur une toute autre course/ligne qu'un autre véhicule, avant de reprendre sa course initiale quelques minutes plus tard. Arrive assez régulièrement en heure de pointe sur le tronc commun TEOR par exemple où un même véhicule peut basculer entre T1, T2 et T3 de façon aléatoire durant son passage sur le tronc commun. 2. Aucune activité post-minuit À partir de minuit, les données ne sont plus mises à jour : le tout se fige jusqu'à disparaitre. Les courses "nocturnes" du T1 ainsi que le Noctambus ne sont alors jamais monitorées. À noter que cela semble être dû aux courses > 24:00:00 puisque les premiers services TEOR vers 04h apparaissent bien là où les fins de Noctambus sont quant à elles invisibles. Sur https://gtfs.bus-tracker.fr/astuce-gtfsrt/ vous pourrez retrouver des captures prises toutes les 5 minutes du GTFS-RT actuel ainsi que de l'ancien (à la fois en JSON et Protobuf) à des fins d'analyse. Ces captures sont datées de la nuit du 9 -> 10 septembre 2025. Tant que l'ancien flux temps réel est disponible, ces anomalies sont +/- corrigibles. Néanmoins, celui-ci sera probablement coupé à un moment donné ce qui affectera la fiabilité des données. Merci par avance Bonne journée, Kevin.

—

Posté le 11 septembre 2025

Bonjour, Nous confirmons les anomalies déjà signalées ci-dessus. Nous constatons le désalignement des identifiants d’arrêts entre statique et temps réel. Exemple : arrêt Fauquet → GTFS statique stops.stop_id = 10961, alors que le flux temps réel (TU) envoie stopId = FAUQU0. Conséquence : les stop_time_update.stop_id du GTFS-RT ne correspondent pas le GTFS statique, ce qui bloque l’affichage des ETA malgré des positions véhicules correctes. Pourriez-vous harmoniser les identifiants d'arrêts, faire en sorte que stop_time_update.stop_id du GTFS-RT corresponde exactement à stops.stop_id du GTFS statique (et non au stop_code, sauf si le statique les aligne aussi)? Merci d'avance et n'hésitez pas à nous répondre pour toute question. Cordialement, Derek Lee Transit

—

Posté le 17 septembre 2025

Je me permets de rajouter un point à la liste : le souci des données qui se figent aléatoirement (même si + fréquemment en heure de pointe) semble de retour depuis la rentrée, bien qu'il fut absent ces derniers mois. Ce phénomène touche à la fois les positions des véhicules et les horaires temps réel. À titre d'exemple, les données sont restées figées de 08:48 à l'instant même (09:08) avant de se mettre à nouveau à jour (soit 20 minutes de temps mort). Le retour se fait de façon assez aléatoire, jusqu'à la prochaine occurrence du phénomène. Merci par avance, et bonne journée à vous. Kevin.

—

Posté le 13 octobre 2025

Bonjour messieurs, Je vous remercie pour toutes ces remontées auxquelles je vais tenter de répondre au mieux : - Concernant la problématique de "Véhicule qui "change" de ligne sporadiquement", nous ne sommes pas parvenus à la reproduire ; auriez-vous des exemples de cas récents à nous transmettre ? - Concernant le "manque d'activité post-minuit", nous avons mis en place une surveillance depuis le jeudi 09 octobre et n'avons pas constaté cette problématique depuis ; n'hésitez pas à revenir vers vous si besoin. - Concernant la problématique relative au "désalignement des identifiants d’arrêts entre statique et temps réel", nous l'avons effectivement reproduite et sommes actuellement en cours de correction sur ce sujet. - Concernant le souci des "données qui se figent", nous avons mis en place une surveillance depuis le jeudi 09 octobre et n'avons pas constaté cette problématique depuis ; n'hésitez pas à revenir vers vous si besoin. Nous vous remercions encore pour vos retours et nous nous excusons pour la gêne occasionnée, Déborah Tourmente-Ben Achrak pour la Métropole Rouen Normandie

—

Posté le 14 octobre 2025

Bonjour, Je reviens vers vous à propos des points 2 et 4 (activité post-minuit et données figées) qui sont effectivement toujours d'actualité. J'ai mis en place une capture toutes les 5 minutes de l'ancien (reseau-astuce.fr) et du nouveau GTFS-RT Vehicle Position que vous pouvez retrouver ici : https://gtfs.bus-tracker.fr/astuce-gtfsrt/ (sous représentation JSON / en UTC > +2h à rajouter). Pour le manque d'activité post-minuit : le fichier est bien généré toutes les minutes (`.header.timestamp` sera toujours +/- frais). En revanche, les véhicules contenus dedans sont quant à eux progressivent figés jusqu'à en disparaitre (`.entity.[vehicle].vehicle.timestamp` ne bouge plus, de même que le reste des données). Pour les véhicules Noctambus et T1 nocturne, ils n'apparaissent quant à eux jamais sur le flux. Vous pouvez consulter les fichiers `2025-10-14_03-40_new.json` et `2025-10-14_03-40_old.json` où on constate bien le souci. Pour les données qui se figent, là aussi le fichier se génère toujours à rhythme constant : ce sont ses données qui se figent. Prenons par exemple les fichiers `2025-10-14_06-50_old.json`, `2025-10-14_06-55_old.json` et `2025-10-14_07_00_old.json` qui ont tous les trois une taille identique de 150Ko : il est plus qu'improbable que le contenu du fichier ne bouge pas à 7h du matin en semaine. et en faisant un diff entre 06-50 et 07-00 : ``` ➜ diff 2025-10-14_06-50_old.json 2025-10-14_07-00_old.json 5788c5788 < "timestamp": 1760417381 --- > "timestamp": 1760417982 ``` La seule donnée ayant changé est le `.header.timestamp`, donc rien d'autre n'a changé dans le fichier en 10 minutes. Je garde le répertoire en activité, au cas où le point 1 venait à se reproduire et pour faciliter vos tests. Merci par avance Bonne journée à vous, Kevin

—

Posté le 15 octobre 2025

Bonjour, J'apporte une petite mise à jour concernant le point n°4, à savoir le rafraichissement des données se faisant à un rythme très lent. Je ne sais pas si des actions ont été menées hier, mais la situation semble être revenue à la normale depuis hier après-midi. On est passé d'un rythme de ~ /20 minutes à ~/45-90s ce qui est bien mieux (même si je ne dis pas non à une cadence plus élevée, maintenant c'est très bien comme ça). Merci dans le doute pour la résolution de ce souci :) Je reste dispo si il y a besoin de plus d'infos sur les autres constats. Bonne journée à vous, Kevin.

—

Posté le 20 octobre 2025

Bonjour, À destination des équipes Transit (et autres utilisateurs par la même occasion) : dans l'attente de la résolution du GTFS-RT officiel, vous pouvez utiliser les deux ressources GTFS-RT présentes dans les ressources communautaires : elles ont été modifiées afin de correspondre aux identifiants présentés dans le GTFS publié ici-même. Bonne journée à vous, Kevin

—

Posté le 26 octobre 2025

Bonjour, Je me permet de vous remonter une anomalie constatée ce soir sur le flux GTFS-RT sur ce fil afin de concentrer toutes ces problématiques précises en un lieu. Cette anomalie concerne le suivi des véhicules en état de déviation (déclaré sur le SAE et impactant au moins un arrêt sur la course). Plus précisément, leur position ne semble plus mise à jour lorsque ceux-ci se situent sur le parcours de déviation. Vous trouverez ici : https://gtfs.bus-tracker.fr/astuce-ano-deviation/ des captures réalisées toutes les 30 secondes du GTFS-RT "nouveau" et "historique" (respectivement avec suffixes new et old) au format JSON entre 21:32 et 21:41 ce dimanche 26 octobre. Dans ces ressources, le véhicule témoin de l'anomalie est le n°3112 qui circulait à ce moment là sur la ligne F8 en direction de Tamarelle. La ligne est actuellement déviée à Mont-Saint-Aignan, supprimant la desserte des arrêts Murets, Gallieni et Fréchon. À 21:34:33 (2025-10-26_21-34-33_new.json), le véhicule arrive au début du parcours de déviation ({49.462936, 1.083865}). Jusque alors, sa position était mise à jour toutes les 30 secondes : le nouveau et l'historique sont +/- raccords. Pendant le parcours de déviation, la position dans le GTFS-RT nouveau se fige. Pendant ce temps, elle continue à être mise à jour dans l'ancien. Enfin, à 21:39:01 : la position est à nouveau mise à jour dans le nouveau. Il se trouve désormais à La Vatine - C.Cial, de retour sur le parcours nominal de la ligne. Anomalie reproductible avec toute déviation programmée dans le SAE et affectant la desserte d'au moins un arrêt : comme par exemple avec la ligne F3 à hauteur de Saint-Yon et Coquelicots. En attendant, l'ancien GTFS-RT permet d'obtenir une position fraiche pendant la déviation d'un véhicule. Néanmoins, lorsque celui-ci sera arrêté, il ne sera plus possible en l'état de suivre un véhicule dévié de sa ligne. Merci par avance Très bonne journée à vous, Kevin

—

Posté le 3 décembre 2025

Bonjour, Tous les flux temps réel semblent KO depuis cette nuit Bonne journée à vous, Kevin

—

Posté le 3 décembre 2025

Bonjour Kévin, Nous vous remercions pour cette remontée. Cependant, pourriez-vous préciser ce que vous entendez par "KO" ? En effet, l'accès aux ressources temps réel semble tout à fait opérationnel. Nous vous remercions par avance pour les précisions que vous pourrez nous apporter et nous excusons pour la gêne occasionnée, Déborah Tourmente-Ben Achrak pour la Métropole Rouen Normandie

—

Posté le 3 décembre 2025

Bonjour, L'anomalie a été corrigée en début d'après-midi visiblement. Les différents flux GTFS-RT (à l'exception de ceux concernant TNI) ne contenaient plus de données. J'en profite pour revenir vers vous à propos du bug concernant le "swap de ligne" sur le flux positions des véhicules : le problème semble toujours d'actualité. Je suis parvenu à capturer ces différences entre l'ancien et le nouveau GTFS-RT. Ancien : https://gtfs.bus-tracker.fr/astuce-gtfsrt/2025-12-03_18-45_old.json Nouveau : https://gtfs.bus-tracker.fr/astuce-gtfsrt/2025-12-03_18-45_new.json En ciblant le véhicule 329, il est sur la ligne 20 sur l'ancien GTFS-RT – ce qui est exact – mais est sur la ligne F1 sur le nouveau GTFS-RT. Ce même 329 a été observé cet après-midi sur la ligne 20, mais par moments (l'ordre de quelques secondes à minutes seulement) sur les lignes F1, F2 et F8 où il ne faisait qu'emprunter un parcours commun (Route de Neufchâtel et Tamarelle). Ce problème arrive de façon aléatoire dès lors qu'un véhicule se situe sur un tracé commun avec une autre ligne (par exemple F1 et 20 route de Neufchâtel, où le bug a été aperçu ici). Cela concerne également le TEOR par exemple où le véhicule 5505 – sur la ligne T2 – a été "vu" sur le T1 de 14:33 à 14:44 et de 18:11 à 18:13. De façon plus générale, ces occurrences sont historisées ici si ça peut aider à la détection du problème : https://bus-tracker.fr/data/networks/1?operatorId=1 Le répertoire https://gtfs.bus-tracker.fr/astuce-gtfsrt/ contient comme pour le 1er signalement des captures de l'ancien et du nouveau RT VP réalisées toutes les 5 minutes. Merci par avance Très bonne journée à vous, Kevin.

Données statiques et temps réel non disponibles

—

Posté le 10 septembre 2025

Discussion close par

Déborah Tourmente le 13 octobre 2025

Données périmées

Kisio Digital

—

Posté le 27 août 2025

Discussion close par

Déborah Tourmente le 13 octobre 2025

Coordonnées GPS

Isaac Fuentes

—

Posté le 26 août 2025

Discussion close par

Déborah Tourmente le 3 novembre 2025

TNI > Données temps réel muettes

—

Posté le 12 août 2025

Discussion close par

Déborah Tourmente le 13 octobre 2025

Données périmées

Métropole Rouen Normandie

—

Posté le 4 août 2025

Bonjour, Nous avons remarqué que les calendriers des trajets de la dernière mise à jour sont périmés. Pourriez-vous vérifier si la version du fichier a été remplacée par la version précédente ? Merci d'avance. Cordialement, Derek Lee Transit

—

Posté le 8 août 2025

—

Producteur

Bonjour Derek, Nous vous remercions pour cette remontée pour laquelle nous sommes actuellement en cours d'analyse. Nous reviendrons vers vous au plus vite dès qu'une correction aura été apportée. Bien cordialement, Déborah Tourmente-Ben Achrak pour la Métropole Rouen Normandie

Valeurs inversées entre pickup_type et drop_off_type