République
Française
HORAIRES SNCF
Description
Horaires théoriques et en temps réel de la SNCF
Théorique : les horaires des lignes TER, Intercités et TGV opérées par la SNCF Voyageurs pour les 151j à venir, sont fournis au format GTFS et au format NeTEx (qui est la norme technique européenne pour l'échange de données de transport). Les fichiers sont disponibles aux liens suivants :
- pour le GTFS : https://eu.ftp.opendatasoft.com/sncf/plandata/Export_OpenData_SNCF_GTFS_NewTripId.zip
- pour le NeTEx : https://eu.ftp.opendatasoft.com/sncf/plandata/export-opendata-sncf-netex.zip
Temps réel : les horaires en temps réel sont fournis selon les deux standards GTFS RT et SIRI pour les horaires et les informations contextuelles sur un périmètre élargi comprenant notamment les TGV, les IC et TER (y compris les sociétés dédiées TER) :
- GTFS-RT TU (Trip Updates) mis à jour toutes les 2 minutes pour les trains circulant dans les 60 prochaines minutes et GTFS-RT SA (Service Alerts) pour les circulations à venir
- SIRI ET Lite (service "Situation eXchange") mis à jour toutes les 2 minutes pour les trains circulant dans les 60 prochaines minutes et SIRI SX Lite (service "Situation eXchange") pour les circulations à venir
Les fichiers sont disponibles aux liens suivants :
- pour le GTFS-RT TU : https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-trip-updates
- pour le GTFS-RT SA : https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-service-alerts
- pour le SIRI ET LITE (version Béta) : https://proxy.transport.data.gouv.fr/resource/sncf-siri-lite-estimated-timetable
- pour le SIRI SX LITE : https://proxy.transport.data.gouv.fr/resource/sncf-siri-lite-situation-exchange
Quelques remarques techniques :
- Au niveau théorique : des mises à jour ont été effectuées sur les données GTFS : le plan de transport théorique intègre désormais à l'échelle nationale les adaptations connues la veille à 17h en cas de perturbations ou de mouvements sociaux.
- Les flux en temps réel ne sont pas filtrés, et peuvent contenir un périmètre plus large que les TGV, IC et TER. Même si des informations concernant d’autres circulations peuvent être visibles, merci de vous référer aux jeux de données des autorités organisatrices compétentes, notamment Ile de France Mobilités pour les données en temps réel en Ile de France ou les différents temps réels des Régions quand elles existent. Le périmètre n’est garanti que pour TGV et IC
- Pour les flux GTFS-RT SA et SIRI SX Lite : l'identifiant commun des circulations entre les différents flux est le numéro commercial du train, que vous trouverez dans pour le GTFS-RT SA et dans dans le SIRI SX LITE. Ces flux ne comprennent que les informations valorisées à la course et ne comprennent pas les informations relatives à des périmètres (gares ou lignes du réseau, qui peuvent impacter plusieurs opérateurs).
·Ce jeu de données est une production SNCF Voyageurs contenant des éléments assemblés pour la communauté open data au-delà de ses obligations réglementaires. Il ne se substitue donc pas aux données officielles progressivement publiées par les autorités organisatrices régionales qui peuvent éventuellement comporter de petites divergences. Aussi, nous vous recommandons de plutôt consommer les données fournies par les Régions et IDFM.
En cas de question, vous pouvez contacter l'équipe Open data SNCF Voyageurs à l'adresse suivante : Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
- Diffuseur
- Attributions
- SNCF Voyageurs(Créateur)SNCF Voyageurs(Éditeur)
- Dernière mise à jour
- 18 juin 2025
Couverture temporelle non renseignée
Vues
0
Téléchargements
0
Ce jeu de données provient d'un portail externe. Voir la source originale.
Consulter ce jeu de données sur le Point d'Accès National aux données de mobilités pour bénéficier d'informations supplémentaires : validations, visualisations, etc.
Votre question porte sur autre chose que ce jeu de données ? Visiter notre forum
23 discussions dont 11 clotûrées
Composition des trains
Bonjour,
Je voudrais savoir s'il serait possible pour vous d'inclure quelque part dans le temps réel la composition des trains. En effet, il peut être très utile pour le voyageur de connaître la taille du train, son apparence, pour mieux anticiper le trajet et repérer le train plus facilement en gare. On peut trouver ces informations sur SNCF Connect ou ter.sncf.com à partir en général de la veille.
Pensez-vous pouvoir inclure, soit le numéro du matériel que l'on peut en tant que réutilisateur traiter facilement (si c'est X76... ou Z27... ou B81... ou B82... c'est un AGC, si c'est z24... z26... c'est un 2NNG...), ce serait peut-être plus facile pour vous comme c'est une information brute, soit en mettant directement le nom du train ainsi que les nombres de voitures et de places ?
Je vous remercie par avance
Isaac Fuentes
Bonjour Issac,
nous n'avons malheureusement pas pour l'instant cette information dans le processus de la chaine de production des données de l'opendata. Nous étudions actuellement la question, pour un enrichissement du NETEX dans un premier temps, sans pouvoir vous garantir le niveau de détail qui sera publié.
j'espère néanmoins que nous pourrons améliorer dans un futur proche ces éléments qui sont demandés par la communauté. je ne manquera
Arnaud
Mes excuses, la derniere phrase est incomplète (erreur de manip).
Je ne manquerai pas de revenir vers vous dès que nous aurons une roadmap claire à ce sujet.
route_type et voies
Bonjour,
Désolé si cela a été évoqué déjà ailleurs, mais :
* Est-ce qu'il serait possible d'utiliser les https://developers.google.com/transit/gtfs/reference/extended-route-types pour pouvoir distinguer les grandes lignes (TGV/Intercités) des TER? Je sais qu'en théorie c'est possible de distinguer à partir des stops.txt mais c'est une information si importante que ce serait bien si les consommateurs n'avaient pas besoin de concevoir une logique supplémentaire juste pour le feed SNCF.
* Est-ce qu'il serait possible d'inclure les voies dans le GTFS-RT dès que cette information est disponible ? Je propose d'ajouter toutes les voies possibles pour toutes les gares dans stops.txt du GTFS (avec "parent_station" et "platform_code") sans qu'elles soient référencés dans le GTFS où juste les stations parentes sans précision de la voie sont utilisées. Mais désormais dans le GTFS-RT on peut référencer les voies du GTFS (parce que GTFS-RT permet de changer le stop_id, justement pour permetter des changements de voie).
Merci par avance.
Bonjour,
l'utilisation des extended-route est en cours d'analyse, cela est demandé par plusieurs utilisateurs (et pourrait aussi résoudre en partie le pb soulevé pour Nantes). j'espère une issue positive. l'implémentation pour notre réseau n'est pas simple car il est très large.
Pour les voies GTFS RT, ceux-ci sont inclus dans le SIRI ET LITE, qui est le format qui le supporte le mieux et qui est le format réglementaire. Pour l'instant il n'est pas prévu de supporter le développement dans le GTFS RT TU qui est assez "couteux" dans le cadre de notre flux très large
pour vos propositions :
- L'ajout dans le StopPoint n'est pas possible et difficilement envisageable
- Il faudrait comme vous le dites, alourdir considérablement le GTFS dans la description et dans le GTFS RT déclarer l'ensemble des trains en changement de station à chaque fois que le quai est connu
malheureusement, les futurs développements seront d'abord implémentés dans les formats réglementaires, qui sont plus lourds mais qui plus souples lorsque les informations sont plus complexes, et leur versement dans le format GTFS est à voir selon la simplicité d'implémentation.
Cordialement
Arnaud
Merci pour vos précisions !
On aimerait bien utilisier le jeu de données NeTEx, mais il semble être incomplet (en ce moment il y a 110 trains en circulation selon le NeTEx contre 700 selon le GTFS). En plus, les ids StopPointRef du SIRI ne correspondent pas aux ScheduledStopPoint du NeTEx (quelques-uns existent avec un ":" de moins, p.ex. "FR:ScheduledStopPoint::87753285" vs "FR:ScheduledStopPoint:87753285", mais la plupart ne semble pas du tout exister dans le NeTEx). Mais peut-être il y a quelque chose qu'on ignore.
Bien-sûr, de notre point de vue, même avec le PlatformName de SIRI, sans les coordonnées GPS il est impossible/difficile de calculer des itinéraires quai à quai comme on peut le faire normalement (et ce qui est important pour un calcul individuel précis des temps de correspondance et p.ex. pour les PMR).
Il existent des feeds avec plus de 600000 stops/quais et des GTFS-RT de ~100 Mo, donc en général cela ne pose pas problème. Mais quand NeTEx/SIRI seront utilisables, ce sera déjà une amélioration très apprécié.
Cordialement
Robin
je vous propose de continuer plutôt sur
Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
je vois au moins deux fois plus de trains actifs dans le GTFS RT et dans le SIRI, je ne sais pas comment vous arrivez à 110 circulations en cours dans le NETEX qui est statique, car les périmètres sont identiques, c'est juste le format de l'export qui change
on peut en discuter plus précisément
Arnaud
Je suis désolé, je n'avais pas bien regardé les chiffres, en effet, le NeTEx semble complet maintenant (même nombre de trains circulant selon les horaires statiques).
Le problème avec les deux-points doubles (:: vs :) et des ScheduledStopPoint n'existant pas du tout persiste.
Merci, Robin
bonjour Robin,
pas de soucis :) super si vous avez retrouvé l'ensemble des trains.
pour le pb des points doubles (doublé ou non) et des déclarations de stoppoints dans le NETEX, je vais regarder cela de plus près et tenter de trouver un cas précis. Si jamais vous en avez sous le coude : référence du SIRI LITE (date-heure )et du VehiculeJourneyRef ou ServiceJourneyRef, je suis preneur sur
Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
bonne journée
Arnaud
Identifiants de trips incorrects dans GTFS-RT Service Alerts
Bonjour,
Dans le flux temps réel Service Alerts, les trips sont référencés par leurs ids comme ceci "OCESN876307F".
Ces identifiants sont différents de ceux trouvés dans le GTFS théorique comme "OCESN44258R1187_R:CTE:FR:Line::24689242-F92D-4E76-A8DA-6E75B6A44DC1::87214056:87144014:20:2038:20260705".
Cette différence nous empêche de bien "brancher" le flux temps réel au flux théorique.
Mes questions :
1) Est-ce que c'est voulu? Pour garder la rétrocompatibilité avec les consommateurs de l'ancienne version du GTFS d'avant NewTripId?
2) Si non, pouvez-vous corriger ça svp?
Merci beaucoup,
Cordialement,
Omar
Bonjour Omar,
comme indiqué dans la description du jeu de données
"Pour les flux GTFS-RT SA et SIRI SX Lite : l’identifiant commun des circulations entre les différents flux est le numéro commercial du train, que vous trouverez dans <trip> pour le GTFS-RT SA et dans <VehiculeJourneyRef> dans le SIRI SX LITE. Ces flux ne comprennent que les informations valorisées à la course et ne comprennent pas les informations relatives à des périmètres (gares ou lignes du réseau, qui peuvent impacter plusieurs opérateurs). "
il s'agit d'une contrainte de notre opendata. Nous n'utilisons pas en interne dans nos services les formats GTFS et NETEX nativement. Les informations en temps réels circulent avec les numéros trains.
Pour le GTFS RT TU, nous avons développé un processus permettant de rapprocher l'ID du GTFS actif, car le GTFS RT TU ne concerne qu'un seul jour de circulation.
Pour le GTFS RT SA et SIRI SX Lite, les alertes pouvant être publiées très longtemps à l'avance et sur des périodes couvrant plusieurs jours de circulation, le "matching" est plus délicat. Nous ne pouvons l'effectuer à ce stade du processus de production de l'information en temps réel sans dégrader trop fortement le délai de mise à disposition de l'information.
cordialement
Arnaud
Problème UIC gare frontalière
Pour les gares frontalières GTFS expose l'UIC international : 71793150 = Portbou
Tandis que SIRI ET expose un code UIC français : 87785956 = Port-Bou
Les deux référentiels SNCF ne sont pas alignés un même arrêt apparaît en double dès qu'on croise les deux flux.
Peut être que l'exception se fait aussi sur le nom qui diffère (Portbou // Port-Bou)
Bonjour,
merci du signalement.
nous avons effectivement des analyses en cours sur ces identifiants quand ils passent la frontière, par uniquement sur Port Bou.
j'essaye de vous tenir informé.
Cordialement
Arnaud
Bonjour Arnaud,
Merci pour votre réponse, je n'hésiterai pas à vous prévenir si je trouve d'autres problèmes similaires.
Excellente journée,
Trayn
Merci, nous avons bien ce soucis en visu, il y a le pb aussi en Suisse par exemple.
excellente journée également
Arnaud
GTFS - logique de regroupement de 11 routes mêlant des modes hétérogènes (TGV INOUI / INTERCITES + Car à réservation)
Discussion close par 
Arnaud Chi le 16 juin 2026
Arnaud Chi le 16 juin 2026Question sur les agency ids?
Discussion close par Arnaud Chi le 1 juin 2026
Arnaud Chi le 1 juin 2026Navettes TGV Haute Picardie
Discussion close par Arnaud Chi le 1 juin 2026
Arnaud Chi le 1 juin 2026Anomalie mode de transport Données
Bonjour,
Je vous contacte concernant les données TER que nous récupérons pour le calculateur Naolib de Nantes Métropole.
Dans ces données, la ligne C7 qui est une ligne TER est typée TT et ressort donc en "Tramway"
Serait-il possible de corriger cela et de passer en mode TER ?
Les données sont récupérées via : https://eu.ftp.opendatasoft.com/sncf/plandata/export-opendata-sncf-gtfs.zip
Je vous remercie pour votre aide.
Bonjour,
merci pour le signalement. Tout d'abord, vous utilisez une url obsolète, notre plan de transport actualisé est maintenant sur https://eu.ftp.opendatasoft.com/sncf/plandata/Export_OpenData_SNCF_GTFS_NewTripId.zip
comme indiqué sur les ressources.
l'url que vous utilisez contient des données mais elles n'ont pas été mises à jour depuis le 29/12/25. il est préférable que vous mettiez à jour l'url pour Naolib.
Pour votre question, j'ai vérifié dans le GTFS de ce jour, la ligne C7 est la ligne Nantes-Chateaubriant, et a ma connaissance, c'est bien un Tram-Train. Par contre, je vois que le transporteur est Tram-Train et non Train TER. Est-ce que c'est cela qui pose soucis?
si vous le souhaitez, nous pouvons rentrer un peu dans le détail directement via
Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
cordialement
Arnaud
Excusez moi, j'ai répondu un peu rapidement. En parlant de transporteur, je voulais dire route_type = 0 pour cette ligne (FR:Line::c1be0e08-29ef-4c9a-9362-ffc94292f082:). est-cela que vous trouvez problématique?
Bonjour Arnaud
Merci pour votre retour rapide.
Effectivement il faudrait que le route_type soit = 2. Est-ce possible ? Il s'agit d'une demande de Nantes Métropole
d'accord, je vais faire remonter la demande.
bonne journée
Merci beaucoup !
j'ai demandé une analyse à l'équipe. Ceci-dit, quand on lit les specifications https://gtfs.org/documentation/schedule/reference/#routestxt
je cite pour la valeur de route_type "
0 - Tram, Streetcar, Light rail. Any light rail or street level system within a metropolitan area.
1 - Subway, Metro. Any underground rail system within a metropolitan area.
2 - Rail. Used for intercity or long-distance travel."
je ne vois pas pourquoi le tram-train Nantes-Chateaubriant devrait être classé en route_type = 2, la valeur requise est bien 0
je vous tiens informée
bon fin de mardi
Arnaud
Question sur les stops
Bonjour,
Je me demandais s'il y avait une raison pour laquelle une même gare est représentée par plusieurs stops enfants distincts selon le mode.
Exemple à Vichy, sous la station parente StopArea:OCE87732008 :
- StopPoint:OCETrain TER-87732008
- StopPoint:OCEINTERCITES-87732008
- StopPoint:OCECar TER-87732008
Les trois partagent exactement les mêmes coordonnées (46.1269910, 3.43047600), il ne s'agit donc pas de quais ou de points d'embarquement distincts. Or l'information de mode est en principe portée par routes.txt (via route_type), pas par le stop lui-même, d'où ma question.
Dans ce contexte-là, j'ai deux questions :
1. Le type de mode est encodé dans le préfixe du stop_id (OCETrain TER, OCEINTERCITES, OCECar TER), mais ce préfixe ne semble pas documenté comme un identifiant stable — donc difficile à exploiter de façon fiable côté consommateur.
2. Sur l'ensemble du réseau, ces stops enfants superposés génèrent beaucoup d'alertes "stops trop proches" lors de la validation GTFS, et compliquent la consommation de stops.txt pour représenter une gare physique.
Est-ce qu'il y a une raison historique ou métier à cette séparation par mode au niveau du stop, plutôt qu'un stop enfant unique par gare physique avec le mode porté par les routes ?
Merci d'avance pour votre retour,
Omar
bonjour Omar,
votre question est tout à fait légitime.
C'est un choix historique qui a été fait pas la SNCF, pour plusieurs raisons. Nous avons un réseau très large, et divers, et pour préserver l'unité il y a des cas où nous ne pouvons traiter correctement certaines situations. Je vous en cites certaines :
- quand nous avons une route mixte car/route, comme c'est le cas de nombreux TER localement, le mode principal de la route est ferré, et l'attribut du mode étant associé à la route, cela nous aurait donc obligé à créer une nouvelle route alors que commercialement, c'est la même desserte (ce qui a des implications autres, notamment en IV et commercialement, des fois le mieux est l'ennemi du bien. Aussi techniquement, cela nous posait soucis car le GTFS vient en bout d'un processus, et nous ne traitons pas de GTFS "nativement"). Dans ce cas, nous pouvons traiter cette exception en descendant l'attribut au niveau du stoppoint et cela est "couvert"
- dans l'optique où il conviendrait de distinguer des zones distinctes, même si cela est souvent le même arrêt comme vous le mentionnez, cela permet à certains utilisateurs de distinguer notamment les Cars et les TER pour des temps de correspondance, etc. ce qui facilite les enrichissements utilisateurs
comme vous le signalez, ce n'est pas documenté car c'est un ID. Mais c'est notre pattern.
Pour info, il y a une issue ouverte et cela est aussi le cas dans d'autres réseaux.
https://github.com/google/transit/issues/409
j'espère que vous trouverez une solution en travaillant ces ID, y'a le code UIC dedans.... sinon, vous pouvez utiliser aussi le NETEX si besoin
bien cordialement et bonne journée
nous pouvons poursuivre la discussion si besoin sur Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
Flux GTFS RT TU KO
Discussion close par Arnaud Chi le 20 avril 2026
Arnaud Chi le 20 avril 2026GTFS-RT TripUpdates
Bonjour,
Depuis quelques jours, des trains supplémentaires apparaissent dans le GTFS-RT TripUpdates, dont les numéros s'apparentent à des RER et Transilien, non prévus donc dans ce GTFS. Les gares indiquées comme desservies concernent que celles présentes dans le jeu de données.
Exemple ce jour (04/04/2026) :
147455
Mission ELBA du RER C
Musée d'Orsay -> Saint-Martin d'Étampes
renvoyée uniquement entre Juvisy et Étampes, sans aucune gare intermédiaire.
Est-il possible de corriger ce problème de filtrage svp ?
Merci par avance,
Erwan DELAHAYE
Bonjour Erwan,
merci du signalement. normalement les Transiliens sont bien absents du GTFS RT TU, et je ne les vois pas dans les quelques réponses que j'ai testé ce matin. j'en ai téléchargé aussi du 4/4 (nous avons qqs jours de back) et je ne les retrouve pas non plus.
si vous rencontrez de nouveau le soucis, n'hésitez pas à m'en faire part directement sur :
Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
avec le trip_id correspondant, ainsi que l'heure/date précise de la réponse
cordialement
Arnaud
bonjour à tous, suite à échange plus approfondie avec Erwan (merci encore :)) nous avons effectivement depuis quelques jour un filtre sur les messages transiliens qui n'est plus fonctionnel, et laisse donc passer qqs trains qui sont donc notés "ADDED", se mélangeant avec les vraies ajouts d'offre du périmètre. Je vois avec le prestataire pour rendre de nouveau ce filtre opérant.
désolé pour le désagrément en cours
Arnaud
trains Sud Azur manquants
Discussion close par Arnaud Chi le 30 mars 2026
Arnaud Chi le 30 mars 2026information sur la mise à jour des NETEX et GTFS
Bonjour chers utilisateurs,
des améliorations ont été apportées dans la chaîne de production des horaires statiques afin de libérer au plus tôt les données. NETEX et GTFS sont maintenant produits nominalement avant minuit (entre 22h et minuit) plutôt qu'autour de 2 à 4h du matin.
Occasionnellement, les exports peuvent être libérés après minuit le jour J.
Le premier jour de circulation commence au moment de l'export. De ce fait, les NETEX et GTFS valides pour le J, et produits avant minuit, ont leur premier jour de circulation à partir de J-1.
je reste à votre disposition pour plus de renseignements si nécessaire sur
Data_Office_Secretariat_General_SA_Voyageurs@sncf.fr
Arnaud
GTFS-RT pas à jour sur TER
Discussion close par Arnaud Chi le 5 mars 2026
Arnaud Chi le 5 mars 2026Problèmes avec fichier NeTEx 2026-01-23
Il y a es problèmes dans le fichier NeTEx.
- Il n'est pas valide avec la version 1.3.0 du NeTEx XSD.
- EPSG::4326, devrait être soit EPSG:4326 ou urn:ogc:def:crs:EPSG::4326. Nous avions déjà mentionné cela il y a 8 mois dans des autres fichiers de la SNCF.
- il y a beaucoup de ref vide ref="". Et ce sont des ref mandataires (e.g. <OperatorRef ref="" version="any"/>.
- si l’attribut dataSourceRef est défini dataSourceRef=»2148» , alors une DataSource doit être définie
- De ne pas avoir des OperatorRef dans Line est une mauvaise idée (par exemple Line id="OCESN-87686006-87741793" version="any">). Il y a plusieurs lignes avec des informations incomplètes
Bonjour Matthias,
merci pour ces remarques. Comme indiqué par mail, nous te proposons de refaire le point avec les équipes techniques pour discuter de tout cela.
cordialement
Arnaud
GTFS RT TU & SA indisponibles
Bonjour Arnaud,
Depuis ce matin, Le GTFS-RT SA et le GTFS-RT TU sont indisponibles.
https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-service-alerts renvoie vers une page 404
https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-trip-updates renvoie un contenu vide.
J'imagine que vous êtes au courant et êtes dessus mais je voulais m'en assurer.
Cordialement,
Lucas CWIK, représentant de Sylvain BEUCHER pour le compte de Google Maps
Bonjour Sylvain,
désolé, je viens juste de regarder et il y a effectivement un soucis.
sur le GTFS RT SA, je ne vois pas de rupture de service sur notre console, et l'url https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-service-alerts renvoie bien des données. Par contre, en creusant, j'ai vu que le lien hypertexte contenu dans le raccourci était différent, et renvoi bien une erreur 404. c'est une erreur de mise à jour sur notre opendata, je viens de le modifier, le temps de remonter les différents moissonneurs, ce sera corrigé. Je vais voir en interne, nos excuses. Mais l'url citée produit bien des données.
Sur le GTFS RT TU, effectivement, les réponses sont vides depuis le reboot de cette nuit. J'ai essayé de redémarrer le serveur, mais cela n'a pas marché. J'ai sollicité HACON en urgence j'espère que le flux sera vite rétabli.
Nos excuses pour le desagrément, je vous tiens informé.
Arnaud
Bonjour Arnaud,
Merci pour ce retour rapide et pour ces investigations.
C'est bien noté pour le GTFS RT SA. En effet, il y a bien des remontées.
Concernant le GTFS RT TU, nous comprenons que le problème est plus complexe. Nous restons en attente de ton retour dès que le flux sera rétabli.
Bon courage pour la résolution,
Cordialement,
Lucas CWIK, représentant de Sylvain BEUCHER pour le compte de Google Maps
merci Sylvain pour la comprehension. finalemebnt le service
merci Sylvain pour la compréhension, finalement le service a été rétabli vers 19h15. je regarde demain matin pour m'assurer que le soucis ne s'est pas reproduit.
! Maintenance des flux ! nouvelles urls pour GTFS et GTFS RT TU
Bonjour à tous,
merci de prendre connaissance des informations relatives à ce jeu de données.
les urls des GTFS et GTFS RT TU changent, pour des raisons de maintenance de notre côté, avec notamment un nouvel trip_ID qui gagnera en stabilité.
les anciennes adresses fonctionnent encore pour une petite période de transition.
Merci de vos changements, et si besoin, n'hésitez pas à nous contacter par mail.
Bon lundi
Bonjour à tous,
merci de basculer maintenant sur les nouvelles url GTFS et GTFS RT, les flux seront décommissionnés cette semaine.
Bon lundi
Bonjour, le flux RT semble vide de toute donnée temps réel pour le TER (En particulier Région Nouvelle aquitaine). Pouvez vous vérifier ?
bonjour,
a priori je ne vois pas cela. Utilisez vous bien https://proxy.transport.data.gouv.fr/resource/sncf-gtfs-rt-trip-updates ?
(voir description).
le site n'a pas encore mis à jour la description du jeux de données, mais les urls TER et https://proxy.transport.data.gouv.fr/resource/sncf-all-gtfs-rt-trip-update
ont été arrêtés conformément aux informations transmises
Arnaud
Absence du fichier shapes dans le GTFS statique
Discussion close par Arnaud Chi le 3 novembre 2025
Arnaud Chi le 3 novembre 2025Line OCESN-71718010-87686006 ne fait pas de sens
Il y a dans le fichier NeTEx des lignes, qui n'ont pas d' OperatorRef et aussi pas d'AuthorityRef
Source:
https://eu.ftp.opendatasoft.com/sncf/plandata/export-opendata-sncf-netex.zip
ça ne fait aucun sense. Un example:
<Line id="OCESN-71718010-87686006" version="any">
<Name> -</Name>
<Description></Description>
<TransportMode>unknown</TransportMode>
<PublicCode>INCONNU</PublicCode>
<routes>
Des lignes doivent être complet ou pas du tout dans le fichier. Ces lignes aussi sembles de ne pas vraiment être bien definites.
Pire est que c'est Line sont referencées avec des ServiceJourney et là soudain i ils ont uneMode et SubMode mais l'OperatorRef est encore plus invalide:
<ServiceJourney id="FR:ServiceJourney::SN9704FERRE_4524166" responsibilitySetRef="1187" dataSourceRef="2148" version="any" status="active">
<ValidBetween>
<FromDate>2025-10-09T00:00:00</FromDate>
<ToDate>2026-03-08T23:59:59</ToDate>
</ValidBetween>
<BrandingRef ref="OUI"/>
<Distance>0</Distance>
<TransportMode>rail</TransportMode>
<TransportSubmode>
<RailSubmode>highSpeedRail</RailSubmode>
</TransportSubmode>
<ServiceAlteration>planned</ServiceAlteration>
<DepartureTime>15:20:00</DepartureTime>
<dayTypes>
<DayTypeRef ref="FR:DayType:1719:" />
</dayTypes>
<JourneyPatternRef ref="FR:ServiceJourneyPattern::SN9704FERRE_4524166" />
<OperatorRef ref="" version="any"/>
<LineRef ref="OCESN-71718010-87686006" version="any"/>
<trainNumbers>
<TrainNumberRef ref="FR:TrainNumber::SN9704FERRE_4524166" version="any"/>
</trainNumbers>
Merci pour faire des corrections et de nous informer quand ils sont faits.
Cordialement
Matthias Günter
Bonjour Matthias,
merci pour le signalement. je transmets à l'équipe technique et vous tiens informé.
Bien cordialement
Arnaud
Bonjour,
nous avons un soucis de référentiel en cours suite à une migration. J'essaye de voir avec l'équipe si nous pouvons faire quelque chose de palliatif rapidement.
ce soucis se répercute sur le NETEX, avec le pb identifié par Matthias : des balises absentes.
il se répercute aussi sur le GTFS, avec des noms de ligne "INCONNU" un peu plus nombreuses que la normale.
En attendant, la desserte reste valide sur les champs principaux
je vous tiens informé et nos excuses pour le désagrément
Arnaud
Clarification affichage des trains pour les voyageurs
Discussion close par Arnaud Chi le 29 septembre 2025
Arnaud Chi le 29 septembre 2025