Innhold

Forord

...

Preface

Harmonization of exchange methodology between different systems is essential to:

Entur AS på vegne av Jernbanedirektoratet

for å kunne samle rutedata fra hver enkel leverandør på en fornuftig måte, sikre datakonsistens og øke datakvalitet. Dette vil tillate etablering av multimodale informasjonssystemer, noe som kan brukes for å implementere landsdekkende reiseplanlegging for alle typer rutegående kollektivtransport, tilgjengeliggjøre data på en konkurransenøytral måte for alle interesserte;

reisende

for å kunne presentere relevante søkeresultater som har god nok kvalitet;

operatørene

som kan bruke dataene i egne ruteplanlegging-, billettering- og informasjonssystemer for å tilby bedre service til sine kunder;

tredjepartsleverandører

for å minimere utgifter knyttet til utvikling av formatstøtte samt bidra til mer strømlinjeformet og standardisert datautveksling.

...

on behalf of Jernbanedirektoratet

in order to efficiently collect all time table data from each data provider, ensure consistency of data, and grow data quality. This allows the creation of multimodal infomation systems which may be used to implement nationwide journey planning solutions and publisize business neutral information to all interested parties.

travellers

in order to present relevant, and high quality journey suggestions

public transport operators

in order to re-use the data in their own journey planning-, ticketing-, and information systems, and offer a better service to their customers.

third party service providers

in order to minimize unessescary costs related to supporting multiple different exchange formats, and to contribute to a continued growth of standardized public transport data exchange.

Introduction

NeTEx (CEN TS 16614-1, 16614-2 og 16614-3) er en CEN-standard som definerer dataformat og beskrivelse av tjenester for utveksling av ruteinformasjon, tidtabeller og andre relevante data for kollektivtrafikk. Denne standarden er basert på referansemodellen for kollektivtransport, Transmodel og 16614-3) is a CEN-standard which defines the data format and description for public transport data exchanges. The standard is based on Transmodel (EN 12896), samt referansemodellen for permanente objekter påkrevd for tilgang til kollektivtransport, and the reference model for permanent objects required for access to public transport: IFOPT (Identification of Fixed Objects in Public Transport, EN 28701).

NeTEx støtter både utveksling av nødvendige data nødvendig for stoppestedsinformasjon, ruteplanlegging med tilhørende informasjonssystemer samt takst og billettering, og er delt opp i tre hoveddeler:

...

supports the exchange of data nessescary for stop place information, journey planning, and ticketing, and is divided into their main categories

1. Networktopology (CEN TS 16614-1)
2. Ruteplan Plan data (CEN TS 16614-2)
3. Tariff-informasjon information (CEN TS 16614-3)

NeTEx ble utarbeidet av was created by CEN / TC278 / WG3 / SG9 ledet av Frankrike. Siste del av formatet ble publisert i 2015. Formatet er laget som en sammenstilling av behov og krav som finnes hos diverse leverandører av offentlige transport-tjenester i Europa, blant annet ERA lead by France. The final part of the format was published in 2015. The format was created to support the needs of a collection of public transport data providers in Europe, among others ERA (European Rail Agency) og and UIC (International Union of Railways).

NeTEx is an XML-format which facilitates ....

NeTEx er et XML-format som legger til rette for utveksling av rutedata mellom distribuerte systemer. Data i NeTEx-formatet skal kunne benyttes for å effektivt oppdatere ulike informasjons- og operasjonelle applikasjoner gjennom både filbaserte tjenester og webservice-arkitekturer. På den offisielle nettsiden ligger utdypende forklaring av intensjonen som ligger til grunn for standarden, datamodeller og offentlig tilgjengelig standard-dokumentasjon. I sær gir "NeTEx White Papers", tilgjengelig under nettsidenes Downloads-seksjon, en god introduksjon til hvordan ulike konsepter innenfor offentlig transport kan modelleres ved hjelp av NeTEx.

...

• Gjenbrukbare komponenter (framework (Copykorrektur))
• Informasjon om stoppesteder (stops (Copykorrektur))
• Informasjon om transportnettverket (network (Copyi arbeid))
• Informasjon om ruteplan (timetable (Copykorrektur))
• Informasjon om takst og billettering (fares (Copy)) (norsk profil klargjøres i senere versjon)

...

Referanser

Følgende dokumenter ligger til grunn for den norske NeTEx-profilen:

• TS 16614-1, Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format
• TS 16614-2, Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange format
• EN 12896, Road Transport and traffic telematics - Public transport - Reference data model (Transmodel)
• EN 28701, Intelligent transportation systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT)

Anchor
PublicationDelivery PublicationDelivery

Utveksling av informasjon

Informasjon utvekslet over NeTEx-formatet skal være XML-filer som inneholder kun én root tag:

...

Datainnsending i CompositeFrame

Ved gruppering av Frames i en CompositeFrame, må ValidityCondition være likt for alle frames under denne. Det vil si at dette ikke settes per frame, men styres implisitt fra CompositeFrame.

Datainnsending som enkeltvise frames

Når frames ikke er gruppert i en CompositeFrame, må alle relevante frames ha satt eksplisitt ValidityCondition. 

Generalisering

I NeTEx er det gjennomgående at objekter kan legges på ulike nivåer, på den måten å mest mulig korrekt kunne modellere faktiske forhold. For å unngå redundans stilles det derfor krav i norsk profil om at alle beskrivelser og referanser skal ligge så høyt i hierarkiet som mulig.

F.eks. kan Operator refereres fra den enkelte ServiceJourney i Timetable, men i de fleste tilfeller vil en Line ha bare én hovedoperatør. Denne skal derfor referes i Line, og eventuelle unntak i stedet overskrives per ServiceJourney (med referanse til "additionalOperators" i Line).

Versjonering

For å sikre kompatibilitet, tilbyr NeTEx versjonskontroll-mekanisme som lar dataleverandører og - mottakere:

...

Versjonshåndtering er basert på versjonsattributt (konseptuelt VersionFrame), og skal settes på relevant(e) objekt(er) så overordnet - dvs. på så høyt nivå i den leverte XML-strukturen - som mulig.

Versjon for profil

Ved innsending av NeTEx XML for henhodsvis stoppestedsinformasjon og rutedata må det spesifiseres i datasettet hvordan innholdet skal leses inn. Dette gjøres ved å oppgi hvilken profilversjon innsendingen gjelder. 

...

Dersom det likevel skulle skje fremtidige endringer i formatet eller kravene i den norske NeTEx-profilen, som gjør at formatet ikke er bakoverkompatibelt, vil tjenestene i sentrale systemer støtte både gammel og nye versjon i rimelig tid slik at dataleverandører får tid til å gjøre nødvendige tilpasninger. 

Versjon for dataelementer

For versjonering av enkeltobjekter i innsendt XML står dataleverandørene friere til å sette dette, med følgende forbehold:

• Versjonsnummer må være et positivt heltall
• Versjonsnummerne må økes på en slik måte at den seneste versjonen for gjeldende objekt alltid har høyest numerisk verdi

Elementer som skal versjoneres

I praksis må de aller fleste objekter med ID også har en versjon (se Eksempel-katalog for nærmere detaljer), og innsendte stoppesteds- og rutedata skal versjoneres slik at alle relevante endringer medfører en økning av versjonsnummer.  

...

• Endring i informasjon om Network / GroupOfLines
• Endring av informasjon om Line krever ny versjon (ID skal normalt bestå)
• Endring av organisations (Authority, Operator) krever ny versjon (ID skal normalt bestå)
• Endring av geografiske data / posisjonsinformasjon for objekter (som ellers ikke revideres) krever ny versjon
• Ny tilleggsinformasjon (f.eks. AlternativeName for oversettelse) krever ny versjon
• Mindre korreksjoner som påvirker publikumsinformasjon (f.eks. justering av tidspunkt for ankomst/avgang), men ellers ikke påvirker datasettet, krever ny versjon

version="any"

I NeTEx kan man eksplitt spesifisere at et objekt ikke er versjonert ved å sette versjonsattributtet til "any".

Objekter definert annet sted enn i datainnsendingen, f.eks. eksterne objekter fra det nasjonale stoppestedsregisteret, vil alltid være i for tiden gjeldende versjon.

Versjonering i referanser

Det stilles krav om version-attributt for referanser til et unikt objekt definert innenfor samme PublicationDelivery, det vil si at ved referanse til et dataelement som er definert i den sammen filen må versjon oppgis. Referanse til eksterne objekter skal derimot oppgis uten versjon.

...

Ved å oppgi version-attributt i en referanse blir denne referansen validert mot ID + VERSION for eksisterende objekt innenfor gjeldende PublicationDelivery. Fordi XML i ved Schema-validering kun støtter streng-likhet, er det ikke mulig å benytte version="any" for referanse til objekter definert med eksplisitt versjonsnummer (selv om dette etter standarden betyr referanse til siste gyldige versjon). Hvis det finnes flere mulige versjoner av et objekt definert internt i filen, og man skal referere til det siste gyldige, brukes derfor referanse uten version-attributt. Altså på samme måte som ved referanse til eksterne objekter.

Gyldighet for dataelementer

Alle objekter som versjoneres må ha gyldighet, enten implisitt (arvet) eller satt eksplisitt på objektet.

...

• ValidityCondition satt eksplisitt per frame i datainnsendingens PublicationDelivery
• ValidityCondition for en CompositeFrame, hvor denne inneholder alle frames i datainnsendingens PublicationDelivery
  Denne ValidityCondition definerer gyldighet som arves av alle objektene i innsendingen, og gjelder implisitt for samtlige underliggende frames (man kan ikke overstyre ValidityCondition for underliggende frames innenfor en CompositeFrame)

Dataelementer som kan overstyre gyldighet (ValidityCondition)

Alle underliggende datalelementer arver implisitt gyldighet, enten satt gjennom ValidityCondition for innsendingens CompositeFrame eller satt gjennom ValidityCondition for den enkelte frame (når CompositeFrame ikke brukes). Ved behov for å overstyre gyldigheten på underliggende objekter, kan dette gjøres ved å sette eksplisitt ValidityCondition for elementet hvis gyldighet skal avvike fra gyldigheten arvet fra på innsendingens frame:

...

Overstyring av Timetable- og ServiceCalendar-relaterte data skal skje gjennom komplette TimetableFrame og ServiceCalendarFrame med ValidityCondition som utvetydig viser perioden underliggende elementer gjelder.

Konvensjoner

Anchor
ID ID

Utforming av identifikatorer

Identifikatorer til diverse objekter i NeTEx skal følge samme mønster og skal utformes som følger:

...

Faste identifikatorer

For utveksling av stoppestedsinformasjon (StopPlace, Quay etc.) med sentrale systemer er det et krav at identifikatorer alltid skal være de som er gitt i det nasjonale stoppestedsregisteret. Dette for at alle objekter skal kunne identifiseres entydig over tid.

...

Der det er nye rutedata uten naturlig kobling til tidligere objekter skal derimot ikke identifikatorer gjenbrukes, selv om det eventuelt skulle tilfeldige likheter med tidligere data.

Codespace

Tilsvarende som namespace brukes for å identifisere et unikt XML Schema, benyttes codespace i NeTEx for å sørge for at de enkelte dataelementer og attributter i XMLen kan identifiseres unikt for hver innsendt XML. Slik kan data fra ulike innsendere identifiseres og kombineres på tvers av aktører. Alle innsendte data skal derfor identifiseres med et unikt codespace tilordnet den enkelte som leverer stoppested- og rutedata. 

Liste over codespaces vedlikeholdes av Nasjonalt Selskap, og alle som skal ha tilgang til å sende inn stoppested- og/eller rutedata på NeTEx-format vil være tilordnet en codespade-ID med samsvarende namespace der.

Kardinalitet

Kardinaltallet er en egenskap som beskriver mengde, og viser antallet elementer som er forventet for et gitt objekt i henhold til den norske NeTEx-profilen.

• 0: 1 - Valgfri - Kan sende inn null eller maksimalt ett av elementet
• 0: * - Valgfri - Kan sende inn null, ett eller flere av elementet
• 1: 1 - Obligatorisk - Må sende inn ett, og bare ett, av elementet
• 1: * - Obligatorisk - Må sende inn ett eller flere av elementet

Typebeskrivelse

Hvert objekt er beskrevet med følgende tabell:

...

Den første kolonnen utelates dersom tabellen kun inneholder elementer (kolonnen brukes kun for å skille mellom attributter og elementer).

Bruk av Enumeration

Profildokumentene beskriver de forskjellige NeTEx-objekter som brukes i Norge, med aktuelle felter og tilhørende datatyper. Noen datatyper er Enumeration, dvs. en liste med pre-definerte verdier som er tillatt for feltet.

...

1. Enkel Enumeration
   Når datatypen er satt til xxxEnumeration (f.eks. FacilitySetEnumeration), betyr det at bare én verdi er tillatt i feltet:

   Code Block
   language xml
   ... <facilitySet>seatingOnly</facilitySet> ...

   
   

2. Liste av Enumerations
   Når datatypen er satt til xxxListOfEnumerations (f.eks. MealFacilityListOfEnumerations), betyr det at det er tillatt med flere verdier i samme element. Dette settes opp i XML'en på følgende måte:

   Code Block
   language xml
   ... <mealFacilityList>breakfast dinner drinks</mealFacilityList> ...

   
   

Definisjoner

Her beskrives alle NeTEx-begrepene som er brukt i profilen.

...