Näin syntyi eduskuntavaalituloksen analyysijuttu

Teimme PlusDesk:ssä kevään eduskuntavaaleihin liittyen useampia juttuja.

Yksi niistä oli vaalitulosta analysoiva juttu "Kokeile, miltä vaalitulos näyttää, jos vain koulutetuimmat tai sairaimmat olisivat äänestäneet", jossa vaalitulosta katsottiin kunnittain viiden demografisen muuttujan kautta. Muuttujiksi olimme valinneet:

1. tulot
2. koulutus
3. työttömyys
4. eläkeläisten osuus
5. terveys

Niin sanotun 100 kuntaa -koneen lähteenä käytettiin Tilastokeskuksen Kuntien avainluvut -aineiston tunnuslukuja 1) valtionveronalaiset tulot, 2) korkea-asteen tutkinnon suorittaneiden osuus, 3) työttömyysaste sekä 4) eläkkeellä olevien osuus väestöstä. Tiedot väestöltään 5) terveimmistä ja sairaimmista kunnista perustuivat THL:n sairastavuusindeksiin.

Lukijan oli mahdollista valita näkyville viiden eri muuttujan ääriarvot. (Kuva 1)

Jutun idea oli, että valitulla muuttujalla vaalitulos laskettiin ottaen huomioon vain 100 kuntaa.

Esimerkiksi jos muuttujaksi valitaan "koulutus" vaalitulos lasketaan niin, että otettiin huomioon vain 100 vähiten tai korkeiden koulutetun kunnan äänet. Vastaavasti jos muuttujaksi valittiin "tulot" pystyi näkemään miten vaalitulos olisi rakentunut jos vain Suomen pieni- tai suurituloisimmat kunnat olisivat äänestäneet. Idea oli lainattu ulkomailta.

Ajatuksenamme oli hypoteesi siitä, että vasemmiston kannatus korostuisi pienituloisissa kunnissa kun taas porvaripuolueiden kannatus olisi huipussaan suurituloisissa kunnissa. Toki näin suoraviivaisesti ei voi ajatella, mutta kantava ajatus analyysissa oli tämänkaltainen. Eli, että puolueiden voimasuhteet ovat riippuvaisia ihmisten demografisista ominaisuuksista.

Äänestysdatat saimme Ylen vaalipalvelun rajapinnan kautta. Tiedot tulivat sieltä .json-formaatissa.

Kehityskaari

Ensimmäisessa vaiheessa toteutimme uutissovelluksen niin, että valitsemalla muuttujan näki vaalituloksen jakautumisen puolueittain pylväsdiagrammeina. Eli lopullisen toteutuksen sen osuuden, joka näkyy sovelluksen vasemmassa laidassa. Tämä oli oikeastaan vähimmäisvaatimus toimivalle sovellukselle. (Kuva 2)

Pylväsdiagrammit esittivät äänestystuloksen valitulla 100 kunnalla sekä verrattuna todelliseen äänestystulokseen, jotta vertailu olisi helppoa. (Kuva 2)

Nopeasti kuitenkin tajusimme, että olisi tuloksen lisäksi hyödyllistä nähdä mitkä nämä 100 kuntaa ovat joista vaalituloksen laskenta tapahtuu ja missä päin Suomea ne sijaitsevat. Näin lisäsimme pylväsdiagrammin rinnalle Suomen kuntakartan, jossa esitetään valitut 100 kuntaa korostevärillä. (Kuva 3)

Valitulla muuttujalla laskennassa käytetyt kunnat korostettiin sinisellä. (Kuva 3)

Pelkkä kuntien esittäminen kartalla tuntui kuitenkin nopeasti liian kapealta näkökulmalta ja tajusimme, että olisi kiva tietää myös äänestystulos yksittäisten kuntien osalta. Lisäsimme tämän aineiston selattavaksi kartalle niin, että osoittamalla kuntaa näki yksittäisen kunnan äänestystuloksen. (Kuva 4)

Osoittamalla näki miten kannatus jakautui puolueittain yksittäisessä kunnassa. (Kuva 4)

Huomiot

Teknisesti tuote siis eli koko kehitysprosessin ajan. Tämä on luontevaa nykyaikaisessa ketterässä ohjelmistokehityksessä. Uusia ominaisuuksia lisätään toimivan tuotteen ympärille kun tarve niille havaitaan. Tätä voidaan kutsua esimerkiksi prototypoinniksi.

Datajournalismin ja uutissovelluksen rakentamisessa tämänkaltainen ketterä kehittäminen on erityisen luontevaa ja tehokasta, koska tilanteet voivat muuttua nopeasti ja mahdollisuus niiden ennakoimiseen on rajallista.

Ei ole tarkoituksenmukaista etukäteen määritellä syvällisesti mitä ollaan tekemässä ja lyödä lukkoon projektin alkuvaiheessa mikä on lopullinen toteutustapa, koska ymmärrys jota näiden päätösten tekemiseen vaaditaan rakentuu vasta kun sovellusta aletaan tekemään.

Verkostovisualisointi gone wrong

Ensinnäkin täytyy kiittää ja onnitella Helsingin Sanomia ja Tuomas Peltomäkeä todella hienosta jutusta koskien eduskunnassa kuultavina olleita tahoja, joka perustui itse hankittuun dataan. Tämä on juuri sen kaltaista datajournalismia, jonka parissa toivoisin itsekin viettäväni enemmän aikaa. Tähän kuitenkin loppuvat tällä erää kiitokset sillä haluan keskittyä muutamaan epäkohtaan, jotka havaitsin jutun verkkoversion yhteydessä julkaistusta verkostovisualisoinnista.

Aluksi kuitenkin muutama huomio verkostoanalyysistä yleisesti.

Verkostoanalyysi on visualisointikeino, joka mahdollistaa ja jolla voidaan kuvata asioiden (solmu, node) välisiä yhteyksiä (edge, yhteys). Verkostoanalyysilla voidaan kuvata esimerkiksi Facebook:ssa olevien käyttäjien välisiä kaverisuhteita. Verkostoanalyysin avulla on siis mahdollista visualisoida millä tavalla Facebook-kaverini ovat kavereita keskenään. Kuvassa 1 nähtävästä verkostovisualisoinnista, jossa solmut ovat Facebook-kavereitani, voidaan lukea mm. että:

• Sukulaiseni ovat Facebook:ssa keskenään kavereita, mutta eivät juuri ole kavereita muiden kavereitteni kanssa.
• Muutamat yliopistokaverini ovat kavereita lapsuuden kavereitteni kanssa, mutta pääosin näiden ryhmien jäsenet ovat kavereita vain keskenään.
• Muutamilla minulle keskeisimmät ihmiset ovat kavereita kaikkien verkostossa nähtävien pääryhmien kanssa.

Parhaimmillaan verkostovisualisointi on erittäin tehokastyökalu asioiden välisten yhteyksien ymmärtämisessä. (Kuva 1)

Verkostovisualisointeja on karkeasti mahdollista manipuloida kolmella eri tavalla, jotka ovat:

• Ladonta-algoritmi
• Solmun koko
• Yhteyden voimakkuus

Mahdollisia ladontatapoja ovat mm. paino-ohjattuladonta kuten Force Atlas ja spatiaalinen ladonta, joka voi perustua esimerkiksi geokoordinaatteihin. Solmun koko taas voidaan määritellä esimerkiksi solmuun tulevien yhteyksien määrällä tai se voidaan esimerkiksi määrittää asukasluvun perusteella jos yksittäisen solmu kuvaa valtiota. Solmujen välinen yhteys voi olla joko nolla, yksi tai jokin lukuarvo. Eli toisin sanoen joko yhteyttä ei ole, yhteys on olemassa tai sitten yhteydellä on jokin arvo, joka kuvaa yhteyden voimakkuutta suhteessa muihin yhteyksiin. Yhteys voidaan määritellä myös suunnattuna tai suuntaamattomana.

Esimerkiksi edellisessä Facebook-esimerkissä yhteys on suuntaamaton, koska yksisuuntaiset kaveruussuhteet eivät ole Facebook:ssa mahdollisia (ainakaan teknisessä mielessä). Twitter-seuraajia visualisoitaessa yhteydet taas ovat suunnattuja, koska Twitter:ssä käyttäjän ei tarvitse seurata toista, jotta toinen voi seurata häntä.

Mikä sitten meni vikaan Helsingin Sanomien julkaisemassa verkostovisualisoinnissa. Se, että se ei noudattanut verkostovisualisointien lainalaisuuksia vaan siinä oli tehty visualisointiteknisiä ratkaisuja graafisin perustein. Minulle verkostoanalyysia ja verkostovisualointeja tehneenä tämä tarkoittaa samaa kuin, että pylväsdiagrammista leikattaisiin pala pois, jotta visualisoinnista saataisiin graafisesti miellyttävämmän näköinen tai paremmin luettava. Kuvassa 2 nähdään erittäin banaali esimerkki pylväsdiagrammista, joka on visualisointiteknisesti pielessä, koska arvon 900 omaavan pylvään tulisi olla korkeampi kuin arvon 700 omaava pylväs.

Pylväsdiagrammissa pylvään korkeuden mielletään kuvaavaan asian suuruutta eikä kyseisen kaltainen pylväiden esitystapa ole siten luonnollinen. (Kuva 2)

Facebook:n Finnish Open Data Ecosystem ryhmässä keskusteltiin kyseessä olevasta Helsingin Sanomien jutusta ja sen yhteydessä käytetystä datasta sekä tehdystä visualisoinnista. Toivomuksena keskustelussa oli, että kerätty data pistettäisiin avoimesti jakoon. Peltomäki ei ollut kuitenkaan valmis suoraan valmis jakamaan dataa vaikka toteutus olikin julkaistu CC-lisenssillä.

Käydystä keskustelusta innostuneena päätin kaivaa datan suoraan toteutuksesta, jotta halukkaat voisivat sitä käyttää. Kaivoin siis verkostovisualisoinnissa käytetyn datan suoraan toteutuksen lähdekoodin uumenista. Toteutuksessa käytetty data oli .json-formaatissa, joka oli toteutuksessa käytetyn Sigma.js:n käyttämä formaatti ja jotta datalle oli mahdollista tehdä mitään järkevää jatkojalostusta oli se siis muunnettava johonkin toiseen formaattiin.

Itselleni luontevin tavoitetila oli .gexf-formaatti, koska tällöin data oli mahdollista avata Gephi-verkostovisualisointityökalussa. "Reverse engineerasin" datan siis verkostoformaattiin, jossa itseasiassa luulen datan alunperinkin olleen ennen sen muuntamista .json-formaattiin, koska itse toteutus näytti hyvin paljon Gephi:n Sigma.js-lisäosalla toteutetulta. Sinällään molemmat tiedostomuodot (.json ja .gexf) ovat muodoltaan hyvin rakenteisia ja kuvaavat erikseen solmut ja erikseen niiden väliset yhteydet, joten muuntaminen onnistui käytännössä muutaman etsi-korvaa komennon avulla.

Avattuani muuntamani datan (.gexf) Gephi:ssä minua alkoi kuitenkin ihmetyttämään miten en saanut aikaan samankaltaista lopputulosta kuin se, joka oli nähtävissä Helsingin Sanomien toteutuksessa. Tutkittuani numeroita tarkemmin huomasin, ettei toteutuksessa olleet visuaaliset komponentit kuten solmujen koko määräytynytkään niin kuin olin ajatellut. Oletin, että solmun koko olisi määräytynyt kuulemiskertojen mukaan ja juteltuani kollegoitteni kanssa oli tämä ollut myös heidän tulkintansa visualisoinnista.

Jutussa mainittiin, että Elinkeinoelämän keskusliittoa oli kuultu useimmin, yhteensä 1 761 kertaa. Alkuperäisen visualisoinnin perusteella seuraavaksi eniten oli kuultu Suomen Yrittäjiä, yhteensä 927 kertaa. Kuitenkin visualisoinnissa nämä kuvattiin noin samankokoisina solmuina vaikka kuulemiskertoja EK:lla on siis yli kaksi kertaa vähemmän. Samalla huomasin, että visualisoinnissa valionkunnat oli normalisoitu samankokoisiksi solmuiksi riippumatta niiden kuulemiskertojen määrästä. Enimmillään valiokuntia oli kuultu yhtä monta kertaa kuin EK:ta eli n. 1 700 kertaa. Toteutuksessa oli siis haluttu korostaa ulkopuolisten tahojen kuulemisia.

Keskusteltuani Peltomäen kanssa sain selville myös, että verkostosta oli rajattu pois ne kuultavat joita oli kuultu vähemmän kuin 50 kertaa (tämä kerottiin myös visualisoinnin lisätietoja kohdassa). En kuitenkaan saanut selville mitä muuta verkostosta on rajattu pois, koska jos tämä olisi ollut ainoa rajaus olisivat käsitykseni mukaan jäljelle jääneiden kuultavien kaikki kuulemiskerrat olleet edelleen mukana verkostossa.

Näin ei kuitenkaan ollut vaan jutussa mainittujen kuulemiskertojen määrä ei täsmännyt kuultavista lähteneiden yhteyksien määrään. Esimerkiksi visualisoinnin mukaan Finnet-liitto ry:tä on kuultu 59 kertaa, mutta tämä määrä ei vastaa verkostossa nähtäviin kuulemiskertoihin eli solmusta lähteneiden yhteyksien määrään.

Verkostosta ei ollut siis luettavissa yksittäisen kuultavan kaikkia kuulemiskertoja, joka kertoo minulle, että verkostosta oli täytynyt tiputtaa pois myös lakialoitteita, joissa kuulemisia on tapahtunut. Yritin selvittää Facebook-ryhmän keskustelussa taustoja näihin epäselvyyksiin, mutta en jankkaamisenkaan jälkeen saanut tyhjentäviä vastauksia.

Verkostovisualisoinnit ovat lähtökohtaisesti monille vaikealukuisia ja hankalasti hahmoteltavia, koska ne eivät ole meille tuttuja, mutta niiden helpompaa tulkintaa ei tulisi kuitenkaan lähteä ohjaamaan puhtaasti graafisin perustein, koska tällöin niiden tulkinta tulee mahdottomaksi tavallisen kansan lisäksi myös ammattilaisille jollaiseksi nyt tässä itseni omahyväisesti lasken.

Miten sitten esimerkiksi tässä tapauksessa oli kannattanut toimia, jotta verkostosta oltaisiin saatu helpompilukuinen ja samalla pidetty kiinni siitä, että ei määriteltäisi verkoston muuttujia joillakin muilla kuin matemaattisilla perusteilla. Itse olisin lähestynyt ongelmaa siten, että olisin romahduttanut verkoston "yksinoodiseksi".

Nyt toteutuksessa oli mukana kahdenlaisia solmuja. Ensinnäkin verkostossa olivat mukana eduskunnassa kuultavina olleet tahot ja toiseksi lakialoitteet joissa kuulemiset olivat tapahtuneet. Yhteyksiä solmujen välillä oli vain eri tyyppisten solmujen välillä eli kuultavina olleista lähti yhteyksiä lakialoitteisiin. Kuultavina olleet solmut tai lakialoitteet eivät olleet suoraan yhteydessä toisiinsa. Toisin sanoen lakialoitteet solmivat yhteen eri kuultavina olleet tahot.

Verkosto olisi siten ollut mahdollista romahduttaa valitusta kaksinoodidesta esitystavasta yksinoodiseksi niin, että verkostoon olisi piirretty vain kuultavina olleet tahot ja yhteydet näiden välille olisi piirretty sen perusteella miten tahot olivat olleet kuultavina samoissa lakialoitteissa. Näin tieto siitä missä lakialoitteissa kukin taho oli ollut kuultavana olisi koodattu yhteyksiin eikä erillisiin solmuihin.

Tämä esitystapa olisi myös paljastanut verkostoteknisesti selkeämmin mitkä tahot ovat sellaisia, että heitä molempia kuullaan kun eri lakialoitteita valmistellaan ja toisaalta mitkä tahot ovat sellaisia, että he ovat lakialoitteissa ainoita kuultavana olevia. Tässä esitystavassa ainoat kuultavina olevat tahot olisivat piirtyneet verkoston reunoille kun runsaasti kuultavina toisten tahojen kanssa olisivat piirtyneet verkoston ytimeen. Näin siis etenkin kun verkosto olisi ladottu painovoimaohjatusti.

Vaikka siis verkostovisualisoinnit ovat viehättävännäköisiä ja usein niitä tulkitaan enemmänkin suurella kunnioituksella kuin asiantuntijuudella tulisi niitä toteuttaessa olla yhtä tarkka tiedon oikeellisuudesta kuin muidenkin visualisointitekniikoiden kanssa.

Toivottavasti tämä herättää keskustelua ja lopputuloksena on edelleen entistä parempaa (data)journalismia, joka varmasti kaikkien etu. Toivottavasti saamme myös alkuperäisen datan jossain vaiheessa aktiivisesti jakoon avoimena datana kuten eduskunta on ilmeisesti luvannut, jotta me kansalaiset pääsemme siitä nauttimaan.

Muokkaus 13.5.2013 klo 18:58

Lisätty linkki .gexf-muotoiseen dataan, joka on siis tuotettu HS:n toteutuksen .json-tiedostosta.