Helsingin kaupungin kokeilukiihdyttämö on kaikille Helsingin työntekijöille tarkoitettu tukipalvelu, jossa järjestetään säännöllisesti ketteriä kokeiluja uusista digitalisaatiota hyödyntävistä ideoista ja ratkaisuista. Talvella 2021-2022 kokeilukiihdyttämön teemana oli data-analytiikka ja paikkatieto. Toki me gispolaiset osallistuimme innolla kampanjaan tavoitteenamme selvittää, mihin tämänhetkisiin ongelmiin avoimen lähdekoodin ratkaisut parhaiten sopisivat ja miten niitä voitaisiin tällä kertaa hyödyntää.

Kaikki kokeiluteemaan osallistuvat kaupungin työntekijät olivat asiaankuuluvan innostuneita omista ideoistaan ja teknologian mahdollisuuksista niiden toteuttamiseen. Myös useita innokkaita yrityksiä oli mukana tukemassa ja kehittelemässä ideoita eteenpäin. Muutaman alkutyöpajan kuluessa Gispon kiinnostuksen kohteeksi valikoituivat erityisesti ehdotukset ”avustushakemusten paikkatieto” sekä ”kaupunkilaisten kehitysideat kartalle” – näistä teemoista meille syntyi heti keskustelun aikana ideoita tai ajatuksia toteutuksen tueksi.

”Kaupunkilaisten kehitysideat kartalle” oli Kaupunkiympäristön toimialalla suorasta tarpeesta syntynyt teema. Helsingin kaupunki tekee jatkuvasti koko kaupungin alueella Yleisten alueiden suunnittelua eli katujen, puistojen ja muiden julkisten alueiden rakentamista, kehittämistä ja kunnossapitoa. Lisäksi suurpiireittäin kaupunki uusii tietyin aikavälein koko yleisten alueiden suunnitelman eli sen, mitä missäkin kaupunginosassa ja milläkin alueella aiotaan tulevaisuudessa tehdä ja mihin investoinneissa keskitytään.

Tiedolla johtamisen kannalta olisi siis ensiarvoisen tärkeää saada katujen, puistojen ja muiden tilojen suunnitteluun mahdollisimman aikaisessa vaiheessa mahdollisimman paljon palautetta ja dataa kaupungin tämänhetkisestä tilasta: kaupunkilaisten kehitysehdotuksista, ideoista, palautteesta ja myös epäkohdista kullakin alueella. Tällaisen tiedon erilliseen keräämiseen kaupungilla on monia kanavia, kuten Kerro kantasi -palvelu projektikohtaiseen palautekyselyyn sekä Eharava-karttakyselyitä karttapohjaiseen palautteen keräämiseen.

Avoin data apuun

Kaupungin jatkuvassa toiminnassa kuitenkin kertyy paljon muutakin hyödynnettävää dataa. Yksi lupaavimmista aineistoista muodostavat Helsingin kaupungin palautejärjestelmän julkiset palautteet, joita kertyy päivittäin kaupungilla useita kanavia pitkin. Palautteet ohjataan kaupungin sisällä oikealle taholle, niihin vastataan ja ne usein johtavat toimenpiteisiin, mutta kaikilla suunnittelijoilla ei ole kattavaa näkymää siihen, millaista palautetta miltäkin alueelta on pitkällä aikavälillä tullut.

Hyvä puoli palautedatassa on se, että julkaistavaksi hyväksytty, ei-henkilötietoja sisältävä palaute on listattu avoimen datan lisenssillä HRI-palvelussa, ja viimeisen vuoden ajalta palaute on ladattavissa suoraan kaupungin avoimesta rajapinnasta. Data on gispolaisille muutenkin tutun Open311-standardin mukaisessa muodossa.

Avoimia kysymyksiä tästä suuresta datasetistä oli alkujaan kolme:

1) onko data sijoitettavissa kartalle niin, että siitä voi muodostaa kaupungin työntekijöille havainnollisia karttoja palautetihentymineen,

2) onko data luokiteltu järkevästi niin, että siitä voi suodattaa erityyppisiä palautteita, ja

3) onko datan tekstimassaa mahdollista analysoida niin, että tekstin perusteella luodaan luokittelu palautteille ja helpotetaan niiden selailua kartalla?

Onko data sijoitettavissa kartalle?

Tähän kysymykseen on puhtaan paikkatietoasiantuntijan mielestä vain kaksi mahdollista vastausta: kyllä, jos datassa on valmiina koordinaatit, muussa tapauksessa ei.

Pelkällä paikkatiedolla pääseekin myös Helsingin kaupungin palautedatan tapauksessa pitkälle. Merkittävässä osassa olemassaolevista palautteista on mukana jollakin tarkkuudella kartalle merkitty karttapiste, jota käyttäjä on palautelomakkeessa klikannut palautetta jättäessään. Jo yksistään kaikkien näiden pisteiden laittaminen kartalle kaupungin työntekijöiden selailtavaksi oli siis yksi tavoitteista.

Lisäksi palautedatassa oli kuitenkin merkittävä määrä palautteita, joihin koordinaatteja ei ollut merkitty. Nämä kommentit olisi voitu poistaa analyysistä, mutta toinen vaihtoehto on verrata palautetekstiä Helsingin kaupungin nimistöön – avoimen datan aineistoon, jossa ovat kaikki kaupungin puistojen, katujen, kaupunginosien, aukioiden ja muiden tunnettujen paikkojen nimet sijainteineen.

Nimistöanalyysiä olisi voinut jatkaa pidemmällekin, mutta tässä kokeilussa riitti, että palautetekstistä tunnistetaan jokin paikannimi, ja merkittiin palautteelle tätä paikannimeä vastaavat koordinaatit. Palautteille tulee tällä tavalla väistämättä puutteellisia (jos palautteessa puhutaan useammasta paikasta) tai epätarkkoja (jos palautteessa puhutaan koko kaupunginosasta, ja palaute merkitään kaupunginosan geometriseen keskipisteeseen) koordinaatteja, mutta nimistöntunnistuksella myös tämä palauteaineisto saadaan edes jollakin tavalla kartalle selattavaksi ja ihmissilmin tulkittavaksi. Nimien taivutusmuotojen tunnistuksesta puhumme alempana.

Onko data luokiteltu järkevästi?

Tutkimuksen jälkeen lyhyt vastaus tähän on: meidän kannaltamme ei. Data on luokiteltu käytännöllisesti, eli Helsingin kaupungin palauteluokitus perustuu siihen, että palaute saa alussa tietyn palvelukoodin sen mukaan, mille toimialalle palaute kuuluu, ja tarkempia palvelukoodeja sen mukaan, mikä toimialan palvelukokonaisuus, alipalvelu ja niin edelleen ottaa asian hoitaakseen tai mille instanssille palautteen katsotaan milloinkin kuuluvan.

Näitä luokituksia voi lisätä palautteelle useita, ja ne voivat muuttua sen mukaan, kun uusia palautetyyppejä ja ilmiöitä tulee vastaan. Tarkoituksena on siis ollut ohjata palautteen etenemistä sen käsittelijätahon sisällä. Kaiken kaikkiaan neljän vuoden aikana tällä tavalla on syntynyt 452 erilaista julkiselle palautteelle merkittyä luokkaa. Erilaisia luokituksia on merkitty hyvin eri tarkkuudella, ja osa luokista on teemoiltaan ja nimiltään hyvinkin päällekkäisiä sen mukaan, mikä käsittelijätaho on palautetta käsitellyt.

Syntyneen luokittelun läpikäyminen ei kaupungin työntekijöiltä eikä myöskään gispolaiselta käy kädenkäänteessä. Luokituksen purkamisessa pitäisi tehdä todella paljon yhdistelyä ja tulkintaa. Myöskään kaikkia luokkia ei ole mielekästä piirtää 452 erilliselle kartalle.

Luokituksesta opimme kuitenkin sen, kuinka luokittelulla voi olla datan eri käyttövaiheissa aivan erilaisia tehtäviä. Mikäli dynaaminen luokittelu on tehty nimenomaan ohjaamaan palautteen käsittelyä ja toimintaa, se toimii sellaisena erinomaisesti ja kertoo palautteen käsittelystä, mutta sitä ei voi käyttää myöhempään analyysiin. Jos kaupungin tulevasta uudesta palautejärjestelmästä halutaan automaattisemmin suuria datamassoja päätöksenteon tueksi, luokittelun jäsentelyyn pitää kiinnittää aivan eri tavalla huomiota. Vanhan palautejärjestelmän suunnittelun aikana tiedollajohtamisnäkökulma ei varmastikaan ole ollut esillä samalla tavalla kuin nykyisin.

Onko datan tekstimassaa mahdollista analysoida?

Tässä pääsemme analyysin vaikeimpaan kysymykseen. Voidaanko tekstistä saada irti tietoa palautteen teemasta tai mahdollisesti luokitella palautteita tekstin perusteella?

Tekstinlouhintaan on toki olemassa monenlaisia työkaluja sentimenttianalyysistä aina monimutkaisempiin koneoppimismalleihin. Yksinkertainen sentimenttianalyysi (tunnetilojen tunnistaminen tekstistä) ei aiempien kokemusten perusteella vaikuttanut hyödylliseltä tai lisäarvoa tuovalta. Monimutkaisemman tekoälymallin luominen tyhjästä ja kouluttaminen taas ei mahtunut pienen kokeiluprojektin sisään. Valmis luokittelutekoäly olisi esimerkiksi Kansalliskirjaston kehittämä avoimen lähdekoodin Annif, jota voi projektin nettisivuilla kuka tahansa kokeilla haluamallaan tekstiaineistolla. Tämä kuitenkin vaatisi jälleen olemassaolevaa luokittelua, tekstin luokittelua käsin, tekoälyn opettamista aineiston perusteella ja sen jälkeen luokittelun verifiointia ja testausta toisella aineistolla. Annifin valmis luokittelu perustuu Yleiseen suomalaiseen ontologiaan, eli opetettu tekoäly on tarkoitettu tekstimassojen, tekstityyppien ja tekstin teemojen luokitteluun kansalliskirjaston tarpeisiin. Palauteaineistolle tarvittavat luokat ovat hyvin spesifit ja toisaalta paljon suppeammat kuin yleinen tekstiontologia, ja kaupungin tarpeet ovat varsin erilaiset.

Näin ollen myös monimutkaisempi tekoälytoteutus jäi projektin ulkopuolelle. Päätimme edetä yksinkertaisen avainsanojen tunnistamisen kautta. Tämä on luonteva lähestymistapa siksi, että suuri osa palautemassasta koskee hyvin toistuvia ja tunnistettavia teemoja, jotka havaitsee helposti palautedataa lukiessa (mm. roskat, ilkivalta, rikkoontuneet tai kaatuneet kalusteet/opasteet, liikenneturvallisuus, kunnossapito, puuttuvat palvelut). Näiden teemojen ulkopuoliset palautteet voivat olla taas niin monisyisiä, että niiden luokittelu on ihmisälyllekin haastavaa. Toisaalta teksti voi olla niin lyhyt, että pelkästä tekstistä on hyvin vaikea tehdä tulkintaa palautteen aiheesta.

Avainsanojen listaaminen ja luokittelu edellyttää suomenkielisen sanan perusmuodon tunnistamista. Avoimen lähdekoodin ratkaisuja suomenkielisen tekstin jäsentämiseen on useitakin. Perusmuodon tunnistamisen lisäksi halusimme työkalun, jolla voidaan

1) helposti jäsentää ja tilastoida koko tekstimassa siinä esiintyvien sanojen perusteella,

2) jaotella tekstimassaa tarpeen mukaan kaupunginosittain ja tehdä erillisiä analyysejä eri alueiden palautteista, sekä

3) lisätä jokaiseen palautteeseen metatiedoiksi tekstianalyysin tuloksena tulkitut palautteen teemat tai kategoriat.

Tekninen ratkaisu

Tietyllä tavalla kaksi kärpästä yhdellä iskulla saadaan tässä tapauksessa käyttämällä Elasticsearchia. Se on avoimen lähdekoodin indeksointi- ja hakukone, johon myös suomenkielinen teksti on indeksoitavissa perusmuodoissaan käyttämällä Raudikko-nimistä suomen kielen morfologisen analyysin työkalua, josta on tehty valmiiksi myös avoin Elasticsearch-plugin. Tällä yhdistelmällä voidaan Elasticsearchiin tallentaa suoraan kaikki palautedokumentit, niitä voidaan hakea millä tahansa tekstissä esiintyvällä sanalla, ja tuloksista on mahdollista tehdä tilastoja vaikkapa eri sanojen esiintymisestä palauteaineistossa. Analyysin asennusohjeet löytyvät Githubista.

Elasticsearchin jälkeen ratkaisuun ei tarvitakaan oikeastaan muuta kuin Python ja paljon aikaa. Elasticsearchille on olemassa valmis Python-kirjasto, jolla indeksointi ja erilaiset haut ovat tehtävissä. Mukavin tapa tehdä Pythonilla analyysia ja tutustua dataan samalla kertaa on tietysti Jupyter Notebook, joka kannattaa asentaa omaan python-ympäristöön, asennusohjeet Githubissa.

Lopputuloksena projektista syntyi käytännössä vain yksi pitkä Python-notebook, joka on ohjeineen, oheistiedostoineen ja tuloksineen ladattavissa Githubista. Samassa osoitteessa ovat Elasticsearchin ja pluginin asennusohjeet Dockeria käyttäen. Käytännössä notebookilla tehty analyysi jakautuu moneen osaan, jossa osa analyysista voidaan tehdä suoraan Elasticsearchin avulla, ja osa tehdään Pythonilla Elasticsearch-tulosten perusteella. Notebookin vaiheet ovat seuraavat:

1. Palautedatan, palvelukoodien, paikannimien, kaupunginosien ja sanaluetteloiden lukeminen. Näistä vain ensimmäinen ja viimeinen ovat välttämättömiä. Palautedataa voidaan lukea joko avoimesta rajapinnasta (yhden vuoden palautteet) tai kaupungin tietokantadumpista (jos halutaan analysoida vanhempia palautteita). Sanaluettelot syntyivät vaiheissa 5-6 iteratiivisesti, mutta prosessin myötä syntyneet luokittelut ovat toki valmiina käytettävissä.
2. Kenttien siivoaminen ja datan indeksointi Elasticsearchiin.
3. Jos käytetään paikannimiaineistoa, puuttuvien koordinaattien lisääminen Elasticsearchin perusmuotoistamien paikannimien perusteella.
4. Tulosten lukeminen Elasticsearchista sanaluetteloineen.
5. Sanatiheyksien ja sanojen yleisyyksien hakeminen Elasticsearchista, jos halutaan tutkia tekstimassaa ja parantaa luokittelua edelleen.
6. Perusmuotojen ja niitä vastaavien kategorioiden tallentaminen jokaisen sanan kohdalle. Tässä vaiheessa voidaan tutkia, mitkä palautteet ovat saaneet mitäkin kategorioita esiintyvien sanojen perusteella, ja parantaa kategorialuokittelua lisäämällä tai poistamalla avainsanoja. Samassa vaiheessa voidaan tutkia palautteiden palvelukoodeja, jos kaupungilta on saatu tietokantadumppi palvelukoodien merkityksistä.
7. Aluesuodatus, jos halutaan käyttää kaupunginosia jakamaan palauteaineistoa pienempiin osiin ja tehdä paikallisia tilastoja. Elasticsearch tukee suoraan myös polygonilla rajattuja hakuja.
8. Datan tallennus QGIS-projektiin visualisointia varten. Valmis QGIS-projekti on myös ladattavissa Githubista, joten notebookia ei ole tarpeen ajaa, jos ei halua tehdä muutoksia analyysiin.

Miten luokittelu syntyi?

Käytännössä analyysissa saadaan valtava datamassa palautteiden sisältämiä sanoja. Loppu on käsityötä, tai lähinnä toistuvien teemojen havaitsemista ja lisäämistä tunnettujen sanojen listalle. Kategoria-aihiot (vaara, luonto, vesi, liikunta, valaistus, …) syntyivät toki Kaupunkiympäristön toimialan kiinnostuksen kohteiden mukaan, mutta kategorioita muuteltiin ja lisättiin sen mukaan, mitkä teemat toistuivat palautteissa ja voivat olla hyödyllisiä kartalla. Joillekin kategorioille avainsanat ovat ilmeisiä (”hengenvaara”, ”vaarallinen”), toisille avainsanojen löytäminen vaatii enemmän olemassaolevien palautteiden silmäilyä (”kaatua”, ”kaatunut” tarkoittaa useammin puuta tai liikennemerkkiä kuin ihmistä, samoin ”kuoppa”, ”kadonnut” tai ”nurin” liittyvät yleensä kunnossapitoon).

Tulostamalla palautteet, joista ei löydy mitään näistä avainsanoista, voidaan löytää uusia teemoja ja avainsanoja, joita ei ole vielä havaittu. Tällä tavalla luokittelua voidaan tarkentaa hyvinkin pitkään. Rajoituksena on kuitenkin se, että mitään tekoälyä ei ole käytetty – luokitus syntyy pelkästään esiintyvien sanojen perusteella. Tämä aiheuttaa väistämättä myös väärintulkintoja ja turhia luokituksia sitä enemmän, mitä suurempia sanaluetteloita tehdään. Jos palautteessa esiintyy sana ”puuttua”, onko kyseessä varmasti kunnossapito-ongelma (”jotakin puuttuu”), vai tulisiko palautteen antajan mielestä kaupungin puuttua johonkin muuhun ongelmaan?

Mikä oli lopputulos?

Projektin tuotoksena saatiin kaupungin työntekijälle valmis visualisaatio, jossa erityyppisiä palautteita on mahdollista suodattaa ja selailla karttanäkymässä. Tämä toteutettiin tallentamalla pisteet kaikkine kategorioineen suoraan Geopackage-tiedostoon, joka sisältää myös QGIS-visualisaation ja on ladattavissa Githubista.

Mitä seuraavaksi?

Analyysia on mahdollista jatkaa ja kehittää palautteen perusteella. Esimerkiksi tiettyjä toistuvia teemoja tai aiheita voi analysoida vielä tarkemmin. Toinen kehityssuunta olisi alueellinen analyysi: toistaiseksi tehtiin vain tilastoja siitä, mitkä sanat ja teemat toistuvat useimmiten missäkin kaupunginosissa, suurpiireissä ja osa-alueilla.

Pidemmällä aikavälillä olisi toki mahdollista tehdä olemassaolevan palautteen perusteella tekoäly, jota sitten voidaan testata toisella palauteaineistolla. Näin tulevaisuudessa olisi esimerkiksi mahdollista, että kaupungin tuleva palautejärjestelmä luokittelisi palautteen tekstin perusteella automaattisesti johonkin alustavaan kategoriaan, jota sitten ihmiskäsittelijä voisi korjata tai hienosäätää tarpeen mukaan. Toisaalta myös kevyemmillä ratkaisuilla päästään pitkälle, ja esimerkiksi jonkinlainen palautteen käsittelijän merkitsemä yleiskategoria voisi olla data-analyysin kannalta hyvinkin toimiva ratkaisu; tämä tekisi tekstianalyysin ehkä tarpeettomaksi.

Projektissa syntynyt koodi sekä analyysin tulokset katseltavissa ja ladattavissa Githubissa.

Riku Oja

Riku on nykyisin softakehittäjä, alunperin fyysikko ja tekniikan tohtori, joka tykkää oravista, kartoista, kaupungeista, paikkatietoanalyyseistä, avoimesta datasta ja avoimesta lähdekoodista. Parhaiten Riku hallitsee Python-, tietokanta- ja backend-projektit, AWS:n, verkkopalveluiden ja rajapintojen rakentelun sekä data-analyysit, mutta kaikki paikkatietoon liittyvä ilahduttaa.