Tavallisen paikkatietoihmisen käytössä olevien 3D-aineistojen tarjonta ja laatu on kasvanut viime vuosina kovasti. Esimerkiksi Maanmittauslaitos tuottaa laserkeilaamalla uutta maaston korkeusmallia 2 metrin hilana, jonka korkeustarkkuuskin on alle metrin. Tässä on aika huikea muutos edelliseen, koko Suomen kattaneeseen 10 metrin hilakokoon nähden. 

Maaston lisäksi käytössämme rupeaa olemaan hyvinkin tarkkoja, aidosti kolmiulotteisia rakennusaineistoja. Muutamat kaupungit ovat jo julkaisseet omia CityGML-skeemaan pohjautuvia mallejaan, ja tulossa oleva Kansallinen Maastotietokanta esittää koko maan rakennusten muodot usealla eri tarkkuustasolla (LOD 0 – LOD 3). Näistä tarkin sisältää esimerkiksi kattojen kaltevuudet, ulkonevat parvekkeet ja katokset sekä pylväät. Kaarevia pintoja ei KMTK:n CityGML-tiedostoformaatti pysty käsittelemään.

Yhä tarkempien maasto- ja rakennusmallien lisäksi 3D-ominaisuuksia tarvitaan ohjelmistoilta mm. uusien kolmiulotteisten kiinteistöjen hallinnoimiseksi. Pari vuotta sitten voimaan tulleen lakimuutoksen jälkeen kiinteistölle on voitu määrittää myös korkeusasema, ja samassa sijainnissa voi olla päällekkäin useita kiinteistöjä. Tämä helpottaa mm. parkkihallien ja -kansien sekä muiden monimutkaisten kohteiden hallinnointia tiheään rakennetuilla alueilla.

Aitoa työskentelyä 3D-karttanäkymässä

3.0 -versiosta alkaen QGIS on sisältänyt oman työkalun, 3D view:n eli -karttanäkymän, kolmiulotteisten aineistojen visualisoimiseksi. Alkuvaiheessa se oli ainakin oman koneeni näytönohjaimelle liian raskas, mutta nykyään (versiossa 3.10) se toimii jo kivasti. Normaalin kuvaustekniikan sijasta (tai lisäksi) vektorikohteille voi määrittää 3D-kuvaustekniikan: asettaa kohteiden korkeuden johonkin ominaisuustietoon perustuen ja säätää pintojen värin, kiillon ja varjostuksen. On huomattava, että jos geometria on aidosti kolmiulotteinen (kuten esimerkkikuvan CityGML:stä muunnetussa geopackage-aineistossa), ei 3D-kuvaustekniikkaa tarvitse asettaa erikseen. Aineistossa on erikseen tasot katto- ja seinäpinnoille ja 3D-karttanäkymä hyödyntää suoraan näille tasoille asetettua kuvaustekniikkaa.

Jos taas 3D-mallissa halutaan esittää pelkkä maastomalli ilman rakennuksia, sen päälle voi liimata esim. ortokuvan. Varsinkin Etelä-Suomessa maastonmuodot ovat sen verran litteitä, että korkeusarvon liioitteleminen vaikkapa kaksinkertaiseksi tekee mallista hieman näyttävämmän näköisen.

3D-karttanäkymän asetuksissa voi mm. vaihtaa valon tulokulmaa ja väriä tai asettaa useamman valonlähteen. Tiilen kokoa voi säätää oman koneen suorituskyvylle sopivaksi. Näkymää voi pyöritellä eri suuntiin helposti hiirellä, ja se sisältää QGISin 2D-karttanäkymästä tuttuja toimintoja, kuten kohteen tietojen kysely Identify-painikkeella ja mittaustyökalu. 3D-karttanäkymästä löytyy myös mainio fly-by-animaation rakentamistyökalu, jolla voi asettaa tietyt kuvakulmat tiettyihin ajanhetkiin avainkehyksiksi, ja animaatio kulkee näiden avainkehysten välillä tasaisesti. Harmi vain, että tätä animaatiota ei saa vietyä QGISista ulos muuten kuin kuvasarjana, ja animaatio täytyy viimeistellä esim. GIFfiksi muualla.

3D-karttanäkymän heikkoutena voidaan (GIFien viennin puuttumisen lisäksi) pitää sen raskautta. Yhtään suuremmat maastomallit latautuvat varsin vaivalloisesti, ja maaston ja vektorikohteiden yhdistäminen on jo liikaa ainakin allekirjoittaneen koneen suoritusteholle. Lisäksi 3D-kuvaustekniikan määrittely on melko suppea: kohteita ei voi esimerkiksi luokitella niiden tyypin mukaan.

Vanha kunnon lisäosa

Monien tilastoaineistojen esittämisessä onkin mukavampi turvautua vanhaan tuttuun lisäosaan Qgis2threejs. Se on ollut käytössä jo paljon ennen 3D-karttanäkymän tuloa, ja tämän vuoksi aiheutuukin muutamia ristiriitoja. Jos olet avannut QGIS-projektissasi 3D-karttanäkymän, ei Qgis2threejs-lisäosa toimi ennen QGISin buuttaamista. Pisteet siitä, että lisäosa informoi käyttäjää tästä, eikä bugia tarvitse jäljittää itse!

Lisäosan vahvuutena on vektoriaineistojen kuvaustekniikka: se lukee luokittelun, läpinäkyvyyden ym. tyyliasetukset suoraan tason kuvaustekniikkamäärittelyistä. Korkeusarvon voi asettaa ominaisuustietokentän tai siitä johdetun lausekkeen avulla. Tarkkoja ilmakuvia ja muuta rasteriaineistoa Qgis2threejs ei sen sijaan piirrä yhtä tarkasti tiiliä laskien kuin 3D-karttanäkymä. Ortoilmakuvalla täydennetty pintamalli meneekin sillä nopeasti rakeisen näköiseksi.

Toinen ominaisuus, joka tekee lisäosasta miellyttävän käyttää, on mahdollisuus viedä malli html-tiedostoksi jolloin sitä on helppo tarkastella myös QGISin ulkopuolella sekä jakaa ja julkaista laajemmallekin yleisölle. Html sisältää interaktion, eli mallia voi pyörittää ja zoomailla, ja sen saa myös pyörimään hitaasti itsensä ympäri. Lisäosan dokumentaatiossa kerrotaan myös mahdollisuudesta tallentaa malli gITF-formaatissa jolloin siitä voi tehdä 3D-tulostimella fyysisen mallin!

Työkalu tarpeen mukaan

3D-karttanäkymällä ja Qgis2threejs-lisäosalla on siis omat vahvuutensa ja rajoitteensa. Itse käytän lisäosaa mielummin tilastoaineiston visualisoimiseen sen monipuolisten kuvastekniikkaominaisuuksien vuoksi. 3D-karttanäkymä taas mahdollistaa hyvinkin tarkan realistisen maastomallin tekemisen, jos vain koneessa riittää tehoja. Suurena puutteena on näkymän pysyminen QGISin sisällä. Fly by-animaatioita kiinnostuksen alaisesta alueesta olisi erittäin hyödyllistä pystyä esittämään laajemmallekin yleisölle.

Hiphei! Alamme tuottamaan QGISiin työkalua, jolla voi käsitellä paremmin Ilmatieteenlaitoksen ilmanlaatudataa. Voitimme nimittäin Forum Viriumin UIA-HOPE innovaatiokilpailun! Olimme yksi kuudesta kisan voittaneesta ja yhteensä ideoita saatiin 43 kappaletta. 

Keväällä, kun ideaa palloteltiin, tuli mieleen vaikka mitä ajatuksia, mutta kaikissa niissä datan laatu ja saatavuus asetti rajoitteita. Aloimme lopulta miettimään, että mikä meille itselle on aihepiirissä haastavinta ja todettiin, että se datan saatavuus helpossa muodossa on se tärkein juttu.

Ilmatieteenlaitoksen data on avoimesta saatavilla, mutta niin kompleksista johtuen eri parametreistä ja havaintojen määrästä ajassa ja paikassa. Siksi ehdotuksemme perustuukin QGISin lisäosan kehittämiseen FMI:n ENFUSER-datalle.

Ilmeisesti kisaraati oli samaa mieltä ja hakemuksemme kuvaus riitti voittoon:

“Ilmatieteen laitoksen rajapinnat ovat keskeinen datalähde ilmanlaatutiedon kannalta. Monipuoliset ja hyvin dokumentoidut rajapinnat eivät kuitenkaan toimi tällä hetkellä suoraan QGIS-työpöytäohjelmistossa. Avoimen lähdekoodin QGISiä käyttää pelkästään Suomessa arviolta sata organisaatiota ja globaalisti käyttäjiä on kymmeniä tuhansia. Rakentamalla toimivan ja helppokäyttöisen datayhteyden QGIS-lisäosana FMI:n rajapintoihin voidaan ilmanlaatutiedon käytettävyyttä ja potentiaalista käyttäjäkuntaa laajentaa huomattavasti.”

Työ siis alkaa Gispolla nyt, ja tarkoitus on tässä syksyn aikana kehittää työkalua QGISille datan käsittelyyn. Toteutuksesta vastaa meillä fyysikkovahvuutemme FT Jaakko Lehto, joka onkin odotellut vastaavaa projektia, jossa voi käpistellä isoja datamassoja ja koodailla QGISille lisäosia. Lisätietoa tulossa, kun päästään testaamaan. Kysymyksiä (ja ehdotuksia) projektista voi laittaa Jaakolle (jaakko@gispo.fi).

Nyt ei puhuta parisuhteista vaan relaatioista. Eli tietokannoista ja QGISistä. En ole ihan varma olisiko tuo ensimmäinen helpompi aihe. Jos relaatiot, suhteet ja tietomallit eivät ole tuttuja, kannattaa tutustua aiheeseen ja kirjoihin, kuten Fundamentals of Database Systems (Elmasri & Navathe). Lisäksi QGISin ohjeistus relaatioiden tekemiseen ja attribuuttitaulujen käsittelyyn on todella hyvä (Working with the Attribute Table).

Pekka-pomo tiesi, että nykyään laajasti käytössä olevat relaatiotietokannat (kuten PostgreSQL) perustuvat 1970-luvulla kehitettyyn relaatiomalliin (http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf).  Yksinkertaistettuna relaatiomallissa tiedot organisoidaan sarakkeista ja riveistä koostuviin tauluihin sekä taulujen välisiin relaatioihin. Eli tarvitaan pari taulua ja pohtia miten ne liittyvät toisiinsa.

Tehdään testiaineisto

Helpoiten homman opettelu menee, kun miettii itselleen tutun ja järkevän ja suhteellisen simppelin keissin, jossa taulujen välille pitää muodostaa yhteys. Tässä esimerkissä palaan lempiaiheeseeni, eli puutarhaan.

Puutarha-taulu on päätaulu (parent), joka sisältää ainoastaan puutarhan nimen ja ulkorajauksen. Puutarhaan sisältyy kukkapenkkejä (child). Tärkeää on ymmärtää, että kukkapenkkejä voi olla useita yhden puutarhan sisällä. Eli relaatiomaailmassa tämä on 1:N -relaatio (yhden suhde moneen). Tämä on vielä helppoa käsittää, eikö?

Kukkapenkissä voi olla useita kasvilajeja. Halutaan tietää missä kaikissa kukkapenkeissä kasvaa sama kasvilaji eli myös kasvilajilla on useita kukkapenkkejä. Tällöin tarvitaan monen suhde moneen relaatio (N:M). Sama kasvilaji voi siis liittyä useaan kukkapenkkiin.

Miten tämä hoidetaan QGISissä?

Tässä esimerkissä tehdään GeoPackage, jossa on neljä taulua. Taulut sisältävät puutarhat, kukkapenkit ja lajilistan. Yksi tauluista on aputaulu, joka yhdistää monen-suhde-moneen relaation tarvitsemat kukkapenkit ja lajit. Jos toteutus perustuisi esimerkiksi PostGIS-tietokantaan, johon on viety valmis relaatiomalli, QGIS tunnistaisi relaatiot ja tarvittavat taulut automaattisesti.

Eikun tekee vaan – luodaan taulut

• Puutarhan_rajaus (polygon), kenttänä fid
• Kukkapenkki (polygon), kenttänä fid + nimi + fk_puutarha (jonka avulla toteutetaan viittaus puutarhaan)
• Lajilista (ei-geometriaa sisältävä taulu), kenttänä fid + lajinimi (lisää muutama rivi tietoa tauluun)
• Lajit_kukkapenkki (ei-geometriaa sisältävä taulu, jolla yhdistetään lajilistat ja kukkapenkki), kenttänä fid, lajit_fk  ja kukkapenkki_fk

Luodaan relaatiot QGIS-työtilaan

Varmista, että työtilassa on kaikki neljä taulua oikeilla kenttänimillä. Avaa QGISin Ominaisuudet > Relaatiot ja määritä taulujen välille yhteydet. Se tehdään tuottamalla tarvittavat relaatiot siten, että taulujen id:t linkittyvät oikein (parent ja child).

Tarvitaan 1:N-relaatio: Kukkapenkki kuuluu puutarhaan (Puutarhan_rajaus.fid – Kukkapenkki.fk_puutarha).

Tarvitaan myös N:M-relaatio molempiin suuntiin, tässä käytetään aputaulua: 

• Kukkapenkki_laji: Kukkapenkki.fid – lajit_kukkapenkki.kukkapenkki_fk
• Laji_kukkapenkki: Lajit.fid – lajit_kukkapenkki.lajit_fkRelaatioiden pitäisi näyttää tältä

Attribuuttitaulun lomakkeen tuunailua

Voit tarkastaa miltä tasojen attribuuttitaulukko näyttää. Seuraava vaihe on tuunata QGISin attribuuttilomakkeita siten, että relaatioiden käyttö on mahdollisimman kätevää.

Klikkaan ensin Puutarhan_rajaus-tason Ominaisuudet > Attribuuttilomake > Drag and Drop. Vedä lomakkeelle vain seuraavat kentät: nimi + tehty relaatio. Tarkista relaation määritykset kuvan mukaiseksi.

Säädä myös Kukkapenkki-taulun lomaketta Drag and Drop designerilla ja tarkista, että kentällä fk_puutarha (relaatio puutarhaan) on määritelty relaatio widgettiin. Vedä Taittoon Kukkapenkin_tunniste ja relaatio Kukkapenkki_laji. Säädä Kukkapenkki_laji-relaatiosta, että lomakkeella ei näy linkkausnappulaa.

Säädä Lajit-taulusta Drag and Drop -näkymässä, että lomakkeella näytetään vain yksilölliset arvot Lajeista.

Säädä lajit_kukkapenkki-taulusta molemmat relaatiot kuntoon ja salli niiden editointi. Poista näkyvistä muut kuin Laji_fk (sille voi antaa Alias-nimeksi vaikka “Lajin id”). Tarkasta display expression -kohdasta, että vimpain näyttää halutusti lajin nimen eikä id:tä (tämä helpottaa käyttöä).

Testaa lopputulos

Tarkasta Puutarhan_rajaus taulusta, että lomake näyttää hyvältä, jos haluat, säädä alias-nimiä. Tallenna työtila.

Mene lopuksi Projektin ominaisuuksiin ja salli Transaktiot tasojen välillä. Tällöin sallit sen, että kaikki tasot ovat editoitavana yhtäaikaa. Huomioi, että jos jokin taso on editoitavana, transaktio-nappula ei ole aktiivinen. Eli poista kaikkien tasojen editointitila, jos jokin sattuu olemaan päällä.

Testaa toimiiko piirtämällä ensin puutarhan rajaus ja siihen kuuluva kukkapenkki. Kannattaa tallentaa kohteet välillä ennen lajien syöttöä.

Huomioita QGISin relaatioista

• Jotta relaation kautta haettavat tiedot voidaan linkittää kohteeseen, pääkohteen pitää olla aina olemassa. Tämän vuoksi, jos kohdetta vasta luodaan, kohde on hyvä tallentaa ensin. 
• N:M-relaatioissa voi olla tarpeen hakea aputauluun myös jokin toinen kenttä kuin id, sillä se ei aina kerro käyttäjälle kaikkea.

Topin vinkki geometria-funktion käyttämiseen

On se vaan kiva kun on kollegoja. Pohdin, että varmaan on mahdollista liittää automaattisesti geometriaan perustuvia tietoja toiseen tauluun ja kävi ilmi, että näin on. Topilta sain vinkin, että jos kohde kuuluu johonkin alueeseen, voidaan funktion avulla hakea geometriaan perustuen toisen kohteen tietoja. Esimerkiksi jos piirretään kukkapenkkejä erikseen ja puutarhoja on useita ja kukkapenkki osuu jonkin puutarhan sisälle, siihen tallentuu kyseisen puutarhan id. Tällaisia expressioneita voi tuottaa attribuuttitauluun Oletus-kohtaan. 

aggregate(
layer:= 'Puutarhan_rajaus_c199cd10_d86e_4d68_806e_4e7d2adeb2a4',
aggregate:='concatenate',
expression:=nimi,
concatenator:=', ',
filter:=intersects($geometry, geometry(@parent))

Olen saanut toimia yhden hienon avoimen lähdekoodin projektin viestinnän tukena nyt kolme vuotta ja viimeistä viedään! Tavallaan nyt on helpottunut ja silti haikea fiilis.

Taustalla projektissa on aito innostus ja usean organisaation ihailtava sitoutuminen avoimen lähdekoodin tuotteen tuottamiseen: paljon ideoita, toiveita, tarpeita ja eri alojen erikoisosaamista. Ja superhyviä paikkatieto-osaajia! Kehittämisryhmästä on muodostunutkin vertaistukiryhmä toisilleen kaikissa paikkatietoalan asioissa. 

Kolmessa vuodessa projektista on kehkeytynyt avoimempi, monipuolisempi ja sen käyttö on laajentunut maailmalle. Ja se on koko yhteisön ansiota. Ehkä paras tunnustus oli yhteisön saama ProGIS ry:n palkinto viime vuoden paikkatietomarkkinoilla. Se yllätti ja lämmitti sydäntä. 

Samalla kun näen, että projekti on edennyt huimasti ja alkanut enemmän ja enemmän toimia avoimen lähdekoodin periaatteiden mukaisesti, toivon samalla että asioita olisi tapahtunut vieläkin enemmän. Ja että itse olisin ehtinyt tehdä enemmän. Muutamaa asiaa, jotka olivat jo syksyllä 2017 työlistalla, ei ole saatu vieläkään toteutettua. Yksi niistä on OSGeo Foundationin hautomosta valmistuminen. En edelleenkään tiedä miksi näin on, tarvittavat avoimuuden toimenpiteet on suoritettu ja raportoitu, mutta asia ei etene OSGeon hallituksessa. Ehkä asia on enemmän kiinni resursseista ja ajasta, kuin koodista. Koen, että avoimen lähdekoodin projekteissa kansainvälisyyteen puskeminen olisi kaikkien yhteisön jäsenten tehtävä, jolloin projektin vakuuttavuus on vakaammalla tasolla.

Tuotetta ei ole vielä aivan täysillä lähdetty viemään eteenpäin minkään yrityksen toimesta, vaikka hyviä keissejä jo näkyykin maailmalla. Sen avulla saisi todella helposti toteutettua esimerkiksi SAAS-palvelun, jota voisi myydä eri asiakkaille sellaisenaan tai kustomoida asiakkaan tarpeisiin. 

Kolmas huoli projektin osalta on Markkinat. Alalla on useita avoimen lähdekoodin karttapalvelujärjestelmiä, joilla on jokaisella hieman erilainen lähestymistapa paikkatietojen esittelyyn. Toisaalta juuri kuulin, että yhdessä projektissa oli käynyt läpi toistasataa alustaa ja päädytty tähän vaihtoehtoon sen toiminnallisuuksien ja vakaan yhteisön ansiosta. Asiakkailla ja toimittajilla on siis mahdollisuus valita useasta tuotteesta oman tarpeensa mukaan. Tämä on hyvä, mutta kilpailu on kovaa. Siksi tuotteella pitää olla hyvä brändi ja sitä pitää myös myydä aktiivisesti.

Paras paikka viedä esille asiaa on ollut kansainväliset FOSS4G konferenssit. Ehkä sinne taas joskus päästään. Sitä ennen pitää tavata virtuaalisesti ja huudella somekanavilla. Sekin auttaa.

Uskon, että tuotteella on potentiaalia. Se tukee OGC:n standardeja, se on stabiili ja sitä kehitetään aktiivisesti eteenpäin. Sen kehittäjäkunta on laajentunut vuosien aikana mukavasti. Sitä kehitetään hienosti avoimen lähdekoodin periaatteiden mukaisesti. Sen paras ominaisuus on julkaistava karttanäkymä, johon loppukäyttäjä voi valita omia aineistojaan ja palveluntarjoajan aineistoja ja upottaa se vaikka oman urheiluseuran sivuille. Sitä voi räätälöidä minkä näköiseksi vain. 

Sen tarina alkoi noin kymmenen vuotta sitten, kun Suomelle tarvittiin kansallista geoportaalia, lähes alusta asti oli selvää, että projekti tehdään avoimen lähdekoodin komponentteja hyödyntäen. Samalla huomattiin, että muutama muukin organisaatio voisi tarvita omaa paikkatietoportaalia. Lopulta koko projekti avattiin avoimella lisenssillä. Itse olin innolla ottamassa sitä käyttöön edellisessä työpaikassani jo vuonna 2014. Nyt Suomessa on kymmeniä organisaatiokohtaisia Oskari-pohjaisia palveluita ja varmasti satoja niistä tehtyjä karttajulkaisuja eri sivustoilla. 

Olen joskus sanonut, että avoimen lähdekoodin projekteissa tärkeintä ovat ne taustatarinat ja ihmiset, jotka kylmän softan takana ovat. Tämän softan takana on niin monta ihanaa tyyppiä, että lista veisi varmasti muutaman sivun tilaa. Softa ei olisi mitään ilman Janeja, Timoja, Samia, Rinaa, Minnoja, Mattia, Markoja, Lari-Pekkaa, Henna-Kaisaa, Elinaa, Nataliaa, Annaa, Outia, Jaakkoa, Jaria, Jarnoa, Jussia, Haflidia, Miskaa, Tuulia, Ailaa, Eevaa, Ekiä, Markkua ja Jenniä ja monenmonta muuta! 

Kiitos, että sain tehdä viestintäkoordinaattorin hommia ja varmasti vielä Oskarin parissa puuhastellaan jatkossakin!

Hiljainen tieto: organisaation voimavara ja vaaranpaikka

Me täällä Gispolla toteutamme usein projekteja, joissa asiakkaan paikkatietoaineistot ja niiden käsittelyn prosessit siirretään uuteen tietojärjestelmään. Homma etenee klassisesti käsitteiden määrittelystä tietomallin nykytilanteen kuvaamiseen ja sitten suunnitelmaan, miten aineistoja olisi paras hallinnoida uusissa tietokannoissa. Tyypillisesti isossa organisaatiossa osa käytetyistä ohjelmistoista voi olla vanhojakin, ja dataa on kertynyt pitkältä ajalta. Prosessit, joilla tietoa siirretään ohjelmistojen välillä ja mahdollinen raportointi eteenpäin ovat vakiintuneet pitkän ajan kuluessa, ja homma toimii totuttuja uria pitkin. 

Sitten jokin viranomaispäätös tai vanhan ohjelmiston tuen loppuminen pakottaa organisaation muutokseen. Samalla ruvetaan kartoittamaan edullisempia ja avoimempia ratkaisuja, siivoamaan vanhoista tietokannoista tarpeettomia tuplakappaleita ja järkeistämään käsin tehtävää tiedonsiirtoa. Konsultin kanssa samassa kokoushuoneessa istuvat asiantuntijat ja projektipäälliköt ovat innoissaan: vihdoinkin tähän saadaan joku selkeys!

Kun katseet alkavat harhailla

Kun ryhdymme kartoittamaan nykytilaa ja piirtämään siitä riittävän tarkkaa kaaviota, törmäämme usein vaiheeseen, jossa kokoushuoneessa ei enää vallitsekaan yksimielisyys. Kukaan ei tunnu oikein tietävän, mistä raakadata tulee, miten se myöhemmin siirtyy toiseen järjestelmään tai miten muutoksia tallennetaan. Katseet alkavat harhailla. Sitten kuuluu jo tutuksi tullut lause: “Tätä pitäis oikeastaan kysyä Tuulalta!”

“Tuula” (joskus myös Timo) viittaa tässä yläkäsitteeseen, joka kattaa kaikki datan käsittelyn työmyyrät. Tuula on ollut talossa töissä pitkään, paljon pidempään kuin tuoreemman koulutuksen saaneet projektipäälliköt. Hän on nähnyt tiedonkäsittelyn automatisoitumisen vaiheet ja tietää aineiston historian. Hänellä on pieni työpiste, siellä pöytäkone ja ergonominen hiiri, ja raudanlujat rutiinit ohjelmistojen käyttöön. Tuula hälytetään paikalle seuraavaan kokoukseen, jossa hän istuu hiukan orvon näköisenä. Ryhti nousee kuitenkin pian, kun esimiehetkin myöntävät, etteivät he oikeastaan tiedä miten Tuula tehtävänsä tekee, koska se on aina hoitunut moitteetta. Tuulan avulla tietomalli tarkentuu, tarpeettomat työvaiheet tunnistetaan, ja samalla saadaan arvokasta palautetta käytettävyyden huomioimisesta uudessa järjestelmässä.  

Tuula, ethän jää bussin alle tai edes eläkkeelle

Tuulan hiljainen tieto on arvokasta, mutta samalla vaarallista. Jono Bacon esittelee kirjassaan The Art of Community niin sanotun bussiskenaarion: jos avoimen lähdekoodin kehitysprojektin hallinnointi lepää yhden ihmisen harteilla, ja tämä henkilö jää bussin alle, koko projekti pysähtyy, jos projektia ei ole dokumentoitu hyvin. Tapahtuman ei tietenkään tarvitse olla näin dramaattinen. Työntekijät saattavat jäädä sairaslomalle, vuorotteluvapaalle tai eläkkeelle tai vaihtaa kokonaan työpaikkaa. Heidän mukanaan menetetään jatkuvasti hiljaista tietoa ja arvokkaita kontakteja toisiin organisaatioihin. 

Mitä jos jokaisesta muutoksesta kirjautuisi tieto tietojärjestelmään?

Jo syntynyttä hiljaista tietoa pitää pystyä hyödyntämään, ja samalla huolehtimaan siitä, että jatkossa kaikki tieto olisi myös dokumentoitu. Tätä voidaan tukea mm. tietokannan automaattisella lokituksella. Kun jokaisesta muutoksesta kirjautuu tieto siitä, kuka muutoksen on tehnyt ja milloin sekä lyhyt päiväkirjamerkintä muutoksen syistä, on aineiston historia jäljitettävissä luotettavasti. Käyttäjää vaihe vaiheelta ohjaava käyttöliittymä vastaa Tuulan päässä olevaa prosessimallia ja varmistaa, ettei mikään työvaihe pääse unohtumaan. Automaattiset tarkistukset esim. päivämäärien oikeellisuudesta ja tyhjäksi jätetyistä kentistä on helppo toteuttaa joko tietokannan tasolla tai suoraan QGISin käyttöliittymään. Kenttien linkitetyt arvoluettelot vapauttavat tiedonkäsittelijän aivokapasiteettia tärkeämpiin tehtäviin, kun jokaista numerokoodia ja kirjoitusasua ei tarvitse muistaa ulkoa tai tarkistaa erillisestä luettelosta.

Tuula tarvitaan suunnitteluun mukaan

Yllä luetellut asiat saattavat kuulostaa pieniltä, mutta niillä on suuri merkitys, kun käsiteltävän datan määrä on suuri ja päivittäisiä toistoja tulee kymmeniä ja satoja. Yhtä tärkeää on, että ne suunnitellaan yhdessä Tuulan kanssa. Hänhän loppujen lopuksi tietää, millaisia toimintoja tarvitaan, ja on uudenkin tietojärjestelmän loppukäyttäjä. Tuulaa ei voi korvata automatisoiduilla toiminnoilla, mutta hänen työtehoaan ja -tyytyväisyyttään voi kasvattaa. Tietojärjestelmä koostuu paitsi ohjelmistoista ja tietokannoista, myös niitä käyttävistä ihmisistä. 

Erilaisten tiedostoformaattien kanssa toimiminen on kaikille paikkatietoasiantuntijoille tuttua. On kuitenkin muutamia formaatteja, jotka aiheuttavat käyttäjillä harmaita hiuksia. Varsinkin, jos ei ole myynyt sieluaan jollekin järjestelmätoimittajalle. 

Toimiiko KuntaGML QGISillä? Tätä kysellään tasaisin väliajoin. Gispon tukipalveluartikkeli KuntaGML:n käytöstä on kerää edelleen kohtuullisen tasaisesti klikkauksia Googlesta. Selkeästi KuntaGML:n käyttöön QGISillä on siis kiinnostusta. Myös Jarno Kinnunen (a.k.a. Paikkatietomies) on blogissaan tarkastellut tapoja lukea kyseistä formaattia. 

Rajapintojen hyödyntäminen komentorivipohjaisten ratkaisujen tai epävarmasti toimivien lisäosien kautta ei ehkä ole tavalliselle käyttäjälle kovinkaan houkuttelevaa. Voisiko siis olla joku yksinkertainen lisäosa QGISiin, jolla vain voisi lukea dataa sisään? Kyllä voisi. 

KuntaGML:n taustaa

Mikäs tämä KuntaGML oikein on? KuntaGML on Suomen paikkatietokentän formaattikummajainen, joka pompsahtelee esille aina erilaisissa yhteyksissä. Edellisellä vuosikymmenellä osana KRYSP-hanketta kehitetyn formaatin oli tarkoitus olla yleinen paikkatietojen siirtoformaatti Suomessa. Tai kuten hankesivuilla asia on määritelty: 

“Yleisenä toiminnallisena tavoitteena on ottaa kunnissa käyttöön standardimuotoiset paikkatietopalvelurajapinnat ja mahdollistaa kaupallisten sekä viranomaisten järjestämien, kuntien tuottamaa paikkatietoa hyödyntävien tietopalvelujen toteuttaminen.”

Hieno tavoite, mutta valitettavasti 10 vuotta myöhemmin voidaan todeta että ihan tähän ei päästy. Yhteensopimattomuus INSPIRE-direktiivin kanssa, epäselvä hallintamalli, hankala hyödynnettävyys ja yleinen avoimen datan politiikka olivat kaikki tekijöitä, jotka eivät varsinaisesti tukeneet KuntaGML:n toimintamallia. Kuntatietopalvelun kuoppaamista voidaan pitää yhtenä KuntaGML:n kuoliniskuna. 

Rajapintoja kuitenkin on edelleen toiminnassa ja niitä käytetään. Tai olisi mukava käyttää jos siihen olisi sopiva työkalu. No nyt on ainakin pohja sellaiselle. 

Lisäosan kehitysprosessi

Meillä Gispolla Joona lähti tutkimaan vielä helpompia  tapoja lukea KuntaGML-formaattia QGISiin ja lähti kehittämään QGISin lisäosaa aineistojen lukemiseen.  Jo muinaiset Gispolaiset (i.e. Mäkisen Erno) olivat tehneet työkalun kehitykseen ansiokasta pohjatyötä, mutta kokonaisuuden paketointi helppokäyttöiseen ja toimivaan kokonaisuuteen oli syystä tai toisesta jäänyt vielä tekemättä. 

Formaatti perustuu OGC:n GML-formaattiin, mutta skeemat ovat rakenteeltaan hyvin vaihtelevia ja käytännössä kattavaa dokumentaatiota rajapinnoista ei oikeastaan ole saatavilla. KuntaGML-pohjaisia rajapintoja löytyy kuitenkin avoimina (siis jotka eivät vaadi tunnistautumista) esimerkiksi Turusta ja Riihimäeltä. Näillä myös testattiin kehitettyä lisäosaa. 

Joona itse kommentoi tätä lyhyttä kehityssprinttiä seuraavasti:

“Erno oli onneksi tehnyt jo raskaan työn havaitessaan ja korjatessaan virheitä tietyissä KuntaGML:n XML-skeemoissa. Lisäosan tehtäväksi jäikin skeemojen korjaaminen ja haluttujen tasojen lisääminen QGISiin. Lisäosa tallentaa halutut tasot kätevästi Spatialite-tiedostoon, jotta niiden käsitteleminen QGISin puolella olisi mahdollisimman vaivatonta. Haastavinta kehitystyössä oli KuntaGML:n aineistojen saaminen yksinkertaisempaan muotoon siten, että kaikki oleellinen tieto pysyy mukana ja on helposti käytettävissä myös QGISin puolella.”

Aineistot käyttöön lisäosan avulla 

Kehitetty lisäosa on julkaistu Gispon GitHubissa. GitHubista löytyy myös ohjeet työkalun käyttöönottoon, mutta tässä askeleet vielä pähkinänkuoressa:

• Lataa kyseisen repositorion releaseista uusin  zip-paketti (ei siis koko tätä repoa, vaan erikseen releaseista tiedosto KuntaGMLLoader.zip)
• Avaa QGIS ja mene käyttöliittymässä lisäosavalikkoon ja sieltä etsi vasemmanpuoleisesta valikosta kohta josta voit asentaa lisäosia zip-tiedostosta (Plugins → Install from ZIP)
• Etsi lataamasi tiedosto ja asenna. Kun näet sinisen palkin lisäosadialogissa, on asennus onnistunut. 

Tämän jälkeen lisäosavalikon alle ilmestyy uusi työkalu. KuntaGML Loader. Syötä KuntaGML-rajapinnan osoite ja lisäosa lataa sinulle sieltä löytyvät kohteet. Alla vielä sama animaationa.

Tämän jälkeen saat geometriat ja ominaisuustiedot esimerkiksi rakennuksista projektiisi. Jotta kyselyt eivät rajottaisi rajapintoja liikaa, on lisäosassa vielä rajoitus kohteiden hakemisen määrän suhteen. 

Tiedot esimerkiksi rakennusten sijainnista ja ominaisuustiedoista on tallennettu erillisiin skeemoihin, joten ne ladataan erillisiksi tasoiksi projektiin. Nohevalle QGISin käyttäjälle näiden tietojen yhdistäminen ei kuitenkaan pitäisi aiheuttaa suurta päänvaivaa joko taululiitoksen tai projektin sisäisen relaation avulla. 

Toteutimme siis toimivan konseptin työkalusta. Tämä ei ole lopullinen ratkaisu, mutta eräänlainen MVP, jonka pohjalta on hyvä rakentaa lisää mikäli tarpeita on. Jos sinulla on aiheesta kysymyksiä tai kehitystarpeita, ota yhteyttä!

Olemme lähteneet Gispolla kehittämään kaavoituksen käyttöön suunnattuja työkaluja QGIS- ja PostGIS-ohjelmistoille. QGIS-ohjelmistoa on jo käytetty mm. yleiskaavan teossa ja näiden kokemusten innoittamina olemme päättäneet kehittää työkaluja kaavoittajalle joustavammaksi ja tehokkaammiksi.

QAAVA-työkalulla QGIS kaavoittajan työvälineeksi

Kehitämme kesän ja syksyn 2020 aikana kaavoittajan käyttöön työkaluja, joilla QGISin avulla voidaan tuottaa kaavakohteita ja linkittää ne lähtötietoihin ja päätöstietoihin. QGIS on avoimen lähdekoodin paikkatieto-ohjelmisto, jolla on jo todella monipuoliset mahdollisuudet ja työkalut digitointiin ja visualisointiin. Nyt on jo valmiina asemakaavan tietomalli vietynä PostGISiin sekä visualisointikirjasto asemakaavan osalta QGISille.

Seuraavaksi lähdetään yleiskaavan tietomallin ja visualisointikirjaston puolelle. Sekä QGISiin tuotettaan QAAVA-lisäosa, jonka avulla on tarkoitus tehdä mm. seuraavat asiat:

• Ottaa yhteys ja alustaa PostGIS-tietokantaan asema- tai yleiskaavan tietomalli
• Lisätä kaavan perustiedot (liitetään kaavan ulkorajaan)
• Lisätä kaavakohteita
• Lisätä kaavakohteille ja ulkorajalle kaavamääräyksiä
• Lisätä kohteille päätöstietoja tai lähtötietoja
• Tuoda olemassa olevista paikkatietoaineistoista kohteita osaksi kaavaan
• Helpottaa usean kohteen yhtäaikaista editointia
• Suodattaa usein tarvittuja tietoja

Jatkokehityslistalla on myös CAD-tyyppisten työkalujen kehitys QGISissä sekä QGIS työtila, jossa valmiina tuotuna visualisointikirjastot, työkalut ja tulostepohjat. Näiden kehitykseen tarvitsemme vielä tukea!

Taustalla tietomallipohjaisuus

QAAVA-lisäosa tarvitaan, koska tieto halutaan tuottaa alusta asti rakenteisessa muodossa hyödyntäen Ympäristöministeriön kehittämää tietomallia ja koodilistoja. Näin kaavaa tuotetaan digitaalisesti eheässä ja harmonisoidussa muodossa heti lähteeltä asti. Tietomallipuoli hoidetaan PostGIS-ympäristössä. PostGIS on PostGreSQL-tietokannan spatiaalilisäosa, jolla hoidetaan paikkatietoaineistojen ylläpito, tietomallin taulujen yhteydet ja versiointi. Jos kunnalla ei ole omaa PostGIS-palvelinta, voimme hostata tai asentaa sen kunnan puolesta. 

Avointa yhteiskehitystä

Kaikki käytetyt ohjelmistot sekä tuotetut materiaalit ja koodit ovat avoimesti saatavilla ja lisensoitu avoimen datan ja avoimen lähdekoodin lisensseillä. Materiaalit projektiin löytyvät GitHubista. Mukaan yhteiskehittämiseen pääsee kuka vain ja otamme kaikki kommentit ja kontribuutiot ilolla vastaan. Nyt projektin eri osioita ovat rahoittamassa Paimio, Espoo, Joensuu, Seinäjoki sekä Kuntaliitto. Mukana olevat organisaatiot muodostavat projektin kehittämisryhmän joka testaa ja kommentoi tehtyjä toteutuksia. 

INSPIRE-direktiivi velvoittaa – lokakuussa 2020 deadline

Jos kunnassasi on huoli siitä miten Inspiren tietotuote kaava-aineistoista tehdään, Gispo voi auttaa. Nyt kehitettävän QAAVA-projektin myötä kaavatiedot saadaan tietomalliin, jonka avulla voidaan tuottaa myös EU:n Inspire-direktiivin vaatimassa muodossa kaavasta tietotuote (julkaistu rajapinta). Huomaattehan, että maankäyttö-teeman Inspire-aineistot tulisi olla saatavilla Inspire:n mukaisissa tietomalleissa jo lokakuussa 2020 (MML, 2013). Tämä vaatii kuitenkin vielä rajapintaratkaisun tuottamista kaavasta. Sen voi toteuttaa avoimen lähdekoodin ohjelmistoilla esimerkiksi GeoServerin avulla. Tästä voimme mielellämme tuottaa myös toimivan esimerkin.

Avoimen lähdekoodin QGIS-paikkatieto-ohjelmisto kehittyy hurjaa vauhtia ja kerää taakseen vinon pinon versionumeroita. Tarkoituksenani on nyt avata hieman logiikkaa eri QGIS-versioiden takana: mitä ohjelmiston versionumerot pyrkivät kertomaan käyttäjälleen? Kaikki tieto, minkä jaan tässä artikkelissa, pohjautuu täältä löytyvään QGISin tiekarttaan.

Ohjelmiston versionumerointi ja QGISin kehityksen vaiheet

Tutustutaan ensimmäiseksi ohjelmiston versionumeroinnin taustoihin sekä QGIS-ohjelmiston kehitysprosesseihin. Ohjelmiston versionumero (esimerkiksi 3.12.1) rakentuu yleensä 2-3 eri luvusta, jotka kertovat ohjelmiston kehitysvaiheesta. Lukujen sisään kätkeytyy erilaisia prosesseja ja logiikoita, joiden kautta siirrytään versionumerosta toiseen.

Major-, Minor- ja Patch-julkaisut

Versionumeron ensimmäinen luku viittaa Major-versioon, johon ohjelmiston päärakenne pohjautuu. Jos ohjelmisto siirtyy Major-versiosta toiseen, ohjelmistoon tehty kehitys on laaja-alaista eikä ohjelmisto ole enää yhteensopiva aikaisemman Major-version ominaisuuksien kanssa (esimerkiksi lisäosat). Esimerkiksi QGISin kehittyessä 2.18-versiosta 3.0-versioon, monet QGIS 2.18-versiolle tehdyt lisäosat eivät enää toimineet QGIS 3.0-versiossa. Myös QGISin graafinen ilme muuttui merkittävästi uudessa Major-versiossa.

Major-luvusta seuraava on Minor-versiota ilmaiseva luku. Minor-julkaisussa ohjelmisto on edelleen joko yksi tai useampi uusi ominaisuus, mutta ohjelmisto pysyy edelleen yhteensopivana aikaisempien Minor-versioiden kanssa. Yleensä ennen uutta Major-julkaisua seuraa liuta pienempiä Minor-julkaisuja (esimerkiksi 3.1, 3.2, 3.3, 3.4…).

Minor-julkaisuakin pienempiskaalaisempi on Patch-julkaisu. Tässä versiossa kehittäjät ovat yleensä korjanneet raportoituja bugeja tai lisänneet ohjelmistoon yhden uuden ominaisuuden. QGISin kohdalla Patch-julkaisuja nimitetään myös vaihejulkaisuiksi eli Point releaseiksi (PR). Eri ohjelmistojen versionumerointi voi edetä Patch-julkaisuakin pidemmälle, mutta pääperiaate on yleensä sama: mitä kauempana numero on Major-luvusta, sitä pienempialaisempaa tehty ohjelmistokehitys on.

QGISin kehitys ja ohjelmistokehitys noin yleisestikin (poislukien pienet nyanssit) noudattavat tiettyjä prosesseja versionumerosta toiseen siirryttäessä. Kehitysprosessi voidaan karkeasti jaotella kolmeen eri vaiheeseen: varsinaiseen kehitysvaiheeseen (development phase), jäädytysvaiheeseen (freeze phase) sekä julkaisuvaiheeseen (release phase). Sekä QGISin viimeisin versio että pitkäaikaisversio (LTR) noudattavat näitä kehitysvaiheita omissa kehityslinjoissaan.

Kehitysvaihe (development phase)

Kehitysvaiheessa QGISiin lisätään uusia toiminnallisuuksia tai olemassaolevia toimintoja kehitetään eteenpäin. Kehitysvaihe jakautuu yleensä useampiin pienempiin vaiheisiin, joissa keskitytään vain tietyn toiminnallisuuden kehitykseen. Jokaisesta pienemmästä kehitysvaiheesta ja uuden toiminnallisuuden lisäämisestä julkaistaan aina oma vaihejulkaisu (PR) tai Patch-versio. Esimerkiksi QGIS-versiot 3.12.1 ja 3.12.2 ovat Patch-julkaisuja/vaihejulkaisuja, joissa ohjelmistoon on lisätty jokin pienempi toiminnallisuus (tai vaihtoehtoisesti korjattu bugeja tai tehty molempia). Kehitysvaiheessa luodaan liuta erilaisia Patch-julkaisuja.

Jäädytysvaihe (freeze phase)

Jäädytysvaiheessa QGISiin ei lisätä enää uusia toiminnallisuuksia, vaan aikaisemmassa kehitysvaiheessa lisättyjä ominaisuuksia pyritään stabiloimaan. Stabiloinnilla tarkoitetaan sitä, että uudet ominaisuudet pyritään saada niin luotettaviksi kuin mahdollista. Käytännössä siis eliminoidaan käytössä havaittuja bugeja, ongelmia ja muita uuden ominaisuuden suoritusta heikentäviä tekijöitä. Jäädytysvaiheessa QGISistä ei yleensä julkaista kuin 1-2 Patch-versiota.

Jotta QGIS pysyisi mahdollisimman stabiilina ja luotettavana, tulisi käyttäjien aina laatia bugiraportti kohtaamistaan ongelmista. Ilman raportointia kehittäjät eivät välttämättä edes tiedä ongelman olemassaolosta, eikä bugi näin ollen katoa! Kerron lisää QGISin bugiraportoinnista artikkelin lopussa.

Julkaisuvaihe (release phase)

Julkaisuvaihe on QGIS-ohjelmistokehityksen viimeinen vaihe. Tässä vaiheessa QGISiin on lisätty uusia ominaisuuksia ja nämä ominaisuudet on stabiloitu niin hyvin kuin mahdollista. QGIS ja sen uudet stabiloidut toiminnallisuudet siirtyvät paketointiin ja lopuksi se julkaistaan myös loppukäyttäjän saataville. Tässä kehityksen loppuvaiheessa QGISistä julkaistaan Minor-versio, joka sisältää kaikki kehitysvaiheessa lisätyt ja jäädytysvaiheessa stabiloidut uudet ominaisuudet. Kun julkaisu on tehty, koko prosessi alkaa alusta ensimmäisestä vaiheesta ja versionumerointi etenee 0 Patch-versiosta eteenpäin. Esimerkiksi QGIS-versio 3.10.0 on kehitysprosessin lopputuote, josta alkaa jälleen uusi kehityssykli.

QGISin kehitys perustuu aikajänteisiin

Jokaiselle edellä mainitulle vaiheelle on määritelty tietty aikajänne, minkä aikana vaihe tulee aloittaa ja saatta loppuun. Tällä vältetään “lipsumista”, kun jokaisesta vaiheesta on olemassa deadline. QGISin kehitys on suunniteltu niin, että joka neljäs kuukausi julkaistaan uusi QGISin Minor-versio. Kehitysvaiheeseen pyritään varaamaan kolme kuukautta (3 x 4 viikkoa) ja jäädytysvaiheeseen yksi kuukausi (1 x 4 viikkoa). Julkaisuvaihe pyritään tekemään samanaikaisesti seuraavan kehitysvaiheen alun kanssa.

Bugiraportin laatiminen

Kun QGIS siirtyy jäädytysvaiheeseen, on aika laittaa kokeiluhattu päähän ja lähteä oikein urakalla testaamaan QGISin uusimpia ominaisuuksia! Mistä sitten uusimman ominaisuudet oikein löytää? Eri QGIS-versioiden muutoksista pidetään kirjaa muutoslokissa (changelog). Tätä kautta voi napsia testiin juuri sinua kiinnostavia uusia ominaisuuksia.

Kuten aiemmin mainitsin, QGISin jäädytysvaiheessa kehittäjät pyrkivät stabiloimaan uusimman version ja sen uudet ominaisuudet. Bugien kokonaisvaltainen korjaus on kuitenkin haastavaa ilman käyttäjäyhteisön tukea, minkä vuoksi bugiraporttien laatiminen on äärimmäisen tärkeää. QGISin kohdalla raportointi on pyritty tekemään mahdollisimman helpoksi, sillä raportti laaditaan valmiille bugiraporttipohjalle QGISin GitHubissa. Raporttipohja sisältää kaiken tiedon siitä, mitä sinun tulee kertoa kehittäjälle, jotta bugi saadaan nitistettyä.

Jos bugiraportin kirjoittaminen englanniksi tai GitHubin käyttö ei jostain syystä luonnistu, QGISin bugilöydöistä voit kertoa myös esimerkiksi Gispon tukipalvelussa! Tukipalvelussa haluamme tietää etenkin käyttämäsi QGIS-version, käyttämäsi aineiston sekä mahdollisimman tarkan ohjeistuksen miten saisimme replikoitua bugin vielä itse (= eli kerro mitä teit, että sait bugin näkyviin QGISissä).

Bugiraportteja saa ja pitääkin kirjoittaa aina, kun löydät ohjelmistosta jotain hämärää – jäädytysvaihe on tavallaan vain tehovaihe, jossa kehittäjät keskittyvät uusien ominaisuuksien bugikorjauksiin ja stabilointiin. Avoimen lähdekoodin QGIS-ohjelmiston kunnossapito ei ole vain kehittäjien työtä, vaan vastuu kuuluu myös käyttäjille!

Lähteet:

https://www.qgis.org/en/site/getinvolved/development/roadmap.html#

https://www.qgis.org/en/site/forusers/visualchangelogs.html

Viimeistään taloudellisesti vaikeina aikoina organisaatioiden on etsittävä kustannussäästöjä toimintojen varmistamiseksi. Jos kustannuksia pitäisi nipistää pois myös paikkatietoprosessien saralla, mitä organisaatiot voisivat karsia ja tehostaa? Gispon asiakkaat ja yhteistyökumppanit kysyvät usein, minkälaisia kustannussäästöjä avoimen lähdekoodin paikkatietoratkaisut synnyttävät pitkällä tähtäimellä ja mistä säästöt syntyvät suhteessa eri suljetun lähdekoodin (eng. proprietory) paikkatieto-ohjelmistovalintoihin. Usein keskustelu kohdistuu seuraaviin kolmeen pääsääntöön, jotka pätevät niin julkisen kuin yksityisen sektorin piirissä:   

1. Katse ohjelmistovalintoihin: lisenssikustannukset kuriin
2. Tuottavuuden kasvattaminen avoimuudella: avoimilla ohjelmistolisensseillä ja lähdekoodilla voidaan räätälöidä organisaatiokohtaisia ratkaisuja tehokkaasti
3. Palvelutoimittajien kilpailuttaminen: yhdestä palvelutoimittajasta useampaan

Nämä kolme sääntöä auttavat näkemään kokonaisuuden yleisellä tasolla. Organisaatioiden tilanteet vaihtelevat tosin suuresti, jolloin Gispossa selvitämme tarkemmin, mitä eri ohjelmistovalinnat tarkoittavat kustannuksina. 

Paikkatietoarkkitehtuureja joka lähtöön

Syventyessämme organisaatiokohtaisiin analyyseihin, käymme läpi kysymyksiä, kuten:

• Mitä erilaisia paikkatiedon käyttötapauksia organisaatiossa on?
• Minkä suuruinen organisaation paikkatietotiimi on?

Näin voisi syntyä esimerkiksi seuraavanlainen arkkitehtuurikuvaus:

Tässä kyseessä on pelkästään avoimen lähdekoodin paikkatieto-ohjelmistoja hyödyntävästä hypoteettisestä organisaatiosta. Asiakkaillamme on kylläkin tilanteita, joissa paikkatietoinfrastruktuuri on hybridi eli käytössä on niin avoimen kuin suljetun lähdekoodin ohjelmistoja, jolloin onkin selvitettävä, mikä ohjelmistojen kombinaatio on sopivin.

Miten kustannussäästöt sitten syntyvät?

Palataan taas takaisin ohjenuoriin ja alkuperäiseen kysymykseen, mistä kustannussäästöjä saadaan? Ensimmäiseksi, jättämällä pois suljetun lähdekoodin paikkatieto-ohjelmistoihin liittyvät lisenssikustannukset säästetään merkittävästi. 

Sitten tuottavuushyödyt toiminnanvapaudesta: myös organisaation paikkatietoratkaisujen tuottavuus kasvaa, koska avoimen lähdekoodin ohjelmistot mahdollistavat toiminnanvapauden ja siten omien paikkatietoratkaisujen räätälöimiseen ja innovoimisen organisaatiokohtaisissa toimintaympäristöissä. Innovoimisen lisäksi ei voida painottaa tarpeeksi sitä, kuinka suuria kustannushyötyjä organisaatiot saavat siitä, että avoimen lähdekoodin ohjelmistoja voi helposti kytkeä olemassa oleviin IT-arkkitehtuureihin. Usein tämä on jopa mahdotonta suljetun lähdekoodin paikkatietoratkaisujen kanssa, mikä tarkoittaa sitä, että ohjelmistojen kytkemisen sijaan, on hankittava kokonaisia ohjelmistoperheitä, jotta paikkatietoratkaisuista saadaan kokonaisvaltaisia. Tässä tärkeitä seikkoja ovat muun muassa avoimien rajapintastandardien eli Open Geospatial Consortiumin (OGC) asettamien standardien noudattaminen ja myös se, että avoimen lähdekoodin ohjelmistojen usein sallivat lisenssit mahdollistavat organisaatiokohtaisten ratkaisujen näppärän räätälöimisen modernin ohjelmistokehityksen periaatteita noudattaen.

Tuottavuutta kasvattaa myös mahdollisuus skaalata paikkatieto-ohjelmistojen käyttöä: QGISin voi asentaa vaikkapa kaikille organisaation tietokoneille ja paikkatietotietokantoja tai -palvelimien määrää ja kapasiteettia voi lisätä tarpeen mukaan ilman yllätyksellisiä lisäkustannuksia käyttömäärien kasvaessa. 

Lopuksi, avoimen lähdekoodin palveluntarjoajat toimivat vapailla, ei-rajoitetuilla markkinoilla, tarkoittaen että lisäarvopalveluiden, kuten konsultoinnin, koulutuksen ja tukipalveluiden, tarjoamista tai niiden hintaa ei voida rajoittaa yhden palveluntarjoajan tai ohjelmistotalon  puolesta. Tämä itsessään kasvattaa kilpailua ja siten tasapainottaa palveluiden hintoja. kilpailuttamisen mahdollisuuksia    tarjoamista  suljetun lähdekoodin paikkatieto-ohjelmistoihin liittyviä lisäarvopalveluita, kuten konsultointi-, koulutus- ja tukipalveluita, voi hyvin harvoin hankkia useammalta palveluntuottajalta, jolloin tilaajan on ostettava palveluita tai ohjelmistokokonaisuuksia vain yhdeltä toimittajalta ilman mahdollisuutta kilpailutukseen.

Kustannusten kasvaminen pitkällä tähtäimellä

Jos halutaan analysoida avoimen ja suljetun lähdekoodin oletettavia kustannuksia yllä olevan hypoteettisen paikkatietoarkkitehtuurin  näkökulmasta, eriytyisivät kustannusrakenteet todennäköisesti kasvavia kustannuksia analysoivan seuraavan kaavion mukaisesti.    

Graafissa on esitetty arvioidut kulut suomalaiselle keskiverto paikkatiedon hyödyntäjäorganisaatiolle, joka tarvitsisi käyttöönsä paikkatietokannan, GIS-sovelluspalvelimen, GIS-työasemaohjelmistoja ja selainpohjaisen paikkatietojen visualisointiratkaisun. Kaaviossa on kuvattu kumulatiiviset kustannukset avoimen lähdekoodin ja suljetun lähdekoodin ohjelmisto- ja IT-infrastruktuurivalinnoille paikkatiedon toimialalla. Näin avoimen ja suljen lähdekoodin käyrät kuvaavat, miten kustannuksien yhteenlaskettu summa viidennen vuoden päätteeksi eroaa kummankin ohjelmistostrategien suhteen. 

Käyrien väliin jäävä osio kuvaa vuosi vuodelta kasvavia kustannussäästöjä avoimen lähdekoodin ohjelmistovalintojen hyväksi. Tässä mielessä organisaatioiden paikkatietotiimien ja hankintaosaston on pystyttävä katsomaan pitkän tähtäimen kustannusrakenteita, ja etsiä kustannussäästöjä ja tuottavuushyötyjä useamman vuoden aikasäteellä. 

Kustannukset eri vaiheissa ja eri palveluista 

Tehdessä strategisia päätöksiä ohjelmisto- ja IT-infrastruktuurivalinnoissa, voidaan jakaa kustannukset eri kategorioihin, kuten ohjelmistojen käyttöönotosta, kouluttamisesta, tukipalvelusta, ohjelmitsojen ylläpidosta ja lisensseistä syntyvistä kustannuksista. Avoimen lähdekoodin paikkatieto-ohjelmistoja hyödynnettäessä esimerkiksi seuraavanlainen kustannusrakenne viiden vuoden aikasäteellä olisi todennäköinen. 

Taulukosta huomataan, kuinka ensimmäiseen vuoteen kasautuu suurimmat investoinnit kuten minkä tahansa IT-hankinnan tapaan. Ensimmäisen vuoden jälkeen kustannusrakenne tasaantuu eikä ohjelmistojen lisensseistä synny kustannuksia.

Arvioi nyt omaa organisaatiotasi

Nyt voidaan taas palata kolmeen kustannussäästön periaatteisiin ja arvioida oman organisaation paikkatietoinfraa: 

1. Lisenssi- ja ylläpitokustannukset:
   1. Arvioi organisaation käyttämiä ohjelmistoja, ja jätä pois korvattavissa olevat lisenssi- ja ylläpitokustannuksia aiheuttavat ohjelmistot.
2. Tuottavuus:
   1. Panosta tuottavuuden kasvattamiseen työvoiman osaamisen kerryttämisellä. 
   2. Käytä ohjelmistoja, jotka mahdollistavat ohjelmistojen ja ohjelmointikirjastojen räätälöimisen organisaation omiin tarkoituksiin kustannustehokkaasti ja ilman ajautumatta ongelmiin muun muassa suljetun lähdekoodin ohjelmistoihin liittyvien lisenssien kanssa. 
3. Kilpailutus:
   1. Kilpailuta ostopalvelusi ja ohjelmistosi usealla palveluntarjoajilla ja ohjelmistotoimittajilla. 
   2. Älä ajaudu yhden toimittajan lock-in tilanteeseen, jossa et voi kilpailuttaa käyttämiäsi ohjelmistoja ja palveluita.

Mikäli sinua kiinnostaisi tutkia organisaatiosi paikkatietostrategiaa ohjelmistovalintojen ja kustannusrakenteiden suhteen, me Gispossa autamme myös näiden strategisten päätösten valmistelussa. Voimme aloittaa lyhyellä palaverilla organisaationne nykytilan kartoittamiseksi ja kustannussäästömahdollisuuksien tunnistamiseksi. 

Jos haluat vielä itse tutkia suomalaisen julkishallinnon tekemiä paikkatieto-ohjelmistoihin liittyviä ICT- ja muita hankintoja, voit tutustua valtion ja kuntien hankintoihin valtiovarainministeriön ja Hanselin ylläpitämästä tietopalvelusta: https://tutkihankintoja.fi/

Meillä on ollut tänä keväänä aivan mielettömän kiva projekti käynnissä! Ollaan opittu hirveästi uutta, saatu tehdä tiiminä hommia juuri omien vahvuuksien kautta ja tehty karttoja, mikä parasta!

Uudenmaan liitto, Varsinais-Suomen liitto ja Turun kaupunki pyysivät toteutuksia Pohjoisen kasvuvyöhykkeen alueen esittelystä karttapohjaisesti ja wau-efekteillä ryyditettynä. Gispon Topi ja Joona pistivät kehityshanskat käteen ja meillä on nyt suunniteltu toinen toistaan upeampia visualisointeja Pohjoisen kasvuvyöhykkeen alueen liikkumisesta, työpaikoista ja vapaa-ajasta. 

Ensimmäisenä toteutuksena julkaistiin Itämeren aamu- ja iltapäiväruuhkia esittelevä laivavisualisointi, jossa hyödynnetään laivojen AIS-signaalia. Se on niin hypnoottista, että tätä voisi tuijottaa vaikka koko päivän. Data kerätään edellisen 24 tunnin ajalta ja eri laivatyypit Suomen aluevesillä seilaavat kartalla yötäpäivää. Aineistot ovat Traffic Management Finlandin avointa dataa. Mukana visualisoinnissa esitelty myös rahtimääriä kasvuvyöhykkeen satamissa.

Kaikki visualisoinnit julkaistaan Pohjoisen kasvuvyöhykkeen tietopalvelussa, joka on toteutettu avoimen lähdekoodin ohjelmistolla nimeltä Kepler.gl. Keplerin kehityssivustolla voi kokeilla myös itse testidatan kanssa miten Kepler toimii. 

Meillekin Kepler oli ihan uusi tuttavuus ja se osoittautui erittäin monipuoliseksi paikkatiedon visualisointityökaluksi. Sen avulla voi renderöidä esimerkiksi isosta datamassasta kaarivisualisointeja ja Topin rakastamia hunajakennoja. Kepler hyödyntää MapBoxin taustakarttoja ja niihin projektissa tehtiin myös omia virityksiä visualisointien parantamiseksi. 

Ainoa ongelma oli, että Kepleristä puuttui kielituki. Noh, Joona vähän käpisteli konepellin alla ja hauskasti suomenkieli oli hetken Keplerissä englannin lisäksi ainoa toinen kielimahdollisuus! Nopeasti sinne on tullut lisäksi myös portugali, espanja ja katalaani, eli muutkin ovat alkaneet hyödyntää kielitukea. Muutenkin tehtiin pieniä aineistoihin liittyviä vimpaimia, joilla saadaan paremmin esiteltyä aineistojen visualisointeja. Niistä myöhemmin lisää.

Projektissa oli mahtavaa päästä työskentelemään hyvinkin aktiivisessa kehityksessä olevan Keplerin kanssa. Oli erityisen hienoa huomata, että kaikki löytämämme kehityskohteet otettiin lämmöllä vastaan ja osa niistä ehdittiin toteuttamaan projektin aikana. Myös toteuttamani kielisyystuki lähti leviämään kulovalkean lailla. Kepler on toteutettu paitsi visuaalisesti näyttäväksi ja käyttöliittymältään monipuoliseksi, myös helposti laajennettavaksi ja käyttöön otettavaksi omassa sovelluksessa. Kattavan dokumentaation ja hyvien esimerkkien avulla Keplerin räätälöinti projektin tarpeisiin sujui suoraviivaisesti ja nopeasti.

Joona Laine, Gispo

Voisin melkein sanoa, että tämän tyyppinen projekti on itselleni unelmaprojekti. Päästään rakentamaan jotain uutta ilman teknologiarajoitteita ja käyttämään omaa luovuutta aineistojen informaatiomuotoilussa. Avoimia aineistoja ja asiakkaan hankkimia aineistoja yhdistelemällä voidaan analyysien ja visualisointien kautta löytää jotain kokonaan uutta ja informatiivista.

Topi Tjukanov, Gispo

Visualisointeja on tarkoitus julkaista pikkuhiljaa, joten herkkua on luvassa infografiikan ja giffereiden janoajille jatkossakin. Seuraa siis esim. Kasvuvyöhykkeen Twitter-tiliä, niin saat uusimmat visualisoinnit heti tietoosi. 

Projektin tavoitteena oli Pohjoisen kasvuvyöhykkeen ihmis- ja liikennevirtojen visualisoiminen kartalla tuoreella ja näyttävällä tavalla. Tehtävä oli haastava, mutta projektitiimi onnistui teknisessä toteutuksessa ja etenkin informaatiomuotoilussa yli odotusten!

Antti Vasanen, tietopalvelupäällikkö, Varsinais-Suomen liitto

On ollut innostavaa, miten hienosti projektitiimi on pystynyt tekemään näkyväksi kiinnostavilla datan visualisoinneilla koko Suomen pärjäämiselle oleellisen vyöhykkeen ominaisuuksia. Erityisesti koronan aikanakin on tärkeää, että keskeiset satamamme ovat toiminnassa ja vastaavat koko Suomen huoltovarmuudesta. Pohjoisen kasvuvyöhykkeen yhteistyöverkosto perustuu kumppanuuksille yhteisten haasteiden ratkaisemiseksi. Sellaiselle on erityisen suuri tarve juuri nyt.

Marjo Uotila, yhteysjohtaja, Turun kaupunki