MetropAccess-Reititin 1.2 Käyttöohje

Transkriptio

1 MetropAccess-Reititin 1.2 Käyttöohje Perttu Saarsalmi, Maria Salonen, Juha Järvi, Henrikki Tenkanen & Tuuli Toivonen Viimeksi päivitetty: (aiemmat päivitykset: ) 1

2 Sisällys Sisällys Mikä Reititin 1.2 on? Reitittimen käyttöönotto Reitityksen logiikka lyhyesti Tiedostojen kuvaus Lähtö- ja kohdepistetiedostot Asetustiedosto conf.json Tulostiedostot (txt ja kml) txt-tulostiedoto kml-tiedosto Perusajojen tekeminen Linux- ja Windows-ympäristöissä Kalkatin käyttöönotto Kalkati-tiedostosta Kalkatin käyttöönotto Muuta huomioitavaa Kalkatiin liittyen Uuden reitin lisääminen Uuden reitin digitointi Uuden reitin käyttö laskennoissa Muuta huomioitavaa Keskusmuistin ylikuormittaminen Ajojen ketjuttaminen Linuxissa Ajon keskeyttäminen Reittihaun logiikasta ja erityistilanteista Matkan aikaisen odottelun vähentäminen optimoinnissa: Haarukointi Huomioita kävelyreitityksestä Hakupisteet keskellä ei mitään Kirjallisuutta Liite 1. Esimerkkicase: Länsimetron lisääminen joukkoliikenteen verkostoon

3 1 Mikä Reititin 1.2 on? Reititin 1.2 on Helsingin yliopiston Geotieteiden ja maantieteen laitoksella toimivan MetropAccesshankkeen ja Busfaster Oy:n yhteistyössä kehittämä työkalu joukkoliikennereititykseen pääkaupunkiseudulla. Työkalu hyödyntää Helsingin Seudun Liikenteen (HSL) joukkoliikenteen aikataulu- ja reittitietokantoja alueelliseen saavutettavuustarkasteluun. Reititin käyttää joukkoliikennereittien laskennassa HSL:n tuottamaa Kalkati.net XML-tiedostoa (sisältää tiedot voimassa olevista joukkoliikenteen aikatauluista ja reiteistä) ja kävelyosuuksien reitityksessä OpenStreetMap-aineistoa (OSM) (sisältää käveltävien tieosuuksien ja polkujen geometrian). Reitittimen aikaisempi versio Reititin 1.0 hyödynsi HSL:n API-rajapintaa reittitiedon kyselyyn, mutta sen käyttö osoittautui liian hitaaksi suurissa laskennoissa. Reititin pystyy optimoimaan tehokkaasti suuren joukon joukkoliikennereittejä ja tuottamaan alueellisissa saavutettavuustarkasteluissa tarvittavaa tietoa esimerkiksi tuhansien lähtöpisteiden ja kymmenien kohdepisteiden välisestä matka-ajasta sekä matkaketjusta eri joukkoliikennevälineillä. Reitittimen reittioptimointia voi muokata erilaisilla parametreilla (esim. lähtökellonaika, kävelynopeuden säätö, vaihdottomuuden suosiminen, tiettyjen joukkoliikennelinjojen tai kulkumuotojen sulkeminen pois käytöstä). Reititintä voi hyödyntää myös pelkkien kävelyreittien ja -aikojen arviointiin. Tällöin reititys perustuu OpenStreetMap-aineiston geometriaan. Reitittimeen on mahdollista lisätä myös uusia, hypoteettisia joukkoliikennereittejä ja testata näiden vaikutusta matka-aikoihin ja reittivalintoihin eri alueilla. Työkalulla on mahdollista myös vertailla reittejä ja niiden matka-aikoja vanhempien aikataulujen ja reitistöjen välillä. Työkalua ja sen edeltäjiä on hyödynnetty sekä kaupunkisuunnittelussa (Helsingin kaupunkisuunnitteluvirasto 2012) että tieteellisessä tutkimuksessa (Toivonen et al. 2010, Salonen et al. 2012, Jäppinen et al. 2013, Lahtinen et al. 2013, Salonen & Toivonen 2013). Työkalun koodi lisensoitu GNU General Public v3 lisenssillä ja vapaasti ladattavissa hankkeen verkkosivuilla osoitteessa 2 Reitittimen käyttöönotto Työkalu on ohjelmoitu käyttäen JavaScriptiä, joten se toimii kaikissa yleisissä käyttöjärjestelmissä. Reitittimestä on versiot sekä Windows että Linux -käyttöjärjestelmille. Molemmat versiot on ladattavissa MetropAccess-hankkeen verkkosivuilta Työkalut osion alta. Ne ovat heti käyttövalmiita, mutta vaativat toimiakseen Node.js-ohjelman asentamisen, jonka saa ladattua Node.js-projektin verkkosivuilta ( Node.js mahdollistaa JavaScript koodin ajamisen paikallisesti käyttäjän omalla tietokoneella, kun perinteisesti koodia on ajettu verkkoympäristössä käyttäen selainta. 3 Reitityksen logiikka lyhyesti Joukkoliikenteen reititys tapahtuu Kalkani.net XML-aineiston sisältämän geometria- ja aikataulutiedon perusteella. Reitit kohteista pysäkeille ja vaihdot pysäkkien välissä optimoidaan käyttäen OSM-aineistoa. Reititys perustuu modifioituun Dijkstran algoritmiin (Dijkstra 1959), jota voidaan pitää reittioptimoinnin 3

4 standardimenetelmänä. Dijkstran algoritmia on muokattu siten, että kustannuksen lisäksi optimoinnissa tallennetaan tietoa mm. kellonajasta, sijainnista graafilla ja tieto edellisestä vieraillusta pisteestä (Järvi ym. 2014), jotka auttavat oikean matka-ajan laskennassa huomioiden mm. aikataulut sekä vaihtoihin että kävelyyn kuluvan ajan. Haetuille reiteille lasketaan sekä laskennallinen kustannus että reittiin kuluva aika. Reititin sallii myös eri joukkoliikennemuotojen suosimisen (esim. raideliikenteen suosiminen). Kustannus määräytyy asetustiedostossa määriteltyjen kustannusparametrien mukaan. Esimerkiksi bussimatkustamisen kustannus voidaan määrittää 1,2-kertaiseksi metromatkustamiseen nähden. Näin ollen 10 minuuttia kestävä bussimatka saisi kustannuksekseen 12, ja saman ajan kestävä metromatka 10. Näistä kahdesta vaihtoehdosta siis metromatka olisi optimaalisempi ja tulisi valituksi. 4 Tiedostojen kuvaus Reititinajo edellyttää muutamia syötetietoja: Lähtö- ja kohdepisteet listataan omissa tekstitiedostoissaan ja asetustiedosto conf.json ohjaa Reititintä käyttämään haluttuja hakuparametreja. 4.1 Lähtö- ja kohdepistetiedostot Lähtö-ja kohdepisteet tallennetaan omiin, puolipisteellä erotettuihin tekstitiedostoihinsa (.txt), joiden rakenne on kummassakin sama. Ne sisältävät: Otsikkorivin Kolme saraketta: Lähtöpisteen ID-tunnus, itäkoordinaatti (x) ja pohjoiskoordinaatti (y). Kaikki puolipisteellä erotettuina Kuvassa 1on esimerkit lähtö- ja kohdepistetiedostojen rakenteesta. Kentät voidaan nimetä vapaasti. Lähtö- ja kohdepisteiden koordinaatit voivat olla missä tahansa EPSG-koordinaatistossa tai täällä listattujen projektioiden mukaisissa koordinaatistoissa: Kuva 1. Esimerkki Reitittimen lähtö- ja kohdepistetiedostoista, kuvassa KKJ2-koordinaatistossa. 4

5 4.2 Asetustiedosto conf.json Conf.json-tiedostossa määritellään kaikki reitityksen parametrit.json-muotoinen tiedosto Srid-kenttä määrittelee lähtö- ja kohdepisteiden projektion (määrittelyn on oltava yhtenäinen lähtö- ja kohdepisteiden projektioiden kanssa). Asetustiedostossa oletuksena on WGS84 ( EPSG: 4326 ) // Pistelistojen projektion SRID-tunnus (EPSG-koodi). srid: 'EPSG: 4326', Date-kenttä määrittelee reitityspäivämäärän, eli minkä päivän joukkoliikenneaikatauluja haussa käytetään. Jos asetustiedoston päivämäärä ei osu käytössä olevan aikataulutiedoston voimassaoloajalle, Reititin ilmoittaa tästä ja käyttää hakua vastaavaa viikonpäivää käytössä olevassa aikataulutiedostossa (ks. Luku 7. Kalkatin vaihtaminen). // Päivämäärä jolle kaikki reitit haetaan, muodossa vvvv-kk-pp. date: ' ', Time-kenttä määrittää reittihaun kellonajan (joko lähtöaika tai saapumisaika, jäljempänä kuvattavasta backwards-asetuksesta riippuen). Aikataulutiedoissa vuorokausi vaihtuu aina aamuyöllä klo 4. Jos hakuja tehdään puolenyön jälkeen, merkitään päiväykseksi edellinen vuorokausi ja tunniksi esimerkiksi 25 kuvaamaan kello yhtä aamuyöllä (26 = klo 2, jne.). Listan haarukointitiheys on käyttäjän määriteltävissä ja vaikuttaa siihen kuinka optimaalinen reitti (matka-aikaan, route_time perusten) saadaan (ks. Luku 9. Reittihaun logiikasta ja erityistilanteista). // Lähtökellonaika reitityksessä, muodossa hh:mm. time: [ '08:00', '08:05', '08:10' ], maxcost-parametri määrittää reitin maksimikustannuksen. Reittejä, joiden laskennallinen kustannus ylittää maxcost-arvon ei huomioida lainkaan, vaan tulostaulukkoon tulostuu tällaisen reitin kohdalle NOROUTE. Maksimikustannus ei perustu suoraan aikaan (vaan laskennalliseen kustannukseen) koska tiettyihin paikkoihin menevät reitit voisivat vaihdella aikarajan mukaan ja tuottaa reuna-alueilla reittejä joiden kustannus ei ole optimaalinen. 5

6 // Reitin maksimikustannus, johon haku pysähtyy. Minuutteina. maxcost: 60*5, walkspeed määrittelee kävelynopeuden reitin kävelyosuuksilla. HSL:n reittioppaan oletuskävelynopeus on 70 m / min. Mikäli halutaan, että reittien kävelyosuudet lasketaan pyöräilynopeuteen perustuen, voidaan tämä parametri säätää pyöräilynopeudeksi. Vastaavasti kävelynopeutta voi hidastaa, jos haluaa tehdä reitityksiä esimerkiksi hitaammin kävelevien vanhusten näkökulmasta. // Kävelynopeus. Metrejä minuutissa. walkspeed: 70, Parametri maxwalk säätää maksimietäisyyden metreinä kävelyreititykselle. Jos Reitittimellä tehdään pelkkään kävelylaskentaa, kannattaa maxwalk säätää melko suureksi. Parametri snapdist säätää kuinka pitkän matkan päästä lähtöpiste voidaan snapata aineistossa olevaan tieverkkoon. Oletusarvo on 200 metriä. Jos siis lähtöpiste on kauempana tieverkosta kuin snap distance, ei reittiä voida laskea. Eri kulkumuotojen kustannuksia määritellään transcost- ja transmodecost-parametreilla. transcost on oletuskustannus kaikille kulkumuodoille, ja transmodecost määrittelee siitä poikkeavat arvot halutuille kulkumuodoille. Jos tietyn kulkumuodon kustannus on yli 1, kyseistä kulkumuotoa vältetään reitin optimoinnissa. Kustannus 0 on erityistapaus se tarkoittaa, että kyseinen kulkumuoto on kokonaan disabloitu. Alla olevassa esimerkissä VR:n lähijunat ovat kokonaan pois käytöstä (transmodecost 12: 0). Jos halutaan hakea pelkkiä kävelyreittejä, transcost määritellään nollaksi (ja samalla täytyy tarkastaa, ettei minkään kulkumuodon transmodecostia ole määritelty erikseen 1:ksi, koska silloin transcost-määritys ei pätisi). Alla on listattu kulkumuotojen koodit niin kuin ne olivat tammikuussa Voimassa olevat koodit kannattaa tarkistaa Reittiopas APIn sivuilta (Reittiopas API, 2014). 1 Hki/linja-auto 2 Hki/raitiovaunu 3 Espoon sisäinen 4 Vantaan sisäinen 5 Seutuliikenne 6 Metroliikenne 7 Vesiliikenne 8 U-liikenne 12 VR:n lähiliikenne 21 Helsingin palvelulinjat 22 Helsingin aamuyönlinjat 23 Espoon palvelulinjat 24 Vantaan palvelulinjat 25 Aamuyön seutulinjat 36 Kirkkonummen sisäinen 38 Sipoon sisäiset linjat 39 Keravan sisäinen // Joukkoliikenteen kustannuskerroin. 6

7 transcost: 1, transmodecost:{ 1: 1, 12: 0, dummy:true }, transjorecost säätää yksittäisten linjojen kustannusta JORE-koodin perusteella (ks. JORE-koodit HSL:n sivuilta). Koodista voi kirjoittaa alkuosaa niin paljon kuin haluaa. Esimerkiksi pelkkä "1" säätää kaikkia Helsingin linjoja, "1010" taas on ratikka 10. Alla olevassa esimerkissä ratikka 10 on poissa käytöstä. transjorecost:{ "1010": 0, }, // Tarpeeton rivi jonka ansiosta edellisen rivin lopussa saa olla pilkku. dummy:true Kävelyn kustannusta säädetään walkcost parametrilla. Mitä suurempi kerroin, sitä vaivalloisempaa kävely on, eli Reititin yrittää etsiä reittejä, joissa kävelyn osuus mahdollisimman pieni. Oletusarvoisesti kävelyn kustannuskerroin on 1.2, eli joukkoliikennettä (jonka kustannuskerroin on oletuksena 1) suositaan ennemmin kuin kävelyä. // Kävelyn kustannuskerroin. walkcost: 1.2, Pysäkillä odottamisen kustannusta säädetään waitcost-parametrilla, ja kotona odottelua initcostparametrilla. Oletuksena initcost on 1, jolloin kotona odottelun kustannus on sama kuin pysäkeillä odottelun kustannus. // Pysäkillä odottamisen kustannuskerroin. waitcost: 1.0, // Kotona odottamisen kustannuskerroin. // Jos 0 niin etsitään lyhin matka-aika ja jos 1 niin etsitään aikaisin saapumisaika. Luku voi olla jotain näiden väliltä. initcost: 1, 7

8 minwait-parametri määrittelee pienimmän mahdollisen vaihtomarginaalin. Esimerkissä Reititin ei ehdota reittejä, joissa vaihtoajaksi jäisi alle kolme minuuttia. // Pienin vaihtoaika minuutteina. minwait: 3, entercost- ja leavecost parametreilla säädetään kulkuvälineeseen siirtymiseen sekä kulkuvälineestä poistumiseen liittyviä kustannuksia. Tätä voidaan myös säätää kulkumuotokohtaisesti edellä mainituilla kulkumuotokoodeilla. // Kulkuvälineeseen siirtymisen kustannus minuutteina. entercost: 2.5, entermodecost:{ 1: 2.5, 12: 2.5, }, // Tarpeeton rivi jonka ansiosta edellisen rivin lopussa saa olla pilkku. dummy:true // Kulkuvälineestä poistumisen kustannus minuutteina. leavecost: 2.5, leavemodecost:{ 1: 2.5, 12: 2.5, }, // Tarpeeton rivi jonka ansiosta edellisen rivin lopussa saa olla pilkku. dummy:true Erityisryhmätarkasteluissa (esim. vanhusten osalta) voi määritellä, että kulkuvälineestä poistumisessa kestää tietty määrä sekunteja (tällöin sekunnit lisätään myös tulostaulun matka-aikoihin). // Kulkuvälineestä poistumiseen kuluva aika sekunteina. leavetime: 0, Backwards-asetus määrittelee, onko asetustiedoston alussa annettu kellonaika lähtöaika vai saapumisaika. Jos backwards on false, annettu kellonaika on lähtöaika. Jos taas backwards on true, reittejä haetaan kohteeseen saapumisen ajan perusteella. Reitit tulostiedostossa kulkevat silti samaan suuntaan lähtöpaikoista kohdepaikkoihin, mutta laskenta kulkee sisäisesti eri suuntaan ja backwards-asetuksen päällä ollessa laskenta on mutkikkaampi. Backwards-asetuksen käyttö on järkevää jos lähtöpisteitä on paljon verrattuna 8

9 kohdepisteisiin ja halutaan käyttää lähtökellonaika. Vastaavasti jos kohdepisteitä on paljon ja halutaan käyttää perilläoloaikaa, on laskenta nopeampaa ilman backwards-asetusta. // Tehdäänkö haku takaperin (true) vai ei (false). Takaperin haettaessa time on saapumiskellonaika. backwards: false, // Tarpeeton rivi jonka ansiosta edellisen rivin lopussa saa olla pilkku. dummy:true } 9

10 4.3 Tulostiedostot (txt ja kml) Mahdollisia Tulostiedostoja on kaksi: txt.muotoinen tekstitiedosto, jossa jokaisen lähtö ja reitti omalla rivillä ominaisuustietoineen sekä kml muotoinen tiedosto, jossa jokainen reitti kuvattu vektorimuodossa. Kuva 2. txt-tulostiedosto Kuva 3. kml-tulostiedosto txt-tulostiedoto sisältää jokaisen lähtö ja kohdepisteen välineen reitti omalla rivillään ominaisuustietoineen Tiedosto voidaan avata ja tarkastella esimerkiksi Excelissä Ominaisuustiedot on eroteltu omiin kenttiin puolipisteillä eroteltuna linjatietoja lukuun ottamatta, jotka löytyvät viimeisestä kentästä; linjat on eroteltu toisistaan risuaidalla # txt-tulostieston kenttien kuvaus: YLEINEN REITIN KUVAUS (samat kentät kaikilla reiteillä) from_id lähtöpisteen id-tunnus to_id kohdepisteen id-tunnus fromid_toid lähtö- ja kohdepisteen id-tunnukset alaviivalla eroteltuna route_number reitin numero hakujen sarjassa (Reitittimen nykyversiossa aina 1) 10

11 at from_x from_y to_x to_y total_route_time route_time route_distance route_walks_total_time route_walks_total_distance route_total_lines departure_datetime first_walk_time first_walk_distance first_stop_name first_stop_code last_stop_name last_stop_code last_walk_time last_walk_distance arrival_datetime reitin lähtö- tai perilläoloaika (ks. backwards-asetuksen määrittely) lähtöpisteen x-koordinaatti lähtöpisteen y-koordinaatti kohdepisteen x-koordinaatti kohdepisteen y-koordinaatti reitin kokonaismatka-aika (sis. mahdollisen lähtöpisteessä odottelun reitin alussa) reitin kokonaismatka-aika (ei sisällä lähtöpisteessä odottelua) reitin kokonaispituus metreinä reitin kaikkien kävelyjen kokonaismatka-aika minuutteina reitin kaikkien kävelyjen kokonaispituus metreinä käytettyjen linjojen määrä lähtökellonaika ensimmäisen kävelyn matka-aika minuutteina ensimmäisen kävelyn pituus metreinä ensimmäisen pysäkin nimi ensimmäisen pysäkin koodi viimeisen pysäkin nimi viimeisen pysäkin koodi viimeisen kävelyn matka-aika minuutteina viimeisen kävelyn pituus metreinä perilläoloaika YKSITYISKOHTAINEN REITIN KUVAUS (lopun pituus riippuu reitin ominaisuuksista) WALK walk1_departure_time walk1_arrival_time walk1_distance LINE line1_departure_time line1_arrival_time line1_distance line1_code line1_type line1_name line1_first_stop_name line1_first_stop_code line1_last_stop_name line1_last_stop_code reitin ensimmäisen vaiheen tyyppi (kävely) ensimmäisen kävelyn lähtöaika ensimmäisen kävelyn saapumisaika (pysäkille) ensimmäisen kävelyn pituus reitin seuraavan vaiheen tyyppi (joukkoliikennelinja) ensimmäisen linjan lähtöaika (pysäkiltä) ensimmäisen linjan saapumisaika (pysäkille) ensimmäisen linjan pituus ensimmäisen linjan koodi ensimmäisen linjan tyyppi ensimmäisen linjan numero ensimmäisen linjan ensimmäisen pysäkin nimi ensimmäisen linjan ensimmäisen pysäkin koodi ensimmäisen linjan viimeisen pysäkin nimi ensimmäisen linjan viimeisen pysäkin koodi 11

12 kml-tiedosto jokainen ajettu reitti vektori-muodossa avataan esim. Google Earth -ohjelmistossa reittien eri osat eroteltuina toisistaan reitin osien ominaisuustiedot ominaisuustiedot: pysäkkien nimet, liikkumismuoto, lähtö- ja saapumiskellonajat sekä liikkumismuotojen vaihtojen kellonajat 4.4 Perusajojen tekeminen Linux- ja Windows-ympäristöissä Sekä Linux- että Windows-ympäristöissä reittihaut tehdään komentoriviä käyttäen. Alla on kuvattu ajojen eri vaiheet. Kaikki reitityksissä käytettävät komennot saadaan näkyviin help-komennolla (Kuva 2). LINUX: route.sh --help WINDOWS: route.bat --help Kuva 4. Reitityskomennot (LINUX) Lähtö- ja kohde-tiedostot sekä conf-tiedosto siirretään (palvelimelle) samaan kansioon (Windowsversiossa aina bin-kansio) (Kirjaudutaan palvelimelle ja) navigoidaan ajokansioon (Windows-versiossa aina bin-kansio) Suoritetaan ajokomento: 12

13 LINUX: route.sh lahtopisteet.txt kohdepisteet.txt --out-avg=tulostiedosto.txt --outkml=tulostiedosto.kml --base-path=/opt/jemma/kalkati WINDOWS: route.bat lahtopisteet.txt kohdepisteet.txt --out-avg=tulostiedosto.txt --outkml=tulostiedosto.kml --base-path=c:\kalkatiensailytyskansio\kalkati route.sh / route.bat ajokomento lahtopisteet.txt tekstitiedosto, jossa on määritelty ajon lähtöpisteet kohdepisteet.txt tekstitiedosto, jossa on määritelty ajon kohdepisteet --out-avg Tekstimuotoinen tulostiedosto. Tulostiedostot tallentuvat oletuksensa samaan kansioon, jossa ajo tehdään. Ne voidaan myös tallentaa eri paikkaan määrittämällä tiedostonimen eteen hakemistopolku (esim. --out-avg=/tulokset/tulostiedosto.txt output tallentuu kansioon tulokset ; HUOM! Windowsympäristössä täytyy määritellä täysi hakemistopolku tuloskansion määrittelyssä!) --out-kml.kml-muotoinen tulostiedosto. kml-tulostiedostolla reitin geometriaa että ominaisuustietoja voidaan tarkastella esimerkiksi GoogleEarthissa. Jos out-kml-parametria ei määritellä,.kml-tiedostoa ei synny. Tiedosto kannattaa jättää pois isoissa ajoissa, koska se muodostuu nopeasti isokokoiseksi ja vie paljon aikaa (ja tilaa) tulostuessaan. --base-path määrittelee Kalkati-aineiston (eli aikataulut ja reitit), jota ajossa käytetään. Kalkati-tiedostoa ei tarvitse erikseen määritellä jokaisen ajon yhteydessä, vaan Reititin käyttää oletuksena latauksen mukana tulevaa Kalkatia. Jos kuitenkin haluat käyttää eri ajankohdan aikatauluja kuin mitkä oletuskalkatissa on, tarkasta, että conf-tiedostossa määrittelemääsi päivämäärää vastaava Kalkati löytyy käsiteltynä kansiosta jonne Kalkatit tallennetaan (esim. /opt/jemma) ja määrittele se komentorivillä ajoa aloittaessasi. 5 Kalkatin käyttöönotto 5.1 Kalkati-tiedostosta HSL jakaa Reittioppaan reitti- ja aikataulutiedot XML-muotoisena Kalkati.net dump-tiedostona. Lisätietoa Kalkati-tiedostosta löytyy osoitteesta Kalkatitiedosto ja mahdolliset muutokset aikataulutiedoissa päivittyvät säännöllisin väliajoin alla mainitulle sivulle. Reititin tarvitsee toimiakseen sekä dump-filen että flag.txt-tiedoksen, joista kompressoidaan Reitittimen käyttämät tiedostot: map2.txt, ref.txt, trans.txt. Dump file api.reittiopas.fi/data/all.zip Dump file's validity flag api.reittiopas.fi/data/flag.txt 13

14 5.2 Kalkatin käyttöönotto Kalkatin käyttöönoton ja päivittämisen voi tehdä kahdella tavalla. (1) Lataamalla hankkeen verkkosivujen Data -osiosta valmiiksi kompressoidut Kalkati-tiedostot ja määrittämällä Reititin ajoja tehdessä uuden Kalkatin sijainti komennolla --base-path tai korvaamalla Reitittimen /MetropAccess-Reititin/data/ - kansion sisältämät tiedostot (map2.txt, ref.txt, trans.txt) ladatun paketin mukana tulleilla tiedostoilla. Tämä on helpoin ja suositeltu vaihtoehto Kalkatin päivittämiseen, ja Windows ympäristössä myös ainoa tapa vaihtaa Kalkatia. (2) Linux ympäristössä Kalkatin vaihto onnistuu samalla tavoin kuin kohdassa 1 (suositeltu tapa). Kalkatin vaihto on mahdollista kuitenkin tehdä myös toisella tapaa, joka edellyttää, että käyttäjällä on HSL:ltä saadut Kalkati.net dump-tiedostot sekä käytettävissä Reitittimen erillinen kehitys-versio (ladattavissa hankkeen Github tililtä: Kalkatin käyttöönotto tapahtuu suorittamalla seuraavat työvaiheet, jossa ensin kompressoidaan Kalkatin aikataulutiedot ja tämän jälkeen: Tässä esimerkissä oletetaan, että ReititinDev -versio on asennettuna /opt/ -kansioon. Nimeä ladatut Kalkati-tiedostot seuraavalla tavalla: all-vvvv-kk-pp.zip, flag-vvvv-kk-pp.txt (esim. all zip). Siirrä Kalkati-tiedostot niille tarkoitettuun hakemistoon (esim. /opt/kalkati/build/big/kalkati-hsl/) ja nimeä tiedostot oikein päivämäärän mukaisesti (esim. all zip ja flag txt) Korjaa tiedostoa /opt/kalkati/build/kalkati/date.txt vaihtaen sisällöksi sama päivämäärä kuin tiedostonimissä (esim ) Siirry /opt/kalkati/build-kansioon ja aja komennot: o./run-01.sh o./run-02.sh o./run-03.sh Siirry hakemistoon, johon haluat tallentaa Kalkatin (esim. /home/myfolder/kalkatijemma) ja suorita komennot: o cd /home/myfolder/kalkatijemma o luo uusi kansio: mkdir kalkati (nimeä kansio kalkatin päivämäärän mukaisesti) o kopioi Kalkati-builderin tekemät tiedostot juuri luomaasi kansioon: - cp -r /opt/kalkati/data /home/myfolder/kalkatijemma/kalkati Viimeiseksi määritetään, että Reititin käyttää juuri kompressoimaamme Kalkatia suorittamalla kohdan (1) työvaiheet. 5.3 Muuta huomioitavaa Kalkatiin liittyen Kalkatin määrittely reitityksen yhteydessä edellyttää, että kyseinen Kalkati on ensin otettu käyttöön (Ks. Kalkatin määrittely perusajojen yhteydessä s. 14) Reitityspäivämäärän täytyy olla joku määritellyn Kalkatin käsittämän ajanjakson päivämäärä; jos näin ei ole, antaa Reititin ilmoituksen Input date is out of range ja valitsee automaattisesti päivän viimeksi määritellyn kalkatin sisältä 14

15 Reititin ilmoittaa uuden päivän käyttäjälle viestillä New date is day 15 of range to Kalkati käyttää oletuksena aina viimeksi määriteltyä kalkatia, joten sitä ei tarvitse määrittää joka ajon yhteydessä uudestaan! valmiiksi käsiteltyjä Kalkati-tiedostoja löytyy tutkimushankkeemme sivuilta 6 Uuden reitin lisääminen Reitittimellä tehtyihin laskentoihin on mahdollista lisätä uusia reittejä, jos halutaan esimerkiksi tarkastella tulevaisuudessa tehtäviä linjamuutoksia ja niiden vaikutuksia reittioptimointeihin sekä matka-aikoihin (esim. länsimetro, ks. Liite 1). Reittien lisäämisprosessi koostuu kahdesta vaiheesta: (1) uuden reitin digitointi sekä (2) uuden reitin ottaminen mukaan laskentaan perusajon yhteydessä annetulla komennolla. 6.1 Uuden reitin digitointi Pysäkkien väliset reitit ovat murtoviivoja (polyline), joista jokaisella attribuutteina on seuraavat tiedot: RouteID = Reitin ID, [Integer] (näitä voi olla samassa tiedostossa useita. Käytännössä siis kaikki uudet linjat on digitoitava samaan tiedostoon ja ne on ladattava Reitittimeen kerralla) Sequence = viivan järjestysnumero reitillä, [Integer] Frequency = vuorotiehys minuutteina (keskiyöstä), [Integer] Duration = viivan pätkän kesto minuuteissa, [Double] Length = viivan pätkän pituus metreinä koordinaatistoista riippumatta, [Double] FirstStop = Viivan pätkän alkupysäkin nimi, [Text] LastStop = Viivan pätkän loppupysäkin nimi, [Text] (FirstStop ja LastStop-sarakkeista toisen voi jättää tyhjäksi kunhan pysäkin nimi on joko sille saapuvassa tai siltä lähtevässä murtoviivan osassa). Huomioitavaa: Sarakkeiden järjestyksellä ei ole väliä Arcin automaattisesti luomat FID ja Shape-kentät eivät ole Reitittimen kannalta ongelma Jos teet kokonaan uuden shapefilen, Arcissa luodut murtoviivat täytyy tallentaa wgs84:ssa, koska Arcin projektiomäärittelyt esim. KKJ2:n osalta eivät noudata kaikkia standardeja 6.2 Uuden reitin käyttö laskennoissa Uusi reitti huomioidaan laskennassa komennolla --extra=tiedostonimi.shp LINUX: route.sh start.txt end.txt --out-avg=tulostiedosto.txt extra=uusireitti.shp --basepath=/opt/jemma/kalkati WINDOWS: route.bat start.txt end.txt --out-avg=tulostiedosto.txt extra=uusireitti.shp 15

16 7 Muuta huomioitavaa 7.1 Keskusmuistin ylikuormittaminen Laskennassa ei periaatteessa ole minkäänlaisia kapasiteettirajoitteita. Ainoastaan keskusmuisti saattaa ylikuormittua, jonka seurauksena ajo hidastuu tai saattaa pysähtyä kokonaan. Kun Reititin hakee reittejä, se tulostaa näytölle kunkin haun jälkeen tekstin "heap now <numero> megs", joka ilmoittaa keskusmuistista varatun muistin määrän. Muistiongelmaan ei toistaiseksi ole muuta ratkaisua kuin ajaa aineisto pienemmissä osissa, esim. jakamalla kohdepisteet x määrään lohkoja ja laskemalla reitit kustakin lähtöpisteestä jokaisen lohkon kaikkiin kohdepisteisiin. Ajettavien tiedostojen määrän kasvaessa todella suureksi on suositeltavaa ajaa kaikki reititykset erillisen ajojono-tiedoston kautta (ks. luku 9.2). 7.2 Ajojen ketjuttaminen Linuxissa Useiden eri reititinajojen ketjuttaminen onnistuu luomalla ajokansioon uusi.sh-tiedosto ja kirjoittamalla sinne kaikki ajokomennot halutussa järjestyksessä alla olevan esimerkin mukaisesti. Alla olevassa esimerkissä (LINUX) kohdepisteet on jaettu useampaan osaan. route.sh start.txt end_lohko_1.txt --out-avg=tulostiedosto_1.txt --base-path=/opt/jemma/kalkati route.sh start.txt end_lohko_2.txt --out-avg=tulostiedosto_2.txt --base-path=/opt/jemma/kalkati route.sh start.txt end_lohko_3.txt --out-avg=tulostiedosto_3.txt --base-path=/opt/jemma/kalkati Tämän jälkeen tiedosto ajetaan seuraavalla komennolla. Tiedoston sisältämät ajokomennot ajetaan yksitellen listausjärjestyksessä. sh ketjutus.sh 7.3 Ajon keskeyttäminen Ajo voidaan sammuttaa sekä linux- että windows-ympäristössä alla olevalla komennolla: ctrl + c 16

17 8 Reittihaun logiikasta ja erityistilanteista 8.1 Matkan aikaisen odottelun vähentäminen optimoinnissa: Haarukointi Reititin toimii siten, että kaikkiin reitin varrella oleviin pisteisiin saavutaan mahdollisimman aikaisin. Ensimmäisellä pysäkillä odottelu voidaan siirtää kotona odotteluksi, mutta myöhempien vaihtopysäkkien odottelua ei. Jos reitin alussa käytetään esimerkiksi metroa, odotellaan lähtöpisteessä vain siten, että ehditään sopivasti ensimmäiseen metroon. Jatkoyhteyttä metrosta eteenpäin voidaan kuitenkin odottaa kymmeniä minuutteja. Syy on Dijkstran algoritmin toiminnassa: jokaiseen pisteeseen on vain yksi lyhin reitti ja kaikkien saman pisteen kautta kulkevien reittien alkuosa on sama. Reitityksessä voi kuitenkin olla sellainen tilanne, että esim. Leppävaaraan pääsee nopeimmin seuraavalla bussilla 106, mutta olisi parempi odotella kotona pidempään ja ottaa bussi 110 joka saapuu Leppävaaraan myöhemmin, mutta jatkoyhteyttä odotellaan vähemmän aikaa. Reitittimen käyttämä algoritmi optimoi kokonaismatka-aikaa (total_route_time, joka huomioi toivotun lähtöajan eikä varsinaista lähtöaikaa ja sisältää näin ollen odotusajan lähtöpisteessä), mutta useimmiten on merkityksellisempää saada tietoon optimaalinen matka-aika, jossa on mukana pelkkä joukkoliikennereittiin käytetty aika (route_time). Tästä johtuen Reitittimellä kannattaa tehdä hakuja useilla lähtöajoilla (eli ns. haarukoida lähtöaikoja), minkä jälkeen minimin laskennalla saadaan optimoitua route_time. Tulostiedostossa total_route_time on on kaikkien näiden hakujen total_route_timen keskiarvo. Muut sarakkeet perustuvat haarukoinnin perusteella lyhimmän route_time:n arvoihin. Kaikkein optimaalisin haarukointitiheys saadaan käyttämällä Golombin viivoitin tekniikka (Golomb Ruler, 2014)

18 8.2 Huomioita kävelyreitityksestä Joillakin alueilla kävelyn reititykseen käytettävää OSM-aineistoa on jouduttu muokkaamaan erityisesti Reitittimen tarpeisiin. Alkuperäisessä OSM-aineistossa esimerkiksi Elielinaukion kävelyreitit mukailevat bussilaitureiden muotoa, eli tuloksena on epärealistisen mutkikas ja pitkä kävelyreitti. Näin ollen tiettyjä kohteita (aukioita, toreja, asemia) on muokattu niin, että reititys kulkisi mahdollisimman realistisesti. Näistä muokkauksista huolimatta OSM-aineisto saattaa edelleen sisältää kävelyreitityksen kannalta ongelmallisia alueita. Näistä johtuen kävelyjen osuus Reitittimen laskemissa joukkoliikennereiteissä on jonkin verran pidempi kuin HSL:n Reittioppaan reiteissä: Testiemme mukaan Reitittimen kävelyosuudet ovat ajassa mitattuna keskimäärin 24,1 % (2,1 minuuttia) pidempiä ja pituudessa mitattuna keskimäärin 12.8 % (58.1 metriä) pidempiä kuin Reittioppaan vastaavat kävelyosuudet. Nämä OSM-aineiston ongelmakohdista johtuvat erot korostuvat nimenomaan osana joukkoliikennereittejä, mutta eivät juurikaan vaikuta reitteihin, joissa joukkoliikennettä ei käytetä. Jos haetaan reitti pisteestä itseensä, reitti saa tulostiedostossa pituuden ja ajan (vaikka loogisesti molempien pitäisi olla 0). Laskenta käy nyt lähimmässä risteyksessä joka on merkittävä pysäkille siirtymisen kannalta. Matka ei ole yleensä kovin pitkä, joten sen vaikutukset matka-aikoihin eivät ole suuret. 8.3 Hakupisteet keskellä ei mitään Reititin hakee ensin jokaiselle annetulle lähtöpisteelle lähimmän tieverkossa olevan pisteen josta pääsee eteenpäin ja kävelee linnuntietä sinne. Sallittua maksimietäisyyttä linnuntiemittaukselle voi säätää conftiedoston parametrilla snapdist. Oletusarvo on 200 metriä. Datassa ei ole tietoa vesialueista. 9 Kirjallisuutta Golob Ruler (2014). < Helsingin kaupunkisuunnitteluvirasto (2012). Arjen saavutettavuus pääkaupunkiseudulla: Makrotaso. Helsingin kaupunkisuunnitteluviraston yleissuunnitteluosaston selvityksiä 2012:6. Jäppinen, S., Toivonen, T. & Salonen, M. (2013) Modelling the potential effect of shared bicycles on public transport travel times in Greater Helsinki: An open data approach, Applied Geography 43: Järvi, J., Salonen, M., Saarsalmi, P., Tenkanen, H. & Toivonen, T. (2014). Reititin: an open source tool for analysing accessibility by public transport in Greater Helsinki. On a book: Jolma, A., Sarkola, P. & Lehto, L. (eds.) Proceedings of the 3rd Open Source Geospatial Research & Education Symposium OGRS Aalto University publication series, Science + Technology, 5: Lahtinen, J., Salonen, M. & Toivonen, T. (2013) Facility allocation strategies and the sustainability of service delivery: Modelling library patronage patterns and their related CO2-emissions, Applied Geography 44: Reittiopas API (2014). < Salonen, M. & Toivonen, T. (2013) Modelling travel time in urban networks: comparable measures for private car and public transport, Journal of Transport Geography 31:

19 Salonen, M., Toivonen, T. & Vaattovaara, M. (2012) Arkiliikkumisen vaihtoehdoista monikeskuksistuvassa metropolissa: Kaksi näkökulmaa palvelujen saavutettavuuteen pääkaupunkiseudulla, Yhdyskuntasuunnittelu 2: Toivonen, T., Jaakkola, T. & Vuori, M. (2010) Solmukohta vai Pussinperä Kumpulan kampus pääkaupunkiseudun joukkoliikenneverkossa. Helsingin yliopiston maantieteen laitoksen julkaisuja B pp. Liite 1. Esimerkkicase: Länsimetron lisääminen joukkoliikenteen verkostoon Länsimetron rakentaminen muokkaa pääkaupunkiseudun sisäisiä saavutettavuusrakenteita ja sillä on vaikutusta monien yhteiskunnallisten toimintojen palveluverkkosuunnitteluun suoraan länsimetron yhteyteen kytkeytyvän uudisrakentamisen muodossa sekä pelkästään välillisesti ihmisten asiointimalleja muokaten. Kirjastoverkoston suunnittelu on esimerkki tilanteesta jossa yhdistyvät molemmat tekijät. Kirjastoverkosto on tyypillinen lähipalvelu jossa asiointimatkat ovat lyhyitä ja liikkumismuotoina kävely, pyöräily ja julkinen liikenne muodostavat selkeän enemmistön yksityisautoiluun nähden. Näistä syistä johtuen julkisen liikenteen palveluverkostossa tapahtuvien muutosten simulointi on ensiarvoisen tärkeää kun pyritään hahmottamaan Espoon sisäisissä asiointivirroissa tapahtuvia muutoksia. Reitittimellä muodostettiin ensin nykyisen julkisen liikenteen palveluverkoston mukainen asiointimatriisi jota käytettiin onnistuneesti kuvaamaan kirjastoverkoston nykyiset asiointivirrat. Nykytilanteen kalibroinnin jälkeen verkoston toimipisteet ja saavutettavuusmatriisi mukautettiin vastaamaan Länsimetron 1 ja 2 vaiheen tilanteita. Liityntäliikenne huomioitiin sillä laajuudella kuin siitä oli tekohetkellä tietoa saatavilla. Reitittimen mukauttaminen tehtiin digitoimalla Länsimetro paikkatietoaineistoksi dokumentissa kuvatulla menettelyllä. Liityntäliikenne huomioitiin SeutuCD- aineiston bussilinjojen tietojen avulla. Länsiväylää pitkin Helsinkiin kulkevat linjat mukautettiin alkamaan tai päättymään lähimmälle soveltuvalle Länsimetron asemalle. Näin voitiin menetellä, koska tällöin useimmille läntisen Espoon linjoille 1 vaiheen Liityntäasemaksi muodostui Matinkylä ja itäisen Espoon alueella Tapiola. Mukautus tehtiin pysäkkitietojen avulla. Aineisto sisälsi pysäkkien järjestysnumerot joiden perusteella pysäkkien reititysjärjestys pystyttiin huomioimaan sen mukaan oliko metroasema linjan alku- vai pääteasema. Järjestyksen selvittyä linjasto reititettiin MetropAccess-hankkeessa aiemmin muodostetun impedanssimuokatun tieverkon avulla. Reitityksen asetuksissa huomioitiin reitittimen vaatimus uusien reittien eheästä topologiasta. Lopuksi täydennettyjen reittien ominaistietotaulun rakenne muokattiin vastaamaan reitittimen vaatimaa struktuuria ja yhdistettiin länsimetron soveltuvan vaiheen kanssa samaan tiedostoon. Tuloksena saatiin simulaatio Espoon alueella tapahtuvista kirjastoverkoston saavutettavuuden muutoksista Länsimetron 1 ja 2 vaiheen aikana nykytilanteeseen nähden. 19

20 Kirjastoverkoston saavutettavuus nykyisillä julkisen liikenteen ja kirjastotoimen palveluverkostoilla. 20

21 Kirjastoverkoston saavutettavuus Länsimetron 1 vaiheen julkisen liikenteen verkostolla ja mahdollisella kirjastotoimen palveluverkostoilla. 21