slutrapport slutrapport ---- teknikplattform för den samlade … · 2019-09-24 · e 2013-05-21...

Slutrapport Slutrapport Slutrapport Slutrapport ---- Teknikplattform för den samlade kolleTeknikplattform för den samlade kolleTeknikplattform för den samlade kolleTeknikplattform för den samlade kollek-k-k-k-

tivtrafikentivtrafikentivtrafikentivtrafiken

DokumentidentitetDokumentidentitetDokumentidentitetDokumentidentitet:::: TRTRTRTR----SIS_TEKNIK_SLUTRAPPORTSIS_TEKNIK_SLUTRAPPORTSIS_TEKNIK_SLUTRAPPORTSIS_TEKNIK_SLUTRAPPORT

Revision:Revision:Revision:Revision: FFFF

Date:Date:Date:Date: 2013201320132013----05050505----30303030

Titel Sida

Slutrapport - Teknikplattform för den samlade kollektivtrafiken 2(72) Författare Godkänd

Ulf Bjersing Dokumentidentitet Datum Revision

TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 F

Slutrapport Slutrapport Slutrapport Slutrapport ---- Teknikplattform för den samlade kolleTeknikplattform för den samlade kolleTeknikplattform för den samlade kolleTeknikplattform för den samlade kollek-k-k-k-

tivtrafikentivtrafikentivtrafikentivtrafiken

RevisionRevisionRevisionRevisionshistorikshistorikshistorikshistorik

Revision Datum Beskrivning Ändrat av

A 2012-12-19 Delrapport Ulf Bjersing

B 2013-03-28 Förslag till slutrapport för remiss Ulf Bjersing

C 2013-04-02 Slutrapport för remiss Ulf Bjersing

D 2013-05-08 Slutrapport med utökningar och bearbetningar uti-från remissvar

Ulf Bjersing

E 2013-05-21 Slutrapport med justeringar efter telefonmöte 2013-05-21

Ulf Bjersing

F 2013-05-30 Slutrapport efter språkgranskning Ulf Bjersing

Titel Sida




Innehållsförteckning

FÖRORD .................................................................................................................................................................. 6

1 SAMMANFATTNING ..................................................................................................................................................... 7

2 DEFINITIONER .............................................................................................................................................................. 8

3 INLEDNING .................................................................................................................................................................. 9

3.1 Syfte ...................................................................................................................................................................... 9

3.2 Läsanvisning och avgränsningar .......................................................................................................................... 9

3.3 Översikt .............................................................................................................................................................. 10

3.4 Rekommendation ................................................................................................................................................ 12

3.4.1 Kopplade resor ..............................................................................................................................................................12

3.4.2 Gränssnitt och API-er ...................................................................................................................................................12

3.4.3 Geografi .........................................................................................................................................................................12

3.4.4 Betalning ........................................................................................................................................................................12

3.4.5 Upphandling och tillståndsgivning ...........................................................................................................................13

4 BAKGRUND ................................................................................................................................................................ 14

4.1 Fördubbling ........................................................................................................................................................ 15

5 FÖRESLAGEN LÖSNING – KOPPLADE RESOR .............................................................................................................. 16

5.1 Organisation och metodik ................................................................................................................................... 16

5.2 Resenärens perspektiv ......................................................................................................................................... 17

5.3 Miljöaspekter ...................................................................................................................................................... 17

5.4 Arbeta med gränssnitt ........................................................................................................................................ 17

5.5 Gemensam geografi ............................................................................................................................................. 19

5.6 Information om resmöjligheter ........................................................................................................................... 19

5.7 Planering av resan .............................................................................................................................................. 23

5.8 Bokning och betalning ........................................................................................................................................ 25

5.9 Resan .................................................................................................................................................................. 26

5.10 Uppföljning på utförda resor ............................................................................................................................ 27

5.11 Ansvar gentemot resenären i kopplade resor .................................................................................................... 27

6 INVENTERING DATAKÄLLOR ..................................................................................................................................... 29

6.1 Geografi .............................................................................................................................................................. 29

6.1.1 Hållplatsregister ...........................................................................................................................................................29

6.1.2 Adresser från fastighetsregistret.................................................................................................................................29

6.1.3 Övriga kända platser –POI (Point Of Interest) .........................................................................................................29

6.1.4 Vägnät ............................................................................................................................................................................30

6.1.5 Nationell geodatastrategi ............................................................................................................................................30

6.1.6 En gemensam geodata-portal .....................................................................................................................................31

7 KARTLÄGGA GRÄNSSNITT FÖR INFORMATIONSUTBYTE MELLAN SYSTEM ............................................................... 32

7.1 Transmodel ......................................................................................................................................................... 32

7.2 NOPTIS .............................................................................................................................................................. 32

7.3 NeTEx, SIRI och GTFS ...................................................................................................................................... 32

7.4 SUTI ................................................................................................................................................................... 32

8 SPECIFICERA INFORMATIONSNAVETS GRÄNSSNITT UTIFRÅN ETABLERADE STANDARDER – AVKORTAD VERSION. 33

8.1 Geodata som behövs för kopplade resor ............................................................................................................... 33

8.1.1 Geodata som krävs för att beskriva den linjelagda trafiken ...................................................................................33

8.1.2 Anropsstyrda områden ................................................................................................................................................33

Titel Sida




8.1.3 Bytespunkter .................................................................................................................................................................34

8.1.4 Stoppställen för lätta fordon (Taxifickor) ..................................................................................................................35

8.2 Geodata som behövs i den anropsstyrda trafikens system .................................................................................. 35

8.2.1 Platser – Bytespunkter .................................................................................................................................................35

8.2.2 Platser - POI (Point Of Interest) .................................................................................................................................35

8.2.3 Platser – Adresser .........................................................................................................................................................35

8.3 Gränssnitt för att leverera turplaner för den linjelagda kollektivtrafiken ........................................................... 35

8.4 Gränssnitt för att leverera turplaner för den anropsstyrda kollektivtrafiken ..................................................... 35

8.5 Gränssnitt för att leverera bokningsförfrågan .................................................................................................... 36

8.6 Gränssnitt för att utväxla information om reservation och bokning .................................................................. 36

8.7 Gränssnitt för dialog mellan beställar- och utförarsystem i den anropsstyrda trafiken – Resursallokering, order och dirigeringen av fordon ........................................................................................................................................ 37

8.8 Gränssnitt för att utbyta information om kortsiktiga ändringar och realtidshändelser ..................................... 37

8.8.1 Gränssnitt för att meddela kortsiktiga ändringar av utbudet ................................................................................37

8.8.2 Gränssnitt för att meddela realtidshändelser ...........................................................................................................37

8.8.3 Gränssnitt för att ge tillgång till en samlad realtidsinformation ............................................................................37

9 FÖRSLAG PÅ FÖRVALTNINGSORGANISATION OCH FORTSATT UTVECKLING ............................................................ 39

9.1 Förvaltning av en gemensam geodataportal ....................................................................................................... 39

9.2 Förvaltning av tillkommande gränssnitt för utväxling av information ............................................................. 39

9.3 Förvaltning av nummerserier och prefix i identifierare ...................................................................................... 39

9.4 Överordnad koordinering ................................................................................................................................... 39

9.5 Fortsatt utveckling.............................................................................................................................................. 40

9.5.1 Gränssnitt ......................................................................................................................................................................40

9.5.2 Geodataportal ...............................................................................................................................................................40

9.5.3 Pilotprojekt för kopplade resor ...................................................................................................................................40

10 TÄNKBARA FRÅGESTÄLLNINGAR ATT UTREDA VIDARE ......................................................................................... 41

11 REFERENSER ............................................................................................................................................................. 42

12 APPENDIX ................................................................................................................................................................ 43

12.1 Funktionsblock .................................................................................................................................................. 43

12.1.1 Planering av linjelagd kollektivtrafik .......................................................................................................................43

12.1.2 Administrera geografisk information för den linjelagda trafiken ........................................................................43

12.1.3 Beskriva störningar och ändringar i förhållande till planerad trafik ...................................................................43

12.1.4 Rapportera realtidshändelser ....................................................................................................................................43

12.1.5 Integrera planerad information från flera källor ....................................................................................................43

12.1.6 Integrera information om störningar, ändringar och realtidshändelser från flera källor. ................................43

12.1.7 Reseplanerare ..............................................................................................................................................................44

12.1.8 Beställarsystem anropsstyrd trafik ...........................................................................................................................44

12.1.9 Utförarsystem anropsstyrd trafik .............................................................................................................................44

12.1.10 Bokning anropsstyrd trafik .....................................................................................................................................44

12.1.11 Bevakning av byten ..................................................................................................................................................44

12.2 Integrator .......................................................................................................................................................... 45

12.3 Kostnadsexempel och möjligheter för Lantmäteriets geodata ........................................................................... 45

12.3.1 Förslag till förändring ................................................................................................................................................46

12.3.2 Vinster ..........................................................................................................................................................................46

12.4 Specificera informationsnavets gränssnitt utifrån etablerade standarder – med tekniska detaljer ................... 46

12.4.1 Allmänt om koordinatsystem ...................................................................................................................................47

12.4.2 Geodata som behövs för kopplade resor .................................................................................................................47

Titel Sida




12.4.3 Geodata som behövs i den anropsstyrda trafikens system ...................................................................................51

12.4.4 Gränssnitt för att leverera turplaner för den linjelagda kollektivtrafiken ...........................................................57

12.4.5 Gränssnitt för att leverera turplaner för den anropsstyrda kollektivtrafiken.....................................................60

12.4.6 Gränssnitt för att leverera bokningsförfrågan ........................................................................................................62

12.4.7 Gränssnitt för att utväxla information om reservation och bokning ...................................................................64

12.4.8 Gränssnitt för dialog mellan beställar- och utförarsystem i den anropsstyrda trafiken – Resursallokering, order och dirigeringen av fordon ........................................................................................................................................70

12.4.9 Gränssnitt för att utbyta information om kortsiktiga ändringar och realtidshändelser....................................70

Titel Sida




Förord

Projektidén är att ta fram en specifikation för ett nationellt informationsnav för kollektivtrafiken där systemen ska kunna ”prata” med varandra genom att de standardiserade gränssnitten anpassas och att samma grunddata från exi-sterande databaser används. Utredningen ska visa vilka databaser som är relevanta och användbara samt hur det går att skapa funktionalitet genom att information från två eller flera databaser länkas samman.

I de fall det finns fungerande standarder ska dessa vara normgivande för utredningen. T.ex. att NOPTIS är normgi-vande för linjelagd trafik och SUTI för den anropsstyrda trafiken. En trolig konsekvens blir då att SUTI ska anpassas till NOPTIS. Det innebär att de mycket betydande investeringar som gjorts i dessa gränssnitt kan tillvaratas.

Vår förhoppning är att en fortsatt pilotstudie skall bidra till ett genombrott när det gäller att binda ihop allmän linje-lagd och anropsstyrd trafik.

Detta X2AB-projekt är finansierat av:

• Taxi Stockholm 150000 AB

• Fågelviksgruppen AB

• AB Storstockholms lokaltrafik

• Västtrafik AB

• Värmlandstrafik AB

• Skånetrafiken

• Jönköpings Länstrafik AB

• AB Östgötatrafiken

• Keolis Sverige AB

• Svenska Taxiförbundet

• Svensk Kollektivtrafik

Följande personer har ingått i projektgruppen:

• Anders Andersson (Projektledare) Svenska Taxiförbundet

• Jonas Johansson Västtrafik AB

• Pär Fröjmark Västtrafik AB

• Lars Hellström Skånetrafiken

• Krister Nordland Skånetrafiken

• Lars Ingvar Johansson SUTI

• Per-Åke Pettersson Taxi Östersund AB

• Bram Lauwers Nobina AB

• Ulf Bjersing (Utredare/sekreterare) Hogia Public Transport Systems AB

Titel Sida




1 Sammanfattning Vår ambition är att skapa en gemensam teknikplattform för den samlade kollektivtrafiken, för såväl allmän och kommersiell kollektivtrafik som linjelagd liksom anropsstyrd trafik.

Utgångspunkten i detta projekt har varit ett hela-resan perspektiv. En resenär vars resa innehåller flera del-resor ska uppleva resan som en sammanhängande helhet. I en kopplad resa sker byten vid väl valda bytes-punkter med relevant stöd och information så att resan även fungerar då störningar uppstår i någon av del-resorna. Tillgänglighetsinformation ingår som en viktig del.

För att åstadkomma en lösning som motsvarar resenärens förväntningar så måste det hela tiden finnas till-gång till aktuell och väl integrerad information om planerat utbud, ändringar i förhållande till detta, stör-ningar och realtidsinformation. De olika tekniska delsystem som finns hos olika aktörer måste hela tiden samverka och utbyta information med varandra.

För att lösa denna typ av interaktion finns det redan i dag etablerade och fungerande gränssnittsstandarder som används för den linjelagda trafiken på regional nivå. Likaså finns etablerade standarder för den anrops-styrda trafiken. Förslaget är att man utgår från gränssnitten NOPTIS och SUTI och tillför de ytterligare gränssnitt som krävs för att automatisera bokning och betalning för hela resan.

En viktig förutsättning för ett fungerande samspel är att alla aktörer har tillgång till en gemensam detaljerad information om geografin; alltså hur platser och adresser benämns, var de ligger och hur de kan nås. En gemensam geodataportal bör därför etableras och denna bör innehålla information från olika aktörer om platser, men även adressinformation. Redan i dag är det möjligt att köpa adressinformation, men till en så hög kostnad att många aktörer avstår från att använda den. Med tillgång till adressinformationen skulle antalet felkörningar kunna minskas och därmed ge bland annat miljömässiga vinster.

Andra länder, exempelvis Danmark, har släppt adressinformationen fri efter att man konstaterat att detta är samhällsekonomiskt lönsamt. Projektet har agerat för att åstadkomma motsvarande förändring i Sverige, och en konstruktiv dialog har inletts med Lantmäteriet.

Som en fortsättning på detta projekt föreslås att tillsammans med Lantmäteriet hitta en kostnadsmässigt acceptabel lösning för adressinformation. Därefter ska en organisation för att förvalta och utveckla en ge-mensam geodataportal fastställas, varefter geodataportalen kan etableras och tas i bruk. Det behöver fortsatt utredas hur kostnaderna för utveckling och drift av denna ska fördelas.

För att underlätta koordinationen mellan bland annat SUTI och NOPTIS bör en paraplyorganisation i exem-pelvis X2ABs regi skapas. I det fortsatta arbete behöver användarguider och tekniska specifikationer för tillkommande gränssnitt och API-er tas fram.

Ett pilotprojekt för att verifiera den föreslagna lösningen med kopplade resor mellan anropsstyrda områden och bytespunkter för stomtrafik bör genomföras. Förslaget är att detta genomförs inom ett avgränsat geogra-fiskt område, men att det så långt som möjligt ska täcka alla aspekter av den föreslagna lösningen. Detta pilotprojekt kan sedan användas som en grund för en lösning i större skala. Vår förhoppning är att en fort-satt pilotstudie skall bidra till ett genombrott när det gäller att binda ihop allmän linjelagd och anropsstyrd

trafik. I rapporten finns slutligen också avsnitt med förslag på närliggande ämnen att utreda vidare.

Titel Sida




2 Definitioner I Börjesson, Mats, Westerlund, Yngve. Utveckling av anropsstyrd trafik Vägverket Publikation 2010:7 återfinns en längre lista över definitioner, nedan följer några dessa samt några andra särskilt centrala begrepp som före-kommer i rapporten.

Begrepp Definition

Anropsstyrd trafik Anropsstyrd trafik är trafik som endast utförs om någon i förväg begärt att få resa.

Integrator En integrator är i detta sammanhang en system-komponent som i realtid, automatiskt och kontinu-erligt kombinerar data från flera olika källor och skapar och tillhandahåller en sammanhållen och konsekvent helhetsinformation till andra system.

Särskild anropsstyrd trafik Anropsstyrd trafik som endast personer med till-stånd av något slag har rätt att utnyttja. Exempelvis färdtjänst och sjukresor.

Teknikplattform Ett fundament eller grundläggande miljö bestående av en gemensam uppsättning principer, gränssnitts-specifikationer, strukturer och eventuellt kompo-nenter. Med detta som bas kan sedan samspelta applikationer och processer skapas.

Trafikföretag Här avser vi trafikföretag på den svenska mark-naden. I denna mening är även en regional kollek-tivtrafikmyndighet eller den de utser att upphandla trafik ett trafikföretag. EU:s definition är som följer: ”ett offentligt eller privat företag, eller en offentlig eller privat företagsgrupp, som bedriver kollektiv-trafik, eller ett offentligt organ som tillhandahåller kollektivtrafiktjänster”1.

1 Baserat på definition i Handlingsplan för framtida betallösningar inom Kollektivtrafiken http://www.svenskkollektivtrafik.se/Global/fordubbling.se/dokument/2_Betallösningar.pdf

Titel Sida




3 Inledning

3.1 Syfte

Syftet med projektet är att specificera en teknikplattform för den samlade kollektivtrafiken. Utgående från kollektivtrafikens samlade behov och en inventering av befintliga datakällor, standarder för gränssnitt och tidigare utredningar beskriver denna rapport metodik och teknik som kan användas för att möjliggöra en bättre integration mellan tekniska system för den anropsstyrda och den linjelagda kollektivtrafiken.

3.2 Läsanvisning och avgränsningar

Projektet berör ett vidsträckt område och det är inte möjligt att i detta dokument beskriva alla infallsvinklar. Vissa aspekter berörs istället ytligt för att ge ett sammanhang till det som är fokus för projektet. Generell bakgrund till problemområdet, erfarenheter från andra länder och applicerbara koncept beskrivs väl i FINAL, FOKAT, med flera rapporter och redovisas därför bara delvis i denna rapport för att undvika onödiga upprepningar. Den som vill få en bredare bild rekommenderas att läsa dessa samt att även studera det som gjorts i vårt grannland Danmark kring flextrafik. Se vidare referenslistan i slutet av rapporten. Denna utredning har fokus på den allmänna kollektivtrafiken då fördubblingsmålet är riktat mot denna och inte mot den särskilda kollektivtrafiken, det vill säga färdtjänst, sjukresor eller skolskjuts. Detta hindrar inte att vissa delar är relevanta även för den särskilda kollektivtrafiken. I det fallet behöver man då också ta hän-syn till det regelverk som den särskilda kollektivtrafiken lyder under. Något som är viktigt för en fungerande helhet är att hitta sätt att kunna betala för hela resan. Likaså finns det frågor om vilka slags betalmedel som ska kunna användas och om man generellt ska kunna använda samma betalmedel och resekortssystem i linjelagd och anropsstyrd trafik. Det är dock inte detta projekts uppgift att hantera frågor runt betallösningar, utan detta behandlas i ett annat X2AB-projekt.

Titel Sida




3.3 Översikt

För att bidra till visionen om en fördubblad andel av resandet i den allmänna kollektivtrafiken behöver vi hitta lösningar som gör det enkelt för resenärerna att utnyttja en mix av anropsstyrd och linjelagd kollektiv-trafik. Tanken är att ersätta lågt utnyttjad linjelagd kollektivtrafik med upphandlad anropsstyrd kollektivtrafik som kopplas till linjelagd kollektivtrafik vid utvalda bytespunkter. En sådan utveckling möjliggör också att linje-lagd stomtrafik kan rätas ut, vilket ger kortare restider. Rätt applicerat borde därmed en bättre kollektivtra-fik kunna erbjudas till samma kostnad för det allmänna.2

Figur 1 Anropsstyrda fordon som matar till stomlinjer ger bättre yttäckning och möjliggör bättre stomtra-fik då hållplatser kan glesas ut.

En ytterligare möjlighet är att synliggöra kommersiella alternativ och kombinationer av kommersiell och allmän trafik. För att åstadkomma välfungerande kopplade resor mellan linjelagd och anropsstyrd kollektivtrafik behöver de tekniska systemen anpassas så att de kan utväxla information på ett bättre sätt än i dag. Det gäller också att säkerställa att alla parter har tillgång till en gemensam detaljerad information om geografin.

2 Börjesson & Westerlund (2009) konstaterar att anropsstyrd kollektivtrafik ofta kan vara en bra ersättning för tidtabellsbunden linjetrafik med liten och oregelbunden efterfrågan.

En viktig slutsats av Glitterprojektet är att det går att till begränsad kostnad genom anropstrafik erbjuda hög minimistandard på kollektivtrafiken för boende utanför tätorter. Slutredovisning av projekt Glitter - Försök med utvecklad landsbygdstrafik, 2003

Titel Sida




Figur 2 Gemensam bild av geografin

Resenären behöver enkelt kunna få en överblick över relevanta resemöjligheter. Om resan innefattar byten bör dessa ske på utvalda bytespunkter och det behöver finnas stöd för att säkerställa bytena om störningar uppstår i realtid. Det måste också finnas tydliga regelverk för vem som tar ansvar om problem uppstår i bytet.

Figur 3 Samlad bild av resmöjligheter

Slutligen måste det vara enkelt att boka och betala resan.

Figur 4 En bokad resa

Titel Sida




För att åstadkomma en mer flexibel kollektivtrafik med smarta lösningar måste alltså arbetssätt och teknik anpassas. I denna rapport försöker vi beskriva en metodik för hur det skulle kunna göras och vilka gräns-snitt som krävs för att etablera en sådan plattform. Tanken är alltså inte att beskriva en enskild teknisk pro-dukt som löser allt, utan istället beskriva hur olika specialiserade tekniska system kan kopplas samman till en fungerande helhet genom att använda gränssnitt och API-er.

3.4 Rekommendation

3.4.1 Kopplade resor

• Importera och beskriv den upphandlade anropsstyrda kollektivtrafiken i de regionala trafikdataba-serna på samma sätt som den upphandlade linjelagda kollektivtrafiken. Därmed kan den anrops-styrda kollektivtrafiken och den linjelagda kollektivtrafiken presenteras som en samlad bild i rese-planerare och övriga medier. Regler och löften till resenären om bytet ska ingå som en del i den im-porterade informationen.

• Tillför möjlighet i reseplanerare att överlämna ett resförslag för hela resan till en bokningsapplikat-ion som är del av eller kan interagera med de anropsstyrda tekniska systemen.

• Förmedla störningsinformation om inställda, delinställda och försenad trafik som påverkar bytet så att inblandade parter i en kopplad resa kan agera i de fall det krävs.

• En väg att ge resenären ytterligare valmöjligheter vore att även i regionala trafikdatabaser presen-tera linjelagd kommersiell trafik för de trafikföretag som så önskar och där gemensamma frågor kring bland annat kundservice och resegarantier kan lösas.

3.4.2 Gränssnitt och API-er

• När teknikplattformen specificeras bör man utgå från de redan etablerade gränssnitten NOPTIS och SUTI så långt som möjligt och endast tillföra de gränssnitt och API-er som saknas för att få en hel-hetslösning.

3.4.3 Geografi

• Agera för att etablera en gemensam geodataportal som omfattar information om adresser och plat-ser från många källor.

• Hitta former för hur olika trafikföretag kan dela med sig av sin platsinformation till en gemensam geodataportal.

• Agera för att den geodata som byggs upp av statliga myndigheter ska bli fritt tillgänglig på ett lik-nande sätt som i Danmark. Därmed undviks att trafikföretag spenderar miljömässiga, tidsmässiga och ekonomiska resurser på att leta adresser som man enkelt funnit om man bara haft tillgång till adress-koordinater, men där man idag valt bort att införskaffa dessa av kostnadsskäl.

3.4.4 Betalning

• Skapa möjlighet för att låta resenären betala för hela den kopplade resan antingen vid bokningstill-fället eller när resan startar.

Titel Sida




• Det vore intressant att kunna integrera betalning för en resa som innehåller blandad kommersiell och allmän trafik.

3.4.5 Upphandling och tillståndsgivning

• När det offentliga upphandlar trafik bör man se till att göra det på ett sätt så man inte i onödan för-hindrar att samordning av olika slags resor kan göras i beställarsystemet.

• Man bör överväga möjligheten att kravställa kapacitet i form av platser och funktion i en flexibel flotta istället för explicit ange specifika fordonstyper för anropsstyrd trafik.

• När färdtjänsttillstånd ges bör man på motsvarande sätt formulera dessa så att man inte förhindrar att resor kan samordnas eller utföras med olika trafikslag.

Titel Sida




4 Bakgrund Den anropsstyrda trafiken och den linjelagda busstrafiken använder i dag olika teknikstandarder och gräns-snitt.

Systemen har över tid utvecklats och är väl lämpade för sina specifika uppgifter men de kan inte kommuni-cera och interagera med varandra på önskvärt sätt. När den linjelagda kollektivtrafiken ska interagera med den anropsstyrda trafiken så blir utmaningen än mer komplex. Såväl trafikförutsättningar som systemmäss-iga förutsättningar skiljer sig åt.

I dag används till exempel olika databaser för geodata med konsekvensen att en hållplats, en plats eller adress saknas eller befinner sig på olika fysiska platser i olika system. Det skapar betydande kostnader att korrigera detta i kommunikationen mellan olika aktörer.

Tekniken inom den anropsstyrda trafiken består av två huvudsakliga delar; (1) beställarsystem (t.ex. Planet eller Pass) och (2) utförarsystem (t.ex. Frogne eller Structab). Det är stora utmaningar att få dessa system att kommunicera och interagera med varandra trots att det har investeras mycket pengar och kraft för att lösa detta. Dessutom finns olika system i olika län (regioner, städer) och de kan för det mesta inte heller ”prata” med varandra. Om ett trafikföretag får ett avtal om trafik i ett nytt område med ett annat beställarsystem så blir anpassningen som regel en kostsam affär. Till viss del löser man problemen med hjälp av SUTI (Stan-dardiserat Utbyte av TransportInformation). En gränssnittsstandard som utvecklas under senare år för den anropsstyrda trafiken. Ändå hämmas systemfunktionen av att grundläggande data inte är hämtade från samma källa. Suti-länkarna överför endast information. Rätt i ena änden blir fel i andra osv.

Den linjelagda kollektivtrafikens system använder i första hand den nordiska de facto standarden NOPTIS (NOrdic Public Transport Interface Standard).

NOPTIS togs fram på initiativ av Skånetrafiken, Västtrafik och Storstockholms lokaltrafik (SL) tillsammans med Movia i Danmark och med stöd av BR och dåvarande SLTF, i syfte att underlätta utbyte av information mellan tekniska system inom den linjelagda kollektivtrafiken. NOPTIS beskriver en konsekvent uppsättning gränssnitt för att utbyta information om den planerade trafiken, realtidshändelser, ändringar och störningar i förhållande till vad som är planerat.

Titel Sida




4.1 Fördubbling

Fokus för detta projekt ur ett fördubblingsperspektiv handlar inte om att fördubbla den särskilda kollektiv-trafiken, det vill säga färdtjänst, sjukresor eller skolskjuts, utan primärt om att skapa förutsättningar för till-växt inom den allmänna kollektivtrafiken:

• Kunna erbjuda kopplade resor

• Ersätta lågfrekvent linjelagd kollektivtrafik med anropsstyrd kollektivtrafik

• Möjliggöra kollektivtrafik på små orter med anropsstyrd trafik.

Ur Vägverkets publikation 2010:7 Utveckling anropsstyrd trafik:

Flera utredningar har påvisat fördelar med att i större omfattning använda anropsstyrd trafik som en del av den all-männa kollektiv-trafiken, t ex som matartrafik till linjetrafiken eller för att ersätta dåligt utnyttjad linjetrafik.

Detta sagt så kan den tänkta tekniken troligen även skapa bättre förutsättningar för att resenärer i särskild kollektivtrafik i vissa fall kan utföra delar av sin resa i den allmänna kollektivtrafiken. Detta bidrar till för-dubblingsmålet samtidigt som det kan ge kostnadsbesparingar.

Titel Sida




5 Föreslagen lösning – kopplade resor Kopplade resor bygger på att resenären gör ett eller flera byten mellan olika fordon. Lämpligen sker dessa byten vid väl valda bytespunkter. Strävan är att begränsa antalet bytespunkter och samtidigt se till att byte-spunkten har en viss kvalitet. Det kan exempelvis vara bra om det finns möjlighet för resenären att kunna gå in och värma sig vintertid.

Fokus för denna utredning är att underlätta integration mellan tekniska system för den anropsstyrda och den linjelagda kollektivtrafiken så att kopplade resor kan synliggöras och genomföras på ett smidigt sätt.

I rapporten ska vi:

1) Beskriva en metodik för hur man genom delvis nya arbetssätt kan integrera information om anrops-styrd kollektivtrafik med linjelagd kollektivtrafik.

2) Beskriva hur de inblandade tekniska systemen kan utbyta nödvändig information genom lämpligt valda gränssnitt.

5.1 Organisation och metodik

En framgångsfaktor för att integrera upphandlad anropsstyrd kollektivtrafik med övrigt utbud i den all-männa kollektivtrafiken är att det förs en nära dialog med dem eller den som planerar utbudet för linjelagd kollektivtrafik vid de tänkta bytespunkterna. Planering av anropsstyrd kollektivtrafik och tidtabellsbunden trafik behöver närma sig varandra3. En väg vore att organisatoriskt hitta lösningar som gör det lättare att samverka, eller där det är möjligt; till och med låta samma person ansvara för att planera utbudet både av upphandlad linjelagd och upphandlad allmän anropsstyrd kollektivtrafik i ett område. Med det tänkta tekniska upplägget som beskrivs nedan skulle i princip samma tur-planeringsverktyg (exempelvis REBUS eller Hastus) kunna användas för att be-skriva utbudet av både linjelagd kollektivtrafik och allmän anropsstyrd kollektivtrafik. Sedan krävs det en tät dialog med dem som arbetar med beställningssystemet för anropsstyrda resor. Det gäller att tillsammans hitta rätt balans mellan utbud och vilka resurser som behöver reserveras samt vilka systemparametrar som ska sättas i beställarsystemet. Genom att i tur-planeringssystemet justera hur många anropsstyrda turer som ska erbjudas, i vilka tidsintervaller och hur stor marginal i ankomst och avgångsti-der som ska användas, kan man anpassa utbudet efter tillgängliga resurser i det anropsstyrda systemet. Förslaget är alltså att registrera utbudet i samma system som används för den linjelagda trafiken och att sedan ha en muntlig dialog om hur detta ska representeras i form av justerade systemparametrar i beställ-ningssystemet för anropsstyrd trafik.

3 Slutredovisning av FINAL-projektet. Fullständig integrering av anropsstyrd kollektivtrafik och linjetrafik.

Västtrafik 2005

Titel Sida




Med detta upplägg begränsas kraven på en teknisk interaktion mellan de ingående systemen för linjelagd och anropsstyrd trafik. Befintliga system för anropsstyrd trafik kan i största möjliga omfattning fortsätta att internt beskriva och hantera information om anropsstyrd trafik på samma sätt som görs i dag.

5.2 Resenärens perspektiv

I denna typ av rapport är det lätt att resenärens perspektiv hamnar i bakgrunden och skyms av alla tekniska resonemang. Detta betyder inte att resenären är oviktig, tvärtom är givetvis syftet att ge resenären en så bra service som möjligt inom ramen för den kostnad som kan accepteras.

Resenärer med särskilda behov måste beaktas, det är exempelvis viktigt att hela tiden ta hänsyn till tillgäng-lighetsaspekten.

Den tänkta lösningen möjliggör också koncept där resenärer blir hämtade och/eller lämnade på en viss adress som en integrerad del av hela resan.

En idé som diskuterats under projektets gång är vad som skulle krävas för att införa platsbokning i hela eller delar av den allmänna linjetrafiken. Detta skulle möjliggöra att fler av de resenärer som normalt enbart reser i den särskilda kollektivtrafiken skulle kunna utnyttja den allmänna kollektivtrafiken för delar av sin resa. Kanske skulle även andra resenärer vara intresserade av att till en extra kostnad kunna boka plats i den all-männa kollektivtrafiken.4

5.3 Miljöaspekter

Den tänkta lösningen möjliggör förhoppningsvis följande positiva miljöaspekter:

• Fordonsstorleken kan anpassas efter antalet resenärer. Tunga fordon används för stomtrafik med fler resenärer medan matartrafiken använder lätta fordon i de fall antalet resenärer är lågt. Vanligt-vis har lätta fordon lägre utsläpp per körd kilometer.

• Genom att införa förbokningskrav för turer som ibland helt saknar resenärer, undviker man tom-körningar. Det innebär att utan resenärer blir det då inga utsläpp.

• Genom att skapa och synliggöra en mer attraktiv kollektivtrafik med bättre yttäckning och uträtad stomtrafik så kommer förhoppningsvis fler att välja att resa kollektivt istället för att köra egen bil.

5.4 Arbeta med gränssnitt

En viktig utgångspunkt i arbetet har varit att kunna ta vara på redan gjorda investeringar i system för den anropsstyrda och linjelagda trafiken.

Istället för att leverera en specifikation på en ny teknisk produkt som täcker alla behov och ersätter nuva-rande system så beskriver vi hur man kan bygga en helhetslösning utifrån ett antal funktionsblock som ut-växlar information enligt fastlagda gränssnitt och API-er. Ett liknande tankesätt tillämpas redan i dag för stora delar av den linjelagda och anropsstyrda trafiken var för sig genom gränssnittsfamiljerna NOPTIS och SUTI.

4 Vidare utredning av denna fråga faller utanför detta projekts ramar, men det vore fullt möjligt att i gräns-snitten tillföra de meddelanden som krävs för att överföra platsbokningsinformationen mellan de tekniska systemen.

Titel Sida




Genom detta arbetssätt kan flera parallella system som tillhör olika organisationer och kommer från olika leverantörer och eventuellt avser olika trafikslag leverera delar av den totala informationen.

Det som föreslås i denna rapport är att man utgår från dessa gränssnitt och sedan lägger till det som saknas. Därmed kan befintliga informationsströmmar till stor del behållas. Befintliga eller nya aktörer kan sedan leverera de tillkommande komponenter som krävs för att erhålla en helhetslösning som kopplar samman den anropsstyrda trafiken och den linjelagda trafiken.

Grundtanken i det tekniska förslaget har alltså inte varit att utgå från ett blankt papper, utan att istället se på vad som redan används i dag, så att gjorda investeringar kan återanvändas i så stor utsträckning om möjligt.

Genom att definiera vilken information som behöver utväxlas istället för att i detalj beskriva hur man tek-niskt löser olika uppgifter inom funktionsblocken öppnar vi förhoppningsvis upp för nya kreativa lösningar och sänker samtidigt tröskeln för nya och befintliga aktörer att leverera olika funktionsblock. En genomgång av de olika funktionsblocken finns som ett separat kapitel i appendix.

Figur 5 Använd gränssnitt för att utbyta information.

I appendix finns även ett separat avsnitt som beskriver integrator-funktionen.

Titel Sida




Vad gäller SUTI-gränssnitten så används de i dag bland annat för att överföra information om dynamisk resursallokering, orderhantering och trafikledning mellan beställarsystem och utförare/utförarsystem från olika leverantörer inom anropsstyrd trafik.

Idén är att använda respektive av dessa två gränssnittsfamiljer till det de främst är ägnade till. Därmed möj-liggörs en tydlig rollfördelning mellan vad som lämpligen hanteras av system som traditionellt varit riktade till den linjelagda trafiken respektive till den anropsstyrda trafiken.

Samtidigt kan vi också återanvända den rollfördelning mellan företag som dessa standarder redan har eta-blerat inom sina respektive områden.

Det kvarstår sedan en gemensam gränsyta mellan de två ”världarna” som behöver täckas. I det följande görs ett försök att beskriva hur detta gap kan överbryggas.

För att bättre förstå den föreslagna lösningen så ska vi titta på de olika stegen och ser vad den skulle betyda för en resenär.

5.5 Gemensam geografi

Det förutsätts att inblandade parter har tillgång till en gemensam information om var hållplatser, adresser och andra relevanta platser är belägna och kan identifiera dessa.

Samtidigt behöver inte alla inblandade system arbeta på samma detaljeringsnivå, utan olika system kan arbeta med delvis olika datauppsättningar.

En reseplanerarapplikation behöver exempelvis förutom information om var de olika hållplatslägena och adresserna ligger, även ha kunskap om bytesprioritet för respektive hållplatsområde och bytestid mellan olika hållplatslägen (gånglänkar).5

Olika system kan också arbeta på olika sätt, vissa använder unika nycklar för att identifiera en punkt, medan det ibland räcker att använda de geografiska koordinaterna. Ibland krävs det att system hanterar både koor-dinater och unika nycklar för att kunna lösa sin uppgift och utväxla information med andra system.

5.6 Information om resmöjligheter

I förväg så har de olika trafikföretagen matat in beskrivningar av de resmöjligheter som de erbjuder.

5 NOPTIS gränssnitt används redan i dag för att utväxla sådan typ av information.

Titel Sida




Figur 6 Beskrivning av en linjelagd tur

Med utgångspunkt från den gemensamma geografin beskriver varje företag vilka hållplatser som angörs vid varje tur och vid vilka tider turen kommer till de olika hållplatserna. När företag A är klar med sina turpla-ner så exporteras de genom fastlagda gränssnitt till ett centralt system där de kan läggas ihop med andra företags linjelagda trafik.

Figur 7 Linjelagd kollektivtrafik från företag A och B läggs samman…

Turplanerna för den linjelagda trafiken kan förutom en detaljerad beskrivning av turerna också innehålla samtrafikregler där det beskrivs under vilka förutsättningar respektive tur kan tänkas invänta resenärer som byter från försenade turer på andra linjer. Så här långt har vi i princip beskrivit en etablerad process6.

6 Om vi exempelvis studerar SL, så finns det i dag en process etablerad där alla entreprenörer för buss, tun-nelbana, pendeltåg och övriga spårbundna trafikslag kontinuerligt exporterar sina turplaner till en integra-tor-applikation enligt NOPTIS-gränssnitt. Till integratorn skickas även Waxholmstrafikens turplaner enligt NOPTIS-gränssnitt.

Titel Sida




Figur 8 Beskrivning av en anropsstyrd tur med förbeställningstid och bytesregel läggs till

Projektets förslag är att man i tillägg till turplaner för den linjelagda kollektivtrafiken även tillför turplaner som beskriver den anropsstyrda kollektivtrafiken.

Dessa turplaner exporteras med samma gränssnitt som används för den linjelagda trafiken men innehåller även förbeställningstider och kontaktuppgifter för bokning.7 Om det rör sig om anropsstyrd områdestrafik så anger man en referens till det anropsstyrda området istället för till ett specifikt fysiskt hållplatsläge. Tur-planerna kan precis som för linjelagd kollektivtrafik innehålla bytesregler.

Värt att notera är att turer för anropsstyrd områdestrafik som är avsedd att avleverera resenärer till den lin-jelagda trafiken typiskt anges med en tidigaste avgångstid från det anropsstyrda området som ger marginal för olika körvägar och trafikfall, men har en precist angiven senaste ankomsttid till bytespunkten. Turer som hämtar upp resenärer vid bytespunkter har på motsvarande sätt en precist angiven avgångstid och en ankomsttid som ger marginal för olika trafikfall.

Turplanerna från de olika trafikföretagen verifieras efterhand som de tas emot i det centrala systemet (integ-rator-systemet) och bytesregler appliceras på den samlade informationen. Information om inställda turer, extra turer och andra avvikelser från den ursprungliga planen samt realtidsinformation tillförs kontinuer-

7 NOPTIS-gränssnittet stödjer redan i dag information om förbeställningstider och kontaktuppgifter för bok-ning av resa och det borde därför vara möjligt att redan med dagens planeringssystem för linjelagd trafik och dagens integratorsystem hantera grundläggande information om allmän anropsstyrd kollektivtrafik. Redan i dag finns också möjlighet att ange viss tillgänglighetsinformation såsom antal rullstolsplatser, barn-vagnsplatser, låggolv/låg entré.

Genom mindre tillägg i NOPTIS-gränssnittet skulle ytterligare information som är viktig för resenärer med särskilda behov kunna tillföras, exempelvis platsbokning i linjelagd trafik.

Titel Sida




ligt.8 Den integrerade informationen inklusive realtidsändringar är genom fastlagda gränssnitt åtkomlig för olika slags användande system.9

Figur 9 Inställda turer och förseningar ingår som en del av den samlade bilden

8 Vid exempelvis SL levererar fordonssystem för bland annat buss, pendeltåg och tvärbana realtidsinformat-ion enligt NOPTIS gränssnitt till integratorn. Ett flertal system levererar parallellt trafikledaråtgärder och störningsinformation för de olika trafikslagen till integratorn.

9Om vi fortsätter med exemplet SL så tillhandahåller integratorn den samlade bilden inklusive realtid på NOPTIS gränssnitt. Ett flertal presentationssystem använder denna information för olika ändamål. Detta innefattar plattformsskyltar för pendeltågen, reseplanerare, webb med mera.

Titel Sida




5.7 Planering av resan

Resenären kan i sin dator eller i mobilen undersöka vilka resmöjligheter som står till buds med hjälp av en reseplanerare.10

Figur 10 Vår resenär ska resa från sitt hem på Aspv 7 till Tuleparken

Som ett alternativ till att välja en viss starthållplats kan resenären välja sin startpunkt med hjälp av en kart-applikation eller genom att mata in sin adress. Både kartan och adressen kan användas för att fram en koor-dinat som anger resenärens önskade startpunkt.

Reseplaneraren kan sedan identifiera om koordinaten ligger nära en hållplats eller om den ligger inom grän-serna för ett område med anropsstyrd områdestrafik. Efter att ett sådant område har identifierats kan en traditionell sökning göras. I detta fall likställs det identifierade området (område B) tillfälligt med en håll-plats varefter sökningen kan göras som om det handlat om en traditionell punkt till punkt sökning. Tid-punkten för avgång från område B är tills vidare satt som tidigast tänkbara avgångstid. I praktiken kan det bli en senare avgångstid, men det avgörs inte förrän i ett senare skede.

10 För att framhäva grundbudskapet visas inte alla aspekter av en sökning i den löpande texten. I en riktig dialog finns givetvis fler möjligheter, moderna reseplanerare kan ta hänsyn till många olika slags parametrar för att anpassa och optimera sökningen utifrån den enskilde resenärens behov och preferenser. Detta ställer i sin tur krav på att bakomliggande system kan tillhandahåll information om tillgänglighet och andra rele-vanta faktorer.

Titel Sida




Figur 11 Även om B egentligen motsvarar ett område så kan reseplaneraren betrakta det som om det vore en punkt när resan ska beräknas.

När reseplaneraren har funnit en lämplig resmöjlighet så presenteras den för resenären. I detta fall ingår en anropsstyrd tur i resan.

Figur 12 Resvägsförslag där anropsstyrd resa ingår

I detta skede är det två saker som skiljer den anropsstyrda resan från en resa med linjelagd trafik. Dels finns det en upplysning om att resan måste förbokas, dels finns en länk för att komma till bokningsapplikationen.

Om resenären väljer att klicka på bokningslänken så skickas hela resvägsförslaget över till en bokningsap-plikation.

Titel Sida




5.8 Bokning och betalning

Figur 13 Bokningsapplikationen har detaljerad kunskap om vilka mötespunkter som finns i området

Bokningsapplikationen förväntas kunna låsa en bokning. Här gäller det främst att kunna garantera resenä-ren att det kommer att finnas fordonsresurser så att resan kan genomföras. Detta kräverantingen att

a) bokningsapplikationen är en del av beställarsystemet för anropsstyrd trafik eller

b) att bokningsapplikationen har en nära interaktion med beställarsystemet för anropsstyrd trafik.

Alternativ b) kräver ett gränssnitt med dubbelriktad kommunikation mellan bokningssystem och beställar-system. Exempel på hur en sådan dialog skulle se ut beskrivs senare i rapporten.

Beroende på beställarsystem och rutiner kan kunden för vissa system redan i detta läge få en snävare tids-angivelse för när upphämtning sker. I andra fall så görs ingen planering i samband med beställning, utan optimering av tider görs i senare skede.

Bokningsapplikationen är lämpligen den applikation som knyter samman bokning med prisförfrågan och betalningsflöde, men betalningsflödet hanteras vanligtvis av en separat systemkomponent. Utifrån använda-rens perspektiv kan ändå bokning och betalning upplevas som en del av samma flöde.

I detta projekt är inte själva betalhanteringen i fokus, men vi ser framför oss att man borde kunna hitta lös-ningar som baserar sig på betalning med kreditkort, att ett belopp dras från en virtuell börs, att beloppet faktureras eller att kortnumret för ett periodkort eller tillstånd att resa gratis presenteras.

Resenären måste på något sätt kunna redovisa att betalning skett. Lämpligt är att resenären får en färdhand-ling i form av ett kvitto att visa upp. Detta kvitto skulle kunna innehålla en kombination av läsbar text och krypterad information i form av läsbar text och siffror, en QR-kod eller utgöra kod som kan hanteras genom NFC.

Titel Sida




Figur 14 Kunden betalar hela resan i förväg

Kvittot bör alltså kunna redovisas i ett SMS, i en mobil-applikation alternativt skrivas ut på papper. För vissa typer av kunder skulle man också kunna tänka sig att de ska visa upp ett plastkort med unikt kortnummer (kollektivtrafikkort, betalkort eller ID-kort) som ett alternativ till eller som ett komplement till kvittot.

I det ovanstående beskrivs en bokning av en enkelresa. För att underlätta för de resenärer som gör åter-kommande resor hade det varit bra om bokningsapplikationen också tillät en samlad bokning av flera resor.

5.9 Resan

Figur 15 Resan består i detta fall av tre delresor och har därmed två byten

Titel Sida




Den kopplade resan genomförs. Som utgångspunkt utgår man från att byten kan ske enligt ursprunglig plan. Eftersom olika saker kan inträffa i realtid behöver olika situationer som påverkar ingående delresor och bytet mellan delresor förmedlas till resenär och/eller involverade förare och/eller trafikledare.

De underliggande systemen för linjelagd trafik och anropsstyrd trafik kan använda redan befintliga NOPTIS respektive SUTI gränssnitt för att skicka olika typer av meddelanden för att på teknisk nivå förmedla an-komst och avgångshändelser och ändringar av olika slag.

Figur 16 Resenären kan använda sin smarta mobil som resebevis och för att få information före och under resan

Med denna realtidsinformation, och i och med att resan med dess delresor är känd inklusive regler för by-teshantering, finns därmed förutsättningar för att inblandade system kan agera korrekt och ge resenär, fö-rare och trafikledare nödvändig information när undantag eller ändringar inträffar i realtid. Om exempelvis en busstur ställs in så får ju inte kunden bli ståendes på en otillgänglig hållplats i regn och rusk.

5.10 Uppföljning på utförda resor

En viktig del i arbetsflödet är att studera i vilken mån utbudet passar behoven. Ett sätt att skaffa sig sådan kunskap är att ta reda på hur många, och vilka av de erbjudna anropsstyrda turerna som har utnyttjats.

En möjlighet är givetvis att låta bokningsapplikationen föra statistik över detta lokalt, men bokningsappli-kationen kan också rapportera när en viss anropsstyrd tur har beställts på NOPTIS-gränssnittet RII. Därmed blir informationen tillgänglig både i realtid och för senare uppföljning.11

5.11 Ansvar gentemot resenären i kopplade resor

Vad händer när något går snett i en kopplad resa? Vem hjälper resenären vid ett missat byte? I många fall kommer de ingående delresorna att utföras av olika trafikföretag. Resenären behöver kunna känna sig trygg när det gäller betalningar, resegarantier och ha någonstans att vända sig och få hjälp om det uppstår pro-blem. Kanske krävs det någon slags kundservice kopplad till den part som ansvarar för bokningen av den kopplade resan. Denna part får sedan i sin tur ta diskussionen med den part som felat.12

För att det ska bli en effektiv process att reda ut om vem som brustit är det viktigt att regelverket kring kopplade resor blir tydligt så man vet hur länge det upphämtande fordonet skulle invänta ett försenat av-

11 Andra faktorer som kan vara intressanta att följa upp är exempelvis beläggningsgrad i fordon, emissioner och bränsleval för de fordon som används.

12 Ett alternativt förslag är att kunden i första hand själv ska ta kontakt med den part de upplever har felat och i andra hand med den som ansvarar för bokningen.

Titel Sida




lämnande fordon och att faktiska tidpunkter för ankomster13 och avgångar14 registreras. Dessa typer av upp-gifter hanteras redan i dag i NOPTIS-gränssnitten för den linjelagda trafiken. En förutsättning för en funge-rande helhet är att uppgifter om när en kund hämtas respektive lämnas kan överföras från det anropsstyrda systemet och översättas till avgångs- och ankomsthändelser på aktuell anropsstyrd tur i det linjelagda sy-stemet.15

13 Hämtat kund.

14 Lämnat kund.

15 Lämpliga meddelandeformat finns redan i dag både i NOPTIS och i SUTI-gränssnitten, men det krävs att någon applikation översätter mellan formaten.

Titel Sida




6 Inventering datakällor

6.1 Geografi

6.1.1 Hållplatsregister

I dag finns det relativt god tillgång till information om vilka hållplatser som används av den linjelagda trafi-ken och var de är belägna. I viss mån finns också information som beskriver egenskaper som öppettider, om uppvärmning finns, tillgång till WC, ledsagarservice et cetera på respektive hållplats. Detta kan användas för att bedöma hållplatsens lämplighet som bytespunkt för olika resenärskategorier.

En ambition hos exempelvis Västtrafik är att på sikt även upprätta register och kunna ge tillgång till namn och koordinater för mötespunkter och servicepunkter i den anropsstyrda trafiken.

Denna information borde vara möjlig att få tillgång till kostnadsfritt.

6.1.2 Adresser från fastighetsregistret

Lantmäteriet har adressinformation och koordinatlägen för fastigheter i Sverige. Tyvärr är denna informat-ion inte kostnadsfri utan har ett så högt pris att vissa trafikföretag som skulle kunna ha nytta av informat-ionen avstår att ta till sig den av kostnadsskäl.

Om denna information istället tillhandhölls kostnadsfritt eller till ett självkostnadspris hade fler trafikföretag använt sig av den. Det borde ligga i samhällets intresse att trafikföretagen använder korrekt adressinformat-ion.Därigenom kan antalet felkörningar med de kostnader dessa medför ekonomiskt, miljömässigt och tids-mässigtminimeras.

Åtminstone historiskt har det även funnits problem med att adressuppgifterna från Lantmäteriet har olika detaljeringsgrad i olika områden, exempelvis saknas ibland vägnamn.

Västtrafik gör årliga uttag av Adressplats light (90B ADRPLL) från Lantmäteriets Fastighetsregister (FR-ADR) till en kostnad av ca 110 000 kr per år för samtliga kommuner inom Västra Götaland samt Kungs-backa, Varberg och Falkenberg. Med detta uttag får de tillgång till koordinatläge för olika adresser.

I appendix finns ett fördjupande avsnitt om geodata från Lantmäteriet och ytterligare exempel på kostnads-bilden.

6.1.3 Övriga kända platser –POI (Point Of Interest)

Det finns ett stort behov av att koordinatsätta andra kända platser som man kan tänkas vilja resa från.

I Västtrafiks fall har man fått viss information från Turistrådet som man sedan har bearbetat och komplette-rat med ytterligare platser såsom sjukhus, sjukhem och vårdcentraler.

Många taxiföretag har upprättat sina egna register över kända platser. Det har vid olika tillfällen gjorts sam-körningar mellan sådana register från olika trafikföretag för att försöka skapa mer heltäckande register.

Formerna för att få tillgång till trafikföretagens information behöver redas ut liksom hur informationen kan kvalitetssäkras. Senare i rapporten finns ett förslag på en möjlig metodik.

Titel Sida




6.1.4 Vägnät

En annan viktig datakälla är Trafikverket som tillhandahåller data om vägnätet genom sin databas NVDB. NVDB innehåller detaljerad information om vägsträckningar med mera, men saknar koppling till informat-ion om gatunummer eller fastighetsbeteckningar.16 Dessa data finns tillgängliga till självkostnadspris. NVDB är inte helt komplett för direkt användning i linjelagd kollektivtrafik utan bearbetas och kompletteras i dags-läget på olika sätt. Västtrafik lägger exempelvis till information om körvägar inne på terminaler.

I vissa fall behöver även taxi lägga in kompletterande uppgifter i sina system för att beskriva var i vägnätet infarten till en viss adress ligger.

6.1.5 Nationell geodatastrategi

Lantmäteriet och Geodatarådet har i samråd med informationsansvariga organisationer, parter i Geodata-samverkan och andra berörda organisationer tagit fram ett dokument som beskriver en nationell geoda-tastrategi. Det framgår bland annat av dokumentet att det är en strategi som utgår från att informationen är avgiftsbelagd:

Vi har enkla och enhetliga villkor och avgifter för geodata som bidrar till en bred och omfattande an-vändning. Användare av geodata får enkelt en överblick av de villkor och avgifter som gäller. Villkoren och avgifterna för användning är relevanta, icke-diskriminerande och tydligt beskrivna. Digital licens-hantering ger användaren snabb och enkel tillgång till geodata.

Representanter för branschen framhåller att problemet inte bara handlar om att informationen kan erbjudas till enhetliga priser, utan primärt om att dagens prisläge på adressinformation är för högt och att man istället bör eftersträva att tillgång till geografisk information i princip ska vara fri och att kostnader enbart bör mot-svara merkostnad för att tillhandahålla informationen till respektive part. I annat fall riskerar vi att det inte blir den breda och omfattande användning som geodatastrategin förespeglar.

Risken är att man avstår från att använda information som kunde optimerat fordonsanvändning av kost-nadsskäl.

Som en jämförelse så är Danmark på väg att etablera fri tillgång till myndigheternas geodata:

Vi skal have en mere moderne offentlige sektor og løse opgaverne klogere, så vores fælles penge i kommune- eller statskassen bruges bedst muligt, og det sikrer vi med det her projekt”, siger finansminister Bjarne Corydon.

Grunddata kan være borgernes adresser, virksomhedernes CVR-numre eller ejendommes matrikelnummer. Altså data, der bruges igen og igen på tværs af hele den offentlige sektor, for at opkræve ejendomsskat, udbetale sociale ydelser eller forebygge oversvømmelser.

Også virksomhederne har udsigt til store besparelser, når de ikke længere skal købe de grunddata, de har brug for, fra det offentlige. Det giver nye muligheder for innovation og vækst, idet særligt de

16 I vissa system ”snappar” man till vägnätet vid den punkt i vägnätet som ligger närmast koordinaterna för sökt adress. Detta ger ofta rätt resultat, men kan i vissa fall, speciellt i glesbygd leda taxi till en väg som går nära sökt adress, men som saknar infart till byggnaden.

Titel Sida




mindre virksomheder og iværksættere får mulighed for at afprøve nye ideer, uden først at skulle investere massivt i de data, der er nødvendige for at skabe deres produkt.17

Utifrån detta har en konstruktiv dialog inletts med Lantmäteriet för att försöka hitta kostnads- och finansie-ringsmodeller som är acceptabla för berörda parter.

6.1.6 En gemensam geodata-portal

Lantmäteriet erbjuder något som kallas för Geodataportalen där geodataproducenter har möjlighet att besk-riva och tillgängliggöra sin information. Detta är något som man bör ha i åtanke om det ska etableras en portal med gemensam information för den samlade kollektivtrafiken. Geodataportalen är inte tänkt att inne-hålla själva informationen utan länkar istället vidare till en extern källa. Dock kan Geodataportalen erbjuda att hålla viss metadata och visst stöd för att synliggöra vilka källor som täcker vilka geografiska regioner.

17 http://fm.dk/nyheder/pressemeddelelser/2012/10/danmarks-digitale-raastof-saettes-fri/

Titel Sida




7 Kartlägga gränssnitt för informationsutbyte mellan system

7.1 Transmodel

Transmodel är en europisk norm (EN12986) som beskriver en konceptuell datamodell för informationssy-stem inom kollektivtrafik.

7.2 NOPTIS

NOPTIS (Nordic Public Transport Interface Standard) är en uppsättning Transmodel(EN12986)-baserade gränssnitt som används för att överföra statisk och dynamisk information mellan olika tekniska delsystem inom kollektivtrafik. NOPTIS är en de facto standard framtagen av Movia, Skånetrafiken, Storstockholms Lokaltrafik och Västtrafik med stöd av SLTF och BR.

7.3 NeTEx, SIRI och GTFS

Övriga gränssnitt som har studerats är GTFS (General Transit Feed Specification) från Google och den kom-mande Europa standarden NeTEx (Network and Timetable Exchange) samt SIRI (Service Interface for Real Time Information, CEN/TS 15531). Såväl NeTEx som SIRI är baserade på Transmodel(EN12986).

NeTEx, SIRI och NOPTIS delar alltså samma konceptuella datamodell och är i vissa stycken lika.

Det som framförallt skiljer NeTEx och SIRI från NOPTIS är att NOPTIS har kunnat definieras mer konse-kvent och entydigt utifrån ett samsynt nordiskt perspektiv. Såväl SIRI som NeTEx innehåller delvis redun-danta konstruktioner för att underlätta övergång från tidigare standarder som använts i de olika länderna. Samma typ av information kan alltså överföras på flera olika sätt. Normalt sett krävs det därför anpassning av det ena eller båda involverade system för att de ska kunna kommunicera med hjälp av SIRI eller NeTEx. För att delvis undvika detta problem finns det en framtagen mappning till NOPTIS i NeTEx. Man skulle alltså relativt entydigt kunna kommunicera med NeTEx om man tillämpade den mappning som anges.

Vad gäller GTFS så är den relativt rättfram och entydigt beskriven, men den är inte baserad på Transmodel och innehåller en terminologi som delvis är i konflikt med Transmodel. Den innehåller en relativt enkel da-tamodell som inte kan uttrycka alla nödvändiga aspekter för den typ av lösningar som är i fokus för detta projekt.

7.4 SUTI

SUTI (Standardiserat utbyte av trafik information) beskriver gränssnitt för bland annat dynamisk resursallo-kering, orderhantering och trafikledning med inriktning mot dialogen mellan beställarsystem och utfö-rare/utförarsystem inom anropsstyrd trafik.

Titel Sida




8 Specificera informationsnavets gränssnitt utifrån etablerade standarder – avkortad version

Följande kapitel är en förenklad beskrivning av ämnet. För den som vill få en djupare förståelse och se fler tekniska de-taljer och exempel rekommenderas att istället läsa motsvarande kapitel i appendix som är betydligt mer omfattande och detaljerat.

Utgångspunkten är att så långt som möjligt utgå från de befintliga gränssnitten NOPTIS och SUTI.

Till stora delar täcker dessa gränssnitt redan det som krävs. I vissa fall behöver det dock tydliggöras hur de ska användas för att kunna beskriva kopplade resor mellan linjelagd och anropsstyrd kollektivtrafik.

8.1 Geodata som behövs för kopplade resor

Förslaget är att i första hand utgå från den befintliga geografin för den linjelagda trafiken och i dess geodata tillföra uppgift om vilka anropsstyrda områdena som finns, samt att tillföra uppgift om stoppställe för taxi i de hållplatsområden där det är aktuellt att utföra byten.

8.1.1 Geodata som krävs för att beskriva den linjelagda trafiken

Med NOPTIS kan nödvändig geodata för den linjelagda trafiken beskrivas.

8.1.2 Anropsstyrda områden

Det är värt att notera att när vi i detta dokument pratar om anropsstyrd områdestrafik så avser vi både

Figur 17 Anropsstyrd områdestrafik - till adresser och till mötespunkter

anropsstyrd kollektivtrafik med fasta mötespunkter och anropsstyrd kollektivtrafik till alla adresser i ett område.

Titel Sida




Vad det gäller anropsstyrda områden är det också viktigt att förstå skillnaden mellan dessa och de zoner som används i de anropsstyrda systemen. Även om de anropsstyrda områdena också är ett slags zoner så har de ett annat syfte och är ofta betydligt större än de detaljerade zonerna som vanligtvis används i de an-ropsstyrda systemen.

Figur 18 Anropsstyrda områden är inte samma sak som de detaljerade zoner som används inom den an-ropsstyrda trafiken.

De anropsstyrda områdena modelleras på samma sätt som den linjelagda trafikens övriga hållplatsområden, men märks upp med uppgift om att de utgör anropsstyrda områden.

8.1.3 Bytespunkter

Bytespunkter är särskilt viktiga eftersom det är punkter där resenärer byter mellan två fordon. Eftersom dessa två fordon kanske trafikleds och hanteras i olika tekniska system är det viktigt att det finns sätt att referera till bytespunkten som inblandade system förstår.

Ordet punkt i bytespunkt måste tolkas på ett speciellt sätt då den oftast avser ett område med flera (mer eller mindre närliggande) positioner där avstigning och påstigning kan ske. Oftast är det olika positioner som används för taxi, buss eller tåg.

Bytet sker alltså inte nödvändigtvis i EN punkt utan resenären kan få stiga av vid en punkt på en terminal och kliva ombord vid en annan punkt. Ett stoppställe kan exempelvis vara en busshållplats eller en taxi-ficka.

I vissa fall omfattar bytespunkten flera närliggande hållplatsområden för olika trafikslag (oftast med samma namn) på samma plats. Det förekommer också att en bytespunkt utgörs av flera hållplatsområden med olika namn men där deras respektive stoppställen är förbundna med varandra med byteslänkar18.

18 Den vanligaste formen av byteslänk är en gånglänk mellan två hållplatslägen. Dessa hållplatslägen kan vara inom samma hållplatsområde, eller inom två olika hållplatsområden.

Titel Sida




8.1.4 Stoppställen för lätta fordon (Taxifickor)

När en resenär i en kopplad resa byter fordon vid en terminal innebär det ofta att avstigningspunkten och påstigningspunkten inte ligger i direkt anslutning till varandra. I beskrivningen av hållplatsområdet bör det därför ingå uppgifter om de enskilda stoppställena, inte bara för den linjelagda trafikens bussar och tåg, utan det bör även anges var stoppställe för lätta fordon finns så att resenären kan hitta den väntande taxin.

8.2 Geodata som behövs i den anropsstyrda trafikens system

8.2.1 Platser – Bytespunkter

Den anropsstyrda trafiken behöver få tillgång till information om de hållplatser där byte kan ske till eller från den linjelagda trafiken.

8.2.2 Platser - POI (Point Of Interest)

Utöver de platser (främst hållplatsområden) som används för att beskriva geografi för den linjelagda trafi-ken så finns det ett behov av att upprätta gemensam information om andra platser som utgör tänkbara start- och ändpunkter för en resa. Det handlar om vårdinrättningar, etablissemang av olika slag, torg och så vi-dare. I dag finns kunskapen och uppgifter om deras namn och olika alias utspridd bland Sveriges trafikföre-tag.

8.2.3 Platser – Adresser

Förslaget är att utgå från information från Lantmäteriet enligt Adressplats light (90B).

8.3 Gränssnitt för att leverera turplaner för den linjelagda kollektivtrafiken

Förslaget är att använda NOPTIS Data Import Interface (DII).

8.4 Gränssnitt för att leverera turplaner för den anropsstyrda kollektivtrafiken


Observera att arbetsuppgiften att skapa turplaner för den anropsstyrda trafiken inte behöver ske i samma system som hanterar den anropsstyrda trafiken. Det är inte heller säkert att alla system involverade i den anropsstyrda trafiken behöver ha detaljerad kunskap om dessa turplaner, utan det kan i vissa fall räcka att hantera konsekvenserna vad gäller resursallokering som dessa resulterar i.

Troligtvis kan samma system som används för att planera den linjelagda trafiken användas även för att skapa turplaner för den anropsstyrda trafik som ska exponeras i reseplanerare och andra system för den linjelagda trafiken. Med nuvarande version av NOPTIS DII så är det möjligt att utan förändringar:

1) Beskriva sådana anropsstyrda turer som körs med fast linjesträckning och enligt fastlagda tider, men som måste förbeställas.

2) Beskriva anropsstyrd områdestrafik och anropsstyrd trafik med mötesplatser. Det förutsätter att man använder konceptet där en virtuell hållplats används för att representera ett område.

Titel Sida




Däremot så skulle det krävas en mindre ändring i gränssnittet (och kanske även i dagens planeringssy-stem19) om man utöver ovanstående önskar kunna beskriva linjelagd trafik med anropsstyrd avvikelse.

Om ambitionen är att erbjuda anropsstyrd områdestrafik i ett tidsintervall, så kan det vara lämpligt att lägga upp ett antal trafikturer mellan det anropsstyrda området och vald bytespunkt som matchar valda linjelagda trafikturer i stomtrafiken i önskad tidsperiod.

Om det senare i realtid visar sig att utbudet är för stort för tillgängliga resurser så kan ett antal av trafiktu-rerna dras tillbaka.

8.5 Gränssnitt för att leverera bokningsförfrågan

Detta är ett gränssnitt som behöver definieras.

När en reseplanerare hittar ett resvägsförslag som innehåller en delresa som måste förbokas, så vore det lämpligt att kunna göra en smidig överlämning av hela reseförslaget till en bokningsapplikation.

För att möjliggöra fristående bokningsapplikationer behövs ett gränssnitt för att överföra information om bokningsförfrågan. Samtliga delresor som ingår i reseförslaget bör överföras tillsammans som en enhet. Varje ingående delresa beskrivs med ett antal detaljer.

8.6 Gränssnitt för att utväxla information om reservation och bokning

Detta är ett gränssnitt som behöver definieras.

I ett första steg skickas en reservationsförfrågan från bokande systemet till relevant utförar- eller beställar-system. Om det mottagande systemet kan acceptera delresan returneras en bekräftelse till det frågande sy-stemet.

När reservationer för samtliga delresor har accepterats så kan köpet genomföras och resenären debiteras på lämpligt sätt från bokningsapplikationen. I dialog med resenären fastställs ett unikt sätt att identifiera rese-nären, exempelvis genom att resenären kan visa upp ett kreditkort eller någon annan handling med unikt id under resan.

För vissa typer av resenärer och resor kan det tänkas att resenärer inte debiteras direkt utan att det istället är en organisation som debiteras. Det är inte heller säkert resenärer med särskilda behov ska behöva visa upp någon speciell handling för att få genomföra resan. I dessa fall kan det kanske räcka att upphämtningspunk-ten är känd och att resenären ledsagas i eventuella byten så att en obruten kedja erhålls.

När resenären betalt för resan skickas de slutliga bokningarna och som svar mottas bokningsbekräftelser.

Systemet som ska utföra delresan kan i sin bekräftelse returnera extra information som bokningsapplikation ska tillföra till färdhandlingen.

När bokningen är genomförd kan bokningsapplikationen producera en färdhandling.

19 Beslutar man att använda anropsstyrd avvikelse behöver leverantörerna av aktuella planeringssystem involveras i arbetet med att göra de anpassningar som krävs.

Titel Sida




8.7 Gränssnitt för dialog mellan beställar- och utförarsystem i den anropsstyrda trafiken – Resursallokering, order och dirigeringen av fordon

Förslaget är att fortsatt använda befintliga SUTI meddelanden.

8.8 Gränssnitt för att utbyta information om kortsiktiga ändringar och realtids-händelser

Förslaget är att utgå från befintliga NOPTIS meddelanden.

I NOPTIS finns det två parallella meddelandeformat för att överföra kortsiktiga ändringar och realtidshän-delser. Dels ett format som medger att varje ändring eller realtidshändelse kan rapporteras separat,dels ett format för att förmedla en sammanställd bild av alla gjorda ändringar och realtidshändelser för hela eller delar av trafiken. Genom denna uppdelning möjliggörs att information från många källor kan integreras i ett separat system och att sedan olika användande system från detta system kan hämta en konsekvent och komplett bild för den samlade trafiken.

8.8.1 Gränssnitt för att meddela kortsiktiga ändringar av utbudet

NOPTIS RII är ett gränssnitt för att överföra information om kortsiktiga förändringar i trafiken. Detta gräns-snitt används redan i dag för att från olika tekniska system i den linjelagda trafiken meddela in ändringar i förhållande till turplanerna. Det kan röra sig om helt eller delvis inställda trafikturer, extra trafikturer, änd-rade ankomstspår för tåg och liknande.

Exempelvis kan anropsstyrda trafikturer behöva ställas in på grund av resursbrist. Det är en fördel om detta rapporteras in så tidigt som möjligt så att exempelvis reseplaneraren ger en rättvisande bild av resemöjlig-heterna. På sikt kan man kanske automatisera processen att skicka in sådana meddelanden direkt från be-ställarsystem för anropsstyrd trafik i samband med resursbrist, annars finns redan i dag möjlighet att manu-ellt rapportera in förändringar i trafiken med befintliga applikationer som används av den linjelagda trafi-ken. Dessa applikationer borde även kunna användas av personal som arbetar med anropsstyrd trafik.

Andra kortsiktiga ändringar som kan vara relevanta vid kopplade resor är:

• Ändrad tid för ankomst eller avgång

• Anropsstyrd kollektivtrafiktur har beställts

• Ändrad bytespunkt för en kopplad resa

8.8.2 Gränssnitt för att meddela realtidshändelser

NOPTIS VSI är ett gränssnitt för att överföra information om realtidshändelser och prognoser. Detta gräns-snitt används redan i dag för att från olika tekniska system i den linjelagda trafiken meddela när buss, tåg och andra trafikslag i den linjelagda trafiken ankommer och avgår från hållplatser i realtid.

8.8.3 Gränssnitt för att ge tillgång till en samlad realtidsinformation

NOPTIS ROI är ett gränssnitt för att i realtid överföra information om trafikturer med applicerade ändringar, realtidshändelser samt prognoser och konsekvenser av samtrafik med andra trafikturer.

Titel Sida




Detta gränssnitt används i dag för att ge exempelvis reseplanerare tillgång till en samlad realtidsbild av den linjelagda trafiken i en region. För aktuella syften skulle det också kunna användas för att ge system i den anropsstyrda trafiken tillgång till realtidsinformation om andra trafikturer i kopplade resor.20

En bokningsapplikation eller en separat bevakningsapplikation skulle genom detta gränssnitt kunna bevaka trafikturer som ingår i bokade resor. Om störningar upptäcks på någon ingående trafiktur i en bokad resa så kan i så fall meddelande skickas till resenärer och berörda beställar- eller utförarsystem.

20 Som ett alternativ eller parallellt med NOPTIS ROI skulle SIRI gränssnitt kunna användas för att ge rese-planerare och andra system tillgång till realtidsinformation om trafiken.

Titel Sida




9 Förslag på förvaltningsorganisation och fortsatt utveckling Det finns ett antal olika områden där förvaltning skulle vara av intresse.

9.1 Förvaltning av en gemensam geodataportal

Förvaltningen kan avse flera olika saker:

• Ansvaret för att förvalta gränssnittsdokumenten som beskriver hur informationen ska utväxlas med en gemensam geodataportal. Detta bör göras på nationell nivå.

• Ansvaret att för en geodataportal förvalta platsinformationen på en överordnad nivå. Det vill säga koordinera och manuellt justera platsinformation där information från olika uppgiftslämnare är i konflikt. Detta kan göras på regional eller nationell nivå.

• Ansvar för ett eventuellt gemensamt tekniskt geodataportalsystem som kan kommunicera med tra-fikföretagen enligt fastställda gränssnitt. Detta kan ske på regional nivå eller på nationell nivå.

Tänkbara parter är Samtrafiken, Lantmäteriet, Trafikverket, de regionala kollektivtrafikmyndigheterna och länstrafikbolag. Vi har inom projektet bedömt att det är för tidigt att komma med en konkret rekommendat-ion innan förutsättningarna för tillgång till adressinformation har fastställts utifrån den problematik som lyfts fram kring kostnadsbilden. I ett fortsatt arbete bör dialogen med Lantmäteriet slutföras och förvalt-ningsorganisationen för en gemensam geodataportal fastställas.

9.2 Förvaltning av tillkommande gränssnitt för utväxling av information

Vad gäller befintliga NOPTIS-gränssnitten finns redan en förvaltning av dessa. Likaså finns det en levande förvaltning av SUTI-gränssnitten. För att inte komplicera arbetet i respektive grupp skulle tillämpliga delar av tillkommande gränssnitt kunna införlivas i respektive gränssnitt och därefter förvaltas av dessa.

9.3 Förvaltning av nummerserier och prefix i identifierare

För att tillåta att olika regioner fritt kan numrera sina linjer och hållplatsområden förutsätts respektive reg-ion/län ha ett eget prefix för sina identifierare. Samordning måste ske på nationell nivå för tilldelning av prefix för region/län. Ett förslag är att utgå från SCBs länsnumrering. Denna numrering används redan i dag för de regioner/län som i dag arbetar med NOPTIS-gränssnitt.

För att säkerställa Sverige-unika identifierare för linjenummer och trafikturer även för kommersiell trafik krävs däremot aktiv samordning på nationell nivå. Det som behövs är koordinering av tilldelning av prefix och nummerserier för linjenummer som inte ingår i den allmänna kollektivtrafiken. Här bör principen vara att stora kommersiella aktörer får egna prefix, och mindre får dela på ett prefix, men tilldelas nummerserier inom valt prefix.

9.4 Överordnad koordinering

För att underlätta koordinationen mellan de olika organ som nämns ovan bör en paraplyorganisation i ex-empelvis X2ABs regi skapas. Detta skulle också kunna vara ett forum för fler parter att få insyn i och ge in-put till fortsatt utveckling i gränssnitten.

Titel Sida




9.5 Fortsatt utveckling

9.5.1 Gränssnitt

Ett fortsatt arbete krävs för att slutföra tekniska specifikationer för tillkommande gränssnitt och API-er på detaljnivå. Det bör också tas fram en fristående användarguide som beskriver hur de olika ingående gräns-snitten ska användas och samverka.

9.5.2 Geodataportal

Utveckla ett tekniskt system för att samordna platsinformation (POI) från alla trafikföretag. Etablera en koppling till den nationella Geodataportalen, detta görs i en fortsatt dialog med Lantmäteriet.

9.5.3 Pilotprojekt för kopplade resor

För att testa metodik och gränssnitt som beskrivs i detta dokument bör pilotprojekt med kopplade resor mellan anropsstyrda områden och bytespunkter för stomtrafik genomföras.

Förslaget är inledningsvis att ett pilotprojekt genomförs inom ett avgränsat geografiskt område, men att det så långt som möjligt ska täcka alla aspekter av den föreslagna lösningen. Detta pilotprojekt kan sedan an-vändas som en grund för en lösning i större skala.

Titel Sida




10 Tänkbara frågeställningar att utreda vidare I projekt och remissarbetet har ett antal frågeställningar och idéer till fortsatta aktiviteter lyfts fram:

• En översiktlig inventering hos de regionala kollektivtrafikmyndigheterna för att se om det finns pla-ner för sammanlänkning av anropsstyrd och linjelagd trafik.

• Kalkyler över vilka kostnader som detta skulle innebära och hur många fler resenärer som kan lock-as över till kollektivtrafiken med det föreslagna konceptet.

• Jämförelse av miljömässiga vinster med det föreslagna konceptet relativt att man anlägger särskilda infartsparkeringar.

• En ekonomisk kalkyl av vilka kostnader som krävs för att etablera lösningar enligt förslaget.

• Kostnader för drift och uppdatering av gemensamma lösningar.

• Ett förslag till affärsmodell för att fördela dessa kostnader mellan de olika aktörerna.

• Utmaningar utöver tekniken – definitioner av affärsmodeller och hur överenskommelser mellan ak-törer bör se ut.

• Forskning kring differentierad prissättning för olika servicenivåer. Är resenärer utan särskilda be-hov beredda att betala mer för tillgång till bokad plats även i den allmänna linjetrafiken?

• Vilka utmaningar och möjligheter innebär det att introducera bokning av plats även i den allmänna linjetrafiken?

• Utredning av samordnade betallösningar.

Titel Sida




11 Referenser Börjesson, Mats, Westerlund, Yngve. Utveckling av anropsstyrd trafik Vägverket Publikation 2010:7

Börjesson, Mats. Slutrapport för projekt Glitter. Försök med utvecklad landsbygdstrafik. Vägverket Rapport 2003:89

Slutredovisning av FINAL-projektet. Fullständig integrering av anropsstyrd trafik och linjetrafik. Västtrafik 2005

Östlund B., Wärnfeldt Y., Jansson, G., Arnör, W., Westerlund, Y. FOKAT — Sammanfattande Slutrapport. Vägverket, 2006.

Hans Olof Gottfridsson. Dubbel kollektivtrafik - alla ombord?, Karlstad University Studies 2010:3

Information om SUTI http://www.suti.se

Information om NOPTIS http://www.noptis.org

Information om GTFS https://developers.google.com/transit/gtfs/reference

Transmodel (EN12986)

NeTEx (prCEN/TS 278307-1 to 3)

SIRI (CEN/TS 00278181-1 to 5)

Information om PayPal betallösning för mobilapp: https://cms.paypal.com/cms_content/US/en_US/files/developer/PP_MPL_Developer_Guide_and_Reference_Android.pdf

Information om svensk geodatastrategi: http://www.geodata.se/sv/Vad/Geodatastrategi/

Pressmeddelande om dansk geodatastrategi: http://fm.dk/nyheder/pressemeddelelser/2012/10/danmarks-digitale-raastof-saettes-fri

Information om flextrafik i Danmark: https://www.flexdanmark.dk/

Titel Sida




12 Appendix

12.1 Funktionsblock

Nedan beskrivs centrala funktionsblock för den tänkta lösningen. Dessa funktionsblock kan beroende på vad som är lämpligast i olika sammanhang antingen utvecklas i form av fristående applikationer eller ingå som en del i ett större system.

12.1.1 Planering av linjelagd kollektivtrafik

Detta funktionsblock löser uppgiften att skapa turplaner för den linjelagda trafiken. I dag kan exempelvis REBUS och HASTUS leverera turplaner på NOPTIS-gränssnittet DII.

12.1.2 Administrera geografisk information för den linjelagda trafiken

Detta funktionsblock löser uppgiften att tillhandahålla korrekt information om hållplatser, stoppställen och annan geografisk information för den linjelagda trafiken. I dag kan REBUS och en del andra system expor-tera denna typ av information på NOPTIS-gränssnittet DII.

12.1.3 Beskriva störningar och ändringar i förhållande till planerad trafik

Detta funktionsblock löser uppgiften att beskriva ändringar i förhållande till planerad trafik. Det kan röra sig om ändrad avgångstid, inställda eller delvis inställda turer eller extra turer utöver det som har planerats. Det kan också handla om ändrad angöringspunkt, exempelvis ändrad plattform för tåg. Utöver det kan det röra sig om störningsinformation som gäller för en eller flera turer eller för en eller flera hållplatsområden eller stationer samt ett antal ytterligare möjligheter. Ett flertal olika manuella och automatiska tekniska system kan i dag rapportera denna typ av information enligt NOPTIS-gränssnittet RII.

12.1.4 Rapportera realtidshändelser

Detta funktionsblock löser uppgiften att tillhandahålla information om ankomster till och avgångar från hållplatser i realtid från ett visst fordonssystem eller en viss fordonsflotta. Det är även möjligt att skicka pro-gnoser för när man förväntas ankomma till bytespunkter och andra hållplatser. Ett flertal olika tekniska sy-stem kan i dag rapportera denna typ av information enligt NOPTIS-gränssnittet VSI.

12.1.5 Integrera planerad information från flera källor

Detta funktionsblock försörjs med data enligt NOPTIS-gränssnittet DII. Den tar emot och sammanställer turplansinformation och geografisk information från flera olika källor. Den säkerställer att informationen från olika källor är konsekvent och hänger samman, applicerar bytesregler och sammanställer och exponerar all planerad information på ett entydigt format enligt NOPTIS-gränssnittet DOI. Detta funktionsblock ingår som en del i integratorn PubTrans.

12.1.6 Integrera information om störningar, ändringar och realtidshändelser från flera källor.

Detta funktionsblock skapar en samlad bild av trafiken i realtid genom att applicera ändringar i förhållande till den planerade trafiken och påföra konsekvenser av olika realtidshändelser.

Titel Sida




Underlaget utgörs av det sammanställda planerade utbudet enligt NOPTIS-gränssnittet DOI, ändringar en-ligt NOPTIS-gränssnittet RII och realtidshändelser enligt NOPTIS-gränssnittet VSI. Den samlade bilden ex-poneras på ett entydigt format enligt NOPTIS-gränssnittet ROI.

Detta funktionsblock ingår som en del i integratorn PubTrans.21

12.1.7 Reseplanerare

Detta funktionsblock beskriver resmöjligheter utifrån det samlade uppdaterade trafikutbudet. Den kan för-sörjas med nödvändig information genom NOPTIS-gränssnitten DOI och ROI.

12.1.8 Beställarsystem anropsstyrd trafik

Detta funktionsblock kommunicerar med utförarsystem enligt SUTI gränssnitt. Detta görs redan i dag. Den skulle med nyutveckling även kunna kommunicera med funktionsblocket bokning anropsstyrd trafik med nya SUTI-meddelanden.

12.1.9 Utförarsystem anropsstyrd trafik

Detta funktionsblock kommunicerar med beställarsystem enligt SUTI gränssnitt.

12.1.10 Bokning anropsstyrd trafik

Detta funktionsblock är nytt. Tänkt funktion beskrivs mer i detalj senare i rapporten.

12.1.11 Bevakning av byten

Detta funktionsblock är nytt, eventuellt utgör det en del av funktionsblocket bokning anropsstyrd trafik.

Detta funktionsblock ska bevaka kopplade turer och överföra realtidsinformation om inblandade fordon mellan SUTI och NOTIS i båda riktningar.

21Ett liknande funktionsblock finns som en del av realtidssystemet ITS4mobility. Detta system kan utifrån det sammanställda planerade utbudet enligt NOPTIS-gränssnittet DOI tillsammans med olika källor för ändrings och realtidsinformation producera uppdaterad information om trafikläget för aktuella fordon och linjer, samt via SIRI-gränssnitt leverera realtidsinformation till en reseplanerare. Denna information kombin-eras sedan i reseplaneraren med planerat utbud mottaget genom NOPTIS-gränssnittet DOI.

Titel Sida




12.2 Integrator

Figur 19 Integratorn kombinerar data från olika källor och tillhandahåller en sammanhållen konsekvent helhetsbild

En integrator är i detta sammanhang en systemkomponent som i realtid, automatiskt och kontinuerligt kombinerar data från flera olika källor och skapar och tillhandahåller en sammanhållen och konsekvent hel-hetsinformation till andra system.

Ovan visas ett exempel där de båda integrationsfunktionsblock som beskrivs i föregående kapitel har kom-binerats till en systemkomponent.

12.3 Kostnadsexempel och möjligheter för Lantmäteriets geodata

I Lantmäteriets prislista Avgifter och leveransinformation för Lantmäteriets geodata, år 2013 kan man utläsa att de företag som önskar ta ut samtliga adresser i Sverige (Adressplats light 90B)får betala kring en miljon kronor22 vardera.

Det finns en prisreduktion som gör att priset istället landar på ungefär 500 000 kr (en halv miljon kr) om det är en enda person inom företaget (ensamåkarföretag) som ska använda uppgifterna. För att få tillgång till uppdateringar av uppgifterna tillkommer sedan en ytterligare årlig prenumerationsavgift i ungefär samma storleksordning.

Varje företag som har ett eget organisationsnummer måste betala. Är företaget en del av en koncern finns möjlighet till en viss rabatt.

22 3,2 miljoner adresser och en kostnad på 40 öre styck med vissa mindre volymrabatter.

Titel Sida




Med denna prisbild och avgiftsmodell är det tveksamt om man kommer att få den breda och omfattande användning som geodatastrategin förespeglar. Risken är istället att många av de berörda företagen avstår från att använda information som kunnat optimera deras fordonsanvändning och gett dem möjlighet att utvidga sin verksamhet till nya geografiska områden.

Självklart kan varje företag välja att enbart ta ut ett mindre geografiskt utsnitt av informationen och därmed få en lägre kostnad, men det är ju en process i sig och innebär dessutom att företaget i förväg måste begränsa sitt tänkta arbetsområde.

En sådan uppdelning skulle ju också försvåra lösningar där flera företag med bara delvis överlappande ar-betsområden önskar arbeta mot en gemensam geodataportal. I och med att Lantmäteriets villkor och pris-modell är kopplad till respektive företags användning av adressinformation kan det bli svårt att hantera att olika företag bara har rätt att använda delar av adressinformationen.

12.3.1 Förslag till förändring

Förslaget är att geodatastrategin och Lantmäteriets prismodell modifieras och förenklas så att tillgång till geografisk information i princip blir fri för (åtminstone) allmänna och kommersiella trafikföretag som bedri-ver kollektivtrafik.

Det är acceptabelt att Lantmäteriet debiterar de specifika merkostnader som uppstår för att tillhandahålla informationen i respektive leverans, men inte att allmänna kostnader fördelas ut på användarna.

En sådan modell öppnar också upp för att flera trafikföretag kan gå samman och dela på uthämtad informat-ion och därmed få ytterligare kostnadsreduktioner.

12.3.2 Vinster

Genom en effektiv trafikledning, där bl.a. adressinformation av hög kvalitet är en viktig förutsättning, kommer taxibilar att styras mer exakt, mer energieffektivt med positiva effekter miljö, tidsåtgång och kost-nader. Trafikföretag kan spara arbetstid och bränsle och resenärer kommer i tid till sina res-mål/bytespunkter.

Det öppnas även upp möjligheter för en friare konkurrens och företagstillväxt inom kollektivtrafikmark-naden.

12.4 Specificera informationsnavets gränssnitt utifrån etablerade standarder – med tekniska detaljer

Utgångspunkten är att så långt som möjligt utgå från de befintliga gränssnitten NOPTIS och SUTI.

Till stora delar täcker dessa gränssnitt redan det som krävs. I vissa fall behöver det dock klargöras hur de ska användas för att kunna beskriva kopplade resor mellan linjelagd och anropsstyrd kollektivtrafik.

I den nedanstående texten förekommer en del engelska ord som komplement till den löpande texten för att förenkla kopplingen till terminologin i NOPTIS och SUTI.

Titel Sida




12.4.1 Allmänt om koordinatsystem

Koordinater för platser kan anges i olika koordinatsystem. Enklast är att använda WGS 84 i gränssnitten då detta är det koordinatsystem som används internt i det satellitnavigeringssystem23 som är helt dominerande i dag.

Samtidigt kan det vara lämpligt att centralt lagra positionsinformationen i SWEREF 99 TM för att undvika den glidning på några centimeter per år som gäller för positioner i WGS 84.

Observera att även om ett centralt system internt lagrar information enligt SWEREF 99 TM så bör det även kunna ta emot och tillhandahålla koordinater enligt WGS 84 (decimalt format).

Det är alltså det centrala systemets ansvar att vid behov konvertera mellan koordinatsystemen.

För fordonsnära tillämpningar används förslagsvis koordinater angivna enligt WGS 84 decimalt. Om meter-precision önskas är det lämpligt att ange koordinaterna med 5 decimalers noggrannhet.

12.4.2 Geodata som behövs för kopplade resor

Förslaget är att i första hand utgå från den befintliga geografin för den linjelagda trafiken och i dess geodata tillföra uppgift om vilka anropsstyrda områdena som finns, samt att tillföra uppgift om stoppställe för taxi i de hållplatsområden där det är aktuellt att utföra byten.

12.4.2.1 Geodata som krävs för att beskriva den linjelagda trafiken

Med NOPTIS kan nödvändig geodata för den linjelagda trafiken beskrivas. Det omfattar beskrivning av hållplatsområden (STOP AREAs), stoppställen/hållplatslägen (STOP POINTs), körvägslänkar (ROUTE LINKs), biljett och kommunzoner (ZONEs) aktiveringspunkter för trafikljusprioritering (ACTIVATION POINTs) med mera.

12.4.2.2 Anropsstyrda områden

Det är värt att notera att när vi i detta dokument pratar om anropsstyrd områdestrafik så avser vi både

23 NAVSTAR GPS (Navigation Signal Timing and Ranging GPS)

Titel Sida




Figur 20 Anropsstyrd områdestrafik - till adresser och till mötespunkter

anropsstyrd kollektivtrafik med fasta mötespunkter och anropsstyrd kollektivtrafik till alla adresser i ett område.

Vad det gäller anropsstyrda områden är det också viktigt att förstå skillnaden mellan dessa och de zoner som används i de anropsstyrda systemen. Även om de anropsstyrda områdena också är ett slags zoner så har de ett annat syfte och är ofta betydligt större än de detaljerade zonerna som vanligtvis används i de an-ropsstyrda systemen. De anropsstyrda områdena är främst tänkta för att kunna ringa in och namnge ett anropsstyrt område gentemot resenären.

Uppgifter om hur den anropsstyrda trafikens interna zonuppdelning ser ut eller uppgifter om exakta posit-ioner eller identiteter för mötesplatser behöver därför inte nödvändigtvis delas mellan den linjelagda och den anropsstyrda trafiken, utan kan fortsatt hållas enbart inom den anropsstyrda sfären som i dag.

Figur 21 Anropsstyrda områden är inte samma sak som de detaljerade zoner som används inom den an-ropsstyrda trafiken.

Titel Sida




De anropsstyrda områdena modelleras på samma sätt som den linjelagda trafikens övriga hållplatsområden, men märks upp med uppgift om att de utgör anropsstyrda områden.

I exemplet ovan så sparas alltså Gröndalsområdet som ett hållplatsområde (STOP AREA) med ett virtuellt stoppställe (STOP POINT) som beskriver områdets geografiska centroid24 tillsammans med information som beskriver det aktuella området utbredning i form av en radie eller alternativt en sluten kurva i form av ett polygontåg.

Hållplatsområde med virtuellt stoppställe

Nedan visas ett exempel på hur information om ett anropsstyrt område kan överföras på NOPTIS DII-format25.

<?xml version="1.0" encoding="UTF-8"?>

<NetworkVersion xmlns="http://www.pubtrans.com/DII/3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" DefaultCoordinateSys-

temName="WGS84" ModificationType="DEFINE" DocumentLayoutVersion="3.0.13" xsi:schemaLocation="http://www.pubtrans.com/DII/3.0

file:///Q:/PT/INTERFACES/DII/M/InternalUse/DII.xsd">

<Source CreatedDateTime="2013-01-23T09:23:01"/>

<IssuingTransportAuthorityRef><Number Number="1"/></IssuingTransportAuthorityRef>

<VersionFrameRef Name="X">

<DefiningOrganisationalUnitRef>

<OrganisationRef><ContractorRef><Number Number="12"/> </ContractorRef> </OrganisationRef>

</DefiningOrganisationalUnitRef>

</VersionFrameRef>

<StopAreas>

<StopArea Number="5237" Name="Gröndalsområdet" Type="UNKNOWN">

<StopPoints>

<StopPoint JourneyPatternPointNumber="5237" LocalNumber="1" Type="UNKNOWN" IsFictitious="Y">

<Keys>

<Key TypeName="FlexibleAreaPolylineBoundary">

<KeyValues>

<KeyValue VariantCode="SWEREF99TM" Value="6579699,669863 6580699,670863 6581699,669863 6580699,668863 6579699,669863"/>

</KeyValues>

</Key>

</Keys>

<Location Northing="6580699" Easting="669863" CoordinateSystem="SWERF99TM"/>

</StopPoint>

</StopPoints>

</StopArea>

</StopAreas>

</NetworkVersion>

24 Centroid-koordinaterna för denna punkt är huvudsakligen intressant i fallet att man beskriver området i form av en radie. Anledningen till att själva punkten behöver existera är att man formellt behöver en STOP POINT att referera till när man ska skapa trafikturer till eller från det anropsstyrda området.

25 NOPTIS DII 3 revision K eller senare.

Titel Sida




12.4.2.3 Bytespunkter

Bytespunkter är särskilt viktiga eftersom det är punkter där resenärer byter mellan två fordon. Eftersom dessa två fordon kanske trafikleds och hanteras i olika tekniska system är det viktigt att det finns sätt att referera till bytespunkten som inblandade system förstår.

Ordet punkt i bytespunkt måste tolkas på ett speciellt sätt då den oftast avser ett område med flera (mer eller mindre närliggande) positioner där avstigning och påstigning kan ske. Oftast är det olika positioner som används för taxi, buss eller tåg.

Bytet sker alltså inte nödvändigtvis i EN punkt utan resenären kan få stiga av vid en punkt på en terminal och kliva ombord vid en annan punkt. Traditionellt kan man skilja på dessa två aspekter av bytespunkt genom att tala om att bytet sker i ett hållplatsområde (STOP AREA) som har flera olika stoppstäl-len/hållplatslägen (STOP POINTs). Ett stoppställe (STOP POINT) kan exempelvis vara en busshållplats eller en taxificka.

I vissa fall omfattar bytespunkten flera närliggande hållplatsområden för olika trafikslag (oftast med samma namn) på samma plats (SITE). Det förekommer också att en bytespunkt utgörs av flera hållplatsområden med olika namn men där deras respektive stoppställen är förbundna med varandra med byteslänkar26 (CONNECTION LINK). I NOPTIS-gränssnitten anges vilka hållplatsområden som är lämpliga att använda för byten med ett speciellt värde för bytesprioritet (Interchange Priority).

Alla inblandade system behöver nu inte känna till den detaljerade uppdelningen i STOP AREA/STOP POINT/SITE/CONNECTION LINK. För att definiera en kopplad resa behöver man i NOPTIS DII-gränssnittet inte beskriva det exakta läget, utan det räcker att ange i vilket hållplatsområde (STOP AREA) som resenären kommer att anlända från den andra trafikturen. Genom att inte behöva beskriva den andra trafikturen alltför detaljerat minskas risken med felmatchningar och en ökad robusthet fås i lösningen.27

12.4.2.4 Stoppställen för lätta fordon (Taxifickor)

När en resenär i en kopplad resa byter fordon vid en terminal innebär det ofta att avstigningspunkten och påstigningspunkten inte ligger i direkt anslutning till varandra. I beskrivningen av hållplatsområdet bör det därför ingå uppgifter om de enskilda stoppställena, inte bara för den linjelagda trafikens bussar och tåg, utan det bör även anges var stoppställe för lätta fordon finns så att resenären kan hitta den väntande taxin.

Taxifickan anges som ett separat stoppställe (STOP POINT) i aktuellt hållplatsområde (STOP AREA), alter-nativt som ett stoppställe (STOP POINT) i ett separat hållplatsområde (STOP AREA) upprättat för trafikslag TAXI. Om olika hållplatsområden används för olika trafikslag vid en terminal bör de två hållplatsområdena knytas samman genom att de ges samma namn och tillförs till samma plats (SITE) och att relevanta stopp-ställen (STOP POINTs) kopplas med byteslänk (CONNECTION LINK).

26 Den vanligaste formen av byteslänk är en gånglänk mellan två hållplatslägen. Dessa hållplatslägen kan vara inom samma hållplatsområde, eller inom två olika hållplatsområden.

27 För resenären är det givetvis fortfarande viktigt att veta vid vilket hållplatsläge som nästa delresa startar, och denna information finns tillgänglig då integratorapplikationen applicerar bytesreglerna och kombinerar information om de båda trafikturerna. Detta görs oavsett om dessa levereras från samma eller från olika planeringssystem.

Titel Sida




12.4.3 Geodata som behövs i den anropsstyrda trafikens system

12.4.3.1 Platser – Bytespunker (STOP POINT)

Den anropsstyrda trafiken behöver få tillgång till information om bytespunkterna till den linjelagda trafiken. Följande uppgifter som beskriver de olika stoppställena/hållplatslägena vid bytespunkterna bör ingå:

• ID-nummer som är unikt inom Sverige för hållplatsläge/stoppställe (STOP POINT).

• Referens till Sverige-unikt ID-nummer för hållplatsområdet (STOP AREA).

• Koordinater enligt SWEREF 99 TM.

• Koordinater enligt WGS-84 latitud och longitud i decimala grader.

• Primärt trafikslag (Buss/Taxi/Tåg/Tunnelbana/Spårvagn/Båt) för hållplatsläget/stoppstället.

• Hållplatsområdets namn (max 50 tecken).

• Kort namn för hållplatsområde (max 16 tecken).

• Lägesbeteckning för hållplatsläget/stoppställe (max 4 tecken).

• Tidpunkt då uppgiften ursprungligen registrerades.

• Tidpunkt för senaste uppdatering.

Sverige-unikt ID för bytespunkt på hållplatsläge/stoppställe-nivå (STOP POINT)

Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att individuell numrering av bytespunkter tillsammans med övriga hållplatsområden och hållplatslägen/stoppställen kan göras på länsnivå. Två alternativa format kan användas för att beskriva bytespunkt på hållplatsläge/stoppställe-nivå:

9 0 2 5 1 2 3 0 1 2 3 4 5 6 7 8 Class Id Prefix för

region/län Globalt nodnummer för hållplatsläge/stoppställe

inom region/län28

eller


region/län Globalt hållplatsområdesnummer

inom region/län Lokalt nummer för

läge inom håll-platsområdet

I exemplen nedan har modellen som baserar sig på globala nodnummer inom region/län använts.

28 Åtta siffror innebär att 100 miljoner unika hållplatsnoder kan finnas inom en region/ett län. Detta bör vara tillräckligt utan att nummer behöver återanvändas i närtid.

Titel Sida




Sverige-unikt ID för bytespunkt på hållplatsområdes-nivå (STOP AREA)

Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell.



inom region/län

12.4.3.2 Platser - POI (Point Of Interest)

Utöver de platser (främst hållplatsområden) som används för att beskriva geografi för den linjelagda trafi-ken så finns det ett behov av att upprätta gemensam information om andra platser som utgör tänkbara start- och ändpunkter för en resa. Det handlar om vårdinrättningar, etablissemang av olika slag, torg och så vi-dare. I dag finns kunskapen och uppgifter om deras namn och olika alias utspridd bland Sveriges trafikföre-tag.

Eftersom informationen är av en relativt statisk natur, så är det inte orimligt att försöka etablera en gemen-sam databas för denna typ av information.

Lösningen behöver hantera att samma plats kan levereras från flera olika källor parallellt, kanske med samma, snarlika eller annorlunda namn. Troligen kommer det att finnas olika uppgifter om exakta koordi-nater för platsen från olika källor.

Samtidigt finns ett behov att skapa en stabilitet där en viss plats får ett unikt ID som inte ändras över tiden.

För att minska mängden manuellt arbete skulle man kunna tillämpa en skiktad lösning där ”rå” information kan tillföras parallellt från olika trafikföretag och utgöra underlag för information i ett separat överordnat skikt.

Poster i det överordnade skiktet kan skapas mer eller mindre automatiskt genom att kopiera och automatbe-arbeta delar av den mottagna informationen och därefter tilldela en unik nyckel till den nya posten i det överordnade skiktet. Samtidigt skapas en kopplingsinformation som kopplar mottagen ”rå” information till posten i det överordnade skiktet.

Om det kommer in uppgifter från trafikföretagen om platser som ligger nära platser som redan existerar i det överordnade skiktet så skapas ingen ny post i det överordnade skiktet utan det skapas enbart ytterligare en koppling mellan mottagen ”rå” information och den befintliga posten i det överordnade skiktet. Eventu-ellt kan informationen i det överordnade skiktet justeras genom att den nyss mottagna informationen vägs in.

Det mesta kan alltså ske automatiskt, men lösningen medger även att manuella justeringar och rättelser kan göras av information i det överordnade skiktet utan att den underliggande informationen från trafikföreta-gen påverkas.

Ansvaret för att vid behov justera informationen på den överordnade nivån skulle kunna vara etablerad på nationell nivå eller fördelad på regional nivå.

Exempel på tänkbar lösning:

Information från trafikföretagen

Trafikföretagen levererar information för alla sina platser. För varje plats anges:

Titel Sida




• Unik identitet för trafikföretaget eller avdelning inom trafikföretaget.

• Platsens ID-nummer inom trafikföretaget eller avdelning inom trafikföretaget (frivilligt).

• Koordinater enligt WGS-84 latitud och longitud i decimala grader eller enligt SWEREF 99 TM.

• Klassning av precision för koordinater (Okänt, inom 20 meter, inom 100 meter, inom en kilometer).

• Typ av plats (Okänt, Hållplats, entré till vårdinrättning, osv.) (frivilligt)29.

• Namn

• Kort namn (frivilligt)

• Alias namn 1 (frivilligt)



• Beskrivning (frivilligt)

• Uppgiften levererad av

o Företag

o Person (frivilligt)

o Kontaktuppgift (frivilligt)

• Tidpunkt då uppgiften registrerades

I samband med leveransen anges om leveransen ersätter alla tidigare levererade uppgifter från trafikföreta-get.

Dessa informationer kommer att lagras i det mottagande systemet som poster i tabellen ExternalPOI.

Förädling av den mottagna informationen

Det mottagande systemet ansvarar för att skapa och underhålla ett register baserat på mottagna uppgifter. Detta skulle kunna göras åtminstone delvis automatiserat. Ett exempel på hur det skulle kunna göras besk-rivs nedan:

För varje mottagen platsuppgift lagras den ”råa” informationen i oförändrat skick som en post i tabellen ExternalPOI. Den enda bearbetning som görs är att koordinatinformationen sparas i både SWEREF99TM och i WGS84 format.

Utifrån angiven position undersöks sedan om det redan finns någon gemensam POI i tabellen PublicPOI som den nya posten kan kopplas till. Om det inte redan finns någon PublicPOI som ligger tillräcklig nära geografiskt så skapas automatiskt en ny post i tabellen PublicPOI genom att kopiera valda uppgifter från ExternalPOI och tilldela ett officiellt Sverige-unikt ID. Om det redan finns en PublicPOI som matchar geo-grafiskt och vi därmed har flera parallella uppgifter från olika trafikföretag om samma plats så kan uppgif-terna i PublicPOI uppdateras genom att koordinater från de olika trafikföretagen vägs samman, eller så väljs automatiskt den med högst angiven precision eller liknande. I ett senare skede kan eventuellt en operatör

29 Antingen som fritext eller så behöver det tas fram en gemensam lista med tillåtna typer.

Titel Sida




från den organisation som har ansvar för det överordnade skiktet gå in och manuellt justera och låsa fast ett ”officiellt” namn och koordinaterna.

Förutom att mottagen ExternalPOI lagras och en PublicPOI skapas eller uppdateras så skapas också auto-matiskt en post i en tredje tabell POIRelation, som utgör kopplingstabell som håller samman ExternalPOI med PublicPOI.

Med denna tredelade modell kan olika trafikföretag oberoende av varandra tillföra flera registreringar för en och samma POI och man kan centralt hantera att det finns flera uppgifter för samma plats. Arbetet kan till stora delar automatiseras, men det är möjligt att göra manuella justeringar vid behov.

Modellen tillåter att man som läsare av informationen kan utgå från uppgifter kopplade till de officiella plat-serna, men man har även möjlighet att se vilka underliggande uppgifter som är kopplade till platsen. Där-med blir alternativa namn (alias) och koordinater för en plats tillgängliga.

Koordinerad information tillgänglig för trafikföretagen

I tabellen PublicPOI bör följande uppgifter ingå:

• ID-nummer som är unikt inom Sverige

• Koordinater enligt SWEREF 99 TM.30

• Koordinater enligt WGS-84 latitud och longitud i decimala grader.31

• Klassning av precision för koordinater (Okänt, inom 20 meter, inom 100 meter, inom en kilometer)

• Typ av plats (Okänt, Hållplats32, entré till vårdinrättning, övrigt)33

• Namn (max 50 tecken)

• Kort namn (max 16 tecken)

• Beskrivning

• Länskod 34

• Kommunkod35

• Tidpunkt då uppgiften ursprungligen registrerades

30Fastställs i det centrala systemet genom omräkning från WGS84 vid behov.

31 Fastställs i det centrala systemet genom omräkning från SWEREF 99 TM vid behov.

32 Normalt sätt ska hållplatser inte anges som POI, utan i första hand ska de officiella bytespunkterna som anges i form av STOP POINT användas.

33 Antingen som fritext eller så behöver det tas fram en gemensam lista med tillåtna typer. Om uppgift sak-nas sätts typen till Okänd.

34 Länskod enligt SCBs numrering. Det borde vara möjligt att i ett centralt system automatiskt räkna ut i vil-ket län en plats ligger utifrån koordinaterna.

35 Kommunkod enligt SCBs numrering. Det borde vara möjligt att i ett centralt system automatiskt räkna ut i vilket kommun en plats ligger utifrån koordinaterna.

Titel Sida




• Tidpunkt för senaste uppdatering

• Koordinater och namn granskade och låsta (Ja/Nej)

• Avslutad (Ja/Nej)

I tabellen POIRelation bör följande uppgifter ingå:

• Löpnummer

• Referens till ID-nummer i PublicPOI

• Referens till ID-nummer för trafikföretaget från ExternalPOI

• Platsens ID-nummer enligt trafikföretagets system från ExternalPOI

• Granskad (Ja/Nej)


I tabellen ExternalPOI exponeras de ”råa” uppgifterna från trafikföretaget. Enda bearbetningen är att koor-dinater har expanderats så att de är tillgängliga både som SWEREF99TM och som WGS84:

• Unik identitet för trafikföretaget eller avdelning inom trafikföretaget.

• Platsens ID-nummer (alternativt ett löpnummer) inom trafikföretaget eller avdelningen.



• Klassning av precision för koordinater (Okänt, inom 20 meter, inom 100 meter, inom en kilometer).

• Typ av plats (Okänt, Hållplats, entré till vårdinrättning, övrigt).

• Namn

• Kort namn (frivilligt)




• Beskrivning (frivilligt)

• Uppgiften levererad av

o Företag

o Person (frivilligt)

o Kontaktuppgift (frivilligt)



Titel Sida





Sverige-unikt ID för POI

Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att individuell numrering av POI kan göras på länsnivå. Adressrymden är så stor att 100 miljoner POI kan anges för varje län.


region/län Point of Interest Number

12.4.3.3 Platser – Adresser

Förslaget är att utgå från information från LMV Adressplats light (90B).

Sverige-unikt ID för adress

Den Sverige-unika identiteten väljs utifrån en kombination av Riksnyckelprefix och RiksnyckelID enligt Lantmäteriets numrering och kan lämpligen anges på ett format som är kompatibelt med GID (global identi-fier) enligt NOPTIS modell.

9 6 1 2 3 4 1 2 3 4 5 6 7 8 9 10 Class Id RIKSNYCKELPREFIX,

ADRESSPLATS RIKSNYCKELID, ADRESSPLATS

Adress-information

För adresser bör följande uppgifter ingå:

• ID-nummer som är unikt inom Sverige (Förslagsvis en kombination av Riksnyckelprefix och Riks-nyckelID, se ovan).



• Koordinatläge (PUNKTTYP)

o B = Byggnadens centralpunkt

o E = Entré

o I = Infart

o U = Ungefärligt

• Namn på gata, väg, by eller klartext (ADROMRADE)

• Namntyp (ADRTYP)

o 1 = Gatu- eller vägnamn, nummerbaserade adresser

o 2 = Gatu- eller vägnamn, avståndsbaserade adresser

o 3 = Bynamn, namn eller nummerbaserade adresser

Titel Sida




• Adressnummer exempelvis gatunummer eller liknande (ADRPLATS)

• Adressnummertyp (ADRPLTYP)

o 01 = Nummer och ev. littera (ex: 1, 24D)

o 02 = Nummeradress med lägestillägg (ex: 1A ÖG)

o 03 = Namn eller blank (gäller byadress, ex: Brygghuset)

o 04 = Avståndsangivelse, metertalsadress (ex: 134-27)

o 09 = Odefinierad adressplatsbeteckning, används vid viss typ av omregistrering

• Gårdsnamn (GARDSNAMN)

• Populärnamn (POPNAMN)

• Kommundel skiljenamn (KOMDELLAGE)

• Kommundel läge (SKILJENAMN)

• POSTNUMMER

• POSTORT

• Länskod (LANKOD)

• Kommunkod (KOMKOD)

• Fastighetsnyckel (FNR)




12.4.4 Gränssnitt för att leverera turplaner för den linjelagda kollektivtrafiken


Sverige-unikt ID för hållplatsläge/stoppställe (STOP POINT)

Titel Sida




Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att individuell numrering av bytespunkter tillsammans med övriga hållplatsområden och hållplatsläges/stoppställen kan göras på länsnivå. Det finns två alternativa nycklar i NOPTIS för att ange ett hållplatsläge/stoppställe. Dels en hierarkiskt uppbyggd nyckel, och dels en globalt numrerad nyckel. Den globalt numrerade nyckeln kopplas till det nodnummer som hållplatsläget/stoppstället tilldelats. Detta nod-nummer är oberoende av hållplatsområdets numrering och är därför mer generell. Av den anledningen är förslaget att i första hand utgå från den globalt numrerade nyckeln:


region/län Globalt nodnummer för hållplatsläge/stoppställe

inom region/län

Som ett alternativ kan den hierarkiskt uppbyggd nyckeln användas:



inom region/län Lokalt nummer för

läge inom håll-platsområdet

Sverige-unikt ID för hållplatsområden (STOP AREA)

Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell.



inom region/län

Sverige-unikt ID för linjenummer (LINE)

Den Sverige-unika identiteten för linje36 kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att oberoende numrering av linjer kan göras inom respektive region eller län. Genom att utnyttja andra prefix än de som används av regioner/län kan unika linje-identiteter skapas även för kommersiell trafik. Samordning måste ske på nationell nivå för tilldelning av prefix och nummerserier för linjenummer inom de prefix som inte administreras av region/län.

9 0 1 1 1 2 3 1 2 3 4 0 0 0 0 0 Class Id Prefix Globalt tekniskt linje-

nummer inom prefix (region/län/övrigt)

36 Linje: En grupp av körvägar för kollektivtrafik som är kända för allmänheten under ett gemensamt num-mer eller namn. Ett exempel på en linje är busslinje 5 i Helsingstad.

Titel Sida




Sverige-unikt ID för linje-riktning (DIRECTION)

Den Sverige-unika identiteten för linje-riktning kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Huvudriktningen för linje anges som antingen 1 eller 2. För övrigt följs samma struktur som för linje.



Riktning

Sverige-unikt ID för trafikturer (SERVICE JOURNEY)

En Sverige-unik identitet för trafikturen kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Samma numrering tillämpas som för linje, men med det tillägget att trafiktursnummer också anges.



Trafikturs-nummer inom linjen.

Turplan för linjelagd kollektivtrafik

Nedan visas ett (korrekt, men förenklat) exempel på hur en leverans på detta format kan se ut.


<TimetableVersion ModificationType="DEFINE" DocumentLayoutVersion="3.0.12" xsi:schemaLocation="http://www.pubtrans.com/DII/3.0 DII.xsd"

xmlns:PT="http://www.pubtrans.com/DII/3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">



<VersionFrameRef Name="X">


<OrganisationRef><ContractorRef><Number Number="12"/> </ContractorRef> </OrganisationRef>


</VersionFrameRef>

<ValidDatePeriod EarliestValidFromDate="2013-01-23" LatestInvalidFromDate="2014-01-23"/>

<ServiceCalendarRef Code="1"/>

<VehicleJourneys>

<ServiceJourney Number="15">

<DayTypes><DayType Code="1"/></DayTypes>

<LineRef><Gid Gid="9011001002200000"/></LineRef>

<Calls>

<Call SequenceNumber="1">

<JourneyPatternPointRef><Gid Gid="9025001000005237"/></JourneyPatternPointRef>

<Departure EarliestTime="08:00:00"/>

</Call>




</Call>

Titel Sida






<Arrival LatestTime="08:30:00"/>

</Call>

</Calls>

</ServiceJourney>

</VehicleJourneys>

</TimetableVersion>

12.4.5 Gränssnitt för att leverera turplaner för den anropsstyrda kollektivtrafiken


Observera att arbetsuppgiften att skapa turplaner för den anropsstyrda trafiken inte behöver ske i samma system som hanterar den anropsstyrda trafiken. Det är inte heller säkert att alla system involverade i den anropsstyrda trafiken behöver ha detaljerad kunskap om dessa turplaner, utan det kan i vissa fall räcka att hantera konsekvenserna vad gäller resursallokering som dessa resulterar i.

Troligen kan samma system som används för att planera den linjelagda trafiken användas även för att skapa turplaner för den anropsstyrda trafik som ska exponeras i reseplanerare och andra system för den linjelagda trafiken. Med nuvarande version av NOPTIS DII så är det möjligt att utan förändringar:

3) Beskriva sådana anropsstyrda turer som körs med fast linjesträckning och enligt fastlagda tider, men som måste förbeställas.

4) Beskriva anropsstyrd områdestrafik och anropsstyrd trafik med mötesplatser på en överordnad nivå. Det förutsätter då att man använder konceptet där en virtuell hållplats används för att repre-sentera ett område.

Däremot så skulle det krävas en mindre ändring i gränssnittet (och kanske även i dagens planeringssy-stem37) om man utöver ovanstående önskar kunna beskriva linjelagd trafik med anropsstyrd avvikelse.

Om ambitionen är att erbjuda anropsstyrd områdestrafik i ett tidsintervall, så kan det vara lämpligt att lägga upp ett antal trafikturer mellan det anropsstyrda området och vald bytespunkt som matchar valda linjelagda trafikturer i stomtrafiken i önskad tidsperiod.

Om det senare i realtid visar sig att utbudet är för stort för tillgängliga resurser så kan ett antal av trafiktu-rerna dras tillbaka med trafikledaråtgärden JourneyCancellation enligt NOPTIS RII.

37 Beslutar man att använda anropsstyrd avvikelse behöver leverantörerna av aktuella planeringssystem involveras i arbetet med att göra de anpassningar som krävs.

Titel Sida




Turplan för anropsstyrd kollektivtrafik

Nedan visas ett exempel på hur en leverans av en trafiktur för anropsstyrd områdestrafik på NOPTIS format kan se ut. Självklart är det möjligt även med andra varianter där flera anropsstyrda områden ingår i samma trafiktur, eller där en mix av anropsstyrda områden och vanliga hållplatser ingår.


<TimetableVersion ModificationType="DEFINE" DocumentLayoutVersion="3.0.13" xmlns:PT="http://www.pubtrans.com/DII/3.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.pubtrans.com/DII/3.0

file:///Q:/PT/INTERFACES/DII/M/InternalUse/DII.xsd">



<VersionFrameRef Name="X2">


<OrganisationRef><ContractorRef><Number Number="152"/></ContractorRef></OrganisationRef>


</VersionFrameRef>

<ValidDatePeriod EarliestValidFromDate="2013-01-23" LatestInvalidFromDate="2014-01-23"/>

<ServiceCalendarRef Code="1"/>

<VehicleJourneys>

<ServiceJourney Number="8">

<DayTypes><DayType Code="1"/></DayTypes>

<LineRef><Gid Gid="9011001722500000"/></LineRef>

<AdvanceOrderCondition IsPublic="Y" LatestAbsoluteTime="15:00:00"/>

<Calls>




<ChangeFromRules><ChangeFromRule MaximumWaitTimeDuration="PT60M">

<FeederJourneyFilter>

<JourneyOnDirectionOfLineDef MaxOffsetDuration="PT10M">

<DirectionOfLineRef><Gid Gid="9014001002200000"/></DirectionOfLineRef>

</FeederJourneyFilter>

<FeederStopRef><StopAreaRef><Number Number="2237"/></StopAreaRef></FeederStopRef>

</ChangeFromRule></ChangeFromRules>

</Call>



<Arrival LatestTime="16:30:00"/>

</Call>

</Calls>

</ServiceJourney>

</VehicleJourneys>

</TimetableVersion>

Titel Sida




12.4.6 Gränssnitt för att leverera bokningsförfrågan

Figur 22 Överföring av reseförslag till bokningsfunktion

Figur 23 Detaljerna om reseförslagets alla delresor överförs

När en reseplanerare hittar ett resvägsförslag som innehåller en delresa som måste förbokas, så vore det lämpligt att kunna göra en smidig överlämning av hela reseförslaget till en bokningsapplikation.

För att möjliggöra fristående bokningsapplikationer behövs ett gränssnitt för att överföra information om bokningsförfrågan. Samtliga delresor som ingår i reseförslaget bör överföras tillsammans som en enhet. Varje ingående delresa beskrivs med ett antal detaljer. Exempelvis:

• Trafikturen

o Identitet: 9015001722500015

o Datum: 2013-03-31

Titel Sida




o Beskrivning: Linje 7225 till Liljeholmen

• Påstigningspunkten

o Identitet: 9025001000072138

o WGS 84 Latitud: 59.32045

o WGS 84 Longitud: 18.09641

o Namn: Område Gröndal

o Tidigast avgångstid: 2013-03-31T07:45:00+01:00

• Avstigningspunkten

o Identitet: 9025001000002237



o Namn: Liljeholmen

o Senast ankomsttid: 2013-03-31T08:10:00+01:00

• Trafikföretag som utför trafikturen

o Namn: TaxiGröndal

o Kontaktuppgifter: 076543210123

Eventuellt skulle överlämningen till bokningsfunktion kunna göras genom att klicka på en hyperlänk varvid en bokningsapplikationens webbsida öppnas. I hyperlänken skulle information om delresorna kunna info-gas.

Med dagens webbläsare bör en URL inte innehålla mer än 2000 tecken varför det finns en begränsning på hur många delresor som kan överföras med denna metod. Troligen ligger maxgränsen kring fem delresor. Om detta inte räcker kan andra mer avancerade webbtekniker användas för överlämningen.

Titel Sida




12.4.7 Gränssnitt för att utväxla information om reservation och bokning

12.4.7.1 Reservation och bokning

Figur 24 Steg 1: Reservation av en delresa

I ett första steg skickas en reservationsförfrågan från bokande systemet till relevant utförar- eller beställar-system.

Information för den delresa som önskas reserveras överförs.

Om inte den önskade delresan är den sista delresan så överförs också information om vilken nästa delresa är samt information om påstigningspunkt och avgångstid för den delresan.

På motsvarande sätt så skickas information om föregående delresas avstigningspunkt och ankomsttid i det fall den aktuella delresan inte är den första delresan.

Exempel på reservation:

Avsändare: System 1

Mottagare: System 2

Meddelandetyp: Reservationsförfrågan

Reservations-ID: Sys-1/1

Delresa att reservera:

• Trafikturen

o Identitet: 9015001722500015

Titel Sida




o Datum: 2013-03-31


o Identitet: 9025001000072138



o Namn: Område Gröndal


• Avstigningspunkten

o Identitet: 9025001000002237



o Namn: Liljeholmen

o Senast ankomsttid: 2013-03-31T08:10:00+01:00

Byte till delresa 2

• Trafikturen

o Identitet: 9015001002201070

o Datum: 2013-03-31

o Beskrivning: Tåg 1070 till Sickla

o Trafikföretag som utför trafikturen: Tågbolaget

o Kontaktuppgifter: 07011210120


o Identitet: 902500100002239



o Namn: Liljeholmen


Titel Sida




Figur 25 Steg 2 Reservationen accepteras

Om det mottagande systemet kan acceptera delresan returneras en bekräftelse till det frågande systemet.

Exempel på bekräftelse:


Mottagare: System 1

Meddelandetyp: Svar på reservationsförfrågan


ReservationsStatus: Accepterad

Pris: 70 kr

Figur 26 Steg 2b Ev. ytterligare reservationer görs

Eventuellt finns det fler delresor att beställa. Motsvarande dialog som ovan genomförs.

Titel Sida




Figur 27 Köpet kan nu slutföras

När samtliga reservationer har accepterats så kan köpet genomföras och resenären debiteras på lämpligt sätt från bokningsapplikationen. I dialog med resenären fastställs ett unikt sätt att identifiera resenären, exem-pelvis genom att resenären kan visa upp ett kreditkort eller någon annan handling med unikt ID under re-san.

För vissa typer av resenärer och resor kan det tänkas att resenärer inte debiteras direkt utan att det istället är en organisation som debiteras. Det är inte heller säkert resenärer med särskilda behov ska behöva visa upp någon speciell handling för att få genomföra resan. I dessa fall kan det kanske räcka att upphämtningspunk-ten är känd och att resenären ledsagas i eventuella byten så att en obruten kedja erhålls.

Titel Sida




Figur 28 Bokningen slutförs

När resenären betalt för resan skickas de slutliga bokningarna och som svar mottas bokningsbekräftelser.

Systemet som ska utföra delresan kan i sin bekräftelse returnera extra information som bokningsapplikation ska tillföra till färdhandlingen.

Denna extra information kan vara krypterad och innehålla uppgift om resenärs-ID, tidsspann, trafiktur, zo-ner, delsträckor eller dylikt så att egen personal kan verifiera att resenären har en giltig färdhandling.

Extrainformationen behöver inte standardiseras utan det är upp till respektive system att besluta vad som ska ingå i dess boknings-info. Däremot är det möjligt att mängden extrainformation som tillåts behöver be-gränsas till en maxstorlek.

Exempel på bokning:


Mottagare: System 3

Meddelandetyp: Bokningsförfrågan


Resenärs-ID: Mastercard_123456123423

Exempel på bokningsbekräftelse:


Mottagare: System 1

Meddelandetyp: Svar på bokningsförfrågan

Titel Sida





BokningsStatus: Accepterad

Boknings-ID: Sys-3/1

Boknings-INFO: X132233290823898FFG12345

När bokningen är genomförd kan bokningsapplikationen producera en färdhandling. Flera tänkbara format är tänkbara, till en början kanske det består av texter i ett SMS eller en pdf-fil med textbeskrivningar samt en eller flera QR-koder.38

12.4.7.2 Clearing

Efter att debitering av resenären har gjorts och bokning(arna) bekräftats kan bokningsapplikationen skapa underlag för ersättning till utförare.

En annan möjlighet är att använda generella betalförmedlingstjänster där ingen särskild clearingfunktion krävs. Betalningen sker då istället direkt till de ”biljettutställare” som ingår i resekedjan enligt de boknings-reservationer och bekräftelser som utbytes mellan ”bokningsfunktion” och ”transportörer/biljettutställare”.

12.4.7.3 Undantagshantering: avbrutet köp

Figur 29 Avbrutet köp

Om resenären inte genomför köpet så upphör reservationen att gälla efter en viss tid. Om möjligt bör bok-ningssystemet dessutom aktivt dra tillbaks reservationen.

38 Detta kan utvecklas vidare med nedladdning av elektroniskt färdbevis på något ”smart media”, kanske i en telefon, för att kunna viseras i kollektivtrafikens kortläsare i linje med tankarna i EU-IFM (http://www.ifm-project.eu/) med multiapplikationer på smarta media. För mer detaljer se X2AB’s arbete med framtida biljett- och betallösningar.

Titel Sida




12.4.7.4 Undantagshantering: ångrat köp

Figur 30 Ångrat köp

Om resenären ångrar sitt köp krävs en aktiv dialog med avbokning och bekräftelse på avbokning för att säkerställa att bomkörningar undviks.

Exempel på avbokning:


Mottagare: System 3

Meddelandetyp: Avbokningsförfrågan


Exempel på avbokningsbekräftelse:


Mottagare: System 1

Meddelandetyp: Svar på avbokningsförfrågan


AvbokningsStatus: Accepterad

12.4.8 Gränssnitt för dialog mellan beställar- och utförarsystem i den anropsstyrda trafiken – Re-sursallokering, order och dirigeringen av fordon

Förslaget är att fortsatt använda befintliga SUTI meddelanden.

12.4.9 Gränssnitt för att utbyta information om kortsiktiga ändringar och realtidshändelser

Förslaget är att utgå från befintliga NOPTIS meddelanden.

I NOPTIS finns det två parallella meddelandeformat för att överföra kortsiktiga ändringar och realtidshän-delser. Dels ett format som medger att varje ändring eller realtidshändelse kan rapporteras separat, och dels ett format för att förmedla en sammanställd bild av alla gjorda ändringar och realtidshändelser för hela eller delar av trafiken. Genom denna uppdelning möjliggörs att information från många källor kan integreras i ett

Titel Sida




separat system och att sedan olika användande system från detta system kan hämta en konsekvent och komplett bild för den samlade trafiken.

12.4.9.1 Gränssnitt för att meddela kortsiktiga ändringar av utbudet

NOPTIS RII är ett gränssnitt för att överföra information om kortsiktiga förändringar i trafiken. Detta gräns-snitt används redan i dag för att från olika tekniska system i den linjelagda trafiken meddela in ändringar i förhållande till turplanerna. Det kan röra sig om helt eller delvis inställda trafikturer, extra trafikturer, änd-rade ankomstspår för tåg och liknande.

Trafiktur inställd

Trafikturer kan behöva ställas av olika skäl. Exempelvis kan anropsstyrda trafikturer behöva ställas in på grund av resursbrist. Det är en fördel om detta rapporteras in så tidigt som möjligt så att exempelvis rese-planeraren ger en rättvisande bild av resemöjligheterna.

På sikt kan man kanske automatisera processen att skicka in sådana meddelanden direkt från beställarsy-stem för anropsstyrd trafik i samband med resursbrist, annars finns redan i dag möjlighet att manuellt rap-portera in förändringar i trafiken med befintliga applikationer som används av den linjelagda trafiken. Dessa applikationer borde även kunna användas av personal som arbetar med anropsstyrd trafik.

Både manuella och automatiska system kan alltså meddela att en trafiktur är inställd. Ett exempel på hur ett sådant meddelande ser ut i NOPTIS RII visas nedan:

...

<DeviationCaseAddRequest MessageId="6956">

<DeviationReason StandardCategory="VEHICLESHORTAGE"/>

<ControlAction>

<JourneyCancellation>

<DatedVehicleJourneyRef OperatingDayDate="2013-03-27" Gid="9015001722500050"/>

</JourneyCancellation>

</ControlAction>

</DeviationCaseAddRequest>

...

Andra kortsiktiga ändringar

Andra meddelandetyper som kan vara relevanta vid kopplade resor och som kan rapporteras enligt NOPTIS RII:

• Ändrad tid för ankomst eller avgång - ChangeOfJourneyTiming

• Anropsstyrd kollektivtrafiktur kommer att köras - JourneyOrdering

• Ändrad bytespunkt för en kopplad resa - ConnectionModification

• …

12.4.9.2 Gränssnitt för att meddela realtidshändelser

NOPTIS VSI är ett gränssnitt för att överföra information om realtidshändelser och prognoser. Detta gräns-snitt används redan i dag för att från olika tekniska system i den linjelagda trafiken meddela när buss, tåg och andra trafikslag i den linjelagda trafiken ankommer och avgår från hållplatser i realtid.

Titel Sida




Figur 31 Exempel på en avgångsrapport enligt NOPTIS VSI

12.4.9.3 Gränssnitt för att ge tillgång till en samlad realtidsinformation

NOPTIS ROI är ett gränssnitt för att i realtid överföra information om trafikturer med applicerade ändringar, realtidshändelser samt prognoser och konsekvenser av samtrafik med andra trafikturer.

Detta gränssnitt används i dag för att ge exempelvis reseplanerare tillgång till en samlad realtidsbild av den linjelagda trafiken i en region, men skulle för aktuella syften också kunna användas för att direkt eller indi-rekt ge system i den anropsstyrda trafiken tillgång till realtidsinformation om andra trafikturer i kopplade resor.39

En bokningsapplikation eller en separat bevakningsapplikation skulle genom detta gränssnitt kunna bevaka trafikturer som ingår i bokade resor. Om störningar upptäcks på någon ingående trafiktur i en bokad resa så kan i så fall meddelande skickas till resenärer och berörda beställar- eller utförarsystem.

39 Som ett alternativ eller parallellt med NOPTIS ROI skulle SIRI gränssnitt kunna användas för att ge rese-planerare och andra system tillgång till realtidsinformation om trafiken.

slutrapport slutrapport ---- teknikplattform för den samlade … · 2019-09-24 · e 2013-05-21...

Documents