Table des matières

Rechercher sur le site

NeTEx

Description rapide

Network Timetable Exchange (NeTEx) est le standard de l’UE pour les données d’horaire. Il a été développé par le Comité européen de normalisation (CEE). Il s’appuie sur Transmodel, le modèle de données de référence européen pour les transports publics.

Cette page du livre de recettes met en évidence et explique les différences et les particularités de l’implémentation de NeTex en Suisse par rapport à d’autres pays de l’UE.

Accès aux données

Description métier

Network Timetable Exchange (NeTEx) crée une plate-forme unifiée d’échange de données relatives au trafic en vue de l’établissement des horaires pour les trains, les bus, les téléphériques, les bateaux ainsi que les prestataires locaux d’autres formes de mobilité, comme les vélos et les trottinettes électriques.

Le groupe NeTEx se compose (état en 2025) de 12 pays qui utilisent activement ce format et de 5 autres pays qui sont en phase de mise en œuvre. Le marché continue de se développer, même au-delà de l’Europe, comme le montre l’exemple de l’État australien de Victoria.

Pour la Suisse, le standard des données NeTEx est d’une grande importance, dans la mesure où il permet un échange efficace de données d’horaire entre les entreprises de transport internationales. Cela permet de proposer au consommateur final un horaire fiable et sans interruption d’un point A à un point B: Par exemple, si une personne consulte l’horaire d’un train de Zurich à Lyon (F), toutes les relations et correspondances pour les deux pays sont indiquées.

Outre NeTEx, il existe d’autres formats de données d’horaire, comme HRDF ou GTFS.

GTFS (General Transit Feed Specification)

  • Provenance: Développé par Google en collaboration avec TriMet (Portland, États-Unis) et perfectionné entre-temps par MobilityData.
  • Format: Ensemble de fichiers CSV (texte), regroupés dans une archive ZIP.
  • Structure: Format tabulaire simple avec des fichiers prédéfinis tels que: stops.txt, routes.txt, trips.txt, stop_times.txt etc.
  • Priorité: Largement utilisé pour les renseignements sur l’horaire, les informations en temps réel et les portails de données ouvertes.

Informations détaillées sur GTFS dans Cookbook GTFS.

HRDF (HAFAS Raw Data Format)

  • Origine: Développé par HaCon, une entreprise allemande (aujourd’hui partie de Siemens).
  • Format: Format propriétaire, binaire ou textuel utilisé en interne dans le système HAFAS de HaCon.
  • Structure: Forte optimisation sur les performances, mais difficilement lisible par l’homme et non documenté publiquement.
  • Thème principal: Principalement utilisé dans les pays germanophones (p. ex. Deutsche Bahn, CFF) pour les systèmes internes de planification et d’horaire.

Informations détaillées sur HRDF dans le Cookbook HRDF.

Description technique

Structure des fichiers et dénomination

Les fichiers NeTEx doivent être nommés de manière claire, cohérente et lisible par une machine. Un schéma typique pourrait ressembler à ceci:

[Module]_[Région]_[Version]_[Date]_[Type].xml

  • Timetable_CH_2025_v1.2_20250801.xml – Données d’horaire pour la Suisse, version 1,2, créé le 1er août 2025
  • FareFrame_ZH_v3.0_20250715.xml – Données tarifaires pour Zurich, version 3,0
  • ServiceFrame_BE_v2.1_20250820.xml – Informations sur les lignes et les services pour Berne

Bases de NeTEx

NeTEx utilise un schéma XML modulaire basé sur Transmodel. Il définit des modèles de données abstraits pour différents domaines des transports publics, p. ex. les arrêts, les lignes, les horaires, les tarifs et les données d’exploitation. Les principaux éléments de NeTEx-XML sont les cadres. Chaque cadre contient des informations spécifiques sur la formation d’un moyen de transport.

Vous trouverez ci-dessous une brève description des cadres avec les principales classes. Des informations plus détaillées sont disponibles sous le lien suivant: NeTEx – Transmodel (https://transmodel-cen.eu/index.php/netex/).

FrameDefaults

FrameDefaults est un mécanisme permettant de définir des valeurs par défaut, telles que le fuseau horaire, l’heure locale, la sélection de la langue.

CompositeFrame

Une CompositeFrame regroupe plusieurs cadres de données (frames) thématiquement liés dans un seul fichier, p. ex. FrameDefaults, ResourceFrame, SiteFrame, ServiceFrame, ServiceCalendarFrame, TimetableFrame. Utile pour la mise à disposition structurée de blocs de données complexes, lorsque différents aspects des transports publics sont requis conjointement.

Cadre Ressource

ResponsibilityRoleAssignment

Associe une organisation (CFF, DB, BLS, etc.) à un rôle particulier en rapport avec un autre élément (p. ex. une ligne, un horaire, un service).

TypeOfProductCategory

Élément de classification qui décrit la nature du produit (p. ex. type de train, offre de bus, classe de service).

TypeOfNotice

Définit les types de remarques ou les offres utilisés dans l’information aux voyageurs. Il s’agit d’une définition du type référencée par des éléments de notice concrets

Cadre Site

TopographicPlace

Sert à établir une classification géographique des arrêts et d’autres emplacements. En Suisse, c’est le plus souvent le canton (et non la commune) qui est utilisé comme TopographicPlace afin de garantir une structure uniforme et claire.

StopPlace

Il décrit différents aspects d’unpoint d’accès physique aux transports, p. ex. une halte ou une station. En Suisse, il désigne un canton ou une région.

Quai

Fait toujours partie d’un StopPlace. Il s’agit d’un dispositif tel qu’un quai, un arrêt ou une passerelle permettant aux voyageurs d’accéder aux transports publics, aux taxis, aux voitures ou à d’autres moyens de transport. Un quai peut desservir un ou plusieurs points d’arrêt et être associé à un ou plusieurs points d’arrêt.

ServiceFrame

Direction

Une direction décrit un sens de circulation à l’intérieur d’une ligne, par exemple «direction gare» ou «direction aéroport». Elle aide à différencier les trajets à l’intérieur d’une ligne – par exemple, aller et retour.

Line

Représente une ligne de transport public, par exemple une ligne de bus, de tram ou de train, par exemple la «ligne de bus 10» ou la «ligne RER S3». Elle regroupe les trajets qui circulent sous le même numéro ou la même désignation de ligne.

DestinationDisplays

L’affichage visuel de la destination indique aux passagers où va un véhicule. Il est souvent associé à un ServiceJourney ou un VehicleJourney et est particulièrement important pour l’information aux voyageurs p. ex. dans les bus, les trains ou les affichages électroniques.

ScheduledStopPoint

Un concept central. Il s’agit du «point» utilisé dans l’horaire où un service s’arrête. Un ScheduledStopPoint peut se référer soit à un quai (p. ex. quai, position d’arrêt), soit à un StopPlace (p. ex. gare, arrêt). Le niveau hiérarchique n’est pas déterminé par l’élément lui-même (voir PassengerStopAssignment).

PassengerStopAssignment

Élément principal décrivant l’affectation. Indique l’ordre dans lequel ce point d’arrêt apparaît dans un itinéraire ou un JourneyPattern. Il fait référence au point d’arrêt logique dans l’horaire, le «ScheduledStopPointRef», qui réfère dans le «StopPlaceRef» à l’emplacement physique (p. ex. un arrêt).

Notice

Définit des éléments textuels réutilisables qui peuvent être utilisés comme remarques, par exemple sous forme de notes de bas de page dans les horaires, d’annonces ou d’autres messages. Les NOTICES sont attribuées à d’autres éléments au moyen d’un NOTICE ASSIGNMENT. Elles peuvent être classées à l’aide d’un TYPE OF NOTICE.

L’élément sert de conteneur dans lequel des avis ou messages prédéfinis – par exemple les informations aux voyageurs, les avis d’exploitation ou les annonces de service – sont associés de manière ciblée à des objets spécifiques dans les données d’horaire. Il s’agit notamment de ce qui suit:

  • ServiceJourneys (trajets concrets)
  • JourneyParts (tronçons partiels d’un parcours)
  • TrainBlocks (roulements de trains)
  • StopPoints (points d’arrêt)
  • OperatingDays (jours d’exploitation)

ServiceCalendarFrame

AvailabilityCondition (condition de disponibilité)

Spécialisation de la VALIDITY CONDITION permettant de définir des conditions temporelles précises. Par exemple, une entrée d’un StopPlace peut être valable (elle existe), mais pas disponible à tout moment (p. ex. fermée entre 21h00 et 6h00). Les VALIDITY CONDITIONs et AVAILABILITY CONDITIONs peuvent être reliées au même objet

Calendrier des services

L’offre de transport d’une entreprise de transports publics est conçue de manière à répondre à différentes demandes. Pour simplifier la planification de l’offre, la quasi-totalité des exploitants établissent leur plan de production sur la base d’une classification par types de jours qui résume le comportement de la demande ou d’autres caractéristiques telles que les jours ouvrables, les week-ends, les vacances scolaires, les jours de marché, etc. Les horaires planifiés à long terme s’appuient sur des calendriers de circulation, dans lesquels les jours civils sont classés comme des types de jours spécifiques (DAY TYPES).

DayTypes

Les horaires sont établis à l’aide du calendrier de circulation, dans lequel les jours civils sont classés comme types de jours spécifiques (DAY TYPEs).

TimetableFrame

Service Journey

Parcours de véhicules dans lequel des voyageurs peuvent monter et descendre aux arrêts. Elle décrit la prestation de transport entre un point de départ et un point d’arrivée, telle qu’elle est communiquée publiquement.

DestinationDisplayRef
Décrit l’affichage visuel de la destination en lien avec un processus d’arrêt (Call). Il est important pour l’information aux voyageurs, p. ex. sur les tableaux d’affichage des véhicules ou les horaires électroniques.

Notice Assignments
Est utilisé dans le cadre du ServiceJourney. Dans ce cas, le message vaut pour l’ensemble du trajet. Si un message n’est valable que pour une partie du ServiceJourney, l’affectation se fait dans tous les éléments d’appel concernés.

Appel
L’ représente une vue regroupant les données relatives à la visite des différents arrêts. Des ensembles ordonnés d’éléments d’appels peuvent être contenus dans des instances ServiceJourney échangées via NeTEx.

Arrêt des requêtes
Identification pour les arrêts à la demande («arrêt sur demande»). Est souvent utilisé en zone rurale ou pour les transports à la demande. Il peut être indiqué en conséquence dans les systèmes d’information des voyageurs (p. ex. avec un symbole ou un texte d’information). Important pour le calcul des temps de parcours, car des arrêts à la demande peuvent être ignorés et le temps de trajet peut ainsi être réduit.

Arrêt de l’utilisation
Attribut indiquant la fonction remplie par un point d’arrêt au sein d’un VehicleJourney. Il indique si l’arrêt pour:

  • Accès (boarding)
  • Descente du train («alighting»),
  • les deux (deux),
  • ou aucune de ces fonctions (pass-through)

est utilisée.

Numéro de train

Les TrainNumber se composent actuellement de six chiffres au maximum. Un ServiceJourney peut en principe contenir plusieurs numéros de train différents, tandis qu’un JourneyPart ne renvoie à chaque fois qu’à un seul TrainNumber. En Suisse, il n’y a pas de différence entre le TrainNumber publié et le TrainNumber productif.

FacilitySets

Élément structuré utilisé pour attribuer des dispositifs à un ServiceJourney ou à un JourneyPart. SKI classe ces dispositifs dans les groupes suivants:

  • Installations d’hébergement
  • Équipements de restauration
  • Classes tarifaires
  • Dispositifs de réservation de groupe
  • Installations de transport de bagages
  • Équipements de mobilité
  • Dispositifs de réduction des perturbations
  • Équipements de communication pour les voyageurs
  • Dispositifs de réservation de services
  • Émetteurs de billets
  • Tarifs des trains UIC

Cette classification permet une description standardisée des services disponibles au cours d’un voyage. La liste peut être étendue au besoin, à condition que la catégorie concernée soit définie dans les spécifications NeTEx.

Journey Meeting

..décrit la possibilité de planifier les horaires en tenant compte des différentes possibilités de correspondance:

  • Changement vers un autre service dont seule l’heure d’arrivée ou de départ est connue
  • Plus général: Service dont l’horaire est basé sur l’heure déterminée d’un événement externe qui alimente ce service ou qui est alimenté par celui-ci.
  • Organisation d’un point de rencontre (hub) entre plusieurs services dans une fenêtre temporelle définie; il s’agit d’une spécification simplifiée de plusieurs correspondances. Si nécessaire, cet aspect peut être décrit en détail par plusieurs INTERCHANGE RULE ou SERVICE JOURNEY INTERCHANGE.
  • Définir un point de rencontre (heure et lieu) pour chaque trajet qui peut profiter de ce rendez-vous.

InterchangeRule 

Ensemble de règles permettant de documenter des changements de train planifiés dans l’horaire sans devoir indiquer les détails exacts des deux ServiceJourneys impliqués. Il sert à définir et à structurer les correspondances potentielles entre les courses, notamment lorsqu’elles ne sont pas spécifiées intégralement.

InterchangeRuleParameter
Élément de la TimetableFrame servant à spécifier des paramètres pour des changements planifiés entre différents ServiceJourneys. Il définit les conditions et restrictions dans lesquelles un changement est considéré comme valable, par exemple au niveau du moyen de transport (Mode), de la ligne (Line) ou du sens de circulation (Direction).
Ces paramètres permettent une modélisation flexible des correspondances sans devoir indiquer des détails complets sur les trajets concernés. Ils sont particulièrement utiles lorsque les changements doivent être planifiés de manière dynamique ou basée sur des règles.

InterchangeRuleTiming
Élément à l’intérieur de la TimetableFrame, permettant de définir les conditions temporelles pour des changements planifiés entre différents ServiceJourneys. Il détermine le temps nécessaire ou autorisé pour une correspondance – par exemple les temps d’attente minimaux ou maximaux entre une course d’apport et une course de distribution à un point d’arrêt commun (ScheduledStopPoint).

Caractéristiques du profil suisse

La Suisse utilise un profil NeTEx national basé sur le standard européen mais adapté aux exigences spécifiques des données suisses sur le trafic.

  • Le profil est documenté en allemand et est basé sur ce que l’on appelle des «appels», c’est-à-dire des exigences de données spécifiques.
  • Une version française est prévue et pourra être traduite par une machine afin de tenir compte du multilinguisme de la Suisse.
  • Il est exporté deux fois par semaine via la plate-forme opentransportdata.swiss et inclut tous les transports publics de Suisse pour l’année d’horaire concernée.
  • En raison du volume de données, les exportations sont divisées en plusieurs fichiers, p. ex. par TimetableFrame, ServiceFrame, SiteFrame, etc. afin de faciliter le traitement

Transport à la demande

Pour le transport à la demande (TAD), il existe des concepts spécifiques qui sont également pris en compte dans le profil suisse. Une offre à la demande est un service pour lequel le voyageur commande un trajet par le biais d’une procédure de réservation, souvent indépendamment d’arrêts fixes ou d’horaires. Il s’agit de trajets collectifs commandés lors desquels plusieurs personnes ayant des besoins de transport similaires sont transportées ensemble. Retrouvez de plus amples informations sur le thème des TAD sur tp-info: Transport à la demande (bus sur appel). Il existe également un concept spécialisé de transport à la demande pour les transports publics suisses: https://www.oev-info.ch/sites/default/files/2023-04/fachkonzept_on-demand_v2.0.pdf.pdf

Un aperçu du TAD sur opentransportdata.swiss se trouve dans le Cookbook sous NeTEx – Transports à la demande.

Processus d’importation et d’exportation NeTEx

Frame Brève définition
TimetableFrame Contient la planification temporelle des trajets (VehicleJourneys), y c. les arrêts et les horaires.
ServiceFrame Il décrit les aspects opérationnels des lignes et des trajets, p. ex. JourneyPatterns et Routes.
Cadre Site Définit les lieux géographiques tels que les arrêts, les gares ou les points d’accès.
Cadre Ressource Comprend les ressources telles que les véhicules, le personnel ou les unités opérationnelles.
ServiceCalendarFrame Définit la validité des courses, p. ex. les jours civils, les périodes et les exceptions.
Commonframe Contient des éléments utilisés en commun comme des organisations, des codes, des tarifs ou des références.
Cadre d’accessibilité Décrit les propriétés accessibles des arrêts, des véhicules et des services.
FareFrame Comprend les informations tarifaires, les règles de prix et les types de billets.

Exemples de données

Exemple de données NeTex XML avec les frames ci-dessus: https://github.com/user-attachments/files/18201746/swiss_mikro.zip

Composants typiques dans le nom de fichier:

Élément Description
Module p. ex. Timetable, FareFrame, ServiceFrame
Région p. ex. CH, ZH, BE (ISO ou sigles internes)
Version p. ex. v1.0, v2.3
Date Format: AAAAMMJJ
Type Facultatif: p. ex. Full, Delta, Test, Export

Validation et dépannage des données NeTex

Les données NeTEx contiennent de nombreuses lignes XML et peuvent également paraître confuses. Il existe différents outils gratuits à cet effet. Les plus populaires sont:

Applications de validation:

  • Netex Validator (https://github.com/entur/netex-validator-java) d’Entur est une bibliothèque de validation basée sur Java spécialement développée pour la vérification des blocs de données NeTEx – en particulier dans le contexte du profil Nordic NeTEx, utilisé en Norvège et dans d’autres pays scandinaves.
  • XMLSpy est un outil de développement et d’éditeur XML payant d’Altova qui peut être utilisé pour valider les données NeTEx. La validation s’effectue à l’aide des fichiers de schéma XML (XSD) associés, qui définissent la structure et les règles des données NeTEx.

Recommandations relatives aux outils et workflows

Conversion et traitement

Outil. Finalité Source
MMTIS/Badger Convertit GTFS → NeTEx EPIPNeTEx EPIP → GTFS GitHub – MMTIS/badger: Conversions de l’horaire
GTFS2NeTEx Converter Convertit GTFS → NeTEx Portail Europe interopérable
Damu Convertit NeTEx → GTFS GitHub – entur/damu
geOps GTFS Feed Conversion GTFS quotidienne à partir de HRDF Flux GTFS geOps

FAQ.

Pourquoi existe-t-il autant de formats différents pour les données de transport?

Des besoins et des cas d’usage variés:

  • GTFS (General Transit Feed Specification): Simple, largement utilisé, idéal pour les applications d’horaire et de routage.
  • NeTEx (Network Timetable Exchange): Plus complexe et détaillé pour une modélisation approfondie du réseau et une interopérabilité européenne.
  • HRDF (Hafas Raw Data Format): Propriétaire, très détaillé, diffusé notamment en Suisse et en Allemagne.
  • Transmodel: Un modèle conceptuel sur lequel NeTEx est basé pour la planification, l’exploitation et l’analyse.

Chaque format a été développé à des fins spécifiques, par exemple GTFS pour Google Maps, NeTEx pour l’intégration des données au niveau européen ou HRDF pour les systèmes internes. Le développement technologique des données de transport joue également un rôle très important. Les formats plus anciens, comme HRDF, se basent sur du texte et sont difficiles à valider. Les formats plus récents, comme NeTEx, sont basés sur XML et permettent des données structurées, lisibles par machine, qui peuvent être traitées plus facilement de manière automatisée.

Les structures de données sont-elles explicites?

NeTEx s’appuie sur un modèle de données très détaillé (Transmodel), ce qui entraîne une courbe d’apprentissage abrupte. La structure est modulaire et l’imbrication profonde, ce qui complique le traitement sans outils spécialisés.

#AutoTranslate