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.

Formålet med denne håndboka

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.

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

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

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

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.

Kunngjøringsplikten

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.

Samarbeidsforum for forvaltning av kunngjøringsplikten

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.

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

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

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.

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.

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.

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.

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

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

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

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

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

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.

Innlevering av datasett

Overordnet prosess-illustrasjon 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.

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.

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

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

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.

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.

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.

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

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

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

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

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

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

4.2. Ansvarsfordeling

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 /wiki/spaces/ROR/pages/637370400 under vedlegg /wiki/spaces/ROR/pages/637370400, 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 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.

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

Nedleggelse av stoppested

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.

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.

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.

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

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.

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

Struktur

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

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.

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

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
  • F.eks. når stoppene er synlig fra hverandre
• Det er en naturlig multimodalitet
  
  • F.eks busstopp tilknyttet til en lufthavnsterminal eller jernbanestasjon "arver" stoppestedsnavn fra hovedtransporttypens.

Stoppesteder skal normalt ikke ha felles navn når:

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

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.

Forkortelser

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

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.

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.

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 (‘/’).

Stoppesteder på geografiske grenser

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.

Landegrenser

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

• Riksgrensen E12
• Riksgrensen rv. 77
• Lutnes riksgrensen

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.

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	Illustrasjon

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.

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 de underliggende StopPlaces og peke til den "parent" StopPlace.

Solli plass - Illustrasjon

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.

Mortensrud T-banestasjon - Illustrasjon

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

Nationaltheatret - Gruppering av objekter

Nationaltheatret - Illustrasjon

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

Koordinat-plassering

Koordinatpunkter på stoppesteder skal settes på standardisert måte, slik at opprettelse, vedlikehold og feilretting gjøres ensartet for alle elementer i det nasjonale stoppestedsregistert. 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.

Buss og trikk

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

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.

Båt

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

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.

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.

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.

5. Sanntids- og avviksdata

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

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

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

5.1. Krav til sanntids- og avviksinformasjon

Det stilles i nåværende løsning ikke krav til at operatører skal implementere systemer for sanntids- og avviksinformasjon. Men alle dataleverandører med sanntidssystem i bruk pålegges å sende inn, 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.

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.
   • Endringer som går på kanselleringer, tilleggsavganger, forsinkelser, omkjøringer, stopp som ikke betjenes og nye stopp som betjenes skal kommuniseres her.
3. SIRI Vehicle Monitoring (VM) sendes kontinuerlig.
   • Oppdatering av posisjoner, samt forsinkelser i sanntid kommuniseres her.
4. For avviksmeldinger skal SIRI Situation Exchange (SX) benyttes.

NTP

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

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:

Datagyldighet

1. Rutedata mottatt som NeTEx PublicationDelivery prosesseres og publiseres fortløpende
   • Endringer som ligger lenger frem i tid enn normalt prosesseringsvindu (1-3 timer) kan sendes inn som nytt datasett
   • 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,
   • 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
   • Ved mottatte endrings- og avviksmeldinger vil disse alltid overstyre eksisterende rutedata