Håndbok N801 - Nasjonale rutedata v2€¦ · egnet til å støtte reiseplanleggere,...

Nasjonale rutedata Rammer og informasjonselementer

Normativ Håndbok N801

Dokument nr.: 201800413-3 Dato: 01.07.2019

Håndbok N801 - Nasjonale rutedata Forord

2

Forord

Det er et transportpolitisk mål å etablere landsdekkende støtte for reiseplanlegging for alle typer rutegående kollektivtransport. Samferdselsdepartementet har derfor i en tid arbeidet med å tilrettelegge for etableringen av nasjonale rutedata. Det skal samles inn data om alle rutetilbud i landet, og disse rutedataene skal gjøres offentlig tilgjengelig på en konkurransenøytral måte som er egnet til å støtte reiseplanleggere, billettsystemer og andre formål som kan nyttiggjøre seg slike rutedata.

Ansvaret for innhenting, forvaltning og formidling av nasjonale rutedata er delegert til Jernbanedirektoratet. Arbeidet med revidering av kunngjøringsplikten samt innhenting, forvaltning og formidling av nasjonale rutedata har vært organisert i form av et prosjekt som har vært ledet og koordinert av Vegdirektoratet. Prosjektgruppen har bestått av medlemmer fra NRI, Statens vegvesen Vegdirektoratet, NSB, Ruter, Flytoget, Opplandstrafikk, Nordland fylkeskommune, Brakar, Kolumbus, Agder Kollektivtrafikk og Jernbaneverket, samt NHO Transport som har ivaretatt kommersielle aktører fra rutebilbransjen. Fra 1. april 2017 ble ansvaret for håndboken overført fra Statens vegvesen Vegdirektoratet til Jernbanedirektoratet. Samtidig ble utviklingsprosjektet for nasjonal reiseplanlegger overført fra Statens vegvesen Vegdirektoratet til Entur AS.

Denne håndboken ble gjort gjeldende fra 1. februar 2017, med krav om innsending av stoppested- og rutedata på nytt format fra 1. juli 2017 og revidert i juni 2019 med krav om innsending sanntidsdata fra 1. desember 2019. Den erstatter tidligere versjon av Håndbok N801 fra 2017.

Jernbanedirektoratet, juni 2019

Prosjektnummer: 600001

Ansvarlig avdeling: Marked og samfunn Faglig ansvar: Markedskunnskap

Versjon: 2.0

Forsidefoto/illustrasjon: Statens vegvesen/Colourbox

ISBN: 978-82-8386-003-0

Håndbok N801 - Nasjonale rutedata Innhold

3

Innhold

Forord................................................................................................................................................................... 2

Innhold ................................................................................................................................................................. 3

1 Innledning .................................................................................................................................................. 4 1.1 Formålet med denne håndboken ............................................................................................. 4 1.2 Innholdet i håndboken .............................................................................................................. 4

2 Rammer for nasjonale rutedata ............................................................................................................ 5 2.1 Formålet med nasjonale rutedata ............................................................................................ 5 2.2 Lovhjemmel ............................................................................................................................... 5 2.3 Forvaltning av nasjonale rutedata ............................................................................................ 6 2.4 Levering av rutedata ................................................................................................................. 6 2.5 Opphør av linje ........................................................................................................................ 12 2.6 Bruk av rutedata ..................................................................................................................... 13

3 Rutedataformat ..................................................................................................................................... 14 3.1 Kort om NeTEx ........................................................................................................................ 14 3.2 NeTEx-profiler ......................................................................................................................... 14 3.3 Profildokumenter .................................................................................................................... 14

4 Nasjonalt stoppestedsregister ............................................................................................................ 16 4.1 Registrerte data ...................................................................................................................... 16 4.2 Ansvarsfordeling ..................................................................................................................... 16 4.3 Eierskap og tilgang ................................................................................................................. 17 4.4 Administrasjon av stoppesteder ............................................................................................ 17 4.5 Standard for navngiving av stoppesteder ............................................................................. 20 4.6 Stoppestedutrustning ............................................................................................................. 24 4.7 Modelleringseksempler .......................................................................................................... 24

5 Sanntids- og avviksdata ....................................................................................................................... 30 5.1 Krav til sanntids- og avviksinformasjon ................................................................................ 30

Håndbok N801 - Nasjonale rutedata Innledning

4

1 Innledning

Denne håndboka adresserer nasjonale rutedata og de rammene som ligger til grunn for levering, forvaltning og bruk av slike data.

Med nasjonale rutedata menes informasjon om all rutegående kollektivtransport i Norge. Dette inkluderer også skinnegående trafikk og luftfart.

Alle krav formulert som «må» og «skal» er absolutte. «Bør»-formuleringer er å anse som anbefalinger. Fravik skal i utgangspunktet ikke forekomme, men i den grad det likevel er behov for dette skal det godkjennes av Jernbanedirektoratet.

1.1 Formålet med denne håndboken Formålet med denne håndboken er tredelt:

• Håndboken skal informere om rammene for nasjonale rutedata. Motivasjonen bak opprettelsen av nasjonale rutedata beskrives med utgangspunkt i europeiske direktiver, nasjonale lover og behov for nye og bedre reiseinformasjonstjenester. Det gis også informasjon om retningslinjer for levering, forvaltning og bruk av rutedata.

• Håndboken skal definere den informasjonen som inngår i nasjonale rutedata og som skal leveres i henhold til Kunngjøringsplikten. Alle dataleverandører, det vil si fylkeskommuner og Jernbanedirektoratet eller deres administrasjonsselskaper/løyvehavere samt fylkeskryssende kommersielle aktører og andre som er ansvarlig for forvaltningen av nasjonale rutedata, skal forholde seg til de gitte kravene og kontrollere at disse oppfylles. Data som ikke skal leveres i dag, men som sannsynligvis vil bli krevd levert i fremtiden defineres også, slik at dataleverandørene kan forberede seg på et tidlig tidspunkt. Merk at listen over data som vil kunne bli omfattet av kunngjøringsplikten er dynamisk og ikke nødvendigvis uttømmende.

• Håndboka skal sikre at alle parter overfører data på et standardisert format, dette gjelder både for rutedata og for sanntids- og avviksdata.

1.2 Innholdet i håndboken Håndboken har følgende kapitler:

• Kapittel 2 gir en kort introduksjon til kunngjøringsplikten og hvilke data vi ønsker innsendt. Kapittelet beskriver også hvordan dette skal skje.

• Kapittel 3 går nærmere inn på dataformatet som skal benyttes for innsendelse av rutedata. • Kapittel 4 tar for seg det nasjonale stoppestedsregisteret, hvilke data som ligger der og

hvilke rutiner som gjelder for oppdatering av stoppestedsdata. • Kapittel 5 beskriver de sanntids- og avviksdata som skal leveres.

I tillegg til dette dokumentet inngår følgende vedlegg som del av Håndbok N801:

• NeTEx profil Norge - Teknisk spesifikasjon for levering av rutedata og annen tilknyttet informasjon

• SIRI profil Norge – Teknisk pesifikasjon for levering av sanntids - og avviksdata

I tillegg til håndbokdokument og vedlegg er det tilgjengeliggjort et eget web-område med tekniske prosessbeskrivelser, teknisk malverk (XML) og eksempler på dataleveranser hos Entur AS.

Håndbok N801 - Nasjonale rutedata Rammer for nasjonale rutedata

5

2 Rammer for nasjonale rutedata

Det er et transportpolitisk mål å få etablert landsdekkende reiseinformasjonstjenester for alle typer rutegående kollektivtransport. Samferdselsdepartementet vil derfor at alle nasjonale rutedata samles inn og gjøres offentlig tilgjengelig for nasjonal reiseplanlegging og andre tjenestetilbud.

2.1 Formålet med nasjonale rutedata Nasjonale rutedata skal inneholde alle opplysninger (data) som er nødvendig for å kunne utarbeide hensiktsmessige landsdekkende reiseinformasjonstjenester for kollektivtransporten i Norge. Med rutedata menes i denne forbindelse både data om stoppesteder og ruteplan.

Rutedataene skal være konkurransenøytrale og de er offentlige. Dette betyr at alle skal ha likeverdig tilgang til dataene og kunne bruke dataene til tjenester som vedrører reiseplanlegging, reiseinformasjonsformidling og annen relevant tjenesteutvikling. Dataene skal også kunne brukes til kommersielle formål. En tilgjengeliggjøring av nasjonale rutedata vil gi bred samfunnsnytte:

• Nasjonale rutedata er et helt nødvendig grunnlag for landsdekkende, konkurransenøytrale reiseplanleggere for alle typer rutegående kollektivtransport.

• Det blir lettere å etablere og drifte reiseinformasjonstjenester ved hjelp av enkel tilgang til kvalitetssikret informasjon om blant annet ruter og stoppesteder.

• Fylkeskommuner og andre aktører behøver ikke selv å etablere tjenester for offentliggjøring og formidling av sine rutedata, og kan basere sine regionale reiseplanleggere på rutedata innsamlet i den nasjonale rutedatabasen.

• Nasjonale rutedata vil legge til rette for en fremvekst av nye og mer komplette reiseinformasjonstjenester som vil gjøre det enklere å velge kollektiv reiseform. Dette vil sannsynligvis også bidra til å øke anseelse og bruk av kollektivtransport, og derigjennom bidra til å nå vekstmålene i Nasjonal transportplan som slår fast at veksten i persontransport skal dekkes av kollektivtjenester, sykling og gange.

Nasjonale rutedata kan etter hvert integreres med andre data som øker funksjonaliteten i reiseinformasjonstjenestene ytterligere. Det er for eksempel et ønske om at rutedata skal kunne integreres med data som muliggjør beregning av takster på tvers av fylkesgrenser og operatører. En utvikling av samordnet billettering basert på Håndbok V821 og etablering av en standard for mobil-billettering vil trolig muliggjøre en realisering av reiseplanleggere som inkluderer støtte for kjøp av billetter, også gjennomgående billetter for sammensatte reiser. Da kan trafikantene slippe å oppsøke flere nettsteder eller selskaper for å få anskaffet billetter.

2.2 Lovhjemmel Etableringen av nasjonale rutedata er tuftet på nasjonale forpliktelser og lover.

2.2.1 ITS-direktivet og PSI-direktivet PSI-direktivet (Public Sector Information direktivet) og ITS-direktivet (Intelligente Transportsystemer direktivet) er vedtatt i EU, og Norge er gjennom EØS-avtalen forpliktet til å følge direktivene. PSI-direktivet omhandler tilgjengeliggjøring av offentlige data, og konsekvensene for Norge er angitt i "Rettleiar til offentleglova" (Justis- og politidepartementet, 2010).

ITS-direktivet legger blant annet til rette for tilgang på multimodal reiseinformasjon for hele Europa. Dette er et av de prioriterte tiltakene i EU. Det er derfor et særskilt prioritert mål å få til teknologi og organisering som muliggjør sammenhengende reiseplanlegging i Europa. Dette vil bli førende for de


6

spesifikasjoner som nå utvikles under ITS-direktivet og som blir obligatoriske også for nasjonale reiseplanleggingstjenester i Norge. Norge må derfor følge arbeidet i Europa tett.

2.2.2 Kunngjøringsplikten Forskrift om yrkestransport med motorvogn og fartøy (yrkestransportforskriften) legges til grunn for å sikre at nødvendige stoppesteds- og ruteplandata overføres fra pliktige parter. Kunngjøringsplikten følger av forskriftens § 28.

Kunngjøringsplikten gjelder for alle som er underlagt yrkestransportloven, det vil si all transport på veg og hurtigbåt/ferje. For togtrafikken og luftfart, vil overføring av data finne sted fra de av virksomhetene som administrerer rutetrafikken på vegne av staten. Hvem som er løyvehaver og leverandør av data varierer fra fylke til fylke. Det kan være fylkeskommunen selv, direkte eller via tilknyttede administrasjonsselskap, trafikkselskapene eller begge. I det videre brukes dataleverandører som samlebetegnelse for de som skal levere informasjon om stoppesteder og rutedata til det nasjonale selskapet.

Samferdselsdepartementet har i rundskriv N-2/2019 fastsatt retningslinjer til yrkestransportforskriften for offentliggjøring av ruteopplysninger for persontransport, og derigjennom trådte dagens krav til kunngjøringsplikten for stoppested- og rutedata i kraft 1. juli 2017 og for sanntidsdata i kraft 1. desember 2019.

Ved gjentatte advarsler for grove tilfeller av manglende, mangelfulle eller for sen leverte data - eller manglende korreksjon av påpekte feil og/eller mangler - kan Samferdselsdepartementet iverksette tilbakekalling av dataleverandørens løyve i henhold til Lov om yrkestransport med motorvogn og fartøy (yrkestransportlova) § 29.

2.3 Forvaltning av nasjonale rutedata

2.3.1 Nasjonalt selskap for administrasjon av rutedata De nasjonale rutedataene skal samles inn, administreres og gjøres tilgjengelig av et nasjonalt selskap. Driften av virksomheten rundt nasjonale rutedata tildeles dette selskapet.

2.3.2 Samarbeidsforum for forvaltning av kunngjøringsplikten For å forvalte og videreutvikle Kunngjøringsplikten, er det etablert et eget Samarbeidsforum som ledes av Jernbanedirektoratet. Deltakerne er et representativt utvalg av de som leverer rutedata, så som Fylkeskommunenes administrasjonsselskaper, jernbaneoperatører, ferjeselskaper og busselskaper.

Faglig uenighet søkes løst innenfor Samarbeidsforumet. Hvis det ikke oppnås konsensus er det opp til Samferdselsdepartementet å bestemme hvem som har myndighet til å ta endelig avgjørelse.

Det nasjonale selskapet (se avsnitt Nasjonalt selskap for administrasjon av rutedata) er sekretariat for Samarbeidsforumet.

2.4 Levering av rutedata For at det til enhver tid skal være mulig å kunne tilgjengeliggjøre komplette og oppdaterte nasjonale stoppesteds- og rutedata, med alle nødvendige opplysninger fra kollektivtransport-sektoren i Norge, er det avgjørende at løyvehavere og dataleverandører overfører sine data elektronisk på definerte formater innenfor fastsatte krav og frister som beskrevet senere i dette dokumentet.


7

2.4.1 Hvem skal levere rutedata Fylkeskommunen eller Samferdselsdepartementet ved Jernbanedirektoratet (som løyvemyndigheter) er ansvarlige for at rutedata leveres til det nasjonale selskapet i henhold til retningslinjene. Ansvaret for å levere rutedata kan organiseres gjennom administrasjonsselskapene for kollektivtrafikk, eller ved at operatører gis fullmakt til å levere rutedata direkte. Fylkeskommunene og Jernbanedirektoratet må da påse at de som ifølge inngått kontrakt har ansvaret for å levere rutedata, gjør dette i henhold til Kunngjøringsplikten.

Rutedata inkluderer også data om stoppestedene som benyttes. Fylkeskommunen har særskilt ansvar for å påse at det leveres informasjon om stoppesteder og knutepunkter i eget fylke, Jernbaneverket har tilsvarende for stopp tilknyttet jernbane. Disse instansene har også ansvar for at det meldes inn navn på stoppestedet. Navn fastsettes av ansvarlig part i henhold til nærmere beskrevne retningslinjer (se avsnitt Standard for navngiving av stoppesteder). Det nasjonale selskapet betraktes som rådgivende part, men dersom navngivningen ikke følger navngivningsstandarden eller skaper tekniske utfordringer vil dette kunne bli gjenstand for endring.

Dataleverandørene har selv ansvaret for at de dataene de leverer er korrekte og komplette.

2.4.1.1 Datavalidering Ved innsending av rutedata vil det nasjonale selskapet automatisk kontrollere alle data som sendes inn etter et sett med valideringsregler. Kun rutedata som passerer denne kontrollen vil bli akseptert. Valideringsrapporter vil bli gjort tilgjengelig for dataleverandørene slik at man kan gjennomgå og korrigere sine datasett før ny innsending.

Det nasjonale selskapet vil også tilby en selvbetjeningsportal hvor dataleverandørene kan registrere og/eller korrigere sine rutedata.

Videre er dataleverandørene selv ansvarlige overfor brukerne av nasjonale rutedata (for eksempel leverandører av reiseplanleggere og andre tjenester som baserer seg på nasjonale rutedata, samt sluttbrukerne på disse løsningene) for eventuelle problemer og avvik som skyldes feil eller mangler ved leverte data.

2.4.2 Hvilke rutedata skal leveres De rutedataene som skal leveres til det nasjonale selskapet er beskrevet i nærmere detalj i vedlegget NeTEx profil Norge.

Dataene skal til enhver tid være oppdaterte. Det er et krav at man skal kunne søke på rutedata som er gyldige i minimum 120 dager frem i tid. På lengre sikt er målsettingen å kunne øke denne perioden, slik at gyldige rutedata blir søkbare et år frem i tid.

Sanntids- og avviksdata leveres gjennom egne kontinuerlige datastrømmer, se avsnitt Sanntidsdata.

Konkurransemanipulasjon

Ved innsending av åpenbart urealistiske rutetider eller andre på annen måte bevisst konkurransevridende manipulasjon av datagrunnlaget, har nasjonalt selskap myndighet til å pålegge endring av ruteoppsettet. Dersom en dataleverandør ikke etterkommer dette, eller gjentatte ganger gjør endringer i strid med disse bestemmelsene, står nasjonalt selskap i ytterste konsekvens fritt til å utelate spekulativt konkurransevridende rutedata fra data-eksporter, reisesøk og liknende frem til forholdet er rettet.


8

2.4.2.1 Stoppesteder Dataleverandører er ansvarlig for opprettelse, endring og nedleggelse av stoppesteder i stoppestedsregisteret som skal benyttes i forbindelse med rutetransport i Norge.

Administrasjon av stoppestedsdata vil bli håndtert med egne retningslinjer hos det nasjonale selskapet. Dette fordi stoppestedsregisteret skal være landsdekkende masterdata-kilde og vil være teknisk og administrativt separert fra ruteplandata. Uavhengig av fysisk tilstand må alle stoppesteder være registrert i det nasjonale stoppestedsregisteret før det kan sendes inn ruter som benytter stoppestedet, eller er koplet til det på annen måte. Dette sikrer at alle transportmidler som stopper ved eller har overgang til et stoppested, bruker den samme nasjonalt unike identifikatoren og det samme navnet på stoppestedet. Stoppestedsregisteret og tilhørende rutiner er beskrevet i avsnitt Nasjonalt stoppestedsregister.

Det vil videre være mulig å legge inn data om andre steder som er interessante med tanke på rutedata og reisesøk (Point of Interest), som for eksempel offentlige kontorer, skoler og utdanningsinstitusjoner, idrettsarenaer eller andre "severdigheter" med betydelig publikumstilstrømning. Dette er ikke primærformålet med stoppestedregisteret, slik at skillet mellom slike steder i stoppestedregisteret kontra kartinformasjon benyttet i reisesøk må avklares fortløpende, men slike steder vil ved behov kunne håndteres på samme måte og gis tilsvarende reise-relevant tilleggsinformasjon som vanlige stoppesteder.

Stoppestedsregisteret vil også inneholde ganglenker i komplekst sammensatte arealer, i særlig grad for større innendørs trafikk-knutepunkter, samt andre steder hvor kartløsningen vanskeliggjør tilstrekkelig gode reiseforslag dersom disse ikke er eksplisitt beskrevet.

2.4.2.2 Ruteplaner Dataleverandører er ansvarlige for at det leveres oppdaterte ruteplaner i henhold til kravene hjemlet i Kunngjøringsplikten.

Alle ruteplaner skal registreres med avgangs- og/eller ankomsttider for det enkelte stoppested. Det skal også fremgå hva slags type transportmiddel som trafikkerer ruten. Informasjonen skal inneholde opplysninger om dager, tider og stoppesteder, samt om linjen kun trafikkeres etter forhåndsbestilling. Begrenset adgang til betjening må framgå av ruteplanene. Det vil si om linjen trafikkeres visse deler av året, om den ikke går helligdager eller visse andre dager, eventuelt om tilbudet reduseres på slike dager. Dersom transportmiddelet stopper på et stoppested kun for påstigning eller avstigning skal dette angis spesielt. Detaljspesifikasjon av krav knyttet til leverte ruteplaner fremkommer i vedlegg NeTEx profil Norge.

Når det nasjonale stoppestedsregisteret er klart, vil alle aktører få en eksport som inneholder komplett liste over alle stoppesteder med deres offisielle stoppested-ID. Fra dette tidspunktet vil denne identifikatoren være eneste gyldige stoppested-referanse ved innsending av ruteplandata.

Merk at fiktive stoppesteder, for eksempel soneskifter eller andre steder hvor passasjerer ikke kan gå på eller av et kjøretøy i rutetrafikk, skal ikke leveres sammen med kunngjorte data.

Informasjon knyttet til stoppesteder vil ikke bli oppdatert gjennom vanlige rutedata-leveranser, i innsendte ruteplaner skal det kun brukes referanser gjennom offisiell ID for eksisterende stoppesteder. Opplysninger om tilknyttede stoppesteder vil gjennom denne referansen i sin helhet bli hentet fra stoppestedsregisteret.

Opprettelse, endring og nedleggelse av stoppesteder skal alltid gjøres som separat datainnsending og/eller direkte i stoppestedsregisteret (ref. vedlegg NeTEx profil Norge).


9

2.4.3 Teknisk dataleveranse Rutedata oppdateres hos Nasjonalt selskap over én av følgende kanaler:

• Filsending med SFTP • Filopplasting i web-grensesnitt • Manuell innlegging via brukergrensesnitt i web-løsning

Det vil bli opprettet bruker med relevante tilganger for alle instanser som har behov for å gjøre oppdateringer i rutedata, skilt mellom tilgang for henholdsvis stoppstedsregisteret og rutedatabasen i henhold til brukernes ansvarsområde og behov.

Alle datasett som oversendes i form av filoverføring eller WebService skal eksporteres til XML som må inneholde en <PublicationDelivery> rotnode (se også nærmere beskrivelse av utvekslingsformatet), hvor innholdet er satt opp i henhold til kravene fastsatt i vedlegg NeTEx profil Norge. Alle XML-filer som leveres til nasjonalt selskap må bestå av komplette datasett for hele sin gyldighetsperiode.

2.4.3.1 Tilgangsstyring Alle instanser som skal sende inn stoppesteds- og/eller rutedata må i forkant ha inngått avtale med nasjonalt selskap, og få opprettet tilgang inkludert leverandør-identifikator (codespace, xmlns, ref. tidligere "Administrasjonskode"). Denne er påkrevd å bruke ved innsending av data, nærmere beskrevet under Utforming av identifikatorer i vedlegg NeTEx profil Norge.

2.4.3.2 Stoppested Dataleverandører skal gjennom innlevering av stoppesteder som XML med komplett NeTEx-struktur for stoppestedsinformasjon i henhold til "stops"-profil (se NeTEx profil Norge og eksempel-katalogen under denne), eller gjennom oppdateringer direkte i Stoppestedsregisterets sluttbrukerløsning (web-portal), sørge for å holde oppdatert alle nasjonale stoppesteder. Dette registeret danner felles grunnlag for alle ruteplaner som gjør anløp på disse stoppestedene. Dette er nærmere beskrevet i eget avsnitt Stoppestedsregister.

2.4.3.3 Ruteplan Dataleverandører skal levere ruteplaner, enten som egne datasett eller som oppdateringer direkte i Rutedatabasens webløsning. Dersom rutedataene sendes inn, skal datasettet bestå av en ZIP-fil uten underkataloger (flatt hierarki) med én XML-fil per linje. Denne filen skal inneholde de NeTEx-strukturer som er nødvendig for å beskrive alle relevante fasetter ved linjen, i henhold til "network-timetable"-profil, med referanser til stoppesteder basert på ID i stoppestedsregisteret (se eksempel-katalog for vedlegg NeTEx profil Norge). Disse data skal være komplette sett per linje, med minimum 120 dagers gyldighet, og inneholde all nødvendig informasjon om transportmiddelet, dager linjen opereres, ankomst- og avgangstider med mer, samt om linjen går i fast trafikk eller må forhåndsbestilles og om det er spesielle begrensninger knyttet til avgangen.

Det vil både legges til rette for at data kan sendes inn per enkeltvise linje, eller som bolker av linje-filer i samme leveranse. Ved innsending av større datasett, for eksempel når det sendes inn mange linjer fra samme operatør, vil nasjonalt selskap legge teknisk til rette for at gjennomgående elementer kan trekkes ut av de enkelte datasettene og leveres i en felles-fil. Dette for å unngå omfattende redundans av for eksempel identifikator-beskrivelser, gyldighetsperioder, referanser til stoppested og tilordning av disse og overordnede rute-definisjoner (se nærmere forklaring i vedlegg NeTEx profil Norge). Merk at en slik forenklet konstruksjon av datasett for innsending er en mulighet, men det stilles ingen krav om dette. Innlevering av data med gjentakende beskrivelse av felles elementer vil bli håndtert på samme måte, og resultere i samme rutedata som innlevering på komprimert form.


10

2.4.3.4 Normal leveranse I forkant av rutedatainnlevering må samtlige stoppesteder brukt i datasettet være registrert i Stoppestedsregisteret, som beskrevet tidligere. Om en linje ikke allerede finnes i Rutedatabasen, vil den automatisk bli opprettet ved første gangs levering av rutedata for denne.

Alle leverandører er påkrevd å bruke sin unike identifikator ved innsending av data, dette er nærmere beskrevet i eget avsnitt om Tilgangsstyring.

Følgende prosess gjelder for innlevering:

1. Dataleverandører sender NeTEx-XML med oppdaterte rutedata (alternativt oppdaterer manuelt i Rutedatabasen) • SFTP • Web-grensesnitt

2. Rutedata valideres etter regler som for eksempel: • Mottatt XML skal være syntaktisk korrekt og validere i henhold til siste versjon av

offisielt NeTEx XML Schema (se NeTEx_publication.xsd i standardorganets offisielle repository på GitHub)

• PublicationDelivery-noden må inneholde alle nødvendige frames for innsendingen • xmlns (innsenders identifikator) er gyldig • Alle stoppesteder referert i datasettet må eksistere • Stoppesteder referert kan ikke være markert som stengt eller nedlagt • Referanser til eksterne rutedata må være korrekte (for eksempel ved overgang til andre

linjer) • Geografiske referanser må være gitt på korrekt format

3. Når mottatt innhold er validert sendes rutedataene videre for importert i rutedatabasen • Ved valideringsfeil vil avsender umiddelbart motta en rapport fra nasjonalt selskap som

beskriver feilene i mottatt datasett • Når logiske feil i datasettet er rettet opp kan dette sendes inn på nytt for import

4. Rapport for mottatt og godkjent datasett gjøres tilgjengelig i ruteoperatørportalen, samt sendes eventuelt ut på epost til registrerte interessenter

Oppdatert liste over valideringssteg publiseres fortløpende, slik at ruteleverandører kan kvalitetssikre sine data i henhold til denne før innsending.


11

Så snart de innleverte rutedataene er importert inn i stoppested- og rutedataregistrene, vil de automatisk være gjort tilgjengelig for rutedata-eksport samt i reiseplanlegger hos nasjonalt selskap.

2.4.3.5 Innlevering av datasett Overordnet prosessillustrasjon for innlevering/oppdatering av datasett:

Alle oppdateringer blir publisert så snart datasettet er verifisert og prosessert (normalt 1-3 timer). For å sikre kvaliteten på innleverte datasett ønsker Nasjonalt selskap i størst mulig grad kontinuerlig oppdatering av disse, og oppfordrer til jevnlig eksport av datasettene. Målsetningen på sikt er en oppdateringsfrekvens hvor nytt datasett overføres for eksempel hvert døgn.

2.4.4 Rettelser Det forventes at dataleverandører etablerer rutiner for å sikre rask retting av rutesett, slik at disse blir korrekte. I dette ligger også at løyvehavere innarbeider rutiner for koordinering og oppfølging av planlagte avvik med aktuelle vegmyndigheter eller andre etater på kommunalt, fylke eller nasjonalt nivå.

Ved feil eller mangler i innrapporterte data for stoppesteder eller rutedata, vil nasjonalt selskap sende varsel til dataleverandør med krav om retting. I varselet vil det bli informert om innrapporterte eller avdekkede feil og mangler, uten at dette varselet nødvendigvis inneholder en uttømmende liste over alle forhold som må korrigeres.

Dersom kjente feil ikke følges opp av dataleverandør innen gitt tidsfrist, kan i ytterste konsekvens nasjonalt selskap utelate berørte datasett fra eksport og reisesøk frem til forholdene er korrigert.

2.4.4.1 Endring av innleverte data Ved planlagte avvik i rutedataene, må dataleverandør så snart avviket er identifisert sende melding om dette til det nasjonale selskapet. Dette skal gjøres så snart som mulig etter at planene er

Merk at innsendte datasett skal inneholde alle data for perioden som erstattes. Rutedatabasen håndterer i første versjon ikke rene endringer (delta-last), slik at innsendte datasettet alltid må være komplette for perioden dataene gjelder.

Dette fordi at det ved mottak av nye data gjøres en fullstendig overskrivning av alle data for gyldighetsperioden i stoppestedsregisteret / reiseplanleggeren.

I nåværende versjon av Rutedatabasen vil siste datasett for en periode alltid være eneste data registrert for perioden.

Dette innebærer at ved endring av data vil nytt datasett erstatte alle data som eventuelt eksisterer, det er derfor nødvendig å alltid sende inn komplette datauttrekk uavhengig av om det allerede er levert rutedata for den gitte perioden eller ikke.


12

fastlagt, senest innen 24 timer før avviket trer i kraft. Avvik skal i størst mulig grad forsøkes håndtert gjennom innsending av nye rutedata. I tilfeller hvor dette ikke er praktisk eller teknisk mulig, for eksempel ved for kort varsel før avviket inntrer, kan dette håndteres gjennom SIRI-SX avviksmeldinger. Alternativt kan avvik innmeldes ved hjelp av SIRI-ET (når endringer gjelder inneværende dag) eller SIRI-PT (når endringene gjelder neste dag) dersom hensiktsmessig. (SIRI meldingstyper er nærmere beskrevet under bestemmelser for Sanntids- og avviksdata).

Merk at for gjeldende utgave av Rutedatabasen er det kun mulig å endre hele datasettet for en linje, fordi innsendte endringer vil erstatte alle data som eventuelt finnes fra før innenfor samme gyldighetsperiode. Nye datasett som oppdaterer ruter og tidtabeller kan altså sendes inn fortløpende via vanlig rutedata-leveranse, så lenge rutedataene til enhver tid er gyldige i minst 120 dager fremover.

2.4.4.2 Ikke-planlagte avvik og andre endringer med kort varsel Ved uforutsette hendelser, som medfører ikke-planlagte avvik i rutedataene med varighet over 24 timer, skal dataleverandør uten ugrunnet opphold sende melding om dette til det nasjonale selskapet. (Merk at det samme også gjelder ved planlagte avvik som blir gjort kjent med for kort varsel, for eksempel avvik som har blitt for sent annonsert på grunn av avhengigheter til mange aktuelle etater eller andre tilfeller av svikt i informasjonsflyten som dataleverandøren ikke kan lastes for.) Dette skal meldes inn gjennom endring av rutedata. Men i de tilfeller hvor rutedata må endres innen kortere tid enn et døgn, må dataleverandøren selv gjøre en vurdering om det er tilstrekkelig å foreta en normal publisering av endringen eller om dette bør publiseres ved hjelp av sanntidsmeldinger (nærmere beskrevet under bestemmelser for Sanntids- og avviksdata). Andre endringer som berører spesifikk(e) avgang(er) med behov for kort publikasjonstid, kommuniseres som hovedregel ved hjelp av sanntidsmeldinger.

2.4.4.3 Status for rutedata Dataleverandør-portalen vil vise info med status per linje (kompletthet for data 120 dager fremover i tid) for den enkelte dataleverandør.

2.4.4.4 Eksempler Relevante varianter av datasett for innsending (XML / PublicationDelivery) finnes i eksempel-katalogen for vedlegg NeTEx profil Norge.

2.5 Opphør av linje Ved nedleggelse av en linje, og rutedata for denne ikke skal sendes inn lenger, må dette gjøres eksplisitt slik at det ikke utløses feilaktig varsel om manglende rutedata. Dette gjelder både midlertidig nedleggelse (for eksempel sesong-rute) og permanent avvikling av en rute.

2.5.1 Permanent Her må operatørene ved innsendelse av rutedata spesifisere at linjen etter siste gyldige avgang ansees som nedlagt. Dette gjøres ved å sette validityCondition samt et attributt på linjen, nærmere beskrevet under Line i vedlegg Netex profil Norge.

2.5.2 Midlertidig Midlertidig opphør av en linje skal presiseres entydig i innsendte rutedata, slik at det fremkommer at linjen er i drift men midlertidig utilgjengelig. Dette er nærmere spesifisert i NeTEx profil Norge. (Se også prosess for Permanent nedleggelse over.)

Gyldighetsperiode anbefales at settes på følgende måter:

• Vanlig linje som eksisterer og skal fortsette å eksistere i uoverskuelig fremtid: ingen validitiyCondition


13

• Sesonglinje: validityCondition som spesifiserer fra og til-dato for gyldighet • Linje som snart legges ned: validityCondition kun med sluttdato • Linje som opprettes i nær fremtid: valdititCondition kun med startdato

For svært kortere opphold anbefales det å sende inn gyldige data eksplisitt uten planlagte avganger for den aktuelle perioden.

Der det er hensiktsmessig vil det også være mulig å sette et attributt ved innsendelse av rutedata, tilsvarende som ved permanent nedleggelse. Linjen vil da betraktes som nedlagt frem til den blir gjenopprettet. Dette gjøres ved på nytt å sende inn gyldige rutedata på vanlig måte, disse vil da overstyre tidligere innsendt nedleggelse.

2.6 Bruk av rutedata De nasjonale rutedataene skal være konkurransenøytrale og tilgjengelige, slik at alle som ønsker utvikle reiseinformasjonstjenester - eller bruke disse dataene på annen måte - skal gis tilgang og derigjennom mulighet til å foreta verdiøkende arbeid på datagrunnlaget.

Når det gis tillatelse til bruk av rutedata, skal det inngås en avtale i henhold til Norsk lisens for offentlige data (NLOD) med brukeren. Dette gjør at nasjonalt selskap har oversikt over bruken av rutedataene gjennom akkreditering med unik brukertilgang for hver interessent.

Det vil ikke bli inngått avtaler som gir enkeltvirksomheter eller enkeltbedrifter eksklusiv rett til bruk av data, alle rutedata inkludert rådata vil derimot bli gjort tilgjengelige via åpne og veldokumenterte tjenestegrensesnitt (API-er) og/eller nedlastbare filer hvor det til enhver tid er mulig for brukerne å hente oppdaterte data.

Håndbok N801 - Nasjonale rutedata Rutedataformat

14

3 Rutedataformat

Rutedata skal oversendes til nasjonalt selskap på et gitt format, definert i vedlegg NeTEx profil Norge.

Dette kapittelet gir en kort oversikt over hva NeTEx er, og hvilke elementer som skal sendes inn i henhold til den norske profilen.

3.1 Kort om NeTEx NeTEx er et XML-basert utvekslingsformat for utveksling av informasjon rundt offentlig transport. NeTEx er en teknisk standard i Europa, og det arbeides for å få den etablert som en norm. NeTEx er bygget på den konseptuelle informasjonsmodellen Transmodel som også er en europeisk norm.

3.2 NeTEx-profiler NeTEx-formatet kan brukes for å beskrive veldig mange aspekter ved offentlig transport, alt fra den fysiske infrastrukturen inkludert stoppesteder via materiell, tidtabeller, sjåførplanlegging til informasjon om billettpriser og soner. Fordi formatet skal være fleksibelt og kunne dekke en rekke transporttekniske behov i Europa, gir modellen også rom for mange ulike måter å modellere ulike aspekter fra virkeligheten på. I informasjonstjenester er det kun behov for en liten del av det som er mulig å beskrive ved hjelp av den tekniske spesifikasjonen, og en "profil" definerer hvilke data-elementer som skal sendes inn og på hvilken form dette skal gjøres.

Selve profilen er et dokument som presiserer følgende:

• Hvilke felter i XML-dokumentet som må inkluderes • Hvilke data-verdier som er gyldige for disse feltene • På hvilke måter gitte aspekter modelleres

3.3 Profildokumenter For å gruppere sammenfallende egenskaper og øke lesbarheten er den norske profilen delt opp i flere dokumenter. De delene som til sammen utgjør norsk NeTEx-profil er listet under:

1. Generell informasjon 2. Rammeverk (Framework) 3. Stoppesteder (Stops)

Det bemerkes spesielt at vedlegget NeTEx profil Norge vil være dynamiske dokumenter i perioden mens standarden innfases, og dette er et aspekt som leverandører av data bør være spesielt oppmerksomme på.

• Fortløpende, mindre justeringer i profilen defineres som pålegg, og dataleverandører skal gjøre eventuelle tilpasninger for å imøtekomme disse.

• Endringer som med stor sannsynlighet vil påvirke datauttrekk hos leveransepliktige parter blir versjonert (publiseres og støttes som ny versjon av profilen).

Nasjonalt selskap skal støtte alle publiserte versjoner av norsk NeTEx-profil i rimelig tid fremover. Ved utfasing av versjon vil end-of-life dato annonseres på forhånd, slik at dataleverandører får tid til å justere datauttrekk i henhold til fortsatt gjeldende versjon(er) av profilen. Eventuelle endringer som gjør profilen ikke-bakoverkompatibel, vil også resultere i en formell revisjon av denne håndboken.

Håndbok N801 - Nasjonale rutedata Rutedataformat

15

4. Nettverk (Network) 5. Tidtabeller (Timetable) 6. Billettpriser (Fares) (kommer senere)

Oppdatert spesifikasjon, med til enhver tid gjeldende krav for dataleveranse til nasjonalt selskap, vil fremgå av dokument-settet i vedlegg NeTEx profil Norge.

Håndbok N801 - Nasjonale rutedata Nasjonalt stoppestedsregister

16

4 Nasjonalt stoppestedsregister

Formålet med stoppestedsregisteret er:

• Sikre at alle eksisterende stoppesteder er kjent og brukes likt av alle dataleverandører. o Dette vil gjøre det enklere for de som opererer på tvers av regioner å planlegge sine

ruter. o Det vil sikre at alle dataleverandører benytter stoppesteder som allerede eksisterer

fremfor å opprette egne. • Sikre at alle dataleverandører som benytter stoppestedet i sine publikasjoner bruker navn,

koordinat og annen publikumsrettet informasjon likt. o Dette er en forutsetning for å kunne beregne korteste reiseveg for en reisende,

samt for å kunne beregne pris og utstede gjennomgående billetter på sikt. • Sikre at endringer i data om stoppesteder kun utføres av, eller etter avtale med, den som er

gitt rett til å administrere stoppestedet. • Sikre at alle endringer i stoppestedsinformasjonen blir kommunisert til alle interessenter. • Sikre at et stoppested som er nedlagt, eller av annen grunn ikke kan betjenes, ikke lenger

benyttes i rutedata.

4.1 Registrerte data Stoppestedsregisteret vil blant annet inneholde følgende dataelementer for et stoppested (Alternativt Point of Interest):

• Navn • Underelementer (Quays, innganger, ganglenker) • Koordinater i henhold til WGS84-standarden

o Latitude o Longitude o Height (hvis relevant)

• Regional tilhørighet o Fylke o Kommune

• Informasjon om fysisk utforming av stoppested og Quay(s) (inkludert relevante data i forhold til universell utforming)

o Herunder stoppestedsutrustning o Automatisk synkronisering av noen relevante data fra NVDB (ikke komplett

datasett) • Administasjonsansvar

o Tilgang for å kunne gjøre endringer

4.2 Ansvarsfordeling Fylkeskommunene og Jernbanedirektoratet, direkte eller gjennom sine administrasjonsselskaper og/eller løyvehavere, er ansvarlige for å melde inn, endre og nedlegge stoppesteder i Norge. Dette inkluderer Quays tilknyttet stoppestedet, koordinater og informasjon om stoppestedets utforming. Innenfor ansvarsområdet ligger også fortløpende vedlikehold av stoppestedsinformasjonen i henhold til kravene beskrevet i profildokument stops under vedlegg NeTEx profil Norge, slik at dette presenteres korrekt i reisesøk og annen informasjon ut mot publikum.

Nasjonalt selskap administrerer brukere av registeret, inkludert tildeling av relevant ansvarsområde med redigeringsmulighet for å stoppesteder som ligger under dette.


17

Annen supplerende informasjon om stoppestedets knytning til vegnett og vegtekniske anliggender, samt noe relevant informasjon i forhold til universell utforming, kan for øvrig finnes i Nasjonal vegdatabank (NVDB).

4.3 Eierskap og tilgang • Alle stoppesteder vil tilhøre et gitt geografisk område som er underlagt en dataleverandør.

Kun den/de gitt administrasjonsansvar kan gjøre endringer på stoppestedet. Dette gjelder normalt også per modalitet, det vil si at en dataleverandør som kan endre områdets stoppesteder langs veg ikke vil være den samme som kan endre områdets stoppesteder for tog eller fly.

• Alle brukere kan se informasjon lagret om stoppesteder, men kun endre data for stoppestedene brukeren selv har ansvar for.

• Visse geografiske knutepunkt vil ikke kunne endres av andre enn nasjonalt selskap. Dette vil typisk gjelde knutepunkt i større byer der flere modaliteter møtes.

• Et stoppested kan normalt ikke legges ned uten at det er gitt en eksplisitt tidsfrist (eksempelvis en kalendermåned) dersom andre ruteoperatører benytter stoppestedet.

4.4 Administrasjon av stoppesteder Kapittelet beskriver i nærmere detalj administrasjon av stoppesteder langs vei, men tilsvarende prosess vil også gjelde andre typer stoppesteder.

For stoppesteder er det et absolutt krav at stoppestedet er etablert i det nasjonale stoppestedsregisteret før det tillates at rutedata benytter stoppet. At et stoppested ikke betjenes i en periode har ingen betydning for status i stoppestedsregisteret, så lenge stoppet "fysisk" eksisterer. Gjøres det derimot utilgjengelig for praktisk bruk, dvs. at andre operatører kan heller ikke benytte stoppet (f.eks. at stoppested-skiltet er permanent fjernet), skal stoppet legges ned i stoppestedregisteret slik at stoppestedet ikke lenger kan benyttes i rutedata.

Merk at i tilfeller hvor stoppesteder etableres, eller opphører, uten at dette har tilknyttede fysiske objekter, er det likevel påkrevd at stoppestedet opprettes / nedlegges i stoppestedregisteret i henhold til de prosessene som dette kapittelet beskriver.

Dersom registrert posisjon ikke sammenfaller med fysisk posisjon for stoppestedet, skal dette oppdateres med riktig(e) koordinat(er) basert på offisielle kartverk. Dette regnes ikke som flytting av stoppestedet. På samme måte ansees heller ikke endring av koordinat for en Quay på et StopPlace som flytting / midlertidig flytting.

Generelt gjelder følgende:

1. Korreksjon av posisjonen for et StopPlace eller Quay kan foretas uten at det behøver å koordineres med vegeier eller utløser annen informasjonsplikt.

2. Midlertidig endring av koordinat(er), på grunn av veiarbeid eller liknende, ansees ikke som flytting. Dette skal i stedet håndteres eksplisitt i stoppestedregisteret, eller som avvik, for å unngå unødig endring av berørte rutedata.

• Knytte status eller varsel til stoppestedet, slik at publikum kan informeres. 3. Midlertidig eller permanent flytting av et stoppested, på en slik måte at rutedata for

linjer som benytter stoppestedet også må endres, skal derimot håndteres som beskrevet i de respektive avsnittene.

Merk at et stoppested som midlertidig ikke betjenes (for eksempel kun benyttet av sesongrute) behøver ikke å legges ned dersom fysisk utrustning blir stående permanent.


18

4.4.1 Opprettelse av stoppested 1. Den part som initierer opprettelsen av et nytt stoppested kontakter vegeier og anmoder om

å få utpekt en fysisk lokasjon hvor stoppestedet kan etableres. 2. Når enighet om plassering er oppnådd skal stoppestedet opprettes i stoppestedsregisteret,

hvor det automatisk tildeles et ID-nummer, samt gis en startdato som viser når stoppestedet vil være fysisk er klart til å tas i bruk.

3. Vegeier oppretter stoppestedet fysisk og gir melding til ansvarlig part for oppdatering i stoppestedsregisteret.

4. Stoppestedsadministrator oppdaterer stoppestedsregisteret med informasjon om de parametere de er ansvarlige for. Data hentes også fra NVDB der disse finnes.

5. Stoppestedsadministrator oppdaterer eventuelt gyldig startdato for når stoppestedet kan tas i bruk. (Sluttdato for betjening av stoppestedet settes kun i de tilfeller hvor dette er kjent, for eksempel i forbindelse med midlertidig vegarbeid.)

Tilsvarende prosess vil også gjelde dersom man oppretter en nytt Quay under et allerede eksisterende StopPlace.

4.4.2 Nedleggelse av stoppested Et stoppested nedlegges dersom det ikke lenger skal være mulig for transportmidler å betjene stoppestedet, og det dermed heller ikke skal benyttes i rutedata.

1. Stoppestedsadministratoren registrerer sluttdato for betjening av stoppestedet i stoppestedsregisteret og informerer vegeier.

Merk at et nytt stoppested ikke skal opprettes på (eller i umiddelbar nærhet av) en posisjon hvor det allerede eksisterer et stoppested. I slikt tilfelle må man komme til enighet med stoppestedets administrator om eventuelle endringer og annen videre bruk.

Der hvor det allerede finnes et (umiddelbart nærliggende) stoppested som er deaktivert (se Nedleggelse av stoppested), skal man ikke opprette nytt. I stedet skal det gamle stoppestedet reaktiveres gjennom å gi dette en ny startdato eller gyldighetsperiode, slik at man opprettholder sporbarhet over tid.


19

2. Fra sluttdato ansees stoppestedet som deaktivert. 3. Vegeier kan etter sluttdato nedlegge stoppestedet fysisk. Dette innebærer å fjerne de

fysiske gjenstandene som er plassert på stoppestedet.

Ved nedleggelse skal Stoppestedet ikke fjernes fra stoppestedsregisteret. Dette som følge av at eldre data, for eksempel statistikkdata eller data vedrørende billettsalg fortsatt kan henvise til stoppestedet. Stoppestedet kan også tenkes gjenopprettet, for eksempel om det gjelder et sesongstoppested hvor fysisk utrustning bare er periodevis fjernet eller utilgjengelig. Stoppestedet skal i stedet merkes med en gyldighetsdato i tillegg til opplysning om tilstand, dette er nærmere beskrevet for dataobjekt StopPlace i vedlegg Netex profil Norge.

Etter deaktivering av et stoppested, kan ingen dataleverandører benytte dette stoppestedet i sine rutedata. (Dette gjelder helt frem til stoppestedet eventuelt reaktiveres igjen).

Tilsvarende prosess vil også gjelde når man nedlegger en betjent Quay under et StopPlace.

4.4.3 Flytting av stoppested Når et stoppested endres konseptuelt til å være et annet stopp (f.eks. legges til et annet sted og gis nytt navn), skal dette håndteres som en flytting. Dette foregår prinsipielt som en nedleggelse av et eksisterende stoppested og en opprettelse av et nytt stoppested - men i omvendt rekkefølge.

1. Det nye stoppestedet opprettes som beskrevet i kapittel ”Opprettelse av stoppested”. 2. Det eksisterende stoppestedet nedlegges som beskrevet i kapittel ”Nedleggelse av

stoppested”.

Etter nedleggelse kan ikke det opprinnelige stoppestedet lenger benyttes i rutedata, og må erstattes av det nyopprettede. Stoppestedregisteret vil automatisk ivareta koplingen mellom gammel og nytt stoppested dersom relevant.

4.4.4 Midlertidig flytting av stoppested En midlertidig endring av et stoppested svarer til en tidsbegrenset nedleggelse av et stoppested og en midlertidig opprettelse av et nytt stoppested. Arbeidsflyten følger derfor de samme beskrivelsene som ovenfor.

1. Det midlertidige stoppestedet opprettes som beskrevet i kapittel ”Opprettelse av stoppested”.

2. Stoppestedet som skal flyttes midlertidig nedlegges som beskrevet i kapittel ”Nedleggelse av stoppested”.

Når den midlertidige endringen skal avsluttes gjennomføres følgende aktiviteter:

1. Det opprinnelige stoppestedet gjenåpnes (fornyes med ny startdato) og eventuelt ajourføres/oppdateres og håndteres som øvrig som beskrevet i kapittel ”Opprettelse av stoppested”.

2. Det midlertidige stoppestedet nedlegges som beskrevet i kapittel ”Nedleggelse av stoppested”.

Merk at ved midlertidig flytting av stoppested bør dette informeres til publikum også på de fysiske lokasjonene i den utstrekning som er relevant.

4.4.5 Meldingsutveksling Initiell innlasting av data til stoppestedregisteret vil foregå ved at alle selskaper sender inn sine stoppesteder i henhold til formater på forhånd godkjent av nasjonalt selskap.


20

Et absolutt kriterium for å holde stoppestedsinformasjonen oppdatert til en hver tid, er at stoppestedsadministratorer vedlikeholder dataene i stoppestedsregisteret. Endringer skal derfor skje fortløpende på følgende måte:

• Alle operasjoner kan gjøres enten via et servicelag eller via et visuelt brukergrensesnitt mot stoppestedsregisteret.

o Meldingsutveksling via servicelaget vil foregå på NeTEx-formatet.

Mange operatører benytter stoppesteder de ikke er administrator for, av den grunn er man nødt til å vite om endringer som gjøres på disse. Fra stoppestedsregisteret vil det derfor, med jevne mellomrom, genereres rapporter over hvilke stoppesteder som er blitt endret på siden forrige rapport. Disse vil bli distribuert per epost samt i leverandørportalen til alle som har trafikk til et gitt stoppested, og vil blant annet omfatte:

• Dersom et stoppested blir nedlagt, flyttet eller midlertidig flyttet skal dette rapporteres av systemet til berørte ruteoperatører.

• Når et stoppested får nytt navn skal dette formidles til alle berørte ruteoperatører.

Det vil også legges til rette for at interessenter selv kan hente ned mer detaljerte eksporter fra stoppestedsregisteret, der man kan spesifisere hvilke områder og typer stoppesteder man ønsker å ha med.

4.5 Standard for navngiving av stoppesteder For å gi et enhetlig system der alle norske stoppesteder har navn etter samme norm, stilles det spesifikke krav til navngivning av disse. Retningslinjene tar utgangspunkt i etablert konvensjon for stoppestedsnavn, hvor eier bestemmer navnet basert på føringer for hvordan dette skal utformes.

4.5.1 Grunnregler Stoppestedets navn fastsettes av den som har eierskapet til stoppestedet, basert på et eller begge av følgende prinsipper:

1. Den reisende skal ut fra navnet forstå hvor stoppestedet er. • For eksempel: Øvre Skurubergsvei 62

2. Den reisende skal ha et unikt og tydelig stoppestedsnavn å forholde seg til. • For eksempel: Tørrisrampa

Stoppestedsnavn skal i hovedsak være i ubestemt form (for eksempel skole, ikke skolen), og ved navngivning eller endring av navn anbefales det generelt at ordlyden i navnet følger kutyme for godt språk. Stoppestedsnavn kan benytte lokal målform og dialekt, såfremt det er i henhold til stedsnavngivningsregler (offentlig vedtatt stedsnavn) fra Kartverket. Se også Lov om stadnamn (stadnamslova) §4, offentlige eiere er pålagt å følge denne loven. Som hovedregel skal det da benyttes navn som i Sentralt stedsnavnregister (SSR) har status "v" (vedtak) fremfor navn med status "g" (godkjent).

4.5.2 Struktur Et stoppestedsnavn består av en eller flere av følgende elementer:

Ved behov for flere navn på samme stoppested, for eksempel ved krav om flerspråklig støtte eller folkemunne-navn, kan dette dekkes gjennom NeTEx-standardens funksjonalitet for alternative navn på stoppestedet.


21

Type Typekode Beskrivelse Eksempel

Egennavn R

Stoppestedets navn er likt navnet på noe dette ligger i tilknytning til. Skrivemåte bestemmes av kilden til navnet (for eksempel navn på en bedrift eller en skole), men kan modifiseres til bruk i holdeplassnavn så langt det fortsatt er tydelig hva kilden til navnet er (for eksempel kan "AS" fjernes fra bedriftsnavn eller man kan bruke anerkjent kortform av navnet).

• IKEA Ringsaker • Marker Mekaniske

Verksted • Universitetet i

Tromsø

Vegnavn V Stoppestedets navn er et vegnavn, men ikke et vegnummer (se P) • Skredderveien

Stedsnavn S

Stoppestedet navngis etter et geografisk sted, og må være i henhold til offisielt vedtatt navn.

• Pålerudfløyta • Ødegårdsroa • Buin

Områdenavn O

Overgripende stedsnavn som dekker et større område. Brukes sammen med Stedsnavn (S) dersom dette ikke er tilstrekkelig presist, for eksempel om flere mindre steder innenfor et nærliggende område har samme navn. Merk: Brukes ikke alene, i relevante tilfeller skal i stedet Stedsnavn (S) brukes.

• Drevjedalen • Folldalen • Stensengdalen

Typenavn T

Henviser til et entydig og kjent begrep på/i et sted (S). Følger ikke regler for egennavn, men er en generell typebeskrivelse (common use). Merk: Brukes ikke alene.

• rutebilstasjon • kai • skole

Posisjonstillegg P

Et navn som beskriver hvor i forhold til egennavn eller sted stoppestedet befinner seg. Merk: Brukes ikke alene.

• sentrum • øst • E6 • husnummer

Disse kan kombineres på følgende måter:

• E (f.eks. IKEA Ringsaker) • EP (f.eks. IKEA Ringsaker parkering) • EV (f.eks. AMFI Narvik Markveien) • S (f.eks. Pålerudfløyta) • SV (f.eks. Skillebekk Trondheimsveien)


22

• SO (f.eks. Ødegårdsroa Snertingdalen) • ST (f.eks. Stryn rutebilstasjon) • SP (f.eks. Stryn rv. 15) • V (f.eks. Skredderveien) • VP (f.eks. Nesveien 62)

Generelt skal stoppestedsnavn som for eksempel «Skolen», «Sykehuset», «Rutebilstasjonen» eller liknende i helhet unngås. Disse navngis fullt ut for å unngå navnekonflikt, da det finnes svært mange skoler, sykehus og rutebilstasjoner.

4.5.3 Geografisk henvisning Navn som står i forhold til hverandre skal være så spesifikke som nødvendig for å unngå misforståelser. Stoppesteder der navn er generelle (S) må ikke blandes med navn som er spesifikke (f.eks. SP, ST) på en måte som gjør at navnets geografiske henvisning overlapper med et annet stoppested.

Eksempelbilde: I første kartutsnitt viser det generelle navnet «Vikersund» til hele tettstedet og vegnavnet Ringeriksvegen til en lang strekning som krysser sentrum og nordre deler av tettstedet. Dette gir en stor overlapping for navnene. I de to følgende eksemplene har navnene blir mer spesifikke og gir mer entydig mening om posisjon.

Langs vei bør stoppestedsnavn som generell regel fastsettes ut fra kryssende veier på tvers av kjøreretningen, og normalt ikke navngis etter veien kjøremønsteret går langs med.

Eksempelbilde: Stoppestedsangivelse langs Nannestadvegen i eller ved krysset til Åsvegen bør navngis etter den kryssende veien, da dette blir vesentlig mer presist i forhold til kjøremønstret.


23

4.5.4 Gruppering av stoppesteder Stoppesteder skal ha felles navn når:

• Alle stedets stopp ligger innenfor et tydelig avgrenset område, fortrinnsvis med samsvarende fremkommelighet mellom disse

• Stoppestedene er knyttet sammen eller på annen måte er lagt til rette for en naturlig reisemessig samhørighet

Stoppesteder bør gis felles navn når:

• Alle stedets stopp ligger fysisk nære i et område med fysisk sammenheng eller annen åpenbar samhørighet

o F.eks. når stoppene er synlig fra hverandre • Det er en naturlig multimodalitet

o F.eks busstopp tilknyttet til en lufthavnterminal eller jernbanestasjon "arver" stoppestedsnavn fra hovedtransporttypen.

Stoppesteder skal normalt ikke ha felles navn når:

• Nærliggende stopp ikke har en naturlig tilknytning o F.eks. når det ikke er mulig å bevege seg uhindret mellom dem

• Det er behov for å tydeliggjøre skillet mellom stoppene

Se også nærmere beskrivelse av stoppestedsstrukturen under Modelleringseksempler.

4.5.5 Informasjon som ikke skal ligge i stoppestedsnavnet • Ruteinformasjon • Destinasjonsinformasjon • Kommuneinformasjon • Kontaktinformasjon

Denne type data hører hjemme i egne felter, selve stoppestedsnavnet skal kun inneholde navneangivelse for stoppestedet.

4.5.6 Forkortelse Forkortelser innenfor stoppestedsnavn skal i hovedsak ikke forekomme, bortsett fra i faste unntak:

• Videregående skole → vgs. (valgfritt) • Riksveg → rv. • Fylkesveg → fv. • Kommuneveg → kv.

Merk at definerte forkortelser skal være i små bokstaver, med mindre det står som innledning i en setning.

4.5.7 Spesialtegn I utgangspunktet tillates kun bokstaver, tall, bindestrek (-), skråstrek (/) og apostrof (´), i tillegg til punktum (.) i eventuelle forkortelser. Andre spesialtegn som for eksempel komma, &, +, #, «», :, [ ] og ( ) skal ikke benyttes.

4.5.8 Vegkryss Stoppesteder i vegkryss bruker følgende benevnelser (annen målform tillates også):

• kryss


24

• vegkryss • vegdele

Reglene for vegkryss omfatter ikke stoppesteder med spesifikke egennavn, som for eksempel Sinsenkrysset, Gimlekrysset eller Madlakrossen.

For stoppesteder i tett bebyggelse bør i størst mulig utstrekning kryssende vegnavn benyttes ved navngivning. Om dette ikke lar seg gjøre, anbefales det å bruke et områdesnavn (S, SP) eller beskrive posisjon med husnummer (VP). Dersom dette ikke heller gir mening kan to gatenavn brukes adskilt av en skråstrek (‘/’).

4.5.9 Stoppesteder på geografiske steder

4.5.9.1 Fylkes- og kommunegrenser Stoppesteder på fylkes- eller kommunegrenser skal ikke navngis f.eks. «Fylkesgrensa» der slikt navn ikke er forankret i lokale navn eller bedrifter, men i stedet gis eget navn i henhold til sin geografiske posisjon (områdenavn) på lik måte som andre stoppesteder.

4.5.9.2 Landegrenser Stoppesteder man benevner «Riksgrensen» må ha tilleggsinformasjon som identifiserer hvilken grensekryssing det gjelder.

• Riksgrensen E12 • Riksgrensen rv. 77 • Lutnes riksgrensen

4.5.9.3 Navnekonflikt Ved inkompatibel navngivning eller gjenbruk av navn allerede benyttet på tidligere opprettet stoppested, må nasjonalt selskap i ytterste konsekvens endre utformingen av navnet, og har derigjennom fullmakt til å sette stoppestedets endelig navn.

4.6 Stoppestedutrustning Stoppestedsregisteret vil gjøre jevnlig synkronisering mot NVDB for å hente ut attributter som går på fysisk utforming, fortrinnsvis informasjon om universell utforming. Men det kan være data som mangler, eller ikke er oppdatert, fra NVDB. Den som er ansvarlig for å administrere et stoppested i registeret er derfor pålagt å til enhver tid sørge for at stoppestedet er beriket med korrekt informasjon som gjelder:

• Universell utforming • Billettautomater • Leskur • Benker • Toaletter • Hittegods • Andre relevante attributter

4.7 Modelleringseksempler Dette kapittelet viser forskjellige typer stoppesteder, og hvordan disse skal modelleres i henhold til oppdeling og hierarki basert på retningslinjer i vedlegg NeTEx profil Norge.

Eksemplene er basert på stoppesteder i Oslo, og er sortert etter kompleksitet.


25

4.7.1 Stoppested for én type transport i én retning En vanlig type stoppested er en stopp langs gate, som betjener én type transport (for eksempel en "busslomme"). Slike stoppesteder skal modelleres som et StopPlace objekt med to Quay objekter - én i hver retning.

Gruppering av objekter Illsutrasjon

4.7.2 Stoppested langs gate med flere typer transport I store byer er det vanlig at et stoppested deles av flere typer transport, for eksempel buss og trikk, eller at bussen stopper rett ved siden av en T-banestasjon.

4.7.2.1 Solli plass – gruppering av objekter Skal modelleres på følgende måte:

• To StopPlace objekter, én for hver transporttype (StopPlace for buss og StopPlace for trikk) . • Transporttypene har hver to Quay, dvs. én i hver retning (totalt fire Quays). • En "parent" multimodal StopPlace for å gruppere de to StopPlace objektene. Dette gjøres

ved å spesifisere "ParentSiteRef" for de underliggende StopPlaces og peke til den "parent" StopPlace.


26

4.7.2.2 Solli plass – illustrasjon

4.7.2.3 Mortensrud T-banestasjon – gruppering av objekter Kan modelleres som følger:

• To Quay-objekter for T-bane (hver retning). • Quay-objekter for alle "busslommer" på stoppestedet (for modellens skyld kun vist de fire

som ligger inntil T-bane-perrongen). • En separat Quay for taxi. • Tre StopPlace objekter, én for hver transporttype. • En "parent" multimodal StopPlace for å samle de tre transporttype-spesifikke StopPlace.


27

4.7.2.4 Mortensrud T-banestasjon – illustrasjon

4.7.3 Komplisert stoppested med flere typer transport Et mer komplisert eksempel er for eksempel Nationaltheatret i Oslo, der det er samlet både buss, trikk, T-bane og tog.


28

Modellstruktur kan se slik ut:

• To Quay og to enkle StopPlace objekter for å modellere buss og trikk hver for seg, i tillegg til en "parent" StopPlace for å samle de (samme som for Solli Plass).

• To Quay og én StopPlace for å modellere T-bane. Access Space kan legges til ved behov. • Fire Quay objekter for spor 1-4, to ekstra Quay objekter for å modellere Tog-plattformene

(hvor både østgående og vestgående togløp har én plattform som deles av to spor) og gruppere de fire Quay objektene (det brukes "parentQuayRef" felt for dette formålet).

• Quay for tog modelleres også med BoardingPosition på de stoppesteder hvor relevant (for eksempelet er tre modellert, Nationaltheatret har egentlig posisjon A-G per Quay).

• Én StopPlace med Access Space for å samle Quay objektene. • Én "parent" StopPlace for å slå sammen StopPlace objektene i et <groupOfStopPlaces> hvor

<members> refererer til StopPlace (stopPlaceRef).

4.7.3.1 Nationaltheatret – gruppering av objekter

4.7.3.2 Nationaltheatret – illustrasjon


29

Andre stoppesteder, inkludert mer komplekst oppbygde, er utdypet i eksempel-katalogen for vedlegg NeTEx profil Norge.

4.7.4 Koordinatplassering Koordinatpunkter på stoppesteder skal settes på standardisert måte, slik at opprettelse, vedlikehold og feilretting gjøres ensartet for alle elementer i det nasjonale stoppestedsregisteret. Dette skal gjøres per Quay, slik at det kan reflekteres til publikum hvor kjøretøyet faktisk stopper, i henhold til retningslinjene beskrevet her. I tillegg vil en generell posisjonsangivelse for stoppestedet (StopPlace) blir automatisk utledet fra Quays, denne kan overstyres dersom stoppestedsadministrator finner det hensiktsmessig.

4.7.4.1 Buss og trikk Koordinat per Quay skal samsvare med posisjonen hvor første ledelinje (taktil merking) krysser fortauskant. Der ikke ledelinje finnes skal koordinaten settes tilsvarende posisjonen for fremste dør i kjøretøyet, der passasjerer normalt kan gå ombord.

4.7.4.2 Fly Når gate er faste strukturer, skal koordinater per Quay samsvare med fysisk posisjon for til disse. Dersom gate-posisjoner ikke er spesifisert skal flyplassens koordinat(er) være plassert der det gir mest hensiktsmessig anvisning til publikum, for eksempel sentrert på hovedterminalbygget.

4.7.4.3 Båt Koordinater per Quay skal samsvare med landgang/rampe der passasjerer/kjøretøy kommer i land.

4.7.4.4 T-bane På grunn av at de fleste T-banestopp har mange innganger, bør koordinaten plasseres midt på perrongen i forhold til langsgående retning. Der perrongen betjener to spor skal det opprettes en Quay per spor/retning, selv om begge betjenes fra samme perrong.

4.7.4.5 Tog Jernbane følger som grunnregel samme posisjonsangivelse per Quay som T-bane, men bør tilpasses til å angi midt på normalt togsett i de tilfeller hvor perrong er vesentlig lenger enn normal toglengde. I tillegg skal det angis korrekt koordinat per BoardingPosition der dette er oppmerket og/eller er spesifisert i stoppestedsangivelsen for tog som betjener stoppestedet.

4.7.5 Overgangstider og ganglenker Datakrav for ganglenker, overgangsregler og liknende er beskrevet i NeTEx profil Norge, og disse forholdene vil legges til grunn ved beregning av overgangstider for ulike passasjergrupper. Merk at planlagt / garanterte overganger må leveres som del av rutedata per linjespesifikke overgang. Andre standardforhold som benyttes ved beregning av reisetider og reisesøk-resultater (f.eks. standard overgangstid ved beregning av reiser i reisesøkemotor eller antatt ganghastighet for deler av en reise) på tvers av leverandør-data vil bli offentliggjort.

Håndbok N801 - Nasjonale rutedata Sanntids- og avviksdata

30

5 Sanntids- og avviksdata

Planlagte rutedata er i seg selv ikke nok for å kunne tilby en oppdatert reiseplanlegger. Det er derfor et stort behov for å få inn oppdaterte rutedata i sanntid, samt avviksmeldinger. Som del av Kunngjøringsplikten blir det derfor stilt krav om at alle selskaper som har i bruk et sanntidssystem skal tilgjengeliggjøre sanntidsdata for nasjonalt selskap.

Endringer i ruter og tidtabeller kan fortløpende sendes inn via vanlig rutedata-leveranse, disse vil bli publisert så snart datasettet er verifisert og prosessert (normalt 1-3 timer). Gjøres det endringer som kun berører spesifikk(e) avgang(er) med behov for kort publikasjonstid, skal dette kommuniseres ved hjelp av sanntidsmeldinger.

Dette gjelder alle endringer i oppsatt(e) rutetid(er), kjøremønster eller andre avvik i tjenester til publikum. Ved endringer som ikke påvirker publikumstilbudet, for eksempel kortvarig flytting av stoppested innenfor ubetydelig avstand på grunn av vedlikehold eller liknende, må ruteplanleggere skjønnsmessig vurdere om det er hensiktsmessig å melde inn avvik.

5.1 Krav til sanntids- og avviksinformasjon Det stilles i nåværende løsning ikke krav til at operatører skal implementere systemer for sanntids- og avviksinformasjon. Men alle dataleverandører med sanntidssystem i bruk pålegges å sende inn sanntidsdata til det nasjonale selskapet i henhold til vedlegg – SIRI profil Norge. .

5.1.1 SIRI SIRI er en felles-europeisk standard basert på WS PubSub-protokollen (Web service publish / subscribe), og er det formatet sanntids- og avviksdata skal sendes inn på. I praksis vil dette bli administrert ved at nasjonalt selskap registrerer et abonnement (subscribe) per ruteselskap, som ruteselskapene deretter sender oppdateringer (publish) til.

Innsendingen kan grovt deles i følgende faser:

1. SIRI Estimated Timetable (ET) sendes fortløpende, men benyttes kun for endringer som gjelder inneværende døgn.

o Endringer som går på kanselleringer, tilleggsavganger, forsinkelser, omkjøringer, stopp som ikke betjenes og nye stopp som betjenes skal kommuniseres her.

2. SIRI Vehicle Monitoring (VM) sendes kontinuerlig. o Oppdatering av posisjoner, samt forsinkelser i sanntid kommuniseres her. Hvis

aktuelt ruteselskap har både VM og ET-feed vil ET-feeden danne grunnlaget for forsinkelser, mens VM-feed vil oppdatere posisjoner.

3. For avviksmeldinger skal SIRI Situation Exchange (SX) benyttes.

5.1.1.1 NTP Alle systemer som sender inn sanntids- og avviksdata skal benytte en klokke synkronisert med NTP (Network Time Protocol).

SIRI-protokollen tillater ulike varianter for levering av samme type data ("dialekter" av standarden). For å unngå at det implementeres leverandøravhengige modeller for datainnsendelse, er det utarbeidet en Norsk profil basert på versjon 2.0 av SIRI. Denne beskriver i detalj profiler for henholdsvis SIRI ET, SIRI VM og SIRI SX henhold til profilens spesifikasjoner.

Håndbok N801 - Nasjonale rutedata Sanntids- og avviksdata

31

5.1.2 Presedens for data Ved mottak av fortløpende endringer som SIRI-ET vil dette overstyre innsendt rutedata. Den samme overstyringen gjelder også avviksmeldinger mottatt som SIRI-SX.

5.1.2.1 Datagyldighet 1. Rutedata mottatt som NeTEx PublicationDelivery prosesseres og publiseres fortløpende

o Endringer som ligger lenger frem i tid enn normalt prosesseringsvindu (1-3 timer) kan sendes inn som nytt datasett

o Det må alltid sendes som komplett datasett, eventuelle tidligere rutedata for gyldighetsperioden vil bli overskrevet.

2. Fortløpende endringer og avviksdata som gjelder inneværende driftsdøgn skal sendes inn som SIRI-ET / VM / SX og blir publisert umiddelbart.

o Ved mottatte endrings- og avviksmeldinger vil disse alltid overstyre eksisterende rutedata

jernbanedirektoratet.no

of 105

N801 appendixCreated by Entur ([email protected]) on behalf of Jernbanedirektoratet.

Table of contents1. Norwegian NeTEx Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 General information: NeTEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1 Data models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Profile documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.2.1 framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.2.2 stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721.2.3 network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851.2.4 timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961.2.5 fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

of 105

Norwegian NeTEx ProfileGeneral information: NeTEx

Data modelsProfile documents

frameworkstopsnetworktimetablefares

NeTEx examples catalogueOn-demand transportBrandingMultiple AuthoritiesSimple bus lineSimple rhythm based bus lineCalendarMultimodal interchangesProjectionStopPlace - simpleStopPlace - complexStopPlace - minimalisticTariff codes

General information: NeTEx

Content

PrefaceIntroduction

ReferencesExchanging information

Data submission in CompositeFrameData submission as single frames

GeneralizationVersioning

Version for profileVersions for data elements

Elements that must have versionsversion="any"Versioning in references

Validity for data elementsData elements which can override validity (ValidityCondition)

ConventionsStructure of ID's

Static ID'sCodespace

CardinalityType descriptionUse of Enumeration

Definitions

Preface

Harmonization of exchange methodology between different systems is essential to:

Entur AS on behalf of Jernbanedirektoratet

...in order to efficiently collect all timetable data from each data provider, ensure consistency of data, and increase data quality. This allowsthe creation of multimodal information systems which may be used to implement nationwide journey planning solutions and publicizebusiness neutral information to all interested parties.

for travellers

...in order to present relevant, and high-quality journey suggestions.

for 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 theircustomers.

for third party service providers

...in order to minimize unnecessary costs related to supporting multiple different exchange formats, and to contribute to continued growth ofstandardized public transport data exchange.

Introduction

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891505/NeTEx+examples+catalogue

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563901/On-demand+transport

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728727682/Branding

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891557/Multiple+Authorities

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728596652/Simple+bus+line

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563925/Simple+rhythm+based+bus+line

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728825959/Calendar

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728825972/Multimodal+interchanges

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728694895/Projection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563936/StopPlace+-+simple

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563946/StopPlace+-+complex

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728662212/StopPlace+-+minimalistic

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728596666/Tariff+codes

of 105

1. 2. 3.

NeTEx ( ) is a CEN-standard which defines the data format and description for public transport dataCEN TS 16614-1, 16614-2 og 16614-3exchanges. The standard is based on Transmodel ( ), and the reference model for permanent objects required for access to publicEN 12896transport: IFOPT (Identification of Fixed Objects in Public Transport, ).EN 28701

NeTEx supports the exchange of data necessary for stop place information, journey planning, and ticketing, and is divided into three maincategories:

Network Topology ( )CEN TS 16614-1Scheduled Timetables Plan data ( )CEN TS 16614-2Fare Information ( )CEN TS 16614-3

NeTEx was created by CEN / TC278 / WG3 / SG9 lead by France. The final part of the format was published in 2015. The format was created tosupport the needs of a collection of public transport data providers in Europe, among others ERA ( ) and UIC (European Rail Agency International

).Union of Railways

NeTEx is an XML format that facilitates the exchange of timetable data between distributed systems. Data in the NeTEx format should be used toeffectively update various information and operational applications through both file-based services and web service architectures. The official

contains a detailed explanation of the intention underlying the standard, data models and publicly available standard documentation. Inwebsite particular, " ", available under the website's -section provides a good introduction to how different concepts inNeTEx White Papers Downloadspublic transport can be modelled using NeTEx.

NeTEx is a comprehensive data format intended to describe concepts in public transport data in different ways, and in many cases, there will beparts of the specification that exceed requirements in actual implementation. Therefore, the extraction of necessary objects, which constitute aso-called NeTEx profile, should be made. Such a profile should be used to specify which parts of the NeTEx format are expected to beexchanged between systems in a given context.

This document describes NeTEx's profile Norway for the exchange of stop and timetable data between external actors and central systemsprovided by Entur. Moreover, this profile has been prepared with the assistance of the NeTEx working group in CEN (Comité européen de

).normalisation, the European Committee for Standardization

To reduce complexity, the profile is divided into several parts:

Reusable Components: frameworkInformation about StopPlaces: stopsInformation about Transport Network Information: networkInformation about Timetable: timetableInformation about Fare and Ticketing: fares

Each section describes data objects that belong to a given functionality. In addition, basic objects reused across the dataset are separated into a"commons" section.

References

http://netex-cen.eu

http://netex-cen.eu

http://netex-cen.eu/?page_id=14

of 105

The Norwegian NeTEx profile is based on the following documents:

TS 16614-1, Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topologyexchange formatTS 16614-2, Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetablesexchange formatEN 12896, Road Transport and traffic telematics - Public transport - Reference data model(Transmodel)EN 28701, Intelligent transportation systems - Public transport - Identification of Fixed Objects inPublic Transport (IFOPT)

Exchanging information

Information exchanged in the NeTEx format should be XML files containing only one root tag: PublicationDelivery

The information should be delivered with one XML file per Line, packed as ZIP-file with a flat structure (no subdirectories). It is technicallypossible to deliver each line separately, packed in separate ZIP-files if all the data objects used by each Line are defined within its PublicationDeli

. However, in order to avoid issues with overwriting and ensure good data update/deletion management, it is recommended that onlyvery stronglycomplete datasets containing all lines are exchanged. Data objects used by multiple Lines can be defined in a separate "common" XML-file (mus be prefixed with an underscore, e.g. "_common.xml") to avoid redundancy of unique objects.t

Within a , < > are defined, which consist of a set of Each frame contains all relevant objects in a singlePublicationDelivery dataObjects Frames.group and specifies common validity conditions, e.g. validity and version. This mechanism supports incremental updating of individual objects incases where the relationships between the objects are not altered and will assist in troubleshooting down to the object- or group level.

PublicationDelivery allows for any number of frames, and the same frame type can be reused multiple times. It is good practice to use as fewframes as possible so that the grouping within the same PublicationDelivery is appropriate (avoid "wrapping" objects into their own frames).Objects that naturally belong together, i.e. have the same version and validity, must be collected in the same frame.

XML example for can be found in the .PublicationDelivery GitHub-repository

Data submission in CompositeFrame

When grouping Frames into a CompositeFrame, ValidityCondition must be the same for all its frames. That is, ValidityCondition is set pernotframe, but is implicitly controlled from the CompositeFrame.

Each PublicationDelivery must contain the following two mandatory fields:<PublicationTimestamp> [data extraction time] </PublicationTimestamp>

<ParticipantRef> [codespace for data submitter] </ParticipantRef>

https://github.com/entur/profile-norway-examples/blob/master/netex/frames/publicationDelivery.xml

of 105

Data submission as single frames

When frames are grouped in a CompositeFrame, all relevant frames must have explicitly defined ValidityConditions.not

of 105

Generalization

In NeTEx, objects can be placed at many different levels, in whichever way is most purposeful. In order to avoid redundancy, the Norwegianprofile dictates that all descriptions and references should be as high up in the hierarchy as possible.

For example: can be referenced from the individual in , but in most cases, a Line will have only one mainOperator ServiceJourney Timetableoperator. This should, therefore, be referenced in , and any exceptions will be overwritten per (with reference toLine instead ServiceJourney"additionalOperators" in ).Line

Versioning

To ensure compatibility, NeTEx offers version control mechanisms which allow both sender and recipient to:

Specify the NeTEx version usedEnsures correct data handling when the parties in the exchange use different versions.Correct usage of exchanged data by the recipient.Notifications when using outdated elements etc.

Version control is based on the version attribute (VersionFrame) and should be placed on relevant objects as high up in the hierarchy as possible.

Version for profile

When submitting NeTEx XML for stop place information, or time table data, the NeTEx version has to be specified in order to instruct the recipientof how to read the data. This is accomplished by stating the profile version of the dataset.

Profile version is defined in a version attribute for the XML's PublicationDelivery root node.

Formats for profile version:

[NeTEx XSD-version]:[ProfileName]:[Profile-version]

NeTEx xsd-version is a numeric value specifying the NeTEx XSD version being used (format )X.YNO-NeTEx-<profilnavn> is the profile name with one of the following values:

stops

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Operator

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-ServiceJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-TimetableFrame

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-Line

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-ServiceJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-Line

of 105

networktimetablefares

Profile version is a numeric value specifying the Norwegian NeTEx-profile version being used (format )X.Y

Examples:

Id Meaning

version="1.08:NO-NeTEx-stops:1.3" NeTEx XSD version 1.08 with data according to Norwegian stops-profile version 1.3

version="1.08:NO-NeTEx-networktimetable:1.3" NeTEx XSD version 1.08 -profile versionwith data according to Norwegian networktimetable1.3

When the NeTEx format or the profile is updated, it will usually be backward compatible. When backward compatibility is not possible, both activeversions will be considered valid and supported, until otherwise stated.

Versions for data elements

Individual elements are also versioned, and here it is up to the creator of the dataset to define a versioning system.

The version number must be a positive whole number (integer).The version number must be increased in such a way that the latest version of the object always has the highest number.

Elements that must have versions

Most objects with an ID must also have a version (see for more details) to ensure all changes lead to an increase of versionExample cataloguenumber.

The following changes are particularly important, and require incremental versioning:

Changes in Network/GroupOfLines.Changes in Line (same ID, new version).Changes in organisations (Authority, Operator - same ID, new version).Changes in geographical data/positions for objects.New additional information (such as AlternativeName).Smaller corrections which impact information to the public (such as changes of departure times).

version="any"

NeTEx allows you to explicitly specify that an object is versioned by defining the version attribute as "any".not

An object defined outside the submitted dataset, such as external objects from the national stop place registry will always be the "current"version.

Versioning in references

A version attribute for references to a unique object defined in the same PublicationDelivery is required. This means that a reference to anelement defined within the same XML-file must be versioned. References to external objects are not versioned.

When the version attribute is stated on a reference, this reference is validated against existing objects with the same "ID + VERSION" in thecurrent PublicationDelivery. Because XML validation uses string comparison in Schema validation it is not possible to use forversion="any"references to objects with explicit version numbers. If there are several possible versions of the objects defined internally in the file, and areference to the latest version is desired, a reference version attributes should be used (just like when referencing external objects).without

Validity for data elements

All objects with a version attribute . Validity can be implicitly based on inherited values, or defined explicitly on the objectmust have a validitythrough ValidityConditions. ValidityConditions can be set for a single line or a set of lines.

This is done in of the following ways:one

ValidityCondition set explicitly per frame in PublicationDelivery.ValdityCondition for a CompositeFrame, which contains all the frames in PublicationDelivery.This defines a validity which is inherited by all objects in the dataset and applies implicitly to all subordinate frames. It is not possible tooverride ValidityCondition for subordinate frames within a CompositeFrame.

Data elements which can override validity (ValidityCondition)

All subordinate data elements implicitly inherit validity defined by ValidityCondition in CompositeFrame, or in individual Frames. When it

Note that when referring to an object with , the consistency validation of the XML-file will the existence ofboth id and version requirethe object referred to (id and version). This also applies when the version is defined as "any".

When referring to external objects (for example an ID in the national stop place registry), the version attribute must be in orderomittedfor the XML to be valid.

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370407/Eksempel-katalog+NeTEx

of 105

is necessary to override inherited validity on subordinate objects, they can be given their own explicit ValidityConditions:

Overriding ValidityCondition is defined per object.Overriding ValidityCondition is constrained by its inherited validity. This means the overriding validity must have a time span thanshorterthe inherited value.

Overriding is supported by the following objects:

Networklinesorganisations (Authority, Operator)routesserviceLinksjourneyPatterns

Overriding of Timetable- and ServiceCalendar related data must be done in a complete TimetabelFrame, and ServiceCalendarFram with anunambiguous ValidityCondition for its subordinate elements.

Conventions

Structure of ID's

Id's to NeTEx objects must follow a common pattern, and are structured in the following way:

[codespace]:[type]:[id]

codespaceCodespace represents the owner, creator, or administrator of the data. ( )see codespacestype Should always be the name of the data type (for example , , , etc.)Network Line StopPlace QuayidA numeric value, unique for the data type (unique in the context of the first two parts of the ID). Please note that the ID string only allowsnumbers (0-9), both cases of characters (A-z), dash (-), underscore (_), and the structuring colon (:).

Object ID examples:

Line RUT:Line:ABC

Route RUT:Route:3434

RoutePoint RUT:RoutePoint:43423342-3424

Static ID's

When exchanging stop place information (StopPlace, Quay etc.) with the central database, usage of nationally defined ID's is . Thisrequiredensures data integrity and uniformity over time.

It is recommended that all data objects describing continual public transport services, such as Line, Route, or ServiceJourney also maintain static, even if each dataset contains changes to them. This makes the collection and use of historical data easier, as well asID's across datasets

linking to the dataset from other datasets (between codespaces).

It would then likewise be important to reuse ID's when there are significant changes to Lines etc.not

Codespace

Just as namespace is used to identify a unique XML Schema, codespace is used in NeTEx to ensure that all elements and attributes in the XMLare unique when combined with other datasets. The central agency (Entur) assigns each data provider a unique codespace, consisting of a threeletter code, for example, "KOL" for the provider . Each dataset must have the correct codespace to pass validation.Kolumbus

Cardinality

Cardinality is a property which describes the number of instances of XML elements per document, as well as whether the element is required ornot, according to the Norwegian NeTEx profile.

0: 1 - Optional - None, or a maximum of 1 instance allowed.0: * - Optional - None, or a maximum of 1 or more instances allowed.

1: 1 - Required - At least one instance is required, but no more than one.1: * - Required - At least one or more instance is required.

Type description

Each object is described with a table:

<Inheritance hierarchy>

https://enturas.atlassian.net/wiki/pages/createpage.action?spaceKey=ROR&title=Codespace

of 105

1.

2.

Attribute/Element

Name Type Cardinality Description

The inheritance hierarchy is described in the following way:

Class < ParentClass < ParentClass < ... < ParentClass

The first column is omitted if the table only contains elements (it is used to separate attributes and elements).

DataManagedObject < EntityInVersion < Entity


attr responsibilitySetRef ResponsibilitySetIdType 1: 1 Points to roles and responsibility areas connected to STOP PLACE, BOARDING ZONEor ACCESS ZONE

elem keyList KeyList 0: 1 A set of key-value pairs which describes additional properties for the relevant object(LINE, STOP PLACE, BOARDING ZONE, PLANNED STOP POINT etc.), andnecessary for third-party systems (eg. ticketing, journey-planning, real-time)

elem Extentions ExtentionStructure 0: 1 Extension element for data not defined by NeTEx. PLEASE NOTE: Should only be used by approval from working group/Entur whenstrictly necessary (e.g. specific need for internal data exchange)

elem BrandingRef BrandingRefStructure 0: 1 Reference to Brand (e.g. Ruter, AtB)

Use of Enumeration

The profile documents describe the various NeTEx-objects used in Norway, with relevant fields and datatypes. Some data types areEnumeration, that is a list of predefined values allowed for the field.

There are two ways to use Enumeration:

Simple EnumerationWhen the datatype is set to xxxEnumeration (for example ), it means only one value is allowed:FacilitySetEnumeration

...<facilitySet>seatingOnly</facilitySet>...

List of EnumerationsWhen the datatype is set to xxxListOfEnumerations (for example ), it means multiple values are allowedMealFacilityListOfEnumerationsfor the same element:

...<mealFacilityList>breakfast dinner drinks</mealFacilityList>...

Definitions

Description of all NeTEx terminology used in the profile:

Term Definition

Access The physical (spatial) possibility for a passenger to access or leave the public transport system. This link may be usedduring a trip for:- the walking movement of a passenger from a PLACE (origin of the trip) to a STOP POINT (origin ofthe PT TRIP), or- the walking movement from a STOP POINT (destination of the PT TRIP) to a PLACE (destination ofthe trip).

Access Equipment Specialisation of PLACE EQUIPMENT dedicated to access (e.g. lifts, entrances, stairs, ramps, etc.).

Access Space An area within a STOP PLACE that does not give direct access to transport vehicles. Can be connected to QUAYS byPATH LINKs.

AccessibilityAssessment

The accessibility characteristics of an entity used by passengers such as a STOP PLACE, or a STOP PLACECOMPONENT. Described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITies.

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AccessEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-AccessSpace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AccessibilityAssessment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AccessibilityAssessment

of 105

AccessibilityLimitation

A categorisation of the ACCESSIBILITY characteristics of a STOP PLACE COMPONENT such as a STOP PATHLINK, STOP PLACE or ACCESS SPACE to indicate its usability by passengers with specific needs, for example,those needing wheelchair access, step-free access or wanting to avoid confined spaces such as lifts.

Actual VehicleEquipment

An item of EQUIPMENT of a particular type actually available in an individual VEHICLE.

Address The descriptive data associated with a PLACE that can be used to describe the unique geographical context of aPLACE for the purposes of identifying it. Can further be specified as either a ROAD ADDRESS, a POSTAL ADDRESSor both.

Addressable Place A PLACE which may have an address.

Allowed LineDirection

A set of allowed DIRECTIONs that can be used on a given ROUTE.

Alternative Name An alternative name for the entity.

Assignment A set of properties to be applied to another element. It has a name and an order.

Assistance Service A specialisation of LOCAL SERVICE for ASSISTANCE providing information like language, accessibility trained staff,etc.

Authority The organisation under which the responsibility of organising the transport service in a certain area is placed.

Availability Condition VALIDITY CONDITION stated in terms of DAY TYPES and PROPERTIES OF DAYs.

Block The work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at aPARKING POINT. Any subsequent departure from a PARKING POINT after parking marks the start of a new BLOCK.The period of a BLOCK has to be covered by DUTies.

Boarding Position A location within a QUAY from which passengers may directly board, or onto which passengers may directly alightfrom, a VEHICLE.

Branding An arbitrary marketing classification.

CheckConstraint Characteristics of e.g. SITE COMPONENT or SERVICE JOURNEY, such as check-in, security screening, ticketcontrol or immigration, that may potentially incur a time penalty that should be allowed for when journey planning.

Common Section A shared set of LINKS or POINTs. A part of a public transport network where the ROUTEs of several JOURNEYPATTERNs are going in parallel and where the synchronisation of SERVICE JOURNEYs may be planned andcontrolled with respect to commonly used LINKs and STOP POINTs. COMMON SECTIONs are defined arbitrarily andneed not cover the total lengths of topologically bundled sections.

Compound Train A VEHICLE TYPE composed of a sequence of more than one vehicles of the type TRAIN.

Contact Details Contact details for ORGANISATION for public use.

Coupled Journey A complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining coupledtogether all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE JOURNEY.

Crossing Equipment A specialisation of PLACE ACCESS EQUIPMENT for CROSSING EQUIPMENTs (zebra, pedestrian lights, acousticdevice sensors, tactile guide strips, etc.).

Cycle StorageEquipment

Specialisation of PLACE EQUIPMENT for cycle storage.

Data Managed Object An ENTITY in VERSION that can be associated with a RESPONSIBILITY SET that describes who has responsibilityfor managing the data.

Data Source The DATA SOURCE identifies the system which has produced the data. References to a data source are useful in aninteroperated computer system.

Day Type A type of day characterized by one or more properties which affect public transport operation. For example "weekdayin school holidays".

Day Type Assignment Associates a DAY TYPE with an OPERATING DAY within a specific Calendar. A specification of a particular DAYTYPE which will be valid during a TIME BAND on an OPERATING DAY.

Dead Run A non-service VEHICLE JOURNEY.

Default Connection The physical (spatial) possibility for a passenger to change from one public transport vehicle to another to continue thetrip. It specifies default times to be used to change from one mode of transport to another at an area or national levelas specified by a TOPOGRAPHIC PLACE, STOP AREA or SITE ELEMENT. It may be restricted to a specific MODEor OPERATOR or only apply in a particular direction of transfer, e.g. bus to rail may have a different time for rail tobus.

Delivery Variant A variant text of a NOTICE for use in a specific media or delivery channel (voice, printed material, etc).

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AccessibilityLimitation

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AccessibilityLimitation

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-ActualVehicleEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-ActualVehicleEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Address

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-AddressablePlace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-AllowedLineDirection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-AllowedLineDirection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AlternativeName

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Assignment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AssistanceService

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Authority

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AvailabilityCondition

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-AvailabilityCondition

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-BoardingPosition

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Branding

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-CheckConstraintStructure

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-CommonSection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-CompoundTrain

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-ContactDetails

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-CoupledJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-CrossingEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-CycleStorageEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-CycleStorageEquipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-DataManagedObject

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-DataSource

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-DayType

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-DayTypeAssignment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-DeadRun

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-DefaultConnection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-DeliveryVariant

of 105

Destination Display An advertised destination of a specific JOURNEY PATTERN, usually displayed on a headsign, on the front of avehicle, or at other onboard locations. This information can be updated dynamically as the journey progresses, inparticular when crossing VAI points.

Destination DisplayVariant

Alternative DESTINATION DISPLAY, generally aimed at specific media (SMS, email, etc).

Direction A classification for the general orientation of ROUTEs.

DistributionChannel An outlet for selling a product.

Entity Any data instance to be managed in an operational Version Management System. When several data sources coexist(multimodality and/or interoperability), an ENTITY has to be related to a given DATA SOURCE in which it is defined.

Entity In Version The ENTITY associated to a given VERSION.

Entrance A physical entrance or exit to/from a SITE. Can be a door, barrier, gate or another recognizable point of access.

Entrance Equipment Specialisation of PLACE ACCESS EQUIPMENT for ENTRANCEs (door, barrier, revolving door, etc.).

Equipment An item of equipment installed either fixed (PLACE EQUIPMENT) or on-board vehicles (VEHICLE EQUIPMENT). Aservice (LOCAL SERVICE such as LEFT LUGGAGE, TICKETING SERVICE) is considered as immaterial equipmentas well.

Equipment Place Designated Place within a SITE for locating EQUIPMENT.

Facility Set A set of FACILITIES that may be associated with an ENTITY and subject to a specific VALIDITY CONDITION.

Fare Product An immaterial marketable element (access rights, discount rights etc), specific to a CHARGING MOMENT.

Flexible Area A specialisation of a FLEXIBLE QUAY (which is abstract) to identify what is the catchment area for a flexible service(so that a stop finder can find the nearest available types of transport). It is a named zone visited by a particular modeof transport. It is part of the SITE data set rather than the service data set, since it can be defined, and existsindependently from an actual service.

Flexible Line A specialisation of LINE for flexible service. As all the service on a LINE may not all be flexible, flexibility itself isdescribed at JOURNEY PATTERN level (meaning that a separate JOURNEY PATTERN is needed for each type offlexibility available for the line).

Flexible LinkProperties

Set of properties describing the flexible characteristics of a LINK. A composition is used with LINK in order to avoidmultiple inheritances and a type explosion of link subtypes

Flexible PointProperties

Set of characteristics describing the possible flexibility of POINTs. A composition is used with POINT in order to avoidmultiple inheritances.

Flexible Quay A physical ZONE such as a section of a road where a flexible service is available on demand. The existence of thezone makes the services visible to journey planners looking for available services for an area.

Flexible Route A specialisation of ROUTE for flexible service. May include both point and zonal areas and ordered and unorderedsections.

Flexible ServiceProperties

Additional characteristics of a FLEXIBLE SERVICE. A service may be partly fixed, partly flexible.

Flexible StopAssignment

Assignment of a SCHEDULED STOP POINT to a FLEXIBLE STOP PLACE and quay. etc.

Flexible Stop Place A specialisation of the STOP PLACE describing a stop of a FLEXIBLE SERVICE. It may be composed of FLEXIBLEAREAs or HAIL AND RIDE AREAs identifying the catchment areas for flexible services (when they use areas orflexible quays). Some FLEXIBLE SERVICE also uses regular STOP PLACEs for their stops. When assigned to aSCHEDULED STOP POINT the corresponding SCHEDULED STOP POINT is supposed to be a ZONE (the centroidpoint of the ZONE being the SCHEDULED STOP POINT).

Frequency The frequency of Journey. (Type for a HEADWAY INTERVAL.)

General Group OfEntities

A grouping of ENTITies which will be commonly referenced for a specific purpose.

Generic ParameterAssigment

A VALIDITY PARAMETER ASSIGNMENT specifying generic access rights for a class of products (e.g. a time bandlimit - 7 to 10 a.m. - for trips made with a student pass).

Group Of DistributionChannels

A grouping of DISTRIBUTION CHANNELs.

Group Of Entities A set of ENTITies grouped together according to a PURPOSE OF GROUPING, e.g. grouping of stops known to thepublic by a common name.

Group Of Lines A grouping of lines which will be commonly referenced for a specific purpose.

Group Of Operators A group of OPERATORs having, for instance, common schemes for fare collection or passenger information.

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-DestinationDisplay

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-DestinationDisplayVariant

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-DestinationDisplayVariant

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Direction

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Entity

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-EntityInVersion

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-Entrance

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-EquipmentTypes

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Equipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-EquipmentPlace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-FacilitySet

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-FlexibleArea

of 105

Group of Services A group of SERVICEs, often known to its users by a name or a number.

Group of Sales OfferPackages

A grouping of SALES OFFER PACKAGEs

Group Of Stop Places A grouping of STOP PLACEs which will be commonly referenced for a specific purpose. The term corresponds to aspecialisation of standard Transmodel concept GROUP OF ENTITIES.

Hail And Ride Area A section of Road between two points within which one may hail a bus to board it or alight from it or ask it to stop toalight.

Headway Interval A time interval or a duration defining a headway period and characterizing HEADWAY JOURNEY GROUP (e.g. every10 min, every 4-6 min).

Headway JourneyGroup

A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN having the same HEADWAY INTERVALbetween a specified start and end time (for example, every 10 min). This is especially useful for passengerinformation.

Interchange The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or differentSTOP POINTs.

Journey Common properties of VEHICLE JOURNEYs and SPECIAL SERVICEs, e.g. their link to accounting characteristics.

Journey FrequencyGroup

A group of JOURNEYs defined in order to describe special behaviour like frequency based services or rhythmicalservices (runs all xxh10, xxh25 and xxh45... for example; this is especially useful for passenger information).

Journey Headway Headway interval information that is available for all the VEHICLE JOURNEYs running on the JOURNEY PATTERN for a given TIME DEMAND TYPE, at a given TIMING POINT. This is a default value that can be superseded byVEHICLE JOURNEY HEADWAY. This information must be consistent with HEADWAY JOURNEY GROUP if available(HEADWAY JOURNEY GROUP being a more detailed way of describing headway services).

Journey Layover Time allowance at the end of each journey on a specified JOURNEY PATTERN, to allow for delays and for otherpurposes. This layover supersedes any global layover and may be superseded by a specific VEHICLE JOURNEYLAYOVER.

Journey Meeting A time constraint for one or several SERVICE JOURNEYs fixing interchanges between them and/or an external event(e.g. arrival or departure of a feeder line, the opening time of the theatre, etc.).

Journey Part A part of a VEHICLE JOURNEY created according to a specific functional purpose, for instance in situations whenvehicle coupling or separating occurs.

Journey Part Couple Two JOURNEY PARTs of different VEHICLE JOURNEYs served simultaneously by a train set up by coupling theirsingle vehicles.

Journey Pattern An ordered list of SCHEDULED STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern ofworking for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once.The first point of a JOURNEY PATTERN is the origin. The last point is the destination.

Journey Pattern RunTime

The JOURNEY PATTERN RUN TIME is the time taken to traverse a TIMING LINK in a particular JOURNEYPATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUNTIME and DEFAULT DEAD RUN RUN TIME.

Journey Pattern WaitTime

The JOURNEY PATTERN WAIT TIME represents the time a vehicle has to wait at a specific TIMING POINT INJOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLEJOURNEY WAIT TIME.

Journey Run Time The time it takes to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMANDTYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUNTIME.

Journey Timing Time-related information referring to journey timing whose value depends on the time of use and so can be associatedwith a TIME DEMAND TYPE, TIME BAND or OPERATIONAL CONTEXT.

Journey Wait Time The time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMANDTYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME.

Key List A list of alternative Key values for an element.

Level An identified storey (ground, first, basement, mezzanine, etc) within an interchange building or SITE on which SITECOMPONENTs reside. A PATH LINK may connect components on different levels.

Line A group of ROUTEs which is generally known to the public by a similar name or number.

Line Network A description of the topological connectivity of a LINE as a set of LINE SECTIONs. This is sufficient to draw a routemap for the whole line including branches and loops.

Line Section A part of a NETWORK comprising an edge between two nodes. Not directional.

Link An oriented spatial object of dimension 1 in view of the overall description of a network, describing a connectionbetween two POINTs.

of 105

Link In JourneyPattern

A SERVICE LINK or TIMING LINK in a JOURNEY PATTERN with its order in that JOURNEY PATTERN.

Link In LinkSequence

The order of a LINK in a LINK SEQUENCE to which it belongs.

Link Sequence An ordered sequence either of POINTs or of LINKs, defining a path through the network.

Location The position of a POINT with a reference to a given LOCATING SYSTEM (e. g. coordinates).

Luggage Service A specialisation of CUSTOMER SERVICE for LUGGAGE SERVICE (provides luggage service attributes like luggagetrolley, free to use, etc.).

Navigation Path A designated path between two places. May include an ordered sequence of PATH LINKs.

Network A named grouping of LINEs under which a transport network is known.

Notice A text for informational purposes on exceptions in a LINE, a JOURNEY PATTERN, etc. The information may beusable for passenger or driver information.

Notice Assignment The assignment of a NOTICE showing an exception in a JOURNEY PATTERN, a COMMON SECTION, or aVEHICLE JOURNEY, possible specifying at which POINT IN JOURNEY PATTERN the validity of the NOTICE startsand ends respectively.

Operating Day A day of public transport operation in a specific calendar. An OPERATING DAY may last more than 24 hours.

Operating Period A continuous interval of time between two OPERATING DAYs which will be used to define validities.

Operator A company providing public transport services.

Organisation A legally incorporated body associated with any aspect of the transport system.

Organisation Part A named subdivision of an ORGANISATION.

Parking A named place where Parking may be accessed. Can be a building complex (e.g. a station) or an on-street location.

Parking Area An area within a PARKING.

Parking Capacity The capacity of a PARKING.

Parking Properties PARKING specific properties other than its CAPACITY.

PassengerEquipment

Equipment for passengers that may be in a fixed within a STOP PLACE.

Passenger StopAssignment

The allocation of a SCHEDULED STOP POINT (i.e. a SCHEDULED STOP POINT of a SERVICE PATTERN orJOURNEY PATTERN) to a specific STOP PLACE for a SERVICE JOURNEY, and also possibly a QUAY andBOARDING POSITION.

Passing Time Time data concerning public transport vehicles passing a particular POINT; e.g. arrival time, departure time, waitingtime.

Path Junction A designated point, inside or outside of a STOP PLACE or POINT OF INTEREST, at which two or more PATH LINKsmay connect or branch.

Path Link A link between any two PLACEs (That is STOP PLACEs, ACCESS SPACEs or QUAYs, BOARDING POSITIONs,POINTs OF INTEREST etc or PATH JUNCTIONs) that represents a step in a possible route for pedestrians, cyclistsor other out of vehicle passengers within or between a PLACE.

Place A geographic place of any type which may be specified as the origin or destination of a trip. A PLACE may berepresented as a POINT (dimension 0) , a road section (dimension 1) or a ZONE (dimension 2).

Place Lighting A specialisation of PLACE EQUIPMENT for LIGHTING EQUIPMENT (e.g. lamp post).

Point A 0-dimensional node of the network used for the spatial description of the network. POINTs may be located by aLOCATION in a given LOCATING SYSTEM.

Point In LinkSequence

A POINT in a LINK SEQUENCE indicating its order in that particular LINK SEQUENCE.

Point Of Interest A type of SITE to or through which passengers may wish to navigate as part of their journey and which is modelled indetail by journey planners.

Point On Route A ROUTE POINT used to define a ROUTE with its order on that ROUTE.

Point Projection An oriented correspondence from one POINT of a source layer, onto an entity in a target layer: e.g. POINT, LINK,LINK SEQUENCE, COMPLEX FEATURE, within a defined TYPE OF PROJECTION.

Postal Address A specification of ADDRESS refining it by using the attributes used for conventional identification for mail. Comprisesvariously a building Identifier, Street name, Postcode and other descriptors.

of 105

Preassigned FareProduct

A FARE PRODUCT consisting of one or several VALIDABLE ELEMENTs, specific to a CHARGING MOMENT.

Projection An oriented correspondence - of the shape of an ENTITY on a source layer, - onto an ENTITY in a target layer: e.g.POINT, LINK, LINK SEQUENCE, COMPLEX FEATURE, - within a defined TYPE OF PROJECTION.

Property Of Day A property which a day may possess, such as school holiday, weekday, summer, winter etc.

Quay A place such as a platform, stance, or quayside where passengers have access to PT vehicles, Taxi, cars or othermeans of transportation. A QUAY may serve one or more VEHICLE STOPPING PLACEs and be associated with oneor more STOP POINTS. A QUAY may contain other sub QUAYs. A child QUAY must be physically contained withinits parent QUAY.

Ramp Equipment A specialisation of PLACE ACCESS EQUIPMENT for RAMPs (provides ramp attributes like length, gradient, etc.).

Refunding Whether and how the product may be refunded.

Road Address A specialisation of ADDRESS refining it by using the characteristics such as road number, and name used forconventional identification of along a road.

Rough Surface A specialisation of PLACE EQUIPMENT for rough surfaces, giving properties of surface texture, mainly for impairedperson information.

Route An ordered list of located POINTs defining one single path through the road (or rail) network. A ROUTE may passthrough the same POINT more than once.

Route Link An oriented link between two ROUTE POINTs allowing the definition of a unique path through the network.

Route Point A POINT used to define the shape of a ROUTE through the network.

Rhythmical JourneyGroup

A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN having the same "rhythm" every hour (forexample, ‘runs at xxh10, xxh25 and xxh45 past the hour’) between a specified start and end time.

Sales Offer PackageSubstitution

SALES OFFER PACKAGE that may be used to substitute base SALES OFFER PACKAGE.

Sanitary Equipment A SANITARY FACILITY, e.g. WC, Shower, baby change.

Scheduled Stop Point A POINT where passengers can board or alight from vehicles.

Schematic Map A map representing schematically the layout of the topographic structure of PLACEs (e.g. a set of SITEs) or the publictransport network (a set of LINEs). It can include a pixel projection of a set of ENTITies onto a bitmap image so as tosupport hyperlinked interactions.

Schematic MapMember

Projection of a transport network object on a SCHEMATIC MAP.

Service Calendar A collection of DAY TYPE ASSIGNMENTs.

Service Exclusion A constraint on the use of a service. The service, on this specific JOURNEY PATTERN (usually an FTS JOURNEYPATTERN), cannot operate when another (regular) service operates. This may occur only on a subpart of theJOURNEY PATTERN, or only on one or some specific SCHEDULED STOP POINTs within the pattern.

Service Facility Set Set of FACILITies available for a SERVICE JOURNEY or a JOURNEY PART. The set may be available only for aspecific VEHICLE TYPE within the SERVICE (e.g. carriage built with a low floor).

Service Journey A passenger carrying VEHICLE JOURNEY for one specified DAY TYPE. The pattern of working is in principle definedby a SERVICE JOURNEY PATTERN.

Service JourneyInterchange

The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or differentSTOP POINTs.

Service Link A LINK between an ordered pair of STOP POINTs. Service links are directional - there will be separate links for eachdirection of a route.

Service Link InJourney Pattern

The use of a SERVICE LINK in a specified order within a JOURNEY PATTERN or SERVICE PATTERN.

Shelter Equipment A specialisation of WAITING EQUIPMENT for a SHELTER.

Sign Equipment SIGN EQUIPMENT can define signs visible to passengers at places in a SITE, such as PLACE SIGNS, DIRECTIONSIGNs, etc. these can be used to provide guidance.

Site A type of PLACE, such as a STOP PLACE, POINT OF INTEREST or ADDRESS, to which passengers may wish totravel. A SITE can have designated ENTRANCEs that represent the available points of access for different USERNEEDs.

of 105

Site Connection The physical (spatial) possibility for a passenger to change from one public transport vehicle to another to continue thetrip, determined by physical locations, such as SITEs and/or its components and/or ENTRANCEs, in particular, STOPPLACEs and/or its components. Different times may be necessary to cover the resulting distance, depending on thekind of passenger.

Site Element A type of PLACE specifying common properties of a SITE or a SITE COMPONENT to describe it., includingaccessibility.

Site Equipment A specialisation of PLACE EQUIPMENT for SITEs (e.g. LUGGAGE LOCKER, WAITING EQUIPMENT, TROLLEYSTAND, etc.)

Site Facility Set Set of enumerated FACILITY values that are relevant to a SITE (names based on TPEG classifications, augmentedwith UIC etc.).

Special Service A passenger carrying VEHICLE JOURNEY for one specified DAY TYPE. The pattern of working is in principle definedby a SERVICE JOURNEY PATTERN.

Stop Assignment The allocation of a SCHEDULED STOP POINT (i.e. a SCHEDULED STOP POINT of a SERVICE PATTERN orJOURNEY PATTERN) to a specific STOP PLACE, for either a Passenger JOURNEY or VEHICLE SERVICE.

Stop Place A place comprising one or more locations where vehicles may stop and where passengers may board or leavevehicles or prepare their trip. A STOP PLACE will usually have one or more well-known names.

Stop Place Space A physical area within a STOP PLACE, for example, a QUAY, BOARDING POSITION, ACCESS SPACE orEQUIPMENT PLACE.

Stop Point In JourneyPattern

A POINT in a JOURNEY PATTERN which is a SCHEDULED STOP POINT.

Suitability A statement of whether a particular USER NEED can be met. It can be used to state whether a SITE can be accessedby a passenger with a particular USER NEED.

Tariff Zone A ZONE used to define a zonal fare structure in a zone-counting or zone-matrix system.

Template ServiceJourney

A VEHICLE JOURNEY with a set of frequencies that may be used to represent a set of similar journeys differing onlyby their time of departure.

Template VehicleJourney

A repeating VEHICLE JOURNEY for which a frequency has been specified, either as a HEADWAY JOURNEYGROUP (e.g. every 20 minutes) or a RHYTHMICAL JOURNEY GROUP (e.g. at 15, 27 and 40 minutes past the hour)has been specified.

Ticketing Equipment A specialisation of PASSENGER EQUIPMENT for TICKETING

Ticket ValidatorEquipment

A specialisation of PASSENGER EQUIPMENT (PLACE EQUIPMENT) for TICKET VALIDATOR.

Timeband A period in a day, significant for some aspect of public transport, e.g. similar traffic conditions or fare category.

Timetable A set of timetable data (VEHICLE JOURNEYs, etc.) to which the same VALIDITY CONDITIONs have been assigned.

Timetabled PassingTime

Long-term planned time data concerning public transport vehicles passing a particular POINT IN JOURNEYPATTERN on a specified VEHICLE JOURNEY for a certain DAY TYPE.

Timing Link An ordered pair of TIMING POINTs for which run times may be recorded.

Timing Link InJourney Pattern

The position of a TIMING LINK in a JOURNEY PATTERN. This ENTITY is needed if a TIMING LINK is repeated in thesame JOURNEY PATTERN, and separate information is to be stored about each iteration of the TIMING LINK.

Timing Point A POINT against which the timing information necessary to build schedules may be recorded.

Timing Point InJourney Pattern

A NODE in a JOURNEY PATTERN which is a TIMING POINT.

Topographic Place A type of PLACE providing the topographical context when searching for or presenting travel information, for exampleas the origin or destination of a trip. It may be of any size (e.g. County, City, Town, Village) and of different specificity(e.g. Greater London, London, West End, Westminster, St James s). A TOPOGRAPHICAL PLACE must always havean official name.

Train A vehicle composed of TRAIN ELEMENTs in a certain order, i.e. of wagons assembled together and propelled by alocomotive or one of the wagons.

Train Component A specification of the order of TRAIN ELEMENTs in a TRAIN.

Train Element An elementary component of a TRAIN (e.g. wagon, locomotive).

Train In CompoundTrain

An instance of a TRAIN making up a COMPOUND TRAIN.

Train StopAssignment

The association of a TRAIN COMPONENT at a SCHEDULED STOP POINT with a specific STOP PLACE and alsopossibly a QUAY and BOARDING POSITION.

of 105

Transfer The possibility of a passenger to transfer between two PLACEs. May have times associated with the transfer.

Transfer Duration The time it takes to complete a TRANSFER.

Type Of Service Classification of a Service.

UsageParameter A parameter used to specify the use of a SALES OFFER PACKAGE or a FARE PRODUCT.

UsageParameterPrice A set of all possible price features of a USAGE PARAMETER: discount in value or percentage etc.

Valid Between Simple version of a VALIDITY CONDITION. Comprises a simple period. NO UNIQUENESS CONSTRAINT.

Validity Condition Condition used in order to characterise a given VERSION of a VERSION FRAME. A VALIDITY CONDITION consistsof a parameter (e.g. date, triggering event, etc.) and its type of application (e.g. for, from, until, etc.).

Validity ParameterAssignment

An ACCESS RIGHT PARAMETER ASSIGNMENT relating a fare collection parameter to a theoretical FAREPRODUCT (or one of its components) or a SALES OFFER PACKAGE.

Validity Trigger External event defining a VALIDITY CONDITION. E.g exceptional flow of a river, bad weather, road closure for works.

Vehicle A public transport vehicle used for carrying passengers.

Vehicle Journey The planned movement of a public transport vehicle on a DAY TYPE from the start point to the end point of aJOURNEY PATTERN on a specified ROUTE.

Vehicle JourneyHeadway

Headway interval information that is available for a VEHICLE JOURNEY (to be understood as the delay between theprevious and the next VEHICLE JOURNEY). This information must be consistent with HEADWAY JOURNEY GROUPif available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services).

Vehicle JourneyLayover

A time allowance at the end of a specified VEHICLE JOURNEY. This time supersedes any global layover orJOURNEY PATTERN LAYOVER.

Vehicle Journey RunTime

The time it takes to traverse a specified TIMING LINK IN JOURNEY PATTERN on a specified VEHICLE JOURNEY.This gives the most detailed control over times and overrides the DEFAULT SERVICE JOURNEY RUN TIME andJOURNEY PATTERN RUN TIME and the DEFAULT DEAD RUN RUN TIME. There may be different times fordifferent TIME DEMAND TYPES.

Vehicle Journey WaitTime

The time for a vehicle to wait at a particular TIMING POINT IN JOURNEY PATTERN on a specified VEHICLEJOURNEY. This wait time will override the JOURNEY PATTERN WAIT TIME.

Vehicle Type Type of VEHICLE.

Version A group of operational data instances which share the same VALIDITY CONDITIONs. A version belongs to a uniqueVERSION FRAME and is characterized by a unique TYPE OF VERSION.

VersionedChild A child ENTITY whose RESPONSIBILITY SET must be the same as its containing parent object, and which cannotexist independently of its parent in a repository, for example, a POINT IN PATTERN. Thus in practice, if the parent isdeleted, so will the child be.

Via A location (e.g. a ROUTE POINT) used to distinguish a ROUTE form another ROUTE. It may be used forDESTINATION DISPLAYs

Waiting Equipment A specialisation of SITE EQUIPMENT for WAITING EQUIPMENTs (shelter, waiting room, etc.).

Zone A two-dimensional PLACE within the service area of a public transport operator (administrative zone, TARIFF ZONE,ACCESS ZONE, etc.).

Zone Projection An oriented correspondence from one ZONE in a source layer, onto a target entity: e.g. POINT, COMPLEXFEATURE, within a defined TYPE OF PROJECTION.

Data models

Content

ContentContextFramework

LocationNeTEx data model for location objects

OrganisationNeTEx data model for organisation

ValidityNeTEx data model for validity

Messages/footnotesNeTEx data model for messages

StopsStopPlace

NeTEx data model for stop placeMonomodal StopPlace

of 105

QuayMultimodal StopPlaceGroup Of StopPlacesFlexibleStopPlace

NeTEx data model for a flexible stop placeEquipment

FacilityEquipment

Transport networksNetwork

NeTEx data model for networkConceptual NeTEx model for network

RouteJourney Pattern

NeTEx data model for JourneyPatternNeTEx overall conceptual model for JourneyPatternNeTEx detailed conceptual model for JourneyPattern

Flexible transportationNeTEx data model for flexible transport

Transfers and InterchangesNeTEx data model for interchange

NeTEx timetable data representationNeTEx data model for calendar

TimetableNeTEx data model for Vehicle JourneyNeTEx conceptual model for ServiceJourney

DeviationsData enrichment

Conceptual model for enrichment of data in NeTEx

This document contains additional information for the Norwegian NeTEx profile, including overall data models and conceptual descriptions of howthe elements from NeTEx will be used.

Context

Transmodel (European Standard “Public Transport Reference Data Model”, ) is the reference model andhttp://www.transmodel-cen.euframework, used to define the Norwegian data model for exchanging public transport information, respectively, NeTEx (Network TimetableExchange, ) for stop places, timetable data and SIRI (Service Interface for Real time Information, )http://netex-cen.eu/ https://www.vdv.de/siri.aspx. Both data models are implemented as XML, and defined in respective XML Schemas (XSD). Further requirements for using the exchangeformats are specified in Norwegian profiles for NeTEx and SIRI.

The framework's implementations form the basis of the services offered for national public transport data in Norway:

http://www.transmodel-cen.eu

http://netex-cen.eu/

https://www.vdv.de/siri.aspx

of 105

Framework

Location

One point ( ) is a node in the network with specified location ( ). It can be a stop place, Point of Interest (POI) or a ticket control pointPoint Locationat a station. The point can be used to specify a larger unit - e.g. an area, using projection ( ). A point can also be used for thePoint Projectiondefinition of a leg, e.g. to describe the actual path between two stop places. Leg can be described by using a link ( ).Link

To define a larger area, (e.g. Tariff Zone) use the objects, which contain different points, and can also be projected onto a map using Zone ZoneP.rojection

NeTEx data model for location objects

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Point

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Location

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-PointProjection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Link

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-ZoneProjection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-ZoneProjection

of 105

Organisation

If you need to describe the organisational structure, you have a selection of several objects:

Organisation may be either the entity (responsible for providing public transport services), or the company fulfilling theAuthority Operator physical public transport role. Operators can be further grouped into if necessary.GroupOfOperatorsOrganisations can be divided into departments ( ) to better reflect their structure.DepartmentEach organisation has contact information and postal address.A unique area of responsibility ( ) can be assigned to an organisation to specify the parts of dataset it represents.Responsibility Set

NeTEx data model for organisation

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Authority

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Operator

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-GroupOfOperators

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-ResposibilitySet

of 105

Validity

Every single object in NeTEx can be versioned which allows changes without affecting unchanged data. A version of an object is tied to a validitydescription ( ) which specifies when the definition takes effect.Validity Condition

Validity Condition has two specializations:

Trigger ( ) which allows long-term changes to be specified (e.g. the stop is moved during a period of flooding, or whileValidity Triggerthere is a sports event). The trigger initiates the change.AvailabilityCondition used to describe temporary conditions with precisely specified dates.

NeTEx data model for validity

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-ValidityTrigger

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-AvailabilityCondition

of 105

Messages/footnotes

Delivering messages to customers is essential when there are deviations or special circumstances for a service. Messages are created using Noti objects (free text messages) and assigned to different objects using a , e.g. for a single journey ( ) or a routece NoticeAssignment VehicleJourney

with a specific . Notices can be delivered in different variations depending on the media it is meant to be displayed on, e.g. a shortJourneyPatternmessage for the information screen at the bus stop, a longer message for mobile devices, and an expanded message for website presentation.This is handled by using .DeliveryVariant

NeTEx data model for messages

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Notice

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Notice

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-VehicleJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-JourneyPattern

of 105

Stops

StopPlace

A stop point ( ) is a special type of site ( ) normally located in a . As a , a can have multiple- s, StopPlace Site Tariff Zone Site StopPlace Parking Leve (each one with its own ), and accessibility . In addition, a is divided into subordinate (and below the Quay,ls Entrance Equipment StopPlace Quays

). Each can also have waiting areas ( ) and footpaths ( ).Boarding Positions StopPlace Access Space NavigationPath

The structure of stop places is subject to variation. It can be anything from a simple kerb stop, to the most complex transport hubs. The followingstructure should be used to describe a stop place:

A always has at least one .StopPlace QuayA may have .StopPlace AccessSpacesA may have a parent (maximum 1 level of nesting).StopPlace StopPlaceTwo or more StopPlaces, including parent StopPlaces, can be grouped into a .GroupOfStopPlacesA can have ( ).Quay BoardingPositions usually only relevant to trains

NeTEx data model for stop place

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-StopPlace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Site

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-TariffZone

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Parking

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Level

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Level

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Entrance

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Equipment


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-Quay

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-BoardingPosition


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-AccessSpace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-NavigationPath




https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-AccessSpace



https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-GroupOfStopPlaces


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-BoardingPositions

of 105

1. 2. 3.

1. 2. 3. 4.

1. 2.

1.

Stop places have three distinct levels of structure:

StopPlace used by one transport type. This is .MonomodalStopPlaceStopPlace used by several transport types, e.g. bus and tram. This is .MultimodalStopPlaceA combination of several StopPlace in direct proximity to each other, e.g. bus and tram next to a metro station. This is GroupOfStopPlac

.es

Note that on a must be (only for one transport type). If a is (for multiple transport types), thisQuays StopPlace monomodal StopPlace multimodalshould always be modelled as a parent consisting of one (with monomodal ) per transport type, even when theStopPlace StopPlace Quaystransport types use the exact same position for stops. It is possible to link StopPlaces which share a common position (one straddling the other,or exact same positions) using AdjacentSites, which can be useful when presenting multimodal stops on a map.

Please note: It is a requirement that both stops belonging to a parent stop have different transport types.not

Monomodal StopPlace

A MonomodalStopPlace is a simple stop place consisting of one or more . This type of stop place can only be served by one type ofQuaystransport, for example bus lines.

The following rules apply to MonomodalStopPlace:

A monomodal StopPlace cannot have any subordinate StopPlace.A monomodal StopPlace must at least have one Quay. A Quay can belong to only one monomodal stop place.A monomodal StopPlace can have one parent StopPlace.

Quay

A is an exact location where vehicles stop and travellers board, or alight. Quay

For train platforms, the can be divided into if applicable. A specifies exactly where on the platform aQuay BoardingPositions BoardingPositionpassenger should wait for the train, for example comfort class car.

The following rules apply to Quay:

Transfer is implicit within the same Quay.Quay inherits the name of its parent StopPlace

Multimodal StopPlace

A MultimodalStopPlace is a StopPlace, which serves more than one transport type. The multimodal StopPlace is the structural parent StopPlace,and it has at least two subordinate monomodal StopPlace.

Please note: It is a requirement that both stops belonging to a parent stop have different transport types.not

The following rules apply to Multimodal StopPlace:








https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-BoardingPostition

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-BoardingPosition

of 105

1. 2.

Has no Quays directly tied to it.Has no parent StopPlaces (only 1 level of nesting allowed).

Group Of StopPlaces

GroupOfStopPlaces should be used when there is a need to group several mono- and/or multimodal stop places in order to refer to themsimultaneously, usually to describe a larger and more complex StopPlace area, such as a hub or a town centre.

FlexibleStopPlace

An on demand service, or flexible line, often deviates from the static bus stops, instead a flexible stop place can be used:

A , does not have a specific position, but rather a defined area, within which the flexible transport picks up, or drops offFlexibleStopPlacepassengers depending on bookings, or other beforehand arrangements. This includes for example address to address journeys, hail and rideconcepts, or combinations thereof.

NeTEx data model for a flexible stop place

Equipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-GroupOfStopPlaces

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonNeTEx-FlexibleStopPlace

of 105

Facility

These are standardized lists describing available facilities which can be grouped into (reusable) . These are then used on relevantFacilitySetsentities.

Equipment

In order to describe the availability and usage of the , use the categories and (including ) toFacilities Equipment EquipmentTypes LocalServicedescribe for example the placement of the equipment.

Equipment normally has one .or more FacilitySets

Transport networks

Network

A network consists mainly of Line, Route and RoutePoints. To model them into the network, NeTEx uses the following structure:

A consists of several lines . Network LinesEach line is operated by an and has one or more associated with it. Operator RoutesA shows the overall physical route of a and consists of several . Route Network RoutePoints

Note that a RoutePoint isn't necessarily a . StopPlaceIn order for it to be possible to reuse the same route points across multiple routes, objects are linked to the Route using theRoutePoint"intermediate object" ( ).PointOnRoute see diagram below

NeTEx data model for network


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Equipment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-EquipmentTypes

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-LocalService


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Network

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Line

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Operator

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Route



https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-RoutePoint

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-StopPlace


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-PointOnRoute

of 105

Lines are grouped into a conceptual . The Lines are described as a set of with . Network Routes RoutePoints

Conceptual NeTEx model for network

Generally speaking, a represents the structure of a network, though the do not infer the network is traversed. ThisRoute RoutePoints howhowever, is defined by describing a given order of as a .PointOnRoute pointsInSequence

This can be illustrated by the following example: :RoutePoint vs. PointOnRoute








https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-PointInJourneyPattern

of 105

Route

Thus, a is defined as a list of , which are placed into the correct sequential order by . To further describe theRoute RoutePoints PointOnRoutespecifics of the Route, such as start, stop and turn-around points, a , linked to the Route is used.JourneyPattern

Journey Pattern

The is a general term which defines the "pattern of stops" (with- or without passengers). It consists of a sorted list of JourneyPattern ScheduledSt (stopping point for boarding or alighting) and/or "check points" (so called , used for measuring vehicle progress along theopPoint TimingPoint

pattern. The pattern references stop points ( objects) using .StopPlace stopAssignments

In addition, various time-related values can be defined if needed:

Headway - interval between two departures.RunTime - time between two neighbouring points. WaitTime - TimingPoint wait time.

NeTEx data model for JourneyPattern




https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-JourneyPattern


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-ScheduledStopPoint


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TimingPoint

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-StopPlace

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-StopAssignment

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-Timing



of 105

The pattern itself is described as a set of points in a given order, . This is usually the , but can alsopointsInSequence StopPointInJourneyPatternbe the .TimingPointInJourneyPattern

NeTEx overall conceptual model for JourneyPattern

The journey pattern is further enriched by references to scheduled stops, , which again links to physical stops ( ) throughScheduledStopPoint Quaya :StopAssignment

NeTEx detailed conceptual model for JourneyPattern

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-PointInJourneyPattern

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-StopPointInJourneyPattern

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TimingPointInJourneyPattern


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Quay

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-StopAssignment

of 105

Connection between Route and JourneyPatternAs shown in earlier example RoutePoint vs PointOnRoute a is defined as a set of in a given order, here illustrated by two Route RoutePoints routes (red and pink respectively):



of 105

How this route is operated is further defined by the JourneyPattern which consists of a set of ScheduledStopPoints in a given order, and theseagain refer to each respective Route.

Each follows the same overall pattern as the referenced , but with considerably more detail. Thus, showsJourneyPattern Route JourneyPattern 1in detail what describes generally, shows in detail, and so onRoute 1 Journey Pattern 2 Route 2 .

This forms the basis for describing the respective departures, explained in more detail in the chapter .timetable data

Flexible transportation

To model a flexible on demand transport, NeTEx offers "flexible" variants of Line and Route - and . They have theFlexibleLine FlexibleRoutesame features as regular Line and Route, but with additional fields to describe contact- and booking information. PointOnRoute can also beexpanded with which for example describes whether the point represents an area or a point.FlexiblePointProperties

NeTEx data model for flexible transport






https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370438/Datamodeller#Datamodeller-rutetabell

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-FlexibleLine

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-FlexibleRoute

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-FlexiblePointProperties

of 105

Transfers and Interchanges

Interchanges has two aspects - physical and planned. The physical action of alighting one vehicle and boarding another is represented by Conne, which also refers to in order to describe that the interchanges can occur between two nearby stops (actually quays). ction ConnectionEnd Transf

objects are then used to describe physical transfer between the arrival- and departure quays.er

The planned transfer is represented by objects which can be linked to in order to provide customers relevant transferInterchange Noticeinformation.

NeTEx data model for interchange

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Connection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Connection

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-ConnectionEnd

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Transfer

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Transfer

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Interchange

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-Notice

of 105

NeTEx timetable data representation

A timetable consists of one or more , usually modelled as (which describes a specific departure at a specificVehicleJourneys ServiceJourneytime) assuming the departure is a passenger carrying service. At least two stops ( ) are required in a ServiceJourney. The date ofPassingTimethe is specified as a , which defines a period or a date. All journeys and other relevant elements are grouped into a ServiceJourney DayType TIM

, while dates/periods are defined in a .ETABLE FRAME SERVICE CALENDAR FRAME

A central part of the structure is the relationship between VehicleJourney and which defines JourneyPattern (and perhaps StopPoints TimingPoint) for a .s Route

Once the pattern of the route has been defined, is used to describe when, and for how long, it operates. For this a OperatingDay ServiceCalendar is created to define the calendar days when the Line operates within an . It is possible to define day by day, but it is usuallyOperatingPeriodsensible to use to define day patterns, such as "Monday-Friday". Even more detailed information, such as specific public holidays, canDayTypebe defined in .PropertyOfDay

allows the linking of to through .ServiceCalendar OperatingDay DayType DayTypeAssignment

NeTEx data model for calendar

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-VehicleJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-ServiceJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TimetabledPassingTime


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-DayType



https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-ServiceCalendarFrame






https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-OperatingDay

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-ServiceCalendar

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-OperatingPeriod


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-PropertyOfDay

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-ServiceCalendar



https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-DayTypeAssignment

of 105

Timetable

When describing a timetable (schedule), is used with which specifies the (withTIMETABLE FRAME VehicleJourneys ServiceJourneyspassengers) for each journey. A can, if necessary be divided into several parts ( ), when for example using compundVehicleJourney JourneyParttrains.

It is also possible to describe rhytm based departures (for example repeating departures every 10 minutes over whole hours), or interval baseddepartures (for example departures every 15 minutes), for a defined period of the day using which JourneyFrequencyGroup TemplateServiceJour

can refer to. Alternatively a list of stop places for a ney ServiceJourney can be created by using objects refering to stops through a PassingTime.ScheduledStopPoint

NeTEx data model for Vehicle Journey





https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-JourneyPart

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-JourneyFrequencyGroup

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TemplateServiceJourney

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TemplateServiceJourney


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-PassingTime


of 105

This means each departure is defined as a ServiceJourney (usually connected to a ), used by a with one or more (Line JourneyPattern DayTypes describing dates or periods). The ServiceJourney describes the times of arrival and departure along the journey by use of StopPointInJourneyPattern for stop, with a PassingTime defining the exact times.

NeTEx conceptual model for ServiceJourney

Deviations

When describing a deviation from the common departure pattern, the , can be described in inverse by define the particular day(s)OperatingDayas .unavailable

Data enrichmentAs mentioned above, a trip can be specified on several levels in NeTEx, ranging from the parent Route via detailed JourneyPattern down to theindividual ServiceJourney.

The goal of the Norwegian NeTEx profile is to place all elements as high up in the structure as possible, in order to avoid redundancies.

CONCEPTUAL MODEL FOR ENRICHMENT OF DATA IN NETEX







https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#Generellinformasjon-TimetabledPassingTime





of 105

Profile documents

frameworkstopsnetworktimetablefares

Changelog

Date Profiledocument

Change Version

of 105

30 Aug2018

Generalinformation:NeTEx, framework,

, network, stops

timetable

This revision includes moving Håndbok N801, all profile documents, and GitHub-examples to a newdomain (Entur).

General information

Version reference changed to v1.3.

framework:

Consolidated ticketing machine-modelling into . The duplicate element TicketingEquipment TicketingFacilityL was removed from the profile.ist

Consolidated sanitary equipment-modelling into . The duplicate element SanitaryEquipment SanitaryFacilityL ist was removed from the profile.

Added VehichleScheduleFrame in order to specify Blocks for a vehicle.TariffZones should be handled as a part of stop places and should, therefore, be part of SiteFrame, ratherthan ServiceFrame.Added "cityTram" as a tram submode. To be used by "Bybanen".

stops:

Added a categorisation of GroupOfStopPlaces as a pre-defined reference to PurposeOfGrouping.Added new StopPlaceType "taxiStand"

network:

Clarification on how to structure booking information for FlexibleLines. Some previously mandatory elementsare no longer so.Removed redundant option for BookWhen (on , aadvanceOnly FlexibleLine BookingArrangementsStructurend )FlexibleServicePropertiesMoved FlexibleServiceProperties to Timetable (used only in )TimetableFrameClarification on the usage of Line PresentationChanged cardinality for Line Monitored and Line AccessibilityAssessment (previously mandatory elementsare no longer so. The reason for this is that most data providers will not be able to provide meaningfulinformation for it)Changed cardinality for ServiceLink projections (previously mandatory elements are no longer so. Thereason for this is that ServiceLinks technically have geographic positionings for parts of the way)Remove unused objects associated with flexible transport (FlexibleRoute, FlexibleLinkProperties, FlexiblePo

) since these should be modelled using the general objectsintProperties (Route, ServiceLink,).ScheduledStopPoint

Added optional field for JourneyPattern.PrivateCode

Timetable

Specified use of Priority for Interchange (specified as weighting, not sequential order).Removed optional fields and for , since this will be implicit for specifiedPlanned Advertised Interchangeinterchanges.Clarification on attributes ID and VERSION for TimetabledPassingTime required (has previously not beenvalidated due to an unhandled discrepancy of the main NeTEx XML-Schema)Clarification that referred in the .ServiceJourney has to exist PublicationDeliveryAdded possible value ServiceJourney ServiceAlteration "replaced" for usage in replacement transport.The concapt SpecialService removed from the profile (not in use). For "special" departures, use normalServiceJourney and add FlexibleServiceProperties when relevant.Added DeadRun to make modelling of trips without passengers possible.Clarification that interchanges across datasets should be defined for the receiving/departing Line at theonlyinterchange.

v1.3

07 Mar2018


, network, stops

timetable

Full export (appendix Håndbok N801) v1.2

of 105

06 Mar2018

Generalinformation:

, NeTEx, framework networ

, k timetable

General information:

Updated version references (NeTEx XSD v1.08 and Norwegian profiles v1.2)

framework:

Removed references to default values for optional fields (they are not optional, and should be handledexplicitly).New and clearer description for fields in .OrganisationPartIt is now that ContactStructure has Email, Phone or Urlrequired at least

For the field is now .CustomerServiceContactDetails, Url requiredListed allowed enumerations for DayType PropertyOfDay DayOfWeek and DayType PropertyOfDay WeeksOfMonthIt is to include the field for .no longer required Distance LinkSequenceAdded optional field to support translations of texts.AlternativeTexts NoticeAdded the " " for .NameType Label AlternativeNameFormalised the requirement for using for local time in (was already the de facto standard),TimeZone Localeand removed the optional fields and which won't be used.TimeZoneOffset SummerTimeZoneOffset

stops:

Updated version number.

network:

Specified usage of and on first- and last stop in .ForAlighting ForBoarding StopPointInJourneyPatternAdded optional field for (can be used to monitor vehicles via in real-time).Distance ServiceLinkAdded optional field for Line (can be used for alternative names).ShortNameChanged cardinality for (a previously required element is no longer required since not allLine PublicCodelines have an actual ).PublicCode

Timetable

Removed references to default values for optional fields (they are not optional, and should be handledexplicitly).Added PrivateCode as an optional field on VehicleJourney for external- or dataset specific ID's (such astrain- or trip numbers).

v1.2

13 Sep2017


, network, stops

timetable

Full export (appendix Håndbok N801) v1.1

12 Sep2017


, stops, network

timetable

All profile documents:

Consolidation of links.

General information:

Clarification regarding the use of versions.Clarification regarding ID formatting.Revised list of definitions according to changes of profile documents (added new-/removed outdatedobjects)Clarification on how a common objects file must be used.

framework:

v. 1.1

of 105

Changed cardinality for . Previously required elements are no longer required when thePoint Locationgeographic position can be derived from projection or links to another locational object.Changed incorrect cardinality for . TheZone < GroupOfPoints < GroupOfEntities < DataManagedObjectimplementation ( only allows 0 or 1 of NeTEx-XSD) gml:Polygo (not 0 to many) for .n ZoneAdded equipment type "sign": GeneralSign < SignEquipment < PlaceEquipment < Equipment <DataManagedObject

There are explicit demands for modelling stop place signs.Changed recommended modelling of walk paths to independent instead of consipathLinks, NavigationPathssting of for objects which support this, since NavigationPath can be derived from them.pathLinks, Removed redundant and optional field for AllAreasWheelchair . The information canPathLink/PathJunctionbe derived from AccessibilityAssessment MobilityImpairedAccess ( ).WheelchairAccess required valueAdded ( minus specified ) for .placeEquipments equipmentPlaces Location SiteAdded under localServices SiteChanged the abstract type to the correct data type WaitingEquipment SiteEquipment WaitingRoomEquipme

(inherits from nt )WaitingEquipmentAdjusted requirements of data fields for (specifically incl. / )Organisation Authority OperatorAdded fields for a possibly explicit for .PrivateContactDetails OrganisationAdjusted AlternativeName:

and are now .Lang NameType requiredNameType "other" no longer valid value.Removed optional fields and TypeOfName, ShortName, QualifierName Abbreviation.

Added as a possible reference in .OperatingPeriodRef DayTypeAssignmentAdded as optional field for in order to handle non-public ID's/codes.PrivateCode EquipmentAdjusted translations for cableway" and "funicular".TransportMode "Clarification of data format for language, language code, and currency.Added the "coach" in order to separate long-distance buses from local-/regional buses.TransportModeAdded the "taxi" (with TaxiSubmode)TransportModeAdded notices and for .noticeAssignments TimetableFrameAdded for .groupsOfStopPlaces SiteFrameAdded attribute which can be used for external objects in a specific version.versionRefAdded optional (which allows multiple Networks and subsequently multiple Authorities)additionalNetworksfor .SiteFrameNotices

Removed the field .TypeOfNoticeRefMade the field required (notice must have content).TextMade optional.PublicCode

stops:

Replaced optional field with optional for .PlaceCode PublicCode QuayAdded optional element for .TransferDuration PathLinkAdded optional element for .ParkingVehicleType ParkingChanged all previously required data fields for Parking to optional.Removed redundant value for Parking ParkingLayout. The concept is instead modelled bycovereddefining Parking ) Covered as or (general value for covered indoors SiteElementAdded optional element for objects of the type .PublicUse SiteElementAdded as optional field for .PrivateCode QuayClarification of data format for land- and area code.Added .GroupOfStopPlacesAdded "country", "region", "interregion" and "municipality" as allowed values for .TopgraphicPlaceType

network:

Adjusted errors in organisation references for , related to .Network AuthorityRefAdded required connection between and .Line AuthorityClarification in , and removed redundant fields and .Presentation ColourName TextColourNameClarification for the minimum required for first DestinationDisplayRef , and allStopPointInJourneyPatternsubsequent stops where changes.DestinationDisplayRemoved redundant data type .ConnectionChanged to required element for and .Name Network GroupOfLinesAdjusted data structure for .Interchange

Removed redundant field for transfer time.Added field for and .Planned AdvertisedAdded field for .MaximumWaitTime

Adjusted requirements for types to reflect technical schema validation.StopAssignmentChanged to required.TransportSubmodeRemoved field for .PublicCode DestinationDisplayRemoved from and .noticeAssignment Line, StopPointInJourneyPattern TimingPointInJourneyPatternShould be located with notices directly in .ServiceFrameAdded optional field for .RequestMethod StopPointInJourneyPatternAdded optional dataset for .BookingArrangements StopPointInJourneyPatternAdded optional field felt for .ExternalLineRef Line

timetable:

Added optional fields ArrivalDayOffset/Departure for .DayOffset TimetabledPassingTimeChanged time-specification for arrival/departure to required. Cardinality for (per PassingTimes VehicleJourn

/ServiceJourney) is specified according to this.eyChanged and to required.TransportMode TransportSubmodeClarified usage of calendar objects in a vs. free standing.ServiceCalendarChanged fields og to required when using .FromDate ToDate ServiceCalendarRemoved fra og . as it is more relevant to place notices directlynoticeAssignment Journey Interchangeunder .TimetableFrameAdded optional field for .ExternalVehicleJourneyRef Journey

of 105

05 Jan2017

framework, , stops

, networktimetable

Initial export (appendix Håndbok N801) v. 1.0

framework

Content

ContentFrames

Data conditionsFrameDefaultsCodespace

Specific componentsResourceFrameSiteFrameServiceFrameServiceCalendarFrameTimetableFrameVehicleScheduleFrame

ComponentsAbstract Types

EntityEntityInVersionDataManagedObjectKeyListTypeOfValueGroupOfEntitiesAddressAssignmentEquipment Details

EquipmentPassengerEquipmentActualVehicleEquipment

FacilitySetPlaceLinkLinkSequence

PointInLinkSequenceLinkInLinkSequence

OrganisationProjection

Basic TypesAlternativeNameContactStructureDeliveryVariantGeneralGroupOfEntitiesGroupOfPointsLocaleLanguageUsageLocationMultilingualStringProjection Types

PointProjectionZoneProjection

Address TypesPostalAddressRoadAddress

VehicleVehicleTypePassengerCapacity

Accessibility TypesAccessibilityAssessmentAccessibilityLimitationSuitability

Geographical TypesPointZonePolygon

Polygon-structureOrganisation Types

Operator

VersionCurrent version for is: framework v1.3 (last changed ) 28 May 2018

of 105

AuthorityOrganisationPartDepartmentGroupOfOperatorsBrandingDataSource

Equipment TypesAccessEquipment

EntranceEquipmentPlaceLightingRampEquipmentRoughSurfaceCycleStorageEquipment

PassengerEquipmentSanitaryEquipment

SiteEquipmentWaitingRoomEquipmentShelterEquipment

TicketingEquipmentTicketingEquipment

TicketValidatorEquipmentSignEquipment

GeneralSignLocalService

AssistanceServiceLuggageService

ServiceFacilitySetTrain Types

CompoundTrainTrainInCompoundTrainTrainTrainSizeTrainComponentTrainElement

Notice TypesNotice

AlternativeTextNoticeAssignment

Calendar TypesDayTypePropertyOfDayTimebandDayTypeAssignmentOperatingDayOperatingPeriod

TimingJourneyWaitTimeJourneyPatternWaitTimeJourneyRunTime

TimingLinkJourneyPatternRunTimeJourneyHeadway

ConstraintsCheckConstraintCheckConstraintDelay

Validity TypesValidityConditionAvailabilityConditionValidBetweenValidityTrigger

Vehicle Schedule TypesBlock

Transport Modes

This document is part of NeTEx Norwegian Profile and describes and used for public transport datacommon components generic conceptsexchange in the NeTEx format.

Frames

Frames are used for logical grouping of different NeTEx concepts:

- frame for an unstructured description of NeTEx-objects. .General Frame used in the Norwegian profileNotResource Frame - frame for common objects, i.e. organisations, responsibilities, equipments etc.Site Frame - frame for information regarding stop places and places of interest.Service Frame - frame for information regarding networks lines, routes, planned stops etc.

of 105

Service Calendar Frame - frame for defining calendar-information - types of days, operating days, and their relations etc.Timetable Frame - frame for describing the actual journeys, such as calendar references, departure times, and waiting times etc.Vehicle Schedule Frame - frame for vehicle usage planning with vehicle information, equipment and blocks.

- frame for information about infrastructure - garages, roads, intersections etc.Infrastructure Frame . used in the Norwegian profile Not - frame for ticketing information. Fare Frame Not used in the Norwegian profile.

There is an additional , which can be used to group other frames, as long as they have identical ValidityCondition (implicitlyComposite Frameinherited from CompositeFrame). There are no requirements regarding order or dependency between frames.

Data conditions

All objects in the profile should be defined with as much generality as possible, and at the highest possible hierarchic level. This is particularlytrue for:

ValidityConditionFrameDefaultsCodespace

Where more specific instances deviate from the general definition at a higher level in the hierarchy, an overruling definition can be set furtherdown the hierarchy.

FRAMEDEFAULTS

Used to define common values. The following elements are permitted:

Element Type Description

DefaultCodespaceRef CodespaceRef Reference to the default codespace.

DefaultDataSourceRef DataSourceRef Reference to the default data source.

DefaultLocale framework#Locale Default locale description

DefaultLocationSystem xsd:normalizedString Default Geographic coordinate system. If defined it should be . EPSG:4326 Coordinatesdelivered for usage in the stop place registry must be sent as WGS84 latitude/longitude.

DefaultSystemOfUnits xsd:normalizedString Default unit should be .SiMetres

DefaultCurrency CurrencyType Three letter currency code according to . ISO 4217 For example NOK or SEK.

CODESPACE

The codespace is used to ensure that objects defined in the frame remain unique even when they are consolidated with data from other datasources. Each codespace is a URL with a unique three-letter code and a description.

<Codespace> <Xmlns>RUT</Xmlns> <XmlnsUrl>http://www.entur.org/ns/rut</XmlnsUrl> <Description>Ruter</Description></Codespace>

The codespaces are assigned to each new data provider by Entur. This ensures the uniqueness of data sources. Contact Entur to be assigned acodespace.

Specific components

Listed here is the structure for each frame, and which objects are expected to appear in them.

RESOURCEFRAME

ResourceFrame < framework#DataManagedObject


dataSources framework#DataSource 0: * Container for objectsDataSource

typesOfValue framework#TypeOfValue 0: * Container for objectsframework#TypeOfValue

organisations framework#Organisation 0: * Container for objectsOrganisation

Codespace example

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Locale

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-DataManagedObject

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-DataSource

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TypeOfValue


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Organisation

of 105

groupsOfOperators framework#GroupOfOperators 0: * Container for objectsGroupOfOperators

equipments framework#Equipment 0: * Container for objectsEquipment

vehicleTypes framework#VehicleType 0: * Container for objectsVehicleType

vehicles framework#Vehicle 0: * Container for objectsVehicle

schematicMaps SchematicMap 0: * Container for objectsSchematicMap

groupsOfEntities framework#GeneralGroupOfEntities 0: * Container for objectsGeneralGroupOfEntities

SITEFRAME

SiteFrame < framework#DataManagedObject


topographicPlaces TopographicPlace 0: * Container for objectsTopographicPlace

addresses framework#Address 0: * Container for objectsAddress

accesses Access 0: * Container for objectsAccess

groupsOfStopPlaces GroupOfStopPlaces 0: * Container for objectsGroupOfStopPlaces

stopPlaces StopPlace 0: * Container for objectsStopPlace

flexibleStopPlaces FlexibleStopPlace 0: * Container for objectsFlexibleStopPlace

pointsOfInterest PointOfInterest 0: * Container for objectsPointOfInterest

parkings Parking 0: * Container for objectsParking

navigationPaths NavigationPath 0: * Container for objectsNavigationPath

pathLinks PathLink 0: * Container for objectsPathLink

tariffZones TariffZone 0: * Container for TariffZone objects

siteFacilitySets SiteFacilitySet 0: * Container for objectsSiteFacilitySet

SERVICEFRAME

ServiceFrame < framework#DataManagedObject


Network Network 0: 1 Network objects

additionalNetworks Network 0: * Container for additional Network objects

routePoints RoutePoint 0: * Container for RoutePoint objects

routes Route 0: * Container for Route objects

flexiblePointProperties FlexiblePointProperties 0: * Container for FlexiblePointProperties objects

flexibleLinkProperties FlexibleLinkProperties 0: * Container for FlexibleLinkProperties objects

commonSections CommonSection 0: * Container for CommonSection objects

lines Line 0: * Container for Line objects

groupsOfLines GroupOfLines 0: * Container for GroupOfLines objects

destinationDisplays DestinationDisplay 0: * Container for DestinationDisplay objects

scheduledStopPoints ScheduledStopPoint 0: * Container for ScheduledStopPoint objects

servicePatterns ServicePattern 0: * Container for ServicePattern objects

stopAssignments StopAssignment 0: * Container for StopAssignment objects

timingPoints TimingPoint 0: * Container for TimingPoint objects

timingLinks framework#TimingLink 0: * Container for objectsTimingLink

journeyPatterns JourneyPattern 0: * Container for JourneyPattern objects

serviceExclusions ServiceExclusion 0: * Container for ServiceExclusion objects

notices framework#Notice 0: * Container for Notice objects

noticeAssignments framework#NoticeAssignment 0: * Container for NoticeAssignment objects

SERVICECALENDARFRAME

ServiceCalendarFrame < framework#DataManagedObject

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GroupOfOperators

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Equipment

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-VehicleType

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Vehicle

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GeneralGroupOfEntities


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Address


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TimingLink

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Notice

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-NoticeAssignment


of 105


ServiceCalendar ServiceCalendar 0: 1 ServiceCalendar objects

dayTypes framework#DayType 0: * Container for DayType objects

timebands framework#Timeband 0: * Container for Timeband objects

operatingDays framework#OperatingDay 0: * Container for OperatingDay objects

operatingPeriods framework#OperatingPeriod 0: * Container for OperatingPeriod objects

dayTypeAssignments framework#DayTypeAssignment 0: * Container for DayTypeAssignment objects

TIMETABLEFRAME

TimetableFrame < framework#DataManagedObject


bookingTimes framework#AvailabilityCondition 0: * Container for objects to describe flexible linesAvailabilityCondition

vehicleJourneys diverse 0: * Container for the following types:

ServiceJourneySpecialServiceVehicleJourney

frequencyGroups HeadwayJourneyGroup 0: * Container for HeadwayJourneyGroup objects

groupsOfServices GroupOfServices 0: * Container for GroupOfServices objects

journeyPartCouples JourneyPartCouple 0: * Container for JourneyPartCouple objects

coupledJourneys CoupledJourney 0: * Container for CoupledJourney objects

serviceFacilitySets framework#ServiceFacilitySet 0: * Container for ServiceFacilitySet objects

flexibleServiceProperties FlexibleServiceProperties 0: * Container for FlexibleServiceProperties objects

journeyMeetings JourneyMeeting 0: * Container for JourneyMeeting objects

journeyInterchanges ServiceJourneyInterchange 0: * Container for ServiceJourneyInterchange objects

notices framework#Notice 0: * Container for Notice objects

noticeAssignments framework#NoticeAssignment 0: * Container for NoticeAssignment objects

VEHICLESCHEDULEFRAME

VehicleScheduleFrame < framework#DataManagedObject

Name Type Cardinality Beskrivelse

blocks framework#Block 0: * Container for objectsBlock

Components

Abstract Types

ENTITY

Entity

Navn Type Cardinality Description

attr nameOfClass NameOfClass 0: 1 Class name for Entity

Used for reflection and describes the name of the class of which this object is an instance.

attr id ObjectIdType 1: 1 Unique identifier of the object.

ENTITYINVERSION

The basic type for all objects. Defines base attributes.

See definition under General information

A basic data type which expands the set of basic attributes, and defines validity conditions.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-DayType

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Timeband

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-OperatingDay

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-OperatingPeriod

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-DayTypeAssignment


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AvailabilityCondition

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ServiceFacilitySet




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Block

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Blo

of 105

EntityInVersion < framework#Entity


attr dataSourceRef DataSourceIdType 0: 1 Identifier for data source system.

attr created xsd:dateTime 0: 1 Time when was createdframework#Entity

attr changed xsd:dateTime 0: 1 Time when was last changedframework#Entity

attr modification ModificationEnum 0: 1 Type of change

deletenewreviseunchanged

attr(choice)

version VersionIdType 1: 1 Version number

versionRef VersionIdType 0: 1 Version number of reference (to an object not defined in theexternaldataset)

Used in cases where the reference does not point to theonly externallast valid version.

attr status VersionStatusEnum 0: 1 Status of version:

ActiveInactive

elem (choice)validityConditions

framework#ValidityCondition 0: * Validity conditions for the object.

elem (choice) ValidBetween ValidBetweenStructure 0: * Simplified version of (simple to and fromframework#ValidityConditiondate)

DATAMANAGEDOBJECT

DataManagedObject < < framework#EntityInVersion framework#Entity


attr responsibilitySetRef ResponsibilitySetIdType 1: 1 Points to roles and responsibilities tied to STOP PLACE, NETWORK or LINE

elem keyList KeyList 0: 1 A set of key-value pairs which describe additional properties for the object (LINE, STOPPLACE, PLANNED STOP POINT etc.) and that can be used in third-party systems,such as ticketing or journey planning.

elem Extensions ExtensionStructure 0: 1 Extension element for data not defined by NeTEx.

Only use after consulting with other affected parties.

elem BrandingRef BrandingRefStructure 0: 1 Reference to a brand.

KEYLIST

KeyList


KeyValue KeyValue 1: * Key-value pair

KeyValue


attr typeOfKey xsd:normalizedString 0: 1 Key type

elem Key xsd:normalizedString 1: 1 Key name

elem Value xsd:normalizedString 1: 1 Key value

TYPEOFVALUE

Datatype which ties responsibility definition and branding to an object. Almost all NeTEx classes inherit from DataManagedObject


List which describes user-defined key-value pairs which exist inside the object to which it belongs.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Entity



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ValidityCondition

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ValidBetween


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-EntityInVersion


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Branding

of 105

TypeOfValue < framework#DataManagedObject


Name framework#MultilingualString 1: 1 Name

Description framework#MultilingualString 0: 1 Description

Image xsd:anyURI 0: 1 URL to an image resource

Url xsd:anyURI 0: 1 URL

GROUPOFENTITIES

GroupOfEntities < framework#DataManagedObject


Name framework#MultilingualString 1: 1 Name be set for all groups of objects (for example on NETWORK, LINE, STOPmustPLACE)

ShortName framework#MultilingualString 0: 1 Short name for a group of objects


PurposeOfGroupingRef PurposeOfGroupingRef 0: 1 The functional goal for grouping.

PrivateCode PrivateCode 0: 1 PrivateCode is meant to use specific identification depending on context.

ADDRESS

Address < < < < < framework#Place framework#Zone framework#GroupOfPoints framework#GroupOfEntities framework#DataManagedObject


CountryRef CountryEnum 0: 1 Two-letter country code as defined by ISO 3166-1 alfa-2

CountryName framework#MultilingualString 0: 1 The official name of the country

ASSIGNMENT

Assignment < framework#DataManagedObject




EQUIPMENT DETAILS

Equipment

Abstract datatype used to define the classification of other types.

Abstract type for grouping arbitrary objects, for example, GroupOfOperators or GroupOfPoints. Classes inheriting from GroupOfEntitiestypically define the "members" element in order to collect objects which belong to the group.


Abstract type to define an address. It is expanded upon by RoadAddress and PostalAddress by default.


Abstract type to tie a set of properties to an object


Abstract type to describe equipment available either in a location or onboard a vehicle.



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-MultilingualString






https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Place

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Zone

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GroupOfPoints

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GroupOfEntities






of 105

Equipment < framework#DataManagedObject



PrivateCode xsd:normalizedString 0: 1 Internal code/ID for identifying equipment (not a public ID)

PublicCode xsd:normalizedString 0: 1 Public code that may identify the equipment


Note framework#MultilingualString 0: 1 Additional notes

OutOfService xsd:boolean 0: 1 Defines the status of equipment

PassengerEquipment

PassengerEquipment < < framework#Eqiupment framework#DataManagedObject


Fixed xsd:boolean 0: 1 Specifies whether the equipment is permanently installed or may be relocated

ActualVehicleEquipment

ActualVehicleEquipment < < < framework#PassengerEquipment framework#Equipment framework#DataManagedObject


Units xsd:integer 0: 1 Number of equipment units

VehicleTypeRef VehicleTypeRef 0: 1 Reference to vehicle type ( )framework#VehicleType

AccessibilityAssessment framework#AccessibilityAssessment 0: 1 Assessment of universal design accessibility

FACILITYSET

FacilitySet < framework#DataManagedObject


ProvidedByRef xsd:normalizedString 0: 1 Reference to organisation offering the services

Description framework#MultilingualString 0: 1 Description of the set of services

AccessibilityInfoFacilityList AccessibilityInfoFacilityListOfEnumerations 0: 1 Possible values

otheraudioForHearingImpairedaudioInformation (audio announcementwhen arriving/departing stops)visualDisplays

Extension of Equipment type describing equipment that can be used by passengers


Expansion of PassengerEquipment which describes equipment on board a vehicle.


Abstract type to define a set of facilities/services (based on classification)TPEG


Examples in the . See the description of specialisations for services and GitHub-repository framework#ServiceFacilitySet SiteFacilitySetfor stop place objects.





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Eqiupment


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PassengerEquipment




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AccessibilityAssessment



https://en.wikipedia.org/wiki/TPEG

https://github.com/entur/profile-norway-examples/blob/master/netex/stops/StopPlace-with-equipment-and-parking_example.xml


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-SiteFacilitySet

of 105

AssistanceFacilityList AssistanceFacilityListOfEnumerations 1: 1 Possible values

anynoneotherpersonalAssistanceboardingAssistancewheelchairAssistanceunaccompaniedMinorAssistancewheelchairUseconductorinformation

AccessibilityToolList AccessibilityToolListOfEnumerations 0: 1 Possible values

passengerCartpushchair (stroller)wheelchair

CateringFacilityList CateringFacilityListOfEnumerations 1: 1 Possible valuesbarnoFoodAvailablenoBeveragesAvailablerestauranttrolleycoffeeShopsnacksfoodVendingMachinebeverageVendingMachine

FareClasses FareClassesListOfEnumerations 1: 1 Possible valuesanybusinessClasseconomyClassfirstClass

MobilityFacilityList MobilityFacilityListOfEnumerations 1: 1 Possible valuesunknownboardingAssistancelowFlooronboardAssistancestepFreeAccesssuitableForWheelchairsunaccompaniedMinorAssistancetactilePatformEdgestactileGuidingStrips

PassengerCommsFacilityList PassengerCommsFacilityListOfEnumerations 0: 1 Possible valuesfreeWifipublicWifipowerSupplySockets

PassengerInformationEquipmentList PassengerInformationEquipmentListOfEnumerations 0: 1 Possible valuesotherfareInformationlineNetworkPlanlineTimetableinformationDeskrealTimeDepartures

PassengerInformationFacilityList PassengerInformationFacilityEnumeration 0: 1 Possible values

othernextStopIndicatorpassengerInformationDisplayrealTimeConnectionsstopAnnouncements

PLACE

Place < < < < framework#Zone framework#GroupOfPoints framework#GroupOfEntities framework#DataManagedObject


Geographic location which may be start or end point for a journey.






of 105

placeTypes TypeOfPlaceRef 1: 1 This element is only used for StopPlace and TopographicPlace, where it is required (the element is definednotby Place type).

Values for StopPlace:

monomodalStopPlacemultimodalStopPlace

Values for TopographicPlace:

county (Norwegian fylke)municipality (Norwegian kommune)citydistrict (part of town/suburb)town

LINK

Link < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Name of the link

Distance xsd:decimal 0: 1 Total length (in meters) for the geographic path the vehicle uses (actual travel distance).

gml:LineString gml:LineString 0: 1 Geometric representation of Link. The LineString is a sequential list of points.

LINKSEQUENCE

LinkSequence < framework#DataManagedObject



Distance xsd:decimal 0: 1 Total length (in meters) for . framework#LinkSequence (can also be derived from component-Links)

PointInLinkSequence

PointInLinkSequence < < < VersionedChild framework#EntityInVersion framework#Entity


attr order xsd:positiveInteger 0: 1 The sequence number of a point

elem LinkSequenceRef LinkSequenceRefStructure 0: 1 Reference to the to which the point belongsframework#LinkSequence

elem projections projections 0: 1 Projection on road or rail

LinkInLinkSequence

LinkInLinkSequence < < < VersionedChild framework#EntityInVersion framework#Entity


attr order xsd:positiveInteger 0: 1 Serial number of the point in order

Describes the line between two points.


Abstract type consisting of or which describe its path through the network.Points Links


An abstract type describing the position of the point in a LinkSequence (normally implemented as a PointOnRoute orPointInJourneyPat).tern


An abstract type describing the position of the link in a LinkSequence (normally implemented as )LinkInJourneyPattern






https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-LinkSequence




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Projection



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Point

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Link

of 105

elem LinkSequenceRef LinkSequenceRefStructure 0: 1 Reference to which the point belongs to framework#LinkSequence

elem projections projections 0: 1 Projections on roads and railways

ORGANISATION

Organisation < framework#DataManagedObject


CompanyNumber xsd:normalizedString 1: 1 Organisation number from the Brønnøysund Register Centre

Name xsd:normalizedString 1: 1 Name of organisation

OrganisationType TypeOfOrganisationEnum 0:1 Type of organisation:

authorityoperatorrailOperatorrailFreightOperatorstatutoryBodyfacilityOperatortravelAgentservicedOrganisationother

The generic organisation types "authority" and "operator" are used for an Authority andan Operator respectively when none of the more specific types are applicable.

LegalName framework#MultilingualString 1: 1 Legal name of the organisation

ContactDetails framework#ContactStructure 1: 1 The public contact information of the organisation

PrivateContactDetails framework#ContactStructure 0: 1 Non-public contact information of the organisation

parts framework#OrganisationPart 0: 1 Departments

PROJECTION

Projection < framework#DataManagedObject


None of the parameters defined in Projection should be used. Specialisation classes have their own parameters.

Basic Types

ALTERNATIVENAME

AlternativeName < VersionedChild < framework#EntityInVersion < framework#Entity


NamedObjectRef VersionofObjectRef 0: 1 Reference to the object to which the alternative name belongs.

Used when the relevant data object does not support alternativeNames sub elements.only

Lang xsd:language 1: 1 Two letter language code as defined by for the language used in anRFC 1766/ISO 639-1alternative name.

A legal body involved in public transport


Description of mapping between the shape of an arbitrary Entity from one layer, to an Entity on a different layer, for example, Point,Link, Zone.


Examples of Alternative name can be a different language or a second spelling.


Examples in the .GitHub-repository


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Projec



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ContactStructure


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-OrganisationPart




https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/site/submodel-alternativeNames.xml

of 105

NameType NameTypeEnumeration 1: 1 Type of alternative name:

AliasLabel (used for airport names)Translation

Name framework#MultilingualString 1: 1 The alternative name

CONTACTSTRUCTURE

ContactStructure


ContactPerson xsd:normalizedString 0: 1 Name of a person to be contacted

Email emailAddressType 0: 1 E-mail address of contact point (ISO format), alternatively a link to a contact form.

Phone PhoneType 0: 1 Phone number of a contact point

Fax PhoneType 0: 1 Fax-number of a contact point

Url xsd:anyURI 0: 1 Website-address for contact point

Note that URL for is .CustomerServiceContactDetails mandatory

FurtherDetails xsd:normalizedString 0: 1 Additional details for contact point

DELIVERYVARIANT

DeliveryVariant < framework#DataManagedObject


DeliveryVariantMediaType DeliveryVariantTypeEnumeration 1: 1 Media type. Possible values:

printedtextToSpeechwebmobile

VariantText framework#MultilingualString 1: 1 Text for respective media types (replaces Note for certain media types)

GENERALGROUPOFENTITIES

GeneralGroupOfEntities < < framework#GroupOfEntities framework#DataManagedObject


members objectRef 0: * List of objects included in the group.

GROUPOFPOINTS

GroupOfPoints < < framework#GroupOfEntities framework#DataManagedObject


A dataset for contact information

It is mandatory to fill out at least one of the following fields: 'Email', 'Phone' or 'Url'.


An alternative variant of Notice meant for certain types of media.


A general grouping of Entity objects. A predefined base group for arbitrary objects.


Defined in ResourceFrame

Group of Point objects








of 105

members objectRef 0: * List of objects included in the group.framework#Point

LOCALE

Locale


TimeZone TimeZoneOffset 1: 1 Name of timezone

Please note that this should always be timezone for .local time

DefaultLanguage xds:language 1: 1 Default language

languages LanguageUsage 0: * Other languages

LANGUAGEUSAGE

LanguageUsage


Language xsd:language 1: 1 Language to be described

LanguageUse LanguageUseListOfEnumerations 1: 1 Possible values

allUsesnativenormallyUsedotherreadspokenwrittenunderstood

LOCATION

Location


attr srsName xsd:normalizedString 0: 1 The reference system for longitude and latitude. If stated, use or if necessaryWGS84a valid coordinate-reference to the standard used (for example " ").EPSG:4326

(choice)elem

Longitude

Latitude

Altitude

LongitudeType

LatitudeType

AltitudeType

1: 1

1: 1

0: 1

Longitude (-180 to 180)

Latitude (-90 to 90)

Elevation (meters above sea level)

(choice)elem

gml:pos gml:pos 1: 1 Location

For example: <gml: pos srsName="urn:ogc:def:crs:EPSG::4326">-59.123 -45.1254 </gml:pos>

Note! The stop place registry only accepts WGS84-coordinates.

elem Precision xsd:decimal 0: 1 Precision in meters

MULTILINGUALSTRING

Description of national settings, such as time, and language.

Examples in the GitHub-repository

Description of language use based on United Nation standard values.

Examples in GitHub-repository

The geographic location of an object


Examples in GitHub-repository (see the description of under or under LocationPoint Point with projection CentroidLocation PointOfInter, s )est ee also data types framework#Polygon and Geographical Types

Text field with specified language


https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-Locale.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-Locale.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-PointWithProjection.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/stops/PointOfInterest.xml


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Polygon

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GeographicalTypes

of 105

MultilingualString


attr lang xsd:language 0: 1 A two-letter language code as specified in for language used.RFC 1766/ISO 639-1

when an object has a language option, for example when using Must be specified framework#AlternativeNameor framework#AlternativeText

PROJECTION TYPES

PointProjection

PointProjection < < framework#Projection framework#DataManagedObject


ProjectedPointRef PointRef 0: 1 Reference to Point being projected

This field is useful when Projection is sent as a separate object. Otherwise, context determines which objectProjection belongs to.

ProjectToPointRef PointRef 0: 1 Point being projected to. (Reference to externally defined Point, e.g. RoutePoint, TimingPoint,ScheduledStopPoint.)

ProjectToLinkRef LinkRef 0: 1 Link being projected to. The point can be projected to a Link.

Distance xsd:decimal (1: 1) The distance between projected Point and Link. Field only used together with ProjectToLinkRef

ZoneProjection

ZoneProjection < < Projection framework#DataManagedObject


ProjectedZoneRef ZoneRef 0: 1 Zone being projected.

This field is useful when Projection is sent as a separate object. Otherwise, context determines which objectProjection belongs to.

ProjectToZoneRef ZoneRef 0: 1 Zone being projected to. (Reference to external zone-object.)

ProjectToPointRef PointRef 0: 1 Point being projected to. A zone can be projected to a Point.

ADDRESS TYPES

PostalAddress

PostalAddress < < < < < < framework#Address framework#Place framework#Zone framework#GroupOfPoints framework#GroupOfEntities framework#DataManagedObject


AddressLine1 framework#MultilingualString 1: 1 Address line 1

AddressLine2 framework#MultilingualString 0: 1 Address line 2

Town framework#MultilingualString 1: 1 Postal place name

Mapping of Point objects from one layer to another, e.g. to Point or Link



Mapping of Zone-object from one layer to another, for example Point or Zone.


Description of a postal address



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AlternativeName

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AlternativeText

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Projection


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Proj


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Address

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Place











of 105

PostCode xsd:normalizedString 1: 1 Postcode

RoadAddress

RoadAddress < < < < < < Address Place Zone framework#GroupOfPoints framework#GroupOfEntities framework#DataManagedObject


GisFeatureRef xsd:normalizedString 1: 1 Reference to a GIS system. The field will help with inking of OpenStreetMap, IGN, NavTeq,etc. data.

RoadNumber xsd:normalizedString 1: 1 House number.

RoadName framework#MultilingualString 1: 1 Road/street name.

BearingDegrees xsd:integer 0: 1 Bearing of the road, in degrees.

VEHICLE

Vehicle < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Name of the vehicle

RegistrationNumber xsd:normalizedString 0: 1 Vehicle registration number/license plate number

OperationalNumber xsd:normalizedString 0: 1 Operational number of the vehicle (e.g. vehicle nr. 4230)

OperatorRef OperatorRefStructure 1: 1 Reference to Operator

VehicleTypeRef VehicleTypeRefStructure 1: 1 Reference to framework#VehicleType

actualVehicleEquipments framework#Equipment 0: * Description of on-board equipment.

Defined inline.

VEHICLETYPE

VehicleType < framework#DataManagedObject


Name framework#MultilingualString 1: 1 Name of vehicle type

Description framework#MultilingualString 1: 1 Description of vehicle type

TypeOfFuel TypeOfFuelEnumeration 0: 1 Fuel type:

PetrolDieselnaturalGasbiodieselelectricityother

Description of a street/road address.



A vehicle used for public transport purposes.




Description of the type of vehicle used




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Addre

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Pl

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624













https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-Vehicle.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-VehicleType.xml

of 105

EuroClass xsd:normalizedString 0: 1 Euroclass for vehicle type

See Wikipedia for information

capacities framework#PassengerCapacity 0: * Capacity per tariff class

LowFloor xsd:boolean 1: 1 Specifies if the vehicle has low flooring or not

HasLiftOrRamp xsd:boolean 1: 1 Specifies if the vehicle is equipped with an elevator or ramp (e.g. forwheelchairs)

Length xsd:decimal 0: 1 The total length of the vehicle type

facilities ServiceFacilitySetRef 0: * References to objectsframework#ServiceFacilitySet

PASSENGERCAPACITY

PassengerCapacity < framework#DataManagedObject


FareClass FareClassEnumeration 1: 1 Possible values:

businessClasseconomyClassfirstClassany

TotalCapacity xsd:nonNegativeInteger 1: 1 Maximum number of passengers

SeatingCapacity xsd:nonNegativeInteger 1: 1 Number of seated passengers

StandingCapacity xsd:nonNegativeInteger 1: 1 Number of standing passengers

SpecialPlaceCapacity xsd:nonNegativeInteger 1: 1 Number of priority seats

PushchairCapacity xsd:nonNegativeInteger 1: 1 Capacity for baby stroller/pushchairs

WheelchairCapacity xsd:nonNegativeInteger 1: 1 Number of designated wheelchair areas

Accessibility Types

ACCESSIBILITYASSESSMENT

AccessibilityAssessment < framework#DataManagedObject


MobilityImpairedAccess LimitationStatusEnum 1: 1 Specifies whether the object can be used by people with special needs:

true ( AccessibilityLi )if all fields in mitation are truefalse ( )if all fields in AccessibilityLimitation are falsepartial (if all fields in AccessibilityLimitation are partially true, or some of

)them are trueunknown

limitations framework#AccessibilityLimitation 1: 1 Accessibility limitations

suitabilities framework#Suitability 0: * Describes suitability

Comment framework#MultilingualString 0: 1 Additional comments for Accessibility definition. Field content is meant to bedisplayed together with Accessibility information.

ACCESSIBILITYLIMITATION

The maximum number of passengers a vehicle can accommodate.


Universal design, description of an object e.g. a stop place.



Possible limitations


https://en.wikipedia.org/wiki/European_emission_standards

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PassengerCapacity



https://en.wikipedia.org/wiki/Priority_seat


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AccessibilityLimitation

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Suitability


https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-VehicleType.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/site/submodel-StationWithEquipment.xml

of 105

AccessibilityLimitation < framework#DataManagedObject


WheelchairAccess LimitationStatusEnum 1: 1 Describes usability for wheelchair users:

truefalsepartialunknown

StepFreeAccess LimitationStatusEnum 1: 1 Describes whether the object has step-free access (no stairs)


EscalatorFreeAccess LimitationStatusEnum 1: 1 Describes whether the object has escalator free access


LiftFreeAccess LimitationStatusEnum 1: 1 Describes whether the object can be accessed without the use of an elevator:


AudibleSignsAvailable LimitationStatusEnum 1: 1 Describes if the object has audio signs (directions for the visually impaired):


VisualSignsAvailable LimitationStatusEnum 1: 1 Describes whether the object has visual signs:


SUITABILITY

Suitability < < framework#UserNeed framework#DataManagedObject


(choice) MobilityNeed MobilityEnumeration 1: 1 Specific mobility needs:

wheelchairassistedWheelchairmotorizedWheelchairwalkingFrame (rullator)otherMobilityNeednormal

(choice) PsychosensoryNeed PsychosensoryNeedEnumeration 1: 1 Specific psychosensory needs:

visualImpairmentauditoryImpairment

(choice) EncumbranceNeed EncumbranceNeedEnumeration 1: 1 Specific luggage needs:

luggageEncumberedpushchairbaggageTrolleyoversizeBaggageguideDogotherAnimalotherEncumbranceNeed

Suitable SuitableEnumeration 1: 1 Specifies if the suitability (established by above values) is true or false.

suitablenotSuitable

Description of suitability



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-UserNeed


of 105

Geographical Types

POINT

Point < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Name of the Point

Location framework#Location 0: 1 Location of the Point

Location is it is implicit based on the projection of the Point, or themandatory unlesssubordinate objects have explicit references to geographic points/areas

PointNumber xsd:normalizedString 0: 1 Alternative identifier

projections Projection 0: * Points projections

ZONE

Zone < < < framework#GroupOfPoints framework#GroupOfEntities framework#DataManagedObject


Centroid framework#Point 0: 1 Representative point for a zone (area). Not meant to be the actual centre point of the zone, but a point whichis representative of the zone (e.g. for displaying on a map)

gml:Polygon gml:Polygon 0: 1 A sorted list of points which represent a closed line (polygon) which describes the zone.

projections Projection 0: * List of projections used to describe infrastructure (e.g. roads, railways, etc.). Typically a reference to anOpenStreetMap dataset.

POLYGON

Polygon-structure

A Point used as an element by a transport network


Examples in (see also )GitHub-repository datatypes framework#Location and framework#Polygon

Description of a geospatial area



Area represented as perimeter/area

See also and framework#Location Geographical Types



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Location

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PointProjection






https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ZoneProjection




https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-Zone.xml


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-GeographicalTypes

of 105

Organisation Types

OPERATOR

Operator < < framework#Organisation framework#DataManagedObject


Address framework#PostalAddress 0: 1 Postal address

PrimaryMode VehicleModeEnumeration 0: 1 The operators primary type of transport (if relevant)

OperatorActivities ListOfOperatorActivities 0: 1 Possible values

passengerinfrastructure

CustomerServiceContactDetails framework#ContactStructure 1: 1 Point of contact for customer support/feedback of that company.

AUTHORITY

Authority < < framework#Organisation framework#DataManagedObject


Address framework#PostalAddress 0: 1 Postal address

Polygon example

A company which is responsible for operating public transport services. Will often operate under contract with an Authority.



A company or organisation which is responsible for the establishment of a public transport service.





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PostalAddress




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PostalAddress

of 105

ORGANISATIONPART

OrganisationPart < framework#DataManagedObject


Name framework#MultilingualString 1: 1 Name of organisation

Description framework#MultilingualString 0: 1 Description of the organisation

PrivateCode xsd:normalizedString 0: 1 Internal code for integration with legacy systems

ContactDetails framework#ContactStructure 0: 1 Contact information

Location framework#Location 0: 1 Location of organisation

DEPARTMENT

Department < < framework#OrganisationPart framework#DataManagedObject


TypeOfOperationRef TypeOfOperationRef 1: 1 Reference to TypeOfOperation (classification of department)

GROUPOFOPERATORS

GroupOfOperators < < framework#GroupOfEntities framework#DataManagedObject


members TransportOrganisationRef 1: * References to operators included in the group

BRANDING

Branding < framework#TypeOfValue < framework#DataManagedObject


Branding inherits from TypeOfValue and does not introduce new elements or attributes.

DATASOURCE

DataSource < < framework#TypeOfValue framework#DataManagedObject


Email EmailAddressType 1: 1 Contact e-mail for data (content) related questions.

Description of common components for a department in an organisation (NeTEx can define several different types of departments)


Department in an organisation

Grouping of operators



Description of branding



Description of the system which is the original source of timetable data. This type has the same set of fields as TypeOfValue, pluse-mail.








https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-OrganisationPart








https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-Branding.xml

of 105

Equipment Types

ACCESSEQUIPMENT

EntranceEquipment

EntranceEquipment < < < framework#PlaceEquipment framework#Equipment framework#DataManagedObject


Door xsd:boolean 0: 1 If entrance has one door

WheelchairPassable xsd:boolean 0: 1 If entrance can be used for wheelchair

PlaceLighting

PlaceLighting < < < framework#PlaceEquipment framework#Equipment framework#DataManagedObject


Lighting LightingEnumeration 1: 1 Description of lighting situation:

wellLitpoorlyLitunlitunknown

AlwaysLit xsd:boolean 0: 1 Specifies whether lighting is always on or not

RampEquipment

RampEquipment < < < framework#PlaceEquipment framework#Equipment framework#DataManagedObject

Installed Equipment

Objects permanently installed at for example stop areas. The following types are included in this profile:

AccessEquipmentEntranceEquipmentPlaceLightingRampEquipmentRoughSurface

ParkingEquipmentCycleStorageEquipment

PassengerServiceEquipmentSanitaryEquipment

TicketingEquipmentTicketingEquipmentTicketValidatorEquipment

SignEquipmentGeneralSign

LocalService

Services connected to for example a stop area.

The following types are included in this profile:

AssistanceServiceLuggageService

Equipment details for an entrance.


Describe the lighting situation for a place.


Description of attributes for an accessibility ramp


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PlaceEquipment









of 105


Gradient RampGradientEnum 0: 1 Possible values:

verySteepshallowsteepmoderatelevel ( )no gradient

RoughSurface

RoughSurface < < < framework#AccessEquipment framework#Equipment framework#DataManagedObject


SurfaceType SurfaceTypeEnumeration 1: 1 Surface types:

asphaltearthgrasslooseSurface (e.g gravel)pavingStones (e.g. paving stones)roughSurface (e.g. rocky)smooth (e.g. concrete or other very smooth surfaces)other

SuitableForCycles xsd:boolean 0: 1 Suitable for bicycles.

CycleStorageEquipment

CycleParkingEquipment < < framework#PlaceEquipment < framework#Equipment framework#DataManagedObject


NumberOfSpaces xsd:integer 1: 1 Number of parking spaces

CycleStorageType CycleStorageEnum 0: 1 Possible values:

racksbarsrailings

Covered xsd:boolean 0: 1 Specifies whether the parking is covered by a roof

PASSENGEREQUIPMENT

SanitaryEquipment

SanitaryEquipment < < < framework#PassengerEquipment framework#Equipment framework#DataManagedObject


SanitaryFacilityList SanitaryFacilityListOfEnumerations 1: 1 List of facilities:

nonetoiletwheelchairAccessToiletshowerbabyChange

NumberOfToilets xsd:integer 0: 1 Number of toilets

SITEEQUIPMENT

Description of surface


Description of bicycle storage equipment.


Description of sanitary equipment.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AccessEquipment









of 105

WaitingRoomEquipment

WaitingRoomEquipment < < < framework#SiteEquipment framework#Equipment framework#DataManagedObject


Seats xsd:nonNegativeInteger 0: 1 Number of seats.

StepFree xsd:boolean 1: 1 Specifies whether access to the waiting room is step free (no stairs).

Heated xsd:boolean 0: 1 Specifies whether the waiting room is heated.

ShelterEquipment

ShelterEquipment < < < < framework#WaitingEquipment framework#SiteEquipment framework#Equipment framework#DataManagedObject


Enclosed xsd:boolean 1: 1 Specifies whether the waiting room is enclosed by walls, or open.

TICKETINGEQUIPMENT

TicketingEquipment

TicketingEquipment < framework#PassengerEquipment < framework#Equipment < framework#DataManagedObject


NumberOfMachines xsd:integer 0: 1 Number of ticket vending machines

TicketingFacilityList TicketingFacilityListOfEnumerations 0: * Possible values:

ticketMachinesticketOfficeticketOnDemandMachines

NumberOfTills xsd:integer 0: 1 Number of tills for ticket sale

PaymentMethods PaymentMethodEnum 0: * Possible values:

cashcashAndCardcoincreditCarddebitCardtravelCardcontactlessTravelCardsms

TicketTypesAvailable TicketTypeEnum 0: * Possible values:

standardpromotionconcessiongroupseasontravelCard

TicketingServiceList TicketingServiceFacilityEnum 0: * Possible values:

purchasecollectioncardTopUpreservations

Description of waiting room equipment.


Description of a waiting room.


Description of ticketing equipment.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-SiteEquipment



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-WaitingEquipment

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-SiteEquipment






of 105

TICKETVALIDATOREQUIPMENT

TicketValidatorEquipment < framework#PassengerEquipment < framework#Equipment < framework#DataManagedObject


ValidatorList TicketValidatorEnum 0: * Possible values:

paperStampcontactLessmagneticnfc

SIGNEQUIPMENT

GeneralSign

GeneralSign < SignEquipment < framework#PlaceEquipment < framework#Equipment < framework#DataManagedObject


PrivateCode xsd:normalizedString 0: 1 Sign code

One of the following code values be used when adding official stops to a stop place.must

Bus stops: 512Tram stops: 513Taxi stops: 514

Also set SignContentType = 'transportMode'.

Content framework#MultilingualString 0: 1 Text on sign

SignContentType SignContentEnum 0: 1 Type of sign:

assistanceemergencyExitentranceexitmeetingPointsosPhoneticketstransportMode

Permanent stops with a transport sign must have . This isSignContentType = 'transportMode'used to distinguish them from non-permanent stops, and/or flexible stops.

LOCALSERVICE

AssistanceService

AssistanceService < LocalService < < framework#Equipment framework#DataManagedObject


AssistanceServices AssistanceServiceEnum 0: * Possible values:

boardingAssistancepersonalAssistancewheelchairAssistanceunaccomapniedMinorsAssistanceconductorinformation

Description of ticket validation equipment


Description of signs


Available assistance service











of 105

AccessibilityTools AccessibilityToolEnum 0: * Possible values:

wheelchairwalkingStickaudioNavigatorvisualNavigator

GuideDogsAllowed xsd:boolean 0: 1 If guide dogs are allowed

LuggageService

AssistanceService < LocalService < < framework#Equipment framework#DataManagedObject


LuggageServiceType LuggageServiceFacilityEnum 0: 1 Possible values:

leftLuggageporteragefreeTrolleyspaidTrolleyscollectAndDeliverToStation

WheelchairLuggageTrolleys xsd:boolean 0: 1 If luggage trolleys for wheelchairs are available

SERVICEFACILITYSET

ServiceFacilitySet < < framework#FacilitySet framework#DataManagedObject


AccommodationAccessList AccommodationAccessListOfEnumerations 0: 1 Possible values:

freeSeatingreservationstanding

AccommodationFacilityList AccommodationFacilityListOfEnumerations 0: 1 Possible values:

familyCarriageseatingsleeperstanding

LuggageCarriageFacilityList LuggageCarriageFacilityListOfEnumerations 0: 1 Possible values:

baggageStoragecyclesAllowedcyclesAllowedWithReservationluggageRacksextraLargeLuggageRacksnoBaggageStoragenoCycles

ServiceReservationFacilityList ServiceReservationFacilityListOfEnumerations 0: 1 Possible values:

bicycleReservationsCompulsorynoReservationsPossiblereservationsCompulsoryreservationsCompulsoryForGroupsreservationsRecommendedreservationsPossiblewheelchairOnlyReservations

Train Types

COMPOUNDTRAIN

Available Luggageservice


A specialisation of FacilitySet to describe available services


Defined in TimetableFrame




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-FacilitySet


https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-ServiceFacilitySet.xml

of 105

CompoundTrain < < VehicleType framework#DataManagedObject


components framework#TrainInCompoundTrain 1: * References to train objects which are a part of a compound train.

TRAININCOMPOUNDTRAIN

TrainInCompoundTrain < < < VersionedChild framework#EntityInVersion framework#Entity


Train framework#Train 1: 1 Train description

ReversedOrientation xsd:boolean 0: 1 Specifies whether the train is in reverse orientation to the framework#CompoundTrain

Label framework#MultilingualString 0: 1 A label associated with the train

TRAIN

Train < < framework#VehicleType framework#DataManagedObject


TrainSize framework#TrainSize 0: 1 Size of the train (number of cars)

components framework#TrainComponent 0: * Components constituting a train

TRAINSIZE

TrainSize


NumberOfCars xsd:nonNegativeInteger 0: 1 Number of cars in the train

TrainSizeType TrainSizeEnumeration 0: 1 Train size types:

NormalShortLong

TRAINCOMPONENT

TrainComponent < framework#DataManagedObject

Descriptions of compound trains




A in a Train CompoundTrain


Train description




Size of the train

A train car (wagon/carriage)


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-VehicleTy


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TrainInCompoundTrain



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Train

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-CompoundTrain

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-CompoundTrain




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TrainSize

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TrainComponent


https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-CompoundTrain.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-Train.xml

of 105


Label framework#MultilingualString 0: 1 Static train component label.

If the label is dynamic, use TrainComponentLabelAssignment instead

Description framework#MultilingualString 0: 1 Description of the component

TrainElement framework#TrainElement 1: 1 Description of the train car

TRAINELEMENT

TrainElement < framework#DataManagedObject


TrainElementType TypeOfTrainElementEnum 1: 1 Classification of a car:

carriageenginesleeperCarriageluggageVanrestaurantCarriage

FareClasses FareClassListOfEnumerations 0: * Tariff/fare class for a car

anybusinessClasseconomyClassfirstClass

equipments framework#Equipment 0: * Description of onboard equipment

Defined inline

Notice Types

NOTICE

Notice < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Name of the Notice.

AlternativeTexts AlternativeText 0: * Notice text for languages other than the primary language (Norwegian). One per language.

Can be used in addition to the primary language notice text.

Text framework#MultilingualString 1: 1 Notice text.

PublicCode xsd:normalizedString 0: 1 Public code of the Notice.

variants framework#DeliveryVariant 0: * Variations of the Notice for different media types.

AlternativeText

AlternativeText < VersionedChild < framework#EntityInVersion < framework#Entity


Detailed train car description



Text-based notification describing circumstances which cannot be modelled as structured data.

Please note that Notice and the related should be placed it the NoticeAssignment framework#ServiceFrame/framework#TimetableFra to which it belongs.me


Defined in ServiceFrame

Placeholder for alternative text other than Norwegian



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TrainElement





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-AlternativeTesxt


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-DeliveryVariant




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ServiceFrame

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-TimetableFrame


of 105

Text framework#MultilingualString 1: 1 Notice text.

Please note the importance of adding the mandatory "lang" attribute, to indicate the language of eachAlternativeText.

NOTICEASSIGNMENT

NoticeAssignment < < framework#Assignment framework#DataManagedObject


NoticeRef NoticeRef 1: 1 Reference to the objectframework#Notice

NoticedObjectRef VersionOfObjectRef 1: 1 Reference to the object the Notice belongs to

Calendar Types

DAYTYPE

DayType < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Name for DayType


EarliestTime xsd:time 0: 1 Start time

DayLength xsd:duration 0: 1 Duration

properties framework#PropertyOfDay 0: * Properties

timebands framework#Timeband 0: * Specific periods within the day

PROPERTYOFDAY

PropertyOfDay


Name framework#MultilingualString 0: 1 Name of property


DaysOfWeek DayOfWeekListOfEnumerations 0: 1 Weekdays or day sets for which the property is valid:

MondayTuesdayWednesdayThursdayFridaySaturdaySundayEverydayWeekdaysWeekend

Reference to the Notice from e.g. or JourneyPattern VehicleJourney

Please note that Notice and the related should be placed it the NoticeAssignment framework#ServiceFrame/framework#TimetableFra to which it belongs.me



Description of DayType, which has a set of properties affecting a public transport service, such as public holidays.


Defined in ServiceCalendarFrame


Properties for DayType



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Assignment






https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-PropertyOfDay





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-ServiceFrame



https://github.com/entur/profile-norway-examples/blob/master/netex/schedule/ServiceCalendar-example.xml

of 105

WeeksOfMonth WeeksofMonthListOfEnumerations 0: 1 Weeks of a month for which the property is valid:

12345EveryWeek

(choice) MonthOfyear xsd:gMonth 0: 1 The month of the year for which the property is valid

(choice) DayOfYear xsd:gMonthDay 0: 1 Day of a year, e.g. "every April 1")

TIMEBAND

Timeband < framework#DataManagedObject


StartTime xsd:time 1: 1 Start time

EndTime xsd:time 1: 1 End time

Duration xsd:duration 0: 1 Period duration.

Usage and cardinality depending on context.

DAYTYPEASSIGNMENT

DayTypeAssignment < < framework#Assignment framework#DataManagedObject


ServiceCalendarRef CalendarRef 0: 1 Reference to ServiceCalendar

(choice) OperatingPeriodRef

( ) OperatingDayRefchoice

( ) Datechoice

OperatingPeriodRef

OperatingDayRef

xsd:date

1: 1 Reference to framework#OperatingPeriod

Reference to framework#OperatingDay

Otherwise, use the normal date instead of OperatingPeriodRef/OperatingDayRef

DayTypeRef DayTypeRef 1: 1 Reference to framework#DayType

isAvailable xsd:boolean 0: 1 Specifies exceptions (for example a specific date)

OPERATINGDAY

OperatingDay < framework#DataManagedObject


CalendarDate xsd:Date 1: 1 Specifies starting date for OperatingDay.

General type to specify time or period (such as a specific time, to-from times, duration or to split a day into different calendar modes).

Note that specific times must be stated with identical StartTime and EndTime.



The reference between DayType and OperatingDay




An operating day when public transport is offered and is defined in a Service Calendar. An operating day may be longer than 24 hours.













of 105

ServiceCalendarRef CalendarRef 0: 1 Reference to associated . ServiceCalendar

Note: A calendar day can have several different OperatingDay objects (in cases ofmultiple service operators). To resolve this, it is recommended to create several ServiceCalendar-objects.

Name framework#MultilingualString 0: 1 Name for OperatingDay.

EarliestTime xsd:time 1: 1 Start time for the OperatingDay.

DayLength xsd:duration 1: 1 Duration of OperatingDay (no upper limit).

OPERATINGPERIOD

OperatingPeriod < framework#DataManagedObject


ServiceCalendarRef CalendarRef 0: 1 Reference to associated . ServiceCalendar

Note: A calendar day can have several different OperatingDay objects (in cases of multiple serviceoperators). To resolve this, it is recommended to create several ServiceCalendar-objects.

(choice) FromDate

(choice) FromDateRef

xsd:dateTime

OperatingDayRef

1: 1 Reference to the from-date ( ) of the period.framework#OperatingDay

(choice) ToDate

(choice) ToDateRef

xsd:dateTime

OperatingDayRef

1: 1 Reference to the to-date ( ) of the period.framework#OperatingDay

Timing

JOURNEYWAITTIME

JourneyWaitTime < < framework#JourneyTiming VersionedChild < < framework#EntityInVersion framework#Entity


TimingPointRef TimingPointRefStructure 0: 1 Reference to TimingPoint

WaitTime xsd:duration 1: 1 Wait time

JOURNEYPATTERNWAITTIME

An OperatingPeriod is the period between an OperatingDay, or date when public transport services defined in Service Calendar isoffered. Can be interval between two OperatingDays or dates.




Wait time at a TimingPoint








https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-JourneyTiming




of 105

JourneyWaitTime < framework#JourneyWaitTime < < framework#JourneyTiming VersionedChild < < framework#EntityInVersion framework#Entity


JourneyRef JourneyPatternRef 1: 1 Reference to JourneyPattern

JOURNEYRUNTIME

JourneyRunTime < framework#JourneyTiming < VersionedChild < < framework#EntityInVersion framework#Entity


TimingLinkRef TimingLinkRef 0: 1 Reference to framework#TimingLink

RunTime xsd:duration 1: 1 Run time

TimingLink

TimingLink < < framework#Link framework#DataManagedObject


FromPointRef TimingPointRef 1: 1 From TimingPoint

ToPointRef TimingPointRef 1: 1 To TimingPoint

JOURNEYPATTERNRUNTIME

JourneyPatternRunTime < framework#JourneyRunTime < framework#JourneyTiming < VersionedChild < < framework#EntityInVersion framework#Entity


LinkRef TimingLinkRef 1: 1 Reference to for Turnaround Timeframework#TimingLink

JourneyRef JourneyPatternRef 1: 1 Reference to JourneyPattern

JOURNEYHEADWAY

JourneyHeadway < framework#JourneyTiming < VersionedChild < < framework#EntityInVersion framework#Entity


ScheduledHeadwayInterval xsd:duration 0: 1 The planned interval between departures

MinimumHeadwayInterval xsd:duration 0: 1 The minimum interval between departures

MaximumHeadwayInterval xsd:duration 0: 1 The maximum interval between departures

Constraints

CheckConstraint

Wait time at a TimingPoint in a JourneyPattern


The vehicles run time from one TimingPoint to the next (i.e. to traverse the TimingLink)


A link (with direction) between two TimingPoint objects


The vehicles run time from one TimingPoint to the next (i.e. to traverse the TimingLink) in a JourneyPattern.


The interval between two departures (service frequency).


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-JourneyWaitTime








https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-Link


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-JourneyRunTime









of 105

CheckConstraint < framework#Assignment < framework#DataManagedObject


CheckProcessType CheckContraintProcessEnum 0: 1 Classification of constraints:

baggageCheckinbaggageReclaimcheckinbaggageSecurityCheckboarding

delay framework#CheckConstraintDelay 0: 1 Delay time

validityConditions framework#ValidityCondition 0: * Validity conditions

CheckConstraintDelay

CheckConstraintDelay < < < VersionedChild framework#EntityInVersion framework#Entity


CheckConstraintRef CheckContraintRef 0: 1 Reference to framework#CheckConstraint

AverageDuration xsd:duration 0: 1 The average duration of a delay

MinimumDuration xsd:duration 0: 1 Minimum duration of delay

MaximumDuration xsd:duration 0: 1 Maximum duration of delay

validityConditions framework#ValidityCondition 0: * Validity conditions

Validity Types

VALIDITYCONDITION

ValidityCondition < framework#DataManagedObject


ConditionedObjectRef ObjectRef 0: 1 Reference to the object associated with a ValidityCondition.Used only if ValidityCondition is defined as separate objects in the Frame, otherwise, the contextwill determine which object the ValidityCondition belongs to, and this field will be ignored.

WithConditionRef ValidityConditionRef 0: 1 Can merge several ValidityCondition objects using an 'AND' operator.

AVAILABILITYCONDITION

Delaying constraints for a or , such as check-ins, security checks, or luggage handling.SiteElement ServiceJourney


Description of a delay.

A condition which specifies when an object, set of objects, or frame is valid. For example when a line operates, when a station is open,or when delays are to be expected. Conditions can be applied to all relevant objects in a PublicationDelivery and should be defined ashigh up in the hierarchy as possible.

No validityCondition = always valid"open ended" conditions are allowed, defining only start end time.orMultiple validity condition periods can also be defined, but they should not overlap.

For Line, a ValidityCondition should be set if the line is not always operating (seasonal Line). This can be used to indicate that validtime table data has been submitted, even if the Line does not actually operate.


Note that ValidityCondition is set for CompositeFrame, and defines all subordinate frames, or set for each Frame when these are notgrouped on submission.

Examples of CompositeFrame or single frames can be found in the .GitHub-repository

ValidityCondition described with dates, day types and day properties.




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-CheckConstraintDelay




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624#framework-CheckConstraint



https://github.com/entur/profile-norway-examples/blob/master/netex/frames/PublicationDelivery-CompositeFrame.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/frames/PublicationDelivery-separate-frames.xml

https://github.com/entur/profile-norway-examples

of 105

AvailabilityCondition < < framework#ValidityCondition framework#DataManagedObject


FromDate xsd:dateTime 0: 1 From-date

ToDate xsd:dateTime 0: 1 To-date

IsAvailable xsd:boolean 1: 1 Specifies whether the service is available or not.

dayTypes DayTypeRef 0: * framework#DayType which determines when ValidityCondition is valid.

Do use together with operatingDays in the same ValidityCondition.not

timebands framework#Timeband 0: * The period when ValidityCondition is valid. Can be used to describe for example openinghours.

operatingDays framework#OperatingDay 0: * Days when ValidityCondition is valid.

Do use together with dayTypes in the same ValidityCondition.not

operatingPeriods framework#OperatingPeriod 0: * The period when ValidityCondition is valid. Used instead of single days whenever this is moresensible.

VALIDBETWEEN

ValidBetween < < framework#ValidityCondition framework#DataManagedObject


FromDate xsd:dateTime 0: 1 From-date

ToDate xsd:dateTime 0: 1 To-date

VALIDITYTRIGGER

ValidityTrigger < < framework#ValidityCondition framework#DataManagedObject


TriggerObjectRef ObjectRef 0: 1 Reference to the object which triggers the framework#ValidityCondition

Vehicle Schedule Types

BLOCK

Block < framework#DataManagedObject


Name framework#MultilingualString 0: 1 Block name


Examples for and datasets can be found in the "available" "unavailable" GitHub-repository

A simplified version of ValidityCondition with only from- and to-date.



Reference to an object, for example, events, or a public holiday which triggers a ValidityCondition


Description of journey pattern for a vehicle from start- to end point.

Note that Blocks which include from different must be defined in the common-file of the dataset, along with any journeys Lines DayTyp or es for Start/Stop.ScheduledStopPoints


Defined in VehicleScheduleFrame















https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/validity/submodel-AvailabilityConditionUnavailable.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/validity/submodel-AvailabilityConditionAvailable.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/validity/submodel-AvailabilityConditionUnavailable.xml

https://github.com/entur/profile-norway-examples

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/validity/submodel-ValidBetween.xml

https://enturas.atlassian.net/wiki/pages/createpage.action?spaceKey=ROR&title=DayType

https://enturas.atlassian.net/wiki/pages/createpage.action?spaceKey=ROR&title=DayType

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/vehicles/submodel-VehicleScheduleFrame.xml

of 105

Description framework#MultilingualString 0: 1 Block description

PrivateCode PrivateCode 0: 1 Internal code or reference for Block.

StartTime xsd:time 0: 1 Start time (local time)

Only specified when than first VehicleJourney (or DeadRun) in Blockstart time is earlier

EndTime xsd:time 0: 1 End time (local time)

Only specified when than last VehicleJourney in Blockend time is later

EndTimeDayOffset xsd:integer 0: 1 The number of days between StartTime and EndTime for the Block.

Only specified when EndTime is one or more calendar days after StartTime.

dayTypes DayTypeRef 1: * References to when Block is activeDayTypes

StartPointRef PointRef 0: 1 Reference to where Block begins.ScheduledStopPoint

Only specified when starting point in VehicleJourney (or DeadRun) is different from thestarting point referenced in Block

StopPointRef PointRef 0: 1 Reference to where Block endsScheduledStopPoint

Only specified when end point in VehicleJourney (or DeadRun) is different from the endpoint referenced in Block

journeys JourneyRef 1: * Reference(s) to (or DeadRuns) which make up a Block.VehicleJourneys

Transport Modes

Mode

(withcorrespondingsubmodeelement)

( )

air

(AirSubmode)

bus

(BusSubmode)

cableway

(TelecabinSubmode)

coach

(CoachSubmode)

funicular

(FunicularSubmode)

metro

(MetroSubmode)

rail

(RailSubmode)

Submodes (allowed

)values

( )

domesticFlight airportLinkBus telecabin internationalCoach funicular metro airportLinkRail

helicopterService expressBus nationalCoach urbanRailway international

internationalFlight localBus touristCoach interregionalRail

nightBus local

metroReplacementBus longDistance

railReplacementBus nightRail

miniBus regionalRail

regionalBus touristRailway

schoolBus

shuttleBus

sightseeingBus

tramReplacementBus

= suggested expansion, not yet in use! Grey text

stops

Allowed transport types with submodes. These are defined by and based on clAllVehicleModesOfTransportEnumeration TPEGassification.

air = aeroplanes and helicoptersbus = street busescableway = gondolas or any form of transport suspended by wirecoach = long distance bus services, usually including separate luggage spaces and a toilet)funicular = cable drawn service on a railway track, often traversing extreme incline routes (mountainsides)metro = In Norway specifically including Oslo subwayrail = heavy trains, or historical heritage rail servicestaxi = taxi (e.g. supplementary- and replacement transport)tram = In Norway the specific concepts of trams (sporvei or "trikk") and the Bergen specific service "Bybanen".water = waterborne transport types

See appendix for more detailed description, definition and examples of the transport modes used in Norway.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728727624

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-VehicleJourney

https://enturas.atlassian.net/wiki/download/attachments/728727624/TransportModes.doc?version=1&modificationDate=1549616835454&cacheVersion=1&api=v2

of 105

Content

ContentComponents

PlaceTopographicPlaceAddressablePlaceSiteElementSite

LevelEntrance

Group of Stop PlacesGroupOfStopPlaces

StopPlaceStopPlaceStopPlaceSpaceQuayBoardingPositionInner Objects

AccessSpacePathLinkPathJunctionEquipmentPlaceSiteFacilitySet

Flexible Stop PlaceFlexibleStopPlaceFlexibleQuayFlexibleAreaHailAndRideArea

Point of InterestPointOfInterest

ParkingParkingParkingAreaParkingPropertiesParkingCapacity

NavigationSiteConnection

SiteConnectionEndStructureNavigationPath

PathLinkEndStructure

This document is part of the NeTEx Profile and describes data elements for the exchange of Norwegian place-, and stop place related viainformation the NeTEx format.

Components

Place

TOPOGRAPHICPLACE

TopographicPlace < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject


VersionCurrent version for is: (last changed ) stops v1.3 23 Aug 2018

An abstract data type for geospatial settlement or inhabited areas, such as city, rural area or suburb.


Defined in SiteFrame

of 105

IsoCode SubdivisionIdType 0: 1 ISO 3166-2 code to identify region county/territory

For example [LK]-[OK]LK = two letter country code [LK] according to ISO 3166-1 alfa-2

OK = two letter area code [OK] according to ISO 3166-2:NO

Examples:

NO-02 – AkershusNO-09 – Vest Agder

TopographicPlaceType TopographicPlaceTypeEnumeration 0: 1 Classification of areas:

country (nationstate)county ( )first level subdivision of countrycity ( )cityinterregion ( )region spanning several other regionsmunicipality ( )second level subdivision of countryplaceOfInterest (sometimes known as pointOfInterest, or POI)region ( )area/region

CountryRef CountryPrincipalityCodeType 0: 1 Two letter country code [LK] according to ISO 3166-1 alfa-2

Only mandatory for TopographicPlaceType "county"

ParentTopographicPlaceRef TopographicPlaceRef 0: 1 Reference to parent area for an area. For example: a municipality istypically a subdivision of a parent county-region.

ADDRESSABLEPLACE

AddressablePlace < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject


Url xsd:anyURI 0: 1 URL related to the place

PostalAddress PostalAddress 0: 1 Postal address for the place

RoadAddress RoadAddress 0: 1 Road/street address for the place

Mandatory for objects which should be linked to road networks, e.g. and /Entrance StopPlace Quay

SITEELEMENT

SiteElement < < < < < < AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


AccessibilityAssessment AccessibilityAssessment 1: 1 forStopPlace

Universal Design - description, see Accessibility Assessment definition

alternativeNames AlternativeName 0: * List of alternative names for Site

PublicUse PublicUseEnumeration 0: 1 Specify for whom the place is available:

allpublicOnlyauthorisedPublicOnlydisabledPublicOnlystaffOnly

Covered CoveredEnumeration 0: 1 Specify whether the place has a roof (is covered and protects people from e.g. rain orsnow):

covered ( )just a roofindoors ( )roof and wallsoutdoors ( )no roof or wallsmixed ( )partially roofed/indoor

Gated GatedEnumeration 0: 1 Specify whether the place/area is open or gated:

openAreagatedAreaunknown

A place which can have address information


An abstract type which describes a superordinate place.


of 105

Lighting LightingEnumeration 0: 1 Specify the lighting situation of the place:

wellLitpoorLitunlitunknown

facilities SiteFacilitySet 0: * List of available facilities

SITE

Site < < < < < < < SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


TopographicPlaceRef TopographicPlaceRef 0: 1 Reference to parent area ( ).TopographicPlace

Locale Locale 0: 1 Information about Locale.

OrganisationRef OrganisationRef 0: 1 Reference to governing or operating for the place.organisation

ParentSiteRef ParentSiteRef 0: 1 Reference to which contains this Site.SiteValue dependent on context.

levels Level 0: * List of levels (floors) of Site.

entrances Entrance 0: * Description of entrance objects (mandatory if Site is a building).

equipmentPlaces EquipmentPlace 0: * Description of equipment.

Used to set Location for PlaceEquipment/LocalService if relevant.

placeEquipments Equipment 0: * Description of available .installed equipment

localServices Equipment 0: * Description of available .LocalServices

Level

Level < DataManagedObject


Name MultilingualString 1: 1 Name of level, e.g. "1", "A", "first floor"

Description MultilingualString 0: 1 Description

PublicUse xsd:boolean 0: 1 Specifies if the floor is accessible to the public, or if access permission is required

AccessibilityAssessment AccessibilityAssessment 0: 1 Description of Universal Design accessibility.

Entrance

Entrance < SiteComponent < < < < < < < SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


LevelRef LevelRef 0: 1 Reference to a .Level

checkConstraints CheckConstraint 0: * Description of security checkpoints, barriers or other potentially delaying factors.

equipmentPlaces EquipmentPlace 0: * Description of available equipment.

An abstract type describing a place.


Description of levels (floors in a building).



Description of entrances.


Examples in the the GitHub-repository



of 105

placeEquipments InstalledEquipment 0: * Description of permanently installed equipment. See for more informationEquipment Typesregarding which objects may be used here.

EntranceType EntranceEnumeration 0: 1 Classification of entrance:

openingopenDoordoorswingDoorrevolvingDoorautomaticDoorticketBarriergate

isEntry xsd:boolean 0: 1 Specifies whether an object is an entrance.

isExit xsd:boolean 0: 1 Specifies if an object is an exit.

Width xsd:decimal 0: 1 The width of an entrance (in meters).

Height xsd:decimal 0: 1 Height (clearance) of an entrance (in meters).

Group of Stop Places

GROUPOFSTOPPLACES

GroupOfStopPlaces < < GroupOfEntities DataManagedObject


PurposeOfGroupingRef xsd:normalizedString

predefined values, seeDescription

1: 1 Categorization for the grouping, defined by referencing predefined PurposeOfGrouping:

generalization (grouping of prominent stop places with a superordinate Place, for)example, a town, or city centre

cluster (stop places in proximity to each other which have a natural geospatial- or)public transport related relationship

Example:<PurposeOfGroupingRef ref="NSR:PurposeOfGrouping:generalization"/>

members StopPlaceRef 2: * List of references ( ) to stop places includedStopPlace ID from national stop place registryin the group

alternativeNames AlternativeName 0: * List of alternative names for the grouping

StopPlace

STOPPLACE

StopPlace < < < < < < < < Site SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


(attr) modification ModificationEnumeration 0: 1 Type of change (audit action). For example when deleting adeletestop place.

Description normalizedString 0: 1 Description. Used to supplement stop place name. Usage of this field isclosely tied to which fields are made public in the end.

TransportMode VehicleModeEnumeration 1: 1 Main transport type for the stop place.

See for possible values.Transport Modes

A grouping normally used to tie together stop places in close proximity to each other. This can be used to link several major stop placesinto a "hub". .Not to be confused with parentStopPlace (multimodal StopPlace)




Description of stop place.




https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728563946/StopPlace+-+complex


of 105

(choice) AirSubmode AirSubmodeEnumeration 0: 1 Submodes for air.

See for possible valuesTransport Modes

(choice)BusSubmode

BusSubmodeEnumeration 0: 1 Submodes for bus.


(choice)FunicularSubmode

FunicularSubmodeEnumeration 0: 1 Submodes for funicular.


(choice)MetroSubmode

MetroSubmodeEnumeration 0: 1 Submodes for metro.


(choice)TramSubmode

TramSubmodeEnumeration 0: 1 Submodes for tram.


(choice)TelecabinSubmode

TelecabinSubmodeEnumeration 0: 1 Submodes for telecabin.


(choice)RailSubmode

RailSubmodeEnumeration 0: 1 Submodes for rail.


(choice)WaterSubmode

WaterSubmodeEnumeration 0: 1 Submodes for waterborne transport types.


OtherTransportModes VehicleModeListOfEnumerations(tilsvarer

)VehicleModeEnumeration

0: * List of other available transport types (valid values are the same as fortransport type).


tariffZones TariffZoneRef 0: * Reference to associated with the stop place.TariffZone

StopPlaceType StopTypeEnumeration 1: 1 Classification of stop place:

onstreetBus (bus stops)onstreetTram (tram stops)taxiStand (taxi stations)airport (airports)railStation (railway stations)metroStation (metro or subway stations)busStation (bus terminals (different from regular bus stops))harbourPort (ports where cars may board or disembark a ship)ferryStop (ports where people can board or disembark a ship)liftStation (station for a cable borne vehicle)

Mandatory when StopPlace has one or more subordinate Quay.Not mandatory if the StopPlace is a parentStop.

BorderCrossing xsd:boolean 0: 1 Specifies if the stop is an international border crossing.

Weighting InterchangeWeightingEnumeration 0: 1 Relative weighting for interchanges at the stop.

preferredInterchangerecommendedInterchangeinterchangeAllowednoInterchange

Corresponds to Priority for Interchange

quays Quay 1: * ( )for leaf StopPlace

0 (for parent StopPlace)or unknown Quay

List of Quays at the StopPlace

One or more for normal StopPlaces. Specifies exact boardingposition.Must be with subordinatenone if the StopPlace is a parentStopStopPlaces.

accessSpaces AccessSpace 0: * List of access spaces at the StopPlace

pathLinks PathLink 0: * Elements describing part of a path link (walking link)

pathJunctions PathJunction 0: * Part of a path link which describes a point where one or many PathLink connect to each other.s

navigationPaths NavigationPath 0: * Description of path links at- or associated with the StopPlace.

Used only when path links should be overridden, or if it is not relevantto define pathLinks for the StopPlace.

STOPPLACESPACE

An abstract class describing details for an area within a StopPlace.


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable#timetable-Interchange

of 105

StopPlaceSpace < < < < < < < SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


entrances Entrance 0: * Description of entrances

QUAY

Quay < < < < < < < < StopPlaceSpace SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


PrivateCode xsd:normalizedString 0: 1 Internal code or information not to be presented to the public.

PublicCode xsd:normalizedString 0: 1 A public code for a Quay, usually linked to a physical sign with a letter or number for theplatform/track.

(attr) modification xs:ModificationEnumeration 0: 1 Type of change (audit action). For example when deleting a Quay.delete

CompassBearing AbsoluteBearingType 0: 1 The compass bearing (direction) of the Quay, i.e. which direction will vehicles leaving theQuay travel. Set in degrees.

boardingPositions BoardingPosition 0: * List of boarding positions along a Quay, typically used for railway platforms.

BOARDINGPOSITION

BoardingPosition < < < < < < < < StopPlaceSpace SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


Label MultilingualString 1:1 A code usually linked to a physical sign with a letter or number for theplatform/track.

BoardingPositionType BoardingPositionTypeEnumeration 1:1 Classification for BoardingPosition:

positionOnRailPlatform

INNER OBJECTS

AccessSpace

AccessSpace < < < < < < < < StopPlaceSpace SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


A part of where passengers can board or disembark a vehicle. For example tactile paving position at a bus stop, theStopPlacemidpoint of a railway platform, a gate at an airport.

See definition under General information.

Examples in the .GitHub-repository

Please note:

Quays do have their own names. This information is inherited from the parent StopPlace.notQuayType is to be specified. This information is inherited from TransportMode on the parent StopPlace. The NorwegiannotNeTEx profile does not allow "multimodal" Quays.

Description of a boarding position. Currently defined to be used only for rail.



Description of waiting areas on a StopPlace



https://github.com/entur/profile-norway-examples/blob/master/netex/stops/BasicStopPlace_example.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/stops/OsloS_station_example.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/stops/OsloS_station_example.xml

of 105

AccessSpaceType AccessSpaceTypeEnumeration 1: 1 Classification of AccessSpace:

concourse ( )for example the main hall of a central train station or an airport terminalunderpassoverpasspassageliftwaitingRoomstaircase

PathLink

PathLink < < Link DataManagedObject


From PathLinkEndStructure 1: 1 Starting position for the PathLink

To PathLinkEndStructure 1: 1 End position for the PathLink


AccessibilityAssessment AccessibilityAssessment 0: 1 Universal Design - description of the path link

Only used when AccessibilityAssessment for of which the PathLink is a NavigationPathpart, needs to be specified in further detail.

Covered CoveredEnumeration 0: 1 Possible values:

indoorsoutdoorsmixed

Gated GatedEnumeration 0: 1 Possible values:

gatedAreaopenArea

Lighting LightingEnumeraion 0: 1 Possible values:


AllowedUse DirectionOfUseEnum 0: 1 Possible values:

updownboth

Transition TransitionEnum 0: 1 Possible values:

updownlevelupAndDowndownAndUp

AccessFeatureType AccessFeatureEnum 0: 1 Possible values:

liftescalatortravelatorrampstairscrossingbarriernarrowEntranceconcoursequeueManagementstreetpavementfootpathpassage

A link between two -objects which describe a (possible) path link between them.Place


of 105

PassageType PassageTypeEnum 0: 1 Possible values:

pathwaycorridoroverpassunderpasstunnelnone

TransferDuration TransferDuration 0: 1 Duration of time needed to traverse the path link

checks CheckConstraint 0: 1 Processes or constraints which may cause queues or delays.

PathJunction

PathJunction < < Point DataManagedObject



indoorsoutdoorscoveredmixed


gatedAreaopenArea



EquipmentPlace

EquipmentPlace < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject


placeEquipments Equipment 0: * Description of available equipment. Use the classes which inherit from Equipment. For more details, see Equip.mentTypes

SiteFacilitySet

SiteFacilitySet < < FacilitySet DataManagedObject


LuggageLockerFacilityList LuggageLockerFacilityLisfOfEnumerations 0: 1 Possible values:

lockers

LuggageServiceFacilityList LuggageServiceFacilityLisfOfEnumerations 0: 1 Possible values:

leftLuggagebaggageChekInCheckOut

A junction within-, or connected to a or , where path links meet or split.StopPlace PointOfInterest


Available equipment at a Site.


Description of services available for a Site.





of 105

ParkingFacilityList ParkingFacilityLisfOfEnumerations 1: 1 Possible values:

carParkparkAndRideParkmotorcycleParkcyclePark

Flexible Stop Place

FLEXIBLESTOPPLACE

FlexibleStopPlace < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject


TransportMode VehicleModeEnumeration 1: 1 Main transport mode for the stop place.


areas (choice) FlexibleArea 1: 1 Zones where on-demand transport is available.

(choice) HailAndRideArea Road sections/segments where the transporting vehicle may be hailed.

FLEXIBLEQUAY

FlexibleQuay < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject


TransportMode VehicleModeEnumeration 0: 1 Transport type for the flexible Quay (used to override transport type defined in superordinate FlexibleStop)


FLEXIBLEAREA

FlexibleArea < < < < < < FlexibleQuay Place Zone GroupOfPoints GroupOfEntities DataManagedObject


Name normalizedString 0: 1 Name of the area ( ).if necessary for override/detail

Description normalizedString 0: 1 Description of area ( ).if for override/detailnecessary

destinations DestinationDisplayRef 0: * References to objects.DestinationDisplay

HAILANDRIDEAREA

HailAndRideArea < < < < < < FlexibleQuay Place Zone GroupOfPoints GroupOfEntities DataManagedObject


destinations DestinationDisplayRef 0: * References to objectsDestinationDisplay

Description of a stop place area for on demand transport (FlexibleLines).



Description of a specific area where on-demand transport is possible.



Description of an area for on-demand transport, in practice, a .FlexibleQuay


Description of an area where it is possible to hail a vehicle.


of 105

StartPointRef PointRef 1: 1 Start of section

EndPointRef PointRef 1: 1 End of section

Point of Interest

POINTOFINTEREST

PointOfInterest < < < < < < < < Site SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


nearTopographicPlaces TopographicPlaceRef 0: * References to nearby -objectsTopographicPlace

pathLinks PathLink 0: * An element which describes a part of a path link.

pathJunctions PathJunction 0: * Part of a path link which describes where one or more are connected.PathLinks

navigationPaths NavigationPath 0: * Description of a path to or from a POI.

Used when overriding a pathLink, or as a piece of stand-alone information if it is notonlyrelevant to define pathLinks for the StopPlace.

Parking

PARKING

Parking < < < < < < < < Site SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


pathLinks PathLink 0: * An element which describes part of a path link

pathJunctions PathJunction 0: * Part of a path link which describes a point where one or more arePathLinksconnected.

navigationPaths NavigationPath 0: * Navigation description to and from a parking location.

Used when overriding a pathLink, or as stand-alone information if it isonlynot relevant to define pathLinks for the StopPlace.

ParkingType ParkingTypeEnumeration 0: 1 Classification of parking:

parkAndRide

ParkingVehicleType ParkingVehicleEnumeration 0: 1 Possible vehicle types:

carmotorcyclepedalCycle

ParkingLayout ParkingLayoutEnumeration 0: 1 Type/layout of parking values:

openSpacemultistoreyundergroundroadside

PrincipalCapacity xsd:nonNegativeInteger 0: 1 Available public parking spaces (reservable spaces excluded)

TotalCapacity xsd:nonNegativeInteger 0: 1 Total number of parking spaces (reservable spaces included)

When the number of reservable spaces is unknown, only specify TotalCapacity.

OvernightParkingPermitted xsd:boolean 0: 1 Specifies if overnight parking is allowed

A location (POI) which may be of interest to people utilizing public transport, for example, museums, stadiums or monuments.



A place to park private road vehicles.

Please note that a parking location always needs to refer to a StopPlace by means of Site/parentSiteRef.





of 105

RechargingAvailable xsd:boolean 0: 1 Specifies if the parking area has charging stations for electrical vehicles

Secure xsd:boolean 0: 1 Specifies if the parking area is guarded by some form of security service.

RealTimeOccupancyAvailable xsd:boolean 0: 1 Specifies whether the parking area has real-time information regardingoccupancy.

ParkingReservation ParkingReservationEnumeration 0: 1 Parking reservation values:

noReservationsregistrationRequiredreservationRequiredreservationAllowed

BookingUrl xsd:anyURI 0: 1 URL for reserving a parking space

FreeParkingOutOfHours xsd:boolean 0: 1 Specifies whether parking at the area is free outside "office hours".

parkingProperties ParkingProperties 0:* Additional properties for the parking area

parkingAreas ParkingArea 0: * Description of individual areas inside the parking.

PARKINGAREA

ParkingArea < ParkingComponent < < < < < < < < SiteComponent SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject


Label MultilingualString 0: 1 Label or identifier for the subsection presented to the public

TotalCapacity xsd:nonNegativeInteger 0: 1 Total capacity for the specific subsection

ParkingProperties ParkingProperties 0: 1 Additional properties for the parking subsection

PARKINGPROPERTIES

ParkingProperties < < < VersionedChild EntityInVersion Entity


ParkingUserTypes ParkingUserListOfEnumerations 0: 1 User classification:

allregisteredregisteredDisabledresidentsWithPermits

MaximumStay xsd:duration 0: 1 Maximum allowed time to stay parked

spaces ParkingCapacity 0: * A detailed description of the parking capacity

PARKINGCAPACITY

ParkingCapacity < < < VersionedChild EntityInVersion Entity


ParkingVehicleType ParkingVehicleEnumeration 1: 1 Vehicle types:

carmotorcyclepedalCycle

A subsection of a parking area.


Additional properties for a parking.


A detailed description of the parking capacity.


of 105

ParkingStayType ParkingStayEnumeration 0: 1 Parking duration values:

shortStaylongTermdropoffunlimited

NumberOfSpaces xsd:nonNegativeInteger 0: 1 Number of parking spaces

Navigation

SITECONNECTION

SiteConnection < < Transfer DataManagedObject


From SiteConnectionEndStructure 1: 1 The starting point for SiteConnection

To SiteConnectionEndStructure 1: 1 The endpoint for SiteConnection

navigationPaths NavigationPath 0: * Possible path links between -objectsSite

SiteConnectionEndStructure

SiteConnectionEnd


StopPlaceRef StopPlaceRef 0: 1 Reference to the in questionStopPlace

QuayRef QuayRef 0: 1 Reference to the in questionQuay

StopPlaceEntranceRef StopPlaceEntranceRef 0: 1 Reference to the in questionEntrance

NAVIGATIONPATH

NavigationPath < < LinkSequence DataManagedObject


From PathLinkEndStructure 0: 1 The starting point for the path link

To PathLinkEndStructure 0: 1 The endpoint for the path link

AccessibilityAssessment AccessibilityAssessment 1: 1 Universal Design - Description of the path link

TransferDuration TransferDuration 0: 1 Specifies the duration of the transfer


indoorsoutdoorscoveredmixed


gatedAreaopenArea



Description of the navigation possibility between two Sites, for example between two StopPlaces, or two Quays.



A detailed description of the path between two places ( )can usually be derived automatically from PathLinks





of 105

NavigationType NavigationTypeEnumeration 1: 1 Path link types:

hallToQuayhallToStreetquayToHallquayToStreetstreetToHallstreetToQuaystreetToSpacestreetTostreetspaceToHallhallToSpacespaceToSpaceother

pathLinksInSequence PathLinkInSequence 0: * Sequential list of , that describe each part of the total walk path.PathLinks

PathLinkEndStructure

PathLinkEndSturcture


PlaceRef PlaceRef 0: 1 Reference to Place

network

Content

ComponentsNetwork components

NetworkGroupOfLinesLine

PresentationTariffZone

ServiceTypeOfService

RouteRouteRoutePointScheduledStopPointTimingPointPointOnRouteRouteLinkServiceLinkStop Assignment

StopAssignmentPassengerStopAssignmentFlexibleStopAssignmentTrainStopAssignment

Journey PatternJourneyPattern

StopPointInJourneyPatternBookingArrangementsStructureTimingPointInJourneyPatternLinkInJourneyPatternTimingLinkInJourneyPatternServiceLinkInJourneyPattern

DestinationDisplayDestinationDisplayVariantVia

Flexible transportFlexibleLineFlexibleStopAssignment

TransfersTransfer

TransferDuration

This document is part of the Norwegian NeTEx profile and describes data elements related to transport networks used for public transport dataexchange in the NeTEx format.

Please note the network part of the profile describes structures, attributes, and geospatial objects, which make up the framework of the

VersionCurrent version for is: (last changed ) network v1.3 30 Aug 2018

of 105

timetable data. It does not, however, describe time-related concepts, such as departure times, or operational days. All of these aredescribed in .timetable

Components

Network components

NETWORK

Network < < < network#GroupOfLines GroupOfEntities DataManagedObject


Name MultilingualString 1: 1 Name of the network.

AuthorityRef OrganisationRefStructure 1: 1 Organisation responsible (for example owner) for the network.

groupsOfLines network#GroupOfLines 0: * Lines ( ) included in the network.network#Line

tariffZones tariffZoneRefs 0: * Tariff zones ( ) in the network ( ).network#TariffZone when relevant

GROUPOFLINES

GroupOfLines < < GroupOfEntities DataManagedObject


Name MultilingualString 1: 1 Group name

members lineRefs 0: 1 An explicit listing of lines included in the group (if appropriate)

Note that reference should link from up to through network#Line network#Network a RepresentedByGroupRef

MainLineRef LineRefStructure 0: 1 Reference to the primary line in the group.

TransportMode AllVehicleModesOfTransportEnumeration 0: 1 The transport mode of the group.

See for possible valuesTransport Modes

LINE

Line < DataManagedObject


(attr) modification xs:ModificationEnumeration 0: 1 Type of modification (use "delete" when a Line is permanently)discontinued

Name MultilingualString 1: 1 Name of the line

ShortName MultilingualString 0: 1 Short name (e.g. short version of commonly (publicly) known name)


A transport network is an "umbrella" structure for all which share relevant features, such as the ownership of thenetwork#Lineslines. Lines can also be grouped as , of which Network is a sub-type, but this is optional).GroupOfLines



Examples in the (including )GitHub-repository use of additionalNetworks

Grouping of lines.



Line (grouping of Routes) with a name or number (PublicCode).




https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370410/timetable

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-GroupOfLines

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-GroupOfLines

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Line

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TariffZone


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Network

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Lines

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-GroupOfLine

https://github.com/entur/profile-norway-examples/blob/master/netex/network/Line61A.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-additionalNetworks.xml


of 105

TransportMode AllVehicleModesOfTransportEnumeration 1: 1 See in for valid valuesMode Transport Modes

TransportSubmode TransportSubmode 1: 1 See in for valid values (Submodes Transport Modes must be aTransportSubmode belonging to the selected TransportMode)

Url xsd:anyURI 0: 1 URL to a website with information about the line.

PublicCode xsd:normalizedString 0: 1 The publicly advertised line number, or code of the line.

Usually a number, or a number combined with a letter (eg L2, 31, 30Eetc.).

The Name field normally contains more information than thePublicCode, and is often the combination of PublicCode + Name.

PrivateCode xsd:normalizedString 0: 1 Internal (non-public) identifier for the line. For example, a code used bytransport planners.

ExternalLineRef ExternalObjectRef 0: 1 Reference (ID) to a related Line (for example, the regular line for whichthis is a replacement).

OperatorRef OperatorRefStructure 1: 1 Reference to the main (may be omitted in operator exceptional cases,).such as a different operator for every departure

additionalOperators transportOrganisationRef 0: * Reference to additional operators of the line

TypeOfLineRef TypeOfLineRef 0: 1 Reference to the line type. Classification, (e.g. replacement line)

Monitored xsd:boolean 0: 1 Specifies whether real-time information normally is available for this line(set to when real-time data exists for the line).true

routes RouteRef 0: * Reference to a listing of all routes ( ) which are part of thenetwork#Routeline.

The references can normally be deduced from Line references in Route. Therefore this field is only relevant in exceptional cases).s

RepresentedByGroupRef GroupOfLinesRefStructure 1: 1 Reference to the Lines' (alternatively a more specificnetwork#Networkreference to the ).GroupOfLines

Presentation network#Presentation 0: 1 Graphical representation information (colour, text, etc.)

AccessibilityAssessment AccessitilityAssessment 0: 1 Universal Design - Description of the line

Presentation

Presentation


Colour ColourValueType 0: 1 Six digit hexadecimal representation of the lines' RGB colour values.

TextColour ColourValueType 0: 1 Six digit hexadecimal representation of the lines' RGB colour values.

TextFont xsd:normalizedString 0: 1 Font identifier (font). Normally not specified.

TARIFFZONE

TariffZone < < < < Zone GroupOfPoints GroupOfEntities DataManagedObject


TariffZone inherits from Zone and does not introduce new elements or attributes.

Service

Description of values used for presenting line information, such as fonts and colours, etc. which may be used on graphicalrepresentations of the line, such as maps or printed publications.

It is required to fill out at least one field (of the ones listed below) in order to have a valid resentation. The default white P values are (FFFFFF) Colour with black TextColour (000000).


Geospatial area/zone used to calculate fares.



Example found in GitHub-repository

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Route



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Network

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-GroupOf

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Presentation

https://en.wikipedia.org/wiki/Web_colors

https://en.wikipedia.org/wiki/Web_colors

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-Presentation.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/site/submodel-StationWithEquipment.xml

of 105

TYPEOFSERVICE

TypeOfService < < TypeOfValue DataManagedObject


TypeOfService inherits fromTypeOfValue and does not introduce new elements or attributes.

Route

ROUTE

Route < < LinkSequence DataManagedObject


LineRef LineRefStructure 1: 1 Reference to Line ( ) to which the Route belongs.network#Line

DirectionType DirectionTypeEnumeration 0: 1 The direction of the route:

inbound (towards the city centre or transport hub)outbound (from the city centre or transport hub)clockwise (circular route in the clockwise direction)anticlockwise (circular route in the anticlockwise direction)

To be able to identify full- or partial circular routes clockwise/anticlockwise must be specified.

pointsInSequence network#PointOnRoute 1: * List of the routes points

InverseRouteRef RouteRefStructure 0: 1 Reference to any route that goes in the opposite direction

ROUTEPOINT

RoutePoint < < Point DataManagedObject


BorderCrossing xsd:boolean 0: 1 Specifies whether the point is on the border between two countries.

SCHEDULEDSTOPPOINT

ScheduledStopPoint < < < network#TimingPoint Point DataManagedObject


Classification of a service.



Description of a route, specified as a sorted list of RoutePoints.




A point that is a stop place in a route.




Point for planned disembarking and/or boarding. Linking to / is done through . StopPlaces Quays network#StopAssignment AllScheduledStopPoint must have such a link.





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-PointOnRoute

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TimingPoint



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-StopAssignment


of 105

tariffZones TariffZoneRef 0: 1 List of TariffZones ( ) the StopPoint belongs to.network#TariffZone

Presentation network#Presentation 0: 1 Graphical elements related to StopPoint

TIMINGPOINT

TimingPoint < < Point DataManagedObject


TimingPointStatus TimingPointStatusEnumeration 0: 1 Type of TimingPoint:

timingPointnotTimingPoint (may indicate the expected passing time)

AllowedForWaitTime xsd:duration 0: 1 Allowed waiting time at the TimingPoint.

POINTONROUTE

PointOnRoute < < < < PointInLinkSequence VersionedChild EntityInVersion Entity


LinkSequenceRef LinkSequenceRefStructure 0: 1 Reference to to which the point belongs.LinkSequence

RouteRef should be used, since inherits from .network#Route LinkSequence

Note that the field should be used if PointOnRoute is defined inline in .not network#Route

projections Projection 0: * Projection on a point (RoutePoint, TimingPoint, SchedueledStopPoint) or a gml-coordinateprojection .

PointRef PointRefStructure 1: 1 Reference to Point

RoutePointRef should be used to point to the corresponding .network#RoutePoint

ROUTELINK

RouteLink < < Link DataManagedObject


FromPointRef RoutePointRef 1: 1 The start point for the RouteLink

ToPointRef RoutePointRef 1: 1 The endpoint for the RouteLink

SERVICELINK

ServiceLink < < Link DataManagedObject

Point for registering passing times. Usually, not a place where the vehicle stops, nor a place relevant to passengers, though it can beused to indicate places where the vehicle waits.



Link between and Route RoutePoint.



Link (with direction) between two RoutePoints.



Link (with direction) between two .stop points



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TariffZone

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Presentation



https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-RoutePoint


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-ScheduledStopPoint

of 105


Distance xsd:decimal 0: 1 Distance in for ServiceLink, i.e. between FromPoint and ToPoint.meters driving distance

projections LinkSequenceProjection 0: 1 Projection with <gml:LineString> indication of position.

FromPointRef ScheduledStopPointRef 1: 1 The start point for the ServiceLink.

ToPointRef ScheduledStopPointRef 1: 1 The endpoint for ServiceLink.

STOP ASSIGNMENT

StopAssignment

StopAssignment < < Assignment DataManagedObject


ScheduledStopPointRef ScheduledStopPointRef 1: 1 Reference to network#ScheduledStopPoint

PassengerStopAssignment

PassengerStopAssignment < < < network#StopAssignment Assignment DataManagedObject


elem StopPlaceRef StopPlaceRef 0: 1 Reference to which is related to StopPlace network#ScheduledStopPoint

Should be included as far as possible, but the StopPlace can also be derived from thereferenced Quay (QuayRef) when the StopPlaceRef is missing

elem QuayRef QuayRef 1: 1 Reference to an actual on Quay StopPlace

elem trainElements TrainStopAssignmentRef 0: * References to a detailed position on platform ( )network#TrainStopAssignment

Used only for trains

attr order xsd:integer 1: 1 The Assignment order.The "order" attribute is inherited from the more generic type Assignment, but in the case of aPassengerStopAssignment its business meaning is undefined. It is however mandatory dueto an XML schema validation constraint.Examples of valid implementations:

an incremented sequence number ("1", "2", "3", ...)a constant value ("0")

FlexibleStopAssignment

FlexibleStopAssignment < < < network#StopAssignment Assignment DataManagedObject


FlexibleStopPlaceRef FlexibleStopPlaceRef 1: 1 Reference to which is related to FlexibleStopPlace network#ScheduledStopPoint

Abstract class used to describe the link between and ScheduledStopPoint StopPlace.


Link between and or ScheduledStopPoint StopPlace Quay


ttrt

https://github.com/entur/netex-norway-examples/blob/master/netex/network/Line61A.xml



Link between and ScheduledStopPoint FlexibleStopPlace.

Defined in ServiceFrame (the same way as )PassengerStopAssignment




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TrainStopAssignment



https://github.com/entur/netex-norway-examples/blob/master/examples/network/Line61A.xml


https://github.com/entur/netex-norway-examples/blob/master/examples/network/Line61A.xml


of 105

(choice) FlexibleQuayRef FlexibleQuayRef 0: 1 Reference to a FlexibleQuay.

Can be added in a supplementary role if a FlexibleQuay is used.

(choice) FlexibleAreaRef FlexibleAreaRef 0: 1 Reference to an actual FlexibleArea

Can be added in a supplementary role if a is defined for the FlexibleArea FlexibleStopPla.ce

(choice)HailAndRideAreaRef

HailAndRideAreaRef 0: 1 Reference to an actual HailAndRideArea

Can be added in a supplementary role if a is defined for the HailAndRideArea FlexibleSto.pPlace

TrainStopAssignment

TrainStopAssignment < < < network#StopAssignment Assignment DataManagedObject


PassengerStopAssignmentRef PassengerStopAssignmentRef 0: 1 Reference to network#PassengerStopAssignment

TrainRef TrainRef 0: 1 Reference to Train.

TrainComponentRef TrainComponentRef 0: 1 Reference to specific cars ( ).TrainComponent

BoardingPositionRef BoardingPositionRef 0: 1 Reference to BoardingPosition.

EntranceToVehicle MultilingualString 0: 1 Specifying entrances to the carriage, e.g. "front door","rear door", etc.

Journey PatternJOURNEYPATTERN

JourneyPattern < < LinkSequence DataManagedObject


PrivateCode xsd:normalizedString 0: 1 Internal (non-public) identifier for the JourneyPattern.

RouteRef RouteRef 1: 1 Reference to used in the JourneyPattern.network#Route

runTimes JourneyPatternRunTime 0: * Description of RunTimes for the JourneyPattern.

Only used when describing frequency-based departures.

waitTimes JourneyPatternWaitTime 0: * Description of WaitTime for JourneyPattern

used only when describing frequency-based departures.Normally

headways JourneyPatternHeadway 0: * Description of JourneyHeadway for JourneyPattern

Only used when describing frequency-based departures.

pointsInSequence PointInJourneyPattern 0: * Sorted list of points in JourneyPattern. Must be or network#StopPointInJourneyPattern net.work#TimingPointInJourneyPattern

linksInSequence network#LinkInJourneyPattern 0: * Sorted list of links in JourneyPattern. Must be or network#ServiceLinkInJourneyPattern net.work#TimingLinkInJourneyPattern

StopPointInJourneyPattern

Link between (train cars) and / / .TrainComponent StopPlace Quay BoardingPosition



Sorted list of / and/or for a .ScheduledStopPoint TimingPoint Links Route



ScheduledStopPoint in a JourneyPattern.




https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-PassengerStopAssignment


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-StopPointInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TimingPointInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TimingPointInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-LinkInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-ServiceLinkInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TimingLinkInJourneyPattern



of 105

StopPointInJourneyPattern < < < < PointInLinkSequence VersionedChild EntityInVersion Entity


ScheduledStopPointRef ScheduledStopPointRef 1: 1 Reference to network#ScheduledStopPoint

ForAlighting xsd:boolean 0: 1 Specifies whether alighting is allowed.

Should be explicitly (normally "false") for the StopPointInJouindicated first rneyPattern

ForBoarding xsd:boolean 0: 1 Specifies whether boarding is allowed.

(normally "false") for StopPointInJourneShould be explicitly indicated last yPattern

DestinationDisplayRef DestinationDisplayRef 0: 1 Reference to network#DestinationDisplay

The required minimum for linear routes is for StopPointInJourneythe firstPattern to have a DestinationDisplayRef. For circular routes, the minimumis two.

A new DestinationDisplayRef should be set at anyStopPointInJourneyPattern along the route where it is relevant to update

. This is particularly relevant for circular routes.the destination text

FlexiblePointProperties network#FlexiblePointProperties 0: 1 Properties of a stop point related to flexible transport.

RequestStop xsd:boolean 0: 1 Specifies whether passengers must signal to use this stop point.

RequestMethod RequestMethodTypeEnumeration 0: 1 Possible values for hailing or arranging a stop:

handSignalphoneCallsmsstopButtonturnOnLight

BookingArrangements network#BookingArrangementsStructure 0: 1 Rules for booking.

Please note that BookingArrangements specified at the StopPointInJourneyPattern level will equivalent specifications at the always override Line-

ServiceJourneyor level.

BookingArrangementsStructure

BookingArrangementsStructure


BookingContact ContactStructure 0: 1 Contact information for booking

Note that the field is if this is not already on mandatory network#FlexibleLineor overridden in FlexibleServiceProperties

BookingMethods BookingMethodListOfEnumerations 0: 1 Possible ways to book (must match info found in BookingContact):

callDrivercallOfficeonlinephoneAtStoptext (text message/SMS)


BookingAccess BookingAccessEnumeration 0: 1 Who may place an order (book):

publicauthorisedPublic (eg TT-transport - special services for mobility

)restricted travellers staff

Details for booking public transport services to a specific in an otherwise non-flexible line, or when theStopPointInJourneyPatternbooking details for the stop deviate from those in a .FlexibleLine


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-DestinationDisplay

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-FlexiblePointProperties

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-BookingArrangementsStructure

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-FlexibleLine


https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-StopPointInJourneyPattern

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370412/network#network-FlexibleLine

of 105

BookWhen PurchaseWhenEnumeration 0: 1 Time constraints for booking:

timeOfTravelOnlydayOfTravelOnlyuntilPreviousDayadvanceAndDayOfTravel


BuyWhen PurchaseMomentListOfEnumerations 0: 1 Time constraints for payment:

onReservationbeforeBoardingafterBoardingonCheckOut

LatestBookingTime xsd:time 0: 1 Latest possible booking time.

MinimumBookingPeriod xsd:duration 0: 1 The minimum period prior to the departure the booking has to be placed.

BookingNote xsd:normalizedString 0: 1 Additional information about the order.

TimingPointInJourneyPattern

TimingPointInJourneyPattern < < < < PointInLinkSequence VersionedChild EntityInVersion Entity

Name Type Cardinality Desription

TimingPointRef TimingPointRef 1: 1 Reference to network#TimingPoint

WaitTime xsd:duration 0: 1 Wait time at the timing point

LinkInJourneyPattern

LinkInJourneyPattern < < < VersionedChild EntityInVersion Entity


(choice) TimingLinkInJourneyPattern network#TimingLinkInJourneyPattern 1: 1 Sorted list of TimingLinks

(choice) ServiceLinkInJourneyPattern network#ServiceLinkInJourneyPattern 1: 1 Sorted list of ServiceLinks

TimingLinkInJourneyPattern

TimingLinkInJourneyPattern < < < VersionedChild EntityInVersion Entity


TimingLinkRef TimingLinkRef 1: 1 Reference to ServiceLink

ServiceLinkInJourneyPattern

ServiceLinkInJourneyPattern < VersionedChild < EntityInVersion < Entity


ServiceLinkRef ServiceLinkRef 1: 1 Reference to ServiceLink

network#TimingPoint in a JourneyPattern.


An abstract type for a sorted list of timing- or service links in a JourneyPattern.


TimingLink in a JourneyPattern.


network#ServiceLink in a JourneyPattern.





https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-ServiceLinkInJourneyPattern

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-ServiceLink


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-ServiceLink

of 105

DestinationDisplay

DestinationDisplay < DataManagedObject


SideText MultilingualString 0: 1 The text displayed on the side of the vehicle body

FrontText MultilingualString 1: 1 The text displayed on the front of the vehicle, commonly above the front window.

vias network#Via 0: 1 An intermediary destination which the vehicle will pass before reaching its final destination.

Eg. Oslo tram line 11: "Majorstuen - Kjelsås via Torshov"

variants network#DestinationDisplayVariant 0: * Variations of DestinationDisplay adapted for particular media types

Note that for composite DestinationDisplay text, e.g. line number and destination name. Theminimum requirement is to provide a DestinationDisplay for web sites, with a destinationname.

DESTINATIONDISPLAYVARIANT

DestinationDisplayVariant < DataManagedObject


DestinationDisplayVariantMediaType DeliveryVariantTypeEnumeration 1: 1 Supported media types:

PrintedTextToSpeechWebMobileother ( )e.g. real-time display

FrontText MultilingualString 1: 1 Front page text for DestinationDisplay

VIA

Via < < < VersionedChild EntityInVersion Entity


DestinationDisplayRef DestinationDisplayRef 1: 1 Reference to the object describing the stop place/area the vehiclenetwork#DestinationDisplayis headed towards.

RoutePointRef RoutePointRef 0: 1 Reference to network#RoutePoint.

ViaType ViaTypeEnumeration 0: 1 Possible values:

stopPointname

Flexible transport

FLEXIBLELINE

The text displayed on (or in) a vehicle, commonly above the front window or onboard information screens, describing the vehicles final(or intermediary) destination.




Variations of DestinationDisplay adapted for particular media types.


An intermediary destination which the vehicle will pass before reaching its final destination.


FlexibleLine is a concept for describing on-demand transport, with at least some non-permanent stop places and/or specificrequirements for prebooking). Note: FlexibleLine be used if one or more ( and/or must FlexibleStopPlace FlexibleArea HailAndRideArea) are present in the Line.

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-Via

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-DestinationDisplayVariant

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-DestinationDisplay

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-RoutePoint

https://github.com/entur/profile-norway-examples/blob/master/netex/submodels/submodel-DestinationDisplay.xml

of 105

FlexibleLine < < network#Line DataManagedObject

Nane Type Cardinality Description

FlexibleLineType FlexibleLineTypeEnumeration 1: 1 Flexible line types:

corridorServicemainRouteWithFlexibleEndsflexibleAreasOnlyhailAndRideSectionsfixedStopAreaWidemixedFlexiblemixedFlexibleAndFixedfixed

BookingContact ContactStructure 0: 1 Contact information for booking.

BookingMethods BookingMethodListOfEnumerations 0: 1 Possible booking methods:

callDrivercallOfficeonlinephoneAtStoptext (text message/SMS)

BookingAccess BookingAccessEnumeration 0: 1 Who may place an order (book):

publicauthorisedPublicstaff

BookWhen PurchaseWhenEnumeration 0: 1 Time constraints for booking:


BuyWhen PurchaseMomentListOfEnumerations 0: 1 Time constraints for payment:


LatestBookingTime xsd:time 0: 1 Latest possible booking time.

MinimumBookingPeriod xsd:duration 0: 1 The minimum period prior to the departure the booking has to be placed.

BookingNote xsd:normalizedString 0: 1 Additional information about the order.

FLEXIBLESTOPASSIGNMENT

FlexibleStopAssignment < < < network#StopAssignment Assignment DataManagedObject


FlexibleStopPlaceRef FlexibleStopPlaceRef 1: 1 Reference to FlexibleStopPlace

Transfers

TRANSFER

Transfer < DataManagedObject




Link between and ScheduledStopPoint FlexibleStopPlace.



An abstract type describing physical opportunity to come from one place to another. Not to be confused with Interchange.




https://github.com/entur/profile-norway-examples/blob/master/netex/network/FlexibleLine-316-with-interchange.xml

of 105


Name MultilingualString 0: 1 Name of the transfer

Description MultilingualString 0: 1 Textual description

Distance xsd:decimal 1: 1 Total length for transfer (in meters)

TransferDuration network#TransferDuration 1: 1 Detailed description for duration transfer

BothWays xsd:boolean 0: 1 Specifies whether the transfer is possible in both directions

TransferDuration

TransferDuration


DefaultDuration xsd:duration 1: 1 Normal duration

FrequentTravellerDuration xsd:duration 0: 1 The time it will take a person with local knowledge to complete the transfer (commuter)

OccasionalTravellerDuration xsd:duration 0: 1 The time it will take a person unfamiliar with the place to complete the transfer (tourist etc.)

MobilityRestrictedTravellerDuration xsd:duration 0: 1 The time it will take a person with special needs to complete the transfer

timetable

Content

ContentComponents

JourneyJourneyJourneyEndpointStructure

Types of journeyVehicleJourney

JourneyPartFrequencyVehicleJourneyWaitTimeVehicleJourneyRunTimeVehicleJourneyHeadwayTimetabledPassingTime

ServiceJourneyFlexibleServiceProperties

DeadRunPeriodical journeys

TemplateVehicleJourneyTemplateServiceJourneyJourneyFrequencyGroupRhythmicalJourneyGroupHeadwayJourneyGroup

Coupled journeysCoupledJourneyJourneyPartCouple

ServiceCalendarInterchange

InterchangeServiceJourneyInterchange

This document is part of NeTEx Norwegian Profile and describes data elements used for and data exchangecalendar data planned timetablesin the NeTEx format.

Note that the timetable-part of the profile describes elements for constructing time plans or time tables (dates, times, frequencies etc.) to be usedin exchanging data between different systems, and representation of this information to travellers, based on the superordinate concept from the n

-profile document.etwork

Specification of the duration of a transfer based on the type of traveller.


VersionCurrent version for is: (last changed ) timetable v1.3 29 Aug 2018

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=728563886#network-TransferDuration

of 105

Components

Journey

JOURNEY

Journey < < LinkSequence DataManagedObject


Description MultilingualString 0: 1 Description of the departure

TransportMode AllVehicleModesOfTransportEnumeration 0: 1 Transport mode, see Mode in for possible valuesTransport Modes(with accompanying submodes).

Note that when overriding the mode for a Journey, TransportModbothe and TransportSubmode must be specified.

TransportSubmode TransportSubmode 0: 1 Transport submode

See in for possible values (Submode Transport Modes must be a)submode of specified TransportMode

Note that when overriding the mode for a Journey, TransportModbothe and TransportSubmode must be specified.

ExternalVehicleJourneyRef ExternalObjectRef 0: 1 Reference (ID) to original when specifyingtimetable#ServiceJourneyreplacement traffic.

Note that replaced ServiceJourneys (if ID is referred to by ExternalVehicleJourneyRef) must also be part of the dataset (even in cases ofpartial delivery) to ensure the validity of the reference.

Monitored xsd:boolean 0: 1 Specifies whether real-time information is available for the departure.

JOURNEYENDPOINTSTRUCTURE

JourneyEndpointStructure


Name MultilingualString 0: 1 Name

ScheduledStopPointRef ScheduledStopPointRef 0: 1 Reference to ScheduledStopPoint

DestinationDisplayRef DestinationDisplayRef 0: 1 Reference to DestinationDisplay

Types of journey

VEHICLEJOURNEY

VehicleJourney < < < timetable#Journey LinkSequence DataManagedObject


PrivateCode xsd:normalizedString 0: 1 Internal code ( ) for the journey (e.g. train- or trip number from thenon-public identifierplanners' tool)

DepartureTime xsd:time 0: 1 Time of departure for the journey.

Frequency timetable#Frequency 0: 1 Frequency or interval for departures.

Used for frequency based departures.only

JourneyDuration xsd:duration 0: 1 The total duration of the journey.

An abstract type which describes a departure/journey.


Examples in the ( ) GitHub-repository replacement transport

Description of the beginning or the destination of a VehicleJourney

A planned journey from starting point to a destination, according to a .JourneyPattern



of 105

RouteRef RouteRef 0: 1 Reference to Route (not mandatory for ServiceJourney, as this can be derived from)JourneyPatternRef

PublicCode xsd:normalizedString 0: 1 Public code or identifier for the journey

Used only when for example the line number is changed per trip or has extraordinaryoverrides.

waitTimes timetable#VehicleJourneyWaitTime 0: * Description of wait times at TimingPoints

Normally used only when describing frequency based departures.

runTimes timetable#VehicleJourneyRunTime 0: * Description of run times between TimingPoints

Normally used only when describing frequency based departures.

passingTimes timetable#TimetabledPassingTime 1: * Description of planned passing times at or StopPoints TimingPoints

parts timetable#JourneyPart 0: * List of the parts of the journey. Used in special cases such as combined journeys.

JourneyPart

JourneyPart < DataManagedObject



MainPartRef JourneyPartCoupleRef 1: 1 Reference to the main part of the journey

JourneyPartCoupleRef JourneyPartCoupleRef 0: 1 Reference to to which this journey part belongs.timetable#CoupledJourney

FromStopPointRef ScheduledStopPointRef 0: 1 The starting point for the journey part ( )ScheduledStopPoint

ToStopPointRef ScheduledStopPointRef 0: 1 The destination for the journey part ( )ScheduledStopPoint

StartTime xsd:time 1: 1 Start-time

EndTime xsd:time 1: 1 End-time

Frequency

Frequency < DataManagedObject


ScheduledHeadwayInterval xsd:duration 1: 1 Planned departure interval

MinimumHeadwayInterval xsd:duration 0: 1 Minimum departure interval

MaximumHeadwayInterval xsd:duration 0: 1 Maximum departure interval

Description MultilingualString 0: 1 Description, for example, "every 15 minutes"

VehicleJourneyWaitTime

VehicleJourneyWaitTime < < < < < timetable#JourneyWaitTime JourneyTiming VersionedChild EntityInVersion Entity


VehicleJourneyRef VehicleJourneyRef 0: 1 Reference to timetable#VehicleJourney

VehicleJourneyRunTime

A part of a journey, used for example when creating compound train journeys.


The frequency for a journey, i.e. the time interval between each departure in traffic.frequency based


Waiting time at for a TimingPoint VehicleJourney.


of 105

VehicleJourneyRunTime < < < < < timetable#JourneyRuntime JourneyTiming VersionedChild EntityInVersion Entity



VehicleJourneyHeadway

VehicleJourneyHeadway < < < < < timetable#JourneyHeadway JourneyTiming VersionedChild EntityInVersion Entity



TimetabledPassingTime

ALTERNATIVE 1: Ordinary timetable for planned journeys

TimetabledPassingTime < PassingTime < < < VersionedChild EntityInVersion Entity


attr id ObjectIdType 1: 1 Unique id for the object

Mandatory attribute

attr version VersionIdType 1: 1 Version number

Mandatory attribute

elem PointInJourneyPatternRef PointInJourneyPatternRef 1: 1 Reference to (the point being served/passed by thePointInJourneyPatternvehicle)

elem(choice)

ArrivalTime

ArrivalDayOffset

xsd:time

DayOffsetType(xsd:integer)

1: 1

0: 1

Planned arrival time (if relevant, both ArrivalTime and DepartureTime may)be specified

Number of days of arrival relative to the journey start day (only used whenjourney spans more than one calendar day)

DepartureTime

DepartureDayOffset

xsd:time

DayOffsetType(xsd:integer)

1: 1

0: 1

Planned departure time (if relevant, both ArrivalTime and DepartureTime m) be specifieday


elem WaitingTime xsd:duration 0: 1 Planned waiting time at a Point

2: On demand transport/FlexibleLines including hail and rideALTERNATIVE

TimetabledPassingTime < PassingTime < < < VersionedChild EntityInVersion Entity


attr id ObjectIdType 1: 1 Unique id for the object

Mandatory attribute

attr version VersionIdType 1: 1 Version number

Mandatory attribute

elem PointInJourneyPatternRef PointInJourneyPatternRef 1: 1 Reference to (the point being served/passed by thePointInJourneyPatternvehicle)

elem WaitingTime xsd:duration 0: 1 Planned waiting time at a Point

Run time between for a TimingPoints VehicleJourney.


Interval between two VehicleJourneys.

Used for frequency based traffic.


Planned passing time at a ( or ) for a PointInJourneyPattern ScheduledStopPoint TimingPoint VehicleJourney.




of 105

elem LatestArrivalTime xsd:time 1: 1 Latest possible arrival time

elem LatestArrivalDayOffset DayOffsetType(xsd:integer)

0: 1 Planned arrival time (if relevant, both ArrivalTime and DepartureTime bemay)specified


elem EarliestDepartureTime xsd:time 1: 1 Earliest possible arrival time

elem EarliestDepartureDayOffset DayOffsetType(xsd:integer)

0: 1 Planned departure time (if relevant, both ArrivalTime and DepartureTime may)be specified


SERVICEJOURNEY

ServiceJourney < < < < timetable#VehicleJourney timetable#Journey LinkSequence DataManagedObject


ServiceAlteration ServiceAlterationEnumeration 0: 1 Journey type:

extraJourneycancellationplannedreplaced ( )by another new ServiceJourneys

DepartureTime xsd:time 0: 1 Departure time

Frequency timetable#Frequency 0: 1 Frequency or interval for departures.


JourneyDuration xsd:duration 0: 1 Duration of the journey

dayTypes DayTypeRef 1: * References to DayTypes

JourneyPatternRef JourneyPatternRef 1: 1 References to JourneyPattern

JourneyFrequencyGroupRef JourneyFrequencyGroupRef 0: 1 References to timetable#JourneyFrequencyGroup

VehicleTypeRef VehicleTypeRef 0: 1 References to VehicleType

OperatorRef OperatorRef 0: 1 References to Operator

passingTimes timetable#TimetabledPassingTime 1: * Planned passing times

parts timetable#JourneyPart 0: * List of parts of the journey (used in special cases, such as combinedjourneys)

To make re-use of journey parts possible, these must be defined separately(as independent objects, referred to from here).

checkConstraints CheckConstraint 0: * Information about security checks, barriers etc. which may cause delays.

TrainSize TrainSize 0: 1 Information about size and structure of a train

FlexibleServiceProperties FlexibleServiceProperties 0: 1 Properties for flexible (on demand) transport.

It is possible to define properties here if they deviate from the flexibleservice properties set at the -level.Line

FlexibleServiceProperties

FlexibleServiceProperties < DataManagedObject

VehicleJourney with passengers. This is usually an ordinary departure according to the planned time table.




Description of properties for flexible transport (used from ).ServiceJourney




https://github.com/entur/profile-norway-examples/blob/master/netex/network/FlexibleLine863-with-interchange.xml

https://github.com/entur/profile-norway-examples/blob/master/netex/network/Flexx-809.xml

of 105


FlexibleServiceType FlexibleServiceTypeEnumeration 0: 1 Type of flexible transport:

dynamicPassingTimesfixedHeadwayFrequencyfixedPassingTimesnotFlexible

CancellationPossible xsd:boolean 0: 1 Specifies whether a service may be cancelled by the operator

ChangeOfTimePossible xsd:boolean 0: 1 Specifies whether times may be changed by the operator

BookingContact ContactStructure 0: 1 Contact information to book the on-demand service.

BookingMethods BookingMethodListOfEnumerations 0: 1 Possible methods for booking the on-demand service.

callDrivercallOfficeonlineotherphoneAtStoptext

BookingAccess BookingAccessEnumeration 0: 1 Access categories for who may place the order for the on-demand service.

publicauthorisedPublicstaff

BookWhen PurchaseWhenEnumeration 0: 1 A time when the booking must be completed:


BuyWhen PurchaseMomentListOfEnumerations 0: 1 A time when payment must be completed:


LatestBookingTime xsd:time 0: 1 Latest possible time for booking

MinimumBookingPeriod xsd:duration 0: 1 The minimum time ahead of journey departure the booking must becompleted

BookingNote xsd:normalizedString 0: 1 Additional information about booking

DEADRUN

DeadRun < < < < timetable#VehicleJourney timetable#Journey LinkSequence DataManagedObject


Frequency timetable#Frequency 0: 1 Frequency/interval for departures


dayTypes DayTypeRef 1: * References to DayTypes

JourneyPatternRef JourneyPatternRef 1: 1 References to JourneyPattern

Note, that for JourneyPatterns used exclusively by DeadRuns, it is permittedto define which are not linked to a (i.e. ScheduledStopPoints Place StopAssi

not defined), when these ScheduledStopPoints do not exist in the is gnmentstop place registry (e.g. vehicle garages, workshops, rest areas)

JourneyFrequencyGroupRef JourneyFrequencyGroupRef 0: 1 Reference to timetable#JourneyFrequencyGroup

VehicleTypeRef VehicleTypeRef 0: 1 Reference to VehicleType

passingTimes timetable#TimetabledPassingTime 0: * Planned passing times

OperatorRef OperatorRef 0: 1 Reference to Operator

timetable#VehicleJourney without passengers.



of 105

DeadRunType DeadRunTypeEnumeration 0: 1 Classification of DeadRun :(if relevant)

garageRunOutgarageRunIn

PERIODICAL JOURNEYS

TemplateVehicleJourney

TemplateServiceJourney < < < < < timetable#TemplateVehicleJourney timetable#ServiceJourney timetable#Journey LinkSequence DataManagedO bject


frequencyGroups (choice) RhytmicalJourneyGroup

(choice) timetable#HeadwayJourneyGroup

(choice)RhytmicalJourneyGroupRef

(choice)HeadwayJourneyGroupRef

1: * timetable#RhythmicalJourneyGroup or , or referencetimetable#HeadwayJourneyGroupto a template which applies to this pattern.

TemplateServiceJourney

TemplateServiceJourney < < < < < timetable#TemplateVehicleJourney timetable#ServiceJourney timetable#Journey LinkSequence DataManagedO bject


TemplateServiceJourney inherits from and does not introduce new elements or attributes.timetable#TemplateVehicleJourney

JourneyFrequencyGroup

JourneyFrequencyGroup < < GroupOfEntities DataManagedObject


FirstDepartureTime xsd:time 1: 1 Departure time for the first stop in the first departure in the frequency group.

LastDepartureTime xsd:time 1: 1 Departure time for the first stop in the last departure in the frequency group.

DayOffset xsd:integer 0: 1 Number of days from the starting point (when service period spans more than one calendar day)

journeys VehicleJourneyRef 0: * List of journeys in a JourneyFrequencyGroup.

Lists ServiceJourneyRef objects.only

RhythmicalJourneyGroup

Template to describe recurring , used together with (to describe frequencytimetable#ServiceJourney timetable#HeadwayJourneyGroup based departures) or with (to describe departures at the same time of day in a set period).timetable#RhythmicalJourneyGroup



Template to describe recurring , used either with (to describe frequencytimetable#ServiceJourney timetable#HeadwayJourneyGroup based departures) or with (to describe departures at the same time of day in a set period).timetable#RhythmicalJourneyGroup




Abstract type which describes recurring (for example: "departures at xx05, xx15, xx25, xx35, xx45, xx55") or frequency baseddepartures ("departures with X minutes spacing").


Description of service where departure(s) start at the same time (minutes over a whole hour) in a set period.


of 105

RhythmicalJourneyGroup < < < timetable#JourneyFrequencyGroup GroupOfEntities DataManagedObject


timebands TimebandRef 1: * Reference to a -object which describes the departure time for as minutes overTimeband timetable#ServiceJourneya full hour.

In the context of RhythmicalJourneyGroup, must have identical Timeband StartTime and EndTime and show thedeparture time as minutes over a full hour. Use "00:..." for generic time representation.

HeadwayJourneyGroup

HeadwayJourneyGroup < < < timetable#JourneyFrequencyGroup GroupOfEntities DataManagedObject


ScheduledHeadwayInterval xsd:duration 1: 1 The planned interval between departures

MinimumHeadwayInterval xsd:duration 0: 1 The minimum interval between departures

MaximumHeadwayInterval xsd:duration 0: 1 The maximum interval between departures

Description MultilingualString 0: 1 Description (for example: "every 15 minutes")

COUPLED JOURNEYS

CoupledJourney

CoupledJourney < DataManagedObject



journeys VehicleJourneyRef 0: * List of in the coupled journey.VehicleJourneys

JourneyPartCouple

JourneyPartCouple < DataManagedObject


Description MultilingualString 0: 1 Description of coupled journey

StartTime xsd:time 1: 1 Starting time for a coupled journey

EndTime xsd:time 1: 1 The end time for a coupled journey

FromStopPointRef ScheduledStopPointRef 1: 1 Planned first stop for a coupled journey ( )ScheduledStopPoint

ToStopPointRef ScheduledStopPointRef 1: 1 Planned last stop for coupled journey ( )ScheduledStopPoint




Description of service which has the same time interval between departures (frequency based departures).



A combined/coupled journey comprised of different , where the operating vehicle is a combination of two or moreVehicleJourneyssingle vehicles .(normally used for trains)linking



Two or more from different which are operating together (coupled) ( ).JourneyParts VehicleJourneys normally used for trainslinking




of 105

MainPartRef JourneyPartRef 1: 1 The main part of a coupled journey (relevant for travel information to the public)

journeyParts JourneyPartRef 0: 1 Remaining parts of a coupled journey (excl. MainPartRef)

ServiceCalendar

ServiceCalendar < DataManagedObject


Name MultilingualString 0: 1 Name of calendar

FromDate xsd:date 1: 1 Calendar start date

ToDate xsd:date 1: 1 Calendar end date

EarliestTime xsd:time 0: 1 Start time for the day can be defined in cases where it differs from the normal 00:00:00.

DayLength xsd:duration 0: 1 Length of the day can be defined in cases where it differs from the normal 24 hours.

dayTypes DayType 0: * DayTypes used in a calendar

May be defined directly in ServiceCalendarFrame

timebands Timeband 0: * Timebands used in a calendar


operatingDays OperatingDay 0: * OperatingDays used in a calendar


operatingPeriods OperatingPeriod 0: * OperatingPeriods used in a calendar


dayTypeAssignments DayTypeAssignment 0: * Linking of to DayTypes OperatingDays


Interchange

INTERCHANGE

Interchange < DataManagedObject


A logical container for a grouping of calendar related elements with identical validity criteria, and/or identical start-end dates.

Please note that unlinked calendar objects with validity criteria to the current identical should be added directlyServiceCalendarFramebelow it, rather than grouping it in a unnecessarily ServiceCalendar.


ServiceCalendarFrameDefined in

Examples in the . GitHub-repository

Interchange across datasetsPlease note that when creating (across codespaces), the agency delivering the interchanges between different datasets receiving Li

is responsible for creating, maintaining and delivering potential interchanges. This is because it normally is the connecting (waiting)netransport which defines/controls the interchange rules for each case.

This means such interchanges are only ever defined on the receiving side, in the appropriate Line-file containing the timetable#Service to which the interchange is linked (where for ToJourneyRef is defined). To re-iterate, interchangesJourneyInterchange ServiceJourney

should not be defined by the arriving transport.

An abstract type which describes planned possibilities for passengers to transfer between on the same or (usually)ServiceJourneysnearby stops, with a description of when/if a vehicle will wait for another arriving vehicle.



of 105

Priority xsd:integer 0: 1 Weighted prioritization of transfers, e.g. when there are multiple possible interchange locations along ajourney, or when there is a need to mark a location as inappropriate for interchanges:

-1 (interchanges not allowed. Corresponds to: )noInterchange0 ( , standard interchange value. Corresponds to: ) null interchangeAllowed1 (recommended interchange location to be weighted higher in the journey planner. [ accordingtimedto stated MaximumWaitTime]. Corresponds to: )recommendedInterchange2 (preferred interchange to be weighted with maximum preference by the journeyplanner. Corresponds to: )preferredInterchange

Corresponds to Weighting (InterchangeWeightingEnumeration) for StopPlace

StaySeated xsd:boolean 0: 1 Specifies that the traveller can remain seated in the vehicle, as it will be re-used for the next part of thejourney.

Useful when describing Lines that operate in a circular pattern (prevents fictitious interchanges)

Guaranteed xsd:boolean 0: 1 Specifies whether the interchange is guaranteed (the passenger is guaranteed the transfer between the two.journeys)

MaximumWaitTime xsd:duration 0: 1 Maximum time (after normal departure time) the connecting transport allows for delays.

SERVICEJOURNEYINTERCHANGE

ServiceJourneyInterchange < < timetable#Interchange DataManagedObject


FromPointRef ScheduledStopPointRef 1: 1 Reference to stop place where passenger begins transfer/interchange (arriving vehicle location)

ToPointRef ScheduledStopPointRef 1: 1 Reference to stop place where passenger continues the journey from (departing vehicle location)

FromJourneyRef VehicleJourneyRef 1: 1 Reference to the journey the passenger transfers from ( )timetable#VehicleJourney

ToJourneyRef VehicleJourneyRef 1: 1 Reference to the journey the passenger transfers to ( )timetable#VehicleJourney

fares

Specialization of for Interchange ServiceJourney.


TimetableFrameDefined in


This part of the Norwegian NeTEx profile will be published at a later date, accompanied by a separate "handbook".

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370400/stops#stops-StopPlace

https://github.com/entur/profile-norway-examples/blob/master/netex/network/FlexibleLine863-with-interchange.xml

of 26

N801 appendixCreated by Entur ([email protected]) on behalf of Jernbanedirektoratet.

Table of contents1. Norwegian SIRI profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 General information SIRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 SIRI Profile Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1 SIRI-ET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 SIRI-SX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.3 SIRI-VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

of 26

Norwegian SIRI profileGeneral information SIRISIRI Profile Documents

SIRI-ETSIRI-SXSIRI-VM

SIRI Examples CatalogueSIRI-ET - Cancelled before departureSIRI-ET - Cancelled in the middle of the route before departureSIRI-ET - Partial cancellation (first leg)SIRI-ET - Changed platformSIRI-SX - Validity of a messageSIRI SX - Message with stopCondition on a VehicleSIRI-SX - Message on a LineSIRI-SX - Message on a leg Melding på en strekning for flere kjøretøySIRI-SX - Message on a single stopSIRI-SX - Message on a stop for specific linesSIRI SX - Message on a vehicleSIRI SX - Message on multiple vehicles on multiple dates

General information SIRI

PrefaceIntroduction

Service Interface for Real Time Information (SIRI)SIRI high-level model

Services supported by the Norwegian SIRI-standardWhat the profile does not includeTerminology

SIRI-specific objects and formatsGeneral requirements on data

Using ID'sFixed ID's

Exchanging dataAsynchronous

Publish/Subscribe - Direct deliveryPublish/Subscribe - Fetched delivery

SynchronousRequest/response

General requirementsStandard valuesSpecificationData freshness

Common componentsMessage objects

ServiceDeliveryData types

NaturalLanguageStringStructureNaturalLanguagePlaceNameStructureFramedVehicleJourneyRefStructure

Preface

A Norwegian standard for exchanging uniform real-time data is extremely valuable for:

Entur AS on behalf of Jernbanedirektoratet

...in order to efficiently collect all real-time data from each data provider, ensure consistency of data, and increase data quality. This allows thecreation of multimodal information systems which may be used to implement nationwide journey planning solutions and publicize business neutralinformation to all interested parties.

for travellers

...in order to present relevant, and up-to-date, high-quality journey suggestions.

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

VersionCurrent version for is: ( )Norwegian SIRI profile v1.0 last changed 01 May 2019

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370773/SIRI+Examples+Catalogue

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370734/SIRI-ET+-+Cancelled+before+departure

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370724/SIRI-ET+-+Cancelled+in+the+middle+of+the+route+before+departure

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370798

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370726/SIRI-ET+-+Changed+platform

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370694/SIRI-SX+-+Validity+of+a+message

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370785/SIRI+SX+-+Message+with+stopCondition+on+a+Vehicle

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370744/SIRI-SX+-+Message+on+a+Line

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370746

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370748/SIRI-SX+-+Message+on+a+single+stop

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370728/SIRI-SX+-+Message+on+a+stop+for+specific+lines

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370806/SIRI+SX+-+Message+on+a+vehicle

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370814/SIRI+SX+-+Message+on+multiple+vehicles+on+multiple+dates

of 26

for third party service providers

...in order to minimize unnecessary costs related to supporting multiple different exchange formats, and to contribute to continued growth ofstandardized public transport data exchange.

Introduction

Service Interface for Real Time Information (SIRI)

Service Interface for Real Time Information (SIRI) is a CEN-specification ( ) forCEN/TS 15531, prCEN/TS-OO278181exchanging real-time data for public transport and vehicles. Its development was a cooperative effort between France, Germany (VerbandDeutscher Verkehrsunternehmen, VDV), Scandinavia and Great Britain ( ). The standard is based onUK Real Time Interest Group, RTIGthe reference model ( ) and contains a general model for real-time data and an XML Schema for itsTransmodel CEN TC278, EN12896implementation.

The SIRI format is used to update planned data with short term changes and deviations in the form of vehicle positions, estimated arrival times,and relevant textual messages.

The guidelines for using SIRI 2.0 XML Schema are specified by a local (Norwegian) profile of the SIRI format, which accounts for existingsystems, as well as future needs. Just like the , which defines the planned and fixed portion of public transport data, theNorwegian NeTEx ProfileNorwegian SIRI profile describes how- and which parts of the wider format to use. It is based on whichTransmodel 5.1 (EN 12896: 2006)in turn is based on the standards of and IFOPT (EN 28701 - Identification of FixedNEPTUNE (AFNOR - PR NF P99-506 desember 2009)Objects in Public Transport). The purpose of the profile is to clarify which events and data are expected to be included in a comprehensive dataexchange and to make the implementation of common standards easier.

SIRI defines a standardised communication layer with procedures and mechanisms for exchanging data by means of a format which is openlydescribed to the public and in wide use around the world.

Well known interfaceOpennessScalabilityFlexible for particular needs

Re-useability for architecture, infrastructure and services (cost-saving)Content independent from transfer protocolsStandardised publication and message handling

WebService (HTTP/SOAP with request/response) and WS-PubSubSupports common mechanisms for access control, versioning and error handling

Configurable updating and filtering

SIRI high-level model

Overview of the functional services from the official SIRI-documentation:

Links for more information about the formatsSIRI: https://www.vdv.de/siri.aspxTransmodel: http://transmodel-cen.euNeTEx: http://netex-cen.eu/

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891481/Norwegian+NeTEx+Profile

https://www.vdv.de/siri.aspx

http://transmodel-cen.eu/

http://netex-cen.eu/

of 26

1. a.

2. a. b.

3. a.

Services supported by the Norwegian SIRI-standard

Real-time information in Norway is exchanged in three formats, , and :SIRI-ET SIRI-SX SIRI-VM

Estimated Timetable (ET) for continuous updates per line, restricted to the current operational day (may differ from calendar days).Changes like delays, cancellations, additional departures, over-takes, or stops that are not going to be served.

Situation Exchange (SX) for information on disruptions in the public transport serviceInformation about planned deviations (such as maintenance work on the tracks)Information about unplanned deviations (such as accidents, unforeseen issues with passengers, objects blocking the road, orsevere weather)

Vehicle Monitoring (VM) for tracking the position of the vehicles used for public transportThe actual position of vehicles as they traverse a route (GPS data).

1. 2.

3. a.

4. 5.

a. b.

6. 7.

a.

SIRI also supports real-time information data types which are included in the Norwegian profile:not

Production Timetable (PT) for changes in planned time table data outside the current operational day.Stop Timetable (ST) changes (theoretic, planned, or calculated) in arrivals and departures for stops outside the currentoperational day.Stop Monitoring (SM) arrival- and transfer times for the same operational day.

Calculated arrival time for a vehicle, usually based on GPS data.Connection Timetable (CT) used to inform about guaranteed interchanges outside the current operational day.Connection Monitoring (CM) for continuous updates on guaranteed interchanges.

Whether the guarantee will be upheld.Unplanned interchanges (for example, a bus will wait for a train).

General Messaging (GM) for general text-based information, such as, for example, describing a widely impactful disruption.Facility Monitoring (FM) for updating the status of equipment, or services.

Elevators, escalators, ticket vending machines.

of 26

1. a. b. c. d.

2. a. b. c. d. e. f.

3. a. b.

4.

What does Norwegian SIRI profile includeBased on relevant use cases as well as experience from existing real-time systems, the following features have been included:

Identification of reference data:Lines, Routes, and VehicleJourneys with arrival- and departure informationStopPlaces, including type and QuaysConnections and TransfersData values

ServiceCategoryProductCategoryVehicleFeatures

Specify technical data exchangesType of data stream/subscriptionCategorisation of messages and dataMessage receipts (when relevant)Filtering mechanismsConsolidation and forwarding of partner-data (including monitoring)Meaning of functions

Usage of data fieldsMeaningsWhether the field is mandatory or not

The ability to describe possible expansions outside the bounds of the main SIRI profile.

What the profile does includenot

Technical specifications, local protocols, and their referential implementations are included in the Norwegian SIRI profile. The same is true fornotaccess privileges, the technical details for data transfers, and the administration of data sources and users.

Details regarding the methods of data transfer are however described in separate protocols, established and agreed upon between Entur, datasources and data users. This includes:

User guidesList of available servicesAccess privilegesMonitoring (uptime, technical disturbances, maintenance)

A complete list of available data streams can be found at .https://developer.entur.org/content/real-time-information

Terminology

Terms and concepts for real-time data in SIRI are, just as in the case of stops- and timetable data, defined according to the NeTEx formatstandard, based on the European reference model "Transmodel".

Exchanging data in a single format means all communication systems involved need to have a unified interpretation of the terms and conceptsbeing used.

With Transmodel as the source for conceptual names, all objects will have English names, and any use of Norwegian terminology should beconsidered as guiding only since local concepts often have widely varying historical meanings and associations. For that reason, in particular, allusers of the format should strive to use the unified terminology to the furthest extent possible.

It is likewise important to point out that all ID's for stop places (StopPlace, Quay, etc.) in the SIRI data must refer to the official stop ID's found inthe national stop place registry. This is important for both data sources- as well as users.

SIRI-specific objects and formats

Definitions of Transmodel-related objects can be found in the . The following complementary table defines and clarifiesNorwegian NeTEx profileSIRI-specific terms.

Please note that the list is not exhaustive, and the list may be expanded on when needs arise.

Data Description of data type

Encoding Primarily UTF-8, but ISO-8859-1 and ASCII can also be handled.

Date/Time Dates and times must be in local time, according to , where "00:00" is midnight.ISO 8601

Please note that the minimum granularity of times is in seconds, but even more precise timestamps can be used.

Language The language used must be defined as a according to .two-letter code RFC 1766 / ISO 639-1

For a more detailed description of Transmodel-specific terms, see the .Norwegian NeTEx profile

https://developer.entur.org/content/real-time-information



of 26

1. 2. 3.

Location Locations must always be defined according to (normally )WGS84/GML EPSG:4326

Coordinates in other formats must be converted to WGS84 before being published in SIRI.

StopPoint In accordance with Transmodel, objects refer to a logical stop point, normally where passengers can board and alight. Forpractical reasons these points always have to be references to valid stops in the national stop place registry.

Destination Usually, the final, or an important intermediary stop place in the route.

Origin Usually, the first stop place in the route.

General requirements on data

For real-time data delivered in XML, the structure and content must be in accordance with SIRI 2.0 XML Schema (XSD), where all data fieldscontain meaningful information and are correctly formatted.

Values must be trimmed (no blanks first or last in data values)Characters must be valid and in accordance with the .encoding

Using ID's

Requirements on unique ID's are described with more detail in the . It is important that all ID's in the SIRI- and NeTExNorwegian NeTEx profiledatasets are constants (real-time, stops, timetables), in order to prevent mismatches and other irregularities.

References to must always use ID's from the national stop place registry.stopsThe data source is responsible for ensuring that ID's are correctly linked between timetable- and real-time data.

Fixed ID's

Just as in the case of timetable data, it is strongly recommended that unchanged objects keep their ID's unchanged across datasets. This makeslong term referencing, and tracking of changes easier.

Exchanging data

Communication of data must be implemented in accordance with the principles of REST-based services via HTTP.

In technical terms, the exchange of data must be identical for all types (SIRI-ET, SIRI-SX and SIRI-VM.

Three forms of data acquisition are allowed:

Publish/Subscribe - Direct delivery (asynchronous)Publish/Subscribe - Fetched delivery (asynchronous)Request/response (synchronous)

Asynchronous

The service has been designed to continuously deliver data updates to all subscribed consumers.

When establishing a subscription, the data stream must be validated or reported as erroneous through the protocols of the mechanism.

All services of the publish/subscribe type in accordance with the subscription-request ( ), to ensuremust send heartbeats HeartbeatIntervalverification of service availability and operational status.

Publish/Subscribe - Direct delivery

When using the data is continuously streamed to all subscribers immediately after they are released into the stream. The recipientDirect Deliverysystem is responsible for handling the received messages. A received message is acknowledged with a HTTP 200 "OK" success-response.


https://en.wikipedia.org/wiki/Heartbeat_(computing)

of 26

Publish/Subscribe - Fetched delivery

When using data is only sent when the receiving system has verified that it is ready to receive data from the stream. TheFetched Deliverymessage has to remain available with the data source until an explicit has been received, and the system has ensured datadataSupplyRequest delivery in accordance with it. This delivery method allows the receiving system to hold off on data fetches until it is ready to do so. It is theresponsibility of the data source to ensure that data is kept until the consumer has fully downloaded it.

Synchronous

Explicit fetching of datasets based on service type, time, and possibly more parameters. When disruptions or other errors occur, the fetch attemptshould result in predefined error messages.

Request/response

of 26

The service will be designed to deliver data per request, in accordance with the requestors filtering criteria (included in the fetch request).

General requirements

It is expected that normal data deliveries will contain updates/changes since the most recent push/request. If new messages also containpreviously delivered messages, mechanisms must be implemented in the exchange protocol to prevent duplication or other corrupting issues.

Standard values

All fields used when setting up a data stream, or when calling the services are expected to have meaningful values, defaults and accordance withrequest-parameters. For example in the cases of:

The time range of the fetched dataFilteringChange-before-update

Specification

When filtering the data it is expected to reduce the data stream content in accordance with the set input-parameters. Likewise, it is expected thatwhen no input-parameters are present, a full dataset is requested.

Data freshness

It is expected that new messages are published at the soonest possible moment after the source data has been changed. For example:

Changes in stops (EstimatedCall RecordedCall)Quay to be used has been determined or changedAdjustments in estimated arrivals or departures

Common components

This chapter describes the generic concept used for exchanging real-time information in accordance with the Norwegian SIRI profile.

Message objects

ServiceDelivery

ServiceDelivery


element ResponseTimestamp xsd:dateTime 1: 1 Time when the dataset was generated/published.

element ProducerRef xsd:NMTOKEN 1: 1 Codespace for dataset producer.

Container for SIRI Functional Service delivery

Norwegian SIRI profile supports:

EstimatedTimetableDelivery ( )SIRI-ETSituationExchangeDelivery ( )SIRI-SXVehicleMonitoringDelivery ( )SIRI-VM

of 26

(choice)element

EstimatedTimetableDelivery EstimatedTimetableDeliveryStructure 1: 1 Data element for Estimated Timetable (SIRI-ET), withchanges in one or more planned within VehicleJourneysthe same operating day.

SituationExchangeDelivery SituationExchangeDeliveryStructure Data element for Situation Exchange (SIRI-SX), withinformation regarding one or more situations (or updates topreviously published situations).

VehicleMonitoringDelivery VehicleMonitoringDeliveryStructure Data element for Vehicle Monitoring (SIRI-VM), withmonitoring information for one or more VehicleJourneys (forestimated adjustments of time table information)

Data types

NaturalLanguageStringStructure

NaturalLanguageStringStructure


attribute xml:lang xsd:string 0: 1 The language used must be defined as a according to .two-letter code RFC 1766 / ISO 639-1

Interpreted as the default "NO" unless otherwise specified. This be specified when themustmessage language is other than the default.

element (elementcontent)

xsd:string (non-)empty

1: 1 The message text.

NaturalLanguagePlaceNameStructure

NaturalLanguagePlaceNameStructure


attribute xml:lang xsd:string 0: 1 The language used must be defined as a according to .two-letter code RFC 1766 / ISO 639-1

Interpreted as the default "NO" unless otherwise specified. This be specified when themustmessage language is other than the default.

element (elementcontent)

xsd:string (non-)empty

1: 1 The message text

FramedVehicleJourneyRefStructure

FramedVehicleJourneyRefStructure


element DataFrameRef xsd:NMTOKEN 1: 1 Date must have the ISO-format (YYY-MM-DD) for the departure in question. Must be inlocal time.

element DatedVehicleJourneyRef xsd:NMTOKEN 1: 1 ID for the related (must be the same as the ID of the corresponding VehicleJourney Vehi in the NeTEx dataset).cleJourney

SIRI Profile Documents

Documents

SIRI-ETSIRI-SXSIRI-VM

Changelog

Text strings with an assigned language code.

Text strings with an assigned language code.

Reference objects for with a specified (date), in order to ensure that objectsDatedVehicleJourneyRef DatedFrameRef VehicleJourneywith the same ID can be separated based on their dates.

of 26

Date of change Profile document Description of change Version

01 May 2019 SIRI-ETSIRI-SXSIRI-VM

The profile is now official and version is changed 1.0 without any changes to the content. v. 1.0

22 Aug 2018 SIRI-ETSIRI-SXSIRI-VM

Corrections and clarifications of data structure and message contents. v. 0.9.2v. 0.9.2v. 0.9.2

02 Mar 2018 General information SIRI,,SIRI-ET,SIRI-SX

SIRI-VM

Initial publication of Norwegian SIRI profile. v. 0.9

SIRI-ET

The Service Interface for Real Time Information - Estimated Timetable

Content

ContentData requirementsComponents

EstimatedTimetableDeliveryEstimatedTimetableDeliveryEstimatedJourneyVersionFrameEstimatedVehicleJourneySimpleContactStructureSituationRefStructureRecordedCallRecordedCallStructureEstimatedCallEstimatedCallStructureStopAssignmentStructure

This document is part of the Norwegian SIRI Profile and describes datasets and elements used for exchanging continuous changes to plannedin the real-time formatdata within the same calendar day SIRI Estimated Timetable (ET) .

SIRI-ET is used to model the status of existing VehicleJourneys and to ensure that deviations from the planned data (within the same operationalday) such as cancellations, additional departures, delays, detours and changes in stops, can be published on short notice. The data is linked toobjects in the planned data by use of ID's, which ensures data quality.

Data requirements

Sending a of SIRI-ET data must be in accordance with this profile and the ServiceDelivery entire dataset should be contained within a single.XML file

Note that the profile does not present an exhaustive list of all real-time information technically possible to transfer via SIRI-ET, but it lays thefoundation for which demands are placed on the datasets in order to meet the demands set by Håndbok N801.

It is permitted for client systems to send more than one , in order for real-timeperEstimatedVehicleJourney EstimatedTimetableDeliveryinformation to be conflated and be transferred as part of the same . ServiceDelivery

The associated with this profile are meant to show practical implementations of specific use cases, and can contain supplementary,exampleslack certain data fields, or contain optional data, compared to a full and complete dataset. See for closer descriptions ofSIRI-VM#Komponenterthe data types, specifications and requirements on the unique elements of the SIRI VM-data.

Components

EstimatedTimetableDelivery

VersionCurrent version for is: (SIRI-ET v1.0 last changed )01 May 2019

When sending data, information should , that is when Estimated Timetable always contain all stops all served EstimatedCallsrelevant (and = 'true')RecordedCalls IsCompleteStopSequence

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370406/H+ndbok+N801


of 26

ESTIMATEDTIMETABLEDELIVERY

EstimatedTimetableDelivery < ServiceDelivery


attribute version xsd:NMTOKEN 1: 1 Version ID for EstimatedTimetableDelivery.

element ResponseTimestamp xsd:dateTime 1: 1 Timestamp for when the dataset wascreated/published.

element EstimatedJourneyVersionFrame SIRI-ET#EstimatedJourneyVersionFrame 1: * A container element for sending one or more Estimate with a timestamp.d Timetable

ESTIMATEDJOURNEYVERSIONFRAME

EstimatedJourneyVersionFrame


element RecordedAtTime xsd:dateTime 1: 1 The time when the data object was created/published.

element EstimatedVehicleJourney SIRI-ET#EstimatedVehicleJourney 1: * Object for dataset.Estimated Timetable

ESTIMATEDVEHICLEJOURNEY

EstimatedVehicleJourney


element LineRef xsd:NMTOKEN 1: 1 Reference to the Line in question (ID to the correspondingobject in the timetable data)

element DirectionRef xsd:NMTOKEN 1: 1 Direction reference.

Please note that the field is implemented as mandatory, but isnot used as a free standing data type in the Norwegian SIRIprofile. If it is not used, this value can be set to 0 (zero).

(choice)element

FramedVehicleJourneyRef FramedVehicleJourneyRefStructure 1: 1 Reference with date to VehicleJourney in question (ID to thecorresponding object in the timetable data).

EstimatedVehicleJourneyCode xsd:NMTOKEN Un-affected replacement departures must be given a newcodespace-unique ID.

For example: RUT:VehicleJourney:51-108833-11872056-00

(choice)element

ExtraJourney xsd:boolean 0: 1 The VehicleJourney in question is a replacement departure.

Must be 'true' if it is a replacement departure.

Cancellation xsd:boolean Used when the VehicleJourney in question is cancelled.

Set to 'true' only if the whole VehicleJourney is cancelled.When only parts of the VehicleJourney is cancelled: use RecordedCall and/or EstimatedCall.

element JourneyPatternRef xsd:NMTOKEN 0: 1 Reference to JourneyPattern in question (ID to thecorresponding object in the timetable data).

A data type for representing information about time table changes for one or more VehicleJourneys within the same operational day.

Container-element for returning an comprised of one or more Estimated Timetable EstimatedVehicleJourney.

Continuously updated timetable data with changes in the current operating day for a VehicleJourney (may also include a reference to aVehicle), and its estimated arrival times at stops.

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-EstimatedJourneyVersionFrame

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-EstimatedVehicleJourney

of 26

element

VehicleMode VehicleModesEnumeration 0: 1 Transport type.

Must be defined for replacement departures!

Possible values:

airbuscoachferry ( )mapped to "water"metrorailtram

element RouteRef xsd:NMTOKEN 0: 1 Reference to Route in question (ID to the correspondingobject in the timetable data).


element GroupOfLinesRef xsd:NMTOKEN 0: 1 Reference to Network/GroupOfLines in question (ID to thecorresponding object in the timetable data).


element ExternalLineRef xsd:NMTOKEN 0: 1 Reference to Line in question (ID to the corresponding objectin the timetable data).


element OriginName NaturalLanguageStringStructure 0: 1 Name of the first stop of the departure (not used due to thereference to the national stop place registry, however becanincluded to make the XML easier to read).

element DestinationName NaturalLanguageStringStructure 0: 1 Name of the last stop of the departure (not used due to thereference to the national stop place registry, however becanincluded to make the XML easier to read).

element OperatorRef xsd:NMTOKEN 0: 1 Reference to Operator in question (ID to the correspondingcompany in the timetable data)

Must be defined for replacement departures where theoperator has been changed!

element PublicContact SIRI-ET#SimpleContactStructure 0: 1 Contact point for the public (if different from original timetableinformation).

At least one field must be filled out.

element OperationsContact SIRI-ET#SimpleContactStructure 0: 1 Administrative contact details (if different from originaltimetable information).

At least one field must be filled out.

element SituationRef SIRI-ET#SituationRefStructure 0: * Unique reference to one or more which linkSituationNumberto earlier published Situation elements (SIRI-SX) linked to thesame EstimatedVehicleJourney.

element PredictionInaccurate xsd:boolean 0: 1 Whether the VehicleJourney is affected by traffic jams orother circumstances which lead to uncertainty around thetime estimates.

element DataSource xsd:string 1: 1 Codespace of the data source (see codespace).

element Occupancy OccupancyEnumeration 0: 1 Open seats-status.

Possible values:

fullseatsAvailablestandingAvailable

element BlockRef xsd:NMTOKEN 0: 1 Reference to block ( )trip pattern

Internal (non-public) information.

element VehicleJourneyRef xsd:NMTOKEN 0: 1 Reference to the VehicleJourney being replaced (ID to thecorresponding object in the timetable data).

Please note: use only for unplanned replacement departures.In other cases, use FramedVehicleJourneyRef.

element AdditionalVehicleJourneyRef xsd:NMTOKEN 0: * Reference to other affected VehicleJourneys.

element Monitored xsd:boolean 0: 1 Whether the vehicle is currently reporting real-time data or not(for example set to when the driver of the vehicle logs ontrueto the system before departing).

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-SimpleContactStructure

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-SimpleContactStructure

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-SituationRefStructure

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370434/List+of+current+Codespaces

of 26

element RecordedCalls SIRI-ET#RecordedCall 0: 1 The full sequence of already served stops in the order theywere served by the VehicleJourney.

Please note that all stops in the sequence must be inchronological order.

element EstimatedCalls SIRI-ET#EstimatedCall 0: 1 The full sequence of affected stops in the order they swill beerved by the VehicleJourney.

Please note that all stops in the sequence must be inchronological order.

element IsCompleteStopSequence xsd:boolean 1: 1 Should always be 'true' as a confirmation that the sequenceof RecordedCalls/EstimatedCalls is complete for theVehicleJourney in question (that is, containing all the stops).

SIMPLECONTACTSTRUCTURE

SimpleContactStructure


element PhoneNumber xsd:string 0: 1 Phone number

element Url xsd:anyURI 0: 1 Url

SITUATIONREFSTRUCTURE

SituationRefStructure


element SituationSimpleRef xsd:string 1: 1 Unique referance to for previously published ( )SituationNumber Situation Element SIRI-SX

RECORDEDCALL

RecordedCall


element RecordedCall SIRI-ET#RecordedCallStructure 1: 1 Description

RECORDEDCALLSTRUCTURE

RecordedCall


element StopPointRef xsd:NMTOKEN 1: 1 Reference to actually served Quay. (ID to the correspondingQuay in the timetable data and national stop place registry).

element Order xsd:positiveInteger 1: 1 Which number in the sequence of served stops this RecordedCa is describing.ll

Please not that the sequence must contain described stopsall(Call), that is Order must be a continuous sequence fromregistered RecordedCall to upcoming EstimatedCall.

element StopPointName NaturalLanguageStringStructure 0: * Name (one per language).

(choice)element

ExtraCall xsd:boolean 0: 1 Whether the served stop is in addition to the planned stopsequence.

Contact details to be presented to the public in cases where the information stated in the planned time table data is no longer true.

Reference to a related in an existing message.Situation Element SIRI-SX

Wrapper object to describe information regarding already served stops in a VehicleJourney.

Specified RecordedCalls must, together with EstimadeCalls, define stops of a complete all EstimatedVehicleJourney (that is,IsCompleteStopSequence should always be 'true').

Data structure with information regarding already served stops.

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-RecordedCall

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-EstimatedCall

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-RecordedCallStructure

of 26

Cancellation Whether this is a cancellation of a planned stop.

Only used when the stop was not served, either for boarding oralighting.


Possible values:


element AimedArrivalTime xsd:dateTime 0: 1 Originally planned arrival time. Required, except for the firststop.

element ActualArrivalTime xsd:dateTime 0: 1 Actual arrival time. Required, except for the first stop.

element AimedDepartureTime xsd:dateTime 0: 1 Originally planned departure time. Required, except for the laststop.

element ActualDepartureTime xsd:dateTime 0: 1 Actual departure time. Required, except for the last stop.

ESTIMATEDCALL

EstimatedCall


element EstimatedCall SIRI-ET#EstimatedCallStructure 1: 1 Description

ESTIMATEDCALLSTRUCTURE

EstimatedCall


element StopPointRef xsd:NMTOKEN 1: 1 Reference to the in question (ID corresponding toStopPlace objects in the national stop place registry).

element Order xsd:positiveInteger 1: 1 Which number in the sequence of served stops this Estimatedis describing.Call

element StopPointName NaturalLanguageStringStructure 0: * Name (one per language).

(choice)element

ExtraCall xsd:boolean 0: 1 Whether the served stop is in addition to the planned stopsequence.

Cancellation Whether this is a cancellation of a planned stop.

Only used when the stop was not served, either for boarding oralighting.

When partially cancelled departures the last stop before thecancellation part is defined with DepartureStatus 'cancelled',while the first stop in the cancellation part is defined with ArrivalStatus 'cancelled'. The remaining non-served stops (the partialcancellation) are defined with Cancellation 'true'.

element PredictionInaccurate xsd:boolean 0: 1 Whether the VehicleJourney is affected by traffic jams or othercircumstances which lead to uncertainty around the timeestimates . When the whole VehicleJourney isfor this calluncertain, this should instead be set onEstimatedVehicleJourney.

element RequestStop xsd:boolean 0: 1 Whether the passenger must signal the vehicle for the stop tobe served.

Wrapper object for describing a stop which will be served in a VehicleJourney.

Specified EstimatedCalls must, together with , define stops of a complete RecordedCalls all EstimatedVehicleJourney (that is,IsCompleteStopSequence should always be 'true').

Data structure information about stops which will be served, in chronological sequence.

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-EstimatedCallStructure

of 26

element DestinationDisplay NaturalLanguageStringStructure 0: * The (destination) text displayed on the vehicle when arriving ata stop.

If this is defined the original text of the departure will benotused.

Please note that the text field be defined in cases ofmustExtraJourney or when overriding a destination text from theplanned timetable data.

element SituationRef SIRI-ET#SituationRefStructure 0: * One or more linking to already publishedSituationNumberSIRI-SX messages for the Call in question.

element AimedArrivalTime xsd:dateTime 0: 1 Originally planned arrival time. Required, except for the firststop.

element ExpectedArrivalTime xsd:dateTime 0: 1 Estimated arrival time. Required, except for the first stop.

Should be updated to the actual arrival time when the vehiclearrives at a stop.

element ArrivalStatus CallStatusEnumeration 0: 1 Status for arrival

Possible values:

arrivedcancelled earlyonTimedelayed

element ArrivalBoardingActivity ArrivalBoardingActivityEnumeration 0: 1 Used when there are changes in the boarding restrictions (mustbe in accordance with ArrivalStatus).

Possible values:

alightingnoAlightingpassThru

element ArrivalStopAssignment SIRI-ET#StopAssignmentStructure 0: 1 Assigned arrival place (Quay).

When necessary the either ArrivalStopAssignment DeparturoreStopAssignment, are defined, but never both

element AimedDepartureTime xsd:dateTime 0: 1 Originally planned departure time. Required, except for the laststop.

element ExpectedDepartureTime xsd:dateTime 0: 1 Estimated departure time. Required, except for the last stop.

element DepartureStatus CallStatusEnumeration 0: 1 Status for departure.

Possible values:

cancelledonTimedelayed

element DepartureBoardingActivity DepartureBoardingActivityEnumeration 0: 1 Used when there are changes in the boarding restrictions(assuming this is not the final stop. Must be in accordancewith ArrivalStatus).

Possible values:

boardingnoBoardingpassThru

element DepartureStopAssignment SIRI-ET#StopAssignmentStructure 0: 1 Assigned departure place (Quay).

When necessary the either ArrivalStopAssignment DeparturoreStopAssignment, is defined, but never both

STOPASSIGNMENTSTRUCTURE

StopAssignmentStructure


element AimedQuayRef xsd:NMTOKEN 1: 1 Reference to originally planned Quay (ID corresponding to objects in the national stop placeregistry).

element ExpectedQuayRef xsd:NMTOKEN 0: 1 Reference to expected/current Quay (ID corresponding to objects in the national stop placeregistry), when there are changes.

Assignment of stop place (Quay).

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-SituationRefStructure

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-StopAssignmentStructure

https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370392#SIRI-ET-StopAssignmentStructure

of 26

SIRI-SX

The Service Interface for Real Time Information - Situation Exchange

Contents

ContentsData requirementsComponents

SituationExchangeDeliverySituationExchangeDeliveryPtSituationElementSituationSourceHalfOpenTimestampRangeStructureInfoLinksInfoLinkAffectsAffectedNetworkAffectedOperatorStructureAffectedLineStructureAffectedRouteAffectedRouteStructureAffectedStopPointAffectedStopPlaceAccessibilityAssessmentAccessibilityLimitationAffectedComponentAffectedVehicleJourney

This document is part of the Norwegian SIRI Profile and describes datasets and elements used for exchanging textual traffic situationin the real-time formatmessages SIRI Situation Exchange (SX) .

SIRI-SX is used to model textual descriptions of disruptions, or deviations from the planned public transport information. The messages can beapplied directly to stops, lines, vehicles etc. in the already existing public transport data by the use of ID references.

Data requirements

Sending of a SIRI-SX data must be in accordance with this profile and the ServiceDelivery, entire dataset should be contained within a single.XML file

Note that the profile does not present an exhaustive list of all real-time information technically possible to transfer via SIRI-SX, but it lays thefoundation for which demands are placed on the datasets in order to meet the demands set by Håndbok N801.

It is permitted for client systems to send more than one per , in order for real-timeSituations (PtSituationElement) SituationExchangeDeliveryinformation to be conflated and be transferred as part of the same . ServiceDelivery

The associated with this profile are meant to show practical implementations of specific use cases, and may contain supplementary examples opt data fields, or lack data fields, compared to a full and complete dataset. See for closer descriptions of theonal mandatory SIRI-SX#Komponenter

data types, specifications and requirements on the unique elements of the SIRI SX-data.

Components

SituationExchangeDelivery

SITUATIONEXCHANGEDELIVERY

SituationExchangeDelivery < ServiceDelivery


attribute version xsd:NMTOKEN 1: 1 Version ID for SitutaionExhangeDelivery

element ResponseTimestamp xsd:dateTime 1: 1 Timestamp for when the dataset was created/published.

element Situations SIRI-SX#PtSituationElement 1: * Data object for a Public Transport Situation Exchange.

VersionCurrent version for SIRI-SX is: v1.0 (last changed )01 May 2019

A data type for the representation of one or more situations, or updates on previously published situations through Situations per with the status and scope of the affected services.(PtSituationElement) SituationExchangeDelivery



of 26

PTSITUATIONELEMENT

PtSituationElement


element CreationTime xsd:dateTime 1: 1 Timestamp for when the situation was created.

element ParticipantRef ParticipantCode 1: 1 Codespace of the data source (see codespace).

element SituationNumber xsd:anyURI 1: 1 Unique situation-ID for PtSituationElement.

Format:CODESPACE:SituationNumber:ID

ABC:SituationNumber:123e.g.:

element Source SIRI-SX#SituationSource 1: 1 Information on the source of the message.

element Progress WorkflowStatusEnumeration 1: 1 Status of a situation message.

Possible values:

openclosed (the situation is over and traffic has returned to

)normal

Please note that when Progress is set to 'closed' the message isconsidered expired and should not be presented to the public.

element VersionedAtTime xsd:dateTime 0: 1 Timestamp when the situation element was updated.

element ValidityPeriod SIRI-SX#HalfOpenTimestampRangeStructure 1: * Validity period(s) set with a start time and optionally with an endtime. When the end time of the situation is undefined theexpiration of the situation is considered unknown untilcancellation status for the situation is sent. If the situation hasseveral periods, all but the last period must have an end date.

Note that for closed ( ) messages, theProgress=closedValidityPeriod have an EndTime with a minimum of must five

into the future to ensure the message is properlyhoursdelivered and received by all systems.

Once EndTime has expired, the message will no longer bere-distributed in real-time data streams or services.

element UndefinedReason Reason 1: 1 Reason should always be .<UndefinedReason/>

The field is mandatory due to format spesification, but is notused.

element Severity SeverityEnumeration 0: 1 How severely the situation affects public transport services.

Possible values:

noImpactslightnormal ( )defaultsevere

element Priority xsd:nonNegativeInteger 0: 1 Number value indicating the priority of the situation message.

The highest number gives the highest priority.

element ReportType ReportTypeEnumeration 1: 1 Type of situation report. The field is required in order todifferentiate general information from incidents.

Possible values:

general (used for public information not impacting the actualoperation of the PT-service. eg. "No food service on thisjourney")incident (used for public information impacting the operationof the PT-service. eg. "expect delays due to roadconstruction work")

element Planned xsd:boolean 0: 1 Whether the situation in question is due to planned events, or anunexpected incident.

element Summary NaturalLanguageStringStructure 1: * The textual summary of the situation (which is not alreadydescribed by structured data). One summary per language (ifmore than one, the attribute be set).xml:lang must

Maximum 160 characters (to keep the message readable).

A container element for situation data.


https://enturas.atlassian.net/wiki/pages/resumedraft.action?draftId=637370605#SIRI-SX-HalfOpenTimestampRangeStructure

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370393/Generell+informasjon+NeTEx#GenerellinformasjonSIRI-NaturalLanguageStringStructure

of 26

element Description NaturalLanguageStringStructure 0: * Expanded textual description (if more than one, the attrixml:langbute be set) of the situation (do not repeat information frommustSummary, or structured data).

Please do not add advice on how to avoid the situation, as thisshould be presented in the Advice field.

element Advice NaturalLanguageStringStructure 0: * Textual advice (if more than one, the attribute bexml:lang mustset) on how a passenger should react/respond to the situation.

element InfoLinks SIRI-SX#InfoLinks 0: 1 Link to a website which has further information on the situation.

element Affects SIRI-SX#Affects 1: 1 A description of what the situation affects.

Can be blank when message progress is changed to .'closed'

SITUATIONSOURCE

SituationSource


element SourceType SourceType 1: 1 Information type

Possible values:

directReport

Required by the format spesification, but not used.

HALFOPENTIMESTAMPRANGESTRUCTURE

HalfOpenTimestampRangeStructure


element StartTime xsd:dateTime 1: 1 Start time for the period.

element EndTime xsd:dateTime 0: 1 End time for the period.

INFOLINKS

InfoLinks


element InfoLink SIRI-SX#InfoLink 1: 1 Link to a website which has further information on the situation.

INFOLINK

InfoLink


element Uri xsd:anyUri 1: 1 Link to a website which has further information on the situation.

element Label NaturalLanguageStringStructure 0: 1 Label for the link.

AFFECTS

Information on the source of the message.

Period can be open- or closed-ended,

Collection of information links

Link to a website which has further information on the situation.

Data objects for closer description of required element affected by the situation.



of 26

Affects


(choice) element Networks SIRI-SX#AffectedNetwork 0: * Network with operators and lines affected by thesituation.

StopPlaces SIRI-SX#AffectedStopPlace Stops affected by the situation.

StopPoints SIRI-SX#AffectedStopPoint Stops affected by the situation, with the possibility ofspecifying criteria of situation relevance.

VehicleJourneys SIRI-SX#AffectedVehicleJourney Trips affected by the situation.

AFFECTEDNETWORK

AffectedNetwork


element AffectedOperator SIRI-SX#AffectedOperatorStructure 0: 1 Reference to affected operator.

element NetworkRef xsd:NMTOKEN 1: 1 Reference to affected Network.

element VehicleMode VehicleModesOfTransportEnumeration 0: 1 Affected modality.

Possible values:

allairbuscoachfunicular (please note: does not have a corresponding submod

)emetrorailtaxi (please note: does not have a corresponding )submodetelecabin ( ) (please note: does not havemapped to til cablewaya corresponding )submodetramwaterselfDrive

Modes must be specified together with corresponding submode(when applicable), whenever the situation does not affect allmodalities in the affected planned data.

(choice)element

AirSubmode AirSubmodesOfTransportEnumeration 0: 1 Possible values:

domesticFlighthelicopterServiceinternationalFlight

BusSubmode BusSubmodesOfTransportEnumeration Possible values:

airportLinkBusexpressBuslocalBusService (mapped to )localBusnightBusrailReplacementBusregionalBusschoolBusshuttleBussightseeingBus

Coach CoachSubmodesOfTransportEnumeration Possible values:

internationalCoachService (mapped to )internationalCoachnationalCoachService (mapped to )nationalCoachtouristCoachService (mapped to )touristCoach

MetroSubmode MetroSubmodesOfTransportEnumeration Possible values:

metrourbanRailway

References to affected Network element(s).

Please note that VehicleMode and Submode are the same as in Norwegian NeTEx profile, TransportModes

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/637370398/framework#framework-TransportModes

of 26

RailSubmode RailSubmodesOfTransportEnumeration Possible values:

interbational . [sic] Please note, is incorrectlythe typoimplemented in the official standard. Mapped to 'international'.interRegionalRailService (mapped to )interregionalRaillocallongDistanceTrain (mapped to )longDistancesleeperRailService (mapped to )nightRailregionalRailspecialTrainService (mapped to )airportLinkRailtouristRailway

TramSubmode TramSubmodesOfTransportEnumeration Possible values:

localTramService (mapped to )localTram

WaterSubmode WaterSubmodesOfTransportEnumeration Possible values:

highSpeedPassengerServicehighSpeedVehicleServiceinternationalCarFerryService (mapped to internationalCarFerry)internationalPassengerFerrylocalCarFerryService (mapped to )localCarFerrylocalPassengerFerrynationalCarFerryService (mapped to )nationalCarFerrysightseeingService

(choice)element

AffectedLine SIRI-SX#AffectedLineStructure 1: * Reference(s) to affected line(s).

Must be stated explicitly or due to technicalAffectedLine AllLines demands on the element in the SIRI standard.

AllLines xsd:string ( )empty 1: 1

AFFECTEDOPERATORSTRUCTURE

AffectedOperatorStructure


element OperatorRef xsd:NMTOKEN 1: 1 Reference to an affected operator.

AFFECTEDLINESTRUCTURE

AffectedLineStructure


element LineRef xsd:NMTOKEN 1: 1 Reference to in question Line (ID to the corresponding object in the timetable data).

element Routes SIRI-SX#AffectedRoute 1: * Reference to in question Route(s) (ID to the corresponding object in the timetable data), when thesituation does not apply to the entire Line.

AFFECTEDROUTE

AffectedRouteStructure


element AffectedRoute SIRI-SX#AffectedRouteStructure 1: 1 Reference to in question Route (ID to the corresponding object in the timetabledata).

AFFECTEDROUTESTRUCTURE

AffectedRouteStructure

Reference to an affected .Operator

Information about an affected .Line

Wrapper object to describe information about a Route affected by the situation.

Information about an affected Route

of 26


element RouteRef xsd:NMTOKEN 0: 1 Reference to in question Route (ID to the corresponding object in the timetable data).

element StopPoints SIRI-SX#AffectedStopPoint 0: * Reference to affected stop(s) in the affected Line.

AFFECTEDSTOPPOINT

AffectedStopPoint


element StopPointRef xsd:NMTOKEN 1: 1 Reference to the Quay in question (ID corresponding to objects in the nationalstop place registry).

If the quay is currently unknown, or the message applies to quays, aallreference to StopPlace may be used instead.

element StopPointName NaturalLanguageStringStructure 0: 1 Name of StopPlace (Not used, but may be set to increase human readability.)

element StopCondition RoutePointTypeEnumeration 0: * Specifies which passengers the message applies to, for example, people whoare disembarking at an affected stop.

Possible values:

exceptionalStop ( )for passengers expecting an interchangedestination (for passengers expecting to disembark, of at the last stop)notStopping (when passing a stop)requestStop ( )when a passenger must request the serving of a stopstartPoint ( )at departure or when passengers expect to boardstop (default - affects all interactions with the stop (boarding, alighting,arrival, departure, interchanges)

If this field is left blank or omitted the message will be interpreted as affectingboarding and alighting.

AFFECTEDSTOPPLACE

AffectedStopPlace


element AccessibilityAssessment SIRI-SX:AccessibilityAssessment 0: 1 Specifies whether the object is still available for users with specialneeds.

element StopPlaceRef xsd:NMTOKEN 1: 1 Reference to StopPlace or specific Quay (ID corresponding to objectsin the national stop place registry).

element PlaceName NaturalLanguageStringStructure 0: 1 Name of the stop (not used due to the reference to the national stopplace registry, but be included to make the XML easier to read). can

element AffectedComponents SIRI-SX#AffectedComponent 0: * Reference(s) to which part(s) of the stop(s) are being affected.

ACCESSIBILITYASSESSMENT

AccessibilityAssessment


element acsb:MobilityImpairedAccess xsd:boolean 1: 1 Specifies whether the object is still available for userswith special needs.

element acsb:Limitations acsb:AccessibilityLimitation 1: 1 Specifies limitations for users with special needs.

ACCESSIBILITYLIMITATION

Reference(s) to affected stop(s).

References to affected stops.

Description of (changed) availability as a result of the situation.

Descriptions of limitations for users with special needs.

Must be in accordance with for the stop, defined in accordance with the Norwegian NeTEx profile for .AccessibilityLimitation stops

https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728727661/stops

of 26

AccessibilityLimitation


element WheelchairAccess AccessibilityEnumeration 1: 1 Possible values:

truefalseunknown

element StepFreeAccess AccessibilityEnumeration 1: 1 Possible values:

truefalseunknown

element EscalatorFreeAccess AccessibilityEnumeration 1: 1 Possible values:

truefalseunknown

element LiftFreeAccess AccessibilityEnumeration 1: 1 Possible values:

truefalseunknown

AFFECTEDCOMPONENT

AffectedComponent


element ComponentRef xsd:NMTOKEN 0: 1 Reference to the Quay in question (ID corresponding to objectsin the national stop place registry).

Used if ComponentType is "quay"

element ComponentType ifopt:StopPlaceComponentTypeEnumeration 1: 1 Possible values:

accessSpaceboardingPosition ( )only for trainsentrancequay

element AccessFeatureType ifopt:AccessibilityFeatureEnumeration 0: 1 Possible values:

escalatorliftnarrowEntrancerampstairs

Used when it necessary to specify limitations for users withspecial mobility needs.

AFFECTEDVEHICLEJOURNEY

AffectedVehicleJourney


(choice)element

VehicleJourneyRef xsd:NMTOKEN 1: 1 Reference to affected VehicleJourney (ID to the correspondingobject in the timetable data).

FramedVehicleJourneyRef FramedVehicleJourneyRefStructure Reference to affected VehicleJourneywith date (ID to thecorresponding object in the timetable data).

element Operator SIRI-SX#AffectedOperatorStructure 0: 1 Reference to affected Operator (ID to the correspondingobject in the timetable data).

Not used, but may be set to increase human readability.

Complementary information regarding parts of a stop being affected by the situation (for example which quay).

Reference(s) to affected VehicleJourney(s) with Route.

of 26

element LineRef xsd:NMTOKEN 0: 1 Reference to affected Line (ID to the corresponding object inthe timetable data).

Not used, but may be set to increase human readability.

element Route SIRI-SX#AffectedRouteStructure 1: * Reference to affected Route(s) (ID to the corresponding objectin the timetable data).

Mandatory field (due to format implementation), but can beblank if the situation affects stops in all AffectedVehicleJourney.

element OriginAimedDepartureTime xsd:dateTime 0: 1 Originally planned departure time (per time table) from the firststop of the departure.

SIRI-VM

The Service Interface for Real Time Information - Vehicle Monitoring

Content

ContentData requirementsComponents

VehicleMonitoringDeliveryVehicleMonitoringDeliveryVehicleActivityProgressBetweenStopsMonitoredVehicleJourneyLocationMonitoredCallStructure

This document is part of the Norwegian SIRI Profile and describes datasets and elements used for exchanging updates on position and status,in the real-time formatas well as estimated delays SIRI Vehicle Monitoring (VM) .

SIRI-VM is used to model vehicle-movements and their progress compared to a planned timetable. The data is linked to objects in the planneddata by use of ID's, which ensures data quality.

Data requirements

Sending a of SIRI-VM data must be in accordance with this profile and the ServiceDelivery entire dataset should be contained within a single.XML file

Note that the profile does not present an exhaustive list of all real-time information technically possible to transfer via SIRI-VM, but it lays thefoundation for which demands are placed on the datasets in order to meet the demands set by .Håndbok N801

It is permitted for client systems to send more than one per , in order for real-time information to beVehicleActivity VehicleMonitoringDeliveryconflated and be transferred as part of the same .ServiceDelivery

The associated with this profile are meant to show practical implementations of specific use cases, and can contain supplementary,exampleslack certain data fields, or contain optional data, compared to a full and complete dataset. See for closer descriptions ofSIRI-VM#Komponenterthe data types, specifications and requirements on the unique elements of the SIRI VM-data.

Components

VehicleMonitoringDelivery

VEHICLEMONITORINGDELIVERY

VersionCurrent version for SIRI-VM is: v1.0 (last changed )01 May 2019

When sending data, information should be restricted to the next stop only, that is the current (and Vehicle Monitoring MonitoredCall IsCompl = 'false')eteStopSequence

It is a fundamental requirement that valid timetable data (as NeTEx or SIRI-ET-data) is delivered sending in position- and statusbeforeinformation as SIRI-VM.

A data type for representing vehicle monitoring (for estimated adjustment of times) for one or more .VehicleJourneys



of 26

VehicleMonitoringDelivery < ServiceDelivery


attribute version xsd:NMTOKEN 1: 1 Version ID for EstimatedTimetableDelivery

element ResponseTimestamp xsd:dateTime 1: 1 Timestamp for when the dataset was created/published.

element VehicleActivity SIRI-VM#VehicleActivity 1: * A container element for sending one or more with aVehicleActivitytimestamp.

VEHICLEACTIVITY

VehicleActivity


element RecordedAtTime xsd:dateTime 1: 1 Timestamp for when the dataset was created/published.

element ValidUntilTime xsd:dateTime 1: 1 Validity-expiration date and time of the dataset.

element ProgressBetweenStops SIRI-VM#ProgressBetweenStops 0: 1 Information on the progress of the vehicle between stops.

element MonitoredVehicleJourney SIRI-VM#MonitoredVehicleJourney 1: 1 Data object for a real-time monitored .VehicleJourney

PROGRESSBETWEENSTOPS

ProgressBetweenStops


element Percentage xsd:decimal 1: 1 How much of the total distance (percentage) that has been traversed at the time of the message.

element LinkDistance xsd:decimal 0: 1 Distance in meters between previous and next stop ( ).MonitoredCall

Corresponds to Distance for current ServiceLink, when available.

MONITOREDVEHICLEJOURNEY

MonitoredVehicleJourney


element LineRef xsd:NMTOKEN 1: 1 Reference to the Line in question (ID to the correspondingobject in the timetable data)

element FramedVehicleJourneyRef FramedVehicleJourneyRefStructure 1: 1 Reference to VehicleJourney in question. Has a date.

element VehicleMode VehicleModesEnumeration 0: 1 Transport types

Possible values:

airbuscoachferry ( )mapped to "water"metrorailtram

element OperatorRef xsd:NMTOKEN 0: 1 Reference to Operator in question (ID to the correspondingcompany in the timetable data)

element OriginRef xsd:NMTOKEN 0: 1 Reference to origin Quay in question (ID to the correspondingQuay in the timetable data and national stop place registry)

element OriginName NaturalLanguagePlaceNameStructure 0: 1 Name describing the origin of the departure.

Container-element for returning one or more VehicleActivity.

Information on the progress of the vehicle along the current or between current-, and next .ServiceLink ScheduledStopPoint

Data objects with elements to describe a real-time monitored VehicleJourney, including supplementary locational information, and dataabout the current stop.

Used to enrich existing timetable data.

of 26

element DestinationRef xsd:NMTOKEN 0: 1 Reference to destination Quay in question (ID to thecorresponding Quay in the timetable data and national stopplace registry)

element DestinationName NaturalLanguagePlaceNameStructure 0: 1 Name describing the destination of the departure.

element Monitored xsd:boolean 0: 1 Whether the vehicle is currently reporting real-time data or not(for example set to when the driver of the vehicle logs on totruethe system before departing).

element DataSource xsd:string 1: 1 Codespace of the data source (see codespace).

element VehicleLocation SIRI-VM#Location 1: 1 The position of a vehicle as a geospatial point.

element Bearing xsd:float 0: 1 Current compass bearing (direction of VehicleJourney)


Possible values:


element Delay xsd:duration 1: 1 Delay-time.

Defined as "PT0S" (0 seconds) when there are no delays.

element InCongestion xsd:boolean 0: 1 Whether the vehicle is affected by traffic jams or othercircumstances which may lead to further delays.

element VehicleStatus VehicleStatusEnumeration 0: 1 Vehicle status.

Possible values:

assigned (a vehicle has been assigned, but not yet)deployed

atOrigin (VehicleJourney has not begun, the vehicle is still)at the first stop

cancelledcompleted (verification that the VehicleJourney has been

)completedinProgressoffRoute ( )VehicleJourney is taking a detour

element MonitoredCall SIRI-VM#MonitoredCallStructure 0: 1 Information on the next or current (the vehicle has not yetdeparted) stop place for a .VehicleJourney

element IsCompleteStopSequence xsd:boolean 1: 1 Always set to 'false' when the submitted data only containsMonitoredCall.

LOCATION

Location


attribute srsName xsd:string 0: 1 The reference system for longitude and latitude. If stated, use WGS84 or if necessary a valid coordinate-reference to the standard used (for example "EPSG:4326").

(choice)element

Longitude

Latitude

xsd:decimal

xsd:decimal

1: 1 Longitude (-180 to 180)

Latitude (-90 to 90)

Coordinates xsd:NMTOKENS Location coordinates.

For example: <gml: pos srsName="urn:ogc:def:crs:EPSG::4326"> -59.123-45.1254 </gml:pos>

Note! The stop place registry only accepts WGS84-coordinates.

MONITOREDCALLSTRUCTURE

MonitoredCallStructure


element StopPointRef xsd:NMTOKEN 1: 1 Reference to the Quay in question (ID corresponding to objects in thenational stop place registry).

Specifies location of something.

Information regarding the current stop for VehicleJourney (the stop the vehicle is headed to or has stopped at.


of 26

element StopPointName NaturalLanguageStringStructure 0: 1 Name of the stop (not used due to the reference to the national stop placeregistry, but be included to make the XML easier to read).can

element VehicleAtStop xsd:boolean 0: 1 Whether the vehicle is at the stop.

element VehicleLocationAtStop SIRI-VM#Location 0: 1 Where the vehicle is at the stop.

Used for significant deviations from planned and published information.

element DestinationDisplay NaturalLanguageStringStructure 0: 1 Destination text (not but be included to make the XML easier to read).can

Håndbok N801 - Nasjonale rutedata v2€¦ · egnet til å støtte reiseplanleggere,...

Documents

Transcript of Håndbok N801 - Nasjonale rutedata v2€¦ · egnet til å støtte reiseplanleggere,...