Indice della materia

Ricerca nella pagina

NeTEx

Descrizione breve

Network Timetable Exchange (NeTEx) è lo standard dell’UE per i dati d’orario ed è stato sviluppato dall’European Committee for Standardization (CEE). Esso si basa sul Transmodel, il modello di dati di riferimento europeo per i trasporti pubblici.

Questa pagina del cookbook mette in evidenza e spiega le differenze e le peculiarità dell’implementazione svizzera di NeTex rispetto ad altri Paesi dell’UE.

Accesso ai dati

Descrizione del funzionamento

Il Network Timetable Exchange (NeTEx) crea una piattaforma uniforme per lo scambio dei dati sul traffico necessari per l’elaborazione dell’orario di treno, autobus, funivie, battelli nonché degli operatori locali di altre forme di mobilità, come biciclette e monopattini elettrici.

Il gruppo NeTEx (dati aggiornati al 2025) è formato da 12 Paesi che utilizzano attivamente questo formato e da altri 5 Paesi che si trovano nella fase di implementazione. Il mercato continua a crescere, anche oltre i confini europei, come dimostra l’esempio dello stato australiano di Victoria.

Lo standard di dati NeTEx riveste grande importanza per la Svizzera per consentire lo scambio efficiente dei dati relativi all’orario tra le imprese di trasporto internazionali. In questo modo è possibile offrire ai clienti finali un orario affidabile e senza interruzioni da un punto A a un punto B: Se ad esempio una persona guarda l’orario per un collegamento ferroviario da Zurigo a Lione (F), sono inclusi tutti i collegamenti e i cambi in entrambi i Paesi.

Oltre a NeTEx sono disponibili anche altri formati di dati relativi all’orario, come HRDF o GTFS.

GTFS (General Transit Feed Specification)

  • Origine: Sviluppato da Google in collaborazione con TriMet (Portland, USA), nel frattempo sviluppato da MobilityData.
  • Formato: una raccolta di file CSV (testo) raggruppati in un archivio ZIP.
  • Struttura: Formato tabellare semplice con file predefiniti come stops.txt, routes.txt, trips.txt, stop_times.txt ecc.
  • Argomento principale: Ampia diffusione per informazioni sull’orario, informazioni in tempo reale e portali open data.

Informazioni dettagliate su GTFS nel Cookbook GTFS.

HRDF (HAFAS Raw Data Format)

  • Origine: Sviluppato da HaCon, un’azienda tedesca (oggi parte di Siemens).
  • Formato: Formato proprietario, binario o basato su testo, utilizzato internamente nel sistema HAFAS di HaCon.
  • Struttura: Fortemente ottimizzato in termini di prestazioni, ma difficilmente leggibile dalle persone e non documentato pubblicamente.
  • Argomento principale: Impiegato principalmente nei Paesi di lingua tedesca (ad es. Deutsche Bahn, FFS) per i sistemi interni di pianificazione e orario.

Informazioni dettagliate su HRDF nel Cookbook HRDF.

Descrizione tecnica

Struttura e denominazione dei file

I file NeTEx devono essere denominati in modo chiaro, coerente e leggibile da una macchina. Uno schema tipico potrebbe essere questo:

[Modulo]_[Regione]_[Versione]_[Data]_[Tipo].xml

  • Timetable_CH_2025_v1.2_20250801.xml – Dati dell’orario per la Svizzera, versione 1.2 redatti il 1° agosto 2025
  • FareFrame_ZH_v3.0_20250715.xml – Dati tariffari per Zurigo, versione 3.0
  • ServiceFrame_BE_v2.1_20250820.xml – Informazioni su linee e servizi per Berna

Fondamenti di NeTEx

NeTEx utilizza uno schema XML modulare basato sul Transmodel. Definisce modelli di dati astratti per diversi settori del trasporto pubblico, come fermate, linee, orari, tariffe e dati d’esercizio. Gli elementi più importanti del NeTEx XML sono i frame. Ogni frame contiene informazioni tecniche specifiche sulla formazione di un mezzo di trasporto.

Segue una breve descrizione dei frame con le classi principali. Per informazioni più dettagliate consultare il link seguente: NeTEx – Transmodel (https://transmodel-cen.eu/index.php/netex/).

Frame Default

I FrameDefaults sono un meccanismo per definire valori predefiniti, come il fuso orario, l’ora locale, la selezione della lingua.

CompositeFrame

Un CompositeFrame raggruppa più frame di dati tematicamente correlati in un unico file, ad es. FrameDefaults, ResourceFrame, SiteFrame, ServiceFrame, ServiceCalendarFrame, TimetableFrame. Utile per la distribuzione strutturata di set di dati complessi in cui sono necessari diversi aspetti del trasporto pubblico.

Resource Frame

ResponsibilityRoleAssignment

Collega un’organizzazione (FFS, DB, BLS ecc.) a un determinato ruolo in relazione a un altro elemento (ad es. una linea, un orario, un servizio).

TypeOfProductCategory

Elemento classificativo che descrive il tipo di prodotto (ad es. tipo di treno, offerta di autobus, classe di servizio).

Tipo di nota

Definisce i tipi di nota o le offerte che vengono utilizzati nell’informazione ai viaggiatori. Si tratta di una definizione del tipo cui fanno riferimento gli elementi concreti della nota

Site frame

TopographicPlace

Serve a classificare geograficamente le fermate e altre ubicazioni. In Svizzera si utilizza perlopiù il Cantone (non il Comune) come TopographicPlace, in modo tale da garantire una struttura unitaria e chiara.

Stop place

Descrive diversi aspetti di un punto di accesso fisico al traffico, come ad esempio una fermata o una stazione; in Svizzera si riferisce a un Cantone o a una regione.

Quay

Fa sempre parte di uno StopPlace. Si tratta di un’installazione come un marciapiede, una posizione di fermata o un passerella in cui i viaggiatori hanno accesso a mezzi di trasporto pubblici, taxi, automobili o altri mezzi di trasporto. Un molo può servire uno o più posti di fermata del veicolo ed essere collegato a uno o più punti di fermata.

Service Frame

Direction

Una Direction descrive una direzione di marcia all’interno di una linea, ad esempio «Direzione Stazione» o «Direzione Aeroporto». Aiuta a distinguere i tragitti all’interno di una linea, ad esempio andata e ritorno.

Line

Rappresenta una linea di trasporto pubblico, ad esempio una linea di autobus, tram o treno, ad esempio «linea di autobus 10» o «S-Bahn S3». Raggruppa i viaggi che circolano sotto lo stesso numero o nome di linea.

DestinationDisplays

Indicatore visivo di destinazione che indica ai viaggiatori dove sta andando un veicolo. È spesso associato a un Service Journey o Vehicle Journey ed è particolarmente rilevante per le informazioni ai viaggiatori, come autobus, treni o display elettronici.

ScheduledStopPoint

Un concetto chiave. Si tratta del «punto» utilizzato nell’orario in cui si ferma un servizio. Uno ScheduledStopPoint può riferirsi a un molo (ad es. marciapiede, posizione di fermata) o solo a uno StopPlace (ad es. stazione, fermata). Il livello gerarchico non è determinato dall’elemento (vedere PassengerStopAssignment).

PassengerStopAssignment

L’elemento principale che descrive l’attribuzione. Indica la sequenza con la quale questo punto di fermata appare all’interno di un itinerario o di un Journey Pattern. Esso rimanda al punto di fermata logico nell’orario, lo «ScheduledStopPointRef», che a «StopPlaceRef» si riferisce al luogo fisico (p. es. una fermata).

Notice

Definisce elementi di testo riutilizzabili che possono essere utilizzati come note a piè di pagina negli orari, annunci o altre comunicazioni. Le NOTIZIE vengono assegnate ad altri elementi tramite un NOTICE ASSIGNMENT. Possono essere classificate con un TYPE OF NOTICE.

L’elemento funge da contenitore per collegare in modo mirato indicazioni o comunicazioni predefinite, come informazioni ai viaggiatori, indicazioni d’esercizio o avvisi di servizio, a determinati oggetti dei dati dell’orario. Fra questi rientrano:

  • Service Journey (corse concrete)
  • JourneyParts (sezioni parziali di una corsa)
  • Train Block (rotazioni di treni)
  • StopPoint (punti di fermata)
  • OperatingDays (giorni d’esercizio)

ServiceCalendarFrame

AvailabilityCondition

Una specializzazione della VALIDITY CONDITION per definire condizioni temporali precise. Ad esempio, un ingresso di uno StopPlace può essere valido (esistente), ma non sempre disponibile (ad es. chiuso tra le 21.00 e le 6.00). Sia VALIDITY CONDITION che AVAILABILITY CONDITION possono essere collegate allo stesso oggetto

Calendario servizi

L’offerta di trasporto di un’impresa di trasporto pubblico viene strutturata per soddisfare le diverse domande. Per semplificare la pianificazione dell’offerta, quasi tutti gli operatori redigono il proprio piano di produzione sulla base di una classificazione per tipi di giorno, che riassume l’andamento della domanda o altre caratteristiche, ad esempio giorno feriale, fine settimana, vacanze scolastiche, giorno di mercato ecc. Gli orari pianificati a lungo termine vengono creati tramite il cosiddetto calendario del traffico, in cui i giorni civili vengono classificati come tipi di giorno specifici (DAY TYPE).

DayTypes

Gli orari vengono creati tramite il cosiddetto calendario del traffico, in cui i giorni civili vengono classificati come specifici tipi di giorno (DAY TYPE).

Timetable Frame

Service Journey

È una corsa del veicolo che consente ai viaggiatori di salire e scendere alle fermate. Descrive la prestazione di trasporto tra un punto iniziale e finale così come viene comunicata pubblicamente.

«DestinationDisplayRef» (Riferimento display di destinazione)
Descrive l’indicatore visivo di destinazione collegato a un processo di fermata (chiamata). È importante per l’informazione ai viaggiatori, ad es. sugli indicatori dei veicoli o negli orari elettronici.

NoticeAssignments
Viene utilizzato all’interno del Service Journey. In questo caso la comunicazione vale per l’intera corsa. Se una comunicazione è valida solo per una parte del Service Journey, l’assegnazione avviene in tutti i relativi elementi Call.

Chiamata
Rappresenta una vista che raggruppa i dati sul singolo sopralluogo alla fermata. Nelle istanze di ServiceJourney scambiate tramite NeTEx possono essere contenute raccolte ordinate di elementi Call.

Request Stop
Contrassegno per le fermate facoltative («fermata su richiesta»). Viene spesso utilizzata nelle aree rurali o nel traffico on demand. Può essere adeguatamente contrassegnata nei sistemi d’informazione ai viaggiatori (per es. con un simbolo o un testo informativo). Importante per il calcolo del tempo di percorrenza, poiché eventualmente si saltano le fermate facoltative e si riduce così il tempo di viaggio.

StopUse
Un attributo che indica la funzione svolta da un punto di fermata all’interno di un VehicleJourney. Descrive se la fermata per:

  • Salita (boarding),
  • Uscita (alighting),
  • Entrambi (both),
  • o nessuna di queste funzioni (pass-through)

viene utilizzato.

NumeroTrain

I TrainNumber sono attualmente composti al massimo da sei cifre. In linea di massima, un Service Journey può contenere più numeri di treno diversi, mentre una JourneyPart rimanda rispettivamente solo a un singolo TrainNumber. In Svizzera non vi è alcuna differenza tra il TrainNumber pubblicato e quello produttivo.

Facility Set

Elemento strutturato utilizzato per assegnare i dispositivi a un Service Journey o a una Journey Part. SKI classifica tali dispositivi nei seguenti gruppi:

  • Strutture ricettive
  • Strutture di ristorazione
  • Classi tariffarie
  • Strutture di prenotazione per gruppi
  • Strutture per il trasporto bagagli
  • Dispositivi di mobilità
  • Dispositivi per la riduzione dei guasti
  • Dispositivi di comunicazione per i passeggeri
  • Servizi di prenotazione
  • Dispositivi d’emissione biglietti
  • Tariffe del treno UIC

Tale classificazione consente una descrizione standardizzata dei servizi disponibili lungo un viaggio. Se necessario, l’elenco può essere ampliato, purché la rispettiva categoria sia definita nelle specifiche NeTEx.

Journey meeting

Descrive la possibilità di pianificare gli orari tenendo conto delle diverse opzioni di cambio:

  • Cambio a un altro servizio di cui si conosce solo l’orario di arrivo o di partenza.
  • Generali: un servizio il cui orario si basa sull’ora stabilita di un evento esterno che alimenta o è alimentato da tale servizio.
  • Organizzazione di un punto di ritrovo (hub) tra più servizi all’interno di una fascia temporale definita; si tratta di una specifica semplificata di più cambi. Se necessario, questo può essere descritto nel dettaglio con più INTERCHANGE RULE o SERVICE JOURNEY INTERCHANGE.
  • Definizione di un punto di ritrovo (ora e luogo) per ogni corsa che può raggiungere questo appuntamento.

InterchangeRule 

Regolamento che permette di documentare nell’orario i cambi pianificati senza dover indicare i dettagli esatti di entrambe le Service Journey coinvolte. Serve a definire e strutturare le potenziali coincidenze per il cambio tra le corse, soprattutto se queste non sono completamente specificate.

InterchangeRuleParameter
Elemento all’interno del TimetableFrame per la specificazione di parametri per i cambi pianificati tra diversi Service Journey. Definisce le condizioni e le restrizioni alle quali un cambio viene considerato valido, ad es. del mezzo di trasporto (Mode), della linea (Line) o della direzione di marcia (Direction).
Questi parametri consentono una modellazione flessibile delle coincidenze per il cambio senza la necessità di fornire i dettagli completi delle corse interessate. Sono particolarmente utili quando i cambi devono essere pianificati in modo dinamico o sulla base di regole.

InterchangeRuleTiming
Elemento all’interno del TimetableFrame per definire le condizioni temporali per i cambi pianificati tra diversi Service Journey. Definisce il tempo necessario o consentito per un cambio, ad esempio i tempi di attesa minimi o massimi tra una corsa di apportatore e una corsa di distribuzione presso un punto di fermata comune (ScheduledStopPoint).

Proprietà del profilo svizzero

La Svizzera utilizza un profilo NeTEx nazionale, che si basa sullo standard europeo, ma che risponde alle esigenze specifiche dei dati sul traffico svizzeri.

  • Il profilo è documentato in lingua tedesca e si basa sulle cosiddette «call», ossia su specifici requisiti di dati.
  • È in programma una versione francese, che può essere tradotta automaticamente, per tenere conto del multilinguismo della Svizzera.
  • L’esportazione viene effettuata due volte alla settimana attraverso la piattaforma opentransportdata.swiss e comprende tutti i mezzi di trasporto pubblici della Svizzera per il rispettivo anno di orario.
  • A causa della quantità di dati, le esportazioni vengono suddivise in diversi file, ad es. per TimetableFrame, ServiceFrame, SiteFrame ecc. per facilitare l’elaborazione

Traffico on demand

Per il trasporto on demand (ODV) esistono concetti specifici che vengono considerati anche nel profilo svizzero. Un’offerta on demand è un servizio con il quale il viaggiatore richiede un viaggio attraverso una procedura di prenotazione, spesso indipendentemente da fermate o orari fissi. Si tratta di corse collettive ordinate in cui diversi passeggeri vengono trasportati insieme con esigenze di trasporto simili. Ulteriori informazioni sull’ODV sono disponibili su Info TP: Trasporto on demand (autobus a chiamata). Esiste inoltre un concetto specialistico Trasporto on demand per i trasporti pubblici svizzeri: https://www.oev-info.ch/sites/default/files/2023-04/fachkonzept_on-demand_v2.0.pdf.pdf

Una panoramica dell’ODV su opentransportdata.swiss si trova nel Cookbook alla voce NeTEx: trasporti on demand.

Processi di importazione ed esportazione NeTEx

Frame Definizione breve
Timetable Frame Contiene la pianificazione temporale delle corse (VehicleJourney) incl. punti di fermata e orari.
Service Frame Descrive gli aspetti operativi di linee e corse, ad es. JourneyPattern e Routes.
Site frame Definisce luoghi geografici come fermate, stazioni o punti di accesso.
Resource Frame Contiene risorse come veicoli, personale o unità operative.
ServiceCalendarFrame Definisce la validità delle corse, ad es. giorni civili, periodi ed eccezioni.
Common Frame Comprende elementi condivisi come organizzazioni, codici, tariffe o riferimenti.
Accessibility Frame Descrive le caratteristiche di accessibilità delle fermate, dei veicoli e dei servizi.
Fareframe Contiene informazioni tariffarie, regole di prezzo e tipi di biglietti.

Dati esemplificativi

Un esempio di dati XML NeTex con i frame sopra menzionati: https://github.com/user-attachments/files/18201746/swiss_mikro.zip

Componenti tipici del nome del file:

Elemento Descrizione
Modulo ad es. Timetable, FareFrame, ServiceFrame
Regione ad es. CH, ZH, BE (ISO o sigla interna)
Versione ad es. v1.0, v 2.3
Data Formato: AAAAMMGG
Tipo Opzionale: ad es. Full, Delta, Test, Export

Convalida ed eliminazione di errori per i dati NeTex

I dati di NeTEx contengono numerose righe XML e possono anche sembrare confusi e ci sono diversi strumenti gratuiti per farlo. I più popolari sono:

Applicazioni di convalida:

  • Il Netex Validator (https://github.com/entur/netex-validator-java) di Entur è una libreria di convalida basata su Java specificamente progettata per testare i set di dati NeTEx, in particolare nel contesto del profilo Nordic NeTEx utilizzato in Norvegia e in altri paesi scandinavi.
  • XMLSpy è uno strumento di sviluppo e editor XML a pagamento di Altova che può essere utilizzato per convalidare i dati NeTEx. La convalida viene eseguita utilizzando i relativi file dello schema XML (XSD) che definiscono la struttura e le regole dei dati NeTEx.

Raccomandazioni per tool e workflow

Conversione ed elaborazione

Tool Scopo Fonte
MMTIS/Badger Converte GTFS → NeTEx EPIPNeTEx EPIP → GTFS GitHub – MMTIS/badger: Timetable conversions
GTFS2NeTEx Converter Converte GTFS → NeTEx Portale Interoperable Europe
Damu Converte NeTEx → GTFS GitHub: entur/damu
geOps GTFS Feed Conversione GTFS giornaliera da HRDF feed GTFS geOps

FAQ

Perché esistono così tanti formati diversi per i dati di trasporto?

Esigenze e casi applicativi diversi:

  • GTFS (General Transit Feed Specification): Semplice, ampiamente utilizzato, ideale per le app per gli orari e il routing.
  • NeTEx (Network Timetable Exchange): Più complesso e dettagliato per una modellazione di rete approfondita e per l’interoperabilità europea.
  • HRDF (Hafas Raw Data Format): Proprietario, molto dettagliato, diffuso soprattutto in Svizzera e Germania.
  • Transmodel: Un modello concettuale sul quale si basa NeTEx – per la pianificazione, l’esercizio e l’analisi.

Ogni formato è stato sviluppato per scopi specifici, ad esempio GTFS per Google Maps, NeTEx per l’integrazione dei dati a livello europeo, HRDF per i sistemi interni. Anche lo sviluppo tecnologico dei dati di trasporto gioca un ruolo molto importante. I formati più vecchi, come l’HRDF, sono basati su testo e difficili da convalidare. I formati più recenti, come NeTEx, si basano sull’XML e consentono dati strutturati e leggibili dai dispositivi, che possono essere elaborati più facilmente in modo automatizzato.

Le strutture dei dati sono autoesplicative?

NeTEx si basa su un modello di dati molto dettagliato (transmodel), che comporta una curva di apprendimento ripida. La struttura è modulare e profondamente annidata, il che rende difficile l’elaborazione senza strumenti specializzati.

#AutoTranslate