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

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

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

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

Avoin data apuun

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

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

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

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

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

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

Onko data sijoitettavissa kartalle?

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

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

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

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

Onko data luokiteltu järkevästi?

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

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

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

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

Onko datan tekstimassaa mahdollista analysoida?

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

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

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

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

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

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

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

Tekninen ratkaisu

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

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

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

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

Miten luokittelu syntyi?

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

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

Mikä oli lopputulos?

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

Mitä seuraavaksi?

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

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

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

Teimme Tampereen kaupungille palautejärjestelmäselvityksen vuoden 2021 lopulla. Kuten monilla kunnilla, myös Tampereella on käytössä useampi palautekanava kaupunkilaisten palautteiden vastaanottamiseksi. Osa järjestelmistä on karttapohjaisia, eli palautteelle valitaan kartalta sijainti, jonka oheen kirjoitetaan lisätiedot. Osa on puhtaasti tekstipohjaisia, joissa paikkatieto kerätään tekstinä.

Monesti tällaisia järjestelmiä käytetään myös toiminnanohjaukseen. Kuntalaisten merkkaamat palautteet, esimerkiksi ilmoitus rikkinäisestä katuvalosta tai tyhjentämättömästä roska-astiasta, poimitaan raportointipuolelta kunnossapidon työlistoille ja tehdyt työt kuitataan järjestelmään. Järjestelmän työraportteja voidaan käyttää lopulta töiden laskutuksessa. Käytännössä siis palaute ei ole pelkästään palaute, vaan osa työlistaa ja lopulta tuote, joka laskutetaan.

Mutta mitä käy, kun järjestelmiä on useita, eivätkä ne kommunikoi keskenään? Jos vikailmoitus on annettu väärään järjestelmään tai siihen liittyvät korjaustoimet pitää välittää tiedoksi toista järjestelmää käyttävälle tiimille, pitää oikea henkilö etsiä ja palaute välittää esimerkiksi sähköpostitse. Vaikka työntekijöiden manuaalinen palautteiden uudelleenlähetys ei sinänsä kuulosta työläältä, pitää muistaa että palautteita tulee vuosittain järjestelmiin helposti tuhansia. Lisäksi työntekijöiden varsinainen tehtävä on korjata vikoja, ei etsiä oikeita henkilöitä tai välittää väärinkohdennettua palautetta.

Mitä hyötyä jaetusta rajapinnasta?

Avoimen standardin mukaisena ratkaisuna palauteruljanssiin on Open311. Kyseessä on kansainvälinen rajapintastandardi, joka on suunniteltu nimenomaan sijaintipohjaisen sähköisen palautteen vastaanottamiseen ja käsittelyyn. Mikäli tiedolla on sijainti ja ominaisuustieto, sitä voidaan käsitellä Open311:n avulla. Standardin keskeisenä pyrkimyksenä on yhtenäistää eri kaupunkien ja muiden julkisten tahojen tuottamia palautelomakkeita ja muita palautejärjestelmiä standardisoinnin avulla. Kyseessä ei ole yksittäinen sovellus tai tuote, vaan tapa varmistaa järjestelmien välinen tekninen yhteentoimivuus. 

Standardin toteutukset voivat olla moninaisia, sillä esimerkiksi jo olemassaoleviin järjestelmiin voidaan lisätä rajapintatuki Open311:tä hyödyntäen. Parhaimmillaan standardi, joka tunnetaan myös nimellä GeoReport v2, helpottaa sekä palautteen antamista että käsittelyä. Suomessa Open311 on käytössä mm. Helsingin kaupungilla sekä SYKE:llä – maailmalla standardi on käytössä mm. New Yorkin, Toronton ja Lissabonin kaupungeilla.

Standardin johtoajatuksena on, että kansalaisten eri järjestelmien kautta antama sähköinen palaute ohjataan kulkemaan Open311-rajapinnan kautta. Samaan palautejärjestelmäkokonaisuuteen voi kuulua useita eri verkkosivustoja tai sovelluksia, joiden kautta saatu palaute saadaan keskitettyä yhtenäiseen palauteprosessiin. Verrattuna siihen, että käytössä on monia erillisiä ja suljettuja järjestelmiä, jotka eivät keskustele keskenään, mahdollistaa jaettu palauterajapinta mm. kaiken vastaanotetun palautteen tarkemman seurannan, analyysin ja raportoinnin sekä erilaiset automatisoidut prosessit. Rajapintayhteyttä voidaan hyödyntää myös toiseen suuntaan, eli kommunikointiin palautteenantajan kanssa: järjestelmissä kirjatut vastaukset palautteet voivat kulkea rajapinnan kautta, rajapintaan voi tehdä erilaisia kyselyitä ja kartoittaa palautteiden käsittelyn etenemistä. 

Tilanteessa, jossa palautekanavia on useita ja ne eivät keskustele keskenään, voisi Open311 olla avuksi. Sen sijaan, että palautteet etenisivät palautekanavista suoraan erillisiin järjestelmiinsä, ne voisivat ohjautua ensin Open311-rajapintaan, josta ne välittyvät eteenpäin. Kun kaikki palautteet ohjautuvat rajapinnan kautta, voidaan siihen ohjelmoida automatisoituja prosesseja esimerkiksi palautteiden kohdentamiseksi oikeille henkilöille ja myös seurata niiden kulkua. Jos palautetta annettaessa käyttäjää pyydetään määrittämään palautteelle kategoria, voi rajapinta kohdistaa sen perusteella palautteen oikealle vastuuhenkilölle.

Käytännössä tämä voi toimia monen palautejärjestelmän mallissa niin, että yhdessä palautejärjestelmässä annettu palaute menee paitsi kyseistä järjestelmää käyttävälle yksikölle, myös palautteen kategorian perusteella toiselle yksikölle tiedoksi. Tämä voi olla kätevää erityisesti tilanteissa, joissa jokin alue tai vastuualue on useamman kuin yhden yksikön vastuulla. Kun palaute menee kategorian perusteella kahteen osoitteeseen, myös toinen yksikkö näkee, mitä palautteelle tehdään ja tarvitseeko heidän auttaa asian kanssa. Jos taas käytössä on vain yksi palauteportaali, jonka kautta kaikki palautteet annetaan, voi rajapinta lähettää kategorian perusteella palautteen oikealle henkilölle. Kummassakaan tapauksessa palautteenantajan tai palautteen käsittelijän ei tarvitse itse etsiä oikeita henkilöitä ja yhteystietoja, vaan automatisointi varmistaa oikean henkilön löytymisen.

Jotta tämä automatisointi toimii optimaalisesti, on käyttäjän tietenkin pitänyt osata määritellä kategoria alunperin oikein. Vaikka mikään rajapinta ei itsessään pysty korjaamaan palautteenantajan antamien tietojen mahdollisia virheitä, voi tässä tapauksessa palautteen käsittelijä luokitella palautteen käsin uudestaan. Tämän jälkeen palaute menisi automaattisesti eteenpäin uuden kategorian mukaiselle käsittelijälle. Toinen vaihtoehto voi olla Helsingin kaupungin malli, jossa luokittelun hoitaa kaupungin asiakaspalvelu. Isossa kaupungissa palautteen luokka saattaa muuttua useammankin kerran kunnes se löytää lopullisen käsittelijänsä, mutta tämä vaihtoehto vaatii enemmän manuaalista työtä.

Rajapintojen hyödyntäminen voi myös helpottaa palautteen siirtoa Open311-standardia tukeviin työnohjausjärjestelmiin, sovelluksiin tai vaikkapa raportteihin. Hyvältä rajapinnalta palautteen matkaa saadaan suoraviivaistettua, jolloin palautteet eivät vahingossa jää kirjaamatta eikä samaa palautetta kirjata moneen kertaan eri palautejärjestelmiin. Tapauksissa, joissa palautteenantaja antaa samasta asiasta monta palautetta tai saman palautteen eri järjestelmiin, voi olla mahdollista myös automatisoinnilla niputtaa palautteet yhdeksi kokonaisuudeksi. Tämä vaatii esimerkiksi käyttäjän tai palautteen tunnistamista esimerkiksi käyttäjänimen, nimen tai vaikkapa IP-osoitteen perusteella, mutta helpottaa palautteen käsittelyä ja kokonaiskuvan saamista tilanteesta.

Lyhyesti

Ylipäänsä palautteenantoprosessin keskittäminen ja automatisointi sujuvoittaa palautteen käsittelyä ja vähentää tarvetta väärin kohdennetun palautteen uudelleenohjaamiselle. Open311-rajapinnan kautta käsiteltyä palautetta voidaan myös tarkastella ja monitoroida erillisillä valvonta- ja raportointityökaluilla, jotka tukevat standardia.

Järjestelmien keskinäinen rajapinta voi olla avuksi silloin, jos

• vikailmoituksia annetaan väärään järjestelmään, 
• vikailmoituksia pitää välittää eteenpäin toista järjestelmää käyttävälle tiimille,
• halutaan varmistaa, että vikailmoitus tulee käsitellyksi,
• halutaan seurata palautteen kulkua ja käsittelyaikaa,
• halutaan kommunikoida palautteenantajan kanssa ja raportoida työn tilasta,
• halutaan suoraviivaistaa palautteen siirtymistä työnohjausjärjestelmiin ja sähköisille työlistoille tai
• halutaan yleisesti sujuvoittaa palautteen käsittelyä

Open311 toimii hyvänä ratkaisuna mikroarkkitehtuuriin, joka koostuu useammasta palautejärjestelmästä, mutta sitä voidaan käyttää myös yhden palautejärjestelmän mallissa. Kuitenkin sen tarjoama teknisen yhteentoimivuuden merkitys korostuu, kun käytössä on useampi eri palautejärjestelmä. Jo olemassaoleviin järjestelmiin voidaan lisätä rajapintatuki Open311:n avulla, ja esimerkiksi Oskari-karttapalveluun on kehitetty kokeellinen Open311-tuki. Tämä mahdollistaa palautteen antamisen Oskarin karttakäyttöliittymän avulla Open311-rajapinnan kautta sekä aikaisemmin annetujen palautteiden kyselyn ja visualisoinnin kartalla. Toisaalta standardia voi käyttää myös muuhun: Open311-rajapintaa hyödyntävien sovellusten avulla voidaan kerätä kaupunkilaisilta ideoita kaupunkisuunnitteluun tai kerätä tietovarantoa kaupunkiympäristöstä. Jos Open311 alkoi kiinnostamaan, meihin voi olla yhteydessä!

Kaavojen tuotanto on taidelaji. Ne ovat hyvin monipuolisia karttatuotteita, joissa eri sidosryhmien näkemykset vaikuttavat lopputulokseen. Usein nämä päätökset ovat piilossa erilaisissa muistioissa ja dokumenteissa ja kaavan tulkinta vaatii osaamista. Tulevaisuudessa kaavan käyttäminen ja tulkinta voi olla helpompaa ja päätöksentekoon johtaneet prosessit avoimempia. Siihen ainakin tähtää kaavoituksen tietomallityö. 

Teimme syksyllä Suomen ympäristökeskukselle (SYKE) testausta, miten kuntien kaavoja voi tuottaa vuonna 2021 valmistuneen kaavatietomallin avulla. Testauksessa oleellista oli tarkastella, pitääkö mallia muuttaa tai lisätä siihen jotain, ja miten käytännön työ kunnissa voitaisiin toteuttaa. Lopulta myös tutkimme, saadaanko tietoja mallista ulos helposti ja miltä ne voisivat näyttää.

Ennen kuin päästään testituloksiin, alla vielä vähän taustoitusta aiheeseen.

Mitä on tietomallipohjainen kaava?

Digitaalisen tietomallipohjaisen kaavan tavoitteena on koneluettavuus ja tiedon harmonisointi. Sitä kautta voidaan mahdollistaa erilaiset käyttötapaukset, joissa tietoja tarvitaan. Kaavan tietomallityötä on tehty Suomessa ympäristöministeriön toimesta, ja tämänhetkinen asema- ja yleiskaavan tietomalli soveltamisohjeineen löytyy täältä. Tietomalli on tässä tapauksessa relaatiotietokanta, joka sisältää useita toisiinsa linkittyneitä tauluja ja koodilistoja. 

Tietomalli on tapa kuvata tietojen rakennetta ja sisältöjä. Sen avulla voidaan esittää tietojen yhteyksiä toisiinsa. Tietomallinnusta voi tehdä eri tasoilla: loogisesta mallista fyysiseen malliin. 

Digitaalinen kaava ei vielä ole koneluettava

Tällä hetkellä Suomen asema- ja yleiskaavat voivat olla digitaalisia, mutta ne eivät ole harmonisessa muodossa eli yhteiskäyttöisiä. Lähivuosikymmenien kaavat on tehty nykyisen lainsäädännön mukaisesti (MRL-laki §5.2.1999/132) ja niitä löytyy usein vain kirjallisessa muodossa (kuva, pdf, paperi). Uusimmissa aineistoissa lähtötiedot voivat olla digitaalisia, mutta ominaisuuksiltaan ja geometrioiltaan ne ovat monimuotoisia. Lainsäädännön muutosta tarvitaan, jotta kunnissa mahdollistuu digitaalisen yhteismitallisen kaavatiedon tuotanto yhteisen kaavatietomallin mukaan. 

Koneluettavuus tarkoittaa sitä, että tieto on rakenteistettu niin, että kone tai sovellus pystyy käsittelemään tietoja. Formaatteja voivat olla esimerkiksi XML, JSON, CSV. Sen sijaan esimerkiksi PDF ei ole konelutettava.

“Haluan tietää kuinka paljon Suomessa on kaavoitettu viheralueita vuonna 2022”

Suhteellisen helppo kysymys, mutta käytännössä siihen on mahdotonta tällä hetkellä vastata. Kaavatietomallin ja yhtenäisten koodistojen avulla vastaus voidaan jossain vaiheessa antaa. Se vaatii kuitenkin paljon työtä. Kun kaavatiedot kerätään yhteen samassa mallissa, tähän ja useisiin muihin kysymyksiin pystytään vastaamaan. Kansallisen tason tietojen kerääminen voi liittyä esimerkiksi ilmastonmuutoksen torjuntaan ja hiilijalanjäljen arviointiin. Yhtenä tärkeänä osana on mm. kunnan omien prosessien tehostaminen, kuten rakennuslupien myöntäminen tai kaavoituksen seuranta. Myös kiinteistöverotuksen määrittely on yksi oleellinen käyttötapaus. 

Jotta nämä käyttötapaukset ja monet muut tarpeet saadaan täytettyä, kaavatietoja pitää harmonisoida. Tällä hetkellä tarkoitus on ensisijaisesti tuottaa uudet kaavat kaavatietomallien mukaan, mutta joissain kunnissa voi olla perusteltua digitoida myös vanhoja kaavoja. Tällöin on luultavasti pakko avata uusi kaavoitusprosessi ja hyväksyttää muutokset tai määrittää, että osa kaavoista ei ole digitaalisessa muodossaan lainvoimaisia. 

Lopputavoitteena on, että kaavatiedot kerätään kansallisesti yhteen. Samalla tavalla toimitaan esimerkiksi kiinteistötietojen ja rakennustietojen osalta. SYKE on vastuussa rakennetun ympäristön tietojärjestelmän (RYTJ) kehittämisestä, joka kerää kaavatiedot yhteen. RYTJ kehitetään useampaa eri maankäyttötietojärjestelmää tukevaksi. RYTJ:n ensivaiheen toteutus määriteltiin vuonna 2021 ja järjestelmän rakentaminen aloitetaan vuoden 2022 aikana. Käyttöönotto alkaa lainsäädännön valmistuttua vuonna 2024. Prosessi vaatii vastaanottavan tietojärjestelmän ja kuntien omat suunnittelu- ja rekisterijärjestelmät. Lisäksi tarvitaan paljon työtä mm. sanastojen ja käsitteiden kanssa. 

Yhteentoimivuus

Yhteiset koodistot ovat oleellinen asia tietojen harmonisoinnissa. Niitä voi ajatella avainsanoina, joita voi olla vain rajallinen määrä. Pelkästään samoja koodeja käyttämällä päästään jo pitkälle. Mutta koodeista pitää sopia ja siksi sanastotyö on usein aikaavievää. Kaavojen osalta hyödynnetään Suomessa ympäristöministeriön “Semanttisen yhteentoimivuuden teemaryhmää” ja sen alaryhmiä. 

Yhteentoimivuusalustalle (esim. https://koodistot.suomi.fi) kerätään käsitteitä, joita käytetään tietomalleissa. Myös tietomallit kuvataan yhteentoimivuusalustalle (https://tietomallit.suomi.fi).  Kaavojen osalta alustalle viedään mm. asema- ja yleiskaavan kaavamääräyslajit eli koodit, jotka kuvaavat jotain kaavamääräystä. Kaavamääräyksiä ovat vaikkapa rakentamisen määrä, ääneneristävyys sekä asumisen alue. Tällä hetkellä esimerkiksi asemakaavan osalta listalla on 277 koodia eli kaavamääräyslajia.

Tietojärjestelmien kyvykkyydet

Tietomallit pitää myös ottaa käyttöön maankäyttötietoja tuottavissa organisaatioissa: kunnissa ja kaavakonsultointia tarjoavissa yrityksissä. Nykyiset suunnittelujärjestelmät eivät aina edes tue relaatiotietokantamalleja. Tietojärjestelmiä pitää siis kehittää uusien määrittelyjen mukaisesti. Kaavatietomalli tarvitsee relaatiotietokannan, johon tiedot syötetään käyttöliittymäkerroksen avulla. Relaatiotietokantoja ovat esimerkiksi kaupallinen Oracle Spatial tai avoimen lähdekoodin tuote PostgreSQL ja sen PostGIS-paikkatietolisäosa. 

Historia- ja elinkaaritiedot ovat oleellisessa osassa kaavatietomallia. Ideana on, että kaavatietojen hyödyntäjä voisi päästä tutkimaan koko kaavaprosessia sen syntyhetkestä lähtien. Jos kohteita eli geometriaa tai ominaisuustietoja muutetaan, pitäisi tieto muutoksesta tallentaa. Erityisesti jos kaava siirtyy elinkaaressa seuraavaan vaiheeseen – vaikkapa luonnoksesta ehdotukseksi – pitää päivittyä myös vuorovaikutustapahtuma ja siihen liittyvä aikaleima. Kaavatietomallissa tämä hoidetaan yksilöivien tunnisteiden ja aikaleimojen avulla. 

On siis mahdollista, että kaava piirretään (eli tuotetaan vektoritiedot) ohjelmistolla, jossa ei ole taustalla relaatiotietokantaa ja tiedot siirretään vasta tietyssä vaiheessa tietokantaan. Tällöin on pidettävä huolta kohteiden geometrioiden uniikeista tunnisteista (ID), jotta elinkaaritiedot pysyvät eheänä. Tätä varten tarvitaan luultavasti tietojärjestelmiin konverttereita, jotka huolehtivat tietojen eheydestä tietokannan ja piirto-ohjelmiston välillä.

Työprosessit muuttuvat ja se on hyvä juttu

Kun suunnittelujärjestelmä mahdollistaa kaavatietomallien mukaisen tiedon tuotannon, siirtyminen uudentyyppiseen tekemiseen vaatii myös kaavoittajilta uudenlaista työskentelytapaa. Kaavatietomallien mukainen tekeminen ohjaa työtä siten, että oleellista on syöttää mahdollisimman paljon koneluettavaa tietoa kaavasta. Kaava ei näin enää ole pelkästään visuaalinen tuote. 

Luonnosteluvaiheessa pitää jo kirjata joitain tietoja kaavakohteista. Toki niitä voi prosessissa muokata niin ominaisuuksien kuin geometriankin osalta. Ensimmäinen kaavatietomallin mukainen vaihe on kaavan vireilletulo, joka vaatii esimerkiksi löyhän aluerajauksen sekä OAS:n liittämisen aluerajaukseen. 

Käyttöönottoprosessi voi olla pitkä, ja siihen pitää varautua ja ottaa tarpeeksi aikaa siirtymään. Uuden järjestelmän käyttöönotto ja opettelu vievät aina resursseja. Vanhojen kaavatietojen siirtokin voi olla perusteltua kunnan omien toimintojen kehityksen osalta. 

Suunnittelujärjestelmät

Kaavan tuotannon käyttöliittymän pitää huomioida kaavatietomallin laatusäännöt. Tällaisia on esimerkiksi se, että tietylle kaavamääräykselle ei voi antaa kuin numeerisia arvoja ja toisille puolestaan vain vapaata tekstiä. Suunnittelujärjestelmän on myös luotava kopioita kaavamääräyksistä, sillä tietojärjestelmän näkökulmasta kahdella kaavakohteella ei voi olla samaa kaavamääräystä vaan vähintään niiden ID pitää olla eri. Huomioitava myös on, että esimerkiksi tietojen versiointiin liittyen tarvitaan RYTJin kautta globaalisti uniikit tunnukset.

Gispo on tehnyt testejä tietomallin toimivuuden osalta QGISillä. Sitä varten rakennettiin syksyllä 2021 kevyt työtila tietojen syöttämiseen PostGIS-tietokantaan. PostGIS-kantaan luotiin fyysinen tietomalli kaavatietomallin määrittelyjen perusteella. Espoon ja Valkeakosken asemakaava-aineistot vietiin tietomalliin. 

Testeissä kävi nopeasti ilmi, että mallin laatusäännöissä on paljon ehdollisuuksia: käytännössä QGISin puolelle pitää rakentaa lisäosa tietojen syöttämiseen tai monipuolisia triggereitä PostGISin puolelle. Pelkällä attribuuttilomakkeiden muokkauksella ei saada toteutettua haluttuja kaavoittajan työtä helpottavia toimintoja. Tällä hetkellä toimivaa valmista työkalua QGISissä tähän työhön ei siis ole, mutta sen suunnittelu ja rahoituksen hankinta on käynnissä. 

Kaavakohteiden digitointiin tarvitaan myös kehitystyötä vaikka soveltuvia editointityökaluja QGISissä jo jonkun verran onkin. Toiveissa on kuitenkin kehittää niitä intuitiivisemmiksi. Tätä varten saimme Gispolle opinnäytetyöntekijän Metropolialta, joka pohtii asiaa meille kevään aikana. Hänen löydöksistään lisää varmasti keväämmällä!

Kaavoittajalle soveltuvia QGIS-työkaluja:

• Editoinnin perustyökalut
• Tarttumisen asetukset (snapping)
• Advanced digitizing (esim. kohteiden leikkaus, siirto, reikien teko)
• Muodot (kaaret, ympyrät, neliöt) 
• Advanced digitizing -työkalut (vierekkäiset  linjat, kulmat, suorakulmiot)
• Taitepistetyökalu (x-y-editori)
• Kaavoituksen tyylikirjastot QGISille asemakaavan kuvaustekniikka tai yleiskaavan kuvaustekniikka.
• Kaavoituksen QGIS layout-mallit QAAVA-repositoriosta qpt-tiedostoina

Ja sitten testitulokset!

Kuten edellä olevasta huomaa, tietomallityö on monipuolista hommaa. Testeissä ei havaittu erityisen kriittisiä kehityskohteita itse tietomalliin, mutta suunnittelujärjestelmien prosesseja se haastaa. Visualisoinnista tulee myös mielenkiintoista. 

Tässä esimerkit Espoon ja Valkeakosken asemakaavoista. Niissä viety kaavamääräykset tietomallin mukaan, mutta päätöstietoja eri vaiheista ei tässä vielä päästy testaamaan. 

Demo Valkeakosken asemakaavan tietomallirakenteesta.

Demo kaavakohteen ja -määräyksen lisäämisestä Espoon asemakaavaan.

Gispolla on pitkä kokemus asiakkaiden kouluttamisesta paikkatieto-ohjelmistojen käyttöön. Ylivoimaisesti eniten toteutamme QGIS-peruskoulutuksia aloitteleville käyttäjille. Lisäksi meiltä saa apua PostGISin, GeoServerin ja QFieldin käyttöön sekä edistyneemmille käyttäjille jatkokursseja mm. lisäosakehityksestä. Koulutukset koostuvat aihepiiriin johdattelevasta luennoista sekä itse tehtävistä harjoituksista. Olemme pyrkineet suunnittelemaan harjoitukset siten, että ne ovat mahdollisimman yleisluonteisia sopiakseen kaikille käyttäjille eri organisaatioista ja erilaisilla lähtötiedoilla. Harjoitusten suorittamista varten jaamme myös aineistopaketin, joka sisältää suomalaisia, avoimesti julkaistuja paikkatietoaineistoja.

Koulutuksista saamamme palaute on ollut enimmäkseen positiivista ja kiittelevää, mikä tietysti ilahduttaa sekä kouluttajaa että koko koulutusten suunnittelutiimiä. Yksi yleinen kehitysehdotus kuitenkin toistuu palautteissa: osallistujat toivovat, että harjoituksissa olisi käytetty enemmän heidän omia aineistojaan, tai että harjoitustehtävät olisivat sopineet paremmin juuri heidän työtehtäviinsä. Tähän tarpeeseen vastaammekin tarjoamalla organisaatiokohtaisesti räätälöityjä koulutuskokonaisuuksia. Jos tiedossa on isompi porukka, joka työskentelee saman aihepiirin parissa ja samoilla aineistoilla, voidaan räätälöinnillä kasvattaa heidän koulutuksesta saamaansa hyötyä vielä ihan uudelle tasolle.

Mutta mitä se tarkoittaa käytännössä?

Koulutuksen räätälöinti toteutetaan aina tiiviissä yhteistyössä koulutuksen tilaajan kanssa. Yhdessä sovitaan, paljonko räätälöintiin on käytettävissä työaikaa, ja mitä sisältöjä asiakas koulutukseen haluaa. Usein lähdetään jostain Gispon valmiista koulutussisällöstä, jota sitten muokataan tarpeiden mukaan. Kevyimmillään räätälöinti voi olla sitä, että vakiomuotoisesta koulutusrungosta pudotetaan pois jokin osio, ja siitä vapautunut aika käytetään asiakkaan omien käyttötapausten tutkimiseen yhdessä. Tällaiseen ad hoc -työpajaan ei kouluttajan välttämättä tarvitse valmistautua lainkaan etukäteen, jolloin ylimääräisiä kulujakaan ei synny. Yksi tai useampi harjoitus voidaan myös muokata sellaiseksi, että siinä käytetään asiakasorganisaation omia aineistoja ja datalähteitä. Tai useammasta Gispon kurssista voidaan poimia tarpeen mukaan yksittäisiä osioita ja parsia kasaan tehokas kokonaisuus.

Mitä suurempi organisaatio on kyseessä ja mitä enemmän koulutukseen on tulossa osallistujia, sitä enemmän hyötyä räätälöinnistä on. Pelkän ohjelmistokoulutuksen lisäksi mukaan voidaan leipoa organisaation sisäisen datan hallinnan ohjausta: missä aineistoja säilytetään, millaiset käyttöoikeudet tietokantoihin on milläkin käyttäjäryhmällä, ja miten ohjelmiston keskitetty asennus ja päivitys on toteutettu. 

Kun koulutusmateriaali on kerran räätälöity, voidaan koulutuksesta järjestää vaikka useitakin toteutuksia, jotta kaikki halukkaat pääsevät mukaan. Räätälöintikustannukset jakautuvat isommalle joukolle, eikä vaikutus yksittäisen osallistujan kuluihin ole enää suuri lainkaan.

Apua vielä koulutuksen jälkeen

Kaikkiin koulutuksiimme sisältyy GispoHelp-tukipalvelun käyttöoikeus koulutuksen jälkeen. Näin varmistamme, että käyttäjät eivät jää yksin, vaan ohjelmiston jatkokäyttöön ja opitun syventämiseen on saatavilla apua. Tätä muutaman kuukauden pituista tukipalvelujaksoa on mahdollista pidentää tarvittaessa, tai kouluttajan kanssa voidaan sopia muutaman viikon tai kuukauden päähän seuranta, jolloin omatoimisen käytön aikana heränneisiin kysymyksiin saa helposti vastauksen. 

Koulutuksia voi siis räätälöidä monella tavalla. Tavoitteena on aina se, että asiakkaan työntekijät saisivat koulutustunneista parhaan mahdollisen hyödyn. Jos keksit koulutusten tehostamiseksi sellaisen tavan, jota ei tässä vielä mainittu, kerro siitä meille (esimerkiksi täällä)! Rakennetaan yhdessä juuri teidän tarpeita palveleva koulutuskokonaisuus.

Olemme tehneet useiden kuntien kanssa avoimen lähdekoodin paikkatieto-ohjelmistojen käyttöönottoprojekteja. Hyvistä käytänteistä on varmasti apua myös muille kunnille, jotka pohtivat esimerkiksi QGISin käyttöä tai omien tietovarantojen tehokkaampaa käyttöä. Tässä yksi esimerkki, miten homma kannattaa hoitaa!

Tarjosimme Hyvinkään kaupungille kuluneen vuoden 2021 aikana tukea avoimen lähdekoodin paikkatieto-ohjelmistojen käyttöön, ja tulokset olivat ilahduttavia. Hyvinkäällä testattiin keväästä alkaen miten QGIS- ja PostGIS-ohjelmistot taipuvat kunnan tarpeisiin. Uusiin työkaluihin tutustumisessa olennaista on käyttäjien koulutus ja tukeminen, mutta myös datarakenteiden suunnittelu ja toteutus on olennainen osa prosessia. 

Lisää osaamista

Hyvinkäällä haluttiin kokeilla QGISin käyttöä eri paikkatietotarpeissa kaavoituksesta tonttipalveluihin. Uusiin työkaluihin siirtyminen vaatii tietenkin apua eikä tapahdu hetkessä. Jotta uusien ohjelmistojen käyttö olisi sujuvaa, järjestimme Hyvinkään työntekijöille useita erilaisia koulutuksia FOSS4G-ohjelmistoihin. Yhteensä n. 20 henkilöä koulutettiin QGISin pariin. Etäyhteydellä järjestetyissä koulutuksissa käytiin läpi muun muassa QGISin ja paikkatietojen perusteita sekä pääkäyttäjille vedettiin myös PostGISin käyttäjänhallintakoulutuksia ja opeteltiin yhdessä tietokantarakenteita.

“Saimme kertarykäyksellä tehtyä pienimuotoisen ohjelmistojen yhdistämisen, eli eri osastoilla on ainakin yksi sama ohjelma (QGIS), mitä ihmiset osaavat ainakin vähän käyttää. Haasteena se, miten töiden ohessa kenelläkin on aikaa paneutua QGIS:iin ja saada se tehokkaaseen ja säännölliseen käyttöön osana päivärutiineja.”

– Jyrki Putus, Hyvinkää

Tiedot talteen

Avoimen lähdekoodin ohjelmistoihin siirtyminen tarkoittaa myös olemassa olevien paikkatietojen siirtämistä ja tietokantaratkaisuja. Hyvinkäälle asennettiin PostgreSQL/PostGIS kaupungin IT-palveluiden ylläpitoon. Samalla suunniteltiin alustavaa rakennetta miten eri yksiköt voisivat parhaiten hyödyntää paikkatietoaineistoja tietokannan kautta. Käytännössä Jyri Keskitalon mukaan Hyvinkäällä on tarkoitus tonttipalvelun osalta aluksi muuttaa vapaana olevien tonttien ylläpitäminen ja julkaisu suoraan PostgreSQL-tietokannasta Hyvinkään karttapalveluun.

Yleisesti tietokannan hyödyntämisen tavoitteina ovat, että tiedot tallennetaan vain yhteen kertaan, niitä voidaan linkittää toisiinsa, tietojen versionhallinta on suunnitelmallista ja että tietoja jaetaan vain niille, jotka niitä tarvitsevat ja käyttävät. Myös yhteiskäyttö onnistuu PostGIS-kannan kautta varmemmin. Jos paikkatiedot ovat vain verkkolevyllä tiedostomuodossa, niiden hyödyntämisestä syntyy pian hankalasti hallittava versioviidakko.

Jotta vältytään vahingoilta, tärkeä osa toteutusta ovat myös käyttäjähallinnan määrittely ja tietoturva-asiat. Esimerkiksi kaava-aineistoille on hyvä antaa muokkausoikeus ainoastaan sellaisille käyttäjille, jotka tietävät mitä tekevät. Näin vältytään virhetallennuksilta. Muille käyttäjille voidaan antaa katseluoikeus aineistoon. Lopulta tietojen siirto voidaan tehdä joko manuaalisesti tai käyttäen edistyneempiä aineistonmuokkausohjelmistoja, joilla voidaan esimerkiksi automatisoida prosesseja. Hyvinkäällä aineistosiirrot toteutettiin käyttäen FME:tä. Aineistojen siirtoon voidaan hyödyntää myös PostgreSQL:n foreign data wrapper -ominaisuuksia.

Koko siirtymän ajalta tarjosimme myös tukipalvelun, jotta mahdolliset ohjelmistoihin liittyvät kysymykset saadaan ratkottua. Tukipalvelu kattoi esimerkiksi QGISiin, PostGISiin ja GeoServeriin liittyvät kysymykset.

Hyvä esimerkki kunnan FOSS4G-työkalujen käyttöönotosta

Hyvinkään tavoin myös avoimen lähdekoodin paikkatieto-ohjelmistoja käyttävässä Paimiossa ollaan oltu tyytyväisiä vastaavaan toimintatapaan (katso vaikka videolta). Hyvinkään toimintatapa oli esimerkkitapaus siitä, miten uusia työkaluja kannattaa ottaa käyttöön:

• Innostunut ydintiimi, joka hoitaa ja tietää kunnan omat tarpeet
• Kaikki käyttäjät koulutetaan uusien päätyökalujen käyttöön (QGIS)
• Pääkäyttäjät koulutetaan tietokantamaailmaan (PostGIS) 
• Kunnan oma IT-puoli hoitaa palvelinympäristön ja heitä avustetaan ohjelmistojen asennuksessa ja ylläpidossa
• Suunnitellaan tietokannan rakenne ja käyttäjänhallinta yhdessä
• Suunnitellaan tietojen siirtoprosessit ja koulutetaan pääkäyttäjät työhön
• Tuetaan koko prosessia alusta asti

“Yhteistyö Gispon kanssa sujui joustavan mallikelpoisesti koulutusten yms. kanssa. Ongelmatilanteen sattuessa eteen, Gispolta saatin jouhevasti apua.”

-Jyrki Putus, Hyvinkää

CAD-ohjelmistoja hyödynnetään usein etenkin insinöörien ja arkkitehtien suunnittelutyössä. CAD-suunnitteluohjelmistoja on myös iso liuta, suurin osa kaupallisia ohjelmistoja. Perinteisesti CAD-ohjelmistoja on käytetty piirtämiseen ja mallintamiseen ja oleellista on ehkä enemmän suunniteltujen kappaleiden ja kohteiden suhde toisiinsa ja ulkoasu, kuin paikkatiedot tai ominaisuustiedot. CAD-maailmassa voi esiintyä myös paikkatieto-ohjelmistolle eksoottisempia geometrioita, kuten kaaria.

Paikkatietomaailma ja CAD-maailma kohtaavat usein erityisesti kaavoituksessa ja johtoaineistojen käsittelyssä ja siten nämä maailmat ovat aika lähekkäin, mutta silti niin kaukana.

Jo pelkästään näistä asioista johtuen CAD-ohjelmistoilla luotujen aineistojen tuominen esimerkiksi QGISiin ei aina ole juhlaa. Jotta aineistot toimisivat ja olisivat sujuvasti käytettävissä muillakin kuin CAD-ohjelmistoilla, kokosimme yhteen ohjelmistojen yhteiskäytön tyypillisiä sudenkuoppia.

Muista siirtoformaatti ja formaattien versiot

QGIS tukee satoja tiedostoformaatteja (GDAL/OGR-kirjastoissa kuvatut), mutta osa tiedostoformaateista on suljettuja, joten niihin ei ole voitu lisenssisyistä tehdä tukea QGISille. 

CAD-aineistoa jaetaan yleensä .DGN-,  .DWG- ja .DXF-formaateissa. 

DGN on Microstationin formaatti ja sen osalta haasteena on Microstationin versio. Versiota 8.0 aikaisempia .DGN-tiedostoja (v7) voi lukea, mutta sen jälkeisiä .DGN-versioita QGIS ei kykene hyödyntämään. Tällaisissa tapauksissa kannattaa tallentaa vanhempaan versioon. 

.DWG on lisensoitu myös siten, että niiden käyttö QGISissä on ongelmallista. Ne eivät avaudu suoraan QGISiin vaan .DWG on importoitava Geopackageksi. 

Parhaiten QGISin kanssa yhteensopiva on  AutoCADin siirtoformaatti .DXF, jonka ominaisuudet ovat suunniteltukin välittämään tietoa eri ohjelmistojen välillä. Usein siis kannattaa pyytää aineistot suoraan .DXF-muodossa tai muuntaa esimerkiksi .DWG tähän muotoon itse. Tämä on onneksi helppo muutos, jonka voi tehdä esimerkiksi netistä löytyvillä ilmaisilla konvertteri-ohjelmistoilla (googleta esim. DWG to DXF). 

Tuo DWG/DXF -työkalu

Tässä ohjeet, kuinka käytetään QGISin “Tuo DWG/DXF”-työkalua (Projekti -> Tuo/vie -> Tuo tasoja DWG/DXF-tiedostoista), joka aineiston avaamisen lisäksi luo GeoPackage-tiedoston sen sisällöstä. Toinen vaihtoehto olisi tuoda aineisto projektiin uutena vektoritasona. Näistä ensinmainittu työkalu antaa paremman näkymän aineistoon, sillä se jakaa aineiston CADissa nimettyihin tasoryhmiin. Sen sijaan aineiston tuonti vektoritasona tuo kaikki polygoni-, viiva- ja pisteaineistot projektiin yksittäisinä tasoina, minkä seurauksena haluamiaan tietoja joutuu kaivelemaan eri tavalla attribuuttitaulukoista. 

Koordinaattijärjestelmän asettaminen

Kun tiedostoa tuodaan QGIS-työtilaan, pitää tietää ja asettaa vielä aineiston koordinaattijärjestelmä. Yleensä QGIS tunnistaa aineistojen koordinaattijärjestelmät automaattisesti, mutta CAD-aineistoissa tämä tieto puuttuu, ja siksi se on hyvä ilmoittaa aineiston vastaanottajalle.

Välillä valitettavasti käy niin, että CAD-piirrosta ei ole missään vaiheessa sidottu koordinaattijärjestelmään. Tällöin ainoa keino saada piirros kohdilleen maailmaan on georeferoida se vastinpisteiden avulla uudelleen tai käyttää Affine- tai Translate-työkaluja. 

CAD-aineistojen sisällöt

Jos aineisto on alunperin luokiteltu ja nimetty johdonmukaisesti, elämä on paikkatietomaailmassa helppoa. Toisinaan kohteiden kuvaustekniikkaa pitää hieman hioa, jotta aineistosta saa korostettua itselleen olennaiset kohteet.

Parhaimmillaan CAD-aineistossa voi olla myös ominaisuustietoja, mutta useimmiten niitä ei ole, vaan kohteiden tiedot on tallennettu vain piirtoteknisesti annotaatio- eli tekstitasoina. Jos käy hyvin, kohteiden tekstitasot ovat loogisesti niihin liittyvien muiden tasojen kanssa samassa tasoryhmässä – esimerkkinä vaikkapa tonttinumerot tonttien rajojen kanssa samassa ryhmässä. Joissain tapauksissa kaikki aineiston tekstit ovat voineet jäädä jo CAD:issa yhdelle tasolle nippuun, jolloin niitä joutuu tulkitsemaan QGISissä attribuuttitaulukosta.

Geometria!

Tietorakenteen lisäksi toinen iso tekijä CAD-aineistojen tarkastelussa paikkatieto-ohjelmistoissa on geometria. Usein CAD-aineistolla piirretyt kohteet ovat viivakohteita, vaikka ne kuvaisivatkin alueita, kuten tontteja tai puistoja. Vaikka aineisto näyttää tässäkin tapauksessa piirtoteknisesti oikealta, esimerkiksi aluemaisten kohteiden pinta-alan laskeminen ei onnistu, ellei käyttäjä muokkaa niitä itse polygoneiksi. Aineiston jatkoanalyysiä ajatellen kohteiden geometrinen ja topologinen eheys (rajatut alueet ovat suljettuja, viivamainen geometria ei saa leikata itse itseään ym.) ovat siis ehdottoman tärkeitä.

QGISin haasteena toisaalta on, että sillä on vielä hankala piirtää “cadimaista” jälkeä eli kaaria ja rakenteita. Työkaluja toki on, mutta ne vaativat kehitystä. Mielenkiintoisia projekteja kuitenkin löytyy, kuten tässäkin keskustelussa läpikäyty Cad Tools, mutta kuten kommenteissa mainitaan, tarvittaisiin pari tonttua hoitamaan homma kuntoon. 

Eikun tekee vaan!

Vaikka tässä artikkelissa on käyty läpi ohjelmistojen eri tarpeista ja toimintatavoista johtuvia ongelmia, kannattaa muistaa, että monet niistä ovat helposti korjattavissa. Tarvittavia korjauksia voi tehdä sekä aineistoja laatiessa CAD-ohjelmistoissa että editoimalla kohteita QGISissä. Jos tavoitteena on käyttää CAD- ja paikkatieto-ohjelmistoja rinnakkain, olisi hyvä laatia ne CAD-ohjelmistossa siten, että yhteiselo olisi mahdollista ja tiedot siirtyisivät hyvin palvelusta toiseen. Tässä vielä lyhyt muistilista:

• Ryhmät kuntoon
• Koordinaattijärjestelmä tietoihin mukaan
• Geometriat kuntoon 
• Ominaisuustiedot mukaan

Meidän kauttamme saa myös koulutusta datan suunnitteluun, editointiin ja hallintaan QGISillä. Lähdemme myös mielellämme kehittämään digitoinnin työkaluja QGISille, jotta editointityökalut kehittyvät – tätä puolta tarvitaan erityisesti kaavoituksen, kiinteistönmuodostuksen, tonttijaon ja maastotietojen tuotannossa. 

Gispon vuosi 2022 alkaa uusilla tuulilla, kun Itä-Suomesta kasvavaan joukkoomme liittyy Jarno Kinnunen. Yli kymmenen vuotta paikkatietoalalla ollut Jarno tunnetaan myös hänen ylläpitämästään Paikkatietomies-blogista.

Kuka olet?

Jarno Kinnunen.

Mistä pidät?

Siimojen uittelusta (jota myös kalastukseksi kutsutaan), erästelystä ja luonnossa liikkumisesta noin yleisestikin. Edellä mainittujen lisäksi positiivisia ajatuksia mielen sopukoihin synnyttävät myös sulkapallon pelaaminen, musiikin kuuntelu sekä kissat.

Mikä paikkatietoalassa kiehtoo ja miksi juuri Gispo?

Paikkatietoalalla minua kiehtovat erityisesti paikkatietojen analysointi ja visualisointi, selainkäyttöiset karttapalvelut, spatiaalitietokannat sekä OGC-rajapinnat. Ja kaikki nämä erityisesti avoimen lähdekoodin teknologioilla toteutettuina. 

Gispolla fokusoidutaan erityisesti avoimen lähdekoodin paikkatietosovellusten ja -teknologioiden hyödyntämiseen, joten yrityksen toiminnan perusfilosofia on juuri sitä, mistä itsekin olen kiinnostunut. Lisäksi Gispolla on mm. mielenkiintoisia julkishallinnon asiakkuuksia, joissa kehitetään tulevaisuuden digitalisoituvan maailman työkaluja ja uusia työn tekemisen tapoja. 

Mikä on supervoimasi?

Lupsakka, ihmisläheinen toimintatapa yhdistettynä intohimoon erilaisia teknologisia ratkaisuja kohtaan – ratkaisuja kehitetään ihmisiä varten. Suustani voi ihan yhtä hyvin kuulla lausahduksen “Elähän hättäile, istuhan mättäälle” kuin “Se, mitä ei vielä osata, pitää opetella”. 

Kuntien, maakuntien ja muiden julkishallinnon toimijoiden palvelutuotannon tuottavuuden lisääminen on avainkysymys koko julkisen talouden kestävyyden näkökulmasta. Miten tuottavuutta sitten lisätään? No, ainakin digitalisaation keinoin.

Autoimme  hiljattain Varsinais-Suomen liittoa ja Lounais-Suomen alueellisena tietopalveluna toimivaa Lounaistietoa rakentamaan automatisoidun dataputken, jonka tehtävänä on kerätä heidän alueellaan sijaitsevien palveluiden tiedot palvelupistetietokantaan. Tietokantapohjaisen ratkaisun käyttöönotto mahdollistaa alue- ja kaupunkisuunnittelijoille sekä muille käyttäjille pääsyn jatkuvasti päivittyvään Lounais-Suomen (= Varsinais-Suomen ja Satakunnan maakuntien) palveluiden kohde- ja sijaintitiedot sisältävään tietovarantoon.

Tieto palveluiden sijainnista osaksi toimeenpanopolitiikkaa

Palvelupisteiden sijainteja ja palveluihin liittyviä tietoja käytetään alue- ja kaupunkiseutujen suunnittelussa. Palveluverkon spatiaalinen jakaantuminen ja mahdolliset muutokset palvelukattavuudessa ovat tärkeitä tekijöitä monien kokonaisuuksien suunnittelussa. Palvelupisteisiin liittyville tietosisällöille tai niistä johdetuille tuotteille (tilastot / kartat) luulisi siis löytyvän innokkaita hyödyntäjiä niin maakuntien liitoista kuin kuntien edustajista. Projektin keskeinen tavoite, ajankohtaisen palveluverkkoihin liittyvän tiedon tarjoaminen avoimesti kaikkien saataville, voidaankin nähdä yhtenä askeleena kohti hyvin toimivaa, datalähtöistä toimeenpanopolitiikkaa.

Projektin lähtötilanne

Varsinais-Suomen liitolla ja Lounaistiedolla oli jo projektin alkaessa olemassa palvelupistetietokanta. Kyseisen palvelupistetietokannan sisältö oli kuitenkin päässyt vanhentumaan, eikä sen sisältämiin tietoihin voinut enää luottaa. Vanhan tietokannan päivityslogiikka perustui tietojen manuaaliseen päivittämiseen ja yhteys viimeisimpään tietojen päivittäjäänkin oli päässyt katkeamaan. Tietovarantoa katsellessa kävi ilmi, ettei tapa, jolla olemassaolevan palvelupistetietokannan kohteet oli luokiteltu, ollut myöskään ajan tasalla. Projektin edetessä huomattiin lisäksi, ettei olemassaolevaan tietovarantoon ollut kerätty tietoa kaikista kohteista, joiden nykyään voidaan ajatella olevan relevantteja palvelupisteitä.

Uuden palvelupistetietokannan muodostuksessa haluttiin ottaa huomioon edellisen tietokannan ylläpitoon liittyvät haasteet ja reagoida niihin niin, ettei tietojen ajantasaisuudesta tarvitsisi tulevaisuudessa kantaa yhtä paljon huolta. On ilmeistä, että aineiston pitäminen ajantasaisena manuaalisin keinoin on hyvin haasteellista. Tästä virisi tarve automatisoidulle ratkaisulle.

Varsinais-Suomen liitto ja Lounaistieto olivat tunnistaneet myös toisen tärkeän seikan; palveluja tarjoaa niin yksityinen kuin julkinenkin sektori. Tämä on keskeistä lähinnä sen vuoksi, ettei kaikkia palvelutietoja ole avoimesti saatavilla yhdestä ja samasta lähteestä. Jakamalla palvelupisteet julkisen ja yksityisen sektorin tarjoamiin palveluihin, ongelma voitiin kuitenkin kiertää. Päätimmekin rakentaa automatisoidun rajapintaratkaisun, jossa yksityisen sektorin tarjoamien palveluiden tiedot haettaisiin OpenStreetMapista (OSM) ja julkisen sektorin tarjoamien palveluiden tiedot Digi- ja väestöviraston palvelutietovarannosta (PTV).

Projektin toteutus

Projektin aikana tuotettiin prosessi, joka kerää dataa kahdesta eri lähteestä, mutta yhdistää ne lopulta samaan tietokantatauluun, josta jalostettuun muotoon muokattu aineisto voidaan julkaista loppukäyttäjien saataville ilman manuaalista / ihmisen työpanosta vaativaa työtä. Lopputuloksena saatiin paikkatiedon rajapintapalveluratkaisu, jonka kautta tuotettua dataa voi käyttää ohjelmistoriippumattomasti. Rajapinnat pohjautuvat avoimiin kansainvälisiin paikkatiedon rajapintastandardeihin.

Palvelupistetietojen keräämisessä keskeistä on sijainti. Rajapintaratkaisussa kerätään ja yhtenäistetään data kahdesta eri tietolähteestä samaan tietokantaan siten, että tiedon kerääminen ja prosessointi (siistiminen + jatkojalostus) on täysin automatisoitu. On tärkeä muistaa, että emme tässä projektissa olleet suinkaan kiinnostuneita kaikista OSMin ja PTV:n sisältämistä kohteista; ainoastaan palveluita tarjoaviin kohdeluokkiin kuuluvista kohteista. Aineiston ajantasaisuus varmistettiin luomalla ajastettuja skriptejä, jotka käyvät hakemassa OSMista ja PTV:stä palvelutietokannan kannalta kiinnostavien kohteiden tiedot kerran vuorokaudessa.

Alla olevasta taulukosta käy ilmi millaisia tietoja uusittu palvelupistetietokanta tällä hetkellä sisältää:

Tekniset rakennuspalikat

PTV-dataputken keskeinen idea oli luoda PTVn JSON-apille Foreign Data Wrapper, jonka avulla relevantit tiedot saatiin imuroitua JSON-apista PostGIS-tietokantatauluun. OSM-dataputken tapauksessa keskeistä roolia näyttelee pgosm-flex, jonka avulla OpenStreetMap-aineistosta voidaan parsia kerättävää dataa OSM-tägi perusteisesti.

Hyödynnetyt teknologiat:

• PostgreSQL + PostGIS
• Docker (ratkaisun paketointi ja implementointi)
• multicorn (PTV-data PostGIS-tauluun)
• pgosm-flex (OSM-data PostGIS-tauluun)
• pg_cron (PTV-datan ajastetut hakutehtävät)
• CRON (OSM-datan ajastetut hakutehtävät)
• ogr2ogr (kahdesta eri datalähteestä haettujen taulujen yhdistäminen)
• Geoserver (palvelupistetietojen luokittelu yläteemoittaisiin kokonaisuuksiin + tiedonjako loppukäyttäjille)

Linkit relevantteihin GitHub-repositorioihin:

• https://github.com/GispoCoding/PTVfdw

• https://github.com/GispoCoding/pgosm-flex

Palveluiden sijainneista analyyseihin ja tiedolla johtamiseen

Nykypäivänä paikkatietojen hyödyntämispotentiaali ei enää ole riippuvainen ohjelmistolisensseihin käytettävästä budjetista, vaan ennemminkin organisaation käytettävissä olevasta teknologia- ja digitalisaatiokyvykkyydestä. Tästä näkökulmasta onkin mielenkiintoista pohtia, kuinka julkishallinnon palvelutarjonnan tuottavuutta voidaan lisätä erinäisin paikkatietosovelluksin.

Esimerkiksi palvelupistetietokannan suhteen voidaan miettiä, minkälaisia automatisoituja analyysejä datasta voidaan tehdä. Voidaan muun muassa luoda jatkuvasti päivittyvä tieto siitä, kuinka pitkä matka kotihoidon palveluyksiköistä on ajallisesti lähinpään pelastustoimen palveluyksikköön. Samalla tavalla voidaan laskea, mikä on terveyspalveluiden ajallinen saavutettavuus kävellen (esim. tarkastella päteekö koko väestön tapauksessa, että lähin terveyspalvelu on saavutettavissa kävelemällä korkeintaan 20 minuuttia).

Lisäksi voidaan laskea automatisoidusti kullekin väestöruudulle ajallinen etäisyys autolla esimerkiksi lähimpään ruokakauppaan, ja näin saada tunnuslukuja siitä, minkälainen palveluverkon saavutettavuus vallitsee esimerkiksi haja-asutusalueilla. Voidaan myös analysoida, minkälainen on tiettyjen palvelutyyppien lukumäärän kehitys 10 minuutin kävelyetäisyydellä turismin kannalta keskeisistä sijainneista.

Onkin helppo huomata, että erilaisia analyysinäkökulmia on paljon. Julkishallinnon tuottavuuden näkökulmasta on tärkeä huomioida, että nykypäivän teknologioilla, avoimella datalla ja riittävällä digiosaamisella nämä analyysit voidaan automatisoida. Tämä vapauttaisi työaikaa muihin ihmisen päätöksentekoa vaativiin tehtäviin. 

Projektissa toteutetusta automaattisesta datankeruuprosessista ja sen tuotteena saadun datan esimerkkianalyysiaihioista voidaan päätellä, että julkishallinnon tuottavuutta voidaan lisätä automatisoimalla datan keruuprosessi ja rakentamalla automaattisesti kerääntyvän datan päälle erinäisiin yhteiskunnallisiin rakenteisiin / ilmiöihin liittyviin kysymyksiin vastaavia analyysejä. Kaikki tietävät, että maailma muuttuu jatkuvasti. Kannattaakin painaa korvan taakse, että tällaisia automatisoituja rajapintaratkaisuja sisältävien dataputkien kautta myös data ja sen päälle rakennetut analyysit ja/tai ilmiöiden seurantaprosessit, pystyvät muuntautumaan jatkuvasti.

Olemme tehneet Gispolla yhteistyöprojekteja Yhdistyneiden kansakuntien kanssa. Tähän blogipostaukseen on koottuna YK:lle tekemiemme projektit ja niiden tulokset.

Koulujen saavutettavuus ja Catchment-lisäosa

Teimme koulujen saavutettavuusalueiden laskentaa YK:n koulutuksesta vastaavalle organisaatiolle (IIEP-UNESCO). Projektissa tutkittiin koulujen saavutettavuutta käyttäen hyväksi OpenStreetMapin aineistoja. Tavoitteena oli tehostaa kouluihin liittyvää suunnittelua, mutta tuloksia voi käyttää muihinkin kouluihin liittyviin matkoihin. Analyysillä voidaan arvioida koulujen potentiaalisia oppilasmääriä, tehdä koulukirjojen toimituksen reittioptimointia tai suorittaa koulujen tarkastusreittien laskentaa. 

Projektin tuloksena julkaisimme Catchment-lisäosan QGISiin. Lisäosa antaa käyttäjän määrittää laskennan parametrit eli kohteena olevat pisteet, liikkumistavan ja etäisyyden, jolta pisteisiin saavutaan. Lisäosa näyttää näin pisteen saavutettavuuden esimerkiksi kävellen, pyöräillen tai autoillen. Lisäosa käyttää laskentaan OpenStreetMapin dataa ja GraphHopper-algoritmia. Testejä tehtiin IIEP:n toimesta kesällä 2021 mm. Pakistanissa, Madagaskarilla, Myanmarissa ja Jamaicalla.

Voit lukea lisää Catchment-lisäosasta  ja projektista blogikirjoituksestamme täältä. Catchment-lisäosan löydät GitHubista. Jos haluat käyttää lisäosaa omiin tarkoituksiisi, saat haluamasi alueen/maan tieaineiston käyttöösi joko ottamalla yhteyttä meihin info@gispo.fi tai pystyttämällä Docker-kontin GitHub-ohjeiden mukaan.

Cloudfree-työkalu eli Cloudfree Remote Sensing Image

Business Finlandin Tempo-rahoituksella toteutimme Un Open GIS -yhteisön käyttöön pilvistä vapaita satelliittikuvia. Samalla saatiin kriisinhallintaan soveltuva työkalu. Pilvet voivat peittää muuten hyvälaatuisista satelliittikuvista isojakin alueita, jolloin alueelle kohdistuvan kenttätyön suunnittelu on vaikeaa. Projektissa pyrittiin automatisoimaan pilvettömien kuvien erottelu valtavasta määrästä satelliittikuvia.

CFSI eli Cloud-Free Satellite Imagery -työkalu yhdistää halutulta alueelta viimeisimmät pilvettömät satelliittikuvat mosaiikiksi. Tekoälyyn perustuva työkalu käyttää  European Space Agencyn (ESA) satelliittikuvia (Sentinel) ja osaa poimia ja yhdistää pilvettömät kuvat aineistosta. Jos alueella tarvitaan esimerkiksi rauhanturvaoperaatiota tai apua luonnonkatastrofin sattuessa, työkalun avulla saadaan kerättyä alueelta tarvittava data. 

Voit lukea projektista lisää blogiartikkelistamme täältä. CFSI:n löydät GitHubista.

E-Resilience Monitoring Dashboard

Keväällä ja kesällä 2021 keräsimme ja visualisoimme internetin käyttöä ja digitalisaatiota kuvavaa dataa UNESCAPin käyttöön. Projektin tavoitteena oli selvittää, millaisia eroja on maiden välillä ja maiden sisällä.

Maakohtaisesti tai ryhmittäin tarkasteltavat visualisoinnit kuvaavat monipuolisesti eri mittareita digitalisaation edistymisen, eriarvoisuuden ja käytön suhteen. Visualisoinneista voi nähdä muun muassa maaseudun ja urbaanien alueiden välisiä eroja sekä sukupuolten välisiä eroja. Yhteistyön tuloksena lanseeratulla nettisivulla voi tarkastella eri maiden tilanteita myös sen suhteen, kuinka isolla osalla yrityksiä on omat nettisivut tai kuinka paljon maassa julkaistaan ja käytetään avointa dataa. Visualisoinnit ja tilastot auttavat päättäjiä ratkaisemaan aiheeseen liittyviä haasteita ja puuttumaan internetin käytettävyyden eriarvoisuuteen.

Visualisoinnit ja tilastot ovat nähtävissä UNESCAPin julkaisemalla sivustolla täällä.

UN Open GIS

Edellä mainittujen projektien lisäksi Gispo on osallistunut YK:n avoimen lähdekoodin paikkatieto-ohjelmistojen yhteisön (UN Open GIS, http://unopengis.org/) toimintaan vuodesta 2018 lähtien. UN Open GIS -yhteisön tavoitteena on edistää avoimen lähdekoodin paikkatieto-ohjelmistojen käyttöä YK:ssa ja sen jäsenmaissa sekä myös muissa kansainvälisissä yhteistyöorganisaatioissa ja kansalaisjärjestöissä (NGO).

FOSS4G Suomi -tapahtuma järjestettiin pari viikkoa sitten 14.10.2021 Helsingin Oodissa –  LIVENÄ! Omalta osaltani tämä taisi olla ensimmäisiä tapahtumia, joihin olen päässyt osallistumaan fyysisesti paikan päälle liki kahteen vuoteen. Täytyy sanoa, että tuntui mahtavalta jättää kaksi vuotta palvelleet pieruverkkarit ja etätyöpiste hetkeksi ja nähdä ihan oikeita ihmisiä! Tapahtumaan saatiin koolle korona-aikaan nähden tosi hyvä porukka ja myös striimin puolella oli hyvä pöhinä loppuun asti.

FOSS4G Suomen keynotena oli Jani Kylmäaho, jonka puheesta ei voinut olla inspiroitumatta. Yllätyin itsekin, kuinka paljon avoimen lähdekoodin komponentteja on jo nyt MML:n toiminnan takana – tulevaisuudessa vieläkin enemmän. Puheen aikana huomasin nyökytteleväni jatkuvasti Janin esiintuomille pointeille – sille yleiselle ajatusmaailmalle, että tekemällä asioita yhdessä päästään paljon pidemmälle kuin käpertymällä kukin omaan nurkkaan tekemään samoja asioita uudestaan ja uudestaan hieman eri tavalla. Mielestäni oli myös hienoa, että Jani toi puheessaan esiin ehkä hieman vähemmän keskusteltuja solmukohtia mm. avoimen lähdekoodin hankintoihin liittyen. Avoimen lähdekoodin käyttö on arkkitehtuuripäätös, eikä se ole hankintalain alainen päätös. Sitten jos hankitaan jotain palvelua avoimen lähdekoodin paikkatieto-ohjelmistoihin liittyen (kuten koulutusta, ohjelmistokehitystä tai tukea), silloin hankintalaki nostetaan pöydälle.

Puheita kuunnellessani oivalsin sen, mitä olin ikävöinyt ehkä eniten kahden vuoden sulun aikana: muiden töistä inspiroitumista. FOSS4G Suomessa oli useampikin esitys, jotka saivat aivonystyräni tuikkimaan ja sormeni syyhyämään. Esimerkiksi Damiano Cerronen esitys väestömäärän vähenemisestä (eng. shrinkage) muualla kuin pääkaupunkiseuduilla oli tämänhetkisiltä tuloksiltaan mielenkiintoinen ja yllättävä – tutkimuksessa pystyttiin tunnistamaan mm. autioituvia rakennustyyppejä. Samaistuin vahvasti myös Kimmo Nurmion esitykseen GTFS-aineistoista ja sen pullataikinan ainesosien kasaamisen ja vaivaamisen tuskaan. Toivottavasti tämä pullataikina saataisiin yhteistyöllä uuniin ja pullat käyttäjille jakoon!

Ja hei! Ubigu lähti mukaan folkoisiin omalla avoimuusprosentillaan, mahtavaa!

Tuhannet kiitokset vielä upeille sponsoreille, järjestäjätiimille, puhujille ja osallistujille – ilman teitä tätä tapahtumaa ei olisi! Toivottavasti nähdään taas pian!

Voit katsoa FOSS4G Suomen jälkistriimin kokonaisuudessaan täältä.

PS. Kuvia puhujista löydät täältä, ja jos tapahtumassa nähty supercool QGIS-huppari kiinnostaa, niitä voi tilata täältä.