Päivämäärä
Kategoriat
Tekijä
-
Hami Kekkonen
Dataa kaikkien käyttöön?
Excel, CSV, pc-axis, Shapefile, KML, TAB, XML, JSON?? Erilaisten tiedostoformaattien kirjo on suuri, samoin avoimen datan käyttäjien. Miten ja missä muodossa dataa kannattaisi avata, jotta mahdollisimman moni pääsisi hyötymään siitä?
HRI:n alkutaipaleella avasimme paljon pikkuisia Excel-tiedostoja. Avaukset olivat kokeilevia ensiaskelia avoimen datan maailmaan. Harjoituksia. Opettelimme itsekin. Opimme. Jokainen avaus tuntui pieneltä voitolta: jälleen jokin uusi taho oli ymmärtänyt, innostunut, halunnut kokeilla, lähtenyt siihen meidän kanssamme.
Ensimmäisiä paikkatietoaineistoja, dataa, johon liittyy sijainti, avasimme nelisen vuotta sitten. MapInfo-muodossa, Helsingin omassa koordinaatistossa, jossa Kallion kirkko on maailman napa. Opettelin samalla itsekin paikkatiedon perusteita. Facebookissa käytiin vilkasta keskustelua aineistoista sekä formaatti- että koordinaattimuunnoksista. Kollegan kanssa ilahduimme suuresta mielenkiinnosta. Ymmärsimme myös, että meidän tulee tehdä osa siitä muunnostyöstä, jota avoimen datan yhteisö teki. Helpottaa datan käyttöönottoa.
Huomasimme, että mitä laajempi aineisto, sitä enemmän se kiinnostaa käyttäjiä. Erityisesti paikkatietoon tartuttiin heti, kokeiltiin aineistoa ja epäsuomalaisesti jopa keskusteltiin siitä. Paikkatietoaineistoilla myös saatiin melko nopeasti tehtyä jotain näyttävämpää, toiminnallistakin.
Joitain rajapintoja oli auki jo HRI:n alkutaipaleella. Ne palvelivat parhaiten sovelluskehittäjiä ja niiden dataa hyödyntäen tehtiin useita arkea helpottavia kännykkäsovelluksia, kuten joukkoliikenteen reittioppaita. Mietimme, että muitakin datoja olisi hyvä saada auki suurempina kokonaisuuksina ja rajapinnan kautta.
Tähän suuntaan datan avaaminen on hienosti lähtenyt vähitellen menemään. Pienistä tiedonmurusista on alkanut rakentua suurempia kokonaisuuksia.
Olin hiljattain kertomassa avoimen datan ilosanomaa journalistiopiskelijoille. Heillä oli ongelmia löytämänsä datan kanssa. Eräs oli löytänyt Esri Shape -muodossa olevat liikennemeluvyöhykkeet. Hän oli googlannut, löytänyt maksuttoman QGIS-ohjelman, ladannut sen koneelleen. Saanut aineiston auki. Mutta sitten tuli kysymys: miten datasta löytää tarvitsemansa tiedon.
Toinenkin opiskelija viittasi. Hän ymmärsi hyvin, miksi dataa avataan rajapintojen kautta. Mutta miten hän ohjelmointitaidottomana saa sieltä tietoa? Kysymys ei ollut minulle uusi.
Ymmärrän hyvin, että HRI:n alkutaipaleella avatut pienet Excel-tiedostot eivät palvele sovelluskehittäjiä. Toisaalta myös Excel-tiedostoille on tarvitsijansa. Esimerkiksi taannoin eräs Excel-muodossa dataa avannut taho kyseli minulta neuvoa. Heiltä oli pyydetty avaamaan datansa myös CSV-muodossa, mutta heillä ei ollut aavistustakaan, mikä CSV on saati miten sellainen tehdään. Sama ongelma on varmasti vielä monilla käyttäjilläkin.
Avattava data on tärkeää tarjota useammassa eri formaatissa, jotta mahdollisimman moni käyttäjä pääsee hyödyntämään sitä. Rajapinta on kätevin tapa avata suuria kokonaisuuksia ja palvella sovelluskehittäjiä. Mutta pelkkä rajapintaratkaisu voi sulkea monia ulkopuolelle. Miten palvella heitäkin, miten tarjota data mahdollisimman laajalle käyttäjäkunnalle?
HRI:n ensimmäiset avaukset, ne pienet Excel-tiedostot, alkavat muodoltaan olla vähitellen historiaa. Datakatalogin suuressa tietomäärässä pienet tiedostot jäävät muiden jalkoihin, sekoittavat hakuja, pirstaloivat aikasarjoja. Tieto on hajallaan pieninä palasina, vaikeasti hyödynnettävissä.
Tätä ryhdymme ensi vuoden alkupuolella ratkomaan. Suunnitteilla on mm. pienten Excel-tiedostojen yhdistely ja päällekkäisyyksien poistaminen. Tämä tarkoittaa myös HRI:n avoimien aineistojen kokonaismäärän rajua pudotusta. Itse datasisältö ei häviä minnekään, jakelutapa vain on järkevämpi. Mietimme ratkaisuja, joilla palvella mahdollisimman monia ja joilla tarvittava tieto löytyisi nykyistä paremmin.
Opettelu jatkuu.
Missä muodossa sinä toivoisit dataa avattavan? Ovatko rajapinnat ratkaisu kaikkeen? Onko tuttu ja turvallinen (?) Excel hyvä formaatti, vai tulisiko siitä luopua kokonaan? Miten avata dataa mahdollisimman laajan käyttäjäkunnan saataville? Toivon, että tämä kirjoitus toimisi keskustelunavauksena, joten kommentoi, kerro meille mielipiteesi, osallistu, vaikuta. Oikeasti. Arvostamme mielipidettäsi.
Hienoa, että mietitte datan julkaisuformaatteja. Toivon kovasti, että kiinnittäisitte myös huomiota datan loogiseen rakenteeseen, teknisen esitysmuodon lisäksi. Aihe ei ole ihan helppo, mutta tämä artikkeli on hyvä johdanto siihen: http://vita.had.co.nz/papers/tidy-data.pdf
Teknisiltä esteettömyys- ja käytettävyys ominaisuuksiltaan CSV ja CSV-niput http://dataprotocols.org/tabular-data-package/ ovat hyvä formaatti, vaikka formaatin tunnettuus onkin huono ja siihen liittyviä parhaita käytäntöjä ei noudateta. Niitä voitaisiin ratkoa ohjeistuksella, koulutuksella ja CSV:n linttaamisella http://csvlint.io/
Kannatan lämpimästi Petrin pointtia datan rakenteen huomioimisesta. Aineiston luettavuus ja jatkokäyttö helpottuvat huomattavasti jos aineisto on jo siistissä muodossa. Toki tähän liittyy mahdollisesti paljon työtä HRI:n päässä.
CSV-nippujen (data-package) käyttäminen on myös hyvä ajataus. Tähän mennessä tämä on mielestäni paras standardi nimenomaan ”pienen datan” paketoimiseen ilman korkeaa teknistä kynnystä.
Jep. Isolle datalle tarvitaan rajapinta, mutta silloinkin rajattujen/filtteröityjen CSV-dumppien generoiminen itsepalveluna olis varmasti monille mieluisa.
Kiitos Petri linkeistä! Toki kiinnitämme (mahdollisuuksien mukaan) huomiota myös datan rakenteeseen. Itse miellän jo CSV-tiedostossa olevan datan koneluettavassa muodossa olevaksi – tosin kun testasin yhtä CSV-muodossa olevaa aineistoa csvlint:illä, sain viitisen huomiota sen rakenteesta. Opettelu jatkukoon 🙂
Ehdottamaasi rakennetta voisi kokeilla esim. vaihtoehtoisena formaattina aluksi muutamaan datasettiin, katsoa, millaista palautetta saamme käyttäjiltä ja seurata analytiikkatiedoista, miten paljon niitä aineistoja ladataan. Yksinomaan tällaisessa muodossa dataa ei ainakaan vielä voi jakaa, sillä Exceleillekin on käyttäjänsä.
Hami: loistava idea tuo kokeilulähtöisyys!
CSV:n data voi yhtälailla olla epäpuhdasta, jolloin data käytännössä ei ole koneluettavaa vaan datan käyttäjä joutuu itse tekemään siitä koneluettavaa (oma kokemukseni, että ”eri tiedostopäätteet” eivät kauheasti käyttöä hidasta, mutta looginen rakenne kylläkin). Tuolla toisessa kommentissani viittasin esimerkkinä Helsingin nuoret alueittain 2007 -tiedostoon. Sen voi toki suoraan muuntaa CSV:ksi, mutta yhtään enempää koneluettava siitä ei silloin tule, koska looginen rakenne on koneellisen käyttämisen näkökulmasta viallinen.
Erittäin hyvä kanava tuommoisille kokeiluille on muuten GitHub:in Gist https://gist.github.com/ Sinne vaan oma tunnus pydeen ja esimerkkiä julki. Git-maailma ehdottomasti opiskelemisen arvoinen, jos haluaa ymmärtää datan käyttäjien prosesseja ja maailmaa.
Sinänsä datan sisäänlukeminen onnistuu kyllä useimmilla työkaluilla myös Excel-tiedostoista (esim. R). Ongelma on siinä, että Excel mahdollistaa hyvien luovien kirjaamistapojen käytön, eli tiedostoista tulee usein vaikeselkoisia (muille kuin tekijälle).
Tuolla Twitterissä https://twitter.com/pe3/status/664708714247659520 ideoimme, kuinka CSV:n tuomista eri ohjelmiin voisi helpottaa. Käyttäjä valitsisi dataportaalin data-sivulla mihin ohjelmaan haluaa datan tuoda ja portaali kertoisi heti ohjeet. Samaan tapaan kuin REST-API-dokumentaatiot nykyään monesti tekevät.
Tiedostamme tämän Exceliin liittyvän ongelman ja mahdollisuuksien mukaan pyrimme muokkaamaan datan rakenteiseen muotoon.
Joskus Excel-data on sellaisessa muodossa, että on joko julkaistava data sellaisenaan ei-koneluettavassa muodossa tai jätettävä avaus tekemättä. Mielestäni kuitenkin on parempi avata data sellaisenaan kuin jättää avaus tekemättä.
Aina parempi julkaista kuin olla julkaisematta, mutta olisi ehkä aika alkaa koulutuksessa, dataportaalin käyttöliittymässä ja kaikessa viestinnässä hienovaraisesti kertomaan, että se on ”likaista”.
Mahtavaa että datan avaamista kehitetään!
Voin kommentoida tutkimuksen näkökulmasta, että tiedostomuotoja oleellisemmalta tuntuu aineiston helppo siirtäminen tilasto-ohjelmistoon. Yritin itse joku vuosi sitten R:llä ladata aineistot suoraan aluesarjat.fi-sivustolta, mutta tämä osoittautui yllättävän hankalaksi, vaikka tiedostomuotojen käsittelyyn löytyi paketteja.
Toki tiedostot voi ladata aina csv-muodossa omalle koneelleen ja sieltä mihin vain tilasto-ohjelmaan. Hienoa olisi kuitenkin, jos aineistot saisi sillä tavoin helposti lähestyttäviksi, että esimerkiksi tällainen vain tilasto-ohjelmien tasolla koodaamiseen tutustunut ihminen saisi ne helposti ladattu vaikka sitten R:llä suoraan verkosta. Voi toki myös olla, että tähän onkin tapoja, joita en vain tunne.
Nettiyhteydenkään takana olevan CSV-tiedoston lukeminen ei pitäisi olla mikään ongelma R:lle. Aiheesta mm. täällä https://theodi.org/blog/how-to-use-r-to-access-data-on-the-web Eriasia sitten, kannattaako dataa hakea jokaisella ajokerralla uudestaan. Itse tekisin paikallisen cachen.
Monesti ihmiset eivät osaa eritellä tekniseen esitysmuotoon ja datan loogiseen rakenteeseen liittyviä ongelmia. Jos heillä on ollut ongelmia loogisen rakenteen littyen Excel-tiedostoa käyttäessä, he ajattelevat, että xls-tiedostot ovat huono formaatti.
Esimerkiksi jos katsotaan Helsingin nuoret alueittain 2007 -tiedostoa http://www.hri.fi/fi/dataset/helsingin-nuoret-alueittain-2007 , sitä on mahdoton käyttää koneellisesti ilman mittavaa tiedon loogisen rakenteen uudelleenorganisointia (niin sanottua datan siivoamista). Tiedosto on ilmiselvästi tehty ihmiskäyttäjille luettavaksi, eikä tietokoneen prosessoitavaksi. Tiedostoa käyttävään ohjelmaan (tai käyttämistä edeltävään datan siivousohjelmaan) täytyy esim. ensin kertoa, että taulukossa 1.1. välillä rivin merkitys on summarivi, välillä rivit ovat tyhjiä jne. Erittäin paljon virhealtista työtä, joka voitaisiin välttää jos datan julkaisija tuottaisi ensimmäisessä kommentissani vinkkaamaa siistiä (tidy) dataa.
Tarkennettakoon siis, että aluesarjat.fi:ssä nuo tiedostot, joiden kanssa olen törmännyt ongelmiin ovat olleet px-muodossa. Näidenkin lataamisen pitäisi periaatteessa onnistua, mutta ongelmia ilmeni silti joissain tiedostoissa.
CSV-tiedostojen lataamisessa en ole itsekään törmännyt ongelmiin, niissä on enemmänkin työtä tuon siistimisen kanssa niin kuin hyvin kommentoit.
Se haluaako tiedostot sitten ladata omalle koneelleen vai päivittää suoraan netistä ohjelmaan lienee kiinni lähinnä käyttötarkoituksesta. Parasta tietenkin, jos molemmat tavat onnistuvat helposti!
Kiitos kaikille ajatuksista ja kommenteista!
Jatketaan keskustelua toki täälläkin, mutta lisäksi tervetuloa jutustelemaan livenä tänään klo 15-18 avoimen datan avoimeen konttoriin Helsinki Think Companyn tiloihin (Vuorikatu 5).
Melkein vuosi sitten saatiin kirjailtu avoimeen paikkatietoon liittyviä asioita: https://github.com/AvoinPaikkatieto
Sieltä voi katsoa ohjeita avaajille ja myös ohjeistusta käyttäjille.
Saa vapaasti käyttää, forkata ja antaa palautetta. Kai me sitä ylläpidetään.
Vanha keskustelu 10.11.2015 klo 18:55 / Petri Kola
Hienoa, että mietitte datan julkaisuformaatteja. Toivon kovasti, että kiinnittäisitte myös huomiota datan loogiseen rakenteeseen, teknisen esitysmuodon lisäksi. Aihe ei ole ihan helppo, mutta tämä artikkeli on hyvä johdanto siihen: http://vita.had.co.nz/papers/tidy-data.pdf
Teknisiltä esteettömyys- ja käytettävyys ominaisuuksiltaan CSV ja CSV-niput http://dataprotocols.org/tabular-data-package/ ovat hyvä formaatti, vaikka formaatin tunnettuus onkin huono ja siihen liittyviä parhaita käytäntöjä ei noudateta. Niitä voitaisiin ratkoa ohjeistuksella, koulutuksella ja CSV:n linttaamisella http://csvlint.io/
Vanha keskustelu 11.11.2015 klo 9:38 / Aleksi Karhula
Mahtavaa että datan avaamista kehitetään!
Voin kommentoida tutkimuksen näkökulmasta, että tiedostomuotoja oleellisemmalta tuntuu aineiston helppo siirtäminen tilasto-ohjelmistoon. Yritin itse joku vuosi sitten R:llä ladata aineistot suoraan aluesarjat.fi-sivustolta, mutta tämä osoittautui yllättävän hankalaksi, vaikka tiedostomuotojen käsittelyyn löytyi paketteja.
Toki tiedostot voi ladata aina csv-muodossa omalle koneelleen ja sieltä mihin vain tilasto-ohjelmaan. Hienoa olisi kuitenkin, jos aineistot saisi sillä tavoin helposti lähestyttäviksi, että esimerkiksi tällainen vain tilasto-ohjelmien tasolla koodaamiseen tutustunut ihminen saisi ne helposti ladattu vaikka sitten R:llä suoraan verkosta. Voi toki myös olla, että tähän onkin tapoja, joita en vain tunne.
Vanha keskustelu 12.11.2015 klo 10:32 / Petri Kola
Nettiyhteydenkään takana olevan CSV-tiedoston lukeminen ei pitäisi olla mikään ongelma R:lle. Aiheesta mm. täällä https://theodi.org/blog/how-to-use-r-to-access-data-on-the-web Eriasia sitten, kannattaako dataa hakea jokaisella ajokerralla uudestaan. Itse tekisin paikallisen cachen.
Monesti ihmiset eivät osaa eritellä tekniseen esitysmuotoon ja datan loogiseen rakenteeseen liittyviä ongelmia. Jos heillä on ollut ongelmia loogisen rakenteen littyen Excel-tiedostoa käyttäessä, he ajattelevat, että xls-tiedostot ovat huono formaatti.
Esimerkiksi jos katsotaan Helsingin nuoret alueittain 2007 -tiedostoa http://www.hri.fi/fi/dataset/helsingin-nuoret-alueittain-2007 , sitä on mahdoton käyttää koneellisesti ilman mittavaa tiedon loogisen rakenteen uudelleenorganisointia (niin sanottua datan siivoamista). Tiedosto on ilmiselvästi tehty ihmiskäyttäjille luettavaksi, eikä tietokoneen prosessoitavaksi. Tiedostoa käyttävään ohjelmaan (tai käyttämistä edeltävään datan siivousohjelmaan) täytyy esim. ensin kertoa, että taulukossa 1.1. välillä rivin merkitys on summarivi, välillä rivit ovat tyhjiä jne. Erittäin paljon virhealtista työtä, joka voitaisiin välttää jos datan julkaisija tuottaisi ensimmäisessä kommentissani vinkkaamaa siistiä (tidy) dataa.
Vanha keskustelu 12.11.2015 klo 11:39 / Joona Lehtomäki
Kannatan lämpimästi Petrin pointtia datan rakenteen huomioimisesta. Aineiston luettavuus ja jatkokäyttö helpottuvat huomattavasti jos aineisto on jo siistissä muodossa. Toki tähän liittyy mahdollisesti paljon työtä HRI:n päässä.
CSV-nippujen (data-package) käyttäminen on myös hyvä ajataus. Tähän mennessä tämä on mielestäni paras standardi nimenomaan “pienen datan” paketoimiseen ilman korkeaa teknistä kynnystä.
Vanha keskustelu 12.11.2015 klo 12:20 / Petri Kola
Jep. Isolle datalle tarvitaan rajapinta, mutta silloinkin rajattujen/filtteröityjen CSV-dumppien generoiminen itsepalveluna olis varmasti monille mieluisa.
Vanha keskustelu 12.11.2015 klo 11:45 / Hami Kekkonen
Kiitos Petri linkeistä! Toki kiinnitämme (mahdollisuuksien mukaan) huomiota myös datan rakenteeseen. Itse miellän jo CSV-tiedostossa olevan datan koneluettavassa muodossa olevaksi – tosin kun testasin yhtä CSV-muodossa olevaa aineistoa csvlint:illä, sain viitisen huomiota sen rakenteesta. Opettelu jatkukoon 🙂
Ehdottamaasi rakennetta voisi kokeilla esim. vaihtoehtoisena formaattina aluksi muutamaan datasettiin, katsoa, millaista palautetta saamme käyttäjiltä ja seurata analytiikkatiedoista, miten paljon niitä aineistoja ladataan. Yksinomaan tällaisessa muodossa dataa ei ainakaan vielä voi jakaa, sillä Exceleillekin on käyttäjänsä.
Vanha keskustelu 12.11.2015 klo 12:16 / Petri Kola
Hami: loistava idea tuo kokeilulähtöisyys!
CSV:n data voi yhtälailla olla epäpuhdasta, jolloin data käytännössä ei ole koneluettavaa vaan datan käyttäjä joutuu itse tekemään siitä koneluettavaa (oma kokemukseni, että “eri tiedostopäätteet” eivät kauheasti käyttöä hidasta, mutta looginen rakenne kylläkin). Tuolla toisessa kommentissani viittasin esimerkkinä Helsingin nuoret alueittain 2007 -tiedostoon. Sen voi toki suoraan muuntaa CSV:ksi, mutta yhtään enempää koneluettava siitä ei silloin tule, koska looginen rakenne on koneellisen käyttämisen näkökulmasta viallinen.
Vanha keskustelu 12.11.2015 klo 12:18 / Petri Kola
Erittäin hyvä kanava tuommoisille kokeiluille on muuten GitHub:in Gist https://gist.github.com/ Sinne vaan oma tunnus pydeen ja esimerkkiä julki. Git-maailma ehdottomasti opiskelemisen arvoinen, jos haluaa ymmärtää datan käyttäjien prosesseja ja maailmaa.
Vanha keskustelu 12.11.2015 klo 11:50 / Joona Lehtomäki
Sinänsä datan sisäänlukeminen onnistuu kyllä useimmilla työkaluilla myös Excel-tiedostoista (esim. R). Ongelma on siinä, että Excel mahdollistaa hyvien luovien kirjaamistapojen käytön, eli tiedostoista tulee usein vaikeselkoisia (muille kuin tekijälle).
Vanha keskustelu 12.11.2015 klo 12:02 / Petri Kola
Tuolla Twitterissä https://twitter.com/pe3/status/664708714247659520 ideoimme, kuinka CSV:n tuomista eri ohjelmiin voisi helpottaa. Käyttäjä valitsisi dataportaalin data-sivulla mihin ohjelmaan haluaa datan tuoda ja portaali kertoisi heti ohjeet. Samaan tapaan kuin REST-API-dokumentaatiot nykyään monesti tekevät.
Vanha keskustelu 12.11.2015 klo 12:28 / Hami Kekkonen
Tiedostamme tämän Exceliin liittyvän ongelman ja mahdollisuuksien mukaan pyrimme muokkaamaan datan rakenteiseen muotoon.
Joskus Excel-data on sellaisessa muodossa, että on joko julkaistava data sellaisenaan ei-koneluettavassa muodossa tai jätettävä avaus tekemättä. Mielestäni kuitenkin on parempi avata data sellaisenaan kuin jättää avaus tekemättä.
Vanha keskustelu 12.11.2015 klo 13:54 / Petri Kola
Aina parempi julkaista kuin olla julkaisematta, mutta olisi ehkä aika alkaa koulutuksessa, dataportaalin käyttöliittymässä ja kaikessa viestinnässä hienovaraisesti kertomaan, että se on “likaista”.
Vanha keskustelu 12.11.2015 klo 16:25 / Aleksi Karhula
Tarkennettakoon siis, että aluesarjat.fi:ssä nuo tiedostot, joiden kanssa olen törmännyt ongelmiin ovat olleet px-muodossa. Näidenkin lataamisen pitäisi periaatteessa onnistua, mutta ongelmia ilmeni silti joissain tiedostoissa.
CSV-tiedostojen lataamisessa en ole itsekään törmännyt ongelmiin, niissä on enemmänkin työtä tuon siistimisen kanssa niin kuin hyvin kommentoit.
Se haluaako tiedostot sitten ladata omalle koneelleen vai päivittää suoraan netistä ohjelmaan lienee kiinni lähinnä käyttötarkoituksesta. Parasta tietenkin, jos molemmat tavat onnistuvat helposti!
Vanha keskustelu 12.11.2015 klo 12:37 / Hami Kekkonen
Kiitos kaikille ajatuksista ja kommenteista!
Jatketaan keskustelua toki täälläkin, mutta lisäksi tervetuloa jutustelemaan livenä tänään klo 15-18 avoimen datan avoimeen konttoriin Helsinki Think Companyn tiloihin (Vuorikatu 5).
Vanha keskustelu 12.11.2015 klo 17:12 / Pekka Sarkola
Melkein vuosi sitten saatiin kirjailtu avoimeen paikkatietoon liittyviä asioita: https://github.com/AvoinPaikkatieto
Sieltä voi katsoa ohjeita avaajille ja myös ohjeistusta käyttäjille.
Saa vapaasti käyttää, forkata ja antaa palautetta. Kai me sitä ylläpidetään.