Slutrapport Slutrapport - Teknikplattform för den samlade

Transcription

Slutrapport - Teknikplattform för den samlade kollekkollektivtrafiken
Dokumentidentitet:
Dokumentidentitet:
TRTR-SIS_TEKNIK_SLUTRAPPORT
Revision:
F
Date:
20132013-0505-30
Titel
Sida
Slutrapport - Teknikplattform för den samlade kollektivtrafiken
Författare
2(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
TR-SIS_TEKNIK_SLUTRAPPORT
2013-05-30
Revision
F
Slutrapport - Teknikplattform för den samlade kollekkollektivtrafiken
Revisionshistorik
Revisionshistorik
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 utifrån remissvar
Ulf Bjersing
E
2013-05-21
Slutrapport med justeringar efter telefonmöte 201305-21
Ulf Bjersing
F
2013-05-30
Slutrapport efter språkgranskning
Ulf Bjersing
Titel
Sida
Författare
3(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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
Författare
4(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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
Författare
5(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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örfattare
6(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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 existerande 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 normgivande 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 linjelagd 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
F
Titel
Sida
Författare
7(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 delresor ska uppleva resan som en sammanhängande helhet. I en kopplad resa sker byten vid väl valda bytespunkter med relevant stöd och information så att resan även fungerar då störningar uppstår i någon av delresorna. 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 tillgång till aktuell och väl integrerad information om planerat utbud, ändringar i förhållande till detta, störningar 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 anropsstyrda 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 gemensam 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 exempelvis 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 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 användas som en grund för en lösning i större skala. Vår förhoppning är att en fortsatt 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
Författare
8(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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örekommer 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 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 helhetsinformation till andra system.
Särskild anropsstyrd trafik
Anropsstyrd trafik som endast personer med tillstå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änssnittsspecifikationer, strukturer och eventuellt komponenter. Med detta som bas kan sedan samspelta
applikationer och processer skapas.
Trafikföretag
Här avser vi trafikföretag på den svenska marknaden. I denna mening är även en regional kollektivtrafikmyndighet 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 kollektivtrafik, eller ett offentligt organ som tillhandahåller
kollektivtrafiktjänster”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
1
F
Titel
Sida
Författare
9(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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änsyn 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
Författare
10(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 kollektivtrafik.
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 linjelagd stomtrafik kan rätas ut, vilket ger kortare restider. Rätt applicerat borde därmed en bättre kollektivtrafik 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 stomtrafik 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.
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.
2
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
Författare
11(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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
F
Titel
Sida
Författare
12(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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änssnitt som krävs för att etablera en sådan plattform. Tanken är alltså inte att beskriva en enskild teknisk produkt 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 trafikdatabaserna på samma sätt som den upphandlade linjelagda kollektivtrafiken. Därmed kan den anropsstyrda kollektivtrafiken och den linjelagda kollektivtrafiken presenteras som en samlad bild i reseplanerare och övriga medier. Regler och löften till resenären om bytet ska ingå som en del i den importerade informationen.
•
Tillför möjlighet i reseplanerare att överlämna ett resförslag för hela resan till en bokningsapplikation 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 presentera 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 helhetslösning.
3.4.3 Geografi
•
Agera för att etablera en gemensam geodataportal som omfattar information om adresser och platser 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 liknande 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 bokningstillfället eller när resan startar.
Titel
Sida
Författare
13(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
•
Revision
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örhindrar 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.
F
Titel
Sida
Författare
14(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
4 Bakgrund
Den anropsstyrda trafiken och den linjelagda busstrafiken använder i dag olika teknikstandarder och gränssnitt.
Systemen har över tid utvecklats och är väl lämpade för sina specifika uppgifter men de kan inte kommunicera 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ässiga 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 (Standardiserat 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
Författare
15(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
4.1 Fördubbling
Fokus för detta projekt ur ett fördubblingsperspektiv handlar inte om att fördubbla den särskilda kollektivtrafiken, det vill säga färdtjänst, sjukresor eller skolskjuts, utan primärt om att skapa förutsättningar för tillvä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 allmä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ördubblingsmålet samtidigt som det kan ge kostnadsbesparingar.
F
Titel
Sida
Författare
16(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 bytespunkten 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 anropsstyrd 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 allmä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 beskriva 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ångstider 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ällningssystemet för anropsstyrd trafik.
3
Slutredovisning av FINAL-projektet. Fullständig integrering av anropsstyrd kollektivtrafik och linjetrafik.
Västtrafik 2005
Titel
Sida
Författare
17(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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änglighetsaspekten.
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 allmä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. Vanligtvis 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 tomkö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 nuvarande system så beskriver vi hur man kan bygga en helhetslösning utifrån ett antal funktionsblock som utvä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.
Vidare utredning av denna fråga faller utanför detta projekts ramar, men det vore fullt möjligt att i gränssnitten tillföra de meddelanden som krävs för att överföra platsbokningsinformationen mellan de tekniska
systemen.
4
Titel
Sida
Författare
18(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 tekniskt 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
Författare
19(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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öjliggö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 etablerat 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 koordinater 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
Författare
20(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 turplaner 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.
Om vi exempelvis studerar SL, så finns det i dag en process etablerad där alla entreprenörer för buss, tunnelbana, pendeltåg och övriga spårbundna trafikslag kontinuerligt exporterar sina turplaner till en integrator-applikation enligt NOPTIS-gränssnitt. Till integratorn skickas även Waxholmstrafikens turplaner enligt
NOPTIS-gränssnitt.
6
Titel
Sida
Författare
21(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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. Turplanerna 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 linjelagda 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 (integrator-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-
NOPTIS-gränssnittet stödjer redan i dag information om förbeställningstider och kontaktuppgifter för bokning 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, barnvagnsplatser, låggolv/låg entré.
7
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
Författare
22(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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
Vid exempelvis SL levererar fordonssystem för bland annat buss, pendeltåg och tvärbana realtidsinformation enligt NOPTIS gränssnitt till integratorn. Ett flertal system levererar parallellt trafikledaråtgärder och
störningsinformation för de olika trafikslagen till integratorn.
8
Om 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.
9
Titel
Sida
Författare
23(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 kartapplikation eller genom att mata in sin adress. Både kartan och adressen kan användas för att fram en koordinat som anger resenärens önskade startpunkt.
Reseplaneraren kan sedan identifiera om koordinaten ligger nära en hållplats eller om den ligger inom gränserna 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ållplats varefter sökningen kan göras som om det handlat om en traditionell punkt till punkt sökning. Tidpunkten 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.
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 relevanta faktorer.
10
Titel
Sida
Författare
24(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 bokningsapplikation.
Titel
Sida
Författare
25(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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ällarsystem. 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 tidsangivelse 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ändarens 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ösningar 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ärdhandling 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
Författare
26(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 återkommande 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
Författare
27(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 ankomst 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 byteshantering, 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 bokningsapplikationen 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 problem. 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-
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.
11
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.
12
Titel
Sida
Författare
28(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
lämnande fordon och att faktiska tidpunkter för ankomster13 och avgångar14 registreras. Dessa typer av uppgifter hanteras redan i dag i NOPTIS-gränssnitten för den linjelagda trafiken. En förutsättning för en fungerande 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 systemet.15
13
Hämtat kund.
14
Lämnat kund.
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.
15
Titel
Sida
Författare
29(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 trafiken 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 information inte kostnadsfri utan har ett så högt pris att vissa trafikföretag som skulle kunna ha nytta av informationen 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 adressinformation.Därigenom kan antalet felkörningar med de kostnader dessa medför ekonomiskt, miljömässigt och tidsmä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 (FRADR) till en kostnad av ca 110 000 kr per år för samtliga kommuner inom Västra Götaland samt Kungsbacka, 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å kostnadsbilden.
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 kompletterat 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 samkö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
Författare
30(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 information 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 dagslä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 Geodatasamverkan och andra berörda organisationer tagit fram ett dokument som beskriver en nationell geodatastrategi. 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 anvä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 licenshantering 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 motsvara 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 kostnadsskä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
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.
16
Titel
Sida
Författare
31(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 finansieringsmodeller 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 beskriva 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 innehå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
Författare
32(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 informationssystem 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 kommande 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 konsekvent och entydigt utifrån ett samsynt nordiskt perspektiv. Såväl SIRI som NeTEx innehåller delvis redundanta 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 datamodell 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 resursallokering, orderhantering och trafikledning med inriktning mot dialogen mellan beställarsystem och utförare/utförarsystem inom anropsstyrd trafik.
Titel
Sida
Författare
33(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 detaljer 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
Författare
34(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 anropsstyrda systemen.
Figur 18 Anropsstyrda områden är inte samma sak som de detaljerade zoner som används inom den anropsstyrda 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 taxificka.
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.
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.
18
Titel
Sida
Författare
35(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 trafiken så finns det ett behov av att upprätta gemensam information om andra platser som utgör tänkbara startoch ändpunkter för en resa. Det handlar om vårdinrättningar, etablissemang av olika slag, torg och så vidare. I dag finns kunskapen och uppgifter om deras namn och olika alias utspridd bland Sveriges trafikföretag.
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
Författare
36(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
Däremot så skulle det krävas en mindre ändring i gränssnittet (och kanske även i dagens planeringssystem19) 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 trafikturerna 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ällarsystem. Om det mottagande systemet kan acceptera delresan returneras en bekräftelse till det frågande systemet.
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 resenä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ämtningspunkten ä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.
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.
19
Titel
Sida
Författare
37(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 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ändelser. 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änssnitt 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, ändrade 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öjligheterna. På sikt kan man kanske automatisera processen att skicka in sådana meddelanden direkt från beställarsystem för anropsstyrd trafik i samband med resursbrist, annars finns redan i dag möjlighet att manuellt rapportera 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.
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änssnitt 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
Författare
38(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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.
Som ett alternativ eller parallellt med NOPTIS ROI skulle SIRI gränssnitt kunna användas för att ge reseplanerare och andra system tillgång till realtidsinformation om trafiken.
20
Titel
Sida
Författare
39(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 trafikfö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 rekommendation 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örvaltningsorganisationen 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 region/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 exempelvis X2ABs regi skapas. Detta skulle också kunna vara ett forum för fler parter att få insyn i och ge input till fortsatt utveckling i gränssnitten.
Titel
Sida
Författare
40(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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änssnitten 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 användas som en grund för en lösning i större skala.
Titel
Sida
Författare
41(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 planer 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 lockas ö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 aktörer bör se ut.
•
Forskning kring differentierad prissättning för olika servicenivåer. Är resenärer utan särskilda behov 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
Författare
42(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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/danmarksdigitale-raastof-saettes-fri
Information om flextrafik i Danmark: https://www.flexdanmark.dk/
Titel
Sida
Författare
43(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 exportera 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 prognoser för när man förväntas ankomma till bytespunkter och andra hållplatser. Ett flertal olika tekniska system 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
Författare
44(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
Underlaget utgörs av det sammanställda planerade utbudet enligt NOPTIS-gränssnittet DOI, ändringar enligt NOPTIS-gränssnittet RII och realtidshändelser enligt NOPTIS-gränssnittet VSI. Den samlade bilden exponeras 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örsö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.
Ett 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 kombineras sedan i reseplaneraren med planerat utbud mottaget genom NOPTIS-gränssnittet DOI.
21
Titel
Sida
Författare
45(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 helhetsinformation till andra system.
Ovan visas ett exempel där de båda integrationsfunktionsblock som beskrivs i föregående kapitel har kombinerats 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
Författare
46(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 arbetsområden önskar arbeta mot en gemensam geodataportal. I och med att Lantmäteriets villkor och prismodell ä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 bedriver 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 information 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 kostnader. Trafikföretag kan spara arbetstid och bränsle och resenärer kommer i tid till sina resmål/bytespunkter.
Det öppnas även upp möjligheter för en friare konkurrens och företagstillväxt inom kollektivtrafikmarknaden.
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
Författare
47(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 meterprecision ö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
Författare
48(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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 anropsstyrda 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 positioner 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 anropsstyrda trafiken.
F
Titel
Sida
Författare
49(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 DIIformat25.
<?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" DefaultCoordinateSystemName="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>
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.
24
25
NOPTIS DII 3 revision K eller senare.
Titel
Sida
Författare
50(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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ällen/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 DIIgrä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), alternativt 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 stoppställen (STOP POINTs) kopplas med byteslänk (CONNECTION LINK).
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.
26
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.
27
Titel
Sida
Författare
51(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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
Class Id
5
1
2
3
Prefix för
region/län
0
0
2
Class Id
2
1
2
3
Prefix för
region/län
1
2
3
4
5
6
Globalt hållplatsområdesnummer
inom region/län
1
2
3
4
5
6
7
8
Globalt nodnummer för hållplatsläge/stoppställe
inom region/län28
eller
9
1
2
3
Lokalt nummer för
läge inom hållplatsområdet
I exemplen nedan har modellen som baserar sig på globala nodnummer inom region/län använts.
Å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.
28
Titel
Sida
Författare
52(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
Sverige-unikt ID för bytespunkt på hållplatsområdes-nivå (STOP AREA)
9
0
2
Class Id
1
1
2
3
Prefix för
region/län
1
2
3
4
5
6
inom region/län
0
0
0
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 trafiken så finns det ett behov av att upprätta gemensam information om andra platser som utgör tänkbara startoch ändpunkter för en resa. Det handlar om vårdinrättningar, etablissemang av olika slag, torg och så vidare. I dag finns kunskapen och uppgifter om deras namn och olika alias utspridd bland Sveriges trafikföretag.
Eftersom informationen är av en relativt statisk natur, så är det inte orimligt att försöka etablera en gemensam 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 koordinater 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 automatbearbeta 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. Eventuellt 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öretagen 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
Författare
53(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
•
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)
F
Tidpunkt då uppgiften registrerades
I samband med leveransen anges om leveransen ersätter alla tidigare levererade uppgifter från trafikföretaget.
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 beskrivs 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 geografiskt och vi därmed har flera parallella uppgifter från olika trafikföretag om samma plats så kan uppgifterna 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
Författare
54(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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å automatiskt 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 platserna, men man har även möjlighet att se vilka underliggande uppgifter som är kopplade till platsen. Därmed 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å:
30
31
•
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
Fastställs i det centrala systemet genom omräkning från WGS84 vid behov.
Fastställs i det centrala systemet genom omräkning från SWEREF 99 TM vid behov.
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.
32
Antingen som fritext eller så behöver det tas fram en gemensam lista med tillåtna typer. Om uppgift saknas sätts typen till Okänd.
33
Länskod enligt SCBs numrering. Det borde vara möjligt att i ett centralt system automatiskt räkna ut i vilket län en plats ligger utifrån koordinaterna.
34
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.
35
Titel
Sida
Författare
55(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
•
Tidpunkt för senaste uppdatering
•
Koordinater och namn granskade och låsta (Ja/Nej)
•
Avslutad (Ja/Nej)
Revision
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)
•
Avslutad (Ja/Nej)
I tabellen ExternalPOI exponeras de ”råa” uppgifterna från trafikföretaget. Enda bearbetningen är att koordinater 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)
•
•
F
Titel
Sida
Författare
56(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
•
Revision
F
Avslutad (Ja/Nej)
Sverige-unikt ID för POI
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.
0
9
Class Id
9
7
1
0
2
3
Prefix för
region/län
1
2
3
4
5
6
Point of Interest Number
7
8
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 identifier) enligt NOPTIS modell.
9
6
Class Id
1
2
3
4
RIKSNYCKELPREFIX,
ADRESSPLATS
1
2
3
4
5
6
7
8
RIKSNYCKELID, ADRESSPLATS
9
10
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 RiksnyckelID, 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
Författare
57(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
•
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)
•
•
•
Avslutad (Ja/Nej)
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)
Revision
F
Titel
Sida
Författare
58(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 nodnummer ä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:
9
0
2
Class Id
5
1
2
3
Prefix för
region/län
0
1
2
3
4
5
6
7
8
Globalt nodnummer för hållplatsläge/stoppställe
inom region/län
Som ett alternativ kan den hierarkiskt uppbyggd nyckeln användas:
9
0
2
Class Id
2
1
2
3
Prefix för
region/län
1
2
3
4
5
6
inom region/län
1
2
3
Lokalt nummer för
läge inom hållplatsområdet
Sverige-unikt ID för hållplatsområden (STOP AREA)
9
0
2
Class Id
1
1
2
3
Prefix för
region/län
1
2
3
4
5
6
inom region/län
0
0
0
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
Class Id
1
1
2
Prefix
3
1
2
3
4
Globalt tekniskt linjenummer inom prefix
(region/län/övrigt)
0
0
0
0
0
Linje: En grupp av körvägar för kollektivtrafik som är kända för allmänheten under ett gemensamt nummer eller namn. Ett exempel på en linje är busslinje 5 i Helsingstad.
36
Titel
Sida
Författare
59(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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.
9
0
1
Class Id
4
1
2
Prefix
3
1
2
3
4
1
Riktning
0
0
0
0
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.
9
0
1
Class Id
5
1
2
Prefix
3
1
2
3
4
5
6
7
8
9
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
Författare
60(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
<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 representera ett område.
Däremot så skulle det krävas en mindre ändring i gränssnittet (och kanske även i dagens planeringssystem37) 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 trafikturerna dras tillbaka med trafikledaråtgärden JourneyCancellation enligt NOPTIS RII.
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.
37
Titel
Sida
Författare
61(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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
Författare
62(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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
F
Titel
Sida
Författare
63(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
o
•
•
•
Revision
F
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
o
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 infogas.
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
Författare
64(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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ällarsystem.
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
Författare
65(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
o
•
•
Datum: 2013-03-31
Påstigningspunkten
o
Identitet: 9025001000072138
o
o
o
Namn: Område Gröndal
o
Avstigningspunkten
o
Identitet: 9025001000002237
o
o
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
Påstigningspunkten
o
Identitet: 902500100002239
o
o
o
Namn: Liljeholmen
o
Revision
F
Titel
Sida
Författare
66(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
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.
F
Titel
Sida
Författare
67(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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, 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ämtningspunkten är känd och att resenären ledsagas i eventuella byten så att en obruten kedja erhålls.
Titel
Sida
Författare
68(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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, zoner, 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 begrä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
Författare
69(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 bokningsreservationer 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 bokningssystemet dessutom aktivt dra tillbaks reservationen.
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.
38
Titel
Sida
Författare
70(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 – Resursallokering, 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ändelser. 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
Författare
71(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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änssnitt 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, ändrade 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 reseplaneraren 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ällarsystem för anropsstyrd trafik i samband med resursbrist, annars finns redan i dag möjlighet att manuellt rapportera 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änssnitt 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
Författare
72(72)
Godkänd
Ulf Bjersing
Dokumentidentitet
Datum
2013-05-30
Revision
F
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 indirekt 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.
Som ett alternativ eller parallellt med NOPTIS ROI skulle SIRI gränssnitt kunna användas för att ge reseplanerare och andra system tillgång till realtidsinformation om trafiken.
39

Slutrapport Slutrapport - Teknikplattform för den samlade

Transcription

Similar documents

Omvärld i förändring

Handbok för rapportering Instruktioner för rapportering av utvecklingsprojekt

100 år i kundens tjänst

Identifiering av områden med betydande översvämningsrisk. Steg 1

Årsberättelse 2013

Här - Persontrafik