Nasjonale rutedata Rammer og informasjonselementer

Normativ Håndbok N801

Dokument nr.: 201800413-1 Dato: 28.02.2018

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 gjeldene fra 1. februar 2017, med krav om innsending av data på nytt format fra 1. juli 2017. Den erstatter tidligere håndbøker V820 – Nasjonale rutedata og N801 – Nasjonale rutedata, utgitt av Statens vegvesen vegdirektoratet.

Jernbanedirektoratet, februar 2018

Prosjektnummer: 600001

Ansvarlig avdeling: Marked og samfunn Faglig ansvar: Markedskunnskap

Versjon: 1.0

Forsidefoto/illustrasjon: Statens vegvesen/Colourbox

ISBN: 978-82-8386-000-9

Innhold

Nasjonale rutedata 3

Innhold

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 avviksinormasjon .................................................................................. 30

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, med teknisk spesifikasjon for levering av sanntids - og avviksdata, vil bli vedlegg til Håndbok N801 ved neste revisjon.

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

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

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-4/2017 (https://www.regjeringen.no/no/dokumenter/rundskriv-n-42017-om-reviderte-retningslinjer-for-offentliggjoring-av-ruteopplysninger-for-persontransport/id2563310/) fastsatt retningslinjer til yrkestransportforskriften for offentliggjøring av ruteopplysninger for persontransport, og derigjennom trådte dagens kunngjøringsplikt i kraft 1. juli 2017.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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)

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

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

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

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.

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.

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.

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

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.

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 avviksinormasjon 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, eller på annen måte tilgjengeliggjøre, eksisterende sanntidsdata til det nasjonale selskapet. Det samme gjelder endringer i ruter og tidtabeller etter at fristen for normal innlevering av data har gått ut. I første omgang omfatter pålegget å sende inn sanntids- og avviksdata fra allerede implementerte systemer, men alle operatører er sterkt oppfordret til å innføre sanntidssystem der det er relevant. Ved fremtidig innføring av dette, eller oppgradering av eksisterende, stilles det videre krav til at ny implementasjon skal støtte SIRI-PT, SIRI-ET, SIRI-VM og SIRI-SX i henhold til gjeldende spesifikasjon.

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 Production Timetable (PT) sendes inn ved endringer som skjer tidligst neste døgn. 2. 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.

SIRI-protokollen tillater ulike varianter for levering av samme type data ("dialekter" av standarden). For å unngå at det implementeres leverandøravhengige modeller for datainnsendelse, vil det i parallell med innfasing av eksisterende sanntidsdata bli utarbeidet en felles norsk profil basert på versjon 2.0 av SIRI. Dette blir tilsvarende som med NeTEx profil Norge for rutedata, og på sikt skal den norske profilen for sanntidsdata publiseres som en del av Håndbok N801. Det vil si at etter en samkjøringsperiode vil leverandører med avviks- og sanntidsdata også bli pålagt å levere disse i henhold til profilens spesifikasjoner.

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

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

5.1.2 Presedens for data I tilfeller hvor nasjonalt selskap mottar data for samme linje over flere kanaler, vil dette håndteres slik at innsendte rutedata vil bli overstyrt av endringer med kort horisont sendt som SIRI-PT. Ved mottak av fortløpende endringer som SIRI-ET vil dette overstyre rutedata og eventuelle tidligere endringer mottatt som SIRI-PT. Den samme overstyringen gjelder også avviksmeldinger mottatt som SIRI-SX.

Kort oppsummert vil innsendte data overstyres på følgende måte:

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. Mindre endringer i datasettet som gjelder mer enn et døgn frem i tid kan sendes inn som SIRI-PT

o Dette vil overstyrer eksisterende rutedata 3. Fortløpende endringer og avviksdata som gjelder inneværende driftsdøgn skal sendes inn

som SIRI-ET / VM / SIRI-SX o Ved mottatte endrings- og avviksmeldinger vil disse alltid overstyre eksisterende

rutedata

jernbanedirektoratet.no

NeTEx (langsiktig rutedata) < SIRI PT (kortsiktig rutedata) < SIRI ET / VM / SX (sanntids- og avviksdata)

Håndbok N801Versjon 1.2

Jernbanedirektoratets håndbokserie

Vedlegg A - NeTEx profil Norge

Vedlegg A inneholder norsk profil for overføring av stoppesteds-, nettverks- og rutedata ved hjelp av NeTEx-formatet.

Vedlegget omfatter norsk dataprofil for NeTEx standard del 1 og del 2.

1. Håndbok N801 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. Generell informasjon NeTEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233. Profildokumenter NeTEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.3 network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.4 timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4. Codespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Håndbok N801

Nasjonale rutedata-      Rammer og informasjonselementer

Normal for elektronisk overføring av rutedata

Håndbøker i Statens vegvesen

Dette er en håndbok i Statens vegvesens håndbokserie. Vegdirektoratet har ansvaret for utarbeidelse og ajourføring av håndbøkene.

Denne håndboka publiseres kun digitalt på Statens vegvesens nettsider, www.vegvesen.no

Statens vegvesens håndbøker utgis på to nivåer:

Nivå 1 -     Oransje eller grønn fargekode på omslaget - omfatter (oransje farge) og  (grønn farge) godkjent av overordnetnormal retningslinjemyndighet eller av Vegdirektoratet etter fullmakt.

Nivå 2 -     Blå fargekode på omslaget - omfatter godkjent av den avdeling som har fått fullmakt til dette i Vegdirektoratet.veiledning

Nasjonale rutedata-  rammer og informasjonselementer

Nr. N801 i Statens vegvesens håndbokserie

Ansvarlig avdeling: Seksjon for trafikkforvaltning

  

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 omalle rutetilbud i landet, og disse rutedataene skal gjøres offentlig tilgjengelig på en konkurransenøytral måte som er egnet til å støttereiseplanleggere, billettsystemer og andre formål som kan nyttiggjøre seg slike rutedata.

Ansvaret for innhenting, forvaltning og formidling av nasjonale rutedata er delegert til Vegdirektoratet. Arbeidet med revidering avkunngjøringsplikten samt innhenting, forvaltning og formidling av nasjonale rutedata har vært organisert i form av et prosjekt som har værtledet 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 samt NHO Transport somJernbaneverket, har ivaretatt kommersielle aktører fra rutebilbransjen.

Innholdsfortegnelse

1. Innledning1.1. Formålet med denne håndboka1.2. Innholdet i håndboka

2. Rammer for nasjonale rutedata2.1. Formålet med nasjonale rutedata2.2. Nasjonalt selskap for administrasjon av rutedata2.3. Lovhjemmel2.4. Levering av rutedata2.5. Opphør av linje2.6. Bruk av rutedata

3. Rutedata-format3.1. Kort om NeTEx3.2. NeTEx profiler3.3. Profildokumenter

4. Nasjonalt stoppestedsregister4.1. Registrerte data4.2. Ansvarsfordeling4.3. Eierskap og tilgang4.4. Administrasjon av stoppesteder4.5. Standard for navngiving av stoppesteder4.6. Stoppestedutrustning4.7. Modelleringseksempler

5. Sanntids- og avviksdata5.1. Krav til sanntids- og avviksinformasjon

1. Innledning

Denne teksten danner grunnlag for publisert under , og detHåndbok N801 nasjonale rutedata Statens vegvesens håndbokseriegjøres oppmerksom på at det er Håndboken publisert hos Statens vegvesen som er gjeldende offisielle versjon av Håndbok N801.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1.

2.

3.

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

1.1. Formålet med denne håndboka

Formålet med denne håndboka er tredelt:

Håndboka skal informere om rammene for nasjonale rutedata.Motivasjonen bak opprettelsen av nasjonale rutedata beskrives med utgangspunkt i europeiske direktiver, nasjonale lover og behovfor nye og bedre reiseinformasjonstjenester. Det gis også informasjon om retningslinjer for levering, forvaltning og bruk av rutedata.Håndboka skal definere den informasjonen som inngår i nasjonale rutedata og som skal leveres i henhold til Kunngjøringsplikten.Alle , det vil si fylkeskommuner og Jernbanedirektoratet eller deres administrasjonsselskaper/løyvehaveredataleverandørersamt fylkeskryssende kommersielle aktører og andre som er ansvarlig for forvaltningen av nasjonale rutedata, skal forholde seg tilde gitte kravene og kontrollere at disse oppfylles. Data som ikke skal leveres i dag, men som sannsynligvis vil bli krevd levert ifremtiden defineres også, slik at dataleverandørene kan forberede seg på et tidlig tidspunkt. Merk at listen over data som vil kunnebli 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- ogavviksdata.

1.2. Innholdet i håndboka

Håndboka har følgende kapitler:

Kapittel 2 gir en kort introduksjon til kunngjøringsplikten og hvilke data vi ønsker innsendt. Kapittelet beskriver også hvordan detteskal 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 avstoppestedsdata.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, med teknisk spesifikasjon for levering av sanntids - og avviksdata, vil ble vedlegg til Håndbok N801 ved neste revisjon.

I tillegg til håndboksdokument og vedlegg vil det bli tilgjengeliggjort et eget web-område med tekniske prosessbeskrivelser, teknisk malverk(XML) og eksempler på dataleveranser.

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 ogandre tjenestetilbud.

2.1. Formålet med nasjonale rutedata

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

Rutedataene skal være konkurransenøytrale og de er offentlige. Dette betyr at alle skal ha likeverdig tilgang til dataene og kunne brukedataene 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åendekollektivtransport.Det blir lettere å etablere og drifte reiseinformasjonstjenester ved hjelp av enkel tilgang til kvalitetssikret informasjon om blant annetruter og stoppesteder.Fylkeskommuner og andre aktører behøver ikke selv å etablere tjenester for offentliggjøring og formidling av sine rutedata, og kanbasere 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 oggange.

Nasjonale rutedata kan etter hvert integreres med andre data som øker funksjonaliteten i reiseinformasjonstjenestene ytterligere. Det er foreksempel et ønske om at rutedata skal kunne integreres med data som muliggjør beregning av takster på tvers av fylkesgrenser og

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

operatører. En utvikling av samordnet billettering basert på Håndbok V821 og etablering av en standard for mobil-billettering vil troligmuliggjø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. Nasjonalt selskap for administrasjon av rutedata

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

2.3. Lovhjemmel

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

2.3.1. ITS-direktivet og PSI-direktivet

PSI-direktivet (Public Sector Information direktivet) og ITS-direktivet (Intelligente Transportsystemer direktivet) er vedtatt i EU, og Norge ergjennom EØS-avtalen forpliktet til å følge direktivene. PSI-direktivet omhandler tilgjengeliggjøring av offentlige data, og konsekvensene forNorge 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 vilbli førende for de spesifikasjoner som nå utvikles under ITS-direktivet og som blir obligatoriske også for nasjonale reiseplanleggingstjenesteri Norge. Norge må derfor følge arbeidet i Europa tett.

2.3.2. Kunngjøringsplikten

Forskrift om yrkestransport med motorvogn og fartøy (yrkestransportforskriften) legges til grunn for å sikre at nødvendige stoppesteds- ogruteplansdata overføres fra pliktige parter. følger aKunngjøringsplikten v forskriftens § 28, som sier:

”Ruteplan må være godkjent av løyvemyndigheten. Forslag om endring av ruteplan sendes løyvemyndigheten senest 4 måneder førendringen skal tre i kraft.

Løyvemyndigheten kan redusere tidsfristen etter første ledd og kan bestemme at endring kan settes i verk på kortere tid eller ativerksettelsen skal utsettes. Løyvemyndigheten kan videre gi pålegg om endring av ruteplan.

Departementet fastsetter nærmere retningslinjer for hva ruteplan for personruter skal angi og hvordan disse skal offentliggjøres.”

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

Samferdselsdepartementet har i rundskriv N-2/2013 (http://www.regjeringen.no/upload/SD/Vedlegg/brev_retningslinjer_rutedatabase_2013.p) fastsatt retningslinjer til yrkestransportforskriften for offentliggjøring av ruteopplysninger for persontransport, og derigjennom trådte dagensdf

kunngjøringsplikt i kraft 1. mai 2013.

2.3.3. Samarbeidsforum for forvaltning av kunngjøringsplikten

For å forvalte og videreutvikle Kunngjøringsplikten, er det etablert et eget Samarbeidsforum som ledes av Vegdirektoratet. Deltakerne er etrepresentativt utvalg av de som leverer rutedata, så som Fylkeskommunenes administrasjonsselskaper, jernbaneoperatører, ferjeselskaperog 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 ( ) er sekretariat for Samarbeidsforumet.se avsnitt Nasjonalt selskap for administrasjon av rutedata

NYTT RUNDSKRIV ER UNDER ARBEID SOM EN DEL AV REVISJON AV HÅNDBOK N801 (referanse vil bli oppdatert når nytt)rundskriv er publisert

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

2.4. Levering av rutedata

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

2.4.1. Hvem skal levere rutedata

Fylkeskommunen eller Samferdselsdepartementet ved Jernbanedirektoratet (som løyvemyndigheter) er ansvarlige for at rutedata leveres tildet nasjonale selskapet i henhold til retningslinjene. Ansvaret for å levere rutedata kan organiseres gjennom administrasjonsselskapene forkollektivtrafikk, eller ved at operatører gis fullmakt til å levere rutedata direkte. Fylkeskommunene og Jernbanedirektoratet må da påse at desom 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 informasjonom stoppesteder og knutepunkter i eget fylke, Jernbaneverket har tilsvarende for stopp tilknyttet jernbane. Disse instansene har også ansvarfor at det meldes inn navn på stoppestedet. Navn fastsettes av ansvarlig part i henhold til nærmere beskrevne retningslinjer (se avsnitt Stand

). Det nasjonale selskapet betraktes som rådgivende part, men dersom navngivningen ikke følgerard for navngiving av stoppestedernavngivningsstandarden 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 mankan 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 ogandre tjenester som baserer seg på nasjonale rutedata, samt sluttbrukerne på disse løsningene) for eventuelle problemer og avvik somskyldes 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 itid. 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.

2.4.2.1. Stoppesteder

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

Administrasjon av stoppestedsdata vil bli håndtert med egne retningslinjer hos det nasjonale selskapet. Dette fordi stoppestedsregisteret skalvære landsdekkende masterdata-kilde og vil være teknisk og administrativt separert fra ruteplandata. Uavhengig av fysisk tilstand må allestoppesteder være registrert i det nasjonale stoppestedsregisteret før det kan sendes inn ruter som benytter stoppestedet, eller er koplet tildet på annen måte. Dette sikrer at alle transportmidler som stopper ved eller har overgang til et stoppested, bruker den samme nasjonaltunike 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 ( ), somPoint of Interestfor eksempel offentlige kontorer, skoler og utdanningsinstitusjoner, idrettsarenaer eller andre "severdigheter" med betydelig

KonkurransemanipulasjonVed innsending av åpenbart urealistiske rutetider eller andre på annen måte bevisst konkurransevridende manipulasjon avdatagrunnlaget, har nasjonalt selskap myndighet til å endring av ruteoppsettet. Dersom en dataleverandør ikkepåleggeetterkommer dette, eller gjentatte ganger gjør endringer i strid med disse bestemmelsene, står nasjonalt selskap i ytterste

fritt til å utelate spekulativt konkurransevridende rutedata fra data-eksporter, reisesøk og liknende frem til forholdet erkonsekvensrettet.

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

publikumstilstrømning. Dette er ikke primærformålet med stoppestedregisteret, slik at skillet mellom slike steder i stoppestedregisteret kontrakartinformasjon benyttet i reisesøk må avklares fortløpende, men slike steder vil ved behov kunne håndteres på samme måte og gistilsvarende reise-relevant tilleggsinformasjon som vanlige stoppesteder.

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

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 typetransportmiddel som trafikkerer ruten. Informasjonen skal inneholde opplysninger om dager, tider og stoppesteder, samt om linjen kuntrafikkeres 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 stopperpå et stoppested kun for påstigning eller avstigning skal dette angis spesielt. Detaljspesifikasjon av krav knyttet til leverte ruteplanerfremkommer i vedlegg .NeTEx profil Norge

2.4.3. Teknisk dataleveranse

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

Filsending med SFTPFilopplasting i web-grensesnittManuell 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 tilgangfor 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 <PublicationDelivrotnode (se også nærmere beskrivelse av  ), hvor innholdet er satt opp i henhold til kravene fastsatt i vedlegg ery>  utveklingsformatet NeTEx

. Alle XMLer som leveres til nasjonalt selskap må bestå av komplette datasett for hele sin gyldighetsperiode.profil Norge

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 tilganginkludert leverandør-identifikator ( , ref. tidligere "Administrajonskode"). Denne er påkrevd å bruke ved innsending av data,codespacenærmere beskrevet under i vedlegg .Utforming av identifikatorer 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 ( ), eller gjennom oppdateringer direkte i Stoppestedsregisteretsse og under denneNeTEx profil Norge eksempel-katalogensluttbrukerløsning (web-portal), sørge for å holde oppdatert alle nasjonale stoppesteder. Dette registeret danner felles grunnlag for alleruteplaner 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 rutXML-fil per linje. Denne filen skaledataene sendes inn, skal datasettet bestå av en ZIP-fil uten underkataloger ( ) med énflatt hierarki  

inneholde de NeTEx-strukturer som er nødvendig for å beskrive alle relevante fasetter ved linjen, i henhold til "network-timetable"-profil, medDisse data skal være.referanser til stoppesteder basert på ID i stoppestedsregisteret (se for vedlegg eksempel-katalog   NeTEx profil Norge)  

komplette sett per linje, med minimum 120 dagers gyldighet, og inneholde all nødvendig informasjon om transportmiddelet, dager linjenopereres, ankomst- og avgangstider med mer, samt om linjen går i fast trafikk eller må forhåndsbestilles og om det er spesiellebegrensninger 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

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 bkunrukes referanser gjennom for eksisterende stoppesteder. Opplysninger om tilknyttede stoppesteder vil gjennom denneoffisiell IDreferansen i sin helhet bli hentet fra stoppestedsregisteret.

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1.

2.

3.

4.

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 atgjennomgående elementer kan trekkes ut av de enkelte datasettene og leveres i en felles-fil. Dette for å unngå omfattende redundans av foreksempel identifikator-beskrivelser, gyldighetsperioder, referanser til stoppested og tilordning av disse og overordnede rute-definisjoner (se

). Merk at en slik forenklet konstruksjon av datasett for innsending er en , men detnærmere forklaring i vedlegg NeTEx profil Norge  mulighetstilles ingen krav om dette. Innlevering av data med gjentakende beskrivelse av felles elementer vil bli håndtert på samme måte, og resulterei samme rutedata som innlevering på komprimert form.

2.4.3.4. Normal leveranse

I forkant av rutedatainnlevering må samtlige stoppesteder brukt i datasettet være registert 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 Tilgangssty.ring

Følgende prosess gjelder for innlevering:

Dataleverandører sender NeTEx-XML med oppdatere rutedata ( )alternativt oppdaterer manuelt i RutedatabasenSFTPWeb-grensesnitt

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_p

i standardorganets offisielle )ublication.xsd repository på GitHubPublicationDelivery-noden må inneholde alle nødvendige for innsendingenframesxmlns (innsenders identifikator) er gyldigAlle stoppesteder referert i datasettet må eksistereStoppesteder referert kan ikke være markert som eller stengt nedlagtReferanser til eksterne rutedata må være korrekte ( )for eksempel ved overgang til andre linjerGeografiske referanser må være gitt på korrekt format

Når mottatt innhold er validert sendes rutedataene videre for importert i rutedatabasenVed valideringsfeil vil avsender umiddelbart motta en rapport fra nasjonalt selskap som beskriver feilene i mottatt datasettNår logiske feil i datasettet er rettet opp kan dette sendes inn på nytt for import

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

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

2.4.3.5. Innlevering av datasett

Overordnet prosess-illustrasjon for innlevering / oppdatering av datasett:

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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

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

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ålsetningenpå 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å atlø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 omretting. I varselet vil det bli informert om innrapporterte eller avdekkede feil og mangler, uten at dette varselet nødvendigvis inneholder enuttø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 datasettfra 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 fastlagt, senest innen 24 timer før avviket trer i kraft. Avvik skal i størst mulig gradforsøkes håndtert gjennom innsending av nye rutedata. I tilfeller hvor dette ikke er praktisk eller teknisk mulig, for eksempel ved for kortvarsel før avviket inntrer, kan dette håndteres gjennom SIRI-SX avviksmeldinger. Alternativt kan avvik innmeldes ved hjelp av SIRI-ET (nårendringer gjelder inneværende dag) eller SIRI-PT (når endringene gjeldender 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 alledata som eventuelt finnes fra før innenfor samme gyldighetsperiode. Nye datasett som oppdaterer ruter og tidtabeller kan altså sendes innfortlø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 ugrunnetopphold sende melding om dette til det nasjonale selskapet. (Merk at det samme også gjelder ved avvik planlagte som blir gjort kjent med for

, for eksempel avvik som har blitt for sent annonsert på grunn av avhengigheter til mange aktuelle etater eller andre tilfeller av sviktkort varseli informasjonsflyten som dataleverandøren ikke kan lastes for.) Dette skal meldes inn gjennom endring av rutedata. Men i de tilfeller hvorrutedata må endres innen , må dataleverandøren selv gjøre en vurdering om det er tilstrekkelig å foreta en normalkortere tid enn et døgnpublisering av endringen eller om dette bør publiseres ved hjelp av sanntidsmeldinger (nærmere beskrevet under bestemmelser for Sanntids-

). Andre endringer som berører spesifikk(e) avgang(er) med behov for kort publikasjonstid, kommuniseres som hovedregel vedog avviksdatahjelp av sanntidsmeldinger.

2.4.5. Status for rutedata

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

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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

2.4.6. Eksempler

Relevante varianter av datasett for innsending (XML / PublicationDelivery) finnes i for vedlegg . eksempel-katalogen 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 feilaktigvarsel 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 i vedlegg .under Line 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 midlertidigutilgjengelig. Dette er nærmere spesifisert i . (Se også prosess for over.)NeTEx profil Norge Permanent nedleggelse

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

Vanlig linje som eksisterer og skal fortsette å eksistere i uoverskuelig fremdtid: ingen validitiyConditionSesonglinje: validityCondition som spesifiserer fra og til-dato for gyldighetLinje som snart legges ned: validityCondition kun med sluttdatoLinje som opprettes i nær fremtid: valdititCondition kun med startdato

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

Der det er hensiktsmessig vil det også være mulig å sette et attributt ved innsendelse av rutedata, tilsvarende som ved permanentnedleggelse. 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 - ellerbruke 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 ( ) med brukeren. DetteNorsk lisens for offentlige data NLODgjø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 vilderimot bli gjort tilgjengelige via åpne og veldokumenterte tjenestegrensesnitt (API-er) og/eller nedlastbare filer hvor det til enhver tid er muligfor brukerne å hente oppdaterte data.

3. Rutedata-format

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 EU, og deter arbeides for å få den etablert som en EU NORM. NeTEx er bygget på den konseptuelle informasjonsmodellen TransModel som også eren EU-standard.

NeTEx har en egen  .nettside der man kan finne mer informasjon

3.2. NeTEx profiler

NeTEx-formatet kan brukes for å beskrive veldig mange aspekter ved offentlig transport, alt fra den fysiske infrastrukturen inkludert

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1. 2. 3. 4. 5. 6.

stoppesteder via materiell, tidtabeller, sjåførplanlegging til informasjon om billettpriser og soner. Fordi formatet skal være fleksibelt og kunnedekke en rekke transportekniske behov i Europa, gir modellen også rom for mange ulike måter å modellere ulike aspekter fra virkeligheten

I informasjonstjenester er det kun behov for en liten del av det som er mulig å beskrive ved hjelp av den tekniske spesifikasjonen, og enpå. "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 inkluderesmåHvilke data-verdier som er gyldige for disse feltenePå hvilke måter man ønsker gitte aspekter modellert

3.3. Profildokumenter

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

Generell informasjon NeTExRammeverk (Framework)Stoppesteder (Stops)Nettverk (Network)Tidtabeller (Timetable)Billettpriser (Fares) ( )kommer senere

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

4. Nasjonalt stoppestedsregister

Formålet med stoppestedsregisteret er:

Sikre at alle eksisterende stoppesteder er kjent og brukes likt av alle dataleverandører.Dette vil gjøre det enklere for de som opererer på tvers av regioner å planlegge sine ruter.Det vil sikre at alle dataleverandører benytter opprette egne.stoppesteder som allerede eksisterer fremfor å

Sikre at alle dataleverandører som benytter stoppestedet i sine publikasjoner bruker navn, koordinat og annen publikumsrettetinformasjon likt.

Dette er en forutsetning for å kunne beregne korteste reiseveg for en reisende, samt for å kunne beregne pris og utstedegjennomgå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

NavnUnderelementer (Quays, innganger, ganglenker)Koordinater i henhold til WGS84-standarden

LatitudeLongitudeHeight ( )hvis relevant

Regional tilhørighetFylkeKommune

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

Det bemerkes spesielt at vedlegget vil være i perioden mens standarden innfases, ogNeTEx profil Norge dynamiske dokumenterdette 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 gjøre eventuelle tilpasninger for åmå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 vil støtte alle publiserte versjoner av norsk NeTEx-profil i rimelig tid fremover. Ved utfasing av versjon vilend-of-life dato annonseres på forhånd, slik at dataleverandører får tid til å justere datauttrekk i henhold til fortsatt gjeldendeversjon(er) av profilen. Eventuelle endringer som gjør profilen ikke-bakoverkompatibel, vil også resultere i en formell revisjon avHåndbok N801.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1.

2.

3. 4.

5.

Herunder stoppestedsutrustningAutomatisk synkronisering av noen relevante data fra NVDB ( )ikke komplett datasett

AdministasjonsansvarTilgang for å kunne gjøre endringer

4.2. Ansvarsfordeling

Fylkeskommunene og Jernbanedirektoratet, direkte eller gjennom sine admninistrasjonsselskaper og/eller , er ansvarlige for åløyvehaveremelde inn, endre og nedlegge stoppesteder i Norge. Dette inkluderer Quays tilknyttet stoppestedet, koordinater og informasjon omstoppestedets utforming. Innenfor ansvarsområdet ligger også fortløpende vedlikehold av stoppestedsinformasjonen i henhold til kravenebeskrevet i profildokument under vedlegg , slik at dette presenteres korrekt i reisesøk og annen informasjon ut motstops NeTEx profil Norgepublikum.

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

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

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 administrasjonsansvarkan gjøre endringer på stoppestedet. Dette gjelder normalt også per modalitet, det vil si at en dataleverandør som kan endreområ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 byerder flere modaliteter møtes.Et stoppested kan normalt ikke legges ned uten at det er gitt en eksplisitt tidsfrist (eksempelvis en kalendermåned) dersom andreruteoperatø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 typerstoppesteder.

For stoppesteder er det at stoppestedet er etablert i det nasjonale stoppestedsregisteret det tillates at rutedata benytteret absolutt krav førstoppet. 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. atstoppsted-skiltet er permanent fjernet), skal stoppet legges ned i stoppestedregisteret slik at stoppstedet 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 atstoppestedet opprettes / nedlegges i henhold til de prosessene som dette kapittelet beskriver.i stoppestedregisteret

4.4.1. Opprettelse av stoppested

Den part som initierer opprettelsen av et nytt stoppested kontakter vegeier og anmoder om å få utpekt en fysisk lokasjon hvorstoppestedet kan etableres.Når enighet om plassering er oppnådd skal stoppestedet opprettes i stoppestedsregisteret, hvor det automatisk tildeles etID-nummer, samt gis en startdato som viser når stoppestedet vil være fysisk er klart til å tas i bruk.Vegeier oppretter stoppestedet fysisk og gir melding til ansvarlig part for . oppdatering i stoppestedsregisteretStoppestedsadministrator oppdaterer stoppestedsregisteret med informasjon om de parametre de er ansvarlige for. Data hentesogså fra NVDB der disse finnes.

1.

2.

3.

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

Generelt gjelder følgende:

Korreksjon av posisjonen for et StopPlace eller Quay kan foretas uten at det behøver å koordineres med vegeier ellerutløser annen informasjonsplikt.Midlertidig endring av koordinat(er), på grunn av veiarbeid eller liknende, ansees som flytting. Dette skal i stedetikkehåndteres eksplisitt i stoppestedregisteret, eller som , for å unngå unødig endring av berørte rutedata.avvik

Knytte status eller varsel til stoppestedet, slik at publikum kan informeres.Midlertidig eller permanent av et stoppested, på en slik måte at rutedata for linjer som benytter stoppestedet ogsåflyttingmå 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 å legges ned dersomikkefysisk utrustning blir stående permanent.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

5.

1. 2. 3.

1. 2.

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

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

4.4.2. Nedleggelse av stoppested

Et stoppsted nedlegges dersom det ikke lenger skal være mulig for transportmidler å betjene stoppestedet, og det dermed heller ikke skalbenyttes i rutedata.

Stoppestedsadministratoren registrerer sluttdato for betjening av stoppestedet i stoppestedsregisteret og informerer vegeier.Fra sluttdato ansees stoppestedet som .deaktivertVegeier kan etter sluttdato nedlegge stoppestedet fysisk. Dette innebærer å fjerne de fysiske gjenstandene som er plassert påstoppestedet.

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

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

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 og gis nytt navn), skal dette håndteres som enannet sted flytting. Dette foregår prinsipielt som en nedleggelse av et eksisterende stoppested og en opprettelse av et nytt stoppested  - men i omvendtrekkefølge.

Det nye stoppestedet opprettes som beskrevet i kapittel ” ”.Opprettelse av stoppestedDet 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.

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

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1. 2.

1.

2.

1.

2.

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 nyttstoppested. Arbeidsflyten følger derfor de samme beskrivelsene som ovenfor.

Det midlertidige stoppestedet opprettes som i kapittel ” ”.beskrevet Opprettelse av stoppestedStoppestedet som skal flyttes midlertidig nedlegges som beskrevet i kapittel ” ”.Nedleggelse av stoppested

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

Det opprinnelige stoppestedet gjenåpnes (fornyes med ny startdato) og eventuelt ajourføres/oppdateres og håndteres som øvrigsom beskrevet i kapittel ” ”.Opprettelse av stoppestedDet 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 errelevant.

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åndgodkjent av nasjonalt selskap.

Et absolutt kriterium for å holde stoppestedsinformasjonen oppdatert til en hver tid, er at stoppestedsadministratorer vedlikeholder dataene istopptedsregisteret. 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. 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å sidenforrige rapport. Disse vil bli distribuert per epost samt i leverandørportalen til alle som har trafikk til et gitt stoppested, og vil blant annetomfatte:

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 spesifiserehvilke 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 disseRetningslinjene tar utgangspunkt i etablert konvensjon for stoppestedsnavn, hvor eier bestemmer navnet basert på føringer for hvordan detteskal utformes.

4.5.1. Grunnregler

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

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

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 navnanbefales det generelt at ordlyden i navnet følger kutyme for godt språk. Stoppestedsnavn kan benytte lokal målform og dialekt, såfremt deter i henhold til stedsnavngivningsregler (offentlig vedtatt stedsnavn) fra Kartverket. Se også Lov om stadnamn (stadnamslova) §4, offentlige

Som hovedregel skal det da benyttes navn som i Sentralt stedsnavnregister (SSR) har status "v". eiere er pålagt å følge denne loven(vedtak) fremfor navn med status "g" (godkjent).

4.5.2. Struktur

Et stoppestednavn består av en eller flere av følgende elementer:

Type Typekode Beskrivelse Eksempel

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Egennavn E Stoppestedets navn er likt navnet på noe dette ligger i tilknytning til. Skrivemåte bestemmes avkilden til navnet (for eksempel navn på en bedrift eller en skole), men kan modifiseres til bruk iholdeplassnavn 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 RingsakerMarkerMekaniskeVerkstedUniversitetet iTromsø

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årdsroaBuin

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 etnærliggende område har samme navn.

Merk: Brukes alene, i relevante tilfeller skal i stedet Stedsnavn (S) brukes.ikke

DrevjedalenFolldalenStensengdalen

Typenavn T Henviser til et entydig og kjent begrep på/i et sted (S). Følger ikke regler for egennavn, men er engenerell typebeskrivelse ( ).common use

Merk: Brukes alene.ikke

rutebilstasjonkaiskole

Posisjonstillegg P Et navn som beskriver hvor i forhold til egennavn eller sted stoppestedet befinner seg.

Merk: Brukes alene.ikke

sentrumøstE6husnummer

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

E (f.eks. )IKEA RingsakerEP (f.eks. )IKEA Ringsaker parkeringEV (f.eks. )AMFI Narvik MarkveienS (f.eks. )PålerudfløytaSV (f.eks. )Skillebekk TrondheimsveienSO (f.eks. )Ødegårdsroa SnertingdalenST (f.eks. )Stryn rutebilstasjonSP (f.eks. )Stryn rv. 15V (f.eks. )SkredderveienVP (f.eks. )Nesveien 62

Generelt skal stoppestedsnavn som for eksempel «Skolen», «Sykehuset», «Rutebilstasjonen» eller liknende i helhet unngås. Disse navngisfullt 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 etannet stoppested.

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

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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

4.5.4. Gruppering av stoppesteder

Stoppesteder ha felles navn når:skal

Alle stedets stopp ligger innenfor et tydelig avgrenset område, fortrinnsvis med samsvarende fremkommelighet mellom disseStoppestedene er knyttet sammen eller på annen måte er lagt til rette for en naturlig reisemessig samhørighet

Stoppesteder gis felles navn når:bør

Alle stedets stopp ligger fysisk nære i et område med fysisk sammenheng eller annen åpenbar samhørighetF.eks. når stoppene er synlig fra hverandre

Det er en naturlig multimodalitetF.eks busstopp tilknyttet til en lufthavnsterminal eller jernbanestasjon "arver" stoppestedsnavn fra hovedtransporttypens.

Stoppesteder skal normalt ha felles navn når:ikke

Nærliggende stopp ikke har en naturlig tilknytningF.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

RuteinformasjonDestinasjonsinformasjonKommuneinformasjonKontaktinformasjon

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

4.5.6. Forkortelser

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

4.5.6.1. Unntak

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

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

4.5.7. Spesialtegn

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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

4.5.8. Vegkryss

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

kryssvegkryssvegdele

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

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 togatenavn brukes adskilt av en skråstrek (‘/’).

4.5.9. Stoppesteder på geografiske grenser

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 ellerbedrifter, 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 grensekrysning det gjelder.

Riksgrensen E12Riksgrensen rv. 77Lutnes riksgrensen

4.5.10. Navnekonflikt

Ved inkompatibel navngivning eller gjenbruk av navn allerede benyttet på tidligere opprettet stoppested, må nasjonalt selskap i ytterstekonsekvens 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 Men det kan være data som mangler, eller ikke er oppdatert, fra NVDB. Den som er ansvarlig for å administrere etom universell utforming.

stoppested i registeret er derfor pålagt å til enhver tid sørge for at stoppestedet er beriket med korrekt informasjon som gjelder:

Universell utformingBillettautomaterLeskurBenkerToaletterHittegodsAndre 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.

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 skalmodelleres som et StopPlace objekt med to Quay objekter - én i hver retning.

Gruppering av objekter Illustrasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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 aven T-banestasjon.

4.7.2.1. Solli plass - Gruppering av objekter

Bør 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 deunderliggende StopPlaces og peke til den "parent" StopPlace.

4.7.2.2. Solli plass - Illustrasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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-perrongenEn separat Quay for taxi.Tre StopPlace objekter, én for hver transporttype.En "parent" multimodal StopPlace for å samle de tre transporttype-spesifikke StopPlace.

4.7.2.4. Mortensrud T-banestasjon - Illustrasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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.

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åendetogløp har én platform som deles av to spor) og gruppere de fire Quay objektene (det brukes "parentQuayRef" felt for detteformå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 (st

).opPlaceRef

4.7.3.1. Nationaltheatret - Gruppering av objekter

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

4.7.3.2. Nationaltheatret - Illustrasjon

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

4.7.4. Koordinat-plassering

Koordinatpunkter på stoppesteder skal settes på standardisert måte, slik at for alleopprettelse, vedlikehold og feilretting gjøres ensartet elementer i det nasjonale stoppestedsregistert. Dette skal gjøres per Quay, slik at det kan reflekteres til publikum hvor kjøretøyet faktiskstopper, i henhold til retningslinjene beskrevet her. I tillegg vil en generell posisjonsangivelse for stoppestedet (StopPlace) blir automatiskutledet 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 ( ) krysser fortauskant. Der ikke ledelinje finnes skaltaktil merking

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

koordinatet 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 spesifisertskal 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 koordinatet 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 detilfeller hvor perrong er vesentlig lenger enn normal toglengde. I tillegg skal det angis korrekt koordinat per BoardingPosition der dette eroppmerket 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 vedberegning av overgangstider for ulike passasjergrupper. Merk at planlagt / garanterte overganger må leveres som del av rutedata perlinjespesifikke overgang. Andre standardforhold som benyttes ved beregning av reisetider og reisesøk-resultater (f.eks. standardovergangstid ved beregning av reiser i reisesøkemotor eller antatt ganghastighet for deler av en reise) på tvers av leverandør-data vil blioffentliggjort.

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 oppdaterterutedata i sanntid, samt avviksmeldinger. Som del av Kunngjøringsplikten blir det derfor stilt krav om at alle selskaper som har i bruk etsanntidssystem 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 verifisertog prosessert (normalt 1-3 timer). Gjøres det endringer som kun berører spesifikk(e) avgang(er) med behov for kort publikasjonstid, skaldette 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åvirkerpublikums , for eksempel kortvarig flytting av stoppested innenfor ubetydelig avstand på grunn av vedlikehold eller liknende, måtilbudetruteplanleggere skjønnsmessig om det er hensiktsmessig å melde inn avvik.vurdere

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 alledataleverandører med sanntidssystem i bruk pålegges å sende inn, eller på annen måte tilgjengeliggjøre, eksisterende sanntidsdata til det

Det samme gjelder endringer i ruter og tidtabeller etter at fristen for normal innlevering av data har gått ut. I førstenasjonale selskapet. omgang omfatter pålegget å sende inn sanntids- og avviksdata fra allerede implementerte systemer, men alle operatører er sterkt oppfordrettil å innføre sanntidssystem der det er relevant. Ved fremtidig innføring av dette, eller oppgradering av eksisterende, stilles det videre krav tilat ny implementasjon skal støtte , , og i henhold til .SIRI-PT SIRI-ET SIRI-VM SIRI-SX gjeldende spesifikasjon

5.1.1. SIRI

SIRI er en felles-europeisk standard , og er det formatet sanntids- ogbasert på WS PubSub-protokollen (Web service publish / subscribe)

SIRI-protokollen tillater ulike varianter for levering av samme type data ("dialekter" av standarden). For å unngå at detimplementeres leverandøravhengige modeller for datainnsendelse, vil det i parallell med innfasing av eksisterende sanntidsdata bliutarbeidet en felles norsk profil basert på versjon 2.0 av SIRI. Dette blir tilsvarende som med for rutedata, og NeTEx profil Norge på sikt skal den norske profilen for sanntidsdata publiseres som en del av Håndbok N801. Det vil si at etter en samkjøringsperiodevil leverandører med avviks- og sanntidsdata også bli pålagt å levere disse i henhold til profilens spesifikasjoner.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1. 2.

3.

4.

1.

2.

3.

avviksdata skal sendes inn på. I praksis vil dette bli administrert ved at nasjonalt selskap registrerer et abonnement ( ) persubscriberuteselskap, som ruteselskapene deretter sender oppdateringer ( ) til.publish

Innsendingen kan grovt deles i følgende faser:

SIRI Production Timetable (PT) sendes inn ved endringer som skjer tidligst neste døgn.SIRI Estimated Timetable (ET) sendes fortløpende, men benyttes kun for endringer som gjelder inneværende døgn.

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

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

For avviksmeldinger skal benyttes.SIRI Situation Exchange (SX)

5.1.1.1. NTP

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

5.1.2. Presedens for data

I tilfeller hvor nasjonalt selskap mottar data for samme linje over flere kanaler, vil dette håndteres slik at innsendte rutedata vil bli overstyrt avendringer med kort horisont sendt som SIRI-PT. Ved mottak av fortløpende endringer som SIRI-ET vil dette overstyre rutedata og eventuelletidligere endringer mottatt som SIRI-PT. Den samme overstyringen gjelder også avviksmeldinger mottatt som SIRI-SX.

Kort oppsummert vil innsendte data overstyres på følgende måte:

NeTEx (langsiktige rutedata)  (kortsiktige rutedata) / / (sanntids- og avviksdata)    <     SIRI PT      <     SIRI ET VM SX

5.1.2.1. Datagyldighet

Rutedata mottatt som prosesseres og publiseres fortløpendeNeTEx PublicationDelivery Endringer som ligger lenger frem i tid enn normalt prosesseringsvindu (1-3 timer) sendes inn som nytt datasettkanDet må alltid sendes som , eventuelle tidligere rutedata for gyldighetsperioden vil bli overskrevet!komplett datasett

Mindre endringer i datasettet som gjelder mer enn et døgn frem i tid sendes inn som ,kan SIRI-PTDette vil overstyrer eksisterende rutedata

Fortløpende endringer og avviksdata som gjelder inneværende driftsdøgn sendes inn som / / skal SIRI-ET VM SIRI-SXVed mottatte endrings- og avviksmeldinger vil disse overstyre eksisterende rutedataalltid

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1. 2. 3.

Generell informasjon NeTExInnhold

ForordInnledning

ReferanserUtveksling av informasjon

Datainnsending i CompositeFrameDatainnsending som enkeltvise frames

GeneraliseringVersjonering

Versjon for profilVersjon for dataelementer

Elementer som skal versjoneresversion="any"Versjonering i referanser

Gyldighet for dataelementerDataelementer som kan overstyre gyldighet (ValidityCondition)

KonvensjonerUtforming av identifikatorer

Faste identifikatorerCodespace

KardinalitetTypebeskrivelseBruk av Enumeration

Definisjoner

Forord

Harmonisering av måter rutedata utveksles på mellom diverse systemer er essensiell for:

Entur AS på vegne av Jernbanedirektoratet

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

reisende

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

operatørene

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

tredjepartsleverandører

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

Innledning

NeTEx (CEN TS 16614-1, 16614-2 og 16614-3) er en CEN-standard som definerer dataformat og beskrivelse av tjenester for utveksling avruteinformasjon, tidtabeller og andre relevante data for kollektivtrafikk. Denne standarden er basert på referansemodellen forkollektivtransport, Transmodel (EN 12896), samt referansemodellen for permanente objekter påkrevd for tilgang til kollektivtransport, IFOPT (

, EN 28701).Identification of Fixed Objects in Public Transport

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

Nettverkstopologi (CEN TS 16614-1)Ruteplan (CEN TS 16614-2)Tariff-informasjon (CEN TS 16614-3)

NeTEx ble utarbeidet av CEN / TC278 / WG3 / SG9 ledet av Frankrike. Siste del av formatet ble publisert i 2015. Formatet er laget som ensammenstilling av behov og krav som finnes hos diverse leverandører av offentlige transport-tjenester i Europa, blant annet ERA (EuropeanRail Agency) og UIC (International Union of Railways).

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

NeTEx er et omfattende dataformat ment for å beskrive konsepter innenfor kollektivtrafikk-data på ulike måter, og i mange tilfeller vil detvære deler av spesifikasjonen som er overflødig i forhold til behovet. Ved faktisk implementasjon bør det derfor lages et uttrekk avnødvendige objekter, som utgjør en såkalt . En slik profil skal brukes for å spesifisere hvilke deler av NeTEx-formatet som erNeTEx profilforventet at utveksles mellom systemer i en gitt kontekst.

Dette dokumentet beskriver NeTEx profil Norge for utveksling av stoppesteds- og rutedata mellom eksterne aktører og sentrale systemersom Nasjonalt Stoppestedsregister og Rutebanken, og denne profilen er utarbeidet med bistand fra NeTEx arbeidsgruppen i CEN (Comité

, den europeiske komitè for standardisering).européen de normalisation

For å redusere kompleksiteten er profilen delt opp i flere deler:

Gjenbrukbare komponenter ( )frameworkInformasjon om stoppesteder ( )stopsInformasjon om transportnettverket ( )networkInformasjon om ruteplan ( )timetableInformasjon om takst og billettering ( ) ( )fares norsk profil klargjøres i senere versjon

Hver del beskriver dataobjekter som hører til en gitt funksjonalitet. I tillegg er det skilt ut en felles del, denne beskriver de grunnleggendeobjektene som gjenbrukes på tvers av hele profilen.

Referanser

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

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

Utveksling av informasjon

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

PublicationDelivery

Informasjon skal leveres som én XML-fil per linje, pakket som ZIP i en flat struktur (uten underkataloger). Det er teknisk mulig å levere hverlinje for seg, pakket i en egen ZIP-fil, såfremt samtlige dataobjekter som benyttes av linjen er definert innenfor dennes PublicationDelive

. Men for å unngå overskrivningsproblematikk, samt sikre god håndtering av dataendring/sletting, er det at ZIP-filen   inry sterkt anbefalt alltidneholder komplett datasett for samtlige linjer. Da skal felles-objekter som brukes på tvers av linje-XMLene - for eksempel organisasjonsdata,

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

stoppestedstilknytning og kalender-objekterer - være definert i en eller flere fellesobjekt-filer (disse  prefikses med underscore, "må _filnavn.x"), slik at det unngås redundans for objekter som må være unike for datasettet.ml

Inne i   defineres det som består av et sett med  , hvor hver frame samler alle relevantePublicationDelivery <dataObjects> Framesobjekter i én gruppe og spesifiserer felles gyldighetsbetingelser, f.eks. gyldighet og versjon. Denne mekanismen støtter inkrementelloppdatering av individuelle objekter i tilfeller hvor relasjonene mellom objektene ikke blir endret, og legger til rette for sporing i tilfeller hvor feileller spørsmål må avklares ned på objekt- eller gruppe-nivå. 

PublicationDelivery tillater bruk av vilkårlig antall frames, fra én til mange, og samme type frame kan brukes flere ganger. Men genereltanmodes det om å benytte færrest mulig frames, slik at grupperingen innen samme   er hensiktsmessig (PublicationDelivery unngå å

). Objekter som naturlig hører sammen, dvs. har samme versjon og gyldighet, skal samles i samme"wrappe" objekter inn i egne framesframe.

Datainnsending i CompositeFrame

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

Hver PublicationDelivery må inneholde følgende to obligatoriske felter:<PublicationTimestamp> [tidspunkt for datauttrekk] </PublicationTimestamp>

<ParticipantRef> [codespace for datainnsender] </ParticipantRef>

XML eksempel for ligger (PublicationDelivery i Rutebankens offisielle GitHub-repository https://github.com/rutebanken/profil).e-norway-examples

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Datainnsending som enkeltvise frames

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Generalisering

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

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

Versjonering

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

Spesifisere hvilken versjon av NeTEx-profilen som brukes Medfører at data håndteres korrekt dersom det sendes i henhold til eldre (men fremdeles støttet) versjon

Bearbeide utvekslede data på korrekt måteFortelle klienten om etterspurt versjon ikke lenger er støttet

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

Versjon for profil

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

Profil-versjon skal settes i -attributt for XMLens rotnode, og format for versjon av profil er som følger:version  PublicationDelivery 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

[NeTEx XSD-versjon]:[Profilnavn]:[Profil-versjon]

NeTEx xsd-versjon er et tall som angir hvilken versjon av NeTEx XSD som benyttes (format )X.YNO-NeTEx-<profilnavn> er profilnavn med en av predefinerte verdier:

stopsnetworktimetablefare

Profil-versjon er et som angir hvilken versjon av Norsk NeTEx-profil som benyttes (format )tall X.Y

Eksempler:

Identifikator Betydning

version="1.08:NO-NeTEx-stops:1.2" Følger NeTEx XSD versjon 1.08 og inneholder data i henhold til norsk stops-profilversjon 1.2

version="1.08:NO-NeTEx-networktimetable:1.2" Følger NeTEx XSD versjon 1.08 og inneholder data i henhold til norsk -networktimetableprofil versjon 1.2

Ved oppdatering av NeTEx vil formatet normalt være bakover-kompatibelt, og det samme vil forsøkes å gjøre med profilen, slik at en vilkårligklient som benytter tidligere versjon av NeTEx (både XSD og norsk profil) også skal kunne utveksle data med tjenester som kjører med nyereversjon(er).

Når ny versjon av NeTEx publiseres, vil det likevel normalt bli laget og publisert en oppdatert versjon av denne profilen. 

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

Versjon for dataelementer

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

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

Elementer som skal versjoneres

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

Følgende versjoneringsregler presiseres spesielt:

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

version="any"

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

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

Versjonering i referanser

Det stilles krav om  -attributt for referanser til et unikt objekt definert innenfor samme  , det vil si at vedversion PublicationDeliveryreferanse til et dataelement som er definert i den sammen filen må versjon oppgis. Referanse til   skal derimot oppgis uteneksterne objekterversjon.

Merk at ved å referere til et objekt med både og , gjøres gjeldende konsistensvalidering internt for XML-filen. Det vil si atid versiondet et objekt i filen med samme id og versjonsnummer. (Dette gjelder tilsvarende ved versjonsløse objekter, her måmå eksisterereferansen eksplisitt oppgis med .)version="any"

Ved referanse til eksterne objekter (f.eks. ved hjelp av id for stoppested i det nasjonale stoppestedsregisteret, må derfor -attversionributtet utelates fra referansen for å gi gyldig XML.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Ved å oppgi version-attributt i en referanse blir denne referansen validert mot ID + VERSION for eksisterende objekt innenfor gjeldende P. Fordi XML i ved Schema-validering kun støtter streng-likhet, er det ikke mulig å benytte   forublicationDelivery version="any"

referanse til objekter definert med eksplisitt versjonsnummer ( ). Hvisselv om dette etter standarden betyr referanse til siste gyldige versjondet finnes flere mulige versjoner av et objekt definert   i filen, og man skal referere til det siste gyldige, brukes derfor referanse   versinternt utenion-attributt. Altså på samme måte som ved referanse til eksterne objekter.

Gyldighet for dataelementer

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

Dette settes gjennom ValidityCondition(s), som definerer gyldigheten for objektene i datainnsendingen ( ), og skalen linje eller et sett av linjergjøres på en av følgende måter:

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

Dataelementer som kan overstyre gyldighet (ValidityCondition)

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

Overstyrende ValidityCondition(s) settes per dataobjektet, for å eksplisitt angi annen gyldighet enn den som implisitt ville vært arvetfra frame (alternativt arvet fra overliggende CompositeFrame)Overstyrende ValidityCondition(s) må være innenfor rammene av arvet gyldighet, det vil si kan kun være strengere (gjelde forkortere tidsperiode)

Slik overstyring er støttet for følgende objekter:

Networklinesorganisations (Authority, Operator)routesserviceLinksjourneyPatterns

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

Konvensjoner

Utforming av identifikatorer

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

[codespace]:[type]:[id]

codespaceCodespace som representerer  definert for frame ( )provider namepace se codespacestype Dette skal være lik datatypens navn (eksempel , , ,  osv.)Network Line StopPlace QuayidUnik id for en gitt objekt-type. Merk at i ID-strengen godtas tall, store/små bokstaver (A-Z/a-z), bindestrek (-) og/eller understrekkun(_) som gyldige tegn.

Objekt ID eksempel

Line RUT:Line:ABC

Route RUT:Route:3434

RoutePoint RUT:RoutePoint:43423342-3424

Faste identifikatorer

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1.

Det er sterkt anbefalt at alle dataobjekter som beskriver uendrede rutedata-forhold, som for eksempel Line, Route, ServiceJourney osv. ogsåbenytter faste identifikatorer på tvers av leveranser, selv om det gjøres mindre endringer i rutemønstre eller tider for ankomst og avgang. Kunda vil det være mulig å opprettholde gjennomgående historikk for like data, samt gi eksterne brukere muligheten til å kunne forholde seg tilfaste identifikatorer på tvers av leveranser. Dette gjelder også selv om elementene nødvendigvis ikke er identiske over tid, så lenge disse ernaturlig å koble sammen. For eksempel vil det være relevant å opprettholde identifikatorer for periodevise sesongruter, for en linje hvor detendringer av rutemønster eller hvor avgangstidpunktet er forskjøvet med noen minutter.

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

Codespace

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

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

Kardinalitet

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

0: 1 - Valgfri - Kan sende inn null eller maksimalt ett av elementet0: * - Valgfri - Kan sende inn null, ett eller flere av elementet

 1: 1 - Obligatorisk - Må sende inn ett, og bare ett, av elementet1: * - Obligatorisk - Må sende inn ett eller flere av elementet

Typebeskrivelse

Hvert objekt er beskrevet med følgende tabell:

<Arvehierarki>

Attributt/Element 

Navn Type Kardinalitet Beskrivelse

Arvehierarkiet beskrives på følgende måte:

Class < ParentClass < ParentClass < ... < ParentClass

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

DataManagedObject < EntityInVersion < Entity

Navn Type Kardinalitet Beskrivelse

attr responsibilitySetRef ResponsibilitySetIdType 1: 1 Peker til roller og ansvarsområder knyttet til STOP PLACE, BOARDING ZONEeller ACCESS ZONE

elem keyList KeyList 0: 1 Et sett med nøkkel-verdi par som beskriver tilleggsegenskaper for objektet (LINE,STOP PLACE, BOARDING ZONE, PLANNED STOP POINT osv.), og som kanbrukes i tredje-parts systemer: billettering, reiseinformasjon osv.

elem Extentions ExtentionStructure 0: 1 Utvidelseselement for data som ikke er definert av NeTEx. N.B.: Brukes kun etter godkjennelse fra arbeidsgruppen dersom strengtnødvendig å legge til nye datafelter som ikke finnes i NeTEx-standarden (f.eks.hvis behov i intern datautveksling).

elem BrandingRef BrandingRefStructure 0: 1 Referanse til varemerke (f.eks. Ruter, ATB, osv)

Bruk av Enumeration

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

Det finnes to måter å bruke Enumeration på:

Enkel Enumeration

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

1.

2.

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

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

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

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

Definisjoner

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

Begrep Definisjon

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

AccessEquipment

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

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, thoseneeding 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. May be refined as either a ROAD ADDRESS, a POSTAL ADDRESS or both.

AddressablePlace

A PLACE which may have an address.

Allowed LineDirection

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

AlternativeName

Alternative name for the entity.

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

AssistanceService

Specialisation of LOCAL SERVICE for ASSISTANCE providing information like language, accessibility trainedstaff, etc.

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

AvailabilityCondition

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

BoardingPosition

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Branding An arbitrary marketing classification.

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

CommonSection

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.

CompoundTrain

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.

CoupledJourney

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.

CrossingEquipment

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 ManagedObject

An ENTITY in VERSION that can be associated with a RESPONSIBILITY SET that describes who has responsibility formanaging 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: weekday inschool holidays.

Day TypeAssignment

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.

DefaultConnection

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 level asspecified by a TOPOGRAPHIC PLACE, STOP AREA or SITE ELEMENT. It may be restricted to a specific MODE orOPERATOR or only apply in a particular direction of transfer, e.g. bus to rail may have a different time for rail to bus.

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

DestinationDisplay

An advertised destination of a specific JOURNEY PATTERN, usually displayed on a headsign or at other on-boardlocations. This information can be updated dynamically as the journey progresses, in particular when crossing VAIpoints.

DestinationDisplay Variant

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

Direction A classification for the general orientation of ROUTEs.

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. May be a door, barrier, gate or other recognizable point of access.

EntranceEquipment

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.

EquipmentPlace

Designated Place within a SITE for a locating EQUIPMENT.

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

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Flexible Line 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 inheritance 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 inheritance.

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 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 StopPlace

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 or flexiblequays). Some FLEXIBLE SERVICE also use regular STOP PLACEs for their stops. When assigned to a SCHEDULEDSTOP POINT the corresponding SCHEDULED STOP POINT is supposed to be a ZONE (the centroid point of theZONE being the SCHEDULED STOP POINT).

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

General GroupOf Entities

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

Group OfEntities

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 OfOperators

A group of OPERATORs having for instance common schemes for fare collection or passenger information.

Group ofServices

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

Group Of StopPlaces

A grouping of STOP PLACEs which will be commonly referenced for a specific purpose. The term corresponds tospecialization of standard Transmodel concept GROUP OF ENTITIES.

Hail And RideArea

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.

HeadwayInterval

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

HeadwayJourney Group

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 passenger information.

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

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

JourneyFrequencyGroup

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

JourneyHeadway

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, opening time of the theatre, etc.).

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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 PartCouple

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. Thefirst point of a JOURNEY PATTERN is the origin. The last point is the destination.

Journey PatternRun Time

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 PatternWait Time

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 RunTime

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

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

Journey WaitTime

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 with view to the overall description of a network, describing a connectionbetween two POINTs.

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

LuggageService

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 be usablefor passenger or driver information.

NoticeAssignment

The assignment of a NOTICE showing an exception in a JOURNEY PATTERN, a COMMON SECTION, or a VEHICLEJOURNEY, possible specifying at which POINT IN JOURNEY PATTERN the validity of the NOTICE starts and endsrespectively.

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

OperatingPeriod

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.

OrganisationPart

A named subdivision of an ORGANISATION.

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Parking Area Area within a PARKING.

ParkingCapacity

Capacity of a PARKING.

ParkingProperties

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, cyclists orother 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 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 a entity in a target layer:  e.g. POINT, LINK, LINKSEQUENCE, 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, Post code and other descriptors.

Projection An oriented correspondence - of the shape of an ENTITY on a source layer, - onto a 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 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 within itsparent QUAY.

RampEquipment

Specialisation of PLACE ACCESS EQUIPMENT for RAMPs (provides ramp attributes like length, gradient, etc.).

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

Rough Surface 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.

RhythmicalJourney Group

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.

SanitaryEquipment

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

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Scheduled StopPoint

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.

ServiceCalendar

A collection of DAY TYPE ASSIGNMENTs.

ServiceExclusion

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

Service FacilitySet

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 equipped with 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 different STOPPOINTs.

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.

ShelterEquipment

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.

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

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 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 leave vehiclesor prepare their trip. A STOP PLACE will usually have one or more well-known names.

Stop PlaceSpace

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

Stop Point InJourney Pattern

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.

TemplateService Journey

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.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TicketingEquipment

Specialisation of PASSENGER EQUIPMENT for TICKETING

Ticket ValidatorEquipment

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.

TimetabledPassing Time

Long-term planned time data concerning public transport vehicles passing a particular POINT IN JOURNEY PATTERNon 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.

TopographicPlace

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.

TrainComponent

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

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

Train InCompoundTrain

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.

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

TransferDuration

Times taken to make a TRANSFER.

Type Of Service Classification of a Service.

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

ValidityCondition

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

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 or JOURNEYPATTERN LAYOVER.

Vehicle JourneyRun Time

The time taken to traverse a specified TIMING LINK IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. Thisgives 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 for differentTIME DEMAND TYPES.

Vehicle JourneyWait Time

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.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

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

WaitingEquipment

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.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Profildokumenter NeTEx

Dokumenter

frameworkstopsnetworktimetablefare

Endringslogg

Dato forsistendring

Profil-dokument Endring Gjeldendeversjon

07 Mar2018

GenerellinformasjonNeTEx, framework,

, network, stops

timetable

Full eksport (vedlegg Håndbok N801) v1.2

05 Mar2018

Generellinformasjon

, NeTEx, framework netwo

, rk  timetable

Generell informasjon:

Oppdatering av versjonsreferanser (NeTEx XSD v1.08 og norske profiler v1.2)

framework:

Fjernet henvisning til default-verdi for ikke-obligatoriske felter (skal oppgis, og håndteres, eksplisitt)Ny beskrivelse for felter i OrganisationPart (var tvetydig oversatt)Gjort det  å oppgi minimum Email, Phone eller Url i ContactStructurepåkrevd

For CustomerServiceContactDetails er Url gjort , da dette feltet kreves utfylt avpåkrevdenkelte karttjenester som konsumerer eksporterte data

Liste lovlige verdier (enumerations) for DayType  PropertyOfDay  DayOfWeek og DayType  PropertyOfDay  WeeksOfMonthGjort felt Distance ikke-obligatorisk for LinkSequence, da dette er data som i liten grad leveres (ogkan utledes basert på kartinformasjon når relevant)Lagt til ikke-påkrevd felt AlternativeTexts for å støtte oversettelser av Notice-tekstLagt til mulig NameType "Label" for AlternativeName (dersom særskilt håndtering av ikke-offisieltnavn er nødvendig av publikumshensyn)Formalisert krav om TimeZone for lokaltid i Locale (de facto standard allerede) og fjernetikke-påkrevde felter TimeZoneOffset og SummerTimeZoneOffset da disse ikke vil bli hensyntatt 

stops:

( )kun oppdatering av versjonsnummer

network:

Spesifisere bruk av ForAlighting og ForBoarding ved første og siste StopPointInJourneyPatternLagt til ikke-påkrevd felt Distance for ServiceLink (kan benyttes ved sanntidsovervåkning avkjøretøy)Lagt til ikke-påkrevd felt ShortName for Line (kan benyttes for navn publikum kjenner linjen under)Endret kardinalitet for Line > PublicCode (tidligere påkrevd element gjort ikke-påkrevd, da det er

 mange dataleverandører som opererer uten slik kode)

Timetable

Fjernet henvisning til default-verdi for ikke-obligatoriske felter (skal oppgis, og håndteres, eksplisitt)PrivateCode som ikke-påkrevd felt på VehicleJourney for dataleverandør-intern ID (f.eks.tognummer/turnummer)

v1.2

13 Sep2017

GenerellinformasjonNeTEx, framework,

, network, stops

timetable

Full eksport (vedlegg Håndbok N801) v1.1

12 Sep2017 

GenerellinformasjonNeTEx, framework,

, stops, network

timetable

Alle profildokumenter:

Konsolidering av lenker

Generell informasjon:

Utdypninger/presiseringer rundt bruk av versjonPresisering av format for identifikatorerRevidert definisjonsliste ihht. endring av profildokumenter (lagt til nye / fjernet utdaterte objekter)Presisering av hvordan fellesobjekt-fil må benyttes (i avsnitt "Utveksling av informasjon")

v. 1.1

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

framework:

Endret kardinalitet for Point > Location (tidligere påkrevd element gjort ikke-påkrevd i de tilfeller hvor)geografisk posisjon kan utledes fra projection eller knytning til annet lokalisert objekt

Rettet feil kardinalitet for Zone < GroupOfPoints < GroupOfEntities <DataManagedObject: Implementasjonen ( tillater kun 0 eller 1 av NeTEx-XSD) gml:Polygon ( nulikkel til flere) for ZoneLagt til utstyrstype "skilt": GeneralSign < SignEquipment < PlaceEquipment < Equipment <DataManagedObject

Stilles eksplisitte krav til modellering av stoppestedsskilterEndret anbefalt modellering av ganglenke til frittstående (fremfor NavigationPaths sompathLinksbestår av pathLinks) for objekter som støtter dette, da NavigationPath kan utledes dynamisk fra

.disseFjernet redundant og ikke-pålagt felt "AllAreasWheelchair" for PathLink / PathJunction, dette kanutledes av AccessibilityAssessment MobilityImpairedAccess WheelchairAccess ( ).pålagt verdiLagt til placeEquipments (= ) for SiteequipmentPlaces minus Location-angivelseLagt til localServices under Site (knytning var tillatt, men manglet eksplisitt spesifisering av hvorobjektet skulle defineres)Endret abstrakt type WaitingEquipment til korrekt SiteEquipment-datatype WaitingRoomEquipment(implementerbar, arver WaitingEquipment)Justering av (tidligere delvis påkrevde) datafelter for Organisation (inkl. spesifikt Authority/Operator)Lagt til felt for mulig eksplisitt PrivateContactDetails for OrganisationAlternativeName justert

Lang og NameType satt som felterpåkrevdeNameType "other" ikke lenger gyldig verdi ( )upresis betegnelseFjernet ikke-påkrevde felter TypeOfName, ShortName, QualifierName og Abbreviation (ikke

)tatt i brukLagt til OperatingPeriodRef som mulig referanse i DayTypeAssignmentLagt til PrivateCode som ikke-påkrevd felt for Equipment, for å kunne håndtere utstyrsintern-koder/-ID som ikke skal ut i publikumstjenesterRettet oversettelse (klargjøre begrepsbruk) for TransportMode "cableway" og "funicular"Presisering av dataformat for språk, språkkode, landkode og valuta (tidligere henvisning var kun tiloverordnede standarder)Lagt til TransportMode coach, med submodes, på grunn av dataleverandørers behov for å kunneskille langdistanse-buss fra lokal- og regionsbussLagt til notices og noticeAssignments for TimetableFrameLagt til groupsOfStopPlaces for SiteFrameLagt til TransportMode "taxi" (med TaxiSubmode)Lagt til versionRef-attributt som kan brukes for eksternt objekt i spesifikk versjonLagt til ikke-påkrevd additionalNetworks (definisjon av sekundær-nettverk) for ServiceFrameFjernet felt TypeOfNoticeRef (vil ikke implementeres), gjort felt Text (må ha innhold for atpåkrevdNotice skal kunne vises til publikum) og gjort tidligere påkrevd felt PublicCode til ikke-påkrevd

stops:

Erstattet (ikke-påkrevd) felt PlateCode med (ikke-påkrevd) felt PublicCode for QuayLagt til ikke-påkrevd element TransferDuration for PathLinkLagt til ikke-påkrevd element ParkingParkingVehicleType for Satt alle tidligere påkrevde datafelter for Parking som ikke-obligatoriske pga manglendedatagrunnlag pdd.Fjernet redundant verdi "covered" for Parking ParkingLayout, konseptet modelleres i stedetgjennom å sette Parking ) Covered til "covered" eller "indoors" (generell verdi for SiteElementLagt til ikke-påkrevd element PublicUse for objekter av type SiteElementLagt til PrivateCode som ikke-påkrevd felt for Quay, til bruk for internkode når relevantPresisering av dataformat for land- og områdekode (tidligere henvisning var kun til overordnedestandarder)Lagt til GroupOfStopPlacesLagt til "country", "region", "interregion" og "municipality" som tillatte verdier forTopgraphicPlaceType

network:

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Korrigert feil i organisasjons-referanse for Network (element-navn AuthorityRef var beskrevet meddatatype "TransportOrganisationRef")Lagt til knytning mellom Lines og Networkpåkrevd

Network arver fra GroupOfLines og kan refereres direkte v.h.a. ,RepresentedByGroupRefalternativt kan Network deles inn i ytterligere GroupOfLines som refereres eksplisitt hvishensiktsmessig

Presiseringer i Presentation, samt fjernet redundante felter ColourName og TextColourNamePresisiering til bruk DestinationDisplayRef, er som minimum for førstepåkrevdStopPointInJourneyPattern (samt for alle påfølgende hvor DestinationDisplay )endresFjernet datatype Connection, kun brukt i interchange hvor alle felter allerede kan utledes (fysiskovergang beregnes og/eller modelleres med PathLink)Satt Name som element for Network og GroupOfLinepåkrevd

Nødvendig for å kunne vise (den påkrevde) referansen i publikumstjenesterJustering av datastruktur for Interchange

Fjernet datafelt for overgangstid, da dette blir utledet ved reisesøkogLagt til felt for Planned og Advertised, for publikumsinformasjonLagt til felt for MaximumWaitTime, for presis beregning av mulige overganger

Justering av krav til StopAssignment-typene slik at profilen avspeiler teknisk skjemavalideringGjort felt TransportSubmode  p.g.a. behov for mer presise data slik atpåkrevdpublikumsinformasjon blir korrekt samt unngå utfordringer med (implisitt) overstyringFjernet felt PublicCode for DestinationDisplay (ikke i bruk for linjenummer, da dette vil utledes fraLine)Fjernet noticeAssignment fra Line, StopPointInJourneyPattern og TimingPointInJourneyPattern, forentydighet skal dette legges sammen med notices direkte under ServiceFrameLagt til ikke-påkrevd felt RequestMethod for StopPointInJourneyPatternLagt til ikke-påkrevde datasett BookingArrangements for StopPointInJourneyPatternLagt til ikke-påkrevd felt ExternalLineRef for Line

timetable:

Lagt til ikke-pålagte felter ArrivalDayOffset / DepartureDayOffset for TimetabledPassingTime (for åkunne vist at ankomst/avgang skjer senere dato enn reisen startet)- Relevant i tilfeller hvor det blir lite hensiktsmessig / unødvendig komplekst å presisereankomst-/avgangstid gjennom meta-informasjon for OperatingDay

kardinalitet for PassingTimes (per VehicleJourney /Tidspunkt for avgang/ankomst er påkrevd, ServiceJourney) er presisert i henhold til detteGjort både TransportMode og TransportSubmode  ved eventuell overstyring, da data ipåkrevddisse to feltene må henge logisk sammenPresisere bruk av kalenderobjekter i en ServiceCalendar vs frikopletGjort felt FromDate og ToDate ved innsending av ServiceCalendar for å sikre entydig brukpåkrevdav dette container-objektetFjernet noticeAssignment fra Journey og Interchange, da dette er mer hensiktsmessig å frikople ogsammenstille med notices direkte under TimetableFrameLagt til ikke-påkrevd felt ExternalVehicleJourneyRef for Journey

05 Jan2017 

framework, , stops

, networktimetable

Initiell eksport (vedlegg Håndbok N801) v. 1.0

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

framework

Innhold

FramesDatabetingelser

FrameDefaultsCodespace

Spesifikke komponenterResourceFrameSiteFrameServiceFrameServiceCalendarFrameTimetableFrame

KomponenterAbstract Types

EntityEntityInVersionDataManagedObjectKeyListTypeOfValueGroupOfEntitiesAddressAssignmentEquipment Details

EquipmentPassengerEquipmentActualVehicleEquipment

PlaceFacilitySetLinkLinkSequence

PointInLinkSequenceLinkInLinkSequence

OrganisationProjection

Basic TypesAlternativeNameContactStructureDeliveryVariantGeneralGroupOfEntitiesGroupOfPointsLocaleLanguageUsageLocationMultilingualStringProjection Types

PointProjectionZoneProjection

Address TypesPostalAddressRoadAddress

ServiceFacilitySetVehicleVehicleTypePassengerCapacity

Accessibility TypesAccessibilityAssessmentAccessibilityLimitationSuitability

Geographical TypesPointZonePolygon

Polygon-sturkturOrganisation Types

OperatorAuthorityOrganisationPart

VersjonGjeldende versjon for er: framework   v1.2   (sist endret ) 07 Mar 2018

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

DepartmentGroupOfOperatorsBrandingDataSource

Equipment TypesAccessEquipment

EntranceEquipmentPlaceLightingRampEquipmentRoughSurfaceCycleStorageEquipment

PassengerEquipmentSanitaryEquipment

SiteEquipmentWaitingRoomEquipmentShelterEquipment

TicketingEquipmentTicketingEquipmentTicketValidatorEquipment

SignEquipmentGeneralSign

LocalServiceAssistanceServiceLuggageService

Train TypesCompoundTrainTrainInCompoundTrainTrainTrainSizeTrainComponentTrainElement

Notice TypesNotice

AlternativeTextNoticeAssignment

Calendar TypesDayTypePropertyOfDayTimebandDayTypeAssignmentOperatingDayOperatingPeriod

TimingJourneyWaitTimeJourneyPatternWaitTimeJourneyRunTime

TimingLinkJourneyPatternRunTimeJourneyHeadway

ConstraintsCheckConstraintCheckConstraintDelay

Validity TypesValidityConditionAvailabilityConditionValidBetweenValidityTrigger

Transport Modes

Dette dokumentet er en del av NeTEx profil Norge og beskriver de og som er brukt for utvekslingfelles komponenter generiske konsepterav kollektivtransport-data over NeTEx-formatet. 

Frames

Det er definert til sammen 8 forskjellige frames i NeTEx:

- frame for å beskrive vilkårlige NeTEx-objekter uten å pålegge bestemt struktur. General Frame Brukes i v1.1 av norsk profil.ikkeResource Frame - frame for felles objekter, f.eks. organisasjoner, ansvarsfordeling, utstyr osv.Site Frame - frame for informasjon om stoppesteder og POI.Service Frame - frame for informajson om nettverk - linjer, ruter, planlagte stopp osv.Service Calendar Frame - frame for kalendar-informasjon - dagtyper, operasjonelle dager, deres relasjoner osv.Timetable Frame - frame for timeplan for en reise - avganger, ventetid osv.

- frame for informasjon om infrastruktur - garasjer, veier, kryss osv. Infrastructure Frame Brukes i v1.1 av norsk profil.ikke

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

- frame for billetteringsinformasjon. Fare Frame Brukes i v1.1 av norsk profil.ikke

I tillegg finnes det en , som kan brukes for å gruppere andre frames, såfremt disse har lik ValidityCondition (arves implisittComposite Framefra CompositeFrame). Det er ikke satt noen krav til rekkefølge eller avhengighet mellom frames.

Databetingelser

Generelt for profilen gjelder at alle definisjoner skal gjøres så generelle som mulig, og settes på så høyt nivå som mulig. Dette angår isærdeleshet:

ValidityConditionFrameDefaultsCodespace

I tilfeller hvor mer spesifikke instanser avviker fra den generelle definisjonen satt høyt i hierarkiet, løses dette ved å sette en overstyrendedefinisjon for den eller de komponentene det gjelder lenger ned i strukturen.

FrameDefaults

Her defineres det felles default verdier. Følgende elementer er tillatt:

Element Type Beskrivelse

DefaultCodespaceRef CodespaceRef Referanse til default codespace

DefaultDataSourceRef DataSourceRef Referanse til default datasource

DefaultLocale Locale Default locale beskrivelse

DefaultLocationSystem xsd:normalizedString Default koordinat system (hvis oppgitt skal denne være "EPSG:4326", uavhengig avDefaultLocationSystem krever Stoppestedsregisteret at koordinater sendes inn WGS84

)latitude/longitude

DefaultSystemOfUnits xsd:normalizedString Default metroisk system (skal være SiMetres)

DefaultCurrency CurrencyType 3-bokstavs valuta kode i henhold til , f.eks. NOK eller SEKISO 4217

Codespace

Codespace brukes for å sikre at objektene som er definert i frame er fortsatt unike når de sammenstilles med data fra andre leverandører.Hver codespace er en URL med tilhørende forkortelse og beskrivelse:

<Codespace> <Xmlns>RUT</Xmlns> <XmlnsUrl>http://www.rutebanken.org/ns/ruter</XmlnsUrl> <Description>Ruter</Description></Codespace>

Disse codespaces blir administrert av Rutebanken, for å sikre deres at unik ID tildeles den enkelte dataleverandør. Eksisterende codespaceser listet i .eget dokument

Spesifikke komponenter

Her listes det opp struktur for hver frame samt hvilke objekter som forventes i hver frame

ResourceFrame

ResourceFrame < DataManagedObject

Navn Type Kardinalitet Beskrivelse

dataSources DataSource 0: * Container for objekterDataSource

Codespace eksempel

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

typesOfValue TypeOfValue 0: * Container for objekterTypeOfValue

organisations Organisation 0: * Container for objekterOrganisation

groupsOfOperators GroupOfOperators 0: * Container for objekterGroupOfOperators

equipments Equipment 0: * Container for objekterEquipment

vehicleTypes VehicleType 0: * Container for objekterVehicleType

vehicles Vehicle 0: * Container for objekterVehicle

schematicMaps SchematicMap 0: * Container for objekterSchematicMap

groupsOfEntities GeneralGroupOfEntities 0: * Container for objekterGeneralGroupOfEntities

SiteFrame

SiteFrame < DataManagedObject

Navn Type Kardinalitet Beskrivelse

topographicPlaces TopographicPlace 0: * Container for objekterTopographicPlace

addresses Address 0: * Container for objekterAddress

accesses Access 0: * Container for objekterAccess

groupsOfStopPlaces GroupOfStopPlaces 0: * Container for   objekterGroupOfStopPlaces

stopPlaces StopPlace 0: * Container for objekterStopPlace

flexibleStopPlaces FlexibleStopPlace 0: * Container for objekterFlexibleStopPlace

pointsOfInterest PointOfInterest 0: * Container for objekterPointOfInterest

parkings Parking 0: * Container for objekterParking

navigationPaths NavigationPath 0: * Container for objekterNavigationPath

siteFacilitySets SiteFacilitySet 0: * Container for objekterSiteFacilitySet

ServiceFrame

ServiceFrame < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Network Network  0: 1 Network objekt (hovednettverk)

additionalNetworks Network  0: * Container for Network objekter (sekundære)

routePoints RoutePoint 0: * Container for RoutePoint objekter

routes Route 0: * Container for Route objekter

flexiblePointProperties FlexiblePointProperties 0: * Container for FlexiblePointProperties objekter

flexibleLinkProperties FlexibleLinkProperties 0: * Container for FlexibleLinkProperties objekter

commonSections CommonSection 0: * Container for CommonSection objekter

lines Line 0: * Container for Line objekter

groupsOfLines GroupOfLines 0: * Container for GroupOfLines objekter

destinationDisplays DestinationDisplay 0: * Container for DestinationDisplay objekter

scheduledStopPoints ScheduledStopPoint 0: * Container for ScheduledStopPoint objekter

servicePatterns ServicePattern 0: * Container for ServicePattern objekter

tariffZones TariffZone 0: * Container for TariffZone objekter

stopAssignments StopAssignment 0: * Container for StopAssignment objekter

timingPoints TimingPoint 0: * Container for TimingPoint objekter

timingLinks TimingLink 0: * Container for objekterTimingLink

journeyPatterns JourneyPattern 0: * Container for JourneyPattern objekter

serviceExclusions ServiceExclusion 0: * Container for ServiceExclusion objekter

notices Notice 0: * Container for Notice objekter

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

noticeAssignments NoticeAssignment 0: * Container for NoticeAssignment objekter

ServiceCalendarFrame

ServiceCalendarFrame < DataManagedObject

Navn Type Kardinalitet Beskrivelse

ServiceCalendar ServiceCalendar  0: 1 ServiceCalendar objekt

dayTypes DayType 0: * Container for DayType objekter

timebands Timeband 0: * Container for Timeband objekter

operatingDays OperatingDay 0: * Container for OperatingDay objekter

operatingPeriods OperatingPeriod 0: * Container for OperatingPeriod objekter

dayTypeAssignments DayTypeAssignment 0: * Container for DayTypeAssignment objekter

TimetableFrame

TimetableFrame < DataManagedObject

Navn Type Kardinalitet Beskrivelse

bookingTimes AvailabilityCondition 0: *  Container for objekter for å beskrive bestillingstransportAvailabilityCondition

vehicleJourneys diverse 0: * Container for følgende typer:

ServiceJourneySpecialServiceVehicleJourney

frequencyGroups HeadwayJourneyGroup 0: * Container for HeadwayJourneyGroup objekter

groupsOfServices GroupOfServices 0: * Container for GroupOfServices objekter

journeyPartCouples JourneyPartCouple 0: * Container for JourneyPartCouple objekter

coupledJourneys CoupledJourney 0: * Container for CoupledJourney objekter

serviceFacilitySets ServiceFacilitySet 0: * Container for ServiceFacilitySet objekter

flexibleServiceProperties FlexibleServiceProperties 0: * Container for FlexibleServiceProperties objekter

journeyMeetings JourneyMeeting 0: * Container for JourneyMeeting objekter

journeyInterchanges ServiceJourneyInterchange 0: * Container for ServiceJourneyInterchange  objekter

notices Notice 0: * Container for Notice objekter

noticeAssignments NoticeAssignment 0: * Container for NoticeAssignment objekter

Komponenter

Abstract Types

Entity

Entity

Navn Type Kardinalitet Beskrivelse

attr nameOfClass NameOfClass 0: 1 Klassenavn for Entity

Brukes for refleksjon og beskriver navnet på klassen dette objektet er en instans av

attr id ObjectIdType 1: 1 Unik identifikator av objektet.

Basistype for alle objekter. Definerer grunleggende attributter.

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

EntityInVersion

EntityInVersion < Entity

Navn Type Kardinalitet Beskrivelse

attr dataSourceRef DataSourceIdType 0: 1 Identifikator for datakilde-systemet

attr created xsd:dateTime 0: 1 Tidspunkt når ble opprettetEntity

attr changed xsd:dateTime 0: 1 Tidspunkt når ble sist endretEntity

attr modification ModificationEnum 0: 1 Angir type av endring:

deletenewreviseunchanged

attr(valg)

version VersionIdType 1: 1 Versjonsnummer

versionRef VersionIdType 0: 1 Versjonsnummer ved  referanse (til objekt som ikke er definerteksterninnenfor datasettet)

Brukes  dersom en referanse skal vise til annet enn siste gyldigekun eksternversjon

attr status VersionStatusEnum 0: 1 Status av versjon:

ActiveInactive

elem (valg)validityConditions

ValidityCondition 0: * Gyldighetsbetingelser for objektet

elem (valg) ValidBetween ValidBetweenStructure 0: * Forenklet versjon av (bare en enkel periode mellom to datoer)ValidityContion

DataManagedObject

DataManagedObject < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

attr responsibilitySetRef ResponsibilitySetIdType 1: 1 Peker til roller og ansvarsområder knyttet til STOP PLACE, NETWORK eller LINE

elem keyList KeyList 0: 1 Et sett med nøkkel-verdi par som beskriver tilleggsegenskaper for objektet (LINE,STOP PLACE, PLANNED STOP POINT osv.), og som kan brukes i tredje-partssystemer: billettering, reiseinformasjon osv.

elem Extentions ExtentionStructure 0: 1 Utvidelseselement for data som ikke er definert av NeTEx. Brukes dersom strengtN.B.: kun etter godkjennelse fra arbeidsgruppen

nødvendig å legge til nye datafelter som ikke finnes i NeTEx-standarden (f.eks.hvis behov i intern datautveksling).

elem BrandingRef BrandingRefStructure 0: 1 Referanse til varemerke (f.eks. Ruter, ATB, osv)

KeyList

KeyList

Navn Type Kardinalitet Beskrivelse

KeyValue KeyValue 1: * Nøkkel-verdi par

Basistype som utvider settet av grunleggende attributter, samt definerer gyldighets betingelser.

Se definisjon under Generell informasjon

Datatype som knytter ansvarsdefinisjon og branding til et objekt. Nesten alle NeTEx klasser arver fra DataManagedObject

Se definisjon under Generell informasjon

Liste som beskriver et sett med egendefinerte nøkkel-verdi par, som lever inne i objektet KeyList tilhører

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

KeyValue

Navn Type Kardinalitet Beskrivelse

attr typeOfKey xsd:normalizedString 0: 1 Nøkkels type

elem Key xsd:normalizedString 1: 1 Nøkkels navn

elem Value xsd:normalizedString 1: 1 Nøkkels verdi

TypeOfValue

TypeOfValue < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn

Description MultilingualString 0: 1 Beskrivelse

Image xsd:anyURI 0: 1 URL til relatert bilde-ressurs

Url xsd:anyURI 0: 1 URL

GroupOfEntities

GroupOfEntities < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn være satt for alle grupper av objekter (f.eks. på NETWORK, LINE, STOPmåPLACE m.v.)

ShortName MultilingualString 0: 1 Kort navn for gruppe av objekter

Description MultilingualString 0: 1 Tekst beskrivelse

PurposeOfGroupingRef PurposeOfGroupingRef 0: 1 Funksjonelt mål av gruppering

PrivateCode PrivateCode 0: 1 PrivateCode er ment å bruke for spesifikk identifisering basert på kontekst.

Address

Address < < < < < Place Zone GroupOfPoints GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

CountryRef CountryEnum 0: 1 To-bokstavers landskode i henhold til  ISO 3166-1 alfa-2

CountryName MultilingualString 0: 1 Landets offisielle navn 

Assignment

Abstrakt datatype som brukes for å definere klassifiseringer av andre typer

Abstrakt type for å gruppere vilkårlige objekter, f.eks. GroupOfOperators eller GroupOfPoints. Klasser som arver fraGroupOfEntities definerer typisk " " elementet for å samle alle objekter som tilhører gruppen.members

Se definisjon under Generell informasjon

Abstrakt type for å definere adresse. Utvides av RoadAddress og PostalAddress by default.

Se definisjon under Generell informasjon

Abstrakt type for å knytte et sett med egenskaper til et gitt objekt

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Assignment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn

Description MultilingualString 0: 1 Beskrivelse

Equipment Details

Equipment

Equipment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn

PrivateCode xsd:normalizedString 0: 1 Internkode/ID for identifisering av utstyr (skal benyttes i publikumstjenester)ikke

PublicCode xsd:normalizedString 0: 1 Offentlig kode som kan identifisere utstyret

Description MultilingualString 0: 1 Beskrivelse

Note MultilingualString 0: 1 Tilleggsnotater

OutOfService xsd:boolean 0: 1 Spesifiserer om

PassengerEquipment

PassengerEquipment < < Eqiupment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Fixed xsd:boolean 0: 1 Spesifiserer om utstyr er montert eller kan flyttes

ActualVehicleEquipment

ActualVehicleEquipment < < < PassengerEquipment Equipment  DataManagedObject

Navn Type Kardinalitet Beskrivelse

Units xsd:integer 0: 1 Antall utstyr elementer

VehicleTypeRef VehicleTypeRef 0: 1  Referanse til kjøretøy type ( )VehicleType

AccessibilityAssessment AccessibilityAssessment 0: 1 Universell Utforming - Beskrivelse av utstyr

Place

Place < < < < Zone GroupOfPoints GroupOfEntities DataManagedObject

Abstrakt type for å beskrive utstyr tilgjengelig enten på et sted eller ombord på kjøretøy

Se definisjon under Generell informasjon

Utvidelse av Equipment type som beskriver utstur som kan brukes av passasjerer

Se definisjon under Generell informasjon

Utvidelse av PassengerEquipment som beskriver utstyr ombord på kjøretøy

Se definisjon under Generell informasjon

Geografisk lokasjon som kan være start- eller slutt punkt for en gitt reise

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Navn Type Kardinalitet Beskrivelse

placeTypes TypeOfPlaceRef 1: 1 Dette elementet brukes kun for StopPlace og TopographicPlace, hvor det er påkrevd (elementet er dikkeefinert av Place type).

Verdier for StopPlace:

monomodalStopPlacemultimodalStopPlace 

Verdier for TopographicPlace:

county (fylke)municipality (kommune)city (by)district (bydel)town (tettsted)

FacilitySet

FacilitySet < DataManagedObject

Navn Type Kardinalitet Beskrivelse

ProvidedByRef xsd:normalizedString 0: 1 Referanse til organisasjon som tilbyr dissetjenester

Description MultilingualString 0: 1 Beskrivelse av tjeneste settet

AccessibilityInfoFacilityList AccessibilityInfoFacilityListOfEnumerations 0: 1 Mulige verdier

otheraudioForHearingImpaired (Teleslynge)audioInformation (Annonsering avavganger/ankomster)visualDisplays

AssistanceFacilityList AssistanceFacilityListOfEnumerations 1: 1  Mulige verdier

anynoneotherpersonalAssistanceboardingAssistancewheelchairAssistanceunaccompaniedMinorAssistancewheelchairUseconductorinformation

AccessibilityToolList AccessibilityToolListOfEnumerations 0: 1  Mulige verdier

passengerCartpushchair (barnevogn)wheelchair

CateringFacilityList CateringFacilityListOfEnumerations 1: 1 Mulige verdierbarnoFoodAvailablenoBeveragesAvailablerestauranttrolleycoffeeShopsnacksfoodVendingMachinebeverageVendingMachine

FareClasses FareClassesListOfEnumerations 1: 1 Mulige verdieranybusinessClass (NSB Komfort, fly)economyClass (alt annet)firstClass (fly)

Et sett med fasiliteter/tjenester som tilbys (baseres på klassifisering)TPEG

Se definisjon under Generell informasjon

 (se Eksempel finnes i Rutebankens offisielle GitHub-repository beskrivelse av SiteFacilitySet, en spesialisering av FacilitySet, foret stoppested) 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

MobilityFacilityList MobilityFacilityListOfEnumerations 1: 1 Mulige verdierunknownboardingAssistancelowFlooronboardAssistancestepFreeAccesssuitableForWheelchairsunaccompaniedMinorAssistancetactilePatformEdgestactileGuidingStrips

PassengerCommsFacilityList PassengerCommsFacilityListOfEnumerations 0: 1 Mulige verdierfreeWifipublicWifipowerSupplySockets

PassengerInformationEquipmentList PassengerInformationEquipmentListOfEnumerations 0: 1 Mulige verdierotherfareInformationlineNetworkPlanlineTimetableinformationDeskrealTimeDepartures

PassengerInformationFacilityList PassengerInformationFacilityEnumeration 0: 1 Mulige verdier

othernextStopIndicatorpassengerInformationDisplayrealTimeConnectionsstopAnnouncements

SanitaryFacilityList SanitaryFacilityListOfEnumerations 0: 1 Mulige verdiernonetoiletwheelChairAccessToiletshowerbabyChange

TicketingFacilityList TicketingFacilityListOfEnumerations 0: 1 Mulige verdiermobileTicketingticketMachinesticketOffice

Link

Link < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Links navn

Distance xsd:decimal 0: 1 Total lengde (i meter) for den geografiske kjøretrasèen transportmiddelet skal benytte (dvs faktiskkjøredistanse)

gml:LineString gml:LineString 0: 1 Geometrisk representasjon av Link vha gml LineString (beskrevet som en rekke punkter)

LinkSequence

LinkSequence < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn

Distance xsd:decimal 0: 1 Total lengde (i meter) for  ( )LinkSequence kan også utledes fra komponent-Links

PointInLinkSequence

Beskrivelse av kobling mellom to punkter

Se definisjon under Generell informasjon

Abstrakt type bestående av eller som beskriver stien gjennom nettverketPoints Links

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

PointInLinkSequence < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

attr order xsd:positiveInteger 0: 1 Serienummer av punktet i rekken

elem LinkSequenceRef LinkSequenceRefStructure 0: 1 Referanse til som punktet hører tilLinkSequence

elem projections projections 0: 1 Projeksjoner på veier eller jernbane

LinkInLinkSequence

LinkInLinkSequence < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

attr order xsd:positiveInteger 0: 1 Serienummer av punktet i rekken

elem LinkSequenceRef LinkSequenceRefStructure 0: 1 Referanse til som punktet hører tilLinkSequence

elem projections projections 0: 1 Projeksjoner på veier eller jernbane

Organisation

Organisation < DataManagedObject

Navn Type Kardinalitet Beskrivelse

CompanyNumber xsd:normalizedString 1: 1 Organisasjonsnummer fra Brønnøysundregistrene

Name xsd:normalizedString 1: 1 Organisasjonsnavn

LegalName MultilingualString 1: 1 Organisasjonens juridiske navn

ContactDetails ContactStructure 1: 1 Offentlig kontaktinformasjon

PrivateContactDetails ContactStructure 0: 1 Kontaktinformasjon ikke for bruk i publikumstjenester ( )dersom relevant

parts OrganisationPart 0: 1 Avdelinger (Departments)

Projection

Projection < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Ingen av parametre definert i Projection skal brukes. Spesialiseringsklasser har egne parametre.

Basic Types

Abstrakt type som beskriver punktets posisjon i en LinkSequence (implementeres normalt som PointOnRoute eller PointInJourney)Pattern

Se definisjon under Generell informasjon

Abstrakt type som beskriver lenkens posisjon i en LinkSequence ( )implementeres normalt som LinkInJourneyPattern

Se definisjon under Generell informasjon

Et juridisk organ som er involvert i offentlig transport sektor

Se definisjon under Generell informasjon

Beskrivelse av mapping mellom formen av en vilkårlig Entity på et lag til en Entity på et annet lag, f.eks. Point, Link, Zone

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

AlternativeName

AlternativeName < VersionedChild < EntityInVersion < Entity 

Navn Type Kardinalitet Beskrivelse

NamedObjectRef VersionofObjectRef 0: 1 Referanse til objektet som AlternativeName hører til

Mer at denne brukes når det relevante dataobjektet ikke støtterkunalternativeNames-underelementer

Lang xsd:language 1: 1 To-bokstavers språkkode i henhold til  for språket brukt i et aliasRFC 1766 / ISO 639-1

NameType NameTypeEnumeration 1: 1 Type navn:

AliasLabel ("folkemunnenavn", brukes dersom et ikke-offisielt navn må håndteres særskilt

)av publikumshensynTranslation

Name MultilingualString 1: 1 Alternativt navn

ContactStructure

ContactStructure

Navn Type Kardinalitet Beskrivelse

ContactPerson xsd:normalizedString 0: 1 Kontaktperson

Email emailAddressType 0: 1 Kontakt-epostadresse (ISO format), alternativt lenke til kontakt-skjema

Phone PhoneType 0: 1 Telefonnummer

Fax PhoneType 0: 1 Faksnummer

Url xsd:anyURI 0: 1 Nettside-adresse

Merk at URL er for CustomerServiceContactDetailspåkrevd

FurtherDetails xsd:normalizedString 0: 1 Tilleggsinformasjon

DeliveryVariant

DeliveryVariant < DataManagedObject

Navn Type Kardinalitet Beskrivelse

DeliveryVariantMediaType DeliveryVariantTypeEnumeration 1: 1 Media type. Mulige verdier er:

printedtextToSpeechwebmobile

VariantText MultilingualString 1: 1 Tekst for de respektive media typene (vil erstatte Note for gitte mediatyper)

Alternativt navn, f.eks. på et annet spåk

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Datasett for kontaktinformasjon

Det er påkrevd å oppgi kontaktinformasjon i minimum ett av feltene Email, Phone eller Url.

Se definisjon under Generell informasjon

Alternaiv variant av Notice egnet for forskjellige typer media

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

GeneralGroupOfEntities

GeneralGroupOfEntities < < GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

members objectRef 0: * Liste av objekter som inngår i gruppen

GroupOfPoints

GroupOfPoints < < GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

members objectRef 0: * Liste av objekter som inngår i gruppenPoint

Locale

Locale

Navn Type Kardinalitet Beskrivelse

TimeZone TimeZoneOffset 1: 1 Navn på tidssone

Merk at dette alltid skal være gjeldende tidssone for lokaltid

DefaultLanguage xds:language 1: 1 Default språk

languages LanguageUsage 0: * Andre språk

LanguageUsage

LanguageUsage

Navn Type Kardinalitet Beskrivelse

Language xsd:language 1: 1 Språket som beskrives

LanguageUse LanguageUseListOfEnumerations 1: 1 Mulige verdier

allUsesnativenormallyUsedotherreadspokenwrittenunderstood

Location

En generell gruppe av Entity objekter. En predefinert basisgruppe for vilkårlige objekter

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Gruppe av Point objekter

Beskrivelse av nasjonale instillinger, som tid og språk

Eksempel finnes i Rutebankens offisielle GitHub-repository

Beskrivelse av språkbruk basert på FN standardverier

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Location

Navn Type Kardinalitet Beskrivelse

attr srsName xsd:normalizedString 0: 1 Referansesystem som gjelder for Longitude og Latitude. Hvis oppgitt, benytt"WGS84" eller hvis nødvendig en gyldig koordinat-referanse til standarden(f.eks. "EPSG:4326").

(valg)elem

Longitude

Latitude

Altitude

LongitudeType

LatitudeType

AltitudeType

1: 1

1: 1

0: 1

Longitude (-180 til 180)

Latitude (-90 til 90)

Høyde (moh)

(valg)elem

gml:pos gml:pos 1: 1 Lokasjon

F.eks. <gml: pos srsName="urn:ogc:def:crs:EPSG::4326"> -59.123 -45.1254</gml:pos>

Merk at stoppestedregisteret kun aksepterer koordinater ihht.WGS84-standarden!

elem Precision xsd:decimal 0: 1 Nøyaktighet (i meter)

MultilingualString

MultilingualString

Navn Type Kardinalitet Beskrivelse

attr lang xsd:language 0: 1 To-bokstavers språkkode i henhold til  for språket som brukesRFC 1766 / ISO 639-1

når objektet er språk-alternativ, f.eks. ved bruk av   / Må settes AlternativeName AlternativeText

Projection Types

PointProjection

PointProjection < < Projection DataManagedObject

Navn Type Kardinalitet Beskrivelse

ProjectedPointRef PointRef 0: 1 Punkt som projiseres. 

Dette feltet er nyttig når Projection er sendt som et separat objekt. Ellers er det bestemt av konteksthvilket objekt Projection hører til.

ProjectToPointRef PointRef 0: 1 Punkt som det projiseres til. (Refanse til eksternt definert punkt, f.eks. RoutePoint, TimingPoint,ScheduledStopPoint.)

ProjectToLinkRef LinkRef 0: 1 Link som det projiseres til. Point kan projiseres til en Link

Distance xsd:decimal (1: 1) Lengde mellom projisert Point og Link. Dette feltet brukes kun sammen med ProjectToLinkRef

ZoneProjection

Geografisk lokasjon av et objekt

Se definisjon under Generell informasjon

Eksempler finnes i Rutebankens offisielle GitHub-repository (se beskrivelse av under  eller LocationPoint Point with projection Centr under  , s )oidLocation PointOfInterest e eventuelt også datatypene Polygon og Geographical Types

Tekstfelt med spesifisert språk

Mapping av Point objekt fra ett lag til et annet lag, f.eks til Point eller Link

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

ZoneProjection < < Projection DataManagedObject

Navn Type Kardinalitet Beskrivelse

ProjectedZoneRef ZoneRef 0: 1 Sone som projiseres. 

Dette feltet er nyttig når Projection er sendt som et separat objekt. Ellers er det bestemt av kontekst hvilketobjekt Projection hører til.

ProjectToZoneRef ZoneRef 0: 1 Sone som det projiseres til. (Referanse til eksternt zone-objekt.)

ProjectToPointRef PointRef 0: 1 Point som det projiseres til. Zone kan projiseres til en Point.

Address Types

PostalAddress

PostalAddress < < < < < < Address Place Zone GroupOfPoints GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

AddressLine1 MultilingualString 1: 1 Adresselinje 1

AddressLine2 MultilingualString 0: 1 Adresselinje 2

Town MultilingualString 1: 1 Stedsnavn

PostCode xsd:normalizedString 1: 1 Postnr

RoadAddress

RoadAddress < < < < < < Address Place Zone GroupOfPoints GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

GisFeatureRef xsd:normalizedString 1: 1 Referanse til GIS system. Dette feltet vil hjelpe å lenke til OSM, IGN, NavTeq, e.l. data

RoadNumber xsd:normalizedString 1: 1 Veinr

RoadName MultilingualString 1: 1 Veinavn

BearingDegrees xsd:integer 0: 1 Orientering av veien

ServiceFacilitySet

ServiceFacilitySet < < FacilitySet DataManagedObject

Mapping av Zone objekt fra ett lag til et annet lag, f.eks til Point eller Zone

Se definisjon under Generell informasjon

Beskrivelse av postadresse

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Beskrivelse av gateadresse

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Spesialisering av FacilitySet for å beskrive tilgjengelige services

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Navn Type Kardinalitet Beskrivelse

AccommodationAccessList AccommodationAccessListOfEnumerations 0: 1 Mulige verdier

freeSeatingreservationstanding

AccommodationFacilityList AccommodationFacilityListOfEnumerations 0: 1 Mulige verdier

familyCarriageseatingsleeperstanding

LuggageCarriageFacilityList LuggageCarriageFacilityListOfEnumerations 0: 1 Mulige verdier

baggageStoragecyclesAllowedcyclesAllowedWithReservationluggageRacksextraLargeLuggageRacksnoBaggageStoragenoCycles

ServiceReservationFacilityList ServiceReservationFacilityListOfEnumerations 0: 1 Mulige verdier

bicycleReservationsCompulsorynoReservationsPossiblereservationsCompulsoryreservationsCompulsoryForGroupsreservationsRecommendedreservationsPossiblewheelchairOnlyReservations

Vehicle

Vehicle < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Kjøretøyets navn

RegistrationNumber xsd:normalizedString 0: 1 Skiltet

OperationalNumber xsd:normalizedString 0: 1 Operasjonell nr

OperatorRef OperatorRefStructure 1: 1 Referanse til operatør

VehicleTypeRef VehicleTypeRefStructure 1: 1 Referanse til VehicleType

actualVehicleEquipments Equipment 0: * Beskrivelse av utstyr ombord.

Defineres inline.

VehicleType

VehicleType < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn på typen

Kjøretøy som brukes for offentlig transport

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Beskrivelse av type kjøretøy

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Description MultilingualString 1: 1 Beskrivelse av typen

TypeOfFuel TypeOfFuelEnumeration 0: 1 Type drivstoff:

PetrolDieselnaturalGasbiodieselelectricityother

EuroClass xsd:normalizedString 0: 1 Euroklass for typen Se Wikipedia for informasjon

capacities PassengerCapacity 0: * Kapasitet per tariffklasse

LowFloor xsd:boolean 1: 1 Spesifiserer om kjøretøyet har lav gulv

HasLiftOrRamp xsd:boolean 1: 1 Spesifiserer om kjøretøyet har heis eller rampe

Length xsd:decimal 0: 1 Lengden på kjøretøyet

facilities ServiceFacilitySetRef 0: * Referanser til objekterServiceFacilitySet

PassengerCapacity

PassengerCapacity < DataManagedObject

Navn Type Kardinalitet Beskrivelse

FareClass FareClassEnumeration 1: 1 Mulige verdier:

businessClasseconomyClassfirstClassany

TotalCapacity xsd:nonNegativeInteger 1: 1 Maks antall passasjerer

SeatingCapacity xsd:nonNegativeInteger 1: 1 Antall sitteplasser

StandingCapacity xsd:nonNegativeInteger 1: 1 Antall ståplasser

SpecialPlaceCapacity xsd:nonNegativeInteger 1: 1 Antall plasser for spesielle behov (f.eks for de funksjonshemmede, "mann medstokk-skilt")

PushchairCapacity xsd:nonNegativeInteger 1: 1 Antall plasser for barnevogn

WheelchairCapacity xsd:nonNegativeInteger 1: 1 Antall plasser for rullestol

Accessibility Types

AccessibilityAssessment

AccessibilityAssessment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

MobilityImpairedAccess LimitationStatusEnum 1: 1 Spesifiserer om objektet er egnet for brukere med spesielle behov:

true ( AccessibilityLi )dersom alle feltene i mitation er truefalse ( )dersom alle feltene i AccessibilityLimitation er falsepartial (dersom felter i AccessibilityLimitation er partial eller bare noen av disse er

)trueunknown

limitations AccessibilityLimitation 1: 1 Begrensninger for tilgang

Maks antall passasjerer et kjøretøy kan romme

Eksempel finnes i Rutebankens offisielle GitHub-repository

Universell Utforming - Beskrivelse av et objekt, f.eks. stoppested

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

suitabilities Suitability 0: * Beskriver egnethet

Comment MultilingualString 0: 1 Tilleggskommetar for Accessibility definisjon. Dette feltet er ment for visning sammen med tilgangsinformasjon.

AccessibilityLimitation

AccessibilityLimitation < DataManagedObject

Navn Type Kardinalitet Beskrivelse

WheelchairAccess LimitationStatusEnum 1: 1 Beskriver om rullestol brukere kan bruke objektet:

truefalsepartialunknown

StepFreeAccess LimitationStatusEnum 1: 1 Beskriver om objektet har trinnfri adgang:

truefalsepartialunknown

EscalatorFreeAccess LimitationStatusEnum 1: 1 Beskriver om objektet kan aksesseres uten bruk av rulletrapp:

truefalsepartialunknown

LiftFreeAccess LimitationStatusEnum 1: 1 Beskriver om objektet kan aksesseres uten bruk av heis:

truefalsepartialunknown

AudibleSignsAvailable LimitationStatusEnum 1: 1 Beskriver om det finnes lydsignaler:

truefalsepartialunknown

VisualSignsAvailable LimitationStatusEnum 1: 1 Beskriver om det finnes visuell informasjon:

truefalsepartialunknown

Suitability

Suitability < < UserNeed DataManagedObject

Navn Type Kardinalitet Beskrivelse

(valg) MobilityNeed MobilityEnumeration 1: 1 Spesifikk bevegelsesbehov:

wheelchairassistedWheelchairmotorizedWheelchairwalkingFrame (rullator)otherMobilityNeednormal

Begrensninger som finnes

Se definisjon under Generell informasjon

Beskrivelse av egnethet

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

(valg)PsychosensoryNeed

PsychosensoryNeedEnumeration 1: 1 Spesifikk behov:

visualImpairmentauditoryImpairment

(valg)EncumbranceNeed

EncumbranceNeedEnumeration 1: 1 Spesifikk bagasjebehov:

luggageEncumberedpushchairbaggageTrolleyoversizeBaggageguideDogotherAnimalotherEncumbranceNeed

Suitable SuitableEnumeration 1: 1 Spesifiserer om behovet (fastsatt gjennom de andre verdiene) erimøtekommet eller ikke:

suitablenotSuitable

Geographical Types

Point

Point < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Points navn

Location Location 0: 1 Points lokasjon

NB: Lokasjon er dersom dette ikke entydig kan utledes av f.eks. punktets projisering ellerpåkrevdinneholdende objekts eksplistte referanse til annet geografisk stedfestet punkt / område

PointNumber xsd:normalizedString 0: 1 Alternativ identifikator

projections Projection 0: * Points projeksjoner

Zone

Zone < < < GroupOfPoints GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

Centroid Point 0: 1 Representativ punkt for Zone. Dette er ikke ment å være zone senter, men et punkt som kan spesifiserelokasjon bra nok (f.eks. på et kart)

gml:Polygon gml:Polygon 0: 1 En sortert liste av punkter som representerer en lukket linje som geografisk omringer Zone.

projections Projection 0: * Liste av projeksjoner som brukes for å beskrive infrastruktur (f.eks. veger, jernbane, osv), typisk ved åreferere til OSM datasett.

Polygon

Et punkt som brukes som element av transport nettverk

Se definisjon under Generell informasjon

Eksempel finnes i (s )Rutebankens offisielle GitHub-repository  e også datatyper Location og Polygon

Beskrivelse av et geografisk område

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Område representert som omriss / overflate

Se også  og Location Geographical Types

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Polygon-sturktur

Organisation Types

Operator

Operator < < Organisation DataManagedObject

Navn Type Kardinalitet Beskrivelse

Address PostalAddress 0: 1 Postadressen

PrimaryMode VehicleModeEnumeration 0: 1 Primær type av transport ( )hvis relevant

OperatorActivities ListOfOperatorActivities 0: 1 Mulige verdier:

passengerinfrastructure

CustomerServiceContactDetails ContactStructure 1: 1 Kontaktinformasjon for kundehenvendelser / kundeservice

Authority

Polygon eksempel

En bedrift som tilbyt offentlig transport tjeneste

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Organisasjon som er ansvarlig for å etablere offentlig transport tjeneste

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Authority < < Organisation DataManagedObject

Navn Type Kardinalitet Beskrivelse

Address PostalAddress 0: 1 Postadressen

OrganisationPart

OrganisationPart < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Organiasjonens navn

Description MultilingualString 0: 1 Organisasjons-beskrivelse

PrivateCode xsd:normalizedString 0: 1 Intern kode for integrasjon med legacy systemer

ContactDetails ContactStructure 0: 1 Kontaktinformasjon

Location Location 0: 1 Organisasjonens lokasjon

Department

Department < < OrganisationPart DataManagedObject

Navn Type Kardinalitet Beskrivelse

TypeOfOperationRef TypeOfOperationRef 1: 1 Referanse til TypeOfOperation (klassifisering av avdeling)

GroupOfOperators

GroupOfOperators < < GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

members TransportOrganisationRef 1: * Referanser til operatører som inngår i gruppen

Branding

Branding < TypeOfValue < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Branding arver fra TypeOfValue og introduserer ikke nye elementer eller attributter

Beskrivelse av felles komponenter for en avdeling i organisasjon (NeTEx definerer flere forskjellige typer avdelinger)

Se definisjon under Generell informasjon

Avdeling i en organisasjon

Gruppe av operatører

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Beskrivelse av merkevare

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

DataSource

DataSource < < TypeOfValue DataManagedObject

Navn Type Kardinalitet Beskrivelse

Email EmailAddressType 1: 1 Kontakt epost for data-relaterte spørsmål

Equipment Types

AccessEquipment

EntranceEquipment

EntranceEquipment < < < PlaceEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Door xsd:boolean 0: 1 Om inngangen har en dør

WheelchairPassable xsd:boolean 0: 1 Om inngangen er forserbar med rullestol

PlaceLighting

PlaceLighting < < < PlaceEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Beskrivelse av systemet som er kilden til rutedata. Denne typen har samme sett med felter som TypeOfValue pluss email.

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Installed Equipment

Faste objekter tilknyttet f.eks. stoppestedsområder. Følgende typer inngår i denne profilen:

AccessEquipmentEntranceEquipmentPlaceLightingRampEquipmentRoughSurface

ParkingEquipmentCycleStorageEquipment

PassengerServiceEquipmentSanitaryEquipment

TicketingEquipmentTicketingEquipmentTicketValidatorEquipment

SignEquipmentGeneralSign

LocalService

Tjenester tilknyttet f.eks. stoppestedsområder. Følgende inngår i denne profilen:

AssistanceServiceLuggageService

Utstyrsdetaljer for en inngang

Se definisjon under Generell informasjon

Beskrive av belysning for et sted

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Lighting LightingEnumeration 1: 1 Belysningsgrad:

wellLitpoorlyLitunlitunknown

AlwaysLit xsd:boolean 0: 1 Spesifiserer om belysning er alltid på eller ikke

RampEquipment

RampEquipment < < < PlaceEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Gradient RampGradientEnum 0: 1 Mulige verdier:

verySteepshallowsteepmoderatelevel ( )no gradient

RoughSurface

RoughSurface < < < AccessEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

SurfaceType SurfaceTypeEnumeration 1: 1 Type belegg:

asphaltearthgrasslooseSurface (f.eks. grus)pavingStones (beleggingsstein)roughSurface (f.eks. steinete)smooth (betong, generell ren overflate)other

SuitableForCycles xsd:boolean 0: 1 Spesifiserer om belegg er egnet for sykling

CycleStorageEquipment

CycleParkingEquipment < < PlaceEquipment < Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

NumberOfSpaces xsd:integer 1: 1 Antall plasser

CycleStorageType CycleStorageEnum 0: 1 Mulige verdier:

racksbarsrailings

Covered xsd:boolean 0: 1 Spesifiserer om parkeringen har tak

PassengerEquipment

Beskrivelse av attributter for en tilgjengelighetsrampe

Se definisjon under Generell informasjon

Beskrivelse av belegg

Se definisjon under Generell informasjon

Beskrivelse av sykkellager

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

SanitaryEquipment

SanitaryEquipment < < < PassengerEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

SanitaryFacilityList SanitaryFacilityListOfEnumerations 1: 1 Liste av fasiliteter:

nonetoiletwheelchairAccessToiletshowerbabyChange

NumberOfToilets xsd:integer 0: 1 Antall toaletter

SiteEquipment

WaitingRoomEquipment

WaitingRoomEquipment < < < SiteEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Seats xsd:nonNegativeInteger 0: 1 Antall sitteplasser

StepFree xsd:boolean 1: 1 Spesifiserer om venteområde er trinnfri

Heated xsd:boolean 0: 1 Spesifiserer om venteområde er varmet

ShelterEquipment

ShelterEquipment < < < < WaitingEquipment SiteEquipment Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Enclosed xsd:boolean 1: 1 Spesifiserer om venteområde er utendørs eller innendørs

TicketingEquipment

TicketingEquipment

TicketingEquipment < PassengerEquipment < Equipment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

NumberOfMachines xsd:integer 0: 1 Antall billettautomater

Beskrivelse av sanitær utstyr

Se definisjon under Generell informasjon

Beskrivelse av venteromsområde

Se definisjon under Generell informasjon

Beskrivelse av venterom

Se definisjon under Generell informasjon

Beskrivelse av billetteringsutstyr

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TicketingFacilityList TicketingFacilityEnum 0: * Mulige verdier:

ticketMachinesticketOfficeticketOnDemandMachinesticketSalesticketCollectioncentralReservationslocalTicketsnationalTicketsinternationalTickets

NumberOfTills xsd:integer 0: 1 Antall skranker for billettsalg

PaymentMethods PaymentMethodEnum 0: * Mulige verdier:

cashcashAndCardcoincreditCarddebitCardtravelCardcontactlessTravelCardsmstokencheque

TicketTypesAvailable TicketTypeEnum 0: * Mulige verdier:

standardpromotionconcessiongroupseasontravelCard

TicketingServiceList TicketingServiceFacilityEnum 0: * Mulige verdier:

purchasecollectioncardTopUpreservations

TicketValidatorEquipment

TicketValidatorEquipment < PassengerEquipment < Equipment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

ValidatorList TicketValidatorEnum 0: * Mulige verdier:

paperStampcontactLessmagneticnfc

SignEquipment

GeneralSign

GeneralSign < SignEquipment < PlaceEquipment < Equipment < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Beskrivelse av billettvalideringsutstyr

Se definisjon under Generell informasjon

Beskrivelse av skilt

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

PrivateCode xsd:normalizedString 0: 1 Skiltkode

For offisielle stoppestedsskilt en av følgende kodeverdier oppgis:skal

Stoppested for buss: 512Stoppested for sporvogn: 513Stoppested for drosje: 514

I tillegg settes SignContentType = 'transportMode' (se under)

Content MultilingualString 0: 1 Skiltets innhold / tekst

SignContentType SignContentEnum 0: 1 Type skilt:

assistanceemergencyExitentranceexitmeetingPointsosPhoneticketstransportMode

For permanente stoppesteder etablert med skilt (f.eks. ordinær busslomme) SignContentTymåpe 'transportMode' være satt, dette brukes for å skille disse fra ikke-permanente stoppesterder("vinkepunkter").

LocalService

AssistanceService

AssistanceService < LocalService < < Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

AssistanceServices AssistanceServiceEnum 0: * Mulige verdier:

boardingAssistancepersonalAssistancewheelchairAssistanceunaccomapniedMinorsAssistanceconductorinformation

AccessibilityTools AccessibilityToolEnum 0: * Mulige verdier:

wheelchairwalkingStickaudioNavigatorvisualNavigator

GuideDogsAllowed xsd:boolean 0: 1 Om førerhund er tillatt

LuggageService

AssistanceService < LocalService < < Equipment DataManagedObject

Navn Type Kardinalitet Beskrivelse

LuggageServiceType LuggageServiceFacilityEnum 0: 1 Mulige verdier:

leftLuggageporteragefreeTrolleyspaidTrolleyscollectAndDeliverToStation

WheelchairLuggageTrolleys xsd:boolean 0: 1 Om baggasjetraller for rullestolbrukere er tilgjengelig

Tilgjengelig spesialassistanse

Se definisjon under Generell informasjon

Tilgjengelige reisegodstjenster

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Train Types

CompoundTrain

CompoundTrain < < VehicleType DataManagedObject

Navn Type Kardinalitet Beskrivelse

components TrainInCompoundTrain 1: * Referanser til tog objekter som er en del av sammensatt tog.

TrainInCompoundTrain

TrainInCompoundTrain < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

Train Train 1: 1 Tog beskrivelse (Train)

ReversedOrientation xsd:boolean 0: 1 Spesifiserer om det enkelte tog står i motsatt retning sammenlignet med CompoundTrain

Label MultilingualString 0: 1 Label assosiert med det enkelte toget

Train

Train < < VehicleType DataManagedObject

Navn Type Kardinalitet Beskrivelse

TrainSize TrainSize 0: 1 Størrelse av toget

components TrainComponent 0: * Komponenter av toget

TrainSize

TrainSize

Navn Type Kardinalitet Beskrivelse

NumberOfCars xsd:nonNegativeInteger 0: 1 Antall vogner

Sammensatt tog beskrivelse

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Et tog ( ) i en sammensatt tog ( )Train CompoundTrain

Se definisjon under Generell informasjon

Tog beskrivelse

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Størrelse på toget

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TrainSizeType TrainSizeEnumeration 0: 1 Størrelsetype

NormalShortLong

TrainComponent

TrainComponent < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Label MultilingualString 0: 1 Statisk tog komponent label. Dersom label er dynamisk, bruk TrainComponentLabelAssignment i stedet.

Description MultilingualString 0: 1 Berskrivelse av komponenten

TrainElement TrainElement 1: 1 Beskrivelse av den aktuelle vognen

TrainElement

TrainElement < DataManagedObject

Navn Type Kardinalitet Beskrivelse

TrainElementType TypeOfTrainElementEnum 1: 1 Klassifisering av vogn:

carriageenginesleeperCarriageluggageVanrestaurantCarriage

FareClasses FareClassListOfEnumerations 0: * Tariffklasse for vogn

anybusinessClasseconomyClassfirstClass

equipments Equipment 0: * Beskrivelse av utstyr ombord

Defineres inline

Notice Types

Notice

Notice < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn for notat

En vogn

Se definisjon under Generell informasjon

Detaljert vogn beskrivelse

Se definisjon under Generell informasjon

Defineres i ResourceFrame

Tekstlig varsel eller oppdatering som ikke lar seg modellere i form av strukturerte data

Merk at Notice (og relatert NoticeAssignment) skal ligge i sin tilhørende ServiceFrame / TimetableFrame

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

AlternativeTexts AlternativeText 0: * Tekstlig innhold  for notis (én per språk)på annet språk enn norsk

Brukes som eventuelt tillegg til norsk tekst (se under)

Text MultilingualString 1: 1 Tekstlig innhold for notis

PublicCode xsd:normalizedString 0: 1 Offentlig kode for notat

variants DeliveryVariant 0: * Variasjoner for forskjellige typer media

AlternativeText

AlternativeText < VersionedChild < EntityInVersion < Entity 

Navn Type Kardinalitet Beskrivelse

Text MultilingualString 1: 1 Innhold for notat

Merk at "lang"-attributt  være satt for språkvarianter av notatetskal

NoticeAssignment

NoticeAssignment < < Assignment DataManagedObject

Navn Type Kardinalitet Beskrivelse

NoticeRef NoticeRef 1: 1 Referanse til objektetNotice

NoticedObjectRef VersionOfObjectRef 1: 1 Referanse til objektet Notice tilhører

Calendar Types

DayType

DayType < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn for DayType

Description MultilingualString 0: 1 Beskrivelse

EarliestTime xsd:time 0: 1 Start tidspunkt

DayLength xsd:duration 0: 1 Varighet

properties PropertyOfDay 0: * Egenskaper

timebands Timeband 0: * Spesifikke perioder ila dagen

PropertyOfDay

Placeholder for tekstfelter på annet språk enn norsk

Kobling mellom Notice og objektet den refererer til, f.eks.  eller JourneyPattern VehicleJourney

Merk at NoticeAssignment (og relatert Notice) skal ligge i sin tilhørende ServiceFrame / TimetableFrame

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Beskrivelse av dag type, som har et sett med egenskaper som påvirker offentlig transport tjeneste, f.eks. helligdag

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

PropertyOfDay

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn på property

Description MultilingualString 0: 1 Beskrivelse

DaysOfWeek DayOfWeekListOfEnumerations 0: 1 Dager i uka property gjelder:

MondayTuesdayWednesdayThursdayFridaySaturdaySundayEverydayWeekdaysWeekend

WeeksOfMonth WeeksofMonthListOfEnumerations 0: 1 Uker i måneden property gjelder:

12345EveryWeek

(valg) MonthOfyear xsd:gMonth 0: 1 Måned i året

(valg) DayOfYear xsd:gMonthDay 0: 1 Dag i året (f.eks. "hver 1. april")

Timeband

Timeband < DataManagedObject

Navn Type Kardinalitet Beskrivelse

StartTime xsd:time 1: 1 Starttidspunkt

EndTime xsd:time 1: 1 Sluttidspunkt

Duration xsd:duration 0: 1 Varighet av periodenBruk, avhenger av kontekstog om påkrevd,

DayTypeAssignment

DayTypeAssignment < < Assignment DataManagedObject

Navn Type Kardinalitet Beskrivelse

Beskrivelse av egenskaper en dagtype kan ha

Se definisjon under Generell informasjon

Generell type for angivelse av tid eller periode, f.eks. et tidspunkt, fra-til tid, varighet (v.h.a. Duration) eller brukt for å dele opp enoperasjonsdag i ulike "modus"

Merk at vi tidspunkt-angivelse skal oppgis med StartTime og EndTime som samme klokkeslett (p.g.a. at begge verdiene erpåkrevde elementer)

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Kobling mellom DayType og OperatingDay

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

ServiceCalendarRef CalendarRef 0: 1 Referanse til ServiceCalendar

(valg) OperatingPeriodRef

(valg) OperatingDayRef

(valg) Date

OperatingPeriodRef

OperatingDayRef

xsd:date

1: 1 Referanse til OperatingPeriod

Referanse til OperatingDay

Ellers brukes vanlig dato istedenfor OperatingPeriodRef / OperatingDayRef

DayTypeRef DayTypeRef 1: 1 Referanse til DayType

isAvailable xsd:boolean 0: 1 Dette feltet spesifiserer unntak (f.eks. unntatt 1. April)

OperatingDay

OperatingDay < DataManagedObject

Navn Type Kardinalitet Beskrivelse

CalendarDate xsd:Date 1: 1 Dato for OperatingDay. Dette feltet spesifiserer startdato for operasjonsdag. Tidspunkt og varighet er definert vha andrefelter.

ServiceCalendarRef CalendarRef 0: 1 Referanse til tilhørende . ServiceCalendar

N.B: Én kalendarsdag kan dekkes av forskjellige OperatingDay objekter (f.eks. fra forskjelligeoperatørene). I dette tilfellet anbefales det å lage forskjellige ServiceCalendar-objekter.

Name MultilingualString 0: 1 Navn for OperatingDay

EarliestTime xsd:time 1: 1 Start tidspunkt på dagen

DayLength xsd:duration 1: 1 Varighet av OperatingDay (ingen øvrig grense)

OperatingPeriod

OperatingPeriod < DataManagedObject

Navn Type Kardinalitet Beskrivelse

ServiceCalendarRef CalendarRef 0: 1 Referanse til tilhørende . ServiceCalendar

N.B: Samme kalenderdag kan være dekket av flere OperatingPeriod-objekter, f.eks.fra forskjellige operatører. I slike tilfeller anbefales det å lage separateServiceCalendar-objekter.

(valg) FromDate

(valg) FromDateRef

xsd:dateTime

OperatingDayRef

1: 1 Periodens startdato

Referanse til som beskriver periodens startdagOperatingDay

(valg) ToDate

(valg) ToDateRef

xsd:dateTime

OperatingDayRef

1: 1 Periodens sluttdato

Referanse til som beskriver periodens sluttdagOperatingDay

Timing

En operasjonsdag er en dag når offentlig transport-tjeneste tilbys og er definert i Service Calendar. En operasjonsdag kan varelengre enn 24 timer.

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

En operasjonsperiode er perioden fra en OperatingDay eller dato, eventuelt intervallet mellom to OperatingDay / datoer, nåroffentlig transport-tjeneste tilbys og er definert i Service Calendar.

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

JourneyWaitTime

JourneyWaitTime < < JourneyTiming VersionedChild < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

TimingPointRef TimingPointRefStructure 0: 1 Referanse til TimingPoint

WaitTime xsd:duration 1: 1 Ventetid

JourneyPatternWaitTime

JourneyWaitTime < JourneyWaitTime < < JourneyTiming VersionedChild < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

JourneyRef JourneyPatternRef 1: 1 Referanse til JourneyPattern

JourneyRunTime

JourneyRunTime < JourneyTiming < VersionedChild < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

TimingLinkRef TimingLinkRef 0: 1 Referanse til TimingLink

RunTime xsd:duration 1: 1 Kjøretid

TimingLink

Ventetid ved et TimingPoint

Se definisjon under Generell informasjon

Ventetid ved et TimingPoint i et gitt JourneyPattern

Se definisjon under Generell informasjon

Kjøretid fra ett TimingPoint til neste (d.v.s. å kjøre hele TimingLink)

Se definisjon under Generell informasjon

En lenke (med retning) mellom to TimingPoint objekter

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TimingLink < < Link DataManagedObject

Navn Type Kardinalitet Beskrivelse

FromPointRef TimingPointRef 1: 1 Start TimingPoint

ToPointRef TimingPointRef 1: 1 Slutt TimingPoint

JourneyPatternRunTime

JourneyPatternRunTime < JourneyRunTime < JourneyTiming < VersionedChild < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

LinkRef TimingLinkRef 1: 1 Referanse til for Turnaround TimeTimingLink

JourneyRef JourneyPatternRef 1: 1 Referanse til JourneyPattern

JourneyHeadway

JourneyHeadway < JourneyTiming < VersionedChild < < EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

ScheduledHeadwayInterval xsd:duration 0: 1 Planlagt intervall mellom avganger

MinimumHeadwayInterval xsd:duration 0: 1 Minimal intervall mellom avganger

MaximumHeadwayInterval xsd:duration 0: 1 Maks intervall mellom avganger

Constraints

CheckConstraint

CheckConstraint < Assignment < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

CheckProcessType CheckContraintProcessEnum 0: 1 Klassifisering av type kontroll / restriksjon / hinder:

baggageCheckinbaggageReclaimcheckinbaggageSecurityCheckboarding

delay CheckConstraintDelay 0: 1 Forsinkelse

validityConditions ValidityCondition 0: * Gyldighetsbetingelser 

CheckConstraintDelay

Kjøretid fra ett TimingPoint til neste (d.v.s. å kjøre hele TimingLink) på et gitt JourneyPattern.

Se definisjon under Generell informasjon

Intervall mellom to avganger (service frekvens)

Se definisjon under Generell informasjon

Begrensninger som gjelder for , f.eks. innsjekkingstidspunkt, sikkerhetssjekk. Kun rådgivende, ikke for bruk iServiceJourneyreiseplanlegger.

Se definisjon under Generell informasjon

Beskrivelse av forsinkelse

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

CheckConstraintDelay < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

CheckConstraintRef CheckContraintRef 0: 1 Referanse tilbake til gjeldende CheckConstraint

AverageDuration xsd:duration 0: 1 Gjennomsnittstid

MinimumDuration xsd:duration 0: 1 Minimumstid

MaximumDuration xsd:duration 0: 1 Maksimumstid

validityConditions ValidityCondition 0: * Gyldighetsbetingelser

Validity Types

ValidityCondition

ValidityCondition < DataManagedObject

Navn Type Kardinalitet Beskrivelse

ConditionedObjectRef ObjectRef 0: 1 Referanse til objektet som ValidityCondition gjelder Dette feltet skal kun brukes dersom ValidityCondition er definert som separat objekt inne iFrame. Ellers vil konteksten bestemme hvilket objekt ValidityCondition hører til, og feltet vildermed ignoreres.

WithConditionRef ValidityConditionRef 0: 1 Dette feltet kan slå sammen flere ValidityCondition objekter vha AND operator

AvailabilityCondition

AvailabilityCondition < < ValidityCondition DataManagedObject

Navn Type Kardinalitet Beskrivelse

FromDate xsd:dateTime 0: 1 Startdato

ToDate xsd:dateTime 0: 1 Sluttdato

IsAvailable xsd:boolean 1: 1 Flag for å angi om tjenesten er tilgjengelig (TRUE) eller ikke (FALSE)

dayTypes DayTypeRef 0: * DayType som bestemmer når ValidityCondition gjelder. Merk at feltet skal brukes samtidig med operatingDays i samme ValidityConditionikke

timebands Timeband 0: * Tidsperiode når ValidityCondition gjelder. Brukes bl.a. for å spesifisere åpningstider.

operatingDays OperatingDay 0: * Virkedager når ValidityCondition gjelder. Merk at feltet skal brukes samtidig med dayTypes i samme ValidityCondition.ikke

Betingelse som spesifiserer når et gitt objekt eller sett av objekter (eller frame) er gyldig, f.eks. når en linje opererer eller når enstasjon er åpen, eller når det forventes avvik. Kan settes på alle relevante objekter i en PublicationDelivery, skal som generell regeldefineres på så overordnet (høyt opp i hierarkiet) som hensiktsmessig.

Ingen validityCondition = alltid gyldigTillatt "open ended" (kun periodens start / slutt er definert)Tillatt å definere én eller flere perioder (men bør for entydighet ikke overlappe)

For Line skal skal det settes en validityCondition dersom linjen ikke alltid er i drift (f.eks. sesong-ruter), slik at det er åpenbart omrutedata er levert for gyldighetsperioden.

Se definisjon under Generell informasjon

Merk at ValidityCondition enten settes for CompositeFrame og da gjelder underliggende frames, eller må settes per Frame nåralledisse ikke leveres gruppert. (Med begrenset mulighet for å overstyre ValidityCondition ned på objektnivå der hvor relevant.)

Eksempel finnes for innsending som CompositeFrame eller som enkeltvise frames i Rutebankens offisielle GitHub-repository

ValidityCondition forklart med datoer, dagtyper og dag egenskaper. 

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes for og datasett i "available" "unavailable" Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

operatingPeriods OperatingPeriod 0: * Periode når ValidityCondition gjelder. Brukes i stedet for enkeltdager når dette blir litehensiktsmessig beskrivelse.

ValidBetween

ValidBetween < < ValidityCondition DataManagedObject

Navn Type Kardinalitet Beskrivelse

FromDate xsd:dateTime 0: 1 Start tidspunkt

ToDate xsd:dateTime 0: 1 Slutt tidspunkt

ValidityTrigger

ValidityTrigger < < ValidityCondition DataManagedObject

Navn Type Kardinalitet Beskrivelse

TriggerObjectRef ObjectRef 0: 1 Referanse til objekt (f.eks. event) som er trigger for ValidityCondition

Transport Modes

Mode

(withcorrespondingsubmodeelement)

( )

air

(AirSubmode)

bus

(BusSubmode)

cableway

(TelecabinSubmode)

coach

(CoachSubmode)

funicular

(FunicularSubmode)

metro

(MetroSubmode)

Submodes (allowed

)values

( )

domesticFlight airportLinkBus telecabin internationalCoach funicular metro

helicopterService expressBus nationalCoach urbanRailway

internationalFlight localBus touristCoach

nightBus

railReplacementBus

regionalBus

schoolBus

Forenklet versjon av ValidityCondition angitt bare med start og slutt tidspunkt

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Referanse til et objekt, f.eks. event eller helligdag som "starter" en gitt ValidityCondition

Se definisjon under Generell informasjon

Tillatte transporttyper med underkategori. Disse er definert av og er basert påAllVehicleModesOfTransportEnumerationTPEG klassifisering.

air = fly / helikopterbus = busscableway = gondolbane og annen type transport hengende på kabelcoach = langdistanse-buss (normalt med ekstra baggasjeplass og eventuelt andre fasiliteter)funicular = skinnegående kabelbanemetro = T-bane / bybanerail = togtaxi = taxi (f.eks. supplerings- og erstatningstransport)tram = trikkwater = vanngående transport

Se vedlegg for nærmere beskrivelse med eksempler

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

shuttleBus

sightseeingBus

Mode

(with correspondingsubmode element)

( )

rail

(RailSubmode)

taxi

(TaxiSubMode)

tram

(TramSubmode)

water

(WaterSubmode)

Submodes ( )allowed values

( )

airportLinkRail charterTaxi localTram highSpeedPassengerService

international communalTaxi highSpeedVehicleService

interregionalRail waterTaxi internationalCarFerry

local internationalPassengerFerry

longDistance localCarFerry

nightRail localPassengerFerry

regionalRail nationalCarFerry

touristRailway sightseeingService

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

stops

Innhold

KomponenterPlace

TopographicPlaceAddressablePlaceSiteElementSite

LevelEntrance

Group of Stop PlacesGroupOfStopPlaces

Stop PlaceStopPlaceStopPlaceSpaceQuayBoardingPositionInner Objects

AccessSpacePathLinkPathJunctionEquipmentPlaceSiteFacilitySet

Flexible Stop PlaceFlexibleStopPlaceFlexibleQuayFlexibleAreaHailAndRideArea

Point of InterestPointOfInterest

ParkingParkingParkingAreaParkingPropertiesParkingCapacity

NavigationSiteConnection

SiteConnectionEndStructureNavigationPath

PathLinkEndStructure

Dette dokumentet er en del av NeTEx profil Norge og beskriver dataelementer for utveksling av - og -relatertsted stoppestedinformasjon over NeTEx-formatet. 

Komponenter

Place

TopographicPlace

TopographicPlace < < < Place Zone GroupOfPoints < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

VersjonGjeldende versjon for stops er:   v1.2   (sist endret  ) 12 Sep 2017

Abstrakt datatype for geografisk bosettingssted som by, bygd eller bydel

Se definisjon under Generell informasjon

Defineres i SiteFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

IsoCode SubdivisionIdType 0: 1 ISO 3166-2 kode for å identifisere fylke / territorium

Dvs. [LK]-[OK]LK = to-bokstavers landskode [LK] i henhold til ISO 3166-1 alfa-2OK = to-siffers områdekode [OK] i henhold til ISO 3166-2:NO

Eksempler:

NO-02 – AkershusNO-09 – Vest Agder

TopographicPlaceType TopographicPlaceTypeEnumeration 0: 1 Klassifisering av område:

country ( )landcounty ( )fylkecity ( )byinterregion ( )flerregionalmunicipality ( )kommuneplaceOfInterestregion ( )område/region

CountryRef CountryPrincipalityCodeType 0: 1 To-bokstavers landskode i henhold til ISO 3166-1 alfa-2

Kun påkrevd ved TopographicPlaceType "county"

ParentTopographicPlaceRef TopographicPlaceRef 0: 1 Referanse til "foreldre"-området hvor det aktuelle området erinkludert i. F.eks refererer kommune til fylke.

AddressablePlace

AddressablePlace < < < Place Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Url xsd:anyURI 0: 1 URL relatert til stedet

PostalAddress PostalAddress 0: 1 Postadresse for stedet

RoadAddress RoadAddress 0: 1 Fysisk adresse for stedet

Kreves for objekter som er relevant å kople mot nærliggende vei, jf. og / Entrance StopPlace Quay

SiteElement

SiteElement < < < < AddressablePlace Place Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

AccessibilityAssessment AccessibilityAssessment 1: 1 forStopPlace

Universell Utforming - Beskrivelse, se Accessibility Assessment definisjon

alternativeNames AlternativeName 0: * Liste av alternative navn for Site

PublicUse PublicUseEnumeration 0: 1 Spesifiserer hvem stedet er tilgjengelig for:

allpublicOnlyauthorisedPublicOnlydisabledPublicOnlystaffOnly

Covered CoveredEnumeration 0: 1 Spesifiserer om stedet har tak:

covered ( )kun takindoorsoutdoorsmixed ( )delvis tak/innendørs og delvis utendørs

Et sted som kan ha adresseinformasjon

Se definisjon under Generell informasjon

Abstrakt type som beskriver et overordnet sted

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Gated GatedEnumeration 0: 1 Spesifiserer om stedet/området er lukket (f.eks. inngjerdet) eller åpent (fritttilgjengelig):

openAreagatedAreaunknown

Lighting LightingEnumeration 0: 1 Spesifiserer hvordan stedet er belyst:

wellLitpoorLitunlitunknown

facilities SiteFacilitySet 0: * Liste av tilgjengelige fasiliteter

Site

Site < < < SiteElement AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

TopogpaphicPlaceRef TopographicPlaceRef 0: 1 Referanse til området stedet tilhører ( )TopographicPlace

Locale Locale 0: 1 Informasjon om lokalitet

OrganisationRef OrganisationRef 0: 1 Referanse til ansvarlig organisasjon

ParentSiteRef ParentSiteRef 0: 1 Referanse til som inneholder denne site. SiteVerdien er kontekstavgengig

levels Level 0: * Liste av etasjer på Site

entrances Entrance 0: * Beskrivelse av inngangsobjekter ( )påkrevd hvis bygning

equipmentPlaces EquipmentPlace 0: * Beskrivelse av utstyr

Brukes for å sette Location for PlaceEquipment / LocalService dersom relevant

placeEquipments Equipment 0: * Beskrivelse av tilgjengelig Installed Equipment

localServices Equipment 0: * Beskrivelse av tilgjengelige LocalServices

Level

Level < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn, f.eks. "1", "A", "første"

Description MultilingualString 0: 1 Beskrivelse

PublicUse xsd:boolean 0: 1 Spesifiserer om etasjen kan brukes av alle, eller det kreves spesiell tillatelse

AccessibilityAssessment AccessibilityAssessment 0: 1 Universell Utforming - Beskrivelse

Entrance

Abstrakt type som beskriver et sted

Se definisjon under Generell informasjon

Etasjebeskrivelse

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

Inngangsbeskrivelse

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Entrance < SiteComponent < < SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

LevelRef LevelRef 0: 1 Referanse til etasje ( )Level

checkConstraints CheckConstraint 0: * Beskrivelse av sikkerhetssjekk, barrierer eller liknende som kan gi forsinkelser

equipmentPlaces EquipmentPlace 0: * Beskrivelse av utstyr som finnes tilgjengelig

placeEquipments InstalledEquipment 0: * Beskrivelse av montert utstyr. Se for mer informasjon om hva slags objekterEquipment Typessom kan brukes her.

EntranceType EntranceEnumeration 0: 1 Klassifisering av inngang:

openingopenDoordoorswingDoorrevolvingDoorautomaticDoorticketBarriergate

isEntry xsd:boolean 0: 1 Spesifiserer om objektet er en inngang

isExit xsd:boolean 0: 1 Spesifiserer om objektet er en utgang

Width xsd:decimal 0: 1 Bredde på inngangen (meter)

Height xsd:decimal 0: 1 Høyde på inngangen (meter)

Group of Stop Places

GroupOfStopPlaces

GroupOfStopPlaces  <  GroupOfEntities  <  DataManagedObject

Navn Type Kardinalitet Beskrivelse

members StopPlaceRef 2: * Liste med referanser ( ) til stoppestedene som hørerStopPlace ID fra Nasjonalt Stoppestedsregisterinnunder gruppen

alternativeNames AlternativeName 0: * Liste av alternative navn for stoppestedsgrupperingen

Stop Place

StopPlace

StopPlace < < Site  < SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

(attr) modification ModificationEnumeration 0: 1 Type endring ( )oppgis som "delete" ved nedleggelse av stoppested

Gruppering av stoppesteder som normalt refereres felles, for eksempel gjennom gjensidig tilknytning eller områdetilhørighet.

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Beskrivelse av stoppested

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Description normalizedString 0: 1 Benyttes dersom nødvendig med ytterligere forklarende tekst.kun

F.eks. beskrive status etter nedleggelse ("fysisk fjernet", "skilt fjernet","urørt" e.l.)

TransportMode VehicleModeEnumeration 1: 1 Hoved-transporttype som er tilgjengelig på stoppestedet

Se for mulige verdierTransport Modes

(valg) AirSubmode AirSubmodeEnumeration 0: 1 Underkategori for fly

Se Transport Modes for mulige verdier

(valg) BusSubmode BusSubmodeEnumration 0: 1 Underkategori for buss

Se Transport Modes for mulige verdier

(valg)FunicularSubmode

FunicularSubmodeEnumration 0: 1 Underkategori for gondolbane

Se Transport Modes for mulige verdier

(valg) MetroSubmode MetroSubmodeEnumration 0: 1 Underkategori for T-bane

Se Transport Modes for mulige verdier

(valg) TramSubmode TramSubmodeEnumration 0: 1 Underkategori for trikk

Se Transport Modes for mulige verdier

(valg)TelecabinSubmode

TelecabinSubmodeEnumration 0: 1 Underkategori for kabelbane

Se Transport Modes for mulige verdier

(valg) RailSubmode RailSubmodeEnumration 0: 1 Underkategori for tog

Se Transport Modes for mulige verdier

(valg) WaterSubmode WaterSubmodeEnumration 0: 1 Underkategori for vanntransport

Se Transport Modes for mulige verdier

OtherTransportModes VehicleModeListOfEnumerations(tilsvarer

)VehicleModeEnumeration

0: * Liste av andre tilgjengelige transporttyper (gyldige verdier er samme)som for hoved-transporttyper

Se Transport Modes for mulige verdier

tariffZones TariffZoneRef 0: * Referanser til takstsoner ( ) som gjelder på stoppestedetTariffZone

StopPlaceType StopTypeEnumeration 1: 1 Klassifisering av stoppested:

onstreetBus (busstopp)onstreetTram (trikkestopp)airport (flyplass)railStation (togstopp)metroStation (T-banestopp)busStation (bussterminal)harbourPort (bilferjekai)ferryStop (passasjerbåtkai)liftStation (kabelbanestopp)

Påkrevd når StopPlace har underliggende Quay(s).Ikke påkrevd dersom det er multimodalt StopPlace (StopPlace utenQuays men med underliggende StopPlaces for hver aktuell modalitet)

BorderCrossing xsd:boolean 0: 1 Om stoppestedet er en grenseovergang

Weighting InterchangeWeightingEnumeration 0: 1 Relativ vekting for for stoppestedets overgangsmulighet(er):

preferredInterchangerecommendedInterchangeinterchangeAllowednoInterchange

quays Quay 1: * (for leaf)StopPlace

0 (for parentStopPlace eller

)ukjent Quay

Liste av Quays som finnes på stoppestedet

Èn eller flere for normale stoppesteder med spesifikke av- ogpåstigningspunkterAlltid null for multimodal StopPlace som utelukkende består avsub-StopPlaces

accessSpaces AccessSpace 0: * Liste av venteområder på stoppestedet

pathLinks PathLink 0: * Element som beskriver en del av en ganglenke

pathJunctions PathJunction 0: * Del av ganglenke som beskriver et punkt hvor èn eller flere PathLinkser forbundet

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

navigationPaths NavigationPath 0: * Beskrivelse av ganglenker inne på eller i tilknytning til stoppestedet

Brukes når pathLinks skal overstyres, eller dersom det ikke erkunrelevant å definere pathLinks for stoppestedet

StopPlaceSpace

StopPlaceSpace <   <  < < <   <    < SiteElement AddressablePlace Place Zone GroupOfPoints GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

entrances Entrance 0: * Beskrivelse av innganger

Quay

Quay < < < StopPlaceSpace SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

PrivateCode xsd:normalizedString 0: 1 Internkode som ikke benyttes i publikumstjenester

PublicCode xsd:normalizedString 0: 1 Publikumskode for Quay (f.eks. k )ode publisert på skilt

(attr) modification xs:ModificationEnumeration 0: 1 Type endring ( )oppgis som "delete" ved nedleggelse av enkelt-Quay på et stopp

CompassBearing AbsoluteBearingType 0: 1 Orientering (grader)

boardingPositions BoardingPosition 0: * Liste av av/påstigningspunkter langs Quay (typisk A, B, C, D, osv)

Brukes for togkun

BoardingPosition

BoardingPosition < < StopPlaceSpace  < SiteElement  < AddressablePlace < Place < Zone  GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Label MultilingualString 1:1 Identifikator som kan vises til publikum (f.eks påstigningssone "A")

BoardingPositionType BoardingPositionTypeEnumeration 1:1 Klassifisering for BoardingPosition:

positionOnRailPlatform

Inner Objects

AccessSpace

En abstrakt klasse som beskriver detaljer for et område inne på StopPlace

Se definisjon under Generell informasjon

En del av der passasjerer kan stige av og på kjøretøy (f.eks. busslomme, togplatform eller gate på flyplass)StopPlace

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Merk at:

Det skal settes navn per quay Quay (dette arves fra parent StopPlace)ikkeQuayType skal oppgis, men skal utledes av TransportMode / StopPlaceType (da NeTEx profil Norge tillaterikke ikkemodellering av multimodale Quays under samme StopPlace)

Beskrivelse av et av/påstigningspunkt - Kun for tog!

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

AccessSpace < < StopPlaceSpace  < SiteElement  < AddressablePlace < Place < Zone  GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

AccessSpaceType AccessSpaceTypeEnumeration 1: 1 Klassifisering av AccessSpace:

concourse (f.eks. hovedområdet Oslo S, spesifisering av hvilken terminal på)Gardermoen osv.

underpassoverpasspassageliftwaitingRoomstaircase

PathLink

PathLink <  < Link DataManagedObject

Navn Type Kardinalitet Beskrivelse

From PathLinkEndStructure 1: 1 Startsted for PathLink

To PathLinkEndStructure 1: 1 Endepunkt for PathLink

Description MultilingualString 0: 1 Overordnet beskrivelse

AccessibilityAssessment AccessibilityAssessment 0: 1 Universell Utforming - Beskrivelse (av ganglenken)

Legges kun inn dersom AccessibilityAssessment for som PathLinkNavigationPather del av må presiseres ytterligere

Covered CoveredEnumeration 0: 1 Mulige verdier:

indoorsoutdoorsmixed

Gated GatedEnumeration 0: 1 Mulige verdier:

gatedAreaopenArea

Lighting LightingEnumeraion 0: 1 Mulige verdier:

wellLitpoorlyLitunlitunknown

AllowedUse DirectionOfUseEnum 0: 1 Mulige verdier:

updownboth

Transition TransitionEnum 0: 1 Mulige verdier:

updownlevelupAndDowndownAndUp

Beskrivelse av venteområde på StopPlace

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

En lenke mellom to -objekter som beskriver ett ledd av en (mulig) rute / ganglenke mellom disse.Place

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

AccessFeatureType AccessFeatureEnum 0: 1 Mulige verdier:

liftescalatortravelatorrampstairscrossingbarriernarrowEntranceconcoursequeueManagementstreetpavementfootpathpassage

PassageType PassageTypeEnum 0: 1 Mulige verdier:

pathwaycorridoroverpassunderpasstunnelnone

TransferDuration TransferDuration 0: 1 Tiden man bruker på å traversere ganglenken

checks CheckConstraint 0: 1 Prosess eller begrensning som kan gi kø / forsinkelse

PathJunction

PathJunction  <    < Point DataManagedObject

Navn Type Kardinalitet Beskrivelse

Covered CoveredEnumeration 0: 1 Mulige verdier:

indoorsoutdoorscoveredmixed

Gated GatedEnumeration 0: 1 Mulige verdier:

gatedAreaopenArea

Lighting LightingEnumeraion 0: 1 Mulige verdier:

wellLitpoorlyLitunlitunknown

EquipmentPlace

EquipmentPlace < < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

placeEquipments Equipment 0: * Beskrivelse av tilgjengelig utstyr. Her skal det brukes som arver fra Equipment. For mer detaljerklassenese .EquipmentTypes

SiteFacilitySet

Et krysningspunkt inne på - eller i tilknytning til - et eller , hvor møtes eller splittes.StopPlace PointOfInterest PathLinks

Se definisjon under Generell informasjon

Tilgjengelig utstyr på en Site

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

SiteFacilitySet < < FacilitySet DataManagedObject

Navn Type Kardinalitet Beskrivelse

LuggageLockerFacilityList LuggageLockerFacilityLisfOfEnumerations 0: 1 Mulige verdier:

lockers

LuggageServiceFacilityList LuggageServiceFacilityLisfOfEnumerations 0: 1 Mulige verdier:

leftLuggagebaggageChekInCheckOut

ParkingFacilityList ParkingFacilityLisfOfEnumerations 1: 1 Mulige verdier:

carParkparkAndRideParkmotorcycleParkcyclePark

Flexible Stop Place

FlexibleStopPlace

FlexibleStopPlace < <  Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

TransportMode VehicleModeEnumeration 1: 1 Hoved-transporttype som er tilgjengelig på stoppestedet

Se for mulige verdierTransport Modes

areas (valg) FlexibleArea 1: * (må oppgi minst 1 av denne eller)HailAndRideArea

Soner hvor bestillingstransport er tilgjengelig

(valg) HailAndRideArea 1: * (Må oppgi minst 1 av denne eller)FlexibleArea

Veiseksjoner hvor det er mulig å stoppe kjøretøy ved ågi signal

FlexibleQuay

FlexibleQuay < <  Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

TransportMode VehicleModeEnumeration 0: 1 Transporttype for delområdet (når behov for å overstyre transporttypen definert overordnetfor dette objektet tilhører)FlexibleStop

Se for mulige verdierTransport Modes

FlexibleArea

Beskrivelse av tjenester tilgjengelig for en Site

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Beskrivelse av stoppestedsområde for bestillingstransport

Se definisjon under Generell informasjon

Defineres i SiteFrame

Beskrivelse av spesifikt område hvor bestillingstransport er tilgjengelig

Se definisjon under Generell informasjon

Defineres i SiteFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

FlexibleArea < < < FlexibleQuay  Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name normalizedString 0: 1 Områdenavn ( )hvis behov for å overstyre / detaljere

Description normalizedString 0: 1 Områdebeskrivelse (hvis behov for å overstyre / detaljere)

destinations DestinationDisplayRef 0: * Referanser til objekterDestinationDisplay

HailAndRideArea

HailAndRideArea < < FlexibleQuay  <  Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

destinations DestinationDisplayRef 0: * Referanser til objekterDestinationDisplay

StartPointRef PointRef 1: 1 Start av seksjon

EndPointRef PointRef 1: 1 Slutt av seksjon

Point of Interest

PointOfInterest

PointOfInterest < < < Site SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

nearTopographicPlaces TopographicPlaceRef 0: * Referanser til -objekter i nærhetenTopographicPlace

pathLinks PathLink 0: * Element som beskriver en del av en ganglenke

pathJunctions PathJunction 0: * Del av ganglenke som beskriver et punkt hvor èn eller flere er forbundetPathLinks

navigationPaths NavigationPath 0: * Beskrivelse av vei til/fra POIBrukes når overstyring av pathLinks eller frittstående hvis ikke relevant å definerekun

 pathLinks for stoppestedet

Parking

Parking

Beskrivelse av område for bestillingstransport, realiserer en FlexibleQuay

Se definisjon under Generell informasjon

Beskrivelse av område hvor det er mulig å stoppe kjøretøy ved å gi signal

Se definisjon under Generell informasjon

En lokasjon som kan være av interesse for noen av de reisende, f.eks. et museum, stadion, monument, osv.

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Sted for parkering

Merk at en Parking alltid må referere til en StopPlace gjennom Site/parentSiteRef.

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Parking < < Site  < SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

pathLinks PathLink 0: * Element som beskriver en del av en ganglenke

pathJunctions PathJunction 0: * Del av ganglenke som beskriver et punkt hvor èn eller flere PathLinkser forbundet

navigationPaths NavigationPath 0: * Veibeskrivelse til/fra parkeringBrukes når pathLinks skal overstyres, eller dersom det ikke erkunrelevant å definere pathLinks for stoppestedet

ParkingType ParkingTypeEnumeration 0: 1 Klassifisering av parkering:

parkAndRide

ParkingVehicleType ParkingVehicleEnumeration 0: 1 Type kjøretøy:

carmotorcyclepedalCycle

ParkingLayout ParkingLayoutEnumeration 0: 1 Utforming av parkering:

openSpacemultistoreyundergroundroadside

PrincipalCapacity xsd:nonNegativeInteger 0: 1 Tilgjengelige parkeringsplasser for publikum (ekslusive reserverte)plasser

TotalCapacity xsd:nonNegativeInteger 0: 1 Total antall parkeringsplasser ( )inklusive reserverbare plasser

Dersom ikke kjent om plasser er , oppgis TotalCapacireserverbare kunty

OvernightParkingPermitted xsd:boolean 0: 1 Spesifiserer om det er tillatt å la kjøretøy stå parkert over natta

RechargingAvailable xsd:boolean 0: 1 Spesifiserer om ladestasjoner er tilgjengelig

Secure xsd:boolean 0: 1 Spesifiserer om parkeringer er sikret (overvåket / bevoktet)

RealTimeOccupancyAvailable xsd:boolean 0: 1 Spesifiserer om det finnes sanntidsinformasjon om ledige plasser

ParkingReservation ParkingReservationEnumeration 0: 1 Reservajoner:

noReservationsregistrationRequiredreservationRequiredreservationAllowed

BookingUrl xsd:anyURI 0: 1 URL for reservasjon

FreeParkingOutOfHours xsd:boolean 0: 1 Spesifiserer om parkering er gratis utenom "kontortid"

parkingProperties ParkingProperties 0:* Tilleggsegenskaper for parkering

parkingAreas ParkingArea 0: * Beskrivelse av områder inne på parkeringen

ParkingArea

ParkingArea < ParkingComponent < < SiteComponent < SiteElement  < AddressablePlace < Place < Zone GroupOfPoints  < GroupOfEntities  < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Label MultilingualString 0: 1 Identifikator som kan vises til publikum

TotalCapacity xsd:nonNegativeInteger 0: 1 Total kapasitet ( )for det spesifikke området

ParkingProperties ParkingProperties 0: 1 Tilleggsegenskaper

ParkingProperties

Område inne på en parkering

Se definisjon under Generell informasjon

TIlleggsegenskaper for parkering

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

ParkingProperties < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

ParkingUserTypes ParkingUserListOfEnumerations 0: 1 Brukerklassifisering:

allregisteredregisteredDisabledresidentsWithPermits

MaximumStay xsd:duration 0: 1 Maksimalt tillatt parkeringstid

spaces ParkingCapacity 0: * Detaljert beskrivelse av kapasitet

ParkingCapacity

ParkingCapacity < VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

ParkingVehicleType ParkingVehicleEnumeration 1: 1 Type kjøretøy:

carmotorcyclepedalCycle

ParkingStayType ParkingStayEnumeration 0: 1 Parkeringsbehov:

shortStaylongTermdropoffunlimited

NumberOfSpaces xsd:nonNegativeInteger 0: 1 Antall plasser

Navigation

SiteConnection

SiteConnection < < Transfer DataManagedObject

Navn Type Kardinalitet Beskrivelse

From SiteConnectionEndStructure 1: 1 Startpunkt for SiteConnection

To SiteConnectionEndStructure 1: 1 Sluttpunkt for SiteConnection

navigationPaths NavigationPath 0: * Mulige ganglenker mellom -objekteneSite

SiteConnectionEndStructure

SiteConnectionEnd

Navn Type Kardinalitet Beskrivelse

StopPlaceRef StopPlaceRef 0: 1 Referanse til den aktuelle StopPlace

QuayRef QuayRef 0: 1 Referanse til den aktuelle Quay

StopPlaceEntranceRef StopPlaceEntranceRef 0: 1 Referanse til den aktuelle Entrance

Se definisjon under Generell informasjon

Kapasitetsbeskrivelse for parkering

Se definisjon under Generell informasjon

Fysisk mulighet for å komme fra et sted i en Site til en annen Site (f.eks. fra StopPlace til StopPlace, Quay to Quay etc.)

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

NavigationPath

NavigationPath < < LinkSequence DataManagedObject

Navn Type Kardinalitet Beskrivelse

From PathLinkEndStructure 0: 1 Startpunkt for ganglenken

To PathLinkEndStructure 0: 1 Endepunkt for ganglenken

AccessibilityAssessment AccessibilityAssessment 1: 1 Universell Utforming - Beskrivelse (av ganglenken)

TransferDuration TransferDuration 0: 1 Spesifisering av tid(er) for transfer

Covered CoveredEnumeration 0: 1 Mulige verdier:

indoorsoutdoorscoveredmixed

Gated GatedEnumeration 0: 1 Mulige verdier:

gatedAreaopenArea

Lighting LightingEnumeraion 0: 1 Mulige verdier:

wellLitpoorlyLitunlitunknown

NavigationType NavigationTypeEnumeration 1: 1 Type ganglenke:

hallToQuayhallToStreetquayToHallquayToStreetstreetToHallstreetToQuaystreetToSpacestreetTostreetspaceToHallhallToSpacespaceToSpaceother

pathLinksInSequence PathLinkInSequence 0: * Sortert rekkefølge av , som beskriver hver del av det som til sammenPathLinksutgjør ganglenken

PathLinkEndStructure

PathLinkEndSturcture

Navn Type Kardinalitet Beskrivelse

PlaceRef PlaceRef 0: 1 Referanse til Place

Detaljert beskrivelse av stien mellom to steder ( )kan normalt utledes automatisk fra PathLinks

Se definisjon under Generell informasjon

Defineres i SiteFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

network

Innhold

KomponenterNetwork

NetworkGroupOfLinesLine

PresentationTariffZone

ServiceTypeOfService

RouteRouteRoutePointScheduledStopPointTimingPointPointOnRouteRouteLinkServiceLinkStop Assignment

StopAssignmentPassengerStopAssignmentFlexibleStopAssignmentTrainStopAssignment

Journey PatternJourneyPattern

StopPointInJourneyPatternBookingArrangementsStructureTimingPointInJourneyPatternLinkInJourneyPatternTimingLinkInJourneyPatternServiceLinkInJourneyPattern

DestinationDisplayDestinationDisplayVariantVia

Flexible TransportFlexibleLineFlexibleRouteFlexibleLinkPropertiesFlexiblePointPropertiesFlexibleStopAssignmentFlexibleServiceProperties

TransferTransfer

TransferDuration

Dette dokumentet er en del av NeTEx profil Norge og beskriver dataelementer for utveksling av informasjon relatert til   ovtransport-nettverker NeTEx-formatet.

Merk at -delen av profilen beskriver elementer for oppbygging av nettverket (struktur, attributter, geografi m.v.), for datautvekslingnetworkmellom informasjonssystemer og representasjon av denne type data i ruteplanleggingsapplikasjoner o.l., men at tilhørendeutenkalenderspesifiserte avganger er beskrevet (da dette er faller inn under -profildokumentet).timetable

Komponenter

Network

Network

VersjonGjeldende versjon for network er:   v1.2   (sist endret  ) 22 Feb 2018

Transport-nettverk, "paraply" for alle som naturlig representeres sammen ut til publikumLines

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Network < <   < GroupOfLines GroupOfEntities DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Nettverksnavn

AuthorityRef OrganisationRefStructure 1: 1 Organisasjon ansvarlig for nettverket

groupsOfLines GroupOfLines 0: * Linjer ( ) som inngår i nettverketLine

tariffZones tariffZoneRefs 0: * Takstsoner ( ) som inngår i nettverket ( )TariffZone der man har dette

GroupOfLines

GroupOfLines < < GroupOfEntities  DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 1: 1 Navn på gruppering av linjer (f.eks. med tanke på sammenstilling /synliggjøring)

members lineRefs 0: 1 Eksplisitt opplisting av linjer som inngår i gruppen ( )hvis hensiktsmessig

Merk at referanse skal normalt gå fra Line opp til Network gjennom enRepresentedByGroupRef

MainLineRef LineRefStructure 0: 1 Referanse til primærlinje i gruppen

TransportMode AllVehicleModesOfTransportEnumeration 0: 1 Transporttype

Se for mulige verdierTransport Modes

Line

Line < DataManagedObject

Navn Type Kardinalitet Beskrivelse

(attr) modification xs:ModificationEnumeration 0: 1 Type endring ( )oppgis som "delete" ved nedleggelse av linje

Name MultilingualString 1: 1 Linjenavn

ShortName MultilingualString 0: 1 Kortnavn (f.eks. "folkemunnenavn", navn som publikum kjennerlinjen under)

Description MultilingualString   0: 1 Beskrivelse

TransportMode AllVehicleModesOfTransportEnumeration 1: 1 Hovedtransporttype for linjen

Se i Mode Transport Modes for gyldige verdier

(Dette grupperes under eksplisitte , men Network er i seg selv en undertype av GroupOfLines-objektet og kan også refereres frittstående uten eksplisitte GroupofLines.)kan GroupOfLines

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Gruppering av linjer for å kunne referere til disse under ett

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Linje (gruppering av ruter, publisert med et gitt navn eller nummer)

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TransportSubmode TransportSubmode 1: 1 Transporttype-underkategori for linjen

Se i Submodes Transport Modes for gyldige verdier (må væreTransportSubmode  Traav den type som korresponderer med valgtnsportMode)

Url xsd:anyURI 0: 1 URL til nettside med reiseinformasjon for linjen

PublicCode xsd:normalizedString 0: 1 Offentlig identifikator for linjen ( )annonsert identifikator

Vanligvis et nummer, som kan kombineres med en bokstav (f.eks.L2, 31, osv).

Name inneholder normalt mer informasjon enn koden, linjens fullenavn er derfor som regel sammenstillingen av PublicCode ogName.

PrivateCode xsd:normalizedString 0: 1 Intern ( ) identifikator for linjenikke-annonsert

ExternalLineRef ExternalObjectRef 0: 1 Referanse (ID) til relatert Line (f.eks. opprinnelig linje som denne)er erstatningslinje for

OperatorRef OperatorRefStructure 1: 1 Referanse til hoved- (operatør kan unntaksvis unnlates, f.eks.)dersom linje kjøres med egen operatør for hver avgang

additionalOperators transportOrganisationRef 0: * Referanse til tilleggsoperatørene på linjen

TypeOfLineRef TypeOfLineRef 0: 1 Referanse til linjenstype

Klassifisering av linjen (f.eks. erstatningslinje)

Monitored xsd:boolean 1: 1 Spesifiserer om det normalt tilbys sanntidsinformasjon for dennelinjen

routes RouteRef 0: * Referanse til liste av ruter ( ) for den aktuelle linjenRoute

Dette kan normalt utledes fra de som har referanse tilRouteslinjen, og det er kun hensiktsmessig å oppgi når disse er beskrevetfra Line (f.eks. i annen leveranse / fil).

RepresentedByGroupRef GroupOfLinesRefStructure 1: 1 Referanse til (alternativt mer spesifikt til )Network GroupOfLinessom denne Line tilhører

Presentation Presentation 0: 1 Informasjon om grafisk representasjon (farge, tekst, osv)

AccessibilityAssessment AccessitilityAssessment 1: 1 Universell Utforming - Beskrivelse av linjen

Presentation

Presentation

Navn Type Kardinalitet Beskrivelse

Colour ColourValueType 0: 1 Hexadecimal representasjon av fargens RGB-verdier (for henholdsvis rød, grønn og blå)

F.eks. "FFA500" = (255, 165, 0) = Orange

TextColour ColourValueType 0: 1 Hexadecimal representasjon av tekstfargens RGB-verdier (for henholdsvis rød, grønn og blå)

TextFont xsd:normalizedString 0: 1 Font-identifikator (skrifttype)

TariffZone

TariffZone < < < < Zone GroupOfPoints GroupOfEntities  DataManagedObject

Navn Type Kardinalitet Beskrivelse

Beskrivelse av verdier som skal brukes for å presentere linjeinformasjon, som tekst font og farge osv. (f.eks. ved representasjon påkart)

Merk at minimum ett gyldig datafelt (under) må være definert i en gyldig Presentation

Takstsone

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TariffZone arver fra Zone og introduserer ikke nye elementer eller attributter

Service

TypeOfService

TypeOfService < < TypeOfValue DataManagedObject

Navn Type Kardinalitet Beskrivelse

TypeOfService arver fra TypeOfValue og introduserer ikke nye elementer eller attributter

Route

Route

Route < < LinkSequence  DataManagedObject

Navn Type Kardinalitet Beskrivelse

LineRef LineRefStructure 1: 1 Referanse til linje ( ) ruten tilhørerLine

DirectionType DirectionTypeEnumeration 0: 1 Rutens retning:

inboundoutboundclockwiseanticlockwise

pointsInSequence PointOnRoute 1: * Liste av rutens punkter

InverseRouteRef RouteRefStructure 0: 1 Referanse til eventuell rute som går i motsatt retning

RoutePoint

RoutePoint < < Point DataManagedObject

Navn Type Kardinalitet Beskrivelse

BorderCrossing xsd:boolean 0: 1 Spesifiserer om punktet ligger på grensen mellom to land

ScheduledStopPoint

Klassifisering av en service

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Beskrivelse av en rute, spesifisert som en sortert liste av RoutePoints

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Et punkt som utgjør et sted på en rute

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Punkt for planlagt av- og/eller påstigning. Kobling mot / skjer gjennom . StopPlaces Quays StopAssignment AlleScheduledStopPoint må ha en slik kobling.

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

ScheduledStopPoint < < < TimingPoint Point DataManagedObject

Navn Type Kardinalitet Beskrivelse

tariffZones TariffZoneRef 0: 1 Liste av takstsoner ( ) StopPoint tilhørerTariffZone

Presentation Presentation 0: 1 Grafiske elementer relatert til StopPoint

TimingPoint

TimingPoint < < Point DataManagedObject

Navn Type Kardinalitet Beskrivelse

TimingPointStatus TimingPointStatusEnumeration 0: 1 Type av TimingPoint:

timingPointnotTimingPoint (kan indikere passeringstid)antatt

AllowedForWaitTime xsd:duration 0: 1 Tillatt ventetid

PointOnRoute

PointOnRoute < < PointInLinkSequence VersionedChild  < EntityInVersion < Entity 

Navn Type Kardinalitet Beskrivelse

LinkSequenceRef LinkSequenceRefStructure 0: 1 Referanse til punktet tilhører.LinkSequence

Det skal brukes RouteRef, siden arver fra .Route LinkSequence

Merk at feltet skal ikke brukes dersom PointOnRoute defineres inline i .Route

projections Projection 0: * Projeksjon på et punkt (RoutePoint, TimingPoint, SchedueledStopPoint) eller engml-koordinatprojeksjon.

PointRef PointRefStructure 1: 1 Referanse til Point

Det skal brukes RoutePointRef for å peke til tilsvarende .RoutePoint

RouteLink

RouteLink < < Link DataManagedObject

Navn Type Kardinalitet Beskrivelse

FromPointRef RoutePointRef 1: 1 Startpunkt for RouteLink

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Punkt for registrering av passeringstid (normalt at transportmiddelet har stopp eller av-/påstigning for passasjerer)ikke

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Kobling mellom og Route RoutePoint

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Lenke (med retning) mellom to RoutePoints

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

ToPointRef RoutePointRef 1: 1 Endepunkt for RouteLink

ServiceLink

ServiceLink < < Link DataManagedObject

Navn Type Kardinalitet Beskrivelse

Distance xsd:decimal 0: 1 Avstand   for ServiceLink, dvs mellom FromPoint og ToPointi meter kjøreavstand

projections LinkSequenceProjection 1: 1 Projeksjon med <gml:LineString> posisjonsangivelse

FromPointRef ScheduledStopPointRef 1: 1 Startpunkt for ServiceLink

ToPointRef ScheduledStopPointRef 1: 1 Endepunkt for ServiceLink

Stop Assignment

StopAssignment

StopAssignment < < Assignment DataManagedObject

Navn Type Kardinalitet Beskrivelse

ScheduledStopPointRef ScheduledStopPointRef 1: 1 Referanse til ScheduledStopPoint

PassengerStopAssignment

PassengerStopAssignment < < < StopAssignment Assignment  DataManagedObject

Navn Type Kardinalitet Beskrivelse

StopPlaceRef StopPlaceRef 0: 1 Referanse til som er relatert til StopPlace ScheduledStopPoint

Bør inkluderes så langt mulig, men StopPlace for referert Quay kan utledes sentralt vedmanglende StopPlaceRef

QuayRef QuayRef 1: 1 Referanse til en aktuell på Quay StopPlace

trainElements TrainStopAssignmentRef 0: * Referanser til detaljert posisjon på plattform ( )TrainStopAssignment

Brukes kun for tog

FlexibleStopAssignment

FlexibleStopAssignment < < < StopAssignment Assignment  DataManagedObject

Lenke (med retning) mellom to stop points

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Abstrakt klasse som brukes i beskrivelse av kobling mellom ScheduledStopPoint og StopPlace

Se definisjon under Generell informasjon

Kobling mellom og eller ScheduledStopPoint StopPlace Quay

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Defineres i ServiceFrame

Kobling mellom og ScheduledStopPoint FlexibleStopPlace

Defineres i ServiceFrame (på samme måte som )PassengerStopAssignment

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Navn Type Kardinalitet Beskrivelse

FlexibleStopPlaceRef FlexibleStopPlaceRef

1: 1 Referanse til som er relatert til FlexibleStopPlace ScheduledStopPoint

(valg) FlexibleQuayRef FlexibleQuayRef 0: 1 Referanse til en aktuell FlexibleQuay

Kan legges inn som supplement om man har definert FlexibleQuay for hvortransportmiddelet skal stoppe

(valg) FlexibleAreaRef FlexibleAreaRef 0: 1 Referanse til en aktuell FlexibleArea

Kan legges inn som supplement om man har definert FlexibleArea for gjeldendeFlexibleStopPlace

(valg)HailAndRideAreaRef

HailAndRideAreaRef 0: 1 Referanse til en aktuell HailAndRideArea

Kan legges inn som supplement om man har definert HailAndRideArea for gjeldendeFlexibleStopPlace

TrainStopAssignment

TrainStopAssignment < < StopAssignment  < Assignment DataManagedObject

Navn Type Kardinalitet Beskrivelse

PassengerStopAssignmentRef PassengerStopAssignmentRef 0: 1 Referanse til PassengerStopAssignment

TrainRef TrainRef 0: 1 Referanse til Train

TrainComponentRef TrainComponentRef 0: 1 Referanse til aktuell vogn ( )TrainComponent

BoardingPositionRef BoardingPositionRef 0: 1 Referanse til riktig BoardingPosition

EntranceToVehicle MultilingualString 0: 1 Spesifisering av inngang i vognen, f.eks. "front", "rear"

Journey Pattern

JourneyPattern

JourneyPattern < < LinkSequence  DataManagedObject

Navn Type Kardinalitet Beskrivelse

RouteRef RouteRef 1: 1 Referanse til brukt i JourneyPatternRoute

runTimes JourneyPatternRunTime 0: * Beskrivelse av RunTime for JourneyPattern

Brukes kun ved beskrivelse av frekvensbaserte avganger

waitTimes JourneyPatternWaitTime 0: * Beskrivelse av WaitTime for JourneyPattern

Brukes normalt kun ved beskrivelse av frekvensbaserte avganger

headways JourneyPatternHeadway 0: * Beskrivelse av JourneyHeadway for JourneyPattern

Brukes kun for beskrivelse av frekvensbaserte avganger

pointsInSequence PointInJourneyPattern 0: * Sortert liste av punkter i JourneyPattern. Skal være eller StopPointInJourneyPattern Timin.gPointInJourneyPattern

linksInSequence LinkInJourneyPattern 0: * Sortert liste av lenker i JourneyPattern. Må være eller ServiceLinkInJourneyPattern Timing.LinkInJourneyPattern

Kobling mellom (vogn) og / / .TrainComponent StopPlace Quay BoardingPosition

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Sortert liste av  /   og/eller for en en gitt .ScheduledStopPoint TimingPoint Links Route

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

StopPointInJourneyPattern

StopPointInJourneyPattern < < < < PointInLinkSequence VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

ScheduledStopPointRef ScheduledStopPointRef 1: 1 Referanse til ScheduledStopPoint

ForAlighting xsd:boolean 0: 1 Spesifiserer om avstigning er tillatt

Bør angis eksplisitt (normalt "false") for StopPointInJourneyPatternførste

ForBoarding xsd:boolean 0: 1 Spesifiserer om påstigning er tillatt

Bør angis eksplisitt (normalt "false") for StopPointInJourneyPatternsiste

DestinationDisplayRef DestinationDisplayRef 0: 1 Referanse til DestinationDisplay

Er pålagt som minimum at referansen er satt for StopPointInJourneyførste Pattern, med henvisning til den teksten publikum ser når kjøretøyetankommer

Skal også settes hvor visning av destinasjonsinformasjon alle steder endres

FlexiblePointProperties FlexiblePointProperties 0: 1 Egenskaper for stopppunktet relatert til fleksibel transport

RequestStop xsd:boolean 0: 1 Spesifiserer om passasjerer må gi signal for å benytte dette stoppunktet

RequestMethod RequestMethodTypeEnumeration 0: 1 Metode som må brukes for å signalisere at transporten skal stoppe:

handSignalphoneCallsmsstopButtonturnOnLight

BookingArrangements BookingArrangementsStructure 0: 1 Bestemmelser dersom betjening av et stopp må forhåndsbookes

BookingArrangementsStructure

BookingArrangementsStructure

Navn Type Kardinalitet Beskrivelse

BookingContact ContactStructure 1: 1 Kontakinformasjon for å gjøre bestilling

BookingMethods BookingMethodListOfEnumerations 1: 1 Mulige måter å bestille på (må samsvare med info som finnes i):BookingContact

callDrivercallOfficeonlinephoneAtStoptext (sms)

BookingAccess BookingAccessEnumeration 0: 1 Kategorier som har lov å bestille:

publicauthorisedPublic ( )f.eks. TT-transportstaff

BookWhen PurchaseWhenEnumeration 1: 1 Tidspunkt når bestillingen må være gjort:

timeOfTravelOnlydayOfTravelOnlyuntilPreviousDayadvanceOnlyadvanceAndDayOfTravel

LatestBookingTime xsd:time 0: 1 Siste tidspunkt for bestilling

ScheduledStopPoint i et JourneyPattern

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Booking-detaljer for betjening av et spesifikt  ved ikke-fleksibel transport eller ved avvik fra de generelleStopPointInJourneyPatternbooking-bestemmelsene for en FlexibleLine

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

MinimumBookingPeriod xsd:duration 0: 1 Minste periode i forkant av avgang bestillingen må være gjort

BookingNote xsd:normalizedString 0: 1 Tilleggsinformasjon om bestillingen

TimingPointInJourneyPattern

TimingPointInJourneyPattern < < < < PointInLinkSequence VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

TimingPointRef TimingPointRef 1: 1 Referanse til TimingPoint

WaitTime xsd:duration 0: 1 Ventetid

LinkInJourneyPattern

LinkInJourneyPattern < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

(valg) TimingLinkInJourneyPattern TimingLinkInJourneyPattern 1: 1 Sortert liste av TimingLinks

(valg) ServiceLinkInJourneyPattern ServiceLinkInJourneyPattern 1: 1 Sortert liste av ServiceLinks

TimingLinkInJourneyPattern

TimingLinkInJourneyPattern < < < VersionedChild EntityInVersion Entity

Navn Type Kardinalitet Beskrivelse

TimingLinkRef TimingLinkRef 1: 1 Referanse til ServiceLink

ServiceLinkInJourneyPattern

ServiceLinkInJourneyPattern < VersionedChild < EntityInVersion < Entity

Navn Type Kardinalitet Beskrivelse

ServiceLinkRef ServiceLinkRef 1: 1 Referanse til ServiceLink

DestinationDisplay

TimingPoint i et JourneyPattern

Se definisjon under Generell informasjon

Abstrakt type for sortert liste av timing- eller service-links i et JourneyPattern

Se definisjon under Generell informasjon

TimingLink i et JourneyPattern

Se definisjon under Generell informasjon

ServiceLink i et JourneyPattern

Se definisjon under Generell informasjon

Informasjon om retning og destinasjon som typisk vises ombord på kjøretøy

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

DestinationDisplay < DataManagedObject

Navn Type Kardinalitet Beskrivelse

SideText MultilingualString 0: 1 Tekst som vises på siden av transportmiddelet

FrontText MultilingualString 1: 1 Tekst som vises på forsiden av transportmiddelet

vias Via 0: 1 Tilleggsdestinasjon som viser spesifikke steder transportmiddelet passerer på vei til endeligdestinasjon,

F.eks. trikk 11: Majorstuen - Kjelsås o/Torshov

variants DestinationDisplayVariant 0: * Varianter av tekst tilpasset diverse media

Merk at ved sammensatt DestinationDisplay-tekst, f.eks. linjenummer og destinasjonsnavn,  dskalet også som minimum sendes inn DestintaionDisplay for "web" som kun inneholderdestinasjonsnavnet (uten tilleggstekst)

DestinationDisplayVariant

DestinationDisplayVariant < DataManagedObject

Navn Type Kardinalitet Beskrivelse

DestinationDisplayVariantMediaType DeliveryVariantTypeEnumeration 1: 1 Støttet type media:

PrintedTextToSpeechWebMobileother ( )f.eks. sanntidsskjerm

FrontText MultilingualString 1: 1 Forside tekst for DestinationDisplay

Via

Via < VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

DestinationDisplayRef DestinationDisplayRef 1: 1 Referanse til -objekt som beskriver stoppestedet / området kjøretøyetDestinationDisplaypasserer

RoutePointRef RoutePointRef 0: 1 Referanse til RoutePoint

ViaType ViaTypeEnumeration 0: 1 Mulige verdier:

stopPointname

Flexible Transport

FlexibleLine

Eksempel finnes i Rutebankens offisielle GitHub-repository

Variant av DestinationDisplay tilpasset gitt mediatype

Se definisjon under Generell informasjon

Tilleggsdestinasjon som viser spesifikke steder bussen passerer på vei til endelig destinasjon

Se definisjon under Generell informasjon

Flexi-linje (gruppering av ruter for bestillingstransport, publisert med et gitt navn eller nummer)

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

FlexibleLine < < Line DataManagedObject

Navn Type Kardinalitet Beskrivelse

FlexibleLineType FlexibleLineTypeEnumeration 1: 1 Type bestillingstransport:

corridorServicemainRouteWithFlexibleEndsflexibleAreasOnlyhailAndRideSectionsfixedStopAreaWidemixedFlexiblemixedFlexibleAndFixedfixed

BookingContact ContactStructure 1: 1 Kontakinformasjon for å gjøre bestilling

BookingMethods BookingMethodListOfEnumerations 1: 1 Mulige måter å bestille på:

callDrivercallOfficeonlinephoneAtStoptext (sms)

BookingAccess BookingAccessEnumeration 0: 1 Kategorier som har lov å bestille:

publicauthorisedPublic ( )f.eks. TT-transportstaff

BookWhen PurchaseWhenEnumeration 1: 1 Tidspunkt når bestillingen må være gjort:

timeOfTravelOnlydayOfTravelOnlyuntilPreviousDayadvanceOnlyadvanceAndDayOfTravel

BuyWhen PurchaseMomentListOfEnumerations 0: 1 Tidspunkt når bestillingen må betales:

onReservationbeforeBoardingafterBoardingonCheckOut

LatestBookingTime xsd:time 0: 1 Siste tidspunkt for bestilling

MinimumBookingPeriod xsd:duration 0: 1 Minste periode i forkant av avgang bestillingen må være gjort

BookingNote xsd:normalizedString 0: 1 Tilleggsinformasjon om bestillingen

FlexibleRoute

FlexibleRoute < < < Route LinkSequence DataManagedObject

Navn Type Kardinalitet Beskrivelse

FlexibleRouteType FlexibleRouteTypeEnumeration 1: 1 Rutetype for bestillingstransport:

flexibleAreasOnlyhailAndRideSectionsmixedfixed

FlexibleLinkProperties

Rute for bestillingstransport

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Eksempel finnnes i Rutebankens offisielle GitHub-repository

Beskrivelse av fleksibilitetsegenskaper for en gitt RouteLink

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

FlexibleLinkProperties < VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

LinkRef LinkRef 1: 1 Referanse til RouteLink

MayBeSkipped xsd:boolean 0: 1 Spesifiserer om denne seksjonen kan utelates

OnMainRoute xsd:boolean 0: 1 Spesifiserer om denne seksjonen ligger på hovedruten

UnscheduledPath xsd:boolean 0: 1 Spesifiserer om denne seksjonen er en del av ikke-planlagt rute

FlexibleLinkType FlexibleLinkTypeEnumeration 1: 1 Klassifisering av RouteLink:

hailAndRideonDemandfixed

FlexiblePointProperties

FlexiblePointProperties < VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

PointRef PointRef 1: 1 Referanse til Point

MayBeSkipped xsd:boolean 0: 1 Spesifiserer om dette punktet kan utelates

OnMainRoute xsd:boolean 0: 1 Spesifiserer om dette punktet ligger på hovedruten

PointStandingForAZone xsd:boolean 0: 1 Spesifiserer om dette punktet representerer en FlexibleZone

FlexibleStopAssignment

FlexibleStopAssignment < < < StopAssignment Assignment DataManagedObject

Navn Type Kardinalitet Beskrivelse

FlexibleStopPlaceRef FlexibleStopPlaceRef 1: 1 Referanse til FlexibleStopPlace

FlexibleServiceProperties

FlexibleServiceProperties < DataManagedObject

Navn Type Kardinalitet Beskrivelse

FlexibleServiceType FlexibleServiceTypeEnumeration 1: 1 Type fleksibel transport:

dynamicPassingTimesfixedHeadwayFrequencyfixedPassingTimesnotFlexible

Defineres i ServiceFrame

Beskrivelse av fleksibilitetsegenskaper for et gitt Point

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Kobling mellom og ScheduledStopPoint FlexibleStopPlace

Se definisjon under Generell informasjon

Defineres i ServiceFrame

Beskrivelse av egenskaper for fleksibel transport. (Kan bl.a. brukes fra .)ServiceJourney

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

CancellationPossible xsd:boolean 1: 1 Spesifiserer om service kan bli kansellert av operatør

ChangeOfTimePossible xsd:boolean 1: 1 Spesifiserer om tiden kan endres av operatør

BookingMethods BookingMethodListOfEnumerations 1: 1 Mulige måter å bestille på:

callDrivercallOfficeonlineotherphoneAtStoptext

BookingAccess BookingAccessEnumeration 0: 1 Kategorier som har lov å bestille:

publicauthorisedPublic (f.eks. TT-transport)staff

BookWhen PurchaseWhenEnumeration 1: 1 Tidspunkt når bestillingen må være gjort:

timeOfTravelOnlydayOfTravelOnlyuntilPreviousDayadvanceOnlyadvanceAndDayOfTravel

BuyWhen PurchaseMomentListOfEnumerations 0: 1 Tidspunkt når bestillingen må betales:

onReservationbeforeBoardingafterBoardingonCheckOut

LatestBookingTime xsd:time 0: 1 Siste tidspunkt for bestilling

MinimumBookingPeriod xsd:duration 0: 1 Minste periode i forkant av avgang bestillingen måvære gjort

BookingNote xsd:normalizedString 0: 1 Tilleggsinformasjon om bestillingen

Transfer

Transfer

Transfer < DataManagedObject

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Navn for transfer

Description MultilingualString 0: 1 Tekstlig beskrivelse

Distance xsd:decimal 1: 1 Total lengde for transfer (i meter)

TransferDuration TransferDuration 1: 1 Detaljbeskrivelse for tiden en transfer tar

BothWays xsd:boolean 0: 1 Spesifiserer om transfer kan gjøres begge veier

TransferDuration

TransferDuration

Navn Type Kardinalitet Beskrivelse

DefaultDuration xsd:duration 1: 1 Normal varighet

FrequentTravellerDuration xsd:duration 0: 1 Tid det vil ta for en person kjent på stedet å gjøre transfer

OccasionalTravellerDuration xsd:duration 0: 1 Tid det vil ta en for en person ukjent på stedet å gjøre transfer

Abstrakt type som beskriver fysisk mulighet å komme fra et sted til et annet sted. Må ikke forveksles med overgang ( )Interchange

Se definisjon under Generell informasjon

Spesifikasjon av tider en transfer tar basert på type reisende

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

MobilityRestrictedTravellerDuration xsd:duration 0: 1 Tid det til ta en funksjonshemmet person å gjøre transfer

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

timetable

Innhold

KomponenterJourney

JourneyJourneyEndpointStructure

Types of journeyVehicleJourney

JourneyPartFrequencyVehicleJourneyWaitTimeVehicleJourneyRunTimeVehicleJourneyHeadwayTimetabledPassingTime

SpecialServiceServiceJourneyPeriodical journeys

TemplateServiceJourneyJourneyFrequencyGroupRhythmicalJourneyGroupHeadwayJourneyGroup

Coupled journeysCoupledJourneyJourneyPartCouple

ServiceCalendarInterchange

InterchangeServiceJourneyInterchange

Dette dokumentet er en del av NeTEx profil Norge og beskriver dataelementer for utveksling av og andre -relatertkalenderdata rutetplaninformasjon over NeTEx-formatet.

Merk at  -delen av profilen beskriver elementer for oppbygging av timeplaner og rutetabell (datoer, tidspunkter, frekvens osv.), fortimetabledatautveksling mellom informasjonssystemer og representasjon av denne type data i ut til kollektivreisende, basert på overordnedekonsepter fra -profildokumentet.network

Komponenter

Journey

Journey

Journey < < LinkSequence DataManagedObject

Navn Type Kardinalitet Beskrivelse

Description MultilingualString 0: 1 Beskrivelse av avgangen

TransportMode AllVehicleModesOfTransportEnumeration 0: 1 Transporttype

Se i Mode Transport Modes for oversikt over mulige verdier(med tilhørende TransportSubmode).

Merk at hvis overstyring for en Journey, må TransportModbådee og TransportSubmode oppgis

VersjonGjeldende versjon for timetable er:   v1.2   (sist endret  ) 27 Nov 2017

Abstrakt type som beskriver en avgang/reise

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TransportSubmode TransportSubmode 0: 1 Transport-underkategori

Se i Submode Transport Modes for mulige verdier (må være TrarannsportSubmode av den type som korresponderer med valgt T

sportMode)

Merk at hvis overstyring for en Journey, må TransportModbådee og TransportSubmode oppgis

ExternalVehicleJourneyRef ExternalObjectRef 0: 1 Referanse (ID) til relatert VehicleJourney (f.eks. opprinneligavgang som denne erstatter eller er alternativ transport for)

Monitored xsd:boolean 0: 1 Spesifiserer om sanntidsinformasjon er tilgjengelig for avgangen

JourneyEndpointStructure

JourneyEndpointStructure

Navn Type Kardinalitet Beskrivelse

Name MultilingualString   0: 1 Navn

ScheduledStopPointRef ScheduledStopPointRef 0: 1 Referanse til ScheduledStopPoint

DestinationDisplayRef DestinationDisplayRef 0: 1 Referanse til DestinationDisplay

Types of journey

VehicleJourney

VehicleJourney < < < Journey LinkSequence  DataManagedObject 

Navn Type Kardinalitet Beskrivelse

PrivateCode xsd:normalizedString 0: 1 Intern kode ( ) for reisen (f.eks. tognummer / turnummer)ikke-annonsert identifikator

DepartureTime xsd:time 0: 1 Avgangstid

Frequency Frequency 0: 1 Frekvens / intervall for avganger

Brukes kun ved beskrivelse av frekvensbaserte avganger

JourneyDuration xsd:duration 0: 1 Reisens totale varighet

RouteRef RouteRef 0: 1 Referanse til Route (ikke påkrevd for ServiceJourney, da dette kan utledes av)JourneyPatternRef

PublicCode xsd:normalizedString 0: 1 Reisens publikumskode ( )annonsert identifikator

Brukes dersom f.eks. linjenummer endres for hver tur, eller unntaksvis overstyreskun

waitTimes VehicleJourneyWaitTime 0: * Beskrivelse av nødvendige ventepauser ved TimingPoints

Brukes normalt kun ved beskrivelse av frekvensbaserte avganger

runTimes VehicleJourneyRunTime 0: * Beskrivelse av kjøretider mellom TimingPoints

Brukes kun for beskrivelse av frekvensbaserte avganger

passingTimes TimetabledPassingTime 1: * Beskrivelse av planlagte passeringstidspunkter ved eller StopPoints TimingPoints

parts JourneyPart 0: * Liste over reisens deler ( )brukes i spesielle situasjoner, f.eks. ved sammensatt reise

JourneyPart

Beskrivelse av start eller destinasjon for VehicleJourney

Planlagt reise fra startpunkt til destinasjon som følger gitt JourneyPattern

Se definisjon under Generell informasjon

En del av en reise, gitt et bestemt funksjonell formål (brukes f.eks. ved sammensatte og/eller splittede togreiser)

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

JourneyPart < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

Description MultilingualString   0: 1 Beskrivelse

MainPartRef JourneyPartCoupleRef 1: 1 Referanse til hoveddel av reisen

JourneyPartCoupleRef JourneyPartCoupleRef 0: 1 Referanse til som denne delen av reisen hører tilCoupledJourney

FromStopPointRef ScheduledStopPointRef 0: 1 Startpunkt for delen av reisen ( )ScheduledStopPoint

ToStopPointRef ScheduledStopPointRef 0: 1 Destinasjon for delen av reisen ( )ScheduledStopPoint

StartTime xsd:time 1: 1 Start-tidspunkt

EndTime xsd:time 1: 1 Slutt-tidspunkt

Frequency

Frequency < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

ScheduledHeadwayInterval xsd:duration 1: 1 Planlagt avreise-intervall

MinimumHeadwayInterval xsd:duration 0: 1 Minste avreise-intervall

MaximumHeadwayInterval xsd:duration 0: 1 Største avreise-intervall

Description MultilingualString   0: 1 Beskrivelse, f.eks. "hver 15. minutt"

VehicleJourneyWaitTime

VehicleJourneyWaitTime < < < JourneyWaitTime JourneyTiming VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

VehicleJourneyRef VehicleJourneyRef 0: 1 Referanse til VehicleJourney

VehicleJourneyRunTime

VehicleJourneyRunTime < < < JourneyRuntime JourneyTiming  VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

VehicleJourneyRef VehicleJourneyRef 0: 1 Referanse til VehicleJourney

VehicleJourneyHeadway

Frekvens for en reise, dvs. tidsintervall mellom hver avgang ved trafikk.frekvensbasert

Se definisjon under Generell informasjon

Ventetid ved for en gitt TimingPoint VehicleJourney

Se definisjon under Generell informasjon

Kjøretid mellom for en gitt TimingPoints VehicleJourney

Se definisjon under Generell informasjon

Intervall mellom to VehicleJourneys

Brukes ved frekvensbasert trafikk

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

VehicleJourneyHeadway < < < JourneyHeadway JourneyTiming  VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

VehicleJourneyRef VehicleJourneyRef 0: 1 Referanse til VehicleJourney

TimetabledPassingTime

TimetabledPassingTime < PassingTime < VersionedChild  < EntityInVersion  < Entity 

Navn Type Kardinalitet Beskrivelse

PointInJourneyPatternRef PointInJourneyPatternRef 1: 1 Referanse til (punktet som betjenes / passeres)PointInJourneyPattern

ArrivalTime xsd:time 0: 1 Planlagt ankomsttid

NB: Må oppgis enten ArrivalTime eller DepartureTime (eller begge, hvis relevant) for hver PassingTime

ArrivalDayOffset DayOffsetType(xsd:integer)

0: 1 Antall dager ankomsten skjer i forhold til reisens startdag

Settes kun dersom ankomster senere kalenderdag(er) enn ServiceJourney startet

DepartureTime xsd:time 0: 1 Planlagt avgangstid

NB: Må oppgis enten ArrivalTime eller DepartureTime (eller begge, hvis relevant) for hver PassingTime

DepartureDayOffset DayOffsetType (xsd:integer)

0: 1 Antall dager avgangen skjer i forhold til reisens startdag

Settes kun dersom avgang er senere kalenderdag(er) enn ServiceJourney startet

WaitingTime xsd:duration 0: 1 Planlagt ventetid ved Point

LatestArrivalTime xsd:time 0: 1 Seneste ankomsttid

EarliestDepartureTime xsd:time 0: 1 Tidligste avgangstid

SpecialService

SpecialService < < < Journey LinkSequence DataManagedObject 

Navn Type Kardinalitet Beskrivelse

DepartureTime xsd:time 0: 1 Avgangstid

Frequency Frequency 0: 1 Frekvens / intervall for avganger

Brukes kun ved beskrivelse av frekvensbaserte avganger

JourneyDuration xsd:duration 0: 1 Reisens varighet

Client MultilingualString 0: 1 Klient for SpecialService

dayTypes DayTypeRef 1: * Referanser til DayTypes

JourneyPatternRef JourneyPatternRef 0: 1 Referanse til JourneyPattern

VehicleTypeRef VehicleTypeRef 0: 1 Referanse til VehicleType

Origin JourneyEndpointStructure 0: 1 Startpunkt

Destination JourneyEndpointStructure 0: 1 Destinasjon

Planlagt passeringtidspunkt ved et ( eller ) for en gitt PointInJourneyPattern ScheduledStopPoint TimingPoint VehicleJourney

Se definisjon under Generell informasjon

Eksempel finnes i Rutebankens offisielle GitHub-repository

VehicleJourney med passasjerer for en gitt . Kan brukes ved spesielle turer, ekstraturer, erstatningsturer, fleksible turerDayTypeetc.

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

BookingMethods BookingMethodListOfEnumerations 0: 1 Tilgjengelige måter å bestille på:

callDrivercallOfficeonlinephoneAtStoptext

BookingAccess BookingAccessEnumeration 0: 1 Kategorier som har lov å bestille:

publicauthorisedPublicstaff

BookWhen PurchaseWhenEnumeration 0: 1 Tidspunkt når bestillingen må være gjort:

timeOfTravelOnlydayOfTravelOnlyuntilPreviousDayadvanceOnlyadvanceAndDayOfTravel

BuyWhen PurchaseMomentListOfEnumerations 0: 1 Tidspunkt når bestillingen må betales:

onReservationbeforeBoardingafterBoardingonCheckOut

LatestBookingTime xsd:time 0: 1 Siste tidspunkt for bestilling

MinimumBookingPeriod xsd:duration 0: 1 Minste periode i forkant av avgang bestillingen må være gjort

BookingNote xsd:normalizedString 0: 1 Tilleggsinformasjon om bestillingen

ServiceJourney

ServiceJourney < < VehicleJourney   Journey < LinkSequence < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

ServiceAlteration ServiceAlterationEnumeration 0: 1 Type reise:

plannedextraJourneycancellation

DepartureTime xsd:time 0: 1 Avgang

Frequency  Frequency 0: 1 Frekvens / intervall for avganger

Brukes kun ved beskrivelse av frekvensbaserte avganger

JourneyDuration xsd:duration 0: 1 Reisens varighet

dayTypes DayTypeRef 1: * Referanser til DayTypes

JourneyPatternRef JourneyPatternRef 1: 1 Referanse til JourneyPattern

JourneyFrequencyGroupRef JourneyFrequencyGroupRef 0: 1 Referanse til JourneyFrequencyGroup

VehicleTypeRef VehicleTypeRef 0: 1 Referanse til VehicleType

OperatorRef OperatorRef 0: 1 Referanse til Operator

passingTimes TimetabledPassingTime 1: * Planlagte passerings-/betjeningstidspunkter

parts JourneyPart 0: * Liste over reisens deler (brukes i spesielle situasjoner, f.eks. vedsammensatt reise)

For eventuelt å kunne gjenbruke deler av en reise, må disse være definertseparat (som uavhenige objekter, referert herfra).

checkConstraints CheckConstraint 0: * Veiledende informasjon om sikkerhetssjekk, barrierer eller liknende somkan gi forsinkelser

VehicleJourney med passasjerer. Dette er en normalt en ordinær avgang som kjører en planlagt rute til et planlagt tidspunkt.

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

TrainSize TrainSize 0: 1 Informasjon om togstørrelse og -struktur

FlexibleServiceProperties FlexibleServiceProperties 0: 1 Egenskaper for fleksibel transport. 

Det er mulig å definere slik informasjon her dersom dette avviker fra ellerikke er relevant å definere på -nivå.Line

Periodical journeys

TemplateServiceJourney

TemplateServiceJourney < < < TemplateVehicleJourney ServiceJourney Journey  < LinkSequence < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

frequencyGroups (valg)RhytmicalJourneyGroup

(valg)HeadwayJourneyGroup

(valg)RhytmicalJourneyGroupRef

(valg)HeadwayJourneyGroupRef

1: * RhythmicalJourneyGroup eller , evt. referanse til, som gjelder forHeadwayJourneyGroupdette mønsteret (template)

JourneyFrequencyGroup

JourneyFrequencyGroup < < GroupOfEntities DataManagedObject 

Navn Type Kardinalitet Beskrivelse

FirstDepartureTime xsd:time 1: 1 Tidspunkt for først avgang. 

Avgangstid for den aller første avgang i serien, fra første stoppested.

LastDepartureTime xsd:time 1: 1 Tidspunkt for siste avgang.

Avgangstid for den aller siste avgang i serien.

DayOffset xsd:integer 0: 1 Antall dager fra utgangspunktet (i tilfeller hvor service-perioden varer i flere dager)

journeys VehicleJourneyRef 0: * Liste av reiser som utgjør JourneyFrequencyGroup.

Her skal det utelukkende brukes ServiceJourneyRef objekter.

RhythmicalJourneyGroup

RhythmicalJourneyGroup < < JourneyFrequencyGroup GroupOfEntities   < DataManagedObject 

Template for å beskrive gjentakende , brukes enten sammen med (for å beskriveServiceJourney HeadwayJourneyGroupfrekvens-baserte avganger) eller (for å beskrive avganger til samme klokkeslett i en gitt periode)RhythmicalJourneyGroup

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Abstrak type som beskriver gjentakende (f.eks. "avganger hver xx05, xx15, xx25, xx35, xx45, xx55") eller frekvensbaserteavganger  ("avganger med X minutters mellomrom")

Se definisjon under Generell informasjon

Beskrivelse av service hvor avgang(er) kjøres til samme klokkeslett (minuttangivelse over hver hele time) for en gitt periode

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes i Rutebankens offisielle GitHub-repository 

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

Navn Type Kardinalitet Beskrivelse

timebands TimebandRef 1: * Referanse til objekt som beskriver tidspunktet i antall minutter over hel time når jouTimeband ServiceJourneyrney har avgang

I kontekst av RhythmicalJourneyGroup skal være definert med StartTime og EndTime, ogTimeband likdenne viser antall minutt over hel time avgangen går (bruk "00:..." for generisk angivelse av time)

HeadwayJourneyGroup

HeadwayJourneyGroup < < JourneyFrequencyGroup GroupOfEntities   < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

ScheduledHeadwayInterval xsd:duration 1: 1 Planlagt intervall mellom avgangene

MinimumHeadwayInterval xsd:duration 0: 1 Minste intervall mellom avgangene

MaximumHeadwayInterval xsd:duration 0: 1 Maksimalt intervall mellom avgangene

Description MultilingualString 0: 1 Beskrivelse (f.eks. "hvert 15. minutt")

Coupled journeys

CoupledJourney

CoupledJourney < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

Description MultilingualString 0: 1 Beskrivelse

journeys VehicleJourneyRef 0: * Liste av som inngår i den sammensatt reisenVehicleJourneys

JourneyPartCouple

JourneyPartCouple < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

Description MultilingualString 0: 1 Beskrivelse av sammensatt reise

StartTime xsd:time 1: 1 Starttidspunkt for sammensatt reise

EndTime xsd:time 1: 1 Sluttidspunkt for sammensatt reise

FromStopPointRef ScheduledStopPointRef 1: 1 Planlagt start-stoppested / start for sammensatt reise (ScheduledStopPoint)

ToStopPointRef ScheduledStopPointRef 1: 1 Planlagt destinasjon / slutt for sammensatt reise ( )ScheduledStopPoint

MainPartRef JourneyPartRef 1: 1 Hoveddel av sammensatt reise (relevant for reiseinfromasjon)

Beskrivelse av service som har samme tidsintervall mellom avganger ( )frekvensbaserte avganger

Se definisjon under Generell informasjon

Defineres i TimetableFrame

En sammensatt reise som består av ulike , hvor kjøretøy er satt sammen av to eller flere enkelt-kjøretøy (VehicleJourneys brukes)normalt kun for tog

Se definisjon under Generell informasjon

Defineres i TimetableFrame

To eller flere fra forskjellige som kjøres sammen ( )JourneyParts VehicleJourneys gjelder normalt bare for sammensatte tog

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

journeyParts JourneyPartRef 0: 1 Andre deler av sammensatt reise

ServiceCalendar

ServiceCalendar < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

Name MultilingualString 0: 1 Kalendarnavn

FromDate xsd:date 1: 1 Startdato

ToDate xsd:date 1: 1 Sluttdato

EarliestTime xsd:time 0: 1 Dagens start ( )oppgis dersom annet tidspunkt enn norm kl 00:00:00

DayLength xsd:duration 0: 1 Dagens varighet ( )oppgis dersom annen lengde enn norm 24 timer

dayTypes DayType 0: * DayTypes brukt i kalender

Tillatt definert direkte i ServiceCalendarFrame

timebands Timeband 0: * Timebands brukt i kalender

Tillatt definert direkte i ServiceCalendarFrame

operatingDays OperatingDay 0: * OperatingDays brukt i kalender

Tillatt definert direkte i ServiceCalendarFrame

operatingPeriods OperatingPeriod 0: * OperatingPeriods brukt i kalender

Tillatt definert direkte i ServiceCalendarFrame

dayTypeAssignments DayTypeAssignment 0: * Kobling av til DayTypes OperatingDays

Tillatt definert direkte i ServiceCalendarFrame

Interchange

Interchange

Interchange < DataManagedObject 

Navn Type Kardinalitet Beskrivelse

Priority xsd:integer 0: 1 Prioriteringstall for bytte/overgang (1. prioritet, 2. priortet osv.) ved flere mulige interchanges langssamme trasè

Prioritet 0 (null) angir at konsumentens standardberegning av overgang skal benyttesNegativt prioritetstall (-1) tolkes som overgangikke tillatt

StaySeated xsd:boolean 0: 1 Spesifiserer at reisende kan bli på samme kjøretøy fordi det fortsetter videre i planlagt retning. 

Kan være nyttig for å beskrive at f.eks. en ring-linje fortsetter med samme transportmiddel selv omlinjenummeret endres

Planned xsd:boolean 0: 1 Spesifiserer om overgangen er planlagt i ruteoppsettet

Guaranteed xsd:boolean 0: 1 Spesifiserer om overgangen er garantert

Advertised xsd:boolean 0: 1 Spesifiserer om overgangsmuligheten opplyses til publikum

Logisk container for gruppering av kalender-relaterte elementer med samme gyldighetsbetingelser og/eller lik start- og sluttdato

Merk at frikoplede kalender-objekter med samme gyldighetsbetingelser som for gjeldende  bør leggesServiceCalendarFramedirekte under denne fremfor å grupperes i en unødvendig ServiceCalendar

Se definisjon under Generell informasjon

Defineres i ServiceCalendarFrame

Eksempel finnes  i Rutebankens offisielle GitHub-repository

Abstrakt type som beskriver planlagt mulighet for passasjerer å bytte mellom på samme eller (vanligvis)ServiceJourneysnærliggende stoppesteder, med rutemessig beskrivelse av kriterier for når/om et kjøretøy venter på det ankomne o.l.

Se definisjon under Generell informasjon

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

MaximumWaitTime xsd:duration 0: 1 Maksimal tid videre transport kan vente (etter normal avgangstid) på overgangspassasjerer

ServiceJourneyInterchange

ServiceJourneyInterchange < < Interchange DataManagedObject 

Navn Type Kardinalitet Beskrivelse

FromPointRef ScheduledStopPointRef 1: 1 Referanse til stoppested hvor passasjerer starter bytte/overgang

ToPointRef ScheduledStopPointRef 1: 1 Referanse til stoppested hvor passasjerer skal fortsette reisen fra

FromJourneyRef VehicleJourneyRef 1: 1 Referanse til reisen passasjerer bytter fra (VehicleJourney)

ToJourneyRef VehicleJourneyRef 1: 1 Referanse til reisen passasjerer bytter til (VehicleJourney)

Spesialisering av som gjelder for Interchange ServiceJourney

Se definisjon under Generell informasjon

Defineres i TimetableFrame

Eksempel finnes  i Rutebankens offisielle GitHub-repository

Håndbok N801 Vedlegg A – NeTEx profil Norge

Jernbanedirektoratet 2018

CodespaceI NeTEx og SIRI brukes konseptet for å unikt identifisere dataelementer og attributter i innsendt XML. Dette er innarbeidet ettercodespace samme modell som   for å identifisere et unikt XML Schema, hvor benyttes på objektnivå slik at data fra ulikenamespace codespaceinnsendere kan kan kombineres globalt. Det vil si at alle innsendte data skal identifiseres med et unikt tilordnet den enkelte aktørcodespacesom leverer stoppested- og rutedata. 

Gyldige  forvaltes av Nasjonalt Selskap, og dataleverandører (alle med behov for å sende inn stoppested- og/eller rutedata) måcodespacesmeldes i det sentrale registeret slik at man blir tildelt bruker og unik ID før innsending.

Under følger  og tilhørende  :foreløpig etablerte codespace namespace

Dataleverandør Codespace Namespace

Agder Kollektivtrafikk AKT AKT http://www.rutebanken.org/ns/akt

AtB ATB http://www.rutebanken.org/ns/atb

Avinor AVI http://www.rutebanken.org/ns/avi

BaneNOR BNR http://www.rutebanken.org/ns/bnr

Brakar BRA http://www.rutebanken.org/ns/bra

Entur AS ENT http://www.rutebanken.org/ns/ent

Finnmark fylkeskommune FIN http://www.rutebanken.org/ns/fin

Flytoget FLT http://www.rutebanken.org/ns/flt

Hedmark Trafikk FKF HED http://www.rutebanken.org/ns/hed

Kartverket KVE http://www.rutebanken.org/ns/kve

Kolombus KOL http://www.rutebanken.org/ns/kol

Linkon LIN http://www.rutebanken.org/ns/lin

Møre og Romsdal fylkeskommune MOR http://www.rutebanken.org/ns/mor

Nasjonal Stoppestedsregister NSR http://www.rutebanken.org/ns/nsr

Nettbuss Ekspress NBE http://www.rutebanken.org/ns/nbe

Nord-Trøndelag fylkeskommune NTR http://www.rutebanken.org/ns/ntr

Nordland fylkeskommune NOR http://www.rutebanken.org/ns/nor

Nor-Way bussekspress NWY http://www.rutebanken.org/ns/nwy

NSB NSB http://www.rutebanken.org/ns/nsb

Oppland fylkeskommune OPP http://www.rutebanken.org/ns/opp

Ruter RUT http://www.rutebanken.org/ns/rut

Sogn og Fjordane SOF http://www.rutebanken.org/ns/sof

Skyss SKY http://www.rutebanken.org/ns/sky

Statens vegvesen SVV http://www.rutebanken.org/ns/svv

Telemark fylkeskommune TEL http://www.rutebanken.org/ns/tel

Timeekspressen TIM http://www.rutebanken.org/ns/tim

Troms fylkeskommune TRO http://www.rutebanken.org/ns/tro

Unibuss Ekspress UNI http://www.rutebanken.org/ns/uni

Vestfold fylkeskommune VKT http://www.rutebanken.org/ns/vkt

Østfold fylkeskommune OST http://www.rutebanken.org/ns/ost

Norgesbuss NBU http://www.rutebanken.org/ns/nbu