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), tämä 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.

https://todogroup.org/resources/mindmap

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, kuten 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 aiheet olivat enemmän käytännön ratkaisuissa, esimerkeissä ja teknisessä toteutuksessa. 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

Pilvimigraatio on osalle organisaatioista arkipäivää, osa on kokeiluvaiheessa, jotkut vielä pohtivat asiaa. Vaikka kovin kuhina ja hype Dockerin ja muiden konttiratkaisuiden päällä on tyyntynyt, ehti “onko siitä Dockeria?” -kysymys vakiintua kielenkäyttöön uusista sovelluksista puhuttaessa. 

Olivatpa kontit ja pilvipalvelut lukijalle tuttuja tai eivät, tässä artikkelissa käymme läpi niiden hyötyjä ja niihin liittyvää pohdintaa käyttäen tapausesimerkkinä Oskari-karttapalvelua. Oskarista voit lukea lisää aiemmista blogeistamme tai Oskarin kotisivuilta. 

Artikkeli on alunperin julkaistu englanniksi Oskari.orgissa. Gispon Juho Rekilä toimii Oskarin viestintäkoordinaattorina.

Mitä ovat pilvipalvelut? Mitä ovat kontit?

Tunnetuimmat pilvipalvelut tällä hetkellä lienevät Amazonin AWS ja Microsoftin Azure. Ne ylläpitävät asiakkaidensa sinne sijoittamia palveluita ja tarjoavat ylläpitoon liittyviä erilaisia lisäpalveluita. 

Pilvimigraatioita voi ajaa tarve pitää julkinen ja valtionhallinnon käyttämä data erillään toisistaan. Nämä kaksi käyttötapausta voidaan erottaa selkeästi käyttämällä julkista pilvipalvelua julkiselle datalle ja toista palvelua sisäiselle datalle.

Pilvipalvelussa ylläpitämisen yhtenä vaihtoehtona on ylläpitää palveluita organisaation omassa konesalissa. Jos organisaatiolla on jo konesali ja siellä tyhjiä palvelimia, palvelut voidaan tietenkin asentaa sinne. Omassa konesalissa palvelut ovat (todennäköisesti) fyysisesti lähellä, ja uuden palvelimen asentaminen voi vaatia manuaalista työtä kaapeleiden ja tietokoneiden kanssa. Pilvialustoilla sama työ voidaan tehdä hiirellä klikkailemalla. Tämä tekee pilvialustoista nopean tavan pystyttää uusia palveluita ja esimerkiksi testata uusinta Oskari-versiota.

Kun palvelua ylläpidetään pilvipalvelussa, organisaatio vastaa ohjelmistosta ja sen päivityksistä, kun taas pilvipalveluntarjoaja varmistaa, että taustalla oleva laitteisto – kuten palvelimet ja fyysiset komponentit – toimivat oikein. Jos taas organisaatiolla on oma konesali, jossa on ongelmia laitteiston kanssa, organisaatio on omillaan.

Konttiteknologia tarkoittaa sovelluksen ja sen kaikkien riippuvuuksien (kirjastot, asennustiedostot jne.) pakkaamista ja eristämistä yhdeksi yksiköksi, jota kutsutaan kontiksi. Konttien luomiseen ja ajamiseen on työkaluja, mm. Docker ja Podman.

Kontit voivat helpottaa ohjelmistojen kehittämistä, testaamista ja käyttöönottoa. Parhaimmillaan kontit tarjoavat yhtenäisen tavan ohjelmistojen pakkaamiseen ja jakamiseen. Kontteja voidaan myös helposti ajaa pilvipalvelussa, ja niitä voidaan ajaa myös omalla tietokoneella. Näistä ominaisuuksista lisää seuraavaksi.

Miksi ajaa Oskaria kontissa?

Oskarissa konttiratkaisun käytön edut verrattuna perinteiseen asennukseen ovat samanlaisia ​​kuin muissa ohjelmistoissa. Tiivistäen voidaan sanoa, että kontit voivat yksinkertaistaa erilaisia ​​prosesseja, jotka liittyvät ohjelmiston asennukseen, kehitykseen ja ylläpitoon. 

Jos ohjelmistosta on saatavilla konttiratkaisu, koko ohjelmisto voidaan ladata yhtenä tiedostona (container image). Myös asennusprosessi helpottuu, sillä monimutkaisetkin asennusprosessit voidaan suorittaa yhdellä komennolla.

Kontin käyttö voi helpottaa kehittäjien työtä, jos esimerkiksi kehitystiimillä on yhtenäinen, jaettu konttiratkaisu ohjelmistolle, jota käytetään paikalliseen kehitykseen ja testaukseen. Tuotantokäyttöä varten ohjelmistosta voidaan tehdä erikseen toinen kontti, joka on räätälöity tietylle pilvialustalle. Tämä helpottaa karttapalveluiden ylläpitoa ja käyttöönottoa.

Kontitetun Oskarin käyttö ratkaisee myös ongelmatilanteen, jossa kehittäjän tietokoneella oleva kehitysympäristö ei vastaa tuotantokäytössä olevan Oskarin palvelinympäristöä. Tuotantokäyttöön suunniteltua konttia voi käyttää palvelimen lisäksi myös paikallisesti kehittäjän koneella, jolloin eri ympäristöt ovat yhdenmukaisia keskenään.

Samalle ohjelmistolle voidaan siis luoda erilaisia ​​kontteja: yksi paikalliseen testaukseen ja toinen tuotantokäyttöön – ja eri ympäristöjen yhdemukaisuutta tarvittaessa samaa konttia voidaan ajaa palvelimella ja paikallisesti omalla koneella.

Pilvialustat yleensä pyrkivät tekemään konttien ylläpidosta helppoa, mutta Oskarin käyttö kontissa ei välttämättä tarkoita, että palvelu pitäisi siirtää pilvialustalle. Konttiratkaisu voi silti olla hyödyllinen mm. edellämainituista syistä.

Kannattaako Oskaria ajaa pilvialustalla?

Yksinkertaisimmassa muodossaan Oskarin käyttö pilvialustalla tarkoittaisi palvelun ylläpitoa esimerkiksi Microsoftin Azuressa. Loppukäyttäjä tai palvelun ylläpitäjä ei välttämättä edes huomaa palvelun siirtymistä pilvialustalle. 

Palveluita voidaan ylläpitää pilvialustalla, vaikka sitä ei olisi kontitettu. Jos palvelu kuitenkin pyörii kontissa, se voidaan asentaa jaetulle palvelimelle ja palvelun kokonaishinta voi tulla halvemmaksi. Usein kuitenkin asiakas ostaa palvelunsa (kuten Oskarin) käyttöön oman palvelimen.

Kun palvelua käytetään pilvialustalla, saadaan käyttöön myös alustan tarjoamat lukuisat työkalut. Eri pilvialustoilla on erilaisia ​​työkaluja, kuten bugiraportit, jotka helpottavat bugien löytämistä ja korjaamista. Tarvittaessa voidaan luoda erilaisia kontteja, jotka sisältävät Oskarin ja siihen liittyviä palveluita – tai pilvialustan tarjoamia siihen tarjoamia palveluita. Näitä voivat olla esimerkiksi tietoturvatyökalut, Oskariin pääsyä rajoittavat työkalut ja/tai palvelun valvonta.

Erityisesti alustan tarjoamat lisäpalvelut helpottavat usein ylläpitoa. Muun muassa pääsynhallinta on helpompaa, tietokannan ja palveluiden varmuuskopiointia voidaan nopeuttaa, ja saatavilla olevat tietoturvatyökalut yksinkertaistavat tietoturvatilanteen seurantaa. Pilvipalvelut mahdollistavat myös sovellusversioiden ja alustojen nopeamman testauksen, kun uuden palvelun käyttöönotto vaatii lähinnä hiiren napsautuksia verkkoselaimessa.

Valikoiden klikkailu verkkoselaimessa ei kuitenkaan ole ainoa tapa ottaa käyttöön uusia palveluita. Pilvialustoja voidaan hallita myös käyttämällä Infrastructure as Code -työkaluja, kuten Terraformia tai pilvipalveluntarjoajan CLI-työkaluja halutun ympäristön määrittämiseksi.

Tällaisten ohjelmistojen käyttäminen mahdollistaa sen, että voidaan kirjoittaa komentoja/skriptejä, jotka käskevät alustaa luomaan palvelinympäristön, asentamaan sinne valitut kontit ja määrittämään palveluihin liittyviä asetuksia. Samaa skriptiä (joko muuttumattomana tai hieman muokattuna) voidaan sitten käyttää saman palvelun asentamiseen toiseen järjestelmään. Häiriötilanteessa palvelu voidaan tarvittaessa sammuttaa ja skriptin avulla rakentaa nopeasti uudelleen.

Skripti voidaan myös tallentaa versionhallintajärjestelmään, jolloin muutoksia voidaan seurata ja asennusta voidaan toistaa helposti. Tämä on usein yksinkertaisempaa ja luotettavampaa kuin yrittää toistaa jokainen palvelun käyttöönottovaihe selainlomakkeissa kautta.

Jatkopohdintaa

Jos Oskaria tai muuta palvelua aiotaan käyttää pilvialustalla, on otettava huomioon useita asioita. Miten sovelluksen sisäinen verkkoliikenne käsitellään? Mitä resursseja ja lisäpalveluita otetaan käyttöön pilvialustalta? Missä kontit säilytetään? Säilytetäänkö vanhoja versioita, kuinka kauan ja missä? Varmuuskopioidaanko koko tietokantaklusteri ja kuinka usein?

Vaikka pilvialustojen työkalut ovat monella tapaa helpottaneet tietoturvan hallintaa, esimerkiksi AWS:n haavoittuvuuksien lista ei ole välttämättä yksiselitteinen. Jos samassa kontissa on esimerkiksi viisi Oskari-instanssia ja jokaisessa on kaksi tietoturvaongelmaa, kokonaistilanne saattaa näyttää todellisuutta huonommalta (“sinulla on 10 tietoturvaongelmaa!”), ja tilanteesta nopean yleiskuvan saaminen voi olla haastavaa.

Näkymät palvelun käyttöön ja kokonaiskustannukset voivat myös vaikuttaa pilvimigraatioon. Pilvialustoilla on useita erilaisia ​​hinnoittelumalleja, kuten  on-demand-malli, jossa palvelun kustannukset määräytyvät käytön mukaan. Lopulliseen hintaan vaikuttavat myös ostetut lisäpalvelut ja käytettävän palvelimen tyyppi. Koska prosessoreita ja muistiyksiköitä on saatavilla kymmeniä, hintaan vaikuttavien muuttujien kokonaismäärä on suuri. Vasta kun palvelu on käynnissä, nähdään siihen valittujen ratkaisujen toimivuus ja onko asetuksia muutettava – mikä voi vaikuttaa palvelun kokonaiskustannuksiin. Tästä syystä lopullista hintaa on vaikea arvioida etukäteen.

Konttiympäristöjen käyttö ja siirtyminen pilvialustoille vaativat myös organisaatiotason linjauksia ja käytäntöjä. Jotkut haluavat siirtää kaikki palvelunsa pilveen, toisilla ei ole vielä vakiintuneita käytäntöjä asian suhteen.

On myös muistettava, että Oskarin tapauksessa ohjelmiston kehittyminen ja päivitykset ovat helpottaneet ohjelmiston sen kehitystyötä ja ylläpitoa kaikilla osa-alueilla – olipa se sitten kontissa tai pilvialustalla tai ei.

Yhdellä lauseella ilmaistuna QGIS on avoimen lähdekoodin työpöytäsovellus paikkatietojen käsittelyyn, analysointiin ja visualisointiin. Puretaan tämä lause osiin ja käsitellään se pala kerrallaan.

• Avoin lähdekoodi: Ohjelmiston koodi on vapaasti saatavilla, kenen tahansa tarkasteltavissa, muokattavissa ja jaettavissa. Kehittäjien yhteisö kehittää ohjelmistoa jatkuvasti ja luo uusia ominaisuuksia. 
• Työpöytäsovellus: Ohjelmisto asennetaan tietokoneelle fyysisesti, eikä sitä käytetä esimerkiksi selaimessa
• Paikkatieto: paikkatieto on tietoa, johon liittyy sijainti ja mahdollisesti muuta ominaisuustietoa. 
• Käsittely, analysointi ja visualisointi: hyppää kohtaan Mitä QGISillä voi tehdä?

QGIS on yksi maailman suosituimmista GIS-ohjelmistoista (GIS = Geographic Information System = paikkatietojärjestelmä). Sitä hyödynnetään lukuisilla eri aloilla ja käyttäjiin lukeutuu niin ammattilaisia kuin opiskelijoita ja harrastelijoitakin.

QGISiä kehittää ja ylläpitää aktiivinen yhteisö. QGIS on myös OSGeo -organisaation alainen projekti. Käytännössä tämä tarkoittaa sitä, että QGIS-projekti täyttää tietyt avoimen lähdekoodin, laadun ja yhteisötoiminnan kriteerit. Käyttäjä voi luottaa siihen, että ohjelmisto pysyy saatavilla, kehittyy koko ajan ja että se ei muutu suljetuksi. 

Miksi QGIS on niin hyvä ja suosittu?

QGISin suosion takana on useita syitä:

• Ilmainen ja avoin lähdekoodi: QGIS on täysin ilmainen ladata ja käyttää. Avoimen lähdekoodin ansiosta kuka tahansa (riitävän koodaustaidon hallitseva) voi hyödyntää koodia (tarkastella, muokata ja jakaa edelleen).
• Monipuolinen: QGIS tukee laajasti erilaisia paikkatietoaineistoja ja tarjoaa työkalut sekä vektoridatan (esim. yksittäiset kohteet kuten tiet, rakennukset tai kaupunginosat) että kuvapohjaisen rasteridatan (esim. ilmakuvat tai korkeusmallit) käsittelyyn.
• Käyttäjäystävällinen: QGISin käyttöliittymä on suunniteltu intuitiiviseksi, mikä tekee siitä helposti lähestyttävän myös uusille käyttäjille. Käyttöliittymä on myös räätälöitävissä käyttäjän tarpeiden mukaan.
• Laaja yhteisö ja tuki: QGISillä on aktiivinen ja laaja yhteisö, joka tarjoaa tukea foorumeilla, dokumentaatiossa ja verkkokursseilla. Tämä helpottaa ongelmien ratkaisemista sekä uusien ominaisuuksien oppimista ja kehittämistä.
• Laajennettavuus (lisäosat): QGISin toiminnallisuutta voi laajentaa tuhansilla lisäosilla (plugins), jotka tarjoavat erikoistuneita työkaluja eri tarpeisiin, kuten verkostoanalyyseihin, datan muunnoksiin ja visualisointiin.
• Yhteensopivuus: QGIS toimii useilla eri käyttöjärjestelmillä, kuten Windowsilla, macOS:llä ja Linuxilla. QGIS tukee monia eri tiedostomuotoja ja rajapintoja. Lisäksi saatavilla on QGISin kanssa yhteensopivia mobiilisovelluksia, joilla aineistot saadaan älypuhelimeen ja toisaalta älypuhelimen avulla paikkatietoa voidaan kerätä mobiilisti vietäväksi työpöytäsovellukseen.

Mihin QGISiä käytetään?

QGISin käyttökohteet ovat lähes rajattomat. Sitä hyödynnetään muun muassa seuraavilla aloilla ja tehtävissä:

• Ympäristöhallinnossa: ympäristövaikutusten arvioinnissa, luonnonsuojelussa ja luonnonvarojen hallinnassa.
• Kaupunkisuunnittelussa: kaavoituksessa, infrastruktuurin suunnittelussa ja väestön jakautumisen analysoinnissa.
• Maataloudessa: peltolohkojen kartoituksessa, sadon arvioinnissa ja lannoituksen optimoinnissa.
• Liikennesuunnittelussa: reittien optimoinnissa ja liikennevirtojen analysoinnissa.
• Pelastustoimessa: hätätilanteiden suunnittelussa ja resurssien kohdentamisessa.
• Arkeologiassa: kohteiden tunnistamisessa, maaston analysoinnissa ja löytöpaikkojen dokumentoinnissa.
• Opetuksessa ja tutkimuksessa: paikkatietojärjestelmien periaatteiden opettamisessa ja tieteellisen tutkimuksen työvälineenä.

Lista on vain pintaraapaisu QGISin käyttömahdollisuuksiin, sillä käytännössä sitä voi käyttää mihin tahansa, missä on tarve paikkatiedoille.

Mitä QGISillä voi tehdä?

Kuten jo aluksi todettu: QGIS on avoimen lähdekoodin työpöytäsovellus paikkatietojen käsittelyyn, analysointiin ja visualisointiin. Ensinnäkin QGISillä voi avata monenlaisia paikkatietoaineistoja. Esimerkkejä yleisimmistä QGISin tukemista tiedostomuodoista ovat GeoPackage, ESRI Shapefile, GeoJSON, TAB ja KML. QGISiin voi tuoda aineistoa myös muista lähteistä kuten erilaisista tietokannoista ja paikkatietopalveluiden (kuten WFS ja WMS-rajapintojen) kautta. 

Kun QGISiin on avattu paikkatietoaineisto tai useampi, niitä voi analysoida yhdessä tai erikseen. Alueille voi esimerkiksi laskea pinta-aloja ja viivoille pituuksia, ja näitä tietoja voi edelleen käyttää suhde- ja tunnuslukujen, kuten väestötiheyden, laskentaan. QGIS sisältää lukuisia työkaluja erilaisten analyysien tekemiseen. 

QGISiä voi käyttää myös paikkatietoaineistojen luomiseen ja ylläpitämiseen. Sillä voi piirtää uusia viivoja, alueita ja pisteitä ja antaa näille ominaisuustietoja. Tätä alueiden piirtämistä kutsutaan paikkatietomaailmassa digitoimiseksi. Digitointia varten QGISissä on runsaasti työskentelyä helpottavia työkaluja. 

Paikkatietoaineistoa yksinään ei vielä ole kovin kaunis katsoa. Vasta visualisoimalla paikkatietoaineistosta voi luoda kauniita ja vaikuttavia karttoja. Tähänkin vaiheeseen QGIS sisältää monia työkaluja. Tämä on se vaihe, kun vesi merkitään siniseksi ja pellot keltaisiksi. Ominaisuustietoja luokittelemalla ja luokittelut visualisoimalla voi luoda teemakarttoja havainnollistamaan esimerkiksi väestöntiheyttä eri alueilla. QGISissä karttaan voi lisätä myös kaikki tarvittavat karttaelementit: pohjoisnuolen, mittakaavan ja selitteen. Lopuksi kartan voi tallentaa kuvaksi esimerkiksi pdf-, svg- tai kuvamuotoon (png, jpeg).

Miten pääsen alkuun?

Yksinkertaisimmillaan: lataa ja asenna QGIS. Avaa QGIS ja avaa saatavilla oleva paikkatietoaineisto QGISissä. Jos sinulla ei ole paikkatietoaineistoa, voit kirjoittaa QGIS-ikkunan alareunassa olevaan koordinaattiruutuun “world”, painaa enter ja ikkunaasi aukeaa maailman kartta, jonka avulla pääset harjoittelemaan paikkatietoaineiston tutkimista ja visualisointia QGISillä. 

Haluatko oppia ohjelmiston käyttöä? Me Gispolla tarjoamme koulutusta QGISin käytön aloittamiseksi:

• Johdanto paikkatietoon ja QGISin käyttöön: heille, jotka eivät vielä tiedä, mitä paikkatieto on, mutta haluavat oppia sekä paikkatiedoista että niiden käsittelystä QGISillä
• Johdanto QGISin käyttöön: heille, jotka tuntevat paikkatietoja, mutta joille QGIS on uusi ohjelmisto
• QGIS-perusteet kunnille: kuin Johdanto QGISin käyttöön, mutta suurempi painotus aineiston luomisessa (digitointi) ja muokkaamisessa (editointi). 
• QGISin kertauskurssi: heille jotka joskus ovat opetelleet QGISin käyttöä, mutta opit ovat päässeet unohtumaan, tai itseopiskelleille, jotka haluavat varmistaa oppineensa keskeiset perustoiminnot.

Olemme olleet mukana tekemässä Autoliitolle sekä liitolle palveluita tarjoavalle AL-Palvelut Oy:lle monenlaisia paikkatietoprojekteja. Autoliitto on  yksityisautoilijoiden palvelu-, etu- ja harrastusjärjestö, joka on perustettu 1919. Autoliitto tarjoaa jäsenistölleen autoiluun liittyviä etuja ja palveluita, esimerkiksi tiepalvelun ja jäsenlehden. AL-palvelut Oy puolestaan tuottaa Autoliitolle erilaisia palveluita tarjoten esimerkiksi hinauspalveluita.

Gispon ja Autoliiton yhteistyö alkoi jo monta vuotta sitten karttavisualisointien merkeissä. Tällöin teimme Autoliiton datan pohjalta näyttäviä karttoja, joita voitiin käyttää Autoliitossa tiedotuksessa, asiakaskäytössä ja sisäisesti.

Yhteistyö jatkui vuonna 2024, kun AL-Palveluille tuli ajankohtaiseksi reittilaskentajärjestelmän kilpailuttaminen. Autoliiton jäsenilleen tarjoama tiepalvelu vastaa vuosittain kymmeniin tuhansiin avunpyyntöihin tien päältä, ja lähimmän hinausliikkeen ja korjaamon löytäminen on olennaista palvelun toteuttamiseksi. Jotta apu saadaan nopeasti ja tehokkaasti perille, hyödynnetään järjestelmässä reittilaskentaa.

AL-Palvelut pyysi Gispolta reitityspalvelun, jonka toteutimme GraphHopperilla. Palvelu on ollut toiminnassa loppuvuodesta 2024 ja on käytössä päivittäin Autoliiton operatiivisessa toiminnassa.

Reittilaskenta käytännössä

Reittilaskentapalvelun vaihtaminen toiseen kävi hyvinkin kivuttomasti. Autoliitolla on käytössä oma järjestelmä, johon kirjataan asiakkailta saapuneet vikapuhelut ja -yhteydenotot. Palvelua käyttävät operaattorit kirjaavat asiakkaan autoon tulleen vian, asiakkaan sijainnin ja asiakkaan sijaintia lähimmät hinausliikkeet, joista olisi mahdollista saada apua tien päälle. Juuri tähän viimeisimpään tehtävään tarvitaan reittilaskentaa: Gispon ylläpitämä avoimen lähdekoodin GraphHopper-työkalu hoitaa etäisyyksien laskennan Suomen tieverkkoa pitkin.

Olemme aiemmin käyttäneet GraphHopperia koulujen saavutettavuuslaskentaan, mutta rajapinta toimii muuhunkin käyttöön. GraphHopperin avulla voidaan tehdä 

• reittilaskentaa
• reititystä
• reittioptimointia
• geokoodausta (sijainnin haku osoitteen perusteella)
• matriiseja matka-ajasta / -matkasta
• GPX-tiedostojen tuomista kartalle tieverkkoon ja 
• klusteroituja ryhmiä yksittäisistä datapisteistä haluttujen rajoitusten puitteissa (kuinka monta pistettä per ryhmä / kuinka kaukana voivat olla toisistaan ym.) 

Kaikki GraphHopperin laskenta pohjautuu OpenStreetMapin tieverkkoaineistoon.

Käytännössä AL-Palveluiden järjestelmä lähettää kyselyitä Gispon ylläpitämään reititysrajapintaan, joka palauttaa vastaukset JSON-formaatissa. Autoliiton kehittäjät muokkasivat hieman omaa ohjelmistoaan, jotta se osaa käsitellä GraphHopperin sille tarjoamaa formaattia, ja ohjelmiston tarjoaman hyvän dokumentaation ansiosta työ sujui sutjakkaasti.

Rajapinta on ollut AL-Palveluilla käytössä lokakuusta lähtien ja yrityksen toimitusjohtaja Ilkka Lehtinen on ollut hyvin tyytyväinen. Rajapinta on toiminut halutulla tavalla ja vaihtamalla reitityspalvelun toimittaja Gispoon on jo nyt saavutettu merkittäviä säästöjä.

“Autoliitto ja AL-palvelut Oy tarvitsevat toiminnassaan luotettavaa perusratkaisua reittikilometrien laskentaan palvelutapauksissamme. Vuosittain avustamme järjestelmämme avulla n. 100 000 tienkäyttäjää eri tyyppisissä tilanteissa ja paikoissa. Kokemus on osoittanut meille vuosien varrella että globaalien pilvitarjoajien pay-as-you -go mallit eivät palvele meitä kovin kustannustehokkaasti. Tähän haasteeseen kaipasimme asiantuntija-apua. Gispon tiimi tuotti meille ratkaisun, joka istuu tarpeeseemme täydellisesti ja toimii erittäin kustannustehokkaasti arjessamme.”

Ilkka Lehtinen, toimitusjohtaja AL-Palvelut Oy

Reitityspalvelun ylläpitoon kuuluvat tietenkin ohjelmiston ja tieverkkoaineiston päivittämiset, palvelun monitorointi, statuspalaverit asiakkaan kanssa, Gispon ylläpitoprotokollan mukainen dokumentaatio ja instanssin varmuuskopiointi. Rajapinnasta on tehty myös kehittäjiä varten testausinstanssi, joka on tuotantorajapinnan tavoin suojattu ulkopuolisilta käyttäjiltä.

Datavisualisointi ja interaktiivinen kartta

Reitityspalvelun ylläpidon lisäksi olemme päässet tekemään AL-Palveluille viimeksi kuluneen vuoden aikana muitakin paikkatietotöitä. Loppuvuodesta 2024 teimme interaktiivisen, nettisivuille upotettavan kartan tiepalvelupiireistä ja niiden päivystysnumeroista. Tänä vuonna tuotimme Kepler.gl-ohjelmistolla datavisualisointeja vuoden 2024 tapauksista.

Vanha kunnon karttapohjainen datavisualisointi paljastaa isosta Excel-tiedostosta yllättävän paljon. Uusi näkökulma aineistoon oli hyödyllinen paitsi AL-Palveluille myös heidän sidosryhmilleen ja asiakkailleen. Kun tuhansia rivejä summataan vaikkapa heatmapiin, saadaan näkyviin, miten ilmiöt sijoittuvat suhteessa toisiinsa, ja kun Kepler ja aineisto vielä mahdollistavat aikasarjan tekemisen, nähdään vaihtelut eri ilmiöiden esiintymisessä eri kuukausina ja jopa vuorokaudenaikoina.

”Kepler on aivan loistava löytö meille. Olimme tuskailleet ja haparoineet eri tyyppisten visualisointimahdollisuuksien parissa pitkään. Tarpeemme ovat aika nopeasti vaihtuvia ja Keplerin tuoma yksinkertaisuus ja helppokäyttöisyys on juuri sitä mitä kaipasimme. Oppimiskäyrä on vain jokusen tunnin siihen, että saamme aikaan hyvää tarkoituksenmukaista visualisointia.

Ilkka Lehtinen, toimitusjohtaja AL-Palvelut Oy

Kesäkuun alussa Ruotsin QGIS User Group järjesti QGIS User Conferencen Norrköpingissä. User conference on kaikille QGIS käyttäjille ja ohjelmistosta kiinnostuneille suunnattu konferenssi. Konferenssin puheenvuorot käsittelivät monipuolisesti QGISiä ja sen käyttöä – mm. käyttötapauksia, ominaisuuksia, yhteentoimivuutta, opettamista ja QGIS-yhteisöä.  Puheenvuorojen lisäksi ohjelmassa oli työpajoja, joissa saattoi opetella ohjatusti uusia ominaisuuksia ja toiminnallisuuksia QGISillä. Konferenssin ja työpajojen jatkoksi Norrköpingissä järjestettiin QGIS-kehittäjien tapaaminen. 

Gispon tiimi matkasi paikan päälle Norrköpingiin verkostoitumaan, oppimaan, osallistumaan ja pitämään Gispon lippua (lue rolluppia) korkealla.

Konferenssin puheenvuorot on julkaistu YouTubessa. Gispon esitykset pääset katsomaan seuraavista linkeistä

• Eemil Haapanen: The killer features of QGIS Server
• Pekka Sarkola & Eeva-Maria Viljakainen, Finavia:  Using QGIS to manage airport data

Konferenssin kaikki puheenvuorot (joiden esiintyjät ovat antaneet luvan tallentamiselle) löytyvät yhdestä soittolistasta, johon pääset tästä. 

Kuumimmat puheenaiheet

Ensimmäisen päivän keynote johdatteli monen ajatukset tiedon visualisointiin, kun puhujana oli Visualiseringscenter C:n johtaja Anders Ynnerman. Norrköpingin Visualiseringscenter C toimi konferenssin yhteistyökumppanina tarjoten inspiroivia tiloja ja mielenkiintoisia puheenaiheita. Visualiseringscenter C on usean toimijan konsortio, joka tutkii ja kehittää visualisointiteknologioita sekä näyttää yleisölle ja etenkin lapsille ja nuorille tietoa mielenkiintoisesti ja osallistavasti visualisoituna. 

Visualiseringscenter C:n myötä Norrköpingistä on luotu varsin kattava ja yksityiskohtainen digitaalinen kaksonen. Digikaksonen on ollut pöhinäsana jo jonkin aikaa, ja tämä näkyi myös konferenssissa ja tulevissa kehityssuunnitelmissa. QGISin työkaluja 3D-aineistojen ja digitaalisten kaksosten käsittelyyn halutaan parantaa. 

Toinen ohjelmassa ja keskusteluissa näkynyt isompi teema oli siirtymät avointen teknologioiden käyttöön. Ruotsin ilmatieteenlaitos SMHI (Sveriges meteorologiska och hydrologiska institut) on siirtynyt käyttämään avoimen lähdekoodin paikkatietoteknologioita. Rasmus Ewehag kertoi keynote puheenvuorossaan SMHI:n siirtymästä, missä oli tunnistettavissa paljon samaa kuin meillä Suomen Ympäristökeskuksen avoimessa siirtymässä. Ruotsin julkisen sektorin organisaatioissa on selvästi kiinnostusta avoimen lähdekoodin paikkatietoteknologioihin. SMHI:n siirtymän myötä moni on käynyt kyselemässä sen kokemuksia. Myös Suomen kokemukset kiinnostivat Ruotsissa: Maanmittauslaitoksen uusi avoimeen lähdekoodiin perustuva maastotietojen tuotantojärjestelmä keräsi huomiota, ja etenkin ruotsalaisten kuntien edustajat kyselivät Gispolta, miten kunnat Suomessa käyttävät QGISiä.

Ennakkoon odotimme, että lähestyvä QGIS 4.0 -julkaisu olisi ollut keskeisesti esillä ja keskusteluissa. Näin ei kuitenkaan ollut, mikä johtuu ehkä siitä että puheenvuoroehdotukset on pitänyt jättää jo hyvissä ajoin, ja silloin 4.0:sta on tiedetty hyvin vähän. Ensi vuoden QGISUser conferencessa tilanne on varmasti toinen. Kesällä 2026 QGIS User Conference järjestetään muuten Sveitsissä. 

Mitä jäi mieleen, mitä opimme?

Viisihenkinen delegaatiomme koostui osaamiseltaan ja kokemukseltaan erilaisista gispolaisista. Niinpä kysymyksiin mitä opit ja mikä jäi päällimmäisenä mieleen, tuli tiimiltämme hyvin erilaisia vastauksia. 

Juho ja Eemil kasvattivat osaamistaan QFieldin ja QFieldCloudin parissa. Eemil sai oppeja myös toisesta mobiilisovelluksesta Mergin Mapsista. Molemmat kävivät oppimassa uutta QGIS Actioneista. Juho pääsi tapaamaan ihmisiä, joiden kanssa on tehnyt yhteistyötä vain etänä. 

Merille jäi päällimmäisenä mieleen mielenkiintoiset lounaspöytäkeskustelut. Satunnaiseen seuraan istuessa ja kysyessä, mitä teet, sai joka kerta kuulla jotain mielenkiintoista sähköautojen latausasemien sijoittamisen suunnittelusta tai avoimen paikkatiedon turvallisuudesta tai jostain muusta. Marille jäi päällimmäisenä mieleen SMHI:n avoin siirtymä, mutta myös QGIS-yhteisö puolalaisen QGIS user groupin muodossa. Uusia oppeja Mari sai QFieldin käystöstä vesiasioiden käsittelyssä sekä pistepilvien käsittelystä QGISissä. 

Tämä oli meille kaikille ensimmäinen kerta QGIS User Conferencessa. Aiemmin olemme osallistuneet FOSS4G tapahtumiin, joten näiden tapahtumien luonnetta tuli vertailtua. Pekka pohti, että QGIS User Conferencessa on enemmän käyttäjiä sekä puhujissa että osallistujissa, kun taas FOSS4G-tapahtumissa on enemmän kehittäjiä. Norrköpingissä yllätti miten vähän osallistujissa oli suomalaisia. Esityksiä ja rinnakkaissessioita oli paljon, mutta tuntui että suunnilleen kaikki erityisen kiinnostava meni päällekkäin. 

Kehitystä ja kehityssuuntia

QGIS-yhteisön ollessa koolla keskustelua käytiin QGISin kehittämisen suunnista. Uusi versiojulkaisu ja siirtyminen QGIS 4.0:aan tuo muutoksia pellin alle QGISin siirtyessä Qt6:seen, mutta kuten todettu tästä käytiin keskustelua varsin vähän. Muutos tulee vaikuttamaan ainakin joidenkin lisäosien toimintaan. 

Yhteisessä paneelikeskustelussa QGISin kehityssuunnista nousi erityisesti kaksi teemaa; käyttöliittymä ja FME. Yhteisö tuntuu olevan samanmielinen siitä, että QGISin käyttöliittymää pitäisi raikastaa ja kehittää modernimmaksi. Mitä tämä modernius tarkoittaa, onkin sitten eri asia. Osa tuntui ajattelevan ribbon-tyylistä työkalupalkkia ja villimmässä keskustelussa pohdittiin ääniohjattavuutta.

FME (Feature Manipulation Engine) tuntuu olevan paikkatietoarkkitehtuurissa pala, jota on vaikea ellei mahdoton korvata avoimen lähdekoodin ratkaisulla. SMHI:n siirtymässä tämä työkalu oli ainoa jäänyt kaupallinen tuote. Keskusteluissa nousi esiin voisiko QGIS tehdä ETL-prosessissa sen, mitä FME tekee. QGISin graafinen mallintaja on käyttöliittymältään jo samankaltainen kuin FME, ehkä siihen voisi kehittää lisää aineiston muuntamiseen liittyviä ominaisuuksia. Isona haasteena tässä suunnitelmassa ovat suljetut formaatit ja niiden käsittely.

Konferenssin jälkeen viikko jatkoi kehittäjien tapaamisella. Kehittäjätapaamisessa osallistujia oli selvästi vähemmän kuin konferenssissa, noin 50 ilmoittautunutta. QGISin ydinkehittäjiä tunteville nimilistaa voisi kuvata termillä “usual suspects”. Kehittäjätapaamisessa kehittäjät jakaantuivat pienryhmiin sen perusteella, mitä itse kukin halusi tehdä ja lähtivät kehittämään. Ajatuksena kehittäjätapaaminen on hyvin yhteisöllinen tapahtuma, mutta tällä kerralla yhteiskehittäminen jäi hieman ohueksi. Vaikka kehittäjät tekivät pääasiassa itsekseen, yhteen kokoontuminen mahdollistaa uusien kehittäjien perehdyttämisen mukaan ja kun naamat tulevat tutuiksi myös myöhemmin yhteiskehittäminen on helpompaa.

Loppusanat

Norrköpingin QGIS User conference oli antoisa, ja antoi eritasoisille QGIS-käyttäjille mahdollisuuden oppia uutta. Osallistujissa oli paljon julkisten organisaatioiden edustajia, tutkijoita, opettajia ja kehittäjiä. Yritysten edustajat olivat vähemmistössä, varsinkin yritysten QGIS-käyttäjiä oli kovin vähän. Tämä heijastui myös ohjelmaan, jossa käyttäjäorganisaatioiden näkökulmaa ja todellisia käyttäjätapauksia oli vähemmän, samoin enterprise-GIS ei juurikaan ollut esillä. Toisaalta esitystarjonnassa oli myös vähemmän teknisiä esityksiä kuin FOSS4G-tapahtumissa on tavannut olla. 

Voimme lämpimästi suositella QGIS User Conferenceen osallistumista, tyhjin käsin sieltä ei varmasti tarvitse lähteä kotiin. Seuraavan UC:n ollessa Sveitsissä matkalaukkuun päätyy varmasti juustoa ja suklaata – uusien oppien lisäksi tietysti. 

Alkuvuodesta aloitimme Gispon omat webinaarit, jotka tietysti nimesimme Gisponaareiksi! Gisponaarien aiheina on avoimen lähdekoodin paikkatieto-ohjelmistojen uusia tuulia ja avoimen datan ajankohtaisia käyttömahdollisuuksia. Kerromme ja demoamme ensin, ja lopuksi on tilaa kysymyksille ja keskustelulle. Toivomme, että Gisponaareista muodostuu mukavia keskustelevia tilaisuuksia, joissa on mahdollista kuulla ja jakaa erilaisia kokemuksia teeman ympärillä.

Syksyn ensimmäisessä Gisponaarissa torstaina 28.8. on aiheena kehitteillä oleva kaavoitustyökalu Arho (Avoimen lähdekoodin kaavoituksen Ryhti-sovellus) ja Ryhti-muotoisen kaavan tuottaminen QGISillä. Gispo on parhaillaan mukana kahdessa ympäristöministeriön rahoittamassa Ryhdin kumppanitestaushankkeessa, joissa kehitämme avoimen lähdekoodin kaavoitustyökalua. Sanna kirjoitti aiheesta blogiin toukokuussa. Tervetuloa Gisponaariin kuulemaan, missä Arhon kehityksessä mennään, ja miten Ryhti-muotoista kaavoitusta tulevaisuudessa tehdään QGISillä ja Arholla.

Elokuun Gisponaari järjestetään 28.8. klo 14.15 eli sopivasti iltapäiväkahvien jatkeeksi. Ilmoittaudu mukaan tästä.