Python hoitaa, eli kuinka Plus-deski kokeili screen scrapingia

Kun keskustelu Keva-johtaja Merja Ailuksen työsuhde-eduista oli jatkunut jo jonkin aikaa, Yle:n toimittaja Jarno Liski alkoi pyöritellä mielessään kysymyksiä: kuinka kannattava työsuhdeasunnossa asuminen on, kuka siitä todella hyötyy ja millä tavalla työsuhdeasuminen otetaan verotuksessa huomioon. Hänen lähtöoletuksensa oli, että työsuhdeasuntojen verotusarvo vastaisi huonosti asunnoista vapailla markkinoilla maksettavaa vuokraa.

Liski otti yhteyttä Plus-deskin tuottaja Juho Salmiseen, joka lähti yhdessä Teemo Tebestin kanssa viemään asiaa eteenpäin. Lopputulos on nähtävissä täällä.

Verottajan väite syyniin

Verottajan mukaan asuntojen verotusarvo vastaa keskimäärin 90-prosenttisesti asunnosta pyydettyä vuokraa. Esimerkiksi 700 eurolla vuokrattavan asunnon verotusarvon pitäisi olla noin 630 euroa. Tämä tuntui kuitenkin pitävän huonosti paikkansa. Ideana olikin tutkia, minkä suuruisia verotusarvoja asunnot todellisuudessa saavat ja kuinka hyvin verotusarvo vastaa asunnoista pyydettävää vuokraa.

Verottaja määrittelee työsuhdeasunnoille laskukaavan, jonka avulla verotusarvo määritellään asuntokohtaisesti. Verotusarvon laskennassa vaikuttavat asunnon sijainti (pääkaupunkiseutu/muu maa), pinta-ala sekä valmistumisvuosi. Työntekijä saa asuntoedusta lisähyötyä silloin, kun verotusarvo on todellista markkina-arvoa selkeästi alhaisempi, koska tällöin hänen verotuksensa on keveämpi kuin sen tulisi olla.

Teemo ja Juho pohtivat, miten asiaan pääsisi käsiksi. Verottajan kaavan pitäisi tuottaa arvo, joka on hyvin lähellä markkinahintaa. Jarno Liskin idea oli kerätä suuri määrä olemassa olevien vuokra-asuntojen tietoja ja laskea asunnoille verottajan kaavan avulla verotusarvo.

Suomessa on muutama suuri vuokra-asuntoja listaava verkkopalvelu, joiden dataa olisi mahdollista käyttää verottajan kaavan testaamiseen. Käsityönä verotusarvon ja markkina-arvon kattava vertailu ei kuitenkaan onnistuisi, sillä vuokra-asuntoja on sivustoilla tuhansia.

Oli siis kirjoitettava koodinpätkä, jonka avulla pystyttäisiin keräämään tietyn verkkopalvelun vuokra-asuntoja koskeva data, laskea niiden perusteella asunnoille verotusarvo ja analysoida saatuja arvoja. Datan keräämiseen käytettävää menetelmää kutsutaan ruudunraavinnaksi (engl. screen scraping, tuttavallisesti screippaus). Asuntojen tiedot voisi poimia miltä tahansa vuokra-asuntoja listaavalta sivustolta. Teemo käytti tässä tapauksessa Alma Median ylläpitämän Vuokraovi.com-palvelun tietoja.

Koodi ja tietokanta valmiiksi

Ruudunraapijan kirjoittamiseen Teemo päätti käyttää Python-kieltä. Screipatessa kirjoitettu koodi käy järjestelmällisesti läpi verkossa olevia nettisivuja, poimii sivulta halutut elementit ja siirtää ne tietokantaan. Tietokannaksi Teemo valitsi ennestään tutun MongoDB:n. MongoDB sopi käyttötarkoitukseen hyvin, koska noSQL-tietokannassa datalle ei tarvitse määrittää tarkkaa rakennetta etukäteen, vaan sitä voidaan täydentää ja muokata tarpeen mukaan.

Kun Teemo laittoi homman aluilleen 29. marraskuuta, Vuokraovi-palvelussa oli tarjolla noin 6 000 vuokra-asuntoa eri puolilta Suomea. Yhdelle hakutulossivulle saa näkyviin kerrallaan 10–30 vaihtoehtoa, joten tarvittavien kyselyjen määrän minimoimiseksi Teemo sääti määrän maksimiinsa. Näin screipattavaksi jäi hieman yli 200 erillistä sivua, jolla jokaisella oli 30 asuntoa. (Kuva 1)

Helmikuussa 2014 Vuokraovi-palvelussa oli tarjolla n. 8 100 vuokra-asuntoa. (Kuva 1)

Datan keräämistä mutkisti se, että kaikki tarvittavat tiedot eivät löytyneet tältä hakutulossivulta. Koodin tuli käydä läpi myös jokaisen asunnon oma sivu, sillä asunnon rakennusvuotta ei mainita kaikkien asuntojen listauksessa. Kyselyjä piti siis lopulta tehdä 200 hakutulossivuille ja 6 000 yksittäisten asuntojen omille sivuille.

Teemon ensimmäinen ajatus oli kokeilla ScraperWiki -palvelua, jota hän oli kuullut käytettävän screippaukseen. Palvelu on ollut etenkin toimittajien suosiossa ja Teemo ajatteli, että palvelun testaamisen jälkeen hän voisi opettaa sen käyttöä muille toimittajille.

ScraperWiki mahdollistaa esimerkiksi Python-koodin kirjoittamisen ilman erillisten ohjelmointiympäristöjen asentamista. Siksi palvelu sopii esimerkiksi journalisteille, joilla ei usein ole mahdollisuutta tai taitoa asentaa kaikki tarvittavia ohjelmistoja. Teemo päätyi kuitenkin tekemään toteutuksen omalla koneella omassa ympäristössä, koska tämä oli lopulta hänelle kätevämpää.

Scraper käy läpi HTML-koodia ja tallentaa määritellyt osiot talteen myöhempää käyttöä varten. (Kuva 2)

HTML-merkkauksen siivouksessa ja käsittelyssä Teemo käytti hyväkseen BeautifulSoup-nimistä Python-kirjastoa. BeautifulSoup on kirjasto, jonka avulla verkkosivuilla käytetty HTML-merkkaus voidaan muuttaa koneelle ymmärrettävään muotoon. Lopulta koodi ryömi Vuokraovi.comin sivuja muutaman tunnin ajan. Ajo tehtiin vielä uudelleen lopullista uutista varten 2. joulukuuta.>

Trouble shooting vei aikaa

Kun Teemo testasi koodia ensimmäisiä kertoja, koodi ei hakenut dataa halutulla tavalla. Vian etsintään menikin hetki. Lopulta Teemo tajusi tutkiessaan HTTP-pyyntöä, että Vuokraovi.com -sivusto asetti Internet-selaimessa tukun evästeitä, eli cookieita, joiden puute esti scraperin toiminnan. Hän päätteli, että asian korjaamiseksi samaiset evästeet tulisi asettaa myös tietokoneohjelman tekemään HTTP-pyyntöön. Tällöin HTTP-pyyntö vaikuttaisi Vuokraovi.comin näkökulmasta täysin samanlaiselta kuin jos sen tekisi esimerkiksi Google Chrome -selaimella. (Kuva 3)

HTTP-pyyntöihin liittyvät evästeet näkee Google Chrome -selaimessa Inspect Element -valikon takaa. (Kuva3)

Joskus screipatessa voi käydä niin, että jos pyyntöjä tehdään suuri määrä, palvelin voi tulkita ne vihamielisiksi ja estää ne. Vuokraoven tapauksessa reilut 6 000 pyyntöä hukkui luultavasti normaalin verkkoliikenteen sekaan. Screippausta suunnitellessa kannattaa kuitenkin miettiä, voiko rajoituksista tulla ongelmia. Esimerkiksi hakukoneyhtiö Google tunnistaa tehokkaasti koneellisesti tehtävät haut ja estää ne, koska koneellisesti tehtävät haut ovat osa heidän maksullista palveluaan.

Toteutus on ladattavissa avoimena lähdekoodina (CC-BY-SA 4.0) Ylen Github-sivulta.

Yhden päivän työ

Ennen julkaisua aineistosta siivottiin pois sellaiset kohteet, joista puuttui jokin tarvituista tiedoista, kuten rakennusvuosi, sekä autotallit ja kalustetut asunnot. Näin aineistosta saatiin vertailukelpoista. Karsimisen jälkeen pohja-aineistoksi jäi noin 5 000 vuokra-asunnon tiedot. MongoDB:stä data tulostettiin .csv-muodossa ja vietiin Googlen Spreadsheets-taulukkolaskentaohjelmaan, jossa lopullinen verotusarvolaskenta tehtiin. Aineisto on ladattavissa Ylen sivuilta Excel-muodossa.

Jutun teknisten osien toteuttaminen järjesteltävine taulukoineen kesti noin työpäivän verran, joskin homma olisi sujunut nopeammin, jos eväste-ongelman selvittämiseen ei olisi mennyt aikaa. Jatkossa vastaavanlaisia toteutuksia tehtäessä evästeet osataan ottaa paremmin huomioon.

Eräs aineistosta tehty havainto oli, että erot markkinavuokrassa suhteessa verotusarvoon olivat alueellisia. Niinpä juttu sai otsikon: Asuntoedusta hyötyy eniten Helsingissä ja kehyskunnissa – katso oman kuntasi tilanne. Jutun yhteydessä käyttäjä sai tutkia asuntojen markkinavuokran ja verotusarvon eroa sekä kunnan että postinumeroalueen perusteella.

Aineisto myös paljasti, että verotusarvon ja markkina-arvon välinen vastaavuus oli keskimäärin 73 prosenttia, siis huomattavasti verottajan edustajan ilmoittamaa 90 prosenttia pienempi.

Juttu ei ollut varsinainen yleisömenestys. Asuntoedusta nauttii Suomessa alle 20 000 henkilöä, joten kohdeyleisökään ei ollut järin suuri. Vaikuttavuutta ei voida kuitenkaan mitata pelkästään lukijamäärän perusteella.

Screippaus-kokeiluna juttu oli Plus-deskille uusi aluevaltaus ja on hyvin todennäköistä, että tulevaisuudessa tällaisia omaan datan hankintaan perustuvia "skuuppeja" tulee enemmän.

Laita siis Python töihin!

Heidi Kähkönen
Kirjoittaja on vapaa toimittaja ja datajournalismikouluttaja
Twitter:  @heidikahkonen

Karttatoteutuksista ja koordinaatistoista

Olemme PlusDeskin ensimmäisten neljän kuukauden aikana toteuttaneet muiden muassa suuret määrät erilaisia karttavisualisointeja. (Kuva 1)

Olemme tehneet niin yksittäisiin pisteisiin perustuvia Google Maps -pohjaisia karttoja kuten:

• Nouseeko kotiseudullesi jättimäisiä tuulimyllyjä? Katso kartalta
• Suomalaisten sieppaus Jemenissä - tapahtumat kartalla

kuin myös erilaisia aluisiin perustuvia Google Maps -karttoja kuten:

• Tuoko ryntäys kaivoksen naapuriisi? Katso kartalta
• Kilpailuta terveytesi – täällä yksityinen lääkäri on halvin

Kartat ovat oiva visualisointikeino kun halutaan kuvata datan spatiaalista merkitystä kuten tässä esimerkissä, jossa ilmiön voidaan keskittynyt rannikolle. (Kuva 1)

Toisinaan olemme myös piirtäneet kartalle yhtäaikaisesti yksittäisiä pisteitä ja alueita kuten Bostonin tapahtumat -jutun yhteydessä, jossa maratonin reitti piirrettiin yhtenäisenä viivana kun taas räjähdykset ja muut tapahtumapaikat yksittäisinä pisteinä.

Google Maps:n lisäksi olemme hyödyntäneet kartoissa OpenStreetMap-palvelua kuten esimerkiksi jutussa, jossa kerroimme mistä löytyy keskimäärin paras sää hiihtolomakaudella.

Mainittujen palveluiden lisäksi olemme toteuttaneet karttoja räätälöidyillä SVG-pohjaisilla ratkaisuilla kuten näissä esimerkeissä:

• Täällä punkit aiheuttavat tauteja – katso alueesi tilanne
• Täällä lohen vaellus katkeaa - katso kartalta pahimmat nousuesteet

Räätälöidyissä toteutuksissa olemme hyödyntäneet Raphaël-nimistä JavaScript-kirjastoa, joka sopii hyvin tarpeisiimme, koska se toimii myös vanhemmilla Internet Explorer -selaimilla. Tavoitteemme kun on, että Yle Uutiset ja sen sisällöt toimivat mahdollisimman laajasti kaikilla laitteilla.

Interaktiivisten ja klikattavien karttojen lisäksi olemme julkaisset staattisia kuviin perustuvia karttoja kuten tässä euroviisupisteiden jakautumista maiden välillä kuvaavassa jutussa.

Se mitä työkalua ja ratkaisua kulloinkin hyödynnämme ohjaa ensisijaisesti se minkälaista dataa olemme visualisoimassa. Joskus toiset työkalut soveltuvat paremmin toisille datoille. Esimerkiksi käsiteltäessä suuria datamassoja on Google Maps usein toimiva työkalu.

Välillä eteen tulee tilanteita, jolloin meillä on olemassa tarvittava karttapohja (kuten sairaanhoitopiirien rajat) valmiina vain SVG-toteutusta varten, joka rajaa meitä käyttämästä Google Maps:n kaltaisia palveluita, koska ne perustuvat SVG:n käyttämien pikseleiden sijaan koordinaatistotietoon.

---

Julkaisimme viime maaliskuussa jutun koskien lakkautettuja kouluja Suomessa vuosina 2006–2012. Jutun taustalla on Tilastokeskukselta tilaamamme kouluaineisto, johon olimme pyytäneet mukaan koulujen paikkatiedot. Ajatuksenamme oli visualisoida lakkautettavat koulut kartalle käyttäen OpenStreetMap-palvelua. (Kuva 2)

Toteutuksesta oli mahdollista tarkastella lakkautettuja kouluja Suomen kartalta valitulla aikajaksolla ja oppilasmäärällä. (Kuva 2)

Saimme datan Excel-tiedostona, johon oli listattu kaikki lakkautetut koulut vuosittain yhdessä koordinaattitietojen kanssa. Ongelma oli, että koordinaattitiedot olivat kartastokoordinaattijärjestelmässä (KKJ), joka on erityisesti Suomeen kehitetty koordinaattijärjestelmä, jota edellä mainitut Google Maps ja OpenStreetmap-palvelut eivät tue.

KKJ jakaa Suomen neljään projektiokaistaan ja projektiokaistoilla on oma koordinaatistonsa. Projektiokaistojen tehtävä on käsittääkseni poistaa maan kaarevuudesta aiheutuvaa vääristymää. (Kuva 3)

KKJ:ssa Suomi on jaettu neljään projektiokaistaan. (Kuva 3)

KKJ-järjestelmän eri projektiokaistojen käyttäminen on siinä määrin monimutkaista etenkin rajakohdissa, että siitä on kehitetty yksinkertaistettu versio nimeltään yhtenäiskoordinaatistojärjestelmä (YKJ).

YKJ tunnetaan myös nimellä KKJ3, koska se vastaa kartastokoordinaattijärjestelmän projektiokaistaa kolme jatkettuna itään ja länteen niin, että se kattaa koko Suomen. YKJ-koordinaateille on ominaista, että kolmoskaistalle sijoittuviin koordinaatteihin ei lisätä alkuun projektiokaistan merkitsevää numeroa kolme.

YKJ-koordinaatit ovat siis muotoa:

• p=6700000, i=3500000

tai lyhyemmin muotoa:

• 6700000, 3500000.

Itäinen koordinaatti lasketaan metreinä keskimeridiaanille ja pohjoinen koordinaatti kertoo matkan päiväntasaajalta pohjoiseen.

Kuten sanottua ongelma KKJ- ja YKJ-koordinaatistoissa on, etteivät kartastopalvelut tue niitä. Esimerkiksi Google Maps tukee GPS:lle kehitettyä WGS84-koordinaatistojärjestelmää, ja tämän vuoksi meidän täytyi muuntaa koordinaattien järjestelmä.

Googlen avulla löysin Luonnontieteellisen keskusmuseon ylläpitämän palvelun nimeltä Luomus, joka mahdollistaa koordinaattijärjestelmien välisen muunnoksen. Palveluun on mahdollista syöttää muunnettavat YKJ:n mukaiset itä- ja pohjoiskoordinaatit, jonka jälkeen palvelu palauttaa muunnoksen tuloksen.

Esimerkiksi kysely http://www.luomus.fi/projects/coordinateservice/?orig_system=ykj&north=6982696&east=3541961 palauttaa vastauksen:

<CoordinateData>
<result>
<new_system>etrs89</new_system>
<north>62.94538003831</north>
<east>27.823170453332</east>
</result>
<orig_system>ykj</orig_system>
<version>2.0</version>
<disclaimer>
This is coordinate translation system provided by Finnish Museum of Natural History (FMNH). Copyright FMNH and National Land Survey of Finland. FMNH makes best effort to keep the data and conversions as accurate as possible.
</disclaimer>
</CoordinateData>

Vastauksen kohdista <north>62.94538003831</north> ja <east>27.823170453332</east> ovat luettavissa annettuja YKJ-koordinaatteja vastaavat WGS84-koordinaatiston mukaiset koordinaatit.

Muunnettavia koordinaattitietoja minulla oli 26 185 Excel-rivin edestä, joten rakensin Python-ohjelmointikielellä yksinkertaisen koodinpätkän, joka automatisoi tämän muunnostyön. Toteutus on saatavilla kirjoituksen lopusta. (Kuva 4)

Tekemäni koodi muunsi YKJ-koordinaatistossa olleet tasokoordinaatit WGS84-koordinaatissa oleviksi maantieellisiksi koordinaateiksi. (Kuva 4)

Mikä on kuitenkin myös luettavissa vastauksesta on kohta <new_system>etrs89</new_system>. Eli kohdejärjestelmä ei tässä siis olekaan WGS84 vaan ETRS89. Tästä seuraavaksi.

---

Käsiteltäessä karttatietoa koordinaatistojärjestelmät eivät ole ainoa huomioitava asia vaan koordinaatit voidaan eri järjestelmien lisäksi esittää myös eri formaateissa yhden järjestelmän sisällä. Yleisiä esitysformaatteja ovat ainakin tasokoordinaatit ja maantieteelliset koordinaatit. YKJ- ja KKJ-koordinaatit ilmoitetaan kokemuksieni mukaan yleisimmin tasokoordinaatteina kun taas Google Maps tukee maantieteellisiä koordinaatteja.

Ero tasokoordinaattien ja maantieteellisten koordinaattien välillä on esitystapa. Tasokoordinaatit kertovat matkan pohjoiseen ja itään kun maantieteelliset koordinaatit kertovat leveys- ja pituuskoordinaatit. Tasokoordinaatit ovat siis kokonaislukuja ja maantieteelliset koordinaatit asteita.

Koordinaatistoformaatteihin ja niiden muunnoksiin pääsin tutustumaan kun teimme äskettäin jutun painorajoitettavista silloista Suomessa. Saimme Liikennevirastolta tiedot 391:stä tulevaisuudessa uuden painorajoituksen saavasta sillasta ja mukana olivat siltojen paikkatiedot. Paikkatiedot olivat saamassamme Excel-tiedostossa ETRS89-koordinaatiston suomalaisen EUREF-FIN-nimisen projektion mukaisia. ETRS89-koordinaatit vastaavat käytännössä WGS84-koordinaatteja (ero on alle metrin).

Koordinaattitiedot olivat kuitenkin tasokoordinaatistoformaatissa, jotka eivät tietääkseni ole tuettuja Google Maps -työkalussa. Tässä tapauksessa minun ei kuitenkaan tarvinnut muuntaa koordinaattijärjestelmää toiseen vaan kuten edellä vaan vaihtaa vain koordinaattien esitystapa. Luomus.fi-palvelusta ei harmikseni löytynyt työkaluja formaattimuunnoksiin, mutta löysin ratkaisun Karttapaikka.fi-palvelusta Juho Salmisen avustuksella.

Karttapaikka.fi-palvelusta löytyvän Karttapaikka-nimisen työkalun avulla on mahdollista tehdä monipuolisesti erilaisia koordinaatteihin liittyviä muunnoksia. Palveluun voi syöttää koordinaatteja niin taso- kuin maantieteellisessä formaatissa, jonka jälkeen palvelu palauttaa tiedot kattavasti. Tarjolla ovat kaikki Suomessa yleisesti käytetyt koordinaatistojärjestelmät ja -formaatit.

Tein myös tässä tapauksessa samanlaisen yksinkertaisen koodinpätkän, jolla automatisoin formaattimuunnoksen tekemisen kaikille hallussani olleille koordinaateille. Tämäkin toteutus on saatavilla kirjoituksen lopusta. (Kuva 5)

Tekemäni koodi muunsi kaikki painorajoitettujen siltojen tasokoordinaatit maantieteellisiksi koordinaateiksi. (Kuva 5)

Itseasiassa ensimmäisessäkin esimerkissä lähdeaineistomme oli aluksi tasokoordinaatistoformaatissa. Eli Luomus.fi-palvelu teki itseasiassa muunnoksen niin koordinaattijärjestelmän kuin myös koordinaattiformaatin osalta.

---

Yhteenvetona voitaneen todeta, että paikkatieto ja sen esittäminen on melko moninaista, mutta kokemuksieni mukaan Suomessa paikkatietodata julkaistaan useimmin tasokoordinaatteina joko YKJ- tai KKJ-järjestelmässä, jotka siis ovat hankalia käytössä olevien karttapalveluiden kannalta.

2000-luvulla Suomessa on pyritty siirtymään ETRS89-järjestelmään, mutta esimerkiksi Tilastokeskuksen ruututietokanta on siirtynyt siihen vasta vuonna 2011. Suunta on kuitenkin kohti ETRS89:ää, joka vastaa siis melkein WGS84-järjestelmää. Eli ETRS89-koordinaatteja on mahdollista käyttää esimerkiksi Google Maps:ssä kunhan ne vain ovat maantieteellisessä formaatissa.

---

Tämän kirjoituksen myötä julkistan Yle Plus -GitHub-repositorion. Repositorion tarkoitus on toimia julkaisukanavana Yle Uutisten ja ainakin PlusDeskin tekemille avoimille lähdekoodille. (Kuva 6)

Tulemme käyttämään Yle Plus-repositoriota toteuttamiemme koodien julkaisemiseen avoimena lähdekoodina. (Kuva 6)

Ensimmäisinä työkaluina julkaisemme tässä kirjoituksessa mainittujen koordinaattimuunnosten lähdekoodit, jotka siis mahdollistavat YKJ-tasokoordinaattien muuntamisen WGS84-järjestelmän maantieteellisiksi koordinaateiksi sekä ETRS89-tasokoordinaattien muuntamisen maantieteellisiksi koordinaateiksi.

Lähdekoodit julkaistaan CC-BY-SA-lisenssillä, joka mahdollistaa koodien hyödyntämisen niin yksityisessä kuin kaupallisessakin käytössä. Ainoat rajoitteet ovat, että käytettäessä alkuperäinen lähde (Yle Uutiset) on mainittava ja että kaikki mahdolliset jatkototeutukset on jaettava samalla lisenssillä.

PlusDesk ja elämää hetkessä

Olen nyt ollut kaksi viikkoa osa Yle Uutisten PlusDesk-toimitusta. PlusDesk on Uutis- ja ajankohtaisorganisaatioon perustettu toimitus, jonka tehtävä on auttaa mm. uutis- ja urheilutoimituksia netin omaisten sisältöjen toteuttamisessa. Ajatuksena on, että PlusDesk yhdessä toimituksien kanssa tuottaa netinomaista sisältöä netin ehdoilla. Tarkoitus ei siis ole, että vastuu nettijuttujen tekemisestä jää pelkästään PlusDesk:n vastuulle.

Tiimimme kuuluu kaksi tuottajaa (Juho Salminen ja Mika Pippuri), kolme graafikkoa (Juha Rissanen, Stina Tuominen ja kolmas vielä vielä nimeämätön henkilö) sekä yksi toimittaja/datajournalisti eli allekirjoittanut. Toimintamme on orientoitumisviikon jälkeen tällä viikolla pyörähtänyt käyntiin ihan juttujenkin toimesta ja olemmekin ehtineet olemaan mukana yhteensä viiden eri julkaistun jutun teossa. Yhtenä tavoitteenamme on avata prosessejamme mahdollisimman paljon niin sisäisesti kuin talon ulkopuolellekin ja tässä kuvaus eräästä jutusta, jolle oli ominaista etenkin eläminen ajassa.

---

Perjantaiaamuna Yle Uutiset uutisoi, että brittiläinen professori Nick Trefethen oli kehittänyt uuden laskukaavan laajalti painonhallinnassa käytetyn painoindeksin laskemiseen. Verrattuna alkuperäiseen uusittu indeksi painottaa hieman eritavalla laskennassa käytettäviä ihmisen pituutta ja painoa. Alkuperäinen Adolphe Quetelet keskimä malli laskee painoindeksin niin, että paino jaetaan pituuden neliöllä:

paino (kg) / pituus (cm) * pituus (cm)

Trefethen:n kehittämässä mallissa paino kerrotaan 1,3:lla ja pituus korotetaan potenssiin 2,5. Kaava on siis muotoa:

1,3 * paino (kg) / pituus (cm) ^2,5

Toinen tuottajistamme Mika Pippuri keksi puolenpäivän aikaan, että voisimme pikaisesti kyhätä tähän uuteen malliin perustuvan laskentakoneen, jonka avulla lukijat voisivat nopeasti laskea oman "uuden" painoindeksinsä ja verrata sitä vanhaan. (Kuva 1)

Kuvankaappaus artikkeliin upotetusta painoindeksikoneesta. (Kuva 1)

Innostuinkin ideasta siinä määrin, että jätin työnalla olleen kiireettömämmän projektin kesken ja lähdin toteuttamaan painoindeksikonetta. Intuitioni oli lähteä toteuttaa HTML-muotoista lomaketta ja sille PHP-käsittelijää, joka nappaisi lomakkeelta lähetetyt tiedot ja palauttaisi käyttäjälle vastauksen. Mika kuitenkin löysi valmiin JavaScript-pohjaisen koodin pätkän painoindeksin laskentaan, joka ohjasi minut toteuttamaan laskurin JavaScript:llä. JavaScript toteutus oli myös lähtökohtaisesti parempi, koska se ei pakottanut käyttäjää lataamaan sivua uudelleen ja oli siten mukavampi käyttää. Jälkikäteen hieman ärsyttää, että lähtökohtani ei ollut JavaScript-pohjainen ratkaisu, mutta tämä pistettäköön perjantain ja erittäin kiireisen viikon piikkiin.

Tämänkaltaiset erikoistoteutukset viemme Yle Uutisten sivuille ns. ulkoisina upotuksina. Toteutuksien koodit sijoitamme erilliseen ympäristöön käyttämämme Escenic-järjestelmän ulkopuolelle ja tuomme ne Escenic:iin ulkoisena sisältötyyppinä. Ulkoinen sisältötyyppi määrittelee itselleen kolme resurssia:

• HTML tai PHP resurssi
• CSS-resurssi(t)
• JavaScript-resurssi(t)

Tämä ulkoinen sisältötyyppi on mahdollista liittää normaaliin uutisartikkeeliin samaan tapaan kuin esimerkiksi kuva. Samoja ulkoisia sisältötyyppejä on mahdollista käyttää useaan kertaan, mutta tällä hetkellä ulkoinen sisältö voidaan sijoittaa vain joko artikkelin alkuun tai loppuun. Tällä samalla tekniikalla tuomme järjestelmään myös esimerkiksi Google:n sisällöt kuten kartat (Google Maps) ja lomakkeet (Google Form).

Toimituksellisesti teimme vielä sellaisen päätöksen, että sijoimme painoindeksikoneen erilliseen artikkeliin sen sijaan, että olisimme päivittäneet sen osaksi aiheesta jo kirjoitettua artikkelia. Näin saimme toteutuksellemme paremman näkyyden, koska saavutimme paremmin myös ne käyttäjät, jotka olivat jo lukeneet alkuperäisen aamulla julkaistun jutun.

Painoindeksikone nousikin nopeasti sivuston luetuimmaksi jutuksi ja piti paikkansa aina siihen asti kun ehdin poistua toimistolta. Vertailuluku seuraavaksi luetuimpaan juttuun viimeisimmän tunnin aikajaksolla mitattuna oli sen suuntainen, että tämä painoindeksikoneemme oli n. kolme kertaa luetumpi kuin koko yle.fi-domainin seuraavaksi luetuin sivu.

Selkeimpänä kehitysideana tuli itselleni mieleen, että olisi ollut kätevää ja käyntimäärien kannalta positiivista jos painoindeksikoneen antaman tuloksen olisi voinut jakaa Facebook:ssa ja muissa palveluissa. Koimme kuitenkin, koska kello alkoi lähennellä iltapäivää, että on tärkeämpää saada toteutus vain mahdollisimman nopeasti julki. Seuraavalla kerralla kun prosessit ovat muutenkin suoraviivaistuneet varmaankin otamme myös tämän aspektin huomioon tämänkaltaisissa toteutuksissa.

Edit: Muokatta Stina Tuomisen nimi oikeaksi ja lisätty linkki JavaScript-koodiin, jonka pohjalta toteutusta lähdettiin tekemään.

Datajournalisti vs. Internet Explorer

Tämä on tarina turhautumisesta ja liian pitkäksi venyneestä päivästä.

---

Tein yhteistyössä Eva Koskisen ja Pekka Palmgrenin kanssa Radar:lle muutaman visualisoinnin koskien amerikkalaisen Capital Group -investointipankin sijoituksia suomalaisissa pörssiyhtiöissä. Aiheesta julkaistu juttu löytyy täältä: Radar: Anonyma ägare på finska börsen

Visualisointien toteutus ja kasaaminen oli melko suoraviivainen ja nopea prosessi, koska käytin olemassa olevia komponentteja. Tämä oli tarkoituksenmukaista sillä muutamassa päivässä, jotka minulla oli aikaa ei ollut mahdollista lähteä toteuttamaan mitään laajempaa omaa ja uudenlaista toteutusta.

Juttuun toteuttamiani tiedonvisualisointikomponentteja oli kolme:

1. pallovisualisointi, joka kuvaa Capital Group:n sijoitusten suuruutta yrityksissä. (Kuva 1)
2. taulukko, josta on mahdollista vertailla tietoja perustuen yrityksen omiin kotisivuihin ja muualta kerättyihin tietoihin. (Kuva 2)
3. pylväsdiagrammi, joka mahdollistaa valittujen yritysten omistajatietojen tarkastelun. (Kuva 3)

Pallovisualisointi kuvasi Capital Group:n sijoitusten arvoja eri yrityksissä. Värit oli asetettu satunnaisesti USA:n lipun väreihin. (Kuva 1)

Taulukosta oli mahdollista vertailla yksittäisen yrityksen omistajalistaa kahden eri lähteen perusteella. (Kuva 2)

Pylväsdiagrammista oli mahdollista selata halutun yrityksen suurimpia omistajia perustuen vaihtoehtoisesta tietolähteestä kerättyihin tietoihin. (Kuva 3)

Pallovisualisoinnin (Kuva 1) toteutin perustuen esimerkkiin, joka löytyy täältä:
http://vallandingham.me/vis/gates/

Samaa lähdekoodia on hyödynnetty mm. New York Times:n toteuttamassa visualisoinnissa, jossa käsitellään USA:n budjettia.

Pylväsdiagrammin toteutin D3-Generator -palvelun avulla. Muokkasin palvelun tuottamaa koodia vain niin, että käyttäjän oli mahdollista valita pudotusvalikon avulla tarkasteluun haluamansa yrityksen tiedot.

Taulukkovisualisointi toteutettiin leipätekstin sekaan sellaisenaan HTML:n ja CSS:n avulla. Kyseessä oli siis tavallinen <table>-HTML-taulukko.

---

Interaktiiviset visualisoinnit toteutin D3.js-JavaScript-kirjaston avulla. Kirjasto mahdollistaa graafisten elementtien yksinkertaisemman toteuttamisen samaan tapaan kuin jQuery helpottaa tavallisten JavaScript-toiminnallisuuksien toteuttamista. D3.js-kirjasto tarjoaa valmiita funktioita ja toiminnallisuuksia, joiden avulla esimerkiksi kuvassa 3 nähtävien pylväiden piirtäminen onnistuu vain muutaman koodirivin avulla.

D3.js:ää on käytetty maailmalla paljon ja se on Raphaël-kirjaston ohella yksi eniten käytetyistä JavaScript-kirjastoista mitä tulee interaktiviisten visualisointien toteuttamiseen selainympäristöissä. Vaikka D3.js on yleisesti käytetty ei se kuitenkaan ole ongelmaton kaikkien selainten suhteen. Tai pikemminkin kaikki selaimet eivät noudata Internet-standardeja siinä määrin, että D3.js:llä toteutetut visualisoinnit toimisivat niissä aina suoraan. Syyttävä sormi osoittaa tässä etenkin Internet Explorer -selaimeen ja sen vanhempiin versioihin (IE 8 ja vanhemmat).

Myös toteuttamani visualisointien kohdalla jouduin toteamaan, etteivät ne toimi IE 8:n ja vanhemmilla selaimilla. Virheilmotukseksi selain antaa:

CSSStyleDeclaration undefined

joka aiheuttaa, että koko D3.js-kirjasto jää määrittelemättä eikä visualisointi toimi siten lainkaan. Google:n avulla ongelmaan löytää D3.js:ään ja kyseiseen virheilmoitukseen linkittyviä aiheita, mutta mitkään niistä eivät tarjonneet toimivaa ratkaisua, jota olisin voinut hyödyntää.

Tilanne oli sinällään erittäin turhauttava, että visualisointi toimi hienosti missä tahansa modernissa selaimessa. Kuitenkin kun Yleisradio:n hiljainen lupaus on tuottaa sisältöä kaikille kansalaisille velvoittaa se ottamaan huomioon kaikki kohderyhmät. En kuitenkaan halunnut jättää toteutusta tämän lupauksen takia julkaisematta, koska olin käyttänyt jo suhteellisen paljon aikaa visualisointien toteuttamiseen.

Vaihtoehtoina oli pyrkiä korjaamaan virhe ja tekemään D3.js:stä paremmin yhteensopiva Internet Explorer -selaimen kanssa, mutta sinällään tämä tie olisi voinut olla hyvinkin kivinen ja aikataulullisesti haastava, koska toteutus tuli saada ulos seuraavana päivänä. Ratkaisuni oli päätyä toteuttamaan visualisoinneista erilliset versiot vanhemmille selaimille, jotka eivät vaatisi niin monimutkaisia JavaScript-toiminnallisuuksia.

Pallovisualisoinnille (Vis 1) toteutin version, joka toimii myös IE:llä (Vis 2) ottamalla kuvankaappauksen alkuperäisestä versiosta ja lisäämällä kuvankäsittelyohjelmassa eri yritysten tiedot visualisoinnin päälle käsin. Eli sen sijaan, että käyttäjän oli mahdollisuus osoittaa palloja hiirellä näytettiin hänelle kaikki data kerralla (joka ironisesti ehkä osoittautui kyllä paremmaksikin tavaksi esittää data).

Interaktiivinen D3.js toteutus näytti yritysten tiedon käyttäjän viedessä hiiren halutun yrityksen päälle. (Vis 1)

Staattisessa kuvassa kaikki yritysten tiedot olivat esillä heti. (Vis 2)

Pylväsdiagrammivisualisoinnissa taas otin kuvankaappaukset kaikista yksittäisten yritysten tiedoista (Kone, Sampo, Nokian Renkaat, Orion ja Nokia) ja muutin toteutusta niin, että datan interaktiivisen uudelleen piirtämisen sijaan visualisointia hallitaan CSS+JavaScript -toiminnallisuuden avulla. IE:lle optimoitu toteutus toimii niin, että kun käyttäjä klikkaa haluamaansa yritystä, piilottaa JavaScript-koodi CSS:n avulla kaikki muut kuin käyttäjän valitseman yrityksen kuvat näkyvistä. Tämänkaltainen toteutus on siinä määrin yksinkertainen, että edes IE ei pysty sen implementoinnissa epäonnistumaan. (Vis 3 & Vis 4)

Interaktiivisessa pylväsdiagrammissa käyttäjän oli mahdollista osoittaa yksittäisiä pylväitä saadakseen lisätietoja. (Vis 3)

Internet Explorer -selaimelle toteutetussa versiossa yrityksen valinta oli tehty linkkien avulla, jotka mukautuvasti näyttivät ja piilottivat kuvia. (Vis 4)

Leipätekstiin interaktiiviset visualisoinnit upotettiin <iframe>:n avulla seuraavasti:

<!--[if (lt IE 9)&(!IEMobile)]>
<iframe src="http://svenska.yle.fi/dataviz/capitalgroup/juttu3/fallback/index.html?l=se" width="400" height="560" frameborder="0" scrolling="no" style="overflow:hidden;">Laddar...</iframe>
<![endif]-->

<!--[if gte IE 9]><!-->
<iframe src="http://svenska.yle.fi/dataviz/capitalgroup/juttu3/index.html?l=se" width="400" height="560" frameborder="0" scrolling="no" style="overflow:hidden;">Laddar...</iframe>
<!--[endif]-->

Koodissa käytetään IE:n tunnistamia conditional comments -lausekkeita, jotka mahdollistavat IE:lle erityisten koodipätkien kirjoittamisen. Kyseisessä koodissa IE 9:ää vanhemmille selaimille tai IE:n mobiiliselaimelle näytetään yksinkertaistettu "fallback" versio toteutuksesta.

Internet Explorer yhteensopivuuden toteuttaminen vei aikaani siitä kun olisin voinut viimeistellä visualisointeja paremmiksi ja selkeämmiksi, joka aiheutti etenkin pallovisualisoinnin (Vis 1) kohdalla, että en ollut lopputulokseen täysin tyytyväinen.

http://stefanvermaas.nl/wp-content/uploads/2012/08/internet_explorer_fail.jpeg

Suosittelen kaikille esimerkiksi Google Chrome, Mozilla Firefox tai Safari -selaimia, joita käyttäessänne teette minun ja monen muun web-sovelluksia kehittävän ihmisen elämän todella paljon helpommaksi.

Esittelyssä datajournalistin työkalut, Osa 1

Datajournalismi kuten tekniikka usein vaatii tuekseen oikeat ja tehokkaat työkalut.

Vasarallakin saa laudan poikki, mutta saha toimii tarkoitukseen paremmin.

Ajattelin tuoda esiin viisi sellaista työkalua, joita itse käytän ja joiden käyttämisen koen olevan jokaisen datajournalismista kiinnostuneen opeteltavissa. Aloitan kuitenkin helppokäyttöisimmästä, jotteivät ei-teknisimmät henkilöt putoa heti matkasta.

SharedCount

SharedCount on yksinkertainen palvelu, joka mahdollistaa linkkien sosiaalisen median näkyvyyden tutkimisen. Palveluun on mahdollista linkittää mikä tahansa www-sivun osoite ja palvelu kertoo kuinka monta kertaa sivu on jaettu Facebook:ssa, Twitter:ssä, LinkedIn:ssä, Google+:ssa jne. Esimerkiksi Youtube-videota "The Canucks of Vancouver" on jaettu sosiaalisissa medioissa seuraavasti.

Palvelu on siis hyvin yksinkertainen käyttää ja siihen nähden se tarjoaa hyvin arvokasta tietoa sisältöjen leviämisestä sosiaalisessa mediassa. Sosiaalinen media on tärkeä osa datajournalismia ja siten myös sosiaalisen median toiminnan ymmärtäminen kuuluu siihen tärkeä osana. Toisaalta myös omien blogikirjoitusten ja vastaavien tuotosten leviämisen seuraaminen on SharedCount:n avulla kätevää.

Huomiotavaa etenkin kehittäjille on, että palvelu tarjoaa myös JSON-rajapinnan.

Google Trends

Mentäessä esiteltäviä palveluita eteenpäin tällä helppokäyttöisyysperiaatteella tulee seuraavaksi eteen Google Trends. Google Trends on nimensä mukaisesti Google:n työkalu, jolla on mahdollista tutkia hakusanojen suosiota. Palvelu ei ole kovinkaan tunnettu etenkään verrattuna Google:n muihin tuotteisiin, mutta ehdottomasti tutustumisen arvoinen. Palvelu toimii niin, että hakukenttään syötetään haluttu lista sanoja pilkuilla eroteltuna, jonka jälkeen palvelu kertoo kuinka paljon kyseisiä hakusanoja on Google:n avulla etsitty. Esimerkkinä tein haun suomalaisista kaupunkien nimistä, joissa on 2000-luvulla tapahtunut ampumistapauksia. (Kuva 1)

Suomalaisten kaupunkien hakusanojen suosiossa näkyvät selkeästi traagiset tapahtumat. (Kuva 1)

Google Trends:stä ovat selkeästi nähtävissä ampumistapauksien ajankohdat ja niiden vaikutus hakusanojen suosioon. Mielenkiintoinen kuriositeetti on, että kaupunginnimen suosio hakusanana on pienentynyt vuosien saatossa.

Google Trends on oiva työkalu tarkoitukseensa, joskin siltä ei kovin paljon enempää tule odottaa.

CometDocs

CometDocs:iin törmäsimme tässä blogissa edellisen viestin yhteydessä. Kyseessä on työkalu, joka muuntaa palveluun lähetetyt .pdf-dokumentit helpommin käsiteltäviin Excel tai Word -muotoihin. Palveluun on siis mahdollista lähettää taulukkodataa sisältävä .pdf-dokumentti ja palvelu muuntaa dokumentin parhaansa mukaan taulukkolaskentaohjelmien ymmärtämään .xls-muotoon.

Muunnokset eivät aina ole täydellisiä, koska .pdf-dokumenttien rakenteen tulkitseminen ei ole yksikäsitteistä. Esimerkiksi välilyönnit ja askelsarkaimet (tab) sekoittavat etenkin taulukkodatan tulkintaa. Yksittäisten virheiden korjaaminen jälkikäteen Excel:ssä on kuitenkin nopeampaa kuin koko datan siirtäminen käsin .pdf-dokumentista taulukkolaskentaohjelmaan. Vastaavanlaisia palveluita löytyy Google:lla useita ja myös esimerkiksi Acrobat Reader Pro -versiosta löytyy tämä vastaava toiminnallisuus.

CometDocs-palvelun huonona puolena pitäisin sitä, että palveluun joutuu antamaan sähköpostiosoitteensa, joka ei aina ole järkevää ja tätäkin palvelua käytettäessä suosittelen käyttämään jotain ei-niin-tärkeää sähköpostiosoitetta.

Scraper

Keskusteltaessa datajournalismista kuulee usein puhuttavan erilaisten raapijoiden, skreippereiden ja ryömijöiden toteuttamisesta. Erilaisia ryömijöitä ja keräimiä on tämänkin blogin yhteydessä käsitelty. Keräimet toteuteutaan usein ohjelmoimalla etenkin jos tekijällä on tähän kompetenssia ja kiinnostusta, mutta olemassa on myös työkaluja, joilla tietoa voidaan kerätä Internetistä ilman kovaa insinööritaustaa.

Erittäin näppärä työkalu tiedon keräämiseen löytyy Google Chrome -lisäosana ja on nimeltään Scraper. Scraper:n käyttämiseksi tarvet siis Google Chrome -selaimen, jota suosittelen muutenkin pääasialliseksi selaimeksi kenelle tahansa. Scraper:n asentamisen jälkeen toiminnallisuutta voi käyttää millä tahansa www-sivulla klikkaamalla haluaamaansa kohdetta ja valitsemalla kontekstivalikosta "Scrape Similar...", jonka jälkeen ruudulle aukeavasta ikkunasta ovat nähtävissä kaikki muut sivulta löytyvät vastaavankaltaiset sisällöt (Kuva 2).

Valitsemalla kontekstivalikosta "Scrape similar..." voit hakea ja tallentaa tietoa www-sivulta. (Kuva 2)

Olen itse käyttänyt Scraper:a mm. ihmisten Facebook-kavereiden hakemiseen ja tallentamiseen, koska Facebook ei suoraan tätä toiminnallisuutta tarjoa. Facebook-kavereiden tapauksessa lataan ensin kaikki halutun käyttäjän Facebook-kaverit selaimeni sivulle, jonka jälkeen klikkaan yhtä heistä ja valitsen "Scrape Similar...", jolloin Scraper tunnistaa kaikki sivulta löytyvät vastaavat sisällöt eli juuri nämä halutut kaverit. Scraper:lla haetut tiedot on mahdollista viedä Google Docs -palveluun, josta ne voi ladata edelleen vaikka omalle koneelle Excel:ssä käsiteltäväksi.

Scraper Similar -toiminto ei aina suoraan toimi oikein vaan "polkua", jonka takaa samankaltaista sisältöä haetaan voi joutua muokkaamaan. Haettava sisältö määritellään XPath-kielen (pikaopas) avulla, joka vaatii hieman teknisempää ajattelua, mutta jota ei välttämättä siis tarvitse käyttää jos "Scrape Similar..." -toiminnallisuus osaa suoraan palauttaa haluttavat sisällöt.

Google Fusion Tables

Tämänkaltaista listaa tehdessä ei varmaan voi ohittaa Google Fusion Tables:a. Kyseessä on Google:n toteuttama palvelu, joka on erikoistunut taulukkomuotoisen datan visualisoimiseen sekä eri datakokoelmien yhdistämiseen. Palvelusta löytyvät komponentit mm. perinteisten viiva-, piirakka- ja pylväsdiagrammien tekoon, mutta palvelulla on myös mahdollista luoda kartta- sekä verkostovisualisointeja.

Palvelu toimii osana Google Drive -palvelua ja uusia Fusion Tables -taulukoita pääsee luomaan Uusi -> Lisää -> Taulukko -polun takaa, jonka jälkeen palvelu pyytää lataamaan palveluun taulukkotiedoston. Tietoa voidaan syöttää mm. .csv ja .kml-muodoissa, joista jälkimmäinen on etenkin pinta-alojen esittämiseen tarkoitettu tiedostomuoto. (Kuva 3)

Uusien Fusion Tables -dokumenttien luominen löytyy More -painikkeen takaa. (Kuva 3)

On huomioitavaa, että Fusion Tables on nimenomaan valmiin datan visualisointityökalu. Datan muokkausmahdollisuudet palvelussa ovat hyvin rajalliset, joten data kannattaa rakentaa mahdollisimman valmiiksi paikallisessa taulukkolaskentaohjelmassa tai Google Spreadsheet:ssä.

Loistava itseopiskelumateriaali Google Fusion Tables:n käyttöön (Tekijä: Tommy Kaas).

---

Tässä muutamia sovelluksia ja ohjelmia, joista itselleni on ollut hyötyä ja joiden käyttäminen ei lähtökohtaisesti vaadi koodaamista. Toivottavasti tästä on hyötyä.

Alkoholinmyyntitiedon visualisointia

Julkaisimme n. kuukausi sitten Eva Koskisen ja Radar:n kanssa jutun alkoholin myyntitiedoista. Ajattelin hieman valaista taustoja tarinan takaa, koska kyseessä oli lukijoita ja kuulijoita kiinnostanut datajournalistinen juttu, joka levisi myös muihin tiedostusvälineisiin.

Datan hankinta

Tilastojen ja datan hankkimisen ei useinkaan tarvitse poiketa luonteeltaan ns. normaalista tiedon hausta (kuten piirakkareseptien etsiminen) eikä alkoholinmyyntitilastojen etsiminen tehnyt tähän poikkeusta. Google on erinomainen työkalu ja hakulauseella "alkoholijuomien kulutus" löytää nopeasti Tilastokeskuksen sivuille, josta käy ilmi, että alkoholijuomien myyntitilastoa ylläpitää Terveyden ja hyvinvoinnin laitos (THL).

THL kerää erinäisiä terveyteen ja ihmisten hyvinvointiin liittyviä tilastoja, joihin kuuluvat mm. alkoholinmyyntitilastot. Tilastot pitävät sisällään kunnittaiset alkoholinmyyntimäärät litroittain juomatyyppikohtaisesti, puhtaana alkoholina sekä suhteutettuna asukasta kohden. Tilastot löytyvät THL:n sivuilta vuositasolla vuosittaisten raporttien yhteydestä (Valvivan sivut antavat ymmärtää, että tilastoja kerättäisiin myös kuukausitasolla).

Ainoa ongelma THL:n sivuilta saatavassa datassa oli, että se on .pdf-muodossa. PDF-muotoista dataa ei usein mielletä koneluettavaksi tai helposti automaattisesti käsiteltäväksi, mutta myös .pdf-dokumenttien käsittely on mahdollista. Mm. Acrobat Readerin Pro -versiosta löytyy toiminnallisuus, jonka avulla .pdf-muotoinen dokumentti on mahdollista muuntaa Excel-muotoiseksi, mutta saatavilla on myös ilmaisia työkaluja kuten esimerkiksi Cometdocs-palvelu, jota itse käytin. Vaikka muunnos ei ollutkaan täydellinen oli yksittäiset virheet helppo korjata käsin.

Myöhemmin ottaessani yhteyttä THL:ään sain myös selville, että THL ylläpitää Sotkanet-nimistä palvelua, josta on mahdollista hakea kaikkia THL:n tuottamia tilastoja monipuolisten rajaustyökalujen avulla ja datat ovat ladattavissa tietokoneluettavassa muodossa. Palvelu mahdollistaa myös suoraan yksinkertaiset datan visualisoinnit mm. karttojen muodossa. Tämänkaltaisten loistavien palveluiden markkinointiin voisi panostaa enemmänkin aikaa ja rahaa.

Kokeilut Google Fusion Tables -työkalulla

Google Fusion Tables on datan visualisointityökalu, joka on osa, nykyisin Google Drive nimellä, tunnettua palvelua (aiemmin Google Docs). Fusion Tablesiin on mahdollista ladata omia datataulukoita tai palvelusta on mahdollista hakea käyttöönsä muiden käyttäjien julkisia taulukoita. Fusion Tables mahdollistaa datan näyttämisen mm. kartta-, verkosto-, viiva-, piirakka- sekä pylväsvisualisulisoinnin muodossa. Kaikki komponentit ovat muutaman hiiren klikkauksen ulottuvissa.

Alkoholinmyyntitietodata oli kuntakohtaista, joten mielekästä oli kuvata data kunnittain Suomen kartalle. Fusion Tables:ssa kuntiin (ja yleensäkin paikkatietoon) perustuvan visualisoinnin toteuttaminen on helppoa, koska palvelusta on mahdollista hakea kuntanimiin perustuen paikkojen sijainnit. Sijainnin merkitään oletuksena ns. "täpillä" (marker), joille on dataan perustuen mahdollista esimerkiksi määrittää arvoa kuvaava väri.

Google Maps -komponentti, jota käytetään kartan piirtoon osaa kuitenkin tulkita myös kuntarajoja (maantieteellisiä alueita) kun ne syötetään KML-muodossa. Näin on mahdollista käyttää yksittäisten täppien sijaan kunnan pinta-alaa datan esittämiseen. Lopputulos on myös paljon miellyttävämmän näköinen visuaalisesti kuin käytettäessä täppiä. Toki tässä tapauksessa datan luonne ei myöskään tue täppien käyttöä, koska ilmiö ei tapahdu spatiaalisesti yhdessä pisteessä vaan data kuvaa suuremman pinta-alan käyttäytymisen keskiarvoa. Toisissa datoissa tietysti taas täpät ovat luontevia datan kuvaamiselle. (Kuva 1)

Google Fusion Tables:ssa hypoteesien erilaisten testaaminen on lähtökohtaisesti näppärää. (Kuva 1)

Google Fusion Tablesissa erilaisten hypoteesien kokeileminen on helppoa, koska mm. värivalintojen tekeminen onnistuu suoraan käyttöliittymäkomponenttien avulla. Tämä mahdollistaa isojenkin muutosten tekemisen nopeasti, joka esimerkiksi omassa toteutuksessa vaatii aina koodaustyötä. Fusion Tables:n ongelmia ovat, että tuotokset eivät erotu, koska ne näyttävät Google:n tuotteilta ja toisaalta, että datan joutuu luovuttamaan Google:lle, joka voi olla arkaluontoisten datojen kohdalla ongelma.

Goole Maps:n ja Google Fusion Tables:n ymmärtämä KML-muotoinen Suomen kuntarajat vuodelta 2011 sisältävä data on ladattavissa täältä.

Lopullinen toteutus HS:n kuntakoneella

Kuten olen tässä blogissa aikaisemminkin maininnut on Helsingin Sanomat ollut aktiivinen toimija suomalaisen datajournalismin saralla. Tähän toimintaan on kuulunut mm., että HS julkaisi toukokuussa toteuttamansa kuntakoneen avoimena lähdekoodina HS Next -blogissa. Kuntakonetta hyödynnettiin laajasti seuranneessa HS Open -tapahtumassa, jossa se näytti toimivuutensa erilaisten datojen esittämiseen.

Alkuperäinen HS:n toteutus kuntakoneesta oli tehty kuntaliitoksia silmällä pitäen, joten karttaa käyttääksemme jouduimme hieman muuntamaan sitä tarpeeseemme. Poistimme kartasta mahdollisuuden yhdistellä kuntia keskenään, mutta mahdollistimme samalla helpomman kunnan uudelleenvalitsemisen. Lisäksi teimme kartan kaksikielisenä sekä toteutimme siihen mahdollisuuden rajata piirron pelkkiin ruotsinkielisiin kuntiin. (Kuva 2)

Kartan värit perustuivat YLE:n uuteen ilmeeseen. Toteutus mahdollisti kartan näkökulman muokkauksen. (Kuva 2)

Toteutimme siis lopullisen ja julkaistun karta Helsingin Sanomien kuntakarttaan perustuen Google Fusion Tables toteutuksen sijaan, koska kuntakarttaan perustuva toteutus osoittautui visuaalisesti paremman näköiseksi ja lisäksi näimme, että omassa toteutuksessa pystyimme paremmin hallitsemaan sitä miten karttaa käytetään. Pyrkimys riippumattomuuteen ulkopuolisesta toimijasta ei sinällään ollut merkittävä tekijä päätöstä tehtäessä.

Jälkipyykki; mitä näimme, mitä opittiin

Radar teki keväällä useampia alkoholiin liittyviä juttuja radioon sekä nettiin ja siten tämä alkoholinmyyntikartta oli osa suurempaa juttujen kokonaisuutta. Lisäksi on huomioitavaa, että Radar:ssa päätuote on radio-ohjelma, jolle netti pyrkii tarjoamaan täydentävää sisältöä. Tässä tapauksessa nähtiin, että nettiin tehty uutinen keräsi hyvin paljon sivulatauksia ja että sisällöt tukivat hyvin toisiaan, koska radiossa pystyttiin keskittymään tiettyihin toimittajan valitsemiin näkökulmiin kun taas netissä pystyttiin tarjoamaan kohdennettua sisältöä kaikille siitä kiinnostuneille.

Saman alkoholinmyyntitiedon uutisointia nähtiin myös muilta suomalaisilta media-alan toimijoilta ja myös YLE Uutiset julkaisi oman uutisensa asiasta rikastettuna samalla kartalla, jota me olimme käyttäneet.

Risuja saimme lähinnä siitä, että kuntakartassa oli otettu huomioon vuoden 2013 kuntaliitokset, jotka eivät kuitenkaan olleet vielä varmistuneita. Esimerkiksi Siuntio oli liitetty Lohjaan ennenaikaisesesti, koska prosessi on vielä kesken. Pyrimme kuitenkin palvelemaan myös heitä, jotka olivat kokeneet itsensä väärin kohdelluiksi antamalla heille THL:n tarjoaman datan keskustelussa.

Yhteenvetona todettakoon, että kyseessä oli erittäin suosittuun aihealueeseen tehty datan karttavisualisointi, joka toi tehdylle jutulle huomattavaa lisäarvoa. Toteutus tuki päätuotetta eli radio-ohjelmaa ja toi myös sille lisäkuuntelijoita.