Indice della materia

Ricerca nella pagina

NeTEx

Descrizione breve

Network Timetable Exchange (NeTEx) è lo standard dell’UE per i dati dell’orario, sviluppato dall’European Committee for Standardization (CEE), Che si basa sul Transmodel, il modello di dati di riferimento europeo per il trasporto pubblico.

Questa pagina del cookbook evidenzia e spiega le differenze e le particolarità dell’implementazione di NeTex in Svizzera rispetto ad altri Paesi dell’UE.

Accesso ai dati

Descrizione del funzionamento

Il Network Timetable Exchange (NeTEx) crea una piattaforma unitaria per lo scambio di dati sul traffico per la redazione degli orari di treni, autobus, funivie, battelli e operatori locali di altre forme di mobilità, quali biciclette e monopattini elettrici.

Il Gruppo NeTEx è composto (aggiornato al 2025) da 12 Paesi che utilizzano attivamente questo formato e da altri 5 Paesi che sono in 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 è di fondamentale importanza per la Svizzera per consentire uno scambio efficiente dei dati sull’orario tra le imprese di trasporto internazionali. Questo consente di offrire ai clienti finali un orario affidabile e senza soluzione di continuità da A a B: Se ad esempio una persona osserva l’orario per un collegamento ferroviario da Zurigo a Lione (F), il sistema include tutti i collegamenti e le coincidenze per entrambi i Paesi.

Oltre a NeTEx esistono anche altri formati per i dati dell’orario come HRDF o GTFS.

GTFS (General Transit Feed Specification)

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

Informazioni dettagliate su GTFS sono disponibili in Coachbook GTFS.

HRDF (formato Raw Data HAFAS)

  • Origine: Sviluppato da HaCon, un’azienda tedesca (oggi parte di Siemens).
  • Formato: formato proprietario, binario o testuale utilizzato internamente nel sistema HAFAS di HaCon.
  • Struttura: Fortemente ottimizzata in base alle prestazioni, ma difficilmente leggibile dal pubblico e non documentata pubblicamente.
  • Priorità: Impiegato principalmente nei Paesi di lingua tedesca (ad es. Deutsche Bahn, FFS) per i sistemi interni di pianificazione e orario.

Per informazioni dettagliate su HRDF consultare: Coachbook HRDF.

Descrizione tecnica

Struttura e denominazione dei file

I file NeTEx devono essere denominati in modo chiaro, coerente e leggibile dalla 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, creata il 1° agosto 2025
  • FareFrame_ZH_v3.0_20250715.xml – Dati tariffari per Zurigo, versione 3.0
  • ServiceFrame_BE_v2.1_20250820.xml – Informazioni sulla linea e sul servizio per Berna

Fondamenti di NeTEx

NeTEx utilizza uno schema XML modulare basato su Transmodel. Definisce modelli di dati astratti per diversi settori del trasporto pubblico (ad es. fermate, linee, orari, tariffe e dati d’esercizio). Gli elementi principali di NeTEx XML sono i frame. Ogni frame contiene informazioni specifiche per la formazione di un mezzo di trasporto.

Segue una breve descrizione dei frame con le classi principali. Informazioni più dettagliate sono disponibili al seguente link: NeTEx – Transmodel (https://transmodel-cen.eu/index.php/netex/).

FrameDefault

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

Composite Frame

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

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).

TypeOfNotice

Definisce i tipi di informazione o le offerte impiegati per le informazioni ai viaggiatori. È una definizione del tipo cui si fa riferimento da elementi Notice concreti

Site Frame

Topographic place

Serve a collocare geograficamente le fermate e altre sedi. In Svizzera viene solitamente utilizzato il Cantone (non il Comune) come TopographicPlace, per garantire una struttura uniforme e chiara.

Stop place

Descrive i diversi aspetti di unpunto di accesso fisico ai trasporti, come una fermata o una stazione; in Svizzera, si riferisce a un Cantone o a una regione.

Marciapiede

Appartiene sempre a uno StopPlace. È un dispositivo come un marciapiede, una fermata o un pontile che consente ai passeggeri di accedere ai trasporti pubblici, ai taxi, alle auto o ad altri mezzi di trasporto. Un molo può servire una o più fermate dei veicoli ed essere collegato a uno o più punti di fermata.

Service Frame

Direction

Una direzione indica una direzione all’interno di una linea, ad esempio «direzione stazione ferroviaria» o «direzione aeroporto». Aiuta a distinguere i viaggi all’interno di una linea, ad esempio andata e ritorno.

Line

Rappresenta una linea di trasporto nel trasporto pubblico, ad esempio una linea di autobus, tram o treno, ad esempio «linea 10» o «rete celere regionale S3». Raggruppa i viaggi che passano sotto lo stesso numero o denominazione di linea.

DestinationDisplays

Indicatore visivo della destinazione che comunica ai viaggiatori dove sta andando un veicolo. Spesso collegato a un Service Journey o a un VehicleJourney ed è particolarmente rilevante per le informazioni ai viaggiatori, ad es. su autobus, treni o display elettronici.

ScheduledStopPoint

Un concetto centrale. Si tratta del «punto» utilizzato nell’orario in cui un servizio si ferma. Uno ScheduledStopPoint può riferirsi a un marciapiede (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. Definisce la sequenza con cui compare tale punto di fermata all’interno di un itinerario o di un JourneyPattern. Si rimanda al punto di fermata logico nell’orario, lo «ScheduledStopPointRef», che si riferisce a «StopPlaceRef» al luogo fisico (ad es. una fermata).

Notice

Definisce elementi di testo riutilizzabili che possono essere usati come indicazioni, ad esempio come note a piè di pagina negli orari, come annunci o in altre comunicazioni. I NOTICES vengono assegnati ad altri elementi tramite un NOTICE ASSIGNMENT. Possono essere classificati con un TYPE OF NOTICE.

L’elemento funge da contenitore per collegare in modo mirato avvertenze o messaggi predefiniti, quali informazioni ai viaggiatori, avvertenze d’esercizio o annunci di servizio, con determinati oggetti presenti nei dati dell’orario. Fra questi si annoverano:

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

ServiceCalendarFrame

AvailabilityCondition

Una specializzazione della VALIDITY CONDITION per definire precise condizioni temporali. Ad esempio, un ingresso di uno StopPlace può essere valido (esiste) ma non essere disponibile in qualsiasi momento (es. chiuso tra le 21:00 e le 6:00). Sia VALIDITY CONDITION che AVAILABILITY CONDITION possono essere associate allo stesso oggetto

Calendario servizi

L’offerta di trasporto di un’impresa di trasporto pubblico viene strutturata in modo tale da soddisfare le diverse domande. Per semplificare la pianificazione dell’offerta, quasi tutti gli operatori elaborano il proprio piano di produzione sulla base di una classificazione per tipo di giorno che riassume il comportamento 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 della circolazione, in cui i giorni civili vengono classificati come tipi di giorno specifici (DAY TYPE).

Timetable Frame

Service Journey

Itinerario del veicolo sul quale i viaggiatori possono salire o scendere alle fermate. Descrive la prestazione di trasporto tra un punto di partenza e un punto di arrivo così come viene comunicata pubblicamente.

DestinationDisplayRif
Descrive l’indicatore visivo di destinazione associato a una procedura di arresto (call). È importante per l’informazione ai viaggiatori, ad es. sui display del veicolo o negli orari elettronici.

NoticeAssignment
Viene utilizzato all’interno del Service Journey. In questo caso, il messaggio vale per l’intero viaggio. Se una comunicazione è valida solo per una parte del Service Journey, l’assegnazione ha luogo in tutti gli elementi della chiamata interessati.

Call
La rappresenta una visualizzazione che raggruppa i dati per la singola visita di una fermata. Raccolte ordinate di elementi call possono essere incluse in istanze di Service Journey che vengono scambiate tramite NeTEx.

Request-Stop
Contrassegno per fermate facoltative («fermata su richiesta»). Spesso impiegato nelle aree rurali o nel trasporto on demand. Può essere opportunamente segnalato nei sistemi d’informazione ai viaggiatori (ad es. con un simbolo o un testo di avviso). È importante per il calcolo del tempo di percorrenza perché le fermate facoltative possono essere saltate e in questo modo riduce il tempo di viaggio.

Stop use
Un attributo che indica quale funzione svolge un punto di fermata all’interno di un VehicleJourney. Descrive se la fermata è prevista per:

  • Accesso (boarding),
  • Discesa (alighting)
  • entrambi (both),
  • o nessuna di queste funzioni (pass-through)

l’utilizzo.

Numero del treno

Al momento i TrainNumber sono composti da un massimo di sei cifre. In linea di massima, un Service Journey può contenere più numeri del treno diversi, mentre una JourneyPart prevede solo collegamenti a un singolo TrainNumber. In Svizzera non c’è alcuna differenza tra il TrainNumber pubblicato e quello produttivo.

Facility Set

Elemento strutturato che viene utilizzato per l’assegnazione di dispositivi a un Service Journey o a una JourneyPart. SKI classifica questi dispositivi nei seguenti gruppi:

  • Strutture ricettive
  • Strutture per la ristorazione
  • Classi tariffarie
  • Dispositivi per prenotazioni di gruppo
  • Dispositivi per il trasporto bagagli
  • Dispositivi di mobilità
  • Dispositivi atti ad attenuare le perturbazioni
  • Installazioni di comunicazione per i viaggiatori
  • Strutture per la prenotazione di servizi
  • Dispositivi di emissione dei biglietti
  • Tariffe dei treni UIC

Tale classificazione consente di descrivere in modo standardizzato i servizi disponibili lungo un viaggio. Se necessario è possibile ampliare l’elenco, purché la rispettiva categoria sia definita nelle specifiche NeTEx.

Meeting di viaggio

Descrive le possibilità di pianificare orari tenendo conto delle diverse possibilità di cambio:

  • Passaggio a un altro servizio per il quale è noto solo l’orario di arrivo o di partenza.
  • Più in generale: un servizio la cui programmazione si basa sull’orario stabilito di un evento esterno che alimenta o alimenta tale servizio.
  • Organizzazione di un punto di ritrovo (HUB) tra più servizi all’interno di una fascia temporale definita; il che rappresenta una specifica semplificata di diversi cambi. Se necessario, può essere descritto nel dettaglio da più INTERCHANGE RULE o SERVICE JOURNEY INTERCHANGE.
  • Definizione di un punto di ritrovo (orario e luogo) per ogni corsa che possa rispettare questo appuntamento.

InterchangeRule 

Regolamento che consente di documentare le procedure di cambio previste nell’orario, senza dover elencare i dettagli di entrambi i service journey interessati. Serve a definire e strutturare potenziali relazioni di cambio tra le corse, soprattutto quando non sono completamente specificate.

InterchangeRuleParameter
Elemento all’interno del TimetableFrame per specificare i parametri per cambi previsti tra diversi Service Journey. Definisce le condizioni e le restrizioni alle quali un cambio è considerato valido, ad esempio in relazione al mezzo di trasporto (Mode), alla linea (Line) o alla direzione di marcia (Direction).
Questi parametri consentono una modellazione flessibile delle relazioni per il cambio, senza la necessità di specificare tutti i dettagli 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 condizioni temporali per cambi pianificati tra diversi Service Journey. Definisce il tempo necessario o ammesso per una coincidenza, ad esempio i tempi di attesa minimi o massimi tra una corsa di portatore e una corsa di distribuzione in un punto di fermata comune (ScheduledStopPoint).

Proprietà del profilo svizzero

La Svizzera utilizza un profilo NeTEx nazionale basato sullo standard europeo, ma adattato alle esigenze specifiche dei dati svizzeri sul traffico.

  • Il profilo è documentato in lingua tedesca e si basa sulle cosiddette «call», ossia requisiti di dati specifici.
  • È in programma una versione francese che può essere tradotta automaticamente per tenere conto del plurilinguismo della Svizzera.
  • Viene esportato due volte alla settimana tramite la piattaforma opentransportdata.swiss e comprende tutti i mezzi pubblici della Svizzera per l’anno di orario corrispondente.
  • A causa della quantità di dati, le esportazioni vengono suddivise in più file, ad es. in TimetableFrame, ServiceFrame, SiteFrame ecc. per facilitarne l’elaborazione

Traffico on demand

Per il trasporto on-demand (ODV) esistono concetti specializzati di cui si tiene conto anche nel profilo svizzero. Un’offerta on-demand è un servizio con il quale il viaggiatore ordina un viaggio attraverso un processo di prenotazione, spesso a prescindere da fermate o orari prestabiliti. Si tratta di corse di raccolta ordinate in cui più viaggiatori con esigenze di trasporto simili vengono trasportati insieme. Sulla pagina öv-info sono disponibili ulteriori informazioni sull’argomento ODV: Trasporto on demand (autobus a chiamata). Esiste inoltre un concetto specialistico relativo al trasporto on demand per i TP svizzeri: https://www.oev-info.ch/sites/default/files/2023-04/fachkonzept_on-demand_v2.0.pdf.pdf

Una panoramica dell’ODV all’indirizzo opentransportdata.swiss è disponibile nel cookbook all’indirizzo NeTEx – Trasporti on demand.

Processi di importazione ed esportazione NeTEx

Frame Definizione breve
Timetable Frame Comprende la pianificazione temporale delle corse (Vehicle Journeys), incl. i punti di fermata e gli 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 Comprende risorse come veicoli, personale o unità d’esercizio.
ServiceCalendarFrame Definisce la validità delle corse, come giorni civili, periodi e eccezioni.
Common Frame Contiene elementi condivisi come organizzazioni, codici, tariffe o riferimenti.
Accessibility Frame Descrive le caratteristiche di accessibilità di fermate, veicoli e servizi.
FareFrame Contiene informazioni sui prezzi, regole sui prezzi e tipi di biglietti.

Dati esemplificativi

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

Componenti tipici nel nome del file:

Parte integrante Descrizione
Modulo ad es. Timetable, FareFrame, ServiceFrame
Regione ad es. CH, ZH, BE (ISO o abbreviazione interna)
Versione ad es. v1.0, v2.3
Data Formato: AAAAMMGG
Tipo Facoltativo: ad es. Full, Delta, Test, Export

Convalida ed eliminazione degli errori per i dati NeTex

I dati NeTEx contengono molte righe XML e possono anche sembrare confusi, per cui sono disponibili diversi strumenti gratuiti. I più popolari sono:

Applicazioni di validazione:

  • Il Netex Validator (https://github.com/entur/netex-validator-java) di Entur è una libreria di convalida basata su Java progettata specificamente per la verifica dei set di dati NeTEx, in particolare nel contesto del profilo Nordic NeTEx utilizzato in Norvegia e in altri paesi scandinavi.
  • XMLSpy è un editor XML a pagamento e uno strumento di sviluppo di Altova che può essere utilizzato per convalidare i dati NeTEx. La convalida viene eseguita utilizzando i file XML (XSD) associati 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: Conversioni orario
GTFS2NeTEx Converter Converte GTFS → NeTEx Portale Europa interoperabile
Damu Converte NeTEx → GTFS GitHub – Diur./damu
geOps GTFS Feed Conversione giornaliera GTFS da HRDF Feed GTFS geOps

FAQ

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

Diverse esigenze e diversi casi applicativi:

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

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

Le strutture dei dati sono intuitive?

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

#AutoTranslate