håndbok n801 - nasjonale rutedata - …...• netex profil norge - teknisk spesifikasjon for...
TRANSCRIPT
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