Aineiston visualisointi on karttojen tekemisessä yksi tärkeimmistä – ja aikaavievimmistä – vaiheista. Karttojen eri osien visualisointiin ja niiden yhteensovittamiseen voi käyttää loputtomasti aikaa ja silti saattaa tuntua, että jotain pitäisi vielä muuttaa tai tehdä.

Jos olet tehnyt QGISissä sopivan visualisoinnin yhdelle aineistolle, voit tallentaa tyylin tyylitiedostona (.qml) ja käyttää samaa visualisointia muille tasoille. Tyylitiedostoon voit värien ja tyylien lisäksi tallentaa esimerkiksi nimiöinnin tyylejä, relaatioita tai diagrammeja. Näin voidaan helpottaa päivitettyjen versioiden luominen samasta aineistoista tai uusien aineistojen visualisoiminen samaan tyyliin!

Tyylitiedoston tallentaminen ja lataaminen

Tyylitiedoston saa tallennettua seuraavasti: klikkaa tasolistasta haluttua tasoa hiiren oikealla painikkeella ja valitse Tason ominaisuudet. Avaa Kuvaustekniikka-välilehti ja sen vasemmasta alareunasta Tyyli-napin takaa klikkaa Tallenna tyyli.

Avautuvassa valikossa voit valita, mitkä kaikki ominaisuudet haluat tallentaa aineiston tyylittelystä. Samasta paikasta onnistuu myös valmiiden tyylitiedostojen lataaminen käyttöön (“Lataa tyyli” -valinnan takaa).

Muiden tekemien tyylien lataaminen ja käyttö

Tyylien suunnittelussa ja määrittämisessä vain taivas tuntuu olevan rajana. Tässä pistetyylissä tähdiksi muotoillut pisteet vaihtavat väriä aina kun kartta liikutat karttaa jotenkin. Samalla karttaan generoituu jokaista pistettä kohti kolme kuusen kuvaa, ja nämä vaihtavat paikkaa, kun liikut kartalla.

Näin villi ja randomisoitu visualisointi ei ehkä sytytä kaikkien joulumieltä, mutta onneksi on vaihtoehtoja. QGIS Hubiin on tallennettu erilaisia valmiita tyylejä, joita voi hyödyntää omissa aineistoissa vapaasti. Tyylien lisäksi sieltä löytyy karttoja, malleja ja skriptejä, joita käyttäjät ovat ladanneet muiden vapaaseen käyttöön. Täältä ladatut tyylit voivat olla myös XML-tiedostona, joiden lisääminen tyylivaihtoehdoksi tehdään QGISissa vähän eri tavalla.

XML-tiedostosta tyylin tuominen aloitetaan lataamalla QGIS Hubista esimerkiksi joulupaita-aiheinen tyylitiedosto: paina sivun ylänurkasta “Download” ja tallenna tyylitiedosto johonkin mielekkääseen sijaintiin omalla tietokoneella. Tiedosto ladataan pakattuna kansiona (.zip). Lataamisen jälkeen avaa kansio, johon latasit sen, klikkaa hiiren oikealla ja valitse “Pura kaikki”.

Kun tyylitiedosto on ladattu ja sen kansio purettu, avaa QGISissä Asetukset → Tyylien hallinta. Täällä voit tehdä erilaisia oletustyylejä ja tuoda tai viedä erilaisia tyylitiedostoja käyttöösi.

Tyylien hallinnassa avaa vasemmalta Tuo/Vie painikkeesta ja valitse Tuo tyylejä. Etsi äsken purkamasi Christmas_jumper.xml -tyylikansio omista tiedostoistasi ja tuo tyyli valintoihin.

Nyt voit avata oman polygonitasosi kuvaustekniikan ja valita valmiista tyylitiedostoista juuri tuomasi uuden tyylin. Sitten voidaankin ihailla jouluista lopputulosta, kas näin:

Tyylejä voi jakaa myös Geopackagen ja QGIS-projektien kautta, kuten tässä nimiöinnin kautta tehdyssä lumihiutalevisualisoinnissa. Tehdään siis tästä jouluvisualisoinnista vielä hieman talvisempi ja toivotaan samalla koko Pohjois-Eurooppaan, tai ainakin tänne Etelä-Suomeen, lunta maahan:

ATK-laitteita käyttävät ihmiset ovat varmasti törmänneet tilanteeseen, jossa jokin ei toimi: ohjelmiston painike ei reagoi, sivu jäätyy tai sovellus kaataa tehtävää suorittaessaan koko laitteen. Perinteiset ratkaisuvaihtehdot ovat tietenkin “käynnistä laite/ohjelma uudelleen”, “paina Ctrl + Alt ja Delete” sekä “hae lisää kahvia ja hengitä syvään”. Harvemmin näillä konsteilla kuitenkaan korjataan ongelman juurisyytä.

Jos ohjelmistossa olevaa ongelmaa ei raportoida, siitä ei tiedetä. Silloin sitä ei voi korjata. Näin samat virheet ilmenevät yhä uudelleen ja päästään erään asiakkaan kuvaamaan tilanteeseen: “4-5 työpäivää mennyt hukkaan tämän takia. Kaikenlaisia virheilmoituksia siellä vilisee.”

Hyvän (tai edes keskikohtalaisen) bugiraportin kirjoittaminen ja lähettäminen mahdollistaa sen, että ongelma korjataan ja kaikkien ohjelmiston käyttäjien hermot säästyvät. Tässä artikkelissa käymme läpi, miksi bugiraportointi on tärkeää ja miten kirjoitetaan raportti, josta ohjelmistojen kehittäjät hyötyvät.

Miksi bugiraportointi on tärkeää?

Kehittäjät eivät näe kaikkea. Vaikka sovellusta testataan paljon ennen julkaisua, todelliset käyttötilanteet ja -ympäristöt paljastavat usein uusia ongelmia. Käyttäjillä on erilaisia laitteita, asetuksia, aineistoja ja tapoja käyttää ohjelmaa. Jokaista eri tekijöiden yhdistelmää ei yksinkertaisesti voi ottaa kehitystyössä huomioon.

Toisekseen bugia, josta kehittäjät eivät tiedä, he eivät voi korjata. Kun ongelma raportoidaan selkeästi, se pääsee kehittäjille tutkittavaksi ja korjattavaksi. Ilman raporttia kehittäjät eivät edes tiedä, että ongelma on olemassa.

Kun ongelmat raportoidaan, käyttäjät saavat paremman ja vakaamman ohjelmiston, joka tekee vaaditut tehtävät. Kehittäjät taas saavat tietoa, mitä he voisivat tehdä paremmin, miten ohjelmistoa käytetään ja miten se toimii. Kaikki voittavat.

Miten hyvä bugiraportti kirjoitetaan?

Hyvä raportti vastaa mahdollisimman hyvin kolmeen kysymykseen: 

1. Mitä tapahtui?
2. Missä?
3. Miten sen voi toistaa? 

Käytännössä bugiraportti alkaa jo otsikosta. “Sovellus ei toimi” on klassinen otsikkovaihtoehto, mutta “QGIS kaatuu kun luon uuden kentän Field Calculatorilla” on huomattavasti kuvaavampi valinta.

Itse leipätekstiin kuvaile kohtaamasi ongelma. Kerro, mitä yritit tehdä, mitä olisi pitänyt tapahtua ja mitä tapahtui. Kerro, toistuuko virhe joka kerta vai satunnaisesti. Hyvä tapa on kirjata ohje ongelman toistamiseksi vaiheittain, esimerkiksi:

1. Avaa QGIS.
2. Avaa vektoritaso.
3. Avaa tason attribuuttitaulukko
4. Avaa Field Calculator.
5. Valitse “Luo uusi kenttä”.
6. QGIS kaatuu.

Yritä kuvata ongelma mahdollisimman yksinkertaisin vaihein ja yksinkertaisessa ympäristössä. Jos saat ongelman toistettua esimerkiksi yksinkertaisella QGIS-projektilla ja yksinkertaisella aineistolla, ei ole syytä lähettää QGIS-projektia, jossa on kymmeniä tasoja ja satoja megatavuja aineistoja.

Jos ohjelmisto tallentaa virhelokia, niin se kannattaa myös liittää bugiraporttiin mukaan. QGISissä virhelokin saa auki ohjelman oikeasta alanurkasta löytyvästä puhekuplasta klikkaamalla. Vaikka sieltä tuleva tekstimassa voi näyttää useimpien silmiin käsittämättömälle, kehittäjälle se kertoo kuitenkin hyvinkin tarkasti, mikä aiheutti ongelman.

Jos epäilet, että ongelma johtuu käyttämästäsi aineistosta, voit myös lähettää sen tai sen osan aineistosta, joka aiheuttaa ongelman.

Lopuksi lisää mukaan tarvittavat tekniset tiedot: yleensä käytetty ohjelmiston versio ja tietokoneesi tai muun käyttämäsi laitteen käyttöjärjestelmä riittävät. Käytännössä siis vaikkapa näin: “käytössä on QGIS 3.40.7. ja Windows 11”. 

Halutessasi voit myös ottaa kuvan tai videon ongelmasta liitteeksi. Windows-käyttäjät voivat ottaa ruutukaappauksen painamalla Print screen -näppäintä tai näppäinyhdistelmää Windows-näppäin + Shift + S. Videon kuvaaminen vaatii puolestaan erillisen ohjelman asentamista ja käyttöä. Asiasta kiinnostuneille vinkattakoon ScreenToGif.

Lopuksi

Bugiraportointi ei ole vain kehittäjiä varten, vaan myös raportoijan sekä muiden ohjelmiston käyttäjien eduksi. Bugiraportit auttavat parantamaan ohjelmistoja. Hyvin kirjoitettu raportti vaatii hieman viitseliäisyyttä, mutta säästää jatkossa aikaa, vaivaa ja hermoja. Muotoseikoista ja bugiraportin oikeaoppisuudesta ei kuitenkaan kannata tehdä kynnyskysymystä itselleen – tärkeintä on, että ongelmasta menee tieto eteenpäin. Lisätietoja voidaan kysyä tarvittaessa.

QGISiin liittyvät bugit voi raportoida QGISin GitHub-sivun Issues-osioon. Tämä vaatii kuitenkin GitHub-tunnusten luomisen. Gispon tukipalvelun käyttäjät voivat raportoida FOSS4G-ohjelmistojen bugit ja myös QGISin suomenkielisen käännöksen virheet meille osoitteeseen tuki@gispo.fi. Me voimme korjata ohjelmistoissa esiintyviä ongelmia itse tai kirjata bugiraportit eteenpäin.

Olemme olleet keväästä lähtien mukana EIP (European Innovation Partnership) hankkeessa, jossa suunnitellaan sovellusta maan kasvukunnon seurantaan. Hanke on EU:n osarahoittama. Teemme hanketta yhdessä Seinäjoen Ammattikorkeakoulun, ammattiopisto Livian sekä LUKE:n kanssa. Hankkeessa kehitetään Peltomappi-sovellus, joka on helppokäyttöinen paikkatietopohjainen karttasovellus maatilojen peltolohkojen maan terveyden arviointiin ja seurantaan. 

Peltomappi-sovelluksen sovellusalustaksi valittiin avoimen lähdekoodin mobiilisovellus Mergin Maps. Peltomapin on tarkoitus olla mahdollisimman yksinkertainen käyttää ja sillä tietojen synkronointi pelloilla onnistuu vaivatta. Sovelluksen lisäksi käytössä on monipuolinen web-käyttöliittymä ja yhteys QGISiin. Uskomme että kehitystyön tuloksena lopullisesta sovelluksesta saadaan todella monipuolinen ja hyödyllinen työkalu maanviljelijöille peltomaan terveyden arviointiin ja seurantaan. 

Yksinkertaisen sovelluksen avulla maanviljelijä voi kerätä pistemäistä ja aluemaista tietoa oman lohkon maaperän kunnosta, merkitä esimerkiksi viljavuusnäytteiden ottopaikat ja salaojien laskuputket tai suunnitella ja tehdä erilaisia koealoja omalle peltolohkolle. Eri vuosien tiedot löytyvät helposti kaikki kartalta ja tuloksia on mahdollista seurata ja vertailla lyhyellä ja pitkällä aikavälillä. Sovellus antaa viljelijälle kokonaisvaltaisen kuvan peltojen kasvukunnosta, muutoksen suunnasta ja parannustoimien vaikutuksista. 

Käyttäjä voi avata oman peltomappiprojektin myös QGISissä, jossa aineistoa voidaan jatkojalostaa ja analysoida omiin tarpeisiin. QGISin puolella omaan projektiin voi lisätä mobiilisovelluksessa näytettäväksi esimerkiksi salaojakartat, joiden avulla peltolohkolla näkee tarkemmin missä salaojat kulkevat.

Sovelluksessa hyödynnetään avoimia kartta-aineistoja, kuten SYKEn, Maanmittauslaitoksen ja ESA:n Sentinel 2 aineistoa. Peltomappi kokonaisuus koostuu kahdesta eri osasta: mobiilisovelluksesta, jota voi käyttää kentällä havaintojen tekemiseen ja muokkaamiseen sekä selainpohjaisesta karttapalvelusta. Puhelimella voi tallentaa työn ohessa pistemäisiä paikkatietoja peltolohkoille, esimerkiksi penetrometrin tai MARA-kuopan tulokset. Kartalle voi tallentaa myös esimerkiksi erilaisia peltomaahavaintoja, kaivojen ja kivien sijainteja sekä lisätä kohteille valokuvia ja muistiinpanoja. Aluemaisiin aineistoihin voi tallentaa esimerkiksi erilaisia lannoituskokeita pellolle, veteliä kohtia tai rikkakasvien alueita, joille pitää tehdä toimenpiteitä myöhemmin. Myös alueille voi tallentaa kuvia sekä muistiinpanoja.

Peltomappi-sovellusta voidaan hyödyntää niin viljelijöiden omana työkaluna maan terveyttä edistävän viljelyn suunnittelussa kuin myös maatalousalan neuvonnassa, opetuksessa ja nuorten viljelijöiden innostajana.

Voit seurata hanketta sen verkkosivuilta: https://peltomappi.livia.fi/

---

Koekalastus on keskeinen menetelmä kalakantojen tilan arvioinnissa sekä vesien ekologisen tilan seurannassa. Siinä käytetään standardoituja kalastusmenetelmiä, kuten monikokoisilla verkoilla tehtävää verkkokoekalastusta ja virtavesissä sovellettavaa sähkökoekalastusta. Koekalastuksen tavoitteena on kerätä vertailukelpoista tietoa kalalajien runsaudesta, lajisuhteista, biomassasta ja ikärakenteesta.

Luonnonvarakeskus (LUKE) ylläpitää kansallista koekalastusrekisteriä (Kokare), joka sisältää havaintoaineistoja järvistä, virtavesistä ja rannikkoalueilta eri puolilta Suomea 1990-luvun lopulta lähtien. Rekisteriin sisältyy tietoa muun muassa koekalastuspaikoista, saalislajeista, ympäristöolosuhteista ja käytetyistä menetelmistä. Kokare palvelee niin tutkimusta, kalatalouden suunnittelua kuin viranomaisvalvontaakin.

Aiemmin nämä tiedot on tallennettu paperilomakkeille ja selainlomakkeille, mikä oli aikaa vievä ja virheille altis menetelmä. Viime keväänä pääsimme mukaan projektiin, jossa kehitettiin QField-mobiilisovellukseen pilotointityötila koekalastusrekisterin havaintojen keräämistä varten. Tämä työtila tehostaa ja tarkentaa havaintotietojen keruuta maastossa. QField mahdollistaa tiedonkeruun suoraan maastossa mobiililaitteilla, jolloin manuaalinen tietojen syöttö vähenee ja tiedonkeruu nopeutuu.

QField mahdollistaa tiedonkeruun suoraan maastossa

Gispo suunnitteli LUKEn tarpeisiin sopivan QGIS-projektin ja siihen liittyvän QField-työtilan, joka sisältää lomakenäkymät havaintopaikkojen, koekalastusjaksojen, kalasaaliin sekä ympäristöolosuhteiden kuten sään ja vedenlaadun syöttämiseen.

QFieldin käytöstä on useita hyötyjä:

• Virheiden väheneminen: Tiedot tallennetaan suoraan kentällä, mikä poistaa manuaalisen siirron tarpeen.
  
• Aika- ja paikkaleimat: Jokainen havainto tallentuu oikeaan paikkaan ja aikaan.
  
• Käytön helppous: Selkeät lomakenäkymät helpottavat tietojen syöttämistä maasto-olosuhteissa.
  
• Parempi tiedonhallinta: Kaikki tiedot kerätään yhteen paikkaan yhtenäisessä muodossa.
  
• Ajansäästö: Reaaliaikainen tiedonsiirto ja digitaalinen tallennus vähentävät manuaalista työtä ja nopeuttavat prosessia.
  
• Vaivattomuus: Tutkijat voivat kerätä tietoa suoraan mobiililaitteilla ilman paperilomakkeita tai erillisiä taulukoita, mikä vähentää logistisia haasteita.
  
• Joustavuus: QField-projektia on helppo jakaa ulkopuolisille muille käyttäjille kuten konsulteille.
  

QField-työtila modernisoi koekalastustietojen keruuta ja tehostaa tiedonkeruuprosesseja avoimen lähdekoodin välineillä. Se auttaa asiantuntijoita säästämään aikaa ja vaivaa sekä edistää luonnonvarojen kestävää hallintaa.

Kenttätyö modernisoituu

LUKEn koekalastushavaintojen QField-työtila on hyvä esimerkki siitä, miten tutkimus- ja viranomaisorganisaatiot voivat tehostaa tiedonkeruuprosessejaan avoimen lähdekoodin välineillä. Meille on ilo olla mukana rakentamassa ratkaisuja, jotka helpottavat asiantuntijoiden arkea ja edistävät luonnonvarojen kestävää hallintaa.

Tiedolla johtaminen on organisaatioiden elinehto, ja monissa tehtävissä päätöksenteon tueksi tarvitaan erilaisia tietoaineistoja. Tilastojen ja haastattelujen lisäksi tarvittava tietolähde voi tuoda ymmärrystä nykyisestä, tulevasta tai potentiaalisesta toimintaympäristöstä: millainen maaperä jollain alueella on, onko siellä rakennuksia tai muuta infrastruktuuria tai onko alueella tehty tärkeitä lajihavaintoja. Muutamina referensseinä tällaisista projekteista Gispolla ovat YVA-kartat, bioenergian tuotanto Suomessa sekä Suomen luonnonsuojeluliiton vapaaehtoisten ohjeistaminen paikkatiedon käyttöön.

Olemme auttaneet asiakkaitamme löytämään tarvittavat aineistot ja tuoneet niitä tarkasteltavaksi rinnakkain ja päällekkäin. Avoimina aineistoina on löydettävissä esimerkiksi perinteinen Maanmittauslaitoksen maastokartta, mutta myös Suomen tiestö, lomamökit, maakunnallisesti tärkeät lintualueet, laserkeilausdataa, säähavaintodataa ja paljon, paljon muuta. Avoimia aineistoja löytyy kootusti mm. aiemmasta blogiartikkelistamme. Avointa dataa löytyy tietenkin runsain mitoin myös Suomen rajojen ulkopuolelta.

Vaikka datan avaamista puntaroidaan nykyisessä maailmantilanteessa enemmän kuin joitain vuosia sitten, on paljon aineistoja yhä perustellusti saatavilla avoimena, ja ne mahdollistavat mm. yrityksille, organisaatioille ja tutkijoille tietoon perustuvien päätösten tekemisen.*

Joillekin jo aineistojen kokoaminen samaan paikkaan voi olla tärkeä työ, jota ei välttämättä olisi saatu omin voimin tehtyä – tai ainakin se olisi vienyt pois työaikaa muulta työltä. Aineistoista kuitenkin saa enemmän irti, jos niiden visualisointia jaksaa hieman työstää. Käytännössä tämä voi tarkoittaa kriittisten kohteiden korostamista, arvoluokkiin perustuvaa aineiston jaottelua (“suojeltavat rakennukset punaisella, muut harmaalla”) tai ylipäänsä sen varmistamista, että aineistojen katselu yhtäaikaisesti on intuitiivista eikä vaadi loppukäyttäjältä suuria voimainponnistuksia.

Jos asiakkaalla on omia aineistoja, ne voidaan tietenkin tuoda samaan näkymään. Näitä voivat olla suunnitellut tuulivoimalat, asiakkaan hallinnoima infrastruktuuri tai asiakkaan itse maastosta keräämä data. Tätä(kin) aineistoa voidaan helposti jatkojalostaa tekemällä suojavyöhykkeitä tiettyjen kohteiden ympärille, luomalla erilaisia skenaarioita kohteiden sijoittelusta sekä kartoittamalla etäisyyksiä tiettyjen kohteiden välillä. Joskus asiakasta kiinnostaa vain oman Excel-taulukon näkeminen kartalla – sekin onnistuu.

Kun aineistot on kerätty samaan paikkaan, voidaan valmis työ jakaa asiakkaalle joko QGIS-projektina tai vaikkapa nettiselaimella käytettävänä HTML-tiedostona. 

QGIS on, kuten monet blogimme lukijat jo tietävät, ilmainen paikkatieto-ohjelmisto, jonka käyttöön voi löytää ohjeita esimerkiksi Gispon blogista. Jos siis organisaatiolla on jo omia paikkatietoasiantuntijoita, he voivat saada vinkkejä jatkaa ja kehittää aineistoanalyysejään. Tai jos paikkatietokärpänen puraisee nyt ensikerran, voimme kouluttaa organisaationne työntekijöitä ohjelmiston käyttöön ja vastaavien aineistoanalyysien tekoon. 

Mikäli aineistoja tarvitsee päivittää maastosta, voidaan tietoa kerätä QGISin kanssa yhteensopivien QField- ja MerginMaps-kännykkäsovellusten avulla. QFieldillä voidaan tehdä esimerkiksi liikenteenohjauslaitteiden hallintaa, inventoida arkelogisia kohteita ja siirtää maastosta kerättyä dataa suoraan omaan tietokantaan. HappyMiniQ puolestaan mahdollistaa sen, että 4000 € lisäinvestoinnilla tuloksien tarkkuus paranee senttitasolle .

Toisinaan QGISiä moititaan siitä, että ohjelmassa “on liikaa nappeja” tai että aloituskynnystä ohjelmiston käyttöön pitäisi saada madallettua. Tämä voidaan onneksi ratkaista. Ohjelmistoon voidaan määrittää valmiiksi käyttäjäprofiili (tai useampi), jossa on valmiiksi määritelty tiettyjä aineistoja ja piilotettu tulevien käyttäjien kannalta epäolennaiset työkalut. Näin voidaan jaella joko organisaatiokohtaista asennuspakettia QGISistä – tai isompaan organisaatioon vaikka tiimikohtaiset asennuspaketit.

Lopuksi jää vain kysymys: millaisia tarpeita teillä on?

*) Kirjoittaja ei ota vastuuta siitä, ovatko tietoon perustuvat päätökset ovat typeriä ja/tai laittomia.

Kuntien ja kaupunkien rooli liikenteenohjauslaitteiden tiedonhallinnassa on siirtynyt ylläpidollisesta tehtävästä strategisen infrahallinnan ytimeen. Liikennemerkkitietojen keruu ja ajantasainen ylläpito ovat välttämättömiä paitsi liikenneturvallisuuden ja yhdyskuntasuunnittelun myös valtiollisten ilmoitusvelvoitteiden vuoksi.

Niin sanotusti “uutena tieliikennelakina” (729/2018) tunnettu laki asettaa tienpitäjille, mukaan lukien kunnille, velvollisuuden ilmoittaa tiedot liikenteenohjauslaitteista (kuten liikennemerkeistä, ajoratamaalauksista ja liikennevaloista) Väyläviraston ylläpitämään Digiroad-järjestelmään. Tämä ilmoitusvelvollisuus on keskeinen osa kattavan kansallisen tie- ja katuverkon tietopohjan luomista.

On myös huomattava, että kattava ja luotettava liikenteenohjausdata edustaa nykypäivänä kriittiseen infrastruktuuriin liittyvää tietoa. Sen eheä, ajantasainen ja kansallisissa järjestelmissä säilytetty hallinta on olennaista yhteiskunnan kyberturvallisuuden ja toimintakyvyn turvaamiseksi häiriötilanteissa.

Tiedonhallinnan tekninen perusta: paikkatietokannan ja tietovirtojen merkitys

Tehokas tiedonhallinta edellyttää, että kunta pystyy jakamaan ja hyödyntämään liikennemerkkitietoa sisäisesti useiden eri sidosryhmien ja sovellusten kesken. Tämän mahdollistamiseksi teknisenä perustana toimii monikäyttäjäprosessit mahdollistava paikkatietokanta (tyypillisesti PostgreSQL/PostGIS), joka tarjoaa keskitetyn, eheän ja usein myös versioidun tiedonlähteen.

Gispo on erikoistunut kehittämään ja toteuttamaan juuri tällaisia kokonaisvaltaisia, End-to-End-ratkaisuja. Kokemuksemme esimerkiksi Tampereen kaupungin liikenteenohjauslaitteiden tiedonhallinnan kehitystyöstä on konkretisoinut tätä osaamista.

Tampereen liikennemerkkirekisterin tiedonkeruuta kehittämässä

Tampereen kaupunki on kehittänyt liikennemerkkirekisterinsä tiedonhallintaa usean toimittajan yhteistyönä avoimen lähdekoodin ohjelmistoperiaattein. Tämä lähestymistapa on taannut kaupungille joustavuuden sekä mahdollistanut räätälöidyn ja tarvelähtöisen ratkaisun kehittämisen.

Gispo on osallistunut prosessin kehittämiseen viimeisimmässä vaiheessa, jossa tiedon editointimahdollisuudet tuotiin maasto-olosuhteisiin QField-mobiilisovelluksen avulla. Liikennemerkkitietojen maastotiedonkeruuprosessi on rakennettu Tampereella niin ikään avoimeen lähdekoodiin perustuvan QFieldCloud-teknologian päälle. QFieldCloud on QField-prosessien hallintaan tarkoitettu pilvipalvelu, jonka avulla voi määrittää ja hallita käyttäjiä, rooleja, tietoturvaa ja datan synkronointia. Tämän arkkitehtuurin avulla Tampere saa käyttöönsä niin maastossa kuin toimistolla eheän ja ajantasaisen tiedon suoraan keskitetyn paikkatietokannan kautta.

Tämänlaiset tiedonhallintaratkaisut varmistaa, että kunnat pystyvät paitsi täyttämään lainsäädännön vaatimukset, myös saavuttamaan operatiivista tehokkuutta ja hallitsemaan koko tietoaineistoaan strategisesti.

Strategiset tietovaatimukset ja Digiroadin tekniset reunaehdot

Liikennemerkkitietojen hallinnassa pelkkä nykytilanteen kuvaaminen ei riitä. Strategisen infrahallinnan ja riskienhallinnan näkökulmasta tietovaatimukset ovat laajat ja useimmiten kaupunkien omat tarpeet ylittävät Digiroadin minimitason.

1. Hallinnollisen historian varmistaminen (versiointi)

Strategisista vaatimuksista esimerkkinä versiointi. Vaikka liikennemerkkien historian versionhallinta ei ole suora lakisääteinen Digiroad-vaatimus, se on oikeudellisen riskienhallinnan ja hyvän hallintotavan kannalta tärkeä ominaisuus. Järjestelmän on kyettävä tallentamaan liikennemerkin historia niin, että takautuvasti tiedetään milloin ja minkälainen merkki on ollut voimassa tietyllä paikalla. Tämä on kriittistä mm. onnettomuusselvityksissä.

2. Digiroad-tietovaatimuksien täyttäminen

Lakisääteinen ilmoitusvelvollisuus edellyttää tiedon toimittamista Väyläviraston määrittämässä muodossa (esimerkiksi XML/GML- tai taulukkomuodossa) ja viraston määrittämän tietomallin mukaisesti. Digiroad edellyttää tarkkaa tietoa liikennemerkeistä mm. seuraavien vaatimuksien osalta:

Digiroad-ilmoitusvelvoituksien täyttäminen vaatii tiedon siirtoa kansallisiin järjestelmiin. Tähän on eri tapoja:

• Massatoimitukset (CSV/Excel): Väylävirasto tarjoaa kunnille massatoimituksiin CSV/Excel-pohjia. Nykyaikaisessa paikkatietokannassa (kuten PostGIS) on tehokasta luoda ja päivittää tällaiset koontinäkymät automatisoidusti suoraan kerätystä tiedosta.
• Tulevaisuuden kuntarajapinta (Infra-O-yhteensopiva): Digiroad-ohjelmassa kehitetään Infra-O-yhteensopivaa kuntarajapintaa, joka mahdollistaa automaattisemman tiedonvaihdon. Rajapinnan kehitystyö on kesken, ja sen valmistumisaikatauluun vaikuttaa suoraan Digiroad-palvelun operointivastuun siirtyminen lakimuutoksen myötä Väylävirastolta Liikenteenohjausyhtiö Fintraffic Oy:lle. On mahdollista, että tähän työhön liittyy rahoitusta myös avoimen lähdekoodin työkaluille (kuten Infra-O Open QGIS-lisäosalle), mikä helpottaisi kuntien rajapintojen hyödyntämistä.

3. Kunnossapidon ja omaisuudenhallinnan tieto

Digiroadin tietomalli mahdollistaa myös kuntien oman infrapääoman hallinnan kannalta kriittisten tietojen keruun, vaikka ne olisivat vapaavalintaisia. Näitä ovat esimerkiksi:

Nämä tiedot, kuten yleinen kuntoluokka, kalvon tyyppi ja arvioitu jäljellä oleva käyttöikä, eivät ainoastaan tue kunnan strategista omaisuudenhallintaa, vaan mahdollistavat myös sen, että kunnossapidon ja yhdyskuntasuunnittelun toimet voidaan kohdentaa tehokkaasti juuri niihin kohteisiin, jotka ovat liikenneturvallisuuden kannalta kriittisimmät.

Siirry manuaalisesta työstä automatisoituun infrahallintaan

Liikennemerkkitietojen hallinta on strateginen investointi, joka edellyttää teknisesti kestävää arkkitehtuuria. Kuten edellä kuvattiin, haasteena on yhdistää tehokas mobiilitiedonkeruu, kriittisen historian (versioinnin) säilytys sekä lakisääteisen Digiroad-ilmoituksen tekniset reunaehdot.

Me Gispollaa emme tarjoa vain yksittäistä ohjelmistoa, vaan otamme haltuun koko tietovirran alusta loppuun. Voimme rakentaa modernin monikäyttäjäpaikkatietokannan (PostGIS), joka mahdollistaa eheän ja ajantasaisen tiedon hallinnan. Varmistamme tietovirtojen sujuvuuden mobiilikeruusta (QField) pilvipalveluun (QFieldCloud) ja sieltä keskitettyyn tietokantaan.

Älä anna monimutkaisten tietovaatimusten hidastaa kunnan infrahallintaa. Ota yhteyttä ja siirry manuaalisista prosesseista moderniin, tietovirrat hallitsevaan paikkatietoratkaisuun.

FOSS4G Suomi järjestettiin 9.–10.9. Helsingissä hotelli Arthurissa. OSGeo Suomi ry:n tapahtuma houkutteli paikalle 80 osallistujaa keskustelemaan, kertomaan kiinnostavista käyttötapauksista ja katsomaan myös kohti tulevaa.

Ensimmäinen päivä: avoimesta lähdekoodista ylätasolla

Ensimmäisen päivän aiheina olivat mm. avoimen lähdekoodin käyttöön liittyvät käytännöt organisaatiossa, maastotietojen tuotanto ja avoimen lähdekoodin käyttö Keski-Aasiassa.

Nokian Timo Perälä kertoi avoimen lähdekoodin käytöstä Nokialla, todeten avoimen lähdekoodin olevan täysin välttämätöntä heille. Kuten monissa organisaatioissa, myös Nokialla monissa tuotteissa on avoimen lähdekoodin osia sekä erilaisia käytäntöjä, jotka tukevat avoimen lähdekoodin hyödyntämistä mm. tutkimuksessa ja tuotekehityksessä. Perälä kertoi organisaation osasta nimeltä OSPO (Open Source Program Office), joka oli monelle yleisöstä uusi ja mielenkiintoinen käsite. Tiivistäen OSPOn tehtävä on hallita ja linjata kaikkea avoimen lähdekoodin käyttöön liittyvää organisaatiossa, ja samaan aikaan jokaisen organisaation OSPO on ihan omanlaisensa.

Ensimmäisen päivän puheenvuoroissa korostui paitsi avoimen lähdekoodin käyttäminen, myös sen tukeminen. Vaikka avoimen lähdekoodin ratkaisut ovat ilmaisia ottaa käyttöön, niitä kannattaa tukea ja kehittää. Jos avoin ratkaisu ei olisi heti valmis omaan käyttötarkoitukseen sellaisenaan, lisenssimaksujen maksamisen sijaan rahat voidaan ohjata kehittämiseen yhdessä muiden organisaatioiden kanssa ja/tai juuri niihin sovelluksen osiin, jotka ovat oman käytön kannalta tärkeitä. Ubigun Ilpo Tammi myös huomautti, että yksityiset firmat voisivat helpommin tukea avoimen lähdekoodin yhteisöjä, sillä niillä on usein vähemmän byrokratiaa kuin julkishallinnon organisaatioilla.

Open source -kenttää kannattaakin seurata, henkilöstöä kouluttaa ja hyviä käytäntöjä jalkauttaa. Kentällä on myös paljon yrityksiä ja kehittäjiä saatavilla, ja Suomessakin monilla organisaatioilla on kyvykkyyttä ohjata ja tehdä kehitystyötä.

Maanmittauslaitoksen Risto Ilves kertoi MML:n käyttävän tietyissä prosesseissaan avointa lähdekoodia. Syitä oli useita: EU:n Open Source Software Strategy, se, ettei tiettyihin prosesseihin ole valmiita ratkaisuja ja toisaalta se, että avoimella puolella oli paljon kypsiä ratkaisuja, joihin oli tietoa helposti saatavilla. Teknologiaselvitys kannattaa kuitenkin aina tehdä ja pohtia, onko avoimen lähdekoodin käyttö järkevää. Joillekin organisaatioille avoimen lähdekoodin ohjelmistojen käyttöön voivat vaikuttaa myös hyvin käytännölliset asiat: jos käytössä on vain pienitehoisia tietokoneita ja on todettu, että QGIS toimii niillä hyvin, sitä suositaan.

Avoimen lähdekoodin hyödyt ja haasteet ovat usein subjektiivisia, eivätkä aina myöskään riipu lähdekoodin avoimuudesta. Tunnistettuja huomioitavia ja usein esiin nousevia aiheita ovat esimerkiksi tuoteomistajan rooli, ohjelmistojen räätälöinti, kustannusten arviointi ja vastuun jakautuminen. Väyläviraston Minna Huovinen muistutti myös, että onnistuneessa OS-kehittämisessä tilaajan rooli ei voi olla etäinen ja pelkästään hallinnollinen.

Ohjelman päätteeksi osallistujat patistettiin ulos ryhmäkuvaan. Ensimmäinen päivä jatkui virallisen ohjelman jälkeen jatkoilla, mutta se jää tämän blogin ulkopuolelle.

Toinen päivä: käytännön esimerkkejä

Toisena päivänä ohjelma oli jaettu kahteen saliin ja esitykset käsittelivät enemmän käytännön ratkaisuja, esimerkkejä ja teknisiä toteutuksia. Ohjelmisto oli ilahduttavan runsas. Pienessä salissa aiheina olivat esimerkiksi PROJ-kirjasto ja suomalaisten koordinaattijärjestelmien puuttuvat muunnokset, HOASin paikkatiedon käyttötapaukset vuokra-asuntojen tiedontuotannossa ja -jakelussa asukkaille sekä pistepilvien hallinta ja hyödyntäminen.

Pienen salin kiinnostavina nostoina mainittakoon ensimmäisenä Gispon Ville Hamusen esitys, joka käsitteli QGISille tehtyä SLYR-lisäosaa, joka mahdollistaa kattavien ja monimutkaisten ArcGIS Pro – ja ArcMap-työtilojen kääntämisen QGISiin. Lisäosa kääntää työtilan QGIS-projektiksi, ESRI:n symbolikirjastot QGISiin ja tuo myös karttalehdet ja -tulosteet ohjelmistoon.

MML:n Teemu Saloriutta esitteli kartografisia yleistysalgoritmeja, jotka mahdollistavat automaattisen karttojen tuotannon eri mittakaavatasoilla. Koska työ päätettiin tehdä avoimella lähdekoodilla, algoritmit pystyttiin kehittämään täysin Suomen tarpeisiin, jolloin esimerkiksi meille tyypillisten pienten, kapeiden saarien käsittelyyn oli saatu tehtyä oma algoritminsa.

Pistepilvien käsittely kiinnosti myös osallistujia, ja pieni sali tuli täyteen Sami Luoman puheenvuoron ajaksi. Pistepilvien hallinnassa ja hyödyntämisessä voidaan toki puhua teknologioista ja ohjelmistoista, mutta selvästi tämänkin aiheen osalta käytännöillä on suuri vaikutus: jotta datasta saatiin asiakkaalle hyötyä, olemassaoleva data koottiin yhteiseen tietovarastoon, uuden datan tuotantoon luotiin tilaamisen ja tiedonhallinnan oppaat, ja kehitettiin aineiston validointiprosessit. Kuten monien muidenkin toisen päivän tapausesimerkkien kohdalla, myös tässä projekti jatkuu ja kehittyy.

Pääsalissa saatiin kuulla avoimen lähdekoodin käytöstä Metsäkeskuksella sekä Lajitietokeskuksella. Yhteenvetona voisi sanoa, että molemmilla on hyvin laaja kirjo avoimen lähdekoodin työkaluja käytössä. Jan Wolski esitteli myös avoimella lähdekoodilla rakennettua palvelua, jossa huomioidaan luontoarvoja metsätoimenpiteiden suunnittelussa. Avoimen lähdekoodin käyttö Geologian tutkimuskeskuksella (GTK) oli myös agendalla ja oli ilo huomata, että heilläkin siirtyminen PostgreSQL-tietokantaan on suunnitteilla. Myös GTK:n verkkopalveluita ollaan uudistamassa ja siihenkin pyritään käyttämään avointa lähdekoodia. Lounaistiedon Natalia Räikkönen esitteli useita projekteja, missä on käytetty muun muassa Oskaria, GeoServeria ja PostGISia.

Yksi pääsalin kohokohdista oli Maanmittauslaitoksen Jukka Rahoksen viihdyttävä esitys GDAL-kirjaston uusista ominaisuuksista. Harvoin kuulee jonkun kertovan niin ymmärrettävästi paikkatiedon komentoriviohjelmistosta. Suomen ympäristökeskuksen Mika Heikkinen oli innostunut OSGeo Suomi ry:n puheenjohtaja Pekka Sarkolan alkupuheesta ja demonstroi Syken QGIS-lisäosia oman varsinaisen esityksensä jälkeen. Tätä oli kiinnostavaa seurata, koska lisäosat ovat pääosin organisaation sisäiseen käyttöön, joten ulkopuoliset eivät niitä pääse kokeilemaan. 

Lopuksi

FOSS4G Suomi oli selvästi pidetty ja odotettu tapahtuma. Oli ilahduttavaa huomata tuttujen kasvojen lisäksi uudempia tuttavuuksia, käydä keskusteluja tauoilla ja nauttia erinomaisesta ohjelmasta. Suurin kiitos kuuluu tietenkin OSGeo Suomi ry:lle, tapahtuman järjestäjille ja sponsoreille, sillä, kuten sanottua, asiat eivät tapahdu itsestään, vaan taustalla oli nytkin useamman ihmisen työpanos.

Ensi kertaan!

Olet saattanut huomata, että QGISin versiossa 3.40 ja eteenpäin on ilmestynyt uusi mystinen nappi Tasojen hallinnan työkalupalkkiin (jos muistisi lyö työkalupalkkien kohdalla tyhjää, voit ilmoittautua QGIS-kurssille täältä). Eli tämä punaisella ympyrällä korostettu nappi:

Kuvateksti: Uusi mystinen nappi muuten tavallisessa QGIS-projektissa

Tämä nappi mahdollistaa STAC-määrittelyn mukaisen aineiston haun suoraan QGISissä. Aiemmin tähän tarpeeseen on löytynyt lisäosia, mutta nyt siis aika on ollut kypsä sen lisäämiseksi suoraan QGISiin.

Mikä ihmeen STAC?

STAC on lyhenne sanoista SpatioTemporal Asset Catalog.  Se on systemaattinen tapa järjestää paikkatietoa aikaleimalla. Eli eräänlainen standardi. Se ei kuitenkaan (vielä) ole OGC (Open Geospatial Consortium)-standardi, mutta ehkä tulevaisuudessa.

Miksi STAC?

Gispolla tykätään avoimista standardeista, mutta joku saattaisi kysyä, eikö niitä ole jo tarpeeksi. STACin tarkoitus ei ole kapinoida OGC API-rajapintoja vastaan, vaan täydentää niitä. STACin läheisin OGC API-sukulainen on ehkä OGC API Records (CSW:n edeltäjä), koska molemmat mahdollistavat metadatan haun esim. aluerajauksella. OGC API Records on yleisempi, kun taas STAC keskittyy spatiotemporaalisiin satelliitti- ja Earth Observation -aineistoihin. 

Keskeiset käsitteet ja STACin rakenne

CSC:n sivuilla on listattuna STACin keskeisimmät käsitteet. Tässä niille vielä suomennokset: 

• Luettelo = Catalog
• Kokoelma = Collection
• Tuote = Item
• Resurssi = Asset

STACin rakenne on helpompi käsittää esimerkin kautta, joten keksitäänpä sellainen. Minä olen intohimoinen äyriäistutkija ja seuraan aktiivisesti katkarapujen elinympäristöjä. Jotta voisin mahdollisimman kätevästi jakaa oleellista paikkatietoa (kuten vesien lämpötiloja aikaleimalla) kavereilleni (jotka eivät ole aivan yhtä kiinnostuneita katkaravuista), niin pistän pystyyn STAC-katalogin ja nimeän sen “Äyriäisten ystävät ry:n STAC”. Kun yhdistetään tähän katalogiin niin saadaan esille kokoelmat “Vesilämpötilat_2m”, “Vesilämpötilat_10m”, Vesilämpötilat_50m”, “planktonesiintymät”, “leväesiintymät” ja katkarapukalastusalueet_sos. Kokoelmien sisältä löytyvät tuotteet. Tuotteita on jo jonkin verran ja ne ovat nimeltään esimerkiksi “Vesilämpötilat_2m_01_01_2025_suomenlahti”, “leväesiintymät_rapusaari_15_3_1912”. Tuotteet ovat siis tietyltä ajalta ja alueelta. Tuotteiden alta löytyy vielä resurssit, joiden kautta saadaan linkki aineistoille. Resursseja voi olla useampia ja esimerkiksi “katkarapuakalastusalueet_sos”-kokoelman tuotteessa “katkarapukalastusalueet_sos_2025_atlantti” on kolme resurssia “10m”, “50m” ja “100m”, eli kolme aineistoa, jotka kuvaavat samaa asiaa, mutta eri resoluutiolla. 

Kuka käyttää STACia?

STAC sopii käyttöön tahoille, jotka haluavat jakaa spatiotemporaalista dataa järjestelmällisesti. Tämä voi olla esimerkiksi jokin äyriäisharrastelijaporukka tai valtion virasto. Suomessa ainakin Tieteen tietotekniikka keskus CSC sekä Ilmatieteen laitos käyttävät STACia. Ruotsissa Lantmäteriet avasi vuoden alussa paljon aineistoja, monet niiistä ovat jaossa STACin kautta. Lue meidän ruotsinkielisestä blogista lisää.

Aineiston hakeminen ja lataaminen STACia käyttäen

Seuraavaksi kokeillaan ladata Paitulin STACin kautta aineistoja QGISiin (koska en ole vielä ehtinyt pystyttää STACia Äyriäisten ystävät ry:lle). 

Kuten yllä kerrottu, QGISissä on nykyään sisäänrakennettu STAC-nappi, jota voi käyttää, mutta tätä kirjoittaessa (syyskuussa 2025) koen, että enemmän hyötyä saa irti asentamalla STAC API Browser-lisäosan. Sen kautta saat helposti suodatettua ja ladattua aineistoa. Lataa lisäosa seuraavasti:

QGISiisi ilmestyi uusi nappi, jonka kautta pääset lisäosalla ottamaan yhteyttä STACiin. Paina nappia. Muutama valmis yhteys on jo olemassa, mutta jos haluat ottaa yhteyttä esimerkiksi Paitulin STACiin, paina “New” ja lisää nimi ja URL. Paina sitten OK.

Tämän jälkeen hyppäät takaisin STAC API Browserin aloitusikkunaan. 

Vilkaise tässä välissä “Settings”-välilehteä ja kerro lisäosalle, minne haluat aineistojen tallentuvan. Oletuskansio ei yleensä ole paras paikka. Palaa tämän jälkeen “Search”-välilehdelle.

Pidä Paituli valittuna ja paina “Fetch Collections”. Jos haluat suodattaa pois aineistoja, voit kokeilla onneasi “Filter”-kentässä. Voit myös rajata hakua ajallisesti sekä alueellisesti. Henkilökohtainen suosikkini on rajata alue QGISin karttaikkunan laajuuden mukaan, koska en ikinä muista koordinaatteja ulkoa.

Paina tämän jälkeen “Search”. Jos tuloksia ei ole, niin palaa ja laajenna suodatusta. Jos sait jotain tuloksia niin hyvä sinä! Jos tarvitset tarkempaa tietoa, missä tuote maantieteellisesti sijaitsee niin voit valita “Select footprint” ja “Add selected footprint”.

Nyt karttaikkunaan ilmestyy uusi taso, joka näyttää alueen, jonka kyseinen tuote kattaa. Jos se on sinulle sopiva, voit paina “View assets”. Tässä uudessa ikkunassa näet tuotteen resurssit ja voit nyt ladata aineiston omalle koneellesi. Valitse itsellesi yksi tai useampi resurssi ja lataa ne. Jos olet onnekas, tarvitsemasi aineisto saattaa olla saatavilla esim. COG-muodossa, jolloin voit ladata sen suoraan QGISiin ilman, että sitä tarvitsee tallentaa paikallisesti. Jos latasit aineistoa omalle koneelle ja haluat saada sen nopeasti käyttöön, niin voit lisätä latauskansion QGIS Selaimen suosikkeihin. Nyt voit vaan klikata aineistot suoraan auki QGISin sisältä.

Näillä eväillä STACia kokeilemaan! Ja jos tulee mitään kysyttävää STACistä, QGISistä, äyriäisten sielunelämästä, rajapinnoista, COGista tai jostain muusta niin otathan yhteyttä!

QField on mobiilisovellus, jonka avulla voidaan kerätä ja päivittää paikkatietoa kentällä. Kun tiedon keräämiseen nähdään se vaiva, että sen vuoksi lähdetään maastoon, tieto myös todennäköisesti halutaan tallentaa ja säilöä niin, että se on hyödynnettävissä myöhemmin. PostgreSQL tietokanta PostGIS laajennuksella (joku saattaa puhua myös PostGIS-tietokannasta) on tähän tarkoitukseen erinomainen vaihtoehto.

Tieto siis kerätään QFieldillä, se tallennetaan tietokantaan ja sitä analysoidaan ja ylläpidetään  QGISillä. Kun tietoa kerätään ja päivitetään QFieldillä, tarvitaan tapa siirtää kerätty tieto tietokantaan. Tähän on periaatteessa neljä, käytännössä kolme toteutustapaa: 

• tiedoston siirto “manuaalisesti” (kaapelilla tai muuten tiedostonhallinnan kautta)
• suora tietokantayhteys
• WFS-T -rajapinta
• QFieldCloud pilvipalvelin

Tarkastellaan näitä vaihtoehtoja seuraavaksi tarkemmin.

Tiedoston siirto manuaalisesti

Tämä tapa on otettavissa käyttöön nopeasti ilman erityisiä pystytyksiä ja asennuksia. Parhaiten tämä menetelmä toimii, jos tiedon kerääjän ei tarvitse synkronoida tietoa tietokannasta, vaan riittää, että kerätty tieto toimitetaan eteenpäin henkilölle, joka vastaa tiedon tallentamisesta tietokantaan. Työn kulku olisi siis seuraava:

• QField projektin luominen (ja toimittaminen tiedon kerääjälle)
• Tiedon keräys maastossa
• Projektikansion toimittaminen takaisin sen luojalle
• Projektin synkronointi QGISissä ja tiedon vienti tietokantaan.

Manuaalinen siirto edellyttää käyttäjältä enemmän osaamista sekä QGISin ja QFieldin perusteissa että yleisesti tietokoneen käyttötaitoa tiedostojen hallinnassa. Huonona puolena manuaalisessa siirrossa on lisäksi, että jos projektia pitää vuorotellen siirrellä laitteeseen ja sieltä pois, versioiden hallinnasta tulee nopeasti hankalaa. 

Manuaalisen siirron etuja  ovat, että se mahdollistaa tiedon keruun ilman verkkoyhteyttä ja on otettavissa käyttöön nopeasti.

Suora tietokantayhteys

Tämä tapa on neljästä mahdollisesta se ei-suositeltava. Tämä tapa edellyttäisi PostgreSQL-tietokannan avaamista verkkoon, mikä ei ole millään tavalla suositeltava toimintatapa. QField-projektiin on kuitenkin mahdollista määrittää suora tietokantayhteys, jos tietokanta on avoimena saatavilla.  Tällöin maastossa kerättävät tiedot päivittyisivät suoraan tietokantaan. Näin toimittaessa tarvitaan koko ajan verkkoyhteys. 

WFS-T rajapinta

Kun yhteys mobiililaitteesta tietokantaan tehdään WFS-T rajapinnan avulla, tietoturva on paremmalla tolalla kuin suorassa tietokantayhteydessä, mutta on huomioitava, että tietokannan käyttäjätunnus ja salasana tallentuvat projektitiedostoon salaamattomina. Rajapinta edellyttää myös jatkuvaa nettiyhteyttä, jotta tietojen tallentaminen onnistuu.  Toteutukseltaan tämä ratkaisu on monimutkaisempi, sillä se edellyttää palvelinohjelmiston (esim. GeoServer), jonka avulla rajapinta luodaan. 

Jos kentältä on tarkoitus kerätä valokuvia kohteista, WFS-T-rajapintayhteys ei mahdollista valokuvien automaattista siirtymistä palvelimelle, vaan kuvat tallentuvat mobiililaitteelle ja niiden siirtäminen pitää hoitaa erikseen. Lisäksi jos tietokanta on tietorakenteeltaan monimutkaisempi ja sisältää esimerkiksi paljon relaatioita ja triggereitä, niin palvelinohjelmisto ja WFS-T ei välttämättä selviydy näistä.

QFieldCloud -pilvipalvelu

Pilvipalvelu mahdollistaa tiedon siirtämisen nopeasti nappia painamalla QFieldistä pilven kautta tietokantaan. Käytännössä toteutusvaihtoehtoja on kaksi, palvelun voi ostaa OPENGIS.ch:lta tai pystyttää oman QFieldCloud palvelimen. Valmiina palveluna ostettuna käyttöönotto on nopeaa ja kätevää. Jos kuitenkin haluaa itse hallita omaa pilvipalveluaan ja sitä, missä tietoja säilytetään, on oman QFieldCloud palvelimen pystyttäminen tarpeellinen vaihtoehto. 

QFieldCloudin ollessa käytössä verkkoyhteyttä tarvitaan projektin lataamiseen ja synkronointiin, mutta itse tiedonkeruu maastossa voi tapahtua ilman yhteyttä.

Tapaus Tampere ja vieraslajit

Tiedon siirtymistä QFieldistää tietokantaan pääsimme pohtimaan ja toteuttamaan yhdessä Tampereen kaupungin kanssa. Tampereen ympäristönsuojelulla oli tarve selkeyttää ja tehostaa vieraslajihavaintoihin ja vieraslajien torjuntaan liittyvien tietojen keräystä ja ylläpitoa.  Kentällä tehtävää tiedon keruuta ja päivitystä varten valittiin uutena työkaluna mukaan QField, tiedon käsittelyssä käytössä oli jo QGIS ja tallennuspaikkana PostgreSQL-tietokanta. 

Tampereella Ympäristönsuojelu vastaa vieraslajeihin liittyvistä tiedoista ja niiden ylläpidosta. Tietoa vieraslajiesiintymistä ja -havainnoista tulee kuitenkin monesta lähteestä. Tampereen Infra Oy tekee paljon vieraslajitorjuntoja ja torjuntatöiden ja muiden töiden yhteydessä kirjaa tehtyjen torjuntatoimenpiteiden lisäksi myös havaintotietoja vieraslajeista. 

Tiedonsiirron menetelmää valittaessa keskeisessä roolissa oli vieraslajeihin keskeisesti liittyvät valokuvat. Kentällä pitää pystyä ottamaan kuvia vieraslajeista ja liittämään ne osaksi havaintotietoa. Vieraslajien torjuntatoimenpiteitä tehdessä otetaan myös kuvia ennen ja jälkeen toimenpiteen.  Lisäksi käyttäjien on tarpeen nähdä maastossa muiden ottamia kuvia. Tämä helpottaa esimerkiksi torjuttavan kohteen löytämistä.

Tampereen kaupunki otti käyttöön oman QFieldCloud -palvelimen, jota vieraslajiprojekti pääsi ensimmäisenä kokeilemaan ja käyttämään.  Käyttäjät kirjautuvat QFieldillä QFieldCloudiin, lataavat vieraslaji-projektin sieltä ja pääsevät sen jälkeen merkitsemään havaintoja ja torjuntoja sekä liittämään niihin ottamiaan kuvia. Vieraslajitiedot päivittyvät QFieldCloudin kautta tietokantaan ja kuvat tallentuvat palvelimelle.  Haasteena on, että QFieldCloud tahtoo pakata kaikki valokuvat mukaan projektitiedostoon, jonka koko paisuu varsin suureksi. Projektimme jälkeen QFieldCloudiin on tullut uusi ominaisuus, joka mahdollistaa kuvien lataamisen vasta kun käyttäjä tahtoo sellaista katsoa.  QField ja QfieldCloud kehittyvät siis koko ajan ja onkin mielenkiintoista seurata, mitä mahdollisuuksia uudet versiot tarjoavat käyttäjille.

GeoServerin käyttäjäyhteisö on ottamassa ison harppauksen eteenpäin, kun GeoServer 3 -versio julkaistaan. Tämä ei ole pieni päivitys, vaan merkittävä muutos, joka uudistaa GeoServerin koko perustan. Uusi versio tuo mukanaan paremman suorituskyvyn ja tietoturvan, mutta samalla se asettaa monelle organisaatiolle uudenlaisen haasteen.

Mikä muuttuu ja miksi se on tärkeää?

GeoServer 3 siirtyy käyttämään nykyaikaisempia teknologioita, kuten Spring Framework -kehyksen versiota 6. Tämän seurauksena muun muassa Java-versio on vihdoin päivitettävä vähintään versioon 17. Nämä muutokset on tehty siksi, että GeoServer pysyy jatkossakin turvallisena ja tehokkaana työkaluna. Vaikka tällaiset päivitykset ovat tärkeitä, ne eivät ole aina helppoja. Ne voivat vaatia aikaa ja erikoisosaamista.

Mitä olemme oppineet asiakkaidemme haasteista?

Usein asiakkaidemme IT-tiimit ovat todella kiireisiä. Minor-päivitykset on helppo hoitaa itse, mutta GeoServer 3:n kaltainen isompi muutos vaatii syvällistä GeoServer-osaamista. On syytä valmistautua päivitykseen laaja-alaisella testauksella, sillä pienetkin virheet esimerkiksi datakansion (eng. data directory) käsittelyssä tai sovelluspalvelimen Java-asetuksissa voivat aiheuttaa palvelukatkoja ja turhaa päänvaivaa. Päivityksen sudenkuoppien tunnistaminen ja välttäminen onkin avainasemassa.

Kumppanuus asiantuntijan kanssa: Näin me autamme

Haluamme tehdä GeoServer-päivityksestä mahdollisimman vaivattoman ja vähäriskisen. Näin IT-tiiminne voi keskittyä muuhun.

1. Alkutilanteen arviointi: Aloitamme lyhyellä arviolla, joka antaa selkeän kuvan ympäristönne tilasta. Näin tiedätte tarkalleen, mitä päivitys vaatii.
2. Päivitys: Hoidamme kaiken itse, datakansion siirrosta konfiguraatioon.
3. Riskien minimointi: Tunnemme GeoServerin yksityiskohdat ja osaamme ratkaista mahdolliset ongelmat ennakolta, jotta palvelunne ovat heti käytössä.

Loppusanat

GeoServer 3 -päivitys on tärkeä askel eteenpäin. Anna meidän auttaa, jotta voitte keskittyä oman toimintanne kehittämiseen.

Ota yhteyttä ja keskustellaan, miten luomme teille selkeän ja luotettavan suunnitelman GeoServer 3 -päivitykseen.

Lisätiedot: https://github.com/geoserver/geoserver/wiki/GeoServer-3