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 repose sur Transmodel, le modèle européen de données de référence pour les transports publics.

Cette page du Cookbook 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 unique d’échange de données de trafic pour l’établissement des horaires pour les trains, les bus, les téléphériques, les bateaux et les prestataires locaux d’autres formes de mobilité, comme les vélos et les trottinettes électriques.

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

Pour la Suisse, le standard de données NeTEx est très important pour permettre un échange efficace des données d’horaire entre les entreprises de transport internationales. Il est ainsi possible de proposer aux clients finaux 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 correspondances et tous les changements dans les deux pays sont inclus.

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

GTFS (General Transit Feed Specification)

  • Origine: Développé par Google en collaboration avec TriMet (Portland, États-Unis), entre-temps développé par MobilityData.
  • Format: Une collection 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.
  • Thème clé: Largement utilisé pour les renseignements sur les horaires, les informations en temps réel et les portails Open Data.

Des informations détaillées sur GTFS sont disponibles dans Cookbook GTFS.

HRDF (HAFAS Raw Data Format)

  • Origine: Développé par HaCon, une société allemande (aujourd’hui partie de Siemens).
  • Format: Format propriétaire, binaire ou textuel utilisé en interne dans le système HAFAS de HaCon.
  • Structure: Fortement optimisé pour la performance, mais difficile à lire et non documenté publiquement.
  • Thème clé: Principalement utilisé dans les pays germanophones (p. ex. Deutsche Bahn, CFF) pour les systèmes internes de planification et d’horaire.

Des informations détaillées sur HRDF sont disponibles dans Cookbook HRDF.

Description technique

Structure et dénomination des fichiers

Les fichiers NeTEx doivent être nommés de manière claire, cohérente et lisible par machine. Un schéma type 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, établie 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 trames. Chaque trame contient des informations techniques sur la formation d’un moyen de transport.

Voici une brève description des trames 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

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

Composite Frame

Un CompositeFrame regroupe plusieurs trames de données thématiques connexes 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.

Ressource Frame

ResponsibilityRoleAssignment

Relie une organisation (CFF, DB, BLS, etc.) à un rôle spécifique par rapport à un autre élément (p. ex. une ligne, un horaire, un service).

TypeOfProductCategory

Élément de classification décrivant le type de produit (p. ex. type de train, offre de bus, classe de service).

TypeOfNotice

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

Site Frame

TopographicPlace

Permet d’établir la classification géographique des arrêts et autres sites. En Suisse, le canton (et non la commune) est généralement utilisé comme TopographicPlace afin de garantir une structure uniforme et claire.

StopPlace

Décrit différents aspectsd’un point d’accès physique au trafic, comme un arrêt ou une gare; en Suisse, il se rapporte à un canton ou à une région.

Quai

Fait toujours partie d’un StopPlace. Il s’agit d’une installation telle qu’un quai, un arrêt ou un ponton 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 de véhicules et être relié à un ou plusieurs arrêts.

Service Frame

Direction

Une direction décrit un sens de déplacement à l’intérieur d’une ligne, par exemple «direction gare» ou «direction aéroport». Elle permet de distinguer les trajets à l’intérieur d’une ligne, par exemple un aller et un retour.

Line

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

DestinationDisplays

Indicateur visuel de destination indiquant aux voyageurs la destination d’un véhicule. Souvent associé à un ServiceJourney ou un VehicleJourney, il 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 faire référence soit à un quai (p. ex. quai, position d’arrêt), soit uniquement à 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’attribution. Indique l’ordre dans lequel ce point d’arrêt apparaît au sein d’un itinéraire ou d’un JourneyPattern. Renvoie au point d’arrêt logique dans l’horaire, le «ScheduledStopPointRef», qui renvoie à la «StopPlaceRef» du lieu 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 d’horaires, d’annonces ou d’autres messages. Les NOTICES sont affectées à d’autres éléments par le biais d’un NOTICE ASSIGNMENT. Elles peuvent être classées avec un TYPE OF NOTICE.

L’élément sert de conteneur pour relier de manière ciblée des indications ou des messages prédéfinis (p. ex. des informations aux voyageurs, des indications d’exploitation ou des annonces de service) à des objets spécifiques des données d’horaire. Il s’agit notamment des éléments suivants:

  • 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

Spécialisation de VALIDITY CONDITION permettant de définir des conditions temporelles précises. Par exemple, une entrée d’un StopPlace peut être valide (elle existe) mais ne pas être 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

ServiceCalendar

L’offre de transport d’une entreprise de transport public est conçue pour répondre aux différentes demandes. Afin de simplifier la planification de l’offre, presque tous les exploitants établissent leur plan de production à l’aide d’une classification par types de jours qui résume le comportement de la demande ou d’autres caractéristiques, par exemple jour ouvrable, week-end, vacances scolaires, jour de marché, etc. Les horaires planifiés à long terme sont établis à l’aide du «calendrier de trafic», dans lequel les jours calendaires sont classés en types de jours spécifiques (DAY TYPEs).

DayTypes

Les horaires sont créés à partir du calendrier de trafic, dans lequel les jours calendaires sont classés en types de jours spécifiques (DAY TYPEs).

TimetableFrame

Service Journey

Parcours de véhicules permettant aux voyageurs de monter ou descendre aux arrêts. Elle décrit la prestation de transport communiquée publiquement entre un point de départ et un point d’arrivée.

DestinationDisplayRef
Décrit l’indicateur visuel de la destination lié à une procédure d’arrêt (Call). Il est important pour l’information aux voyageurs, p. ex. sur les systèmes d’affichage des véhicules ou dans les horaires électroniques.

NoticeAssignments
Est utilisé dans le cadre du ServiceJourney. Dans ce cas, la communication s’applique à l’ensemble du trajet. Si une communication n’est valable que pour une partie du ServiceJourney, elle est attribuée dans tous les éléments Call concernés.

Appel
Représente une vue regroupant les données relatives à une visite d’arrêt individuelle. Des ensembles ordonnés d’éléments d’appel peuvent être contenus dans des instances de ServiceJourney, qui sont échangées via NeTEx.

RequestStop
Identification des arrêts facultatifs («arrêt sur demande»). Souvent utilisé dans les zones rurales ou pour les transports à la demande. Il peut être indiqué en conséquence dans les systèmes d’information des voyageurs (p. ex. par un symbole ou un texte d’indication). Important pour le calcul du temps de parcours, car les arrêts facultatifs peuvent être ignorés et le temps de trajet est ainsi réduit.

StopUse
Attribut qui indique la fonction remplie par un point d’arrêt au sein d’un VehicleJourney. Il décrit si l’arrêt pour:

  • Accès (embarquement),
  • Descente (alighting),
  • les deux (both),
  • ou aucune de ces fonctions (pass-through)

est utilisé.

TrainNumber

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

FacilitySet

É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
  • Installations de restauration
  • Classes tarifaires
  • Dispositifs de réservation de groupe
  • Installations de transport de bagages
  • Équipements de mobilité
  • Dispositifs destinés à atténuer les dérangements
  • Équipements de communication pour les voyageurs
  • Dispositifs de réservation de services
  • Dispositifs d’émission de billets
  • Tarifs de train UIC

Cette classification permet une description standardisée des services disponibles le long d’un voyage. La liste peut être étendue si nécessaire, si la catégorie concernée est 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 changement:

  • Changement pour un autre service où 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 fixée d’un évènement externe qui alimente ou est alimenté par ce service.
  • Organisation d’un point de rencontre (hub) entre plusieurs services dans un créneau horaire défini; il s’agit d’une spécification simplifiée de plusieurs correspondances. Si nécessaire, cela peut être décrit en détail par plusieurs INTERCHANGE RULE ou SERVICE JOURNEY INTERCHANGE.
  • Définition d’un point de rencontre (heure et lieu) pour chaque trajet qui peut se rendre à ce rendez-vous.

InterchangeRule 

Réglementation permettant de documenter les correspondances planifiées dans l’horaire sans devoir détailler les deux ServiceJourneys impliqués. Elle sert à définir et à structurer de potentielles correspondances entre les trajets, en particulier si celles-ci ne sont pas entièrement spécifiées.

InterchangeRuleParameter
Élément du TimetableFrame servant à spécifier des paramètres pour les correspondances planifiées entre différents ServiceJourneys. Il définit les conditions et restrictions sous lesquelles un changement est considéré comme valable, par exemple en ce qui concerne le mode de transport (Mode), la ligne (Line) ou le sens de la marche (Direction).
Ces paramètres permettent de modéliser de manière flexible les correspondances sans avoir à fournir tous les détails des trajets concernés. Ils sont particulièrement utiles lorsque la planification des correspondances doit être dynamique ou basée sur des règles.

Règle d’échangeTiming
Élément du TimetableFrame servant à définir les conditions temporelles pour les changements planifiés entre différents ServiceJourneys. Il définit le temps de correspondance nécessaire ou autorisé, p. ex. temps d’attente minimal ou maximal entre un trajet d’apport et un trajet de distribution à un arrêt commun (ScheduledStopPoint).

Caractéristiques du profil suisse

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

  • Le profil est documenté en allemand et repose sur des «calls», c’est-à-dire des exigences spécifiques en matière de données.
  • Une version française est prévue et pourra faire l’objet d’une traduction automatique afin de tenir compte du multilinguisme de la Suisse.
  • Il est exporté deux fois par semaine via la plate-forme opentransportdata.swiss et comprend tous les moyens de transports publics de Suisse pour l’année d’horaire correspondante.
  • En raison de la quantité de données, les exportations sont divisées en plusieurs fichiers, p. ex. TimetableFrame, ServiceFrame, SiteFrame, etc. pour simplifier le traitement

Transport à la demande

Il existe des concepts spécialisés pour le transport à la demande (TAD), qui sont également pris en compte dans le profil suisse. Une offre à la demande est un service pour lequel la passagère ou le passager commande un trajet via un processus de réservation, souvent indépendamment d’arrêts fixes ou d’horaires. Il s’agit de courses collectives commandées, dans le cadre desquelles plusieurs voyageuses et voyageurs ayant des besoins de transport similaires sont transportés ensemble. De plus amples informations sur le TAD sont disponibles sur la page Info transports publics: Transport à la demande (bus à la demande). Il existe en outre un concept spécialisé 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 est disponible dans le Cookbook sous NeTEx – Transports à la demande.

Processus d’importation et d’exportation NeTEx

Frame Définition succincte
TimetableFrame Comprend la planification temporelle des trajets (VehicleJourneys), y c. les arrêts et les heures.
Service Frame Décrit les aspects opérationnels des lignes et des courses, p. ex. JourneyPatterns et Routes.
Site Frame Définit des lieux géographiques tels que les arrêts, les gares ou les points d’accès.
Ressource Frame Contient des ressources telles que les véhicules, le personnel ou les unités d’exploitation.
ServiceCalendarFrame Définit la validité des trajets, p. ex. jours civils, périodes et exceptions.
Common Frame Contient des éléments partagés tels que des organisations, des codes, des tarifs ou des références.
Accessibility Frame Décrit les caractéristiques d’accessibilité des arrêts, véhicules et services.
FareFrame Contient des informations tarifaires, des règles tarifaires et des types de billets.

Exemples de données

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

Composants typiques dans le nom de fichier:

Composante Description
Module p. ex. Timetable, FareFrame, ServiceFrame
Région p. ex. CH, ZH, BE (ISO ou abréviation interne)
Version p. ex. v1.0, v2.3
Date Format: AAAAMMJJ
Type Facultatif: p. ex. Full, Delta, Test, Export

Validation et élimination des erreurs dans les données NeTex

Les données NeTEx contiennent de nombreuses lignes XML et peuvent aussi sembler confuses. Pour cela, il existe différents outils gratuits. Les plus populaires sont:

Applications de validation:

  • Le validateur Netex (https://github.com/entur/netex-validator-java) d’Entur est une bibliothèque de validation basée sur Java, spécialement conçue pour tester les ensembles 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 éditeur et outil de développement XML payant d’Altova qui peut être utilisé pour valider les données NeTEx. La validation est effectuée à 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 pour les outils et workflows

Conversion et traitement

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

FAQ.

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

Différents besoins et cas d’usage:

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

Chaque format a été développé à des fins spécifiques, p. ex. GTFS pour Google Maps, NeTEx pour l’intégration des données à l’échelle de l’UE, 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 sont basés sur du texte et difficiles à valider. Les formats plus récents comme NeTEx reposent sur XML et permettent des données structurées, lisibles par une machine, qui peuvent être traitées plus facilement de manière automatisée.

Les structures de données sont-elles explicites?

NeTEx repose sur un modèle de données très détaillé (Transmodel), ce qui entraîne une courbe d’apprentissage raide. La structure est modulaire et fortement imbriquée, ce qui rend le traitement difficile sans outils spécialisés.

#AutoTranslate