Kesäkuun alussa Gispon joukkoon on liittynyt mukaan Anna Saarinen. Opintojen myötä Anna on innostunut paikkatietoanalyysin menetelmistä ja pääsee kesäharjoittelun muodossa avustamaan myös myynnissä ja markkinoinnissa.

Kuka olet?

Olen Espoosta kotoisin ja täällä edelleen opiskeleva syksyllä kolmannen vuoden aloittava energia- ja ympäristötekniikan kandiopiskelija. Kandin jälkeen aion jatkaa geoinformatiikan maisteriopinnoissa, sillä erilaiset paikkatiedonkeruumenetelmät sekä data-analyysi kiinnostavat minua erityisen paljon.

Mistä pidät?

Vapaa-ajalla viihdyn hyvin virkistävillä kävelyillä ja toisaalta myös kirjallisuuden sekä musiikin parissa. Instrumenttitaustaa löytyy, joten oli musiikki sitten soittamisen tai kuuntelun muodossa, saa se minut aina hyvälle tuulelle. Lisäksi nautin ruuanlaitosta ja eri ruokakulttuureihin syventymisestä.

Mikä paikkatietoalassa kiehtoo ja miksi juuri Gispo?

Alun perin innostuin GIS-ohjelmistojen käytöstä, jonka myötä ajauduin luonnollisesti myös paikkatiedon pariin. Erityisesti minua kiinnostaakin paikkatiedon analysointi ja sen visualisoinnin mahdollisuudet. Paikkatietoala tuntuu antavan myös joka päivä jotain uutta ja mielenkiintoista pohdittavaa. Siispä tieto ei lopu ja tekemistä riittää!

Koen avoimen datan ja lähdekoodin tärkeänä ja kiehtovana, joten Gispo kohtaa ajatusmaailmani tässä kohtaa täydellisesti. Uskon juuri täällä työn merkityksellisyyden pääsevän huippuunsa. Lisäksi Gispo on se paikka, jossa pääsen haastamaan itseäni, oppimaan paljon uutta ja työskentelemään upeiden ihmisten kanssa.

Mikä on supervoimasi?

Avoimuus! Oli kyse sitten ihmisistä tai kokemuksista, se  on minulle loistava tapa saada tilanteista kaikki irti.

Gispon Joensuun osaston henkilöstömäärä tuplaantuu, kun Joona liittyy joukkoomme! Joonaa kiinnostavat paikkatietopähkinöiden ratkomisen lisäksi liikunta ja karttojen yksityiskohdat.

Kuka olet?

Lupsakka savolainen paikkatietoimmeinen. Taustaltani olen yhteiskuntamaantieteilijä ja opinnoissani suuntauduin erityisesti geoinformatiikkaan. Tämän lisäksi sivuaineena tuli luettua metsätiedettä ja tietojenkäsittelytiedettä. Kymmenen vuotta olen pitänyt majaani Pohjois-Karjalan pääkaupungissa Joensuussa.

Mistä pidät?

Liikunta ja maastohiihto on olleet aina lähellä sydäntä. Nuorempana tuli harrastettua hiihtoa aina kilpatasolla asti. Tällä hetkellä liikuntalajeista erityisesti sulkapallo ja salibandy liikuttavat minua eniten. Muuna aikana kaikenlainen puuhastelu, liittyipä se kodin rakentamiseen tai pihatöihin saa minun mielenkiinnon hereille.

Mikä paikkatietoalassa kiehtoo ja miksi juuri Gispo?

Alunperin paikkatietoalasta kiinnostuin karttojen ja maantieteen kautta. Karttojen lukemattomat eri yksityiskohdat ovat saaneet minut aina haltioihin. Tykkään kaikenlaisista virityksistä ja ongelmanratkaisusta. Niitähän paikkatietoalalalla pääsee kehittelemään kyllästymiseen asti.

Gispossa kiinnostaa avoimien järjestelmien eturintamassa oleminen ja kaikenlainen uuden kehittely. Odotan myös oman osaamisen syventämistä ja uuden oppimista.

Mikä on supervoimasi?

Supervoimani kumpuavat analyyttisyydestä, nopeaoppisuudesta ja kokonaisuuksien hahmottamisesta.

Usein puhutaan siitä, kuinka avoin lähdekoodi mahdollistaa ekosysteemin muodostuminen ohjelmiston ympärille. QGISin tapauksessa tässä kohtaa ajatellaan yleensä sille kehitettäviä lisäosia, plugineja, joilla työpöytäohjelmiston perusominaisuuksia voidaan helposti laajentaa. Tähän voisi kuitenkin lukea mukaan myös muut ohjelmistot, jotka on kehitetty toimimaan hyödyntäen QGISia ja integroimaan se osaksi työnkulkua. Hyvänä esimerkkinä tästä voisi mainita paikkatiedon mobiilikeruuseen kehitetyn QField-sovelluksen, jota olemme esitelleet aiemmissa blogeissamme täällä ja täällä. 

Toinen esimerkki QGISia hyödyntävästä ohjelmistosta on Lizmap, joka on ranskalaisen 3Liz-yrityksen vuodesta 2011 asti kehittämä avoimen lähdekoodin karttapalvelusovellus (julkaistu Mozilla Public Licence -lisenssillä). Lizmapilla QGISissa luodut ja muokatut paikkatiedot saa kätevästi julkaistua karttapalveluna verkossa. Esittelemme tässä  Lizmapin perusominaisuudet ja mahdollisen QGIS-pohjaisen työnkulun paikkatietojen muokkaamisesta kartan julkaisuun sovelluksessa. 

Jos siis tarpeena on saada organisaation paikkatiedot helposti ja keskitetysti kaikille niitä tarvitseville, eikä pelkästään vaikkapa paikkatietospesialisteille, on web-selainenpohjainen karttapalvelu kätevä vaihtoehto tähän tarkoitukseen.

Lizmapin eri ominaisuudet ja karttojen julkaisuprosessi

LizMap on kehitetty hyvin yhteensopivaksi QGISin kanssa. Kuten aiemmin mainitussa QFieldissakin, myös LizMapissa esimerkiksi QGISissa määritetyt aineistojen kuvaustyylit toimivat sellaisenaan, ja muutenkin karttojen julkaisemiseen karttapalvelussa liittyvä konfigurointi ja muu ylimääräinen puljaus on vähäistä. Kun aineistojen muokkaus on siis kerran QGISissa saatu valmiiksi, voi olla varma, että kartat näyttävät ja toimivat palvelussa oikealla tavalla. Karttapalvelimelle lisätään karttakohtaisesti QGIS-projektitiedosto, ja sen voikin tässä yhteydessä ajatella olevan kartan tärkein konfigurointitiedosto. 

Kokonaisuuden ymmärtämiseksi, tarkastellaan aluksi mistä eri osioista Lizmap on rakennettu, ja mikä niiden rooli on.

Lizmap koostuu muutamasta eri komponentista: 

• QGIS Desktop ja QGIS Server: Iso osa karttapalvelussa julkaistavan kartan konfiguraatioista määritellään suoraan tavallisessa työpöytäsovelluksen  QGIS-projektitiedostossa (mm. kuvaustyylit, karttatasot, karttatulostepohjat, tasojen ominaisuustiedot ja lomakkeet niiden muokkaukseen).  Kartta-aineistojen palvelu perustuu QGIS Serveriin ja tukee OGC:n rajapintastandardeja (WFS, WMS, WMTS, WPS).
• Lizmap-lisäosa QGISille: auttaa projektin paketoimisessa karttapalvelua varten. Lisäosassa konfiguroidaan esimerkiksi halutut karttatyökalut.
• Web-hallintapaneeli: julkaistujen karttojen ja tasojen katselu- ym. oikeuksien sekä  karttapalvelun ulkoasun määrittely.

Karttojen julkaisun kannalta oleellisimmasta Lizmapin ominaisuuksista mainittakoon, että Lizmap tukee yleisimpiä paikkatietodatan formaatteja, kuten Shapefile, GeoJSON, MapInfo TAB ja MIF/MID, GeoTIFF ja netCDF. Lisäksi PostGIS- tai Spatialite-tietokantoja käytettäessä datan editointi käyttäjän toimesta on mahdollista karttapalvelussa. Karttapalvelu on laajennettavissa myös palvelinpuolen moduulien avulla. Käyttöliittymän modifioinnissa on ulkoasun säätämisen lisäksi kätevä hyödyntää toiminnallisuuksiin joko itsetehtyjä tai valmiita Javascript-koodeja.

Työnkulku datasta julkaistuksi kartaksi menee lyhykäisyydessään seuraavalla tavalla:

• Aluksi aineistot lisätään ja valmistellaan QGIS-projektissa: esimerkkinä kuvaustyylien, karttatulostepohjien sekä ominaisuustietojen täyttölomakkeen määrittely. Tässä yhteydessä huomattakoon, että Lizmap tukee myös QGISin lausekkeiden (expressions) käyttöä. Projektitiedosto tallennetaan .qgs-muodossa yhdessä mahdollisten tiedostopohjaisten tasojen kanssa samaan kansiorakenteeseen. Kukin qgs-muotoinen tiedosto vastaa siis yhtä karttaa karttapalvelussa ja kartat ryhmitellään kansioittain. 
• QGIS-projektin asetuksista QGIS Server -välilehdeltä määritetään karttapalvelua varten metadata sekä WMS/WFS-rajapintojen julkaisujen asetukset.
• Projektin loput konfiguroinnit tehdään LizMap-lisäosan avulla. Valitaan halutut karttatyökalut, määritellään mittakaavat, taustakartat ja joukko WFS:n avulla käytettäviä toiminnallisuuksia, kuten datan tilastollisia visualisointeja.

 

LizMap ei tietenkään missään nimessä ole ainoa avoimeen lähdekoodiin pohjautuva työkalu karttapalvelun toteutukseen, vaan niitä on muitakin. Esimerkkeinä voisi mainita vaikkapa QWC2:n, Qgis2web:n, Geoserverin, Mapserverin, Geonoden tai vaikkapa “kotoisen” Oskari-karttapalvelun. Edellisistä kaksi ensin mainittua ovat myös erityisesti QGIS-sidonnaisia, joten miten LizMap sitten erottuu näistä tai muista mainituista ohjelmistoista? Ainakin LizMap on käyttäjäystävällinen ja melko yksinkertaisesti pystytettävissä oleva täysiverinen web-karttapalvelu monipuolisilla työkaluilla. 

LizMapin mahdollisuuksista ja käytöstä tässä käytiin vain lyhyt esittely. Lisää ominaisuuksista ja esimerkkejä voi löytää Lizmapin dokumentaatiosta. Githubista on saatavissa myös LizMapista dockeroitu versio, jolla karttapalvelua pääsee kätevästi testaamaan itse myös omalla koneella.

Kerroimme taannoisessa blogauksessamme Helsingin kaupungin kokeilukiihdyttämössä tekemästämme kaupunkilaisten palautteiden tekstianalyysistä. Nyt paneudumme toiseen kokeilukiihdyttämöhankkeeseemme, jonka tavoitteena oli analysoida ja tutkia paikkatiedon keräämistä Helsingin kaupungin vastaanottamista avustushakemuksista. 

Kokeilukiihdyttämön hankkeiden tarkoituksena on hakea uusia kokeiluja, jotka kehittävät kaupungin palveluita ja toimintaa. Tässä hankkeessa tarkastelumme keskiössä olivat kulttuurin, liikunnan ja nuorisotyön toimialojen avustukset. Kokeilussa loimme kuvan paikkatiedon keräämisen nykytilanteesta ja tulevaisuuden tavoitetilasta. Näiden lisäksi teimme konkreettisia kehitysehdotuksia Helsingin kaupungin avustusjärjestelmän kehittämiseksi. Hanketta varten loimme QGIS-projektiimme demodataa, jonka pohjalta teimme esimerkkejä mahdollisista tulevaisuuden analyyseistä. Tämän artikkelin kuvituskuvat eivät perustu kaupungin aineistoihin, vaan gispolaisten luomaan esimerkkiaineistoon.

Miksi kerätä paikkatietoa?

Helsingin kaupunki myöntää vuosittain lukuisia avustuksia. Eri toimialat myöntävät avustuksia pitkin vuotta, ja myönnetyt avustukset voivat olla mm. projektikohtaisia, kertaluontoisia, monivuotisia tai tila-avustuksia. Kaupungin työntekijöitä on jo pitkään kutkuttanut ajatus saada tukisummat kartalle, ja asiaa on hieman jo tutkittu vuonna 2017 (Arttu Antila). 

Avustushakemusten paikkatiedon paremmalla keräämisellä ja analysoinnilla saataisiin kaupungin työntekijöille parempi käsitys siitä, missä kaupungin tukemaa toimintaa tapahtuu ja miten avustukset jakautuvat alueellisesti. Paikkatietoa voitaisiin käyttää päätöksenteon tueksi ja toisaalta avustushakemuspäätösten seurantaan. Hyvä visualisointi kertoo datasta paljon ja tuo erilaista konkretiaa aineistoon kuin pelkkä Excel-tiedosto. Paikkatieto voi myös mahdollistaa mahdollisimman oikeellisen kuvan saamisen avustushakemustilanteesta.

Vaikka kokeilun kärkenä oli tutkia ja visioida paikkatiedon keräämistä, tulimme samalla tehneeksi katsauksen avustushakemusten käsittelyprosessiin ulkopuolisten silmin. Tämä oli ehdottoman tarpeellista, sillä paikkatiedon keruu, käyttö ja analyysi eivät tapahdu irrallaan nykyisestä avustusjärjestelmästä, vaan sen sisällä ja sen asettamissa reunaehdoissa. Kysymällä paikkatietoon liittyviä kysymyksiä pystyimme kartoittamaan järjestelmän nykytilaa ja suunnittelemaan tavoitetilaa, jota kohti pyrkiä.

Selvityksiä, visualisointi-ideoita ja dataputkia

Kuten monet selvitystyöt, aloitimme hankkeen kartoittamalla asiakkaan tarpeita. Onko paikkatietoa kerätty aiemmin avustushakemuksista? Millaisia tarpeita kaupungin työntekijöillä on paikkatiedolle? Mitä paikkatiedolla voitaisiin tehdä?

Tietenkin avustushakemuksista puhuttaessa kiinnostavin analyysi liittyy rahasummien alueelliseen jakautumiseen. Kuitenkin kaupungin avustushakemuspohjiin tarkemmin syventymällä ja kaupungin työntekijöiden kanssa keskustelemalla potentiaalisia analyysi-ideoita alkoi nousta enemmän. Tuomalla avustuskohteet kartalle voidaan mm. nähdä eri toimijoiden keskittyminen ja palvelujen saavutettavuus. Jos aineisto saadaan pisteinä, voidaan paikkatieto-ohjelmassa suodattaa karttanäkymään vain esimerkiksi tiettyä toimintaa tarjoavat toimijat.

Samalla kun toimijat saadaan kartalle, voidaan myös tarkastella katvealueita. Kaivamalla hakemuksista niiden toimialoja (tässä tapauksessa taide/liikunta/nuoriso), voidaan tutkia avustusten jakautumista eri toimialojen välillä alueiden sisällä. Samoin aineistoa voidaan luokitella ja tarkastella eri avustustyyppien perusteella. 

Visualisoinneissa ei ole siis kyse pelkästään toimijoiden sijoittelusta kartalle. Mutta miksi jäädä vain staattisiin visualisointeihin? Monet analyyseistä voidaan automatisoida, jolloin karttanäkymä voi päivittyä sitä mukaa kun avustuspäätöksiä tehdään. Suurin hyöty prosessien automatisoinnista kuitenkin on päällekkäisen työn vähentyminen: sama analyysi, jota eri työntekijät ovat tahoillaan tehneet käsin, voidaan ohjelmoida ja saada valmiina kaikille työntekijöille jaettuun näkymään.

Datan keruu ja laatu

Prosessien automatisointiin pääseminen ei tapahdu toki hetkessä, vaan matka ideaalitilanteeseen vaati työtä ja välivaiheita. Avustustietokannan kylkeen voidaan rakentaa paikkatietokanta (esim. PostGIS), joka kerää halutut tiedot avustuksista ja suorittaa tietyt analyysit aineistolle. Toimiva dataputki puolestaan vaatii sen, että käytetyn datan on lähtökohtaisesti oltava kunnossa.

Datan laatuun törmätään lähes kaikissa projekteissa. Lähtöaineistoa ei päästä analysoimaan, mikäli osoitteet on kirjoitettu väärin tai avustuksen hakija on ilmoittanut oman kotiosoitteensa eikä järjestämänsä toiminnan tapahtumapaikkaa. Jotta dataa voidaan siis jatkojalostaa ja analysoida, pitää miettiä kuinka dataa kerätään ja miten sen laatu varmistetaan. Datan keruuprosesseja kehittäessä on toisaalta ajateltava sitä, kuinka aineistoa käsitellään ja mitä sieltä halutaan nähdä.

Vaikka puhutaan kaupungin sisäisistä tarpeista, tiedon käyttäjiä ei kuitenkaan ole vain yksi vaan useita. Eri toimialoilla saattaa olla erilaisia tarpeita ja toiveita kerätyn datan tarkkuudesta, ja toisaalta on mietittävä datan keräämisen käyttäjäystävällisyyttä. Avustushakemuksen täyttäminen voi vaatia hakijalta jo lähtökohtaisesti paljon työtä ja monien liitteiden lähettämistä, eikä työmäärää haluta tietenkään lisätä tekemällä paikkatiedon ilmoittamisesta hankalaa tai monivaiheista. Ei ole kuitenkaan mielekästä, että työntekijät joutuisivat esimerkiksi etsimään haluttua dataa useammasta hakemukseen liittyvästä tiedostosta tai korjaamaan väärinkirjoitettuja osoitteita.

Toimintapaikkaa voidaan toki kysyä muunakin kuin osoitteena. Esimerkiksi kaupunginosa- tai postinumeroaluetarkkuus voi olla riittävä monissa yhteyksissä. Myös se mahdollistaa erilaisia näkymiä aineistoon ja avustussummien alueelliseen jakautumiseen. Potentiaalisia jatkoideoita tässä tapauksessa ovat esimerkiksi päällekäisanalyysi Tilastokeskuksen postinumeroaineiston kanssa, joka sisältää tietoja alueiden väestörakenteista. Näin voitaisiin tarkastella vaikkapa sitä, mitkä ikäryhmät ovat avustuksen saajan välittömässä vaikutuspiirissä samalla postinumeroalueella.

Toivottu tarkkuus paikkatietoasiantuntijalle on yleensä kuitenkin tarkin mahdollinen – tässä tapauksessa eksakti osoite, jossa avustettu toiminta tapahtuu. Pisteaineistosta saadaan tehtyä tarkimmat analyysit, mutta pisteet voidaan myös liittää halutessa postinumeroalueisiin. Pisteaineisto on siis tarkasteltavissa useammalla skaalalla; yksittäisinä kohteina, postinumeroaluetarkkuudella – tai vaikkapa 250 neliömetrin ruudukkona. 

Mikäli avustushakuprosessissa päästään keräämään toimijoiden toimintapaikkojen tarkkoja, ajantasaisia osoitteita, olisi mahdollista myös julkaista kaupungin tukemista toimijoista vaikkapa selainpohjainen kartta. Näkymään voidaan suodattaa esimerkiksi vain avustuksen saaneen toimijan perustiedot (nimi, osoite, kotisivut, mitä toimintaa tarjoaa). Näin saataisiin kaupunkilaisten käyttöön selainpohjaisia karttoja mm. kaupungin tukemista nuorisopalveluista tai eri liikuntaharrastusmahdollisuuksista.

Toimintapaikkatiedot voidaan kysyä esimerkiksi hakijalta raportointivaiheessa, kun hänellä on tarkka tieto siitä, missä toiminta tapahtui. Tällöin tieto on varmemmin paikkansapitävää kuin hakuvaiheen suunnitelmissa, eikä tiedon ilmoittaminen kuormita hakijaa hakuvaiheessa. Toisaalta tiedon ajankohtaisuus voi kärsiä, mikäli toimija ei jatka toimintaansa samassa paikassa vielä avustuskauden jälkeen. Käytännössä yksittäinen taidenäyttely ei todennäköisesti ole pitkään samassa paikassa, mutta ympärivuotinen nuorisotoiminta avustuksen saajan itse omistamassa tilassa voi jatkua pitkäänkin.

Lopputulokset ja jatko

Vaikka tässä tekstissä on esitetty visioita avustushakemusten paikkatiedon keruusta ja sen mahdollisuuksista, ei näihin analyyseihin ja tavoitetilanteisiin päästä heti. Kyse ei ole yksittäisestä loikasta, vaan sarjasta pienempiä askeleita, jotka pitää suorittaa järjestyksessä. Monesti myös näiden muutosten tekeminen järjestelmiin ja työorganisaation sisällä voi olla hidasta. Nyt kuitenkin pohjatyöt ovat valmiina ja lista tarvittavista toimenpide-ehdotuksista tehtynä Helsingin kaupungille.

Tämän hankkeen aikana tuotimme Helsingin kaupungille nykytilasta analyysin sekä suunnitelman nykyisen avustustietojärjestelmän parantamiseksi kohti yhdessä hahmoteltua tavoitetilaa. Teimme myös QGIS-työtilan, joka sisältää erilaisia näkymiä tekemällämme demoaineistolla ja mockupeja avustushakemusten parantamiseksi (aineisto löytyy kokonaisuudessaan Gispon GitHubista).

Näiden ideoiden ei kuitenkaan tarvitse jäädä vain avustushakemuksiin. Vaikka kyseessä on paikkatietoprojekti, hankkeesta on saatu oppeja myös yleiseen tietojärjestelmähallintaan. Samoin monet tässäkin esitetyt prosessit ja huomiot ovat sovellettavissa muihinkin lomakkeisiin, joissa kerätään tai halutaan kerätä paikkatietoa.

Kulkiessamme kohti vähähiilistä yhteiskuntarakennetta paikkatietojen merkitys kasvaa. Vuonna 2021 Gispo oli kehittämässä Tampereen maamassojen tiedon hallintaa kaupungingeodeetti Anna Mustajoen ja kaupungin maamassakoordinaattori Matti Pokkisen johdolla. Kaupungeille elintärkeistä maamassoista syntyy merkittäviä ympäristöpäästöjä sekä taloudellisia kustannuksia. Päästöjen ja kustannuksien vähentämiseksi on tuotettava dataa, jonka avulla voidaan suunnitella, hallita ja optimoida maamassojen siirtelyä ja hallintaa.

Maamassaa kuljetetaan kaupunkien sisällä paikasta toiseen merkittävissä määrin. Koko kaupunki-infra perustuu tietyllä tapaa erilaisten maamassojen hallintaan: 

• Meluvalleja varten kuljetaan soraa
• Rakennustyömaat tarvitsevat osaltansa useita kerrosaineiksia
• Puistoympäristöjen hoito vaatii taas omanlaistansa maamassaa 

Tarjonta ja kysyntä eri maalajeista kohtaavat, jos ja kun kaupunki onnistuu tuottamaan ja keräämään dataa maamassoista, eri maamassatyyppien sijainnista ja saatavuudesta eri puolilla kaupunkia. 

Maamassojen kuljetusten suunnittelu ja massojen hallinta ponnistaa keskeisesti sijaintipohjaisesta tiedosta. Perinteisesti kuljetuksia on ohjattu ennen kaikkea virkahenkilöiden ja urakoitsijoiden hallitseman operatiivisen tietämyksen eli hiljaisen tiedon pohjalta. Kovenevien taloudellisten ja ympäristöllisten tavoitteiden nimissä kaupungit sijoittavat nyt dataohjautuvuuteen ja sitä kautta toimiensa optimoimiseen. 

Suomalaiset kaupungit ovat lähteneet mukaan maamassojen koordinointiin viimeisten kymmenen vuoden sisällä. Maamassojen tietopohjaisen hallinnan ja sitä myöten maamassojen hyötykäytöllä on saavutettu merkittäviä säästöjä. Helsingissä on arvioitu säästöjä syntyneen 40 miljoonaa euroa 4-5 vuoden aikana, kiitos maamassojen tietopohjaisen hallinnan.

Tampereen ja Gispon yhteistyöprojektin tuloksena kaupungille syntyi työkalu, jonka avulla voidaan tuottaa paikkatietoa maamassojen sijainneista, tarpeista ja kysynnästä sekä niiden jalostamisesta. Tätä tietoa voidaan käyttää puolestaan tietojohtamisen raaka-aineena. Maamassakoordinaattorin työkaluksi valikoitui paikkatieto-ohjelmisto QGIS ja paikkatietokannaksi PostgreSQL & PostGIS-tietokantaympäristö. 

Tietomallipohjainen tiedontuotanto ja määrämuotoinen tiedon hallinta mahdollistavat kaupungille tavan optimoida toimiaan minimoidakseen satojen tuhansien ellei miljoonien eurojen kustannuksia sekä maamassojen kuljetuksista aiheutuvia mittavia päästövähennyksiä. 

Digitaalisen transformaation avulla yhteiskuntamme eri prosesseista tulee kasvavissa määrin mitattavia ja hallittavia. Kuten aina, kaikki tapahtuu jossain, ja datan keruumenetelmien kasvaessa ja rikastuessa myös paikkatietoa tullaan tuottamaan ja hyödyntämään päätöksenteossa kasvavissa määrin.

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ää