Vuoden ensimmäisen kehittäjätapaamisen teema tuli yhteisön toiveesta, ja tapaamisessa sukellettiin joukkoliikennedatan konepellin alle teknisiin yksityiskohtiin. Kysyimme tapahtumaa suunnitellessamme osallistujien toiveita tapaamiselle, ja ne olivat selkeät: katsaus Digitransitiin, joukkoliikennedatan standardeihin ja HSL:n avoimeen ohjelmistokehitykseen kiinnostivat. HRI Loves Developers: HSL:n digikehityksen tuoreimmat kuulumiset -etätapaaminen keräsi linjoille n. 40 osallistujaa maaliskuun 2022 lopussa. Tapaamisesta tehtiin tallenne.

Helsingin seudun liikenteellä (HSL) on pitkä historia datan avaamisen parissa: ensimmäinen avoin rajapinta joukkoliikenteen aikataulutietoihin ja linjoihin julkaistiin vuonna 2010 innokkaiden sovelluskehittäjien toiveesta. Nykypäivänä HSL tarjoaa runsaasti avointa dataa esimerkiksi joukkoliikenteen reiteistä, aikatauluista, ajoneuvojen sijainneista, liikennetiedotteista ja kaupunkipyörillä ajetuista matkoista. Avoimesta datasta viestitään etenkin Twitter-tilin @HSLdevcom kautta. Lisäksi organisaatiossa tehdään ohjelmistokehitystä avoimen lähdekoodin periaattein. Koodi julkaistaan pääasiassa Githubin kautta.

Digitransit on käytössä ympäri Suomen

Avointa ohjelmistokehitystä tehdään HSL:llä nykyisin pääosin konsulttien voimin. CGI:llä työskentelevä Vesa Meskanen kertoi tapaamisessa Digitransit-palvelualustan kehityksestä. HSL:n vuonna 2017 julkaistun uudistetun Reittioppaan lisäksi Digitransit on taustalla myös esimerkiksi Kuopion, Vaasan ja Lahden julkisen liikenteen reittioppaissa sekä käytössä myös muissa maissa, esimerkiksi Saksassa, Virossa, Italiassa ja Romaniassa. Palvelualusta kattaa varsinaisen loppukäyttäjälle suunnatun käyttöliittymän lisäksi mm.:

• reititysmoottori OpenTripPlannerin, joka yhdistelee aikataulutietoja ja etsii käyttäjälle sopivimman reitin eri kulkumuotoja yhdistellen
• osoitehakurajapinnan, jonka avulla voi etsiä osoitteille koordinaatteja tai koordinaateille osoitteita
• taustakarttarajapinnan, joka on lähinnä sisäisessä käytössä

Digitransit integroi laajasti erityyppisiä datalähteitä, ja kehitystä tehdään yhdessä monen toimijan kanssa myös kansainvälisesti, sillä kaikki lähdekoodi on avointa.

Tänä vuonna Digitransitin kehityssuunnitelmiin kuuluu mm. OpenTripPlannerin kehitys, joka parantaa huomattavasti reittihaun laatua. Tämän yhteydessä GraphQL-rajapinta tullaan uusimaan ja kuvaamaan. Lisäksi kutsuperustainen liikenne (esim. taksit) pyritään integroimaan alustaan ja liitttymäpysäköinnin mahdollisuuksia pyritään laajentamaan kansalliseen dataan. Nämä uudistukset parantavat etenkin haja-asutusalueiden asukkaiden matkojen suunnittelua ja reititystä.

Avointa kehitystä yhteistyössä

HSL:n Teemu Laaksonen kertoi tapahtumassa organisaation karttatuotannon palveluista sekä reittilokista. Laaksonen toimii palveluiden tuoteomistajana, ja kehitystä tehdään osin konsulttivoimin, osin talon sisällä. Karttatuotannon palvelut sisältävät taustakartat, juliste- ja painokarttatuotannon työkalut, kuljettaohjeen sekä linjakartan. Karttatuotannon palveluita hyödyntävät lähinnä HSL itse sekä liikennöitsijät, vaikka ne ovat jaossa myös avoimena lähdekoodina. Tiedossa on, että Julistegeneraattorin koodia ovat hyödyntäneet myös Turun ja Tampereen seutujen joukkoliikennepalvelut. Tavoitteena on jatkossa käydä tiiviimpää vuoropuhelua eri kaupunkien joukkoliikennepalveluiden kehittäjien kesken ja jakaa kunkin tekemiä muutoksia muiden käyttöön.

Laaksosen mukaan Reittilokin avulla HSL seuraa sitä, kuinka hyvin liikennöitsijät “pysyvät aikataulussa” liikkumispalveluita tuottaessaan. Palvelussa visualisoidaan ajoneuvojen tuottamaa reaaliaikaista dataa, joka on HFP-muodossa. Reittilokista selviää mm. ajoneuvon sijainnit, linjojen ajantasaisuus, pysäkeille lähtö- ja saapumisajat sekä liikennevaloetuustapahtumat. Reittiloki on käytössä sekä HSL:llä että liikennöitsijöillä, joille palvelusta on tehty oma, kirjautumisen takana oleva versio. Suuri osa palvelun sisällöstä on kuitenkin kaikille avointa. Palvelussa dataa voi tutkia alueellisesti, pysäkkikohtaisesti ja linjoittain.

HSL:n Ossi Berg kertoi tapaamisessa organisaation sisäisestä tietojärjestelmästä Joukkoliikennerekisteristä, eli tuttavallisemmin Joresta. Palvelu on muun muassa reittien, aikataulujen, pysäkkien sekä liikennöintisopimusten perusvarasto ja siinä käsitellään lähtökohtaisesti vain suunnittelutietoa. Joressa esimerkiksi piirretään reitit ja sinne ladataan aikataulut suunnitteluohjelmasta. Jore on ollut käytössä 1990-luvulta lähtien. Vanhaa järjestelmää uusitaan tällä hetkellä paremmin nykypäivän vaatimuksia vastaavaksi konsulttitiimin voimin. Avoimeksi dataksi Joresta päätyvät tiedot reiteistä ja aikatauluista. Lisäksi Joren lähdekoodi on avoimesti jaossa.

HSL myös hyödyntää muiden tuottamaa avointa dataa

HSL:n Markku Huotari kertoi tapaamisessa organisaation tavasta käyttää OpenStreetMapia (OSM), ilmaista ja avointa maailmanlaajuista kartta-aineistoa. OSM otettiin käyttöön HSL:llä Reittioppaan uudistuksen yhteydessä, ja vuonna 2018 julkaistiin HSL:n uudet, OSM:iin perustuvat taustakartat. Yhtenäisen karttatyylin pohjalla on vektoridataa ja se toimii useilla mittakaavoilla. Karttatyyli on avoimesti jaossa ja sen teknistä toteutusta uudistettiin vuoden 2022 alussa.

OSM:ia käytetään HSL:ssä taustakartoilla, reittioppaan kohdehauissa sekä reitityksessä. HSL käyttää OpenStreetMapia useasta syystä. OSM on pitkälti valmis kartta-aineisto, jonka tietomalli on laaja ja kattava: aineisto sisältää perinteisten kohteiden lisäksi esimerkiksi portaita ja hissejä. Lisäksi kartta-aineisto on nopeasti päivitettävä, sitä päivittää laaja yhteisö ja kartan kansainvälisyys tarjoaa käyttöön runsaan työkalupakin. Nopea päivitettävyys ja laaja käyttäjäyhteisö voivat tuoda kuitenkin mukanaan lieveilmiöitä, joissa kohteiden nimiä muokataan virallisten nimien vastaisiksi. HSL:llä on suunnitelmissa kehittää OSM-datan validointia mahdollisten häirintätapausten estämiseksi. Huotari näkee kuitenkin vaikuttavampana toimena OSM:in käyttäjäyhteisön ohjeistamisen ja yhteisön kanssa käytävän tiiviin keskustelun.

API-hallinnalla kestävää avoimen datan toimintaa

HSL:n avoimet rajapinnat ovat tällä hetkellä täysin avoimia, eli kuka tahansa voi vapaasti tehdä rajapintoihin kyselyitä. Tämä on kuitenkin paikoittain johtanut rajapintojen suureen kuormitukseen, sillä vialliset kyselyt voivat rasittaa rajapintaa kohtuuttomasti, vaikka kyselijä ei olisi tehnyt virhettä tarkoituksellisesti. Toistaiseksi suurta kuormitusta on pyritty suitsimaan kyselyjen validoinnilla tai suodattamisella HSL:n päässä. Suunnitteilla on kuitenkin suurempi muutos, eli API-hallinnan käyttöönotto.

HSL:n Jarmo Korkeamäen mukaan API-hallinnan käyttöönotto tehdään Digitransitin tarpeista lähtien ja sillä tavoitellaan operatiivista kestävyyttä sekä tietoturvanäkökulman huomioimista. Rajapintojen hallintamallin avulla voitaisiin paremmin puuttua virheellisiin kyselyihin ja niiden kuormitukseen, mikä parantaisi rajapinnan toimivuutta kaikille. HSL tarjoaa jatkossakin avointa dataa rajapintojen kautta, ja API-hallinta mahdollistaisi myös palvelutasolupauksen (SLA) tarjoamisen.

Rajapintojen käyttäjän näkökulmasta API-hallinta merkitsee kirjautumisen paluuta. Hallintaa tullaan harjoittelemaan alkuun pienemmällä käyttäjäjoukolla.

“Voimme säätää tuotantoa vastaamaan odotuksia: optimoida datan luotettavuutta, saatavuutta, ja niin edelleen. Parhaimmillaan tätä tehdään dialogissa käyttäjien kanssa”, toivoo Korkeamäki.

Tapaamisen osallistujia mietitytti, mitä kirjautuminen tarkoittaa esim. HSL:n aineistoja paikkatieto-ohjelmisto QGIS:in kautta käyttäville. Käyttöesimerkki otettiin mielenkiinnolla HSL:ssä vastaan ja se lisättiin selvitettävien asioiden listaan.

Standardit helpottavat joukkoliikenteen datojen yhteentoimivuutta

Joukkoliikennetoimijoita on jo Suomessa paljon, puhumattakaan muista maista. Joukkoliikenteen järjestäminen on myös dataintensiivistä: bussit ja junat kulkevat jatkuvalla syötöllä, jolloin niiden reiteistä, aikatauluista ja sijainneista syntyy jatkuvasti uutta dataa. Jotta dataa voitaisiin hyödyntää mahdollisimman tehokkaasti monista lähteistä eri tarkoituksiin, tarvitaan standardisointia. HSL:n Ossi Bergin mukaan joukkoliikenteen standardit ovat rakentuneet kahta polkua: joko suunnitteluohjelmistojen tai loppukäyttäjäpalvelujen kautta. Erityisen pitkällä standardisointi on reittien ja aikataulujen kuvauksessa, sillä alalla on paljon kilpailua.

Joukkoliikennedataa jäsennellään etenkin kahden päästandardiperheen mukaan: EU-standardi Transmodelin lähtökohtana on joukkoliikenteen suunnitteluohjelmistot, kun taas alun perin Googlen kehittämän GTFS-standardin kehitys lähti kartta- ja reitityspalvelujen käyttäjien tarpeesta. Teknisesti Transmodelin mukaista dataa julkaistaan NeTEx-siirtoformaatissa, joka on käytännössä XML-tekstitiedosto. GTFS-data on käytännössä puolestaan kokoelma pakattuja CSV-tiedostoja. Transmodel-standardi on kattava ja laaja formaatti, jonka avulla voi kuvata reittien ja aikataulujen lisäksi tietoja infrastruktuurista (esim. varikoista) ja operoinnin yksityiskohdista. Markkinalähtöisesti kehitetty GTFS on tietosisällöltään hieman suppeampi esim. pysäkkien kuvauksessa, mutta kattava kuvaamaan reittejä ja aikatauluja. GTFS-syötettä tarjoavatkin erittäin monet joukkoliikenteen toimijat.

Dataa on mahdollista muuntaa Transmodelista GTFS:ään tai toisin päin. Myös HSL on tehnyt työkaluja muuntamiseen. Ongelmana on kuitenkin se, että datamuunnoksen myötä osa informaatiosta saattaa kadota. Lisäksi vaikka data noudattaisi periaatteessa standardia, voi se olla niin huonosti tehtyä, että muuntaminen formaatista toiseen vain syventää ongelmia.

Nykypäivän joukkoliikenne kattaa perinteisten joukkoliikennevälineiden lisäksi myös kevyen liikenteen välineitä, kuten kaupunkipyöriä tai kaupallisten toimijoiden tarjoamia sähköpotkulautoja. Näiden jaettavien kulkuvälineiden datan standardiksi on muodostunut GBFS. Joukkoliikennettä täydentävällä taksialalla puolestaan ei ole vielä yhtä selkeää, laajasti käytettyä standardia, eikä avointa dataakaan vielä laajasti jaella. Myös lipunmyyntipuolella standardisointi on lapsenkengissä.

Dataa joukkoliikenteen matkustajamääristä kysytään usein

Tapaamisen eniten keskustelua herättänyt teema oli joukkoliikenteen matkustajamäärät, niiden kerääminen ja keräämisen haasteet. Dataa nousijamääristä kysytään HSL:tä sekä meiltä HRI:ltä aika ajoin. Datan keräämisestä on tehty vuosien saatossa kokeiluja ja sitä on julkaistukin avoimena datana, jota ei ole kuitenkaan päivitetty vuoden 2016 jälkeen. Suomenlinnan lauttojen käyttömääristä on kuitenkin saatavilla dataa HSL:n Louhin-palvelun kautta.

Aiheesta kertoneen HSL:n Taneli Niemen mukaan haasteena nousijamäärätietojen keräämiselle on HSL:n toimintaympäristön monimutkaisuus. Pääkaupunkiseudun joukkoliikenne toimii usean eri kulkuvälineen voimin, kaluston ikä vaihtelee ja liikennöitsijöiden kanssa tehdyissä sopimuksissa on eriäviä velvoitteita ja sopimukset ikääntyvät eriaikaisesti. Lisäksi suuri osa matkustajista käyttää nykyään mobiililippua, jota ei leimata kulkuvälineeseen noustessa. Tällöin leimauslaitteiden laskennasta jää puuttumaan osa matkustajista.

Tieto nousijamääristä on kuitenkin HSL:n perustoiminnan suunnittelun ja hankinnan kannalta niin keskeinen, että tarve tarkemmalle tiedolle on suuri. Organisaatiossa etsitään parhaillaan tapoja mitata matkustajamääriä luotettavasti, ensin omaan käyttöön ja tulevaisuudessa toivottavasti myös avoimen datan julkaisuun. Tietojen keräämisessä tulevat auttamaan ajan kuluminen ja uusien liikennöitsijäsopimusten teko. Esimerkiksi elokuusta 2021 eteenpäin tehdyissä bussien sopimuksissa edellytetään kamerateknologiaan pohjaavaa sensorijärjestelmää, jonka avulla matkustajien määrää voidaan laskea. Lisäksi organisaatiossa luotetaan koneoppimisen ja tekoälyn mahdollisuuksien soveltamisen sekä tilipohjaisen lippu-uudistuksen (tieto matkustusoikeudesta tallentuu sovelluksen sijaan käyttäjätilin taustajärjestelmään) tuovan uusia eväitä nousijamäärien arviointiin.

Tapaamisen osallistujilla oli runsaasti ideoita nousijamäärädatan keräykseen. Yhtenä mahdollisena teknologiana ehdotettiin hahmontunnistusta kamerateknologian avulla sekä puhelinten määrän tunnistusta ihmisten määrän indikaattorina. Mielikuvituksellinen, mutta matemaattinen lähestysmistapa pulmaan oli myös ehdotus matkustajien määrän arvioinnista bussin kiihtyvyyden perusteella: puolillaan tai täynnä oleva bussi kiihtyy hitaammin kuin tyhjä, ja kokonaispainolastin arvioimalla paino voitaisiin jakaa keskimääräisen ihmisen painolla karkean arvion saamiseksi. HSL reagoi kehittäjätapaamisen keskusteluun rivakasti ja julkaisi jo koemielessä dataa muutamien bussien täyttöasteesta GTFS-RT-feedissä.

Nousijamäärät ja yhteentoimivuus puhututtivat

Kehittäjätapaamisen lopuksi työpajailtiin totuttuun tapaan. Linjoille jäi vielä noin 20 innokasta keskustelijaa. Jakauduimme kahteen etähuoneeseen keskustelemaan puheenvuoroista heränneistä ajatuksista sekä täyttämään keskustelun tueksi laadittua Flinga-pohjaa. Osallistujien antama palaute on edelleen nähtävissä Flingassa.

Toisessa ryhmässä jatkettiin keskustelua joukkoliikenteen matkustajamääristä ja ideoitiin sitä, millä tavoin nousijamäärätietoja olisi mahdollista lähteä avaamaan. Viimeaikainen esimerkki joukkoliikenteen matkustajamäärätietojen avaamisesta löytyy Turun seudun joukkoliikennetoimija Föliltä: se avasi dataa päivittäisistä, linjakohtaisista matkustajamääristä pysäkeittäin vuoden 2021 loppupuolella. Dataa kerätään rahastuslaitejärjestelmän leimauksista. Turun seudun joukkoliikennevälineitä ovat tällä hetkellä bussit, joihin noustessaan matkustaja maksaa lippunsa leimaamalla tai esittää aikaisemmin ostetun lippunsa laitteelle.

Toisessa ryhmässä puolestaan pyrittiin ratkomaan erään osallistujan kinkkistä ongelmaa: hän on rakentanut joukkoliikenteen seurantasovelluksen (Bussitutka.fi) pks-seudun joukkoliikennedatalle ja haluaisi laajentaa palveluaan muualle Suomeen, esimerkiksi Turun ja Tampereen alueelle. Samat datat tarjotaan kuitenkin rajapinnoissa niin eri rakenteella, että palvelun skaalaaminen toisaalle vaatisi paljon työtä. HSL:läiset tunnistivat ongelman ja pohtivat, miten jatkossa datojen yhdenmukaisuutta voitaisiin parantaa Suomen sisällä.