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.

Formålet med denne håndboka er tredelt:

1. Håndboka 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.

2. Håndboka 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.

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

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

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.

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.

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

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

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.

Forskrift om yrkestransport med motorvogn og fartøy (yrkestransportforskriften) legges til grunn for å sikre at nødvendige stoppesteds- og ruteplansdata overføres fra pliktige parter. Kunngjøringsplikten følger av 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ør endringen 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 at iverksettelsen 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 og luftfart, vil overføring av data finne sted fra de av virksomhetene som administrerer rutetrafikken på vegne av staten. Hvem som er løyvehaver og leverandør av data varierer fra fylke til fylke. Det kan være fylkeskommunen selv, direkte eller via tilknyttede administrasjonsselskap, trafikkselskapene eller begge. I det videre brukes dataleverandører som samlebetegnelse for de som skal levere informasjon om stoppesteder og rutedata til det nasjonale selskapet.

Samferdselsdepartementet har i Rundskriv N-2/2019 (https://www.regjeringen.no/contentassets/077b183d3c5c4511ae8014621095197d/n-2_2019.pdf) fastsatt retningslinjer til yrkestransportforskriften for offentliggjøring av ruteopplysninger for persontransport, og derigjennom trådte dagens krav til kunngjøringsplikten for stoppested- og rutedata i kraft 1. juli 2017 og for sanntidsdata i kraft 1. desember 2019.

For å forvalte og videreutvikle Kunngjøringsplikten, er det etablert et eget Samarbeidsforum som ledes av Vegdirektoratet. 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.

For at det til en hver 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.

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

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.

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.

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.

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.

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 utveklingsformatet), hvor innholdet er satt opp i henhold til kravene fastsatt i vedlegg NeTEx profil Norge. Alle XMLer som leveres til nasjonalt selskap må bestå av komplette datasett for hele sin gyldighetsperiode.

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, ref. tidligere "Administrajonskode"). Denne er påkrevd å bruke ved innsending av data, nærmere beskrevet under Utforming av identifikatorer i vedlegg NeTEx profil Norge.

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

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 énXML-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 enmulighet, 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.

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 Tilgangsstyring (se kapittel Tilgangsstyring).

Følgende prosess gjelder for innlevering:

1. Dataleverandører sender NeTEx-XML med oppdatere 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

Open

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.

Overordnet prosess-illustrasjon for innlevering / oppdatering av datasett:

Open

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.

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.

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 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 gjeldender neste dag) dersom hensiktsmessig. (SIRI meldingstyper er nærmere beskrevet under bestemmelser for Sanntids- og avviksdata. Se kapittel "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.

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. Se kapittel "Sanntids- og avviksdata"). Andre endringer som berører spesifikk(e) avgang(er) med behov for kort publikasjonstid, kommuniseres som hovedregel ved hjelp av sanntidsmeldinger.

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

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

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.

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.

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

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.

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.

NeTEx er et XML-basert utvekslingsformat for utveksling av informasjon rundt offentlig transport. NeTEx er en teknisk standard i EU, og det er arbeides for å få den etablert som en EU NORM. NeTEx er bygget på den konseptuelle informasjonsmodellen TransModel som også er en EU-standard.

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

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 transportekniske 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 man ønsker gitte aspekter modellert

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 NeTEx

2. Rammeverk (Framework)

3. Stoppesteder (Stops)

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.

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

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

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

  • Latitude

  • Longitude

  • Height (hvis relevant)

• Regional tilhørighet

  • Fylke

  • Kommune

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

  • Herunder stoppestedsutrustning

  • Automatisk synkronisering av noen relevante data fra NVDB (ikke komplett datasett)

• Administasjonsansvar

  • Tilgang for å kunne gjøre endringer

Fylkeskommunene og Jernbanedirektoratet, direkte eller gjennom sine admninistrasjonsselskaper 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).

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

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 stoppsted-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 at stoppestedet opprettes / nedlegges i stoppestedregisteret i henhold til de prosessene som dette kapittelet beskriver.

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

Open

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

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

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.

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.

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

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.

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