Tänä vuonna Apps4Finlandiin sopivia ajatuksia ja sovelluksia sovelluksia olikin kertynyt useampia. Nämä kuusi lähtivät mukaan kilpailuun:

Idea: Luonto ympärilläsi

Datan avaus: Ilmanlaatu rajapintana

Visualisointi: Ilmanlaadun mukaan vaihtuva kännykän taustaväri

Sovellus: Mobiiliperuskartta

Ja työpaikan puolesta:

Datan avaus: Kasviatlas-rajapinta – Putkilokasvien esiintyminen Suomessa

Datan avaus: Havaintoimoitin

Pari viikkoa sitten avasin rajapinnan, josta saa reaaliaikaista ilmanaatudataa. Yksi ajatus datan visualisoinnista oli asettaa älypuhelimen taustaväri muuttumaan ilmanlaadun mukaan, käyttäen virallista vihreä-kelta-punaista väriskaalaa.

Mutta minkä mittausaseman ilmanlaatutietoa pitäisi käyttää? Seuraava ajatus oli valita mittausasema automaattisesti sijaintitiedon perusteella, käyttäen Geolocation API:a. Tässä kuitenkin on pari ongelmaa.

Asemien tarkkoja sijaintitietoja ei ole saatavilla, ainakaan keskitetysti. Ilmanlaatuportaalissa on mukana 83 mittausasemaa, joita ylläpitävät kymmenet kunnat ja muut organisaatiot. Portaali näyttää sijainnit ainoastaan hyvin karkeilla kartoilla (ks. esim. Jyväskylä).

Jos tulossivu kuitenkin osaisi valita mittausaseman automaattisesti, osaisiko taustaväriä muuttava sovellus näyttää tällaisen sivun, ja päivittää sijainnin oikein? Toimivuus mahdollisimman monella eri laitteella on kuitenkin tärkeämpää kuin hieno automatiikka.

Suurin hankaluus automaattisessa paikan sijainnissa kuitenkin olisi se, että mittausasemien ilmanlaatutiedot ovat sovellettavissa vain suppealla alueella. Jos käyttäjä istuu metsän keskellä, mutta lähin mittausasema sattuu olemaan kaupungin keskustassa, ei aseman antamat tiedot kerro juuri mitään käyttäjän hengittämästä ilmasta. Parempi olsi valita lähin maaseutua edustava asema, joka kertoo ilmanlaadun vaihteluista suuremmalla mittakaavalla (esim. miten Suomenlahden laivojen rikkipäästöt tai naapurimaiden suuret metsäpalot vaikuttavat ilmanlaatuun tänään).

Parempi ja varmatoimisempi ratkaisu olisikin siis että käyttäjä itse valitsee seurattavan aseman oman kiinnostuksensa mukaan. Valinnan voi nyt tehdä mittausasemasivulta.

Miten voisin helposti seurata ilman laatua ja epäpuhtauksien määrää? Idea tähän lähti Open Knowledge -festivaalissa, jossa mm. sivuttiin ympäristön havainnointia sensoreilla. Arduinolla, Iobridgellä yms. välineillä voi helposti seurata esim. lämpötilaa ja ilmankosteutta, mutta erilaisten epäpuhtauksien seuranta onkin jo huomattavasti hankalampaa.

Saisiko datan jostain muualta, ammattilaisvälineillä ja -menetelmillä mitattuna? Saa: ilmanlaatuportaalissa esitetään ilmanlaatudataa eri puolilta Suomea lähes reaaliajassa (tuntikeskiarvoina). Enää tarvittaisiin avoin koneluettava rajapinta. Sellaista ainakaan toistaiseksi ole, joten ei muuta kuin tekemään: ilmanlaatudata rajapintana. Rajapinnan tekemisen taustoista ja, noh, erikoisuuksista alla tarkemmin.

Visualisointi

Miten datan visualisoisi, niin että ilmanlaatua tulisi todella seurattua? Seuranta kännykän kautta olisi kätevää, mutta en haluaisi taas yhtä uutta ikonia jo nyt täydelle näytölle; ei sitä kuitenkaan tulisi käytettyä. Ilmanlaatuindeksi esitetään tavallisesti väreillä, jotka ovat sinänsä helposti hahmotettavissa. Väriä voisikin käyttää taustavärinä.

Ainakin Androidille saa muutamia sovelluksia, jotka asettavat halutun verkkosivun taustakuvaksi, ja päivittävät sen säännöllisesti. Tämän lisäksi tarvitaan vain sivu, joka näyttää ilmanlaadun värinä (ja samalla myös mittausarvot). Tuloksena ilmanlaadun näkee sujuvasti kännykkää vilkaisemalla. Visualisointisivun voi valita tästä valikosta.

Rajapinnan tekeminen

Tämä on ollut tähän mennessä tekemistäni screen scraping -prosesseista haastavin.

Ilmanlaatuindeksi on tunnetuin mittari ilman laadulle. Se on saatavilla ilmanlaatuportaalista, mutta vain karttakuvana tai kaaviona. Koska tiedon irroittaminen kuvasta olisi hankalaa, kannattaa se laskea saatavilla olevien numeeristen mittaustulosten perusteella.

Ilmanlaatuindeksi määritetään eri saasteiden mittaustulosten perusteella: jos kaikkien näiden arvot ovat hyvän rajoissa, on myös indeksi ‘hyvä’. Jos yhdenkin pitoisuus nousee tyydyttäväksi, muuttuu myös koko indeksi tyydyttäväksi. Ja niin edelleen. Raja-arvot ovat saatavilla ilmanlaatuportaalin ja HSY:n sivuilta. Ilmanlaatuportaali antaa tarkemmat raja-arvot, joten seurataan niitä. Indeksin laskentaa hankaloittaa se, että kaikilta mittausasemilta ei ole saatavilla kaikkia mittaustuloksia. Ilmanlaatuindeksi pitää siis voida laskea myös puutteellisista tiedoista.

Saasteiden mittaustiedot saa näkyville ilmanlaatuportaalissa valikkosivun kautta. Tieto kaupungista, mittausasemasta ja mitattavasta saasteesta ovat valikkosivun GET-parametreissa. Tulossivu aukeaa valikkosivulla olevaan iframeen, jossa myös on aseman numero GET-parametrina. Myös päivämäärä pitää asettaa GET-parametrina, hieman eri muodossa valikko- ja tulossivulla. Kaupungin asetuksella ei käytännössä ole merkitystä, tulokset haetaan yksinomaan aseman numeron perusteella.

Mutta jos tulossivun avaa ilman että on ensin avannut valikkosivua, palauttaa palvelin internal server errorin. Valitun saasteen nimi välitetäänkin tulossivulle evästeellä. Scraperin on siis hallittava evästeet, ja käytävä ensin asettamassa ne valikkosivulla.

Tulossivulla on taulukko, jossa on kuluneen vuorokauden mittaustulokset tunneittain. Joka tasatunti taulukkoon ilmaantuu uusi rivi, jossa on kellonaika. Varsinainen mittaustulos tulee näkyville vasta hieman myöhemmin. Scraperin on siis hallittava sekä tilanne, jossa uusin mittaustulos on viimeisellä rivillä, että tilanne jossa se on toiseksi viimeisellä rivillä.

Joskus myös useampi rivi voi olla tyhjä. Dataa voi poistua palvelusta myös jälkikäteen, joten tyhjät rivit voivat olla missä kohtaa taulukkoa tahansa. Rajapinta hakee ja palauttaa nyt kaikki tämänpäiväiset mittaustiedot, sekä vielä erikseen viimeisimmän viimeisimmän saatavilla olevan.

Kun vuorokausi vaihtuu, on koko tulossivu ensimmäisen tunnin ajan tyhjä. Ensimmäisen tunnin keskiarvotulos ilmaantuu sille vasta joskus yhden jälkeen yöllä. Scraperin olisi siis osattava pyytää edellisen päivän valikko- ja tulossivua, jos tulosta ei vielä löydy kuluvan päivän sivulta.

Jos kaikki menee hyvin ja ilmanlaatuportaali on toiminnassa, rajapinta palauttaa ilmanlaatuindeksin tai valitun saasteen pitoisuuden (paitsi vuorokauden ensimmäisen tunnin – puolentoista aikana). Tätä pikku hiljaa rakennellessa systeemistä tuli ehkä turhankin monimutkainen. Rajapinnan koodi on Githubissa, joten sitä saa mieluusti tarkistaa ja parantaa: https://github.com/mikkohei13/airquality-finland

Luomus avasi eilen uuden verkkolomakkeen, jolla suuri yleisö voi kertoa luontohavainnoistaan. Kaikille avoimia havaintolomakkeita on ollut aiemminkin Hatikassa, mutta mikään niistä ei ole suunniteltu satunnaiskäyttäjille. Uusi lomake yrittää olla mahdollisimman helppokäyttöinen, mutta kerätä silti kaiken tarpeellisen datan.

Uutta tässä lomakkeessa on myös avoimuus: kaikki havainnot tulevat saman tien verkkoon kaikkien nähtäville sekä taulukkona että koneluettavana JSON-muodossa. Havaintoja voi käyttää Creative Commons Nimeä -lisenssillä. Yhteystietoja ei julkaista, eikä tarkkoja paikka ja aikatietoja mikäli havainnoija ei niin halua, mutta nekin pidetään tallessa mahdollista tarvetta varten.

Suomen vieraslajistrategia valmistui keväällä, ja ehkä sen ansiosta erilaisia vieraslajihavaintojen keruuhankkeita on alkanut pulpahdella esiin ympäri Suomea. Hyvä että havaintoja kerätään, mutta satunnaisen havainnoijan näkökulmasta tulos on kovin sekava. Esim. SLL:n sivuilla on listattu toistakymmentä paikkaa, johon havaintoja voi ilmoittaa.

Tausta-ajatuksena uudessa lomakkeessa onkin että erilaisten havaintojenkeruuhankkeiden ei tarvitsisi aina luoda omia havaintolomakkeitaan (tai käyttää sähköpostia), vaan ne voisivat ohjata ihmiset yhteen paikkaan, ja käydä myöhemmin poimimassa kertyneen datan käyttöönsä. Toimiiko tämä ajatus, vai tuleeko lomakkeita jatkossakin olemaan kymmeniä erilaisia? Suurimpana kompastuskivenä saattaa olla havaintojen kerääjien erilaiset vaatimukset; jos kaikki eri hankkeissa kerättävät tiedot koottaisiin yhdelle lomakkeelle, tulos olisi helposti liian monimutkainen ja karkottaisi merkittävän osan käyttäjistä. Pelkästään em. vieraslajilomakkeilla on kymmeniä erilaisia tietokenttiä torjuntatoimista yksityiskohtaisiin yhteystietoihin.

Tämä on havaintolomakkeen ensimmäinen versio, ja muutamia parannuksia (+ siistimpi ulkoasu) on jo mielessä. Miten havaintojen keräämistä tällä tai yleisesti kannattaisi sinun mielestäsi edistää?

One reason why I like Twitter more than Facebook or Google Plus:

Interesting content on Twitter marked with blue:

On Facebook:

And on Google+:

Larger and simpler content area, less clutter.

Hankin muutama viikko sitten ioBridge-moduulin ja siihen liitettävät lämpötila-, kosteus- ja valoisuussensorit. Nyt voin seurata olohuoneeni olosuhteita mistä tahansa!

ioBridge-moduuli on modeemiin liitettävä laite, johon voi liittää 1-4 sensoria. Sensorit liitetään moduulissa oleviin liittimiin, jonka jälkeen niiden mittaama data näkyy moduulin “kanavilla” 1-4. Tämän jälkeen mittaustuloksiin käsiksi ioBridgen verkkopalvelun kautta. Sensoreiden tilalle voi kytkeä myös muita analogisia tai digitaalisia laitteita, esim. servoja, X10-ohjaimia tai vaikka Arduinon, joita voi sitten ohjata tai seurata webin kautta.

Ensimmäinen projektini oli lämpö/kosteus/valoisuusloggerin rakentaminen kotiini. Tällaisella voi seurata esim. asuintilojen olosuhteita tai vaikka pakastimen lämpötilaa. Tässä yhteenveto mitä olen oppinut ioBridgen tekniikasta tähän mennessä. Virallisessa ohjewikissä on varsin kattavia ohjeita.

Tiedot talteen API:n kautta

Moduulin dataan pääsee käsiksi kahdella tavalla: ohjelmointirajapinnan (API) ja ioBridgen kojelaudan (dashboard) kautta. Käytin näistä itselleni tutumpaa eli ohjelmointirajapintaa. Oman moduulin tietoihin pääsee käsiksi antamalla rajapinnalle oman API key:n.

Tein skriptin, joka käy säännöllisesti hakemassa uusimman sensorien mittaaman datan rajapinnan kautta JSON-muodossa ja tallentaa sen MongoDB-tietokantaan (joka sopii mainiosti juuri tällaiselle datalle). Skripti ajetaan kymmenen minuutin välein cronjobilla. Tietokannassa olevan datan perusteella voi sitten generoida monenlaisia kaavioita tai tilastoja. Kokosin tätä varten tekemäni työkalut Githubiin muidenkin käytettäväksi.

Moduuliin ei siis pääse suoraan käsiksi, vaan sitä käytetään aina ioBridgen palvelimen kautta. Tämän ansiosta käyttäjän ei tarvitse välittää esim. muuttuvista IP-osoitteista. Laitteen voi myös siirtää vaikka kokonaan toiseen verkkoon ilman että asetuksia pitäisi muuttaa. (Uuden paikan nimi tai kuvaus kannattaa kirjata kojelautaan, sillä tällöin se tallentuu myös tietokantaan.)

Huomioonotettavaa API:n käytössä

Jos verkkoyhteys ei toimi oman ja ioBridgen palvelimen välillä, saattaa skripti hakea tyhjän JSON:in. Datan oikeellisuus on siksi aina tarkistettava ennen kun sitä käytetään tai tallennetaan. Oikeellisuuden voi tarkistaa esim. tarkistamalla onko [module][status]-kenttä olemassa.

Jos verkkoyhteys ei toimi moduulin ja ioBridgen palvelimen välillä, palautuu JSON:issa virheellisiä arvoja. Tämän takia kannattaa aina tarkistaa että [module][status]-kentän arvo on “Online”. Offline tarkoittaa että arvoihin ei voi luottaa.

Oma Saunalahden ADSL-yhteyden varassa toimiva moduulini on offline-tilassa 1-4 kertaa vuorokaudessa (kun dataa haetaan 10 min välein). En tiedä johtuvatko katkokset Saunalahdesta, ioBridgen palvelimesta vai jostain muusta.

Kojelaudan käyttö

Toinen tapa päästä käsiksi dataan on käyttää ioBridgen kojelautaa. Moduulille voi luoda sääntöjä, esim. määrätä sen lähettämään sensorin arvo palvelimelle minuutin välein. ioBridgen palvelimen voi sitten säätää reagoimaan moduulista tulevaan dataan, esim. lähettämään sen sähköpostitse tietyn raja-arvon ylittyessä. Näin dataa pääsee käyttämään ilman omaa ohjelmointityötä.

Sääntöjä ja toimintoja luodaan kojelaudassa wizard-tyyppisellä työkalulla. Koska vaihtoehtoja on paljon, ei oikean toiminnon löytäminen kuitenkaan ole aina helppoa.

API:n avulla tekemäni toiminnon voisi tehdä kojelaudan avulla seuraavasti:

1) Määrää moduuli lähettämään data palvelimelle määrätyin väliajoin:
1B) Tee moduuliin Onboard Rule “Push Update Rule” > Analog Input (Push at Interval).
1B) Valitse kanava ja määrittele väliaika sekunteina.
1C) Lopuksi Sync Rules, jolloin sääntö päivitetään moduuliin.
2) Määrää palvelin tekemään saapuvalle datalle jotain
2A) Tee Server Action “Analog Input Post”
2B) Säädä Trigger value sellaiseksi, että Action suoritetaan aina kun haluat.
2C) Täytä kentät esim.

http://posttestserver.com/post.php?dir=iob

humidity=%%input%%
3) Tee skripti, joka ottaa POST-datan vastaan ja tekee sillä jotain (esim. tallentaa tietokantaan)

Nyt moduuli lähettää väliajoin datan ioBridgen palvelimelle, joka lähettää sen edelleen valitsemaasi paikkaan. Jos haluat tehdä datalla jotain vain kun tietyt ehdot täyttyvät (esim. lämpötila on korkeampi kuin määrätty arvo), voit tehdä tämän joko Server Actionissa tai omassa skriptissä.

Tällä mallilla on joitakin plussia ja miinuksia suhteessa API:iin

Plussia
+Toimintoja pääsee hallitsemaan Dashboardin kautta.
+Server Actionien avulla voi luoda toimintoja (esim, sähköpostihälytyksiä) ilman omaa ohjelmointia

Miinuksia
-Sääntöjen ja toimintojen virittäminen on työlästä, etenkin jos haluaa saada datan useammalta kanavalta. Jokaiselle on tehtävä oma sääntö ja toiminto. Jos näitä haluaa muuttaa jälkikäteen, on vanha sääntö poistettava ja sen tilalle luotava uusi.
-Moduuli voi lähettää vain kanavan arvon ja aikatiedon. Muihin tietoihin (esim. raaka-arvoon tai paikkatietoon) ei pääse käsiksi.

ioBridgen kojalauta: kanavien data ja asetukset. Lämpötilasensori on tässä korkea koska sensori on digiboksin päällä: lämpötilasta voi seurata milloin boksi on käynnissä (esim. toimiiko ajastettu tallennus).

Viime viikolla julkaistiin Suomen 3. lintuatlaksen tulokset. Lintuatlaksessa on kyse pesimälintujen levinneisyyden kartoittamisesta. Suomi on jaettu sadan neliökilometrin ruutuihin, jonka jokaisen lajisto pyritään selvittämään mahdollisimman luotettavasti. Tuloksia voidaan käyttää mm. arvioitaessa levinneisyydessä tapahtuneista muutoksia. Konkreettisin tulos suuren yleisön näkökulmasta lienee lintukirjoissa olevat levinneisyyskartat.

Lintuatlas on toteutettu Suomessa kahdesti aiemmin: ensin 1970- ja sitten 80-luvulla. Toteutustapa on ollut aina sama: vapaaehtoiset lintuharrastajat tekevät kartoitustyön. Tämä on välttämätöntä, sillä kenenkään raha ei riittäisi vastaavan työn teettämiseen palkattuna. Uusimmassa atlaksessa tehtiin yhteensä yli 1,1 miljoonaa lintuhavaintoa 3848 ruudusta. (Vain 11 ruutua jäi kartoittamatta, nämäkin olivat lähes saarettomia ulkomeren tai juuri ja juuri Suomen puolella sijaitsevia raja-alueen ruutuja.)

Saadakseni mittakaavaa hankkeelle yritin arvioida kuinka kallista havainnointityö olisi, jos sitä tehtäisiin vain palkattuna. Pohjaksi otin omien atlashavaintojeni määrän ja niiden keräämisen käytetyn ajan*. Karkean arvion tulos: 6,3 miljoonaa euroa (133 henkilötyövuotta). Aikamoinen joukkoistamishanke!

Lähes kaikkien merkittävien valtakunnallisten linnustonseurantahankkeiden havainnointi toteutetaan Suomessa vapaaehtoistyönä. Näitä ovat atlaksen lisäksi esim. talvilintu-, piste- ja vesilintulaskennat ja pesäkorttitutkimukset. Seurantojen organisointi, tulosten kokoaminen ja analysointi puolestaan tehdään yleensä palkattuna työnä. Lisäksi seurantahankkeita toteutetaan paikallisemmalla tasolla, esimerkiksi nyt on käynnissä Rovaniemen lintuatlas. Nämä tehdään usein kokonaan vapaaehtoisvoimin. Lisäksi vastaavia projekteja on muillakin eliöryhmillä kasveista hyönteisiin.

Haasteita

Ongelmana seurantahankkeissa on ollut osallistujien väheneminen. Harrastus muuttaa muotoaan: kartoituksiin osallistuminen tuntuu olevan vähenemässä uudempien harrastusmuotojen kustannuksella (valokuvaaminen, harvinaisuuksien bongaus).

Toisena haasteena on työvälineiden kehittäminen. Kahden ensimmäisen atlaksen havainnot kerättiin paperilomakkeilla vuosittain, kolmannessa atlaksessa havainnot kerättiin verkossa ja tulokset olivat näkyvillä reaaliajassa. Tietojärjestelmien kehittäminen kaikille erilaisille hankkeille on kuitenkin hankalaa. Kussakin hankkeessa kerätään hieman toisistaan poikkeavia tietoja, ja hankkeita on kymmeniä erilaisia. Hankkeista vastaavat myös lukuisat eri tahot (Luonnontieteellinen keskusmuseo, Suomen ympäristökeskus, tieteelliset yhdistykset, Riista- ja kalatalouden tutkimuslaitos, Metsähallitus ym.). Koordinoinnin puute on johtanut siihen, että kukin rakentaa järjestelmiä omaan käyttöönsä. Koordinointia ja kehitystyötä kyllä muutama vuosi sitten esitettiin, mutta rahaa toteutukselle ei tietääkseni ole löytynyt.

Tilastoja

Tilastot havainnointiaktiivisuuden jakautumisesta on mielenkiintoisia. Havaintoja tallensi kaikkiaan n. 1500 henkilöä. Heistä ktiivisimmat 10 % tallensi yhteensä >60 % havainnoista ja aktiivisin prosentti (15 henkilöä) 20 % havainnoista. (Nämä ovat alustavia tuloksia; tarkempien lukujen laskeminen vaatisi mm. yhdessä tehtyjen havaintojen huomioimista. Ilmoittajien lisäksi mukana oli monesti myös muita: yhteensä havaintoihin on kirjattu n. 5000 ihmisen nimi.)

Mielenkiintoista katsottavaa on myös havaintomäärien kertymisestä kertova kaavio. Lintuatlashavaintoja tehdään etenkin kesä-heinäkuussa, parhaimmillaan yli 4000 päivässä. Havaintoja kertyy vuosi vuodelta vähemmän: osallistuvat kyllästyvät atlakseen, ja toisaalta näkevät että suurin osa ruuduista alkaa jo olla kartoitettu riittävän hyvin. Koska tallentajia on paljon, on myös erilaisia tapoja käyttää tallennusjärjestelmää. Monet ovat kirjanneet tallennuspäivän havaintopäivämäärän tilalle (näkyy piikkeinä talvikaudella), mikä hankaloittaa datan käyttöä pesinnän ajoittumiseen tutkimiseen.

Lisätietoja

• Laajempaa pohdintaa joukkoistamisesta ympäristöalalla (2007)
• Joukkoistamisen merkitys ympäristöalalla (2009)
• Atlaksen tuloksista ja osallistumisesta
  (Taviokuurna-blogi)
• Lintuatlaksen tulossivusto (Luonnontieteellinen keskusmuseo)

* Käytin arvion pohjana omaa retkeilyäni:
-omia atlashavaintoja 4057 kpl
-havainnointia karkeasti arvioiden kaksi tuntia joka päivä touko-heinäkuussa viiden vuoden ajan = 920 tuntia
-havaintoja atlaksessa yhteensä 1179610 kpl
-mediaanipalkka 2654 e/kk (Tilastokeskus 2009)
-sivukulukerroin 1,5

Huuhkaja on taas viime päivinä viihtynyt Narinkkatorin liepeillä Helsingin keskustassa. Helsingin kantakaupungin alueella on jo vuosia elellyt useita huuhkajia, parhaimmillaan reviirejä lienee ollut 3-4 koiraalla tai pariskunnalla. Ravintoa on hyvin saatavilla: rottia, kaniineja ja puluja.

Kevättalvi on helpoin aika nähdä ja kuulla huuhkajia. Kampin lintu on torkkunut päivisin hyvin näkyvillä etenkin Kampin kauppakeskuksen räystäillä, hotelli Scandicin valomainostornissa ja Sokoksen katolla. Eilen huuhkaja intoutui huutamaankin: matala “huu” kuului selvästi kaupungin hälinän yli, kun sitä osasi kuunnella.

Tämä onkin mielenkintoinen juttu huuhkajissa: useimmat helsinkiläiset ovat kuulleet cityhuuhkajista ja Bubista, mutta harva lienee niitä nähnyt tai kuullut. Narinkkatorin läpi kulkee kuitenkin jatkuva virta ihmisiä, valtaosa tietämättä että huuhkaja istuu kymmenen metriä korkeammalla hyvin näkyvissä ja kuultavissa, mikäli vain pysähtyisi ja katsoisi oikeaan suuntaan.

Tänään otin kaukoputken mukaan ja pystytin sen Narinkkatorin laidalle kesken iltapäiväruuhkan. Huuhkaja istui tuttuun tapaan kauppakeskuksen räystäällä. Muutaman minuutin kuluttua ensimmäinen ohikulkija – ulkomaalainen turisti – tuli kyselemään mitä katselen. Pian ympärille alkoi kerääntyä varovaisempia paikallisiakin. Kaikki olivat tohkeissaan, kameroita kaivettiin taskuista, kavereille soiteltiin ja joku liikuttui kyyneliin asti. Tavallinen päivä kaupungilla, ainakin huuhkajalle.

Kampin huuhkaja kaukoputken läpi kamerakännykällä kuvattuna.

Kun joku katselee (kaukoputkella) ylöspäin, leviää kiinnostus ympäröiviinkin. Puolen tunnin aikana parikymmentä ihmistä tuli kyselemään mitä katselemme. Osa uskalsi kysyä voiko kaukoputkellakin katsoa, muutamat yrittivät ottaa huuhkajasta kuviakin putken läpi. Parhaimmillaan tuntui että joka toinen ohikulkija katseli tai osoitteli huuhkajan suuntaan.

Suurin spektaakkeli syntyi kun kauppakeskuksen parvekkeelle ilmaantui pari ikkunanpesijää. He eivät huomanneet huuhkajaa, mutta huuhkaja kyllä heidät. Aluksi se tarkkaili pesijöitä tiiviisti, mutta tuntui sitten menettävän mielenkiintonsa. Vasta kun pesijät olivat suoraan huuhkajan alla – ehkä 3-4 metrin päässä, se havahtui kunnolla, otti siivet alleen ja liiteli hieman kauemmaksi. Yleisön kohahti kuin urheilukisoissa, joissa kotijoukkue melkein teki maalin.

Kannattaa katsella kaupungilla välillä muutakin kuin varpaitaan tai kännykkäänsä. Huuhkaja lienee paikalla huomennakin.

PS. Pari Ilta-Sanomien toimittajaakin osui paikalle, kuvasi huuhkajaa putken läpi ja sanoi tekevänsä jutun verkkolehteen. Saa nähdä miten tulkitsivat sanomiseni. (Lisäys: juttu julkaistiin illalla.)

Huuhkajan ihmettelyä aiemmin päivällä.

Espanjalainen huuhkaja.
Kuva danielguip: Hibou grand duc (Bubo bubo). Creative Commons BY-NC-SA 2.0.

I’m building a simple collection management system Hyntikka* to be used mainly (or first) with insect collections of the Finnish Museum of Natural History. We currently don’t have any such system in place for insects. Plans to get (build/buy/modify) a more sophisticated museum-wide system are underway, but a practical system for insects is needed asap. Hopefully Hyntikka will either develop into better system, or help in figuring out what are the most important real-life needs for such a system and its user interface.

Main features of Hyntikka

• Browser-based user interface
• Supports different types of GUID’s, currently HTTP URI’s and LSID’s
• Data import from flat-file CSV-tables (ad hoc format)
• Basic data validation (handling fatal and non-fatal errors separately)
• Simple search tools
• Label printing tools:
  • Creates either unique specimen labels from pre-entered data or labels
    en masse with unchanging data (and unique ID’s)
  • Supports QRCode and Code 39 -barcodes
  • Templates for different kinds of labels (small, large, entomological,
    botanical…)
• Persistent data structure: all versions of the data are preserved
• Unicode support (UFT-8)
• User authentication via Windows Active Directory
• Full daily backups
• Currently about 80 data fields. More can be added at ease.
• Ability to handle data on different taxa (insects, plants, fungi…),
  object types (specimens, direct or published observations…) levels (single
  individuals, boxes, trays…) and primary & secondary data.

More powerful tools for querying, analyzing, publishing and sharing the data are being built in a separate data warehouse -project (Mustikka). Hyntikka will be connected to the warehouse with automatic ETL**-process using XML-files (ABCD-compatible FMNH2008-schema). Connection to LSID and HTTP URI -resolvers will be made directly or via the data warehouse.

Hyntikka does not contain tools for maintaining taxonomic information (hierarchy, synonyms…) about the names used with the specimens. Taxonomy will be taken care with a separate system.

So far I have used roughly 5 weeks for building Hyntikka (under 10 months), with zero funding. Testing the system with pilot data (c. 15000 records) is underway. No online demo available, sorry.

Software used: PHP 5 with Codeigniter and Zend frameworks, SQL Server 2008, with some Javascript and Google Maps.

* Hyntikka = abbreviation for hyvin yksinkertainen kokoelmatietokanta, very simple collection database.
** ETL = Extract-Transform-Load

Keskustelu tiedon ja datan avoimuudesta on nousussa (ks. esim. Julkinen data -kirja). Päätöksentekoon ja hallintoon liittyvästä datasta puhutaan paljon, mutta julkishallinnolla on hallussaan myös paljon tieteellistä tutkimusdataa. Biologina tiedän etenkin ympäristöhallinnon ja ympäristöön liittyviä viranomaistoimia harjoittavien organisaatioiden datasta. Tieteellisen ympäristödatan avoimuuteen liittyy omanlaisiaan ongelmia:

Rahoitus ja urakehitys kohdistuvat tutkimusartikkeleiden tekijöille. Datan kerääjää ja julkaisijaa ei palkita. Datan julkaisemisesta voi siten olla haittaa; jos joku muu ehtii tuottaa sen pohjalta artikkelin ensimmäisenä, ei muiden tutkimus enää saakaan huomiota tai edes pääse julkaistavaksi. (Tämän todellista vaaraa on tosin kritisoitu.)

Joskus kuulee puhuttavan päällekkäisen työn välttämisestä. Ilman perusteluja tämä kuitenkin kuulostaa edellisen kohdan peittelyltä; ei haluta että kukaan muu käyttää dataa samantyyppisessä tutkimuksessa kuin mitä itsellä on meneillään, jotta kilpailua olisi vähemmän.

Datan käyttäminen väärin nähdään usein uhkana. Datan kerääjä voi haluta varmistua että käyttäjä ymmärtää todella aihealuetta, tuntee datan ongelmakohdat ja puutteet, eikä vedä johtopäätöksiä ottamatta puutteita huomioon.

Toinen väärinkäytön pelko liittyy luontoselvityksiin. Tavallinen tapa tehdä luontoselvitys on mennä maastoon tekemään kartoitus sopivilla menetelmillä ja työvoimalla. Jos avointa dataa samalta alueelta on kuitenkin saatavilla, on houkutuksena jättää hintavat maastotyöt tekemättä ja käyttää vain olemassa olevaa dataa, riippumatta siitä kuinka puutteellista se on (esim. kerätty selvityksen kannalta väärään aikaan, epäsystemaattisesti ja epäkattavasti).

Suojelunäkökohdat. Etenkin tarkan sijainnin julkaiseminen uhanalaisista (esim. muuttohaukka) tai ristiriitoja herättävistä lajeista (esim. merimetso, maakotka) saattaa edistää häirintää, salametsästystä ja munien keräämistä myyntitarkoituksiin. Jotkin lajit saattavat pesiä samoilla paikoilla sukupolvesta toiseen jopa satoja vuosia, joten parinkymmenen vuoden suoja-aikakaan ei välttämättä estä väärinkäyttöä.

Periaatteellisella tasolla tutkimusdatan avoimuutta on edistetty (esim. keskusmuseon avoimuusperiaatteet), mutta käytännön tasolla askeleet ovat olleet pieniä. Avoimuus nähdään monesti vain sähköpostitse ammattilaisten välillä pyydettäessä tapahtuvana tiedonvaihtona: “Jos pyydät dataa perustellen, niin harkitsemme asiaa ja ehkä lähetämme sen Excel-taulukkona”.

Parhaimmillaan avoimuus olisi kuitenkin oletusarvoista ja data olisi kaikkien saatavilla koneluettavassa muodossa. Miten tällaista avoimuutta voisi edistää?

Muuttamalla rahoitusmalleja. Organisaatioiden tuloksellisuutta voisi mitata paitsi julkaistujen tutkimusartikkelien myös avoimesti julkaistun datan määrällä ja laadulla.

Asettamalla avoimuusvaatimuksia rahoitukselle ja julkaisemiselle. Joillakin aloilla rahoittajat ja tieteellisten julkaisujen kustantajat vaativat jo datan saattamista avoimesti saataville. Tämän kuitenkin pitäisi levitä laajemmalle, etenkin kustantajien piirissä. Muuten julkaiseminen tahtoo suuntautua niihin lehtiin jotka eivät vaadi avoimuutta.

Muuttamalla kirjoittaja- ja siteerauskäytäntöjä tieteellisissä julkaisuissa. Voitaisiin esimerkiksi vaatia että datan kerääjät ovat mukana kirjoittajien nimiluettelossa, jolloin hekin saisivat uuden rivin julkaisuluetteloonsa ja lisäpisteitä rahanjakolaskelmiin.

Luomalla selkeät ja tieteellisesti perustellut salausperiaatteet sekä suoja-ajat suojelun kannalta oleelliselle datalle.

Asettamalla tiukemmat vaatimukset luontoselvitysten pohjana käytettävälle datalle.

Tarjoamalla hyödyllisiä esimerkkejä siitä mitä avoimella datalla voisi tehdä. Ajatus datan automaattisesta jatkojalostamisesta lienee monille vieras, varsinkin jos oletetaan että sitä tekisivät muut kuin alan ammattilaiset. Toteutetut esimerkit valaisisivat asiaa paremmin kuin pelkkä puhe.