Slutrapport Slutrapport - Teknikplattform för den samlade
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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 3(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 4(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 5(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 6(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 7(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 8(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 9(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 10(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 11(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 12(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 13(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 14(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 15(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 16(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 17(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 18(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 19(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 20(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 21(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 22(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 23(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 24(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 25(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 26(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 27(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 28(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 29(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 30(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 31(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 32(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 33(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 34(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 35(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Förslaget är att använda NOPTIS Data Import Interface (DII). 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 36(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 37(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 38(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 39(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 40(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 41(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 42(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 43(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 44(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 45(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 46(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 47(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 48(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 49(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 50(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 51(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 52(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 Revision F Sverige-unikt ID för bytespunkt på hållplatsområdes-nivå (STOP AREA) Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. 9 0 2 Class Id 1 1 2 3 Prefix för region/län 1 2 3 4 5 6 Globalt hållplatsområdesnummer 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 53(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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) • Alias namn 2 (frivilligt) • Alias namn 3 (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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 54(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 55(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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. • Koordinater enligt SWEREF 99 TM. • Koordinater enligt WGS-84 latitud och longitud i decimala grader. • 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) • Alias namn 1 (frivilligt) • Alias namn 2 (frivilligt) • Alias namn 3 (frivilligt) • Beskrivning (frivilligt) • Uppgiften levererad av o Företag o Person (frivilligt) o Kontaktuppgift (frivilligt) • Tidpunkt då uppgiften ursprungligen registrerades • Tidpunkt för senaste uppdatering F Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 56(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 • Revision F Avslutad (Ja/Nej) Sverige-unikt ID för POI Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att individuell numrering av POI kan göras på länsnivå. Adressrymden är så stor att 100 miljoner POI kan anges för varje län. 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). • Koordinater enligt SWEREF 99 TM. • Koordinater enligt WGS-84 latitud och longitud i decimala grader. • 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 57(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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) • Tidpunkt då uppgiften ursprungligen registrerades • Tidpunkt för senaste uppdatering • Avslutad (Ja/Nej) 12.4.4 Gränssnitt för att leverera turplaner för den linjelagda kollektivtrafiken Förslaget är att använda NOPTIS Data Import Interface (DII). Sverige-unikt ID för hållplatsläge/stoppställe (STOP POINT) Revision F Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 58(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 Revision F Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. Denna modell medger att individuell numrering av bytespunkter tillsammans med övriga hållplatsområden och hållplatsläges/stoppställen kan göras på länsnivå. Det finns två alternativa nycklar i NOPTIS för att ange ett hållplatsläge/stoppställe. Dels en hierarkiskt uppbyggd nyckel, och dels en globalt numrerad nyckel. Den globalt numrerade nyckeln kopplas till det nodnummer som hållplatsläget/stoppstället tilldelats. Detta 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 Globalt hållplatsområdesnummer 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) Den Sverige-unika identiteten kan lämpligen anges som en GID (global identifier) enligt NOPTIS modell. 9 0 2 Class Id 1 1 2 3 Prefix för region/län 1 2 3 4 5 6 Globalt hållplatsområdesnummer 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 59(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Globalt tekniskt linjenummer inom prefix (region/län/övrigt) 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 Globalt tekniskt linjenummer inom prefix (region/län/övrigt) 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. <?xml version="1.0" encoding="UTF-8"?> <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"> <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> <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 SequenceNumber="2"> <JourneyPatternPointRef><Gid Gid="9025001000002645"/></JourneyPatternPointRef> <Departure EarliestTime="08:15:00"/> </Call> Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 60(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 Revision F <Call SequenceNumber="3"> <JourneyPatternPointRef><Gid Gid="9025001000002237"/></JourneyPatternPointRef> <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 Förslaget är att använda NOPTIS Data Import Interface (DII). 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 61(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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. <?xml version="1.0" encoding="UTF-8"?> <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"> <Source CreatedDateTime="2013-01-23T09:23:01"/> <IssuingTransportAuthorityRef><Number Number="1"/></IssuingTransportAuthorityRef> <VersionFrameRef Name="X2"> <DefiningOrganisationalUnitRef> <OrganisationRef><ContractorRef><Number Number="152"/></ContractorRef></OrganisationRef> </DefiningOrganisationalUnitRef> </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> <Call SequenceNumber="1"> <JourneyPatternPointRef><Gid Gid="9025001000002237"/></JourneyPatternPointRef> <Departure EarliestTime="16:00:00"/> <ChangeFromRules><ChangeFromRule MaximumWaitTimeDuration="PT60M"> <FeederJourneyFilter> <JourneyOnDirectionOfLineDef MaxOffsetDuration="PT10M"> <DirectionOfLineRef><Gid Gid="9014001002200000"/></DirectionOfLineRef> </FeederJourneyFilter> <FeederStopRef><StopAreaRef><Number Number="2237"/></StopAreaRef></FeederStopRef> </ChangeFromRule></ChangeFromRules> </Call> <Call SequenceNumber="2"> <JourneyPatternPointRef><Gid Gid="9025001000072138"/></JourneyPatternPointRef> <Arrival LatestTime="16:30:00"/> </Call> </Calls> </ServiceJourney> </VehicleJourneys> </TimetableVersion> Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 62(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 63(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 WGS 84 Latitud: 59.31064 o WGS 84 Longitud: 18.02645 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 64(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 65(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 o • • Datum: 2013-03-31 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 WGS 84 Latitud: 59.31064 o WGS 84 Longitud: 18.02645 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 WGS 84 Latitud: 59.31045 o WGS 84 Longitud: 18.02643 o Namn: Liljeholmen o Tidigast avgångstid: 2013-03-31T08:15:00+01:00 Revision F Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 66(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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: Avsändare: System 2 Mottagare: System 1 Meddelandetyp: Svar på reservationsförfrågan Reservations-ID: Sys-1/1 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 67(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 68(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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: Avsändare: System 1 Mottagare: System 3 Meddelandetyp: Bokningsförfrågan Reservations-ID: Sys-1/2 Resenärs-ID: Mastercard_123456123423 Exempel på bokningsbekräftelse: Avsändare: System 3 Mottagare: System 1 Meddelandetyp: Svar på bokningsförfrågan Titel Sida Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 69(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 2013-05-30 Revision F Reservations-ID: Sys-1/2 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 70(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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: Avsändare: System 1 Mottagare: System 3 Meddelandetyp: Avbokningsförfrågan Boknings-ID: Sys-3/1 Exempel på avbokningsbekräftelse: Avsändare: System 3 Mottagare: System 1 Meddelandetyp: Svar på avbokningsförfrågan Boknings-ID: Sys-3/1 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 71(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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 Slutrapport - Teknikplattform för den samlade kollektivtrafiken Författare 72(72) Godkänd Ulf Bjersing Dokumentidentitet Datum TR-SIS_TEKNIK_SLUTRAPPORT 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
© Copyright 2024