Uusi QGIS 3.40 LTR-versio julkaistaan helmikuun aikana. QGIS 3.40 sisältää kymmenittäin uusia ominaisuuksia ja parannuksia, ja ohjelmistovirheitä eli bugeja on korjattu useita satoja edellisen LTR-version jälkeen. Tämä on pääsyy siihen, miksi suosittelemme käyttämään aina uusinta LTR versiota QGISistä – se on vakain ja suorituskykyisin. LTR tulee sanoista Long Term Release ja viittaa pidempään tuettuun ja vakaaseen versioon ohjelmistosta. Tässä blogissa sukellamme uuden LTR-version uusiin ominaisuuksiin.

Uudessa LTR-versiossa on mukana kaikki edellisen LTR-version jälkeen ilmestyneiden ohjelmistoversioiden uudet ominaisuudet ja toiminnot. Ohjelmisto kehittyy joka julkaisun myötä, ja kehityksessä voi olla hankala pysyä kärryillä. Siksi olemme Gispolla keränneet tähän artikkeliin (mielestämme) tärkeimmät ja hyödyllisimmät uudet ominaisuudet ja toiminnallisuudet. QGIS-versioiden kaikki uudet ominaisuudet kirjataan muutoslokeihin, joiden linkit keräsimme alle, näiden kautta pääsee tutustumaan kaikkiin ohjelmiston päivityksiin:

Käyttöliittymän parannuksia

QGISin käyttöliittymä on säilynyt pääosin tuttuna ja turvallisena, mutta siihen on tullut joitakin pieniä ja näppäriä parannuksia. Tässä muutama kokeilemisen arvoinen:

Hiiren keskinäppäin aukaisee Lausekkeen muokkaajan/Expression builderin.
Kohteeseen liittyvät relaatiot näkyvät nyt Kohteen tiedot- taulussa
Uudet toiminnot ”Luo tietokanta” ja ”Luo tietokanta ja taso” on lisätty tarjoamaan selkeämpiä ja yhtenäisempiä vaihtoehtoja tietokantojen luomiseen.
Selaimen yhteyksien monistaminen. Tämä helpottaa, jos käytössä on useita samantapaisia yhteyksiä, sillä monistetuista yhteyksistä voi vain vaihtaa parametrit eikä kaikkia tietoja tarvitse syöttää uudelleen.
Mahdollisuus uudelleenjärjestää kentät luotaessa uutta vektoritasoa. Esimerkiksi GeoPackagea luodessa kenttiä voi järjestää itse eikä kenttien järjestystä tarvitse miettiä jo niitä syöttäessä.
Selainpaneelissa on mahdollisuus lisätä yhteydet pilvitallennuspalveluntarjoajiin
Käyttäjä voi merkitä tärkeimmät prosessointityökalut suosikeiksi, jolloin ne löytyvät aina nopeasti.
Ominaisuustietotaulukon sarakkeiden leveys on mahdollista asettaa määräytymään automaattisesti, jolloin taulukon avatessa sarakkeiden leveys säätyy automaattisesti taulukon sisällön mukaan, ja on siten luettavampi.

Vektoritasojen uusia ominaisuuksia

Yksi maanmittauksen kannalta oleellinen ominaisuus, joka on puuttunut QGISistä tähän asti, on korkeuskoordinaattijärjestelmän valinta. Uudessa QGIS 3.40 versiossa voit valita korkeusjärjestelmän jokaiselle tasolle erikseen (Tason ominaisuudet → Korkeus). Kun korkeusjärjestelmät on valittu tasoille niin esimerkiksi 3D näkymät, kohteen tiedot -työkalun tulokset ja korkeusprofiilit näkyvät oikein. Tämän ominaisuuden myötä on mahdollista määritellä myös tarkemmin, miten korkeusjärjestelmä kiinnitetään ja sidotaan korkeusprofiiliin (ks. kuva alla). Tarkemmin tästä ominaisuudesta kerrotaan täällä.

QGIS 3.40 uusi ominaisuus: korkeuskoordinaattijärjestelmä

Jo aiemmin tason datasta on voinut tehdä erilaisia diagrammeja, mutta vaakapalkkikaaviot ovat uupuneet. Nyt ne ovat tulleet QGISin diagrammivalikoimaan, ja esimerkiksi väestöpyramidien luominen on nyt mahdollista suoraan QGISilla

QGIS 3.40 sisältää vaakapalkkikaaviot, joiden avulla voi tehdä vaikka ikäpyramidin

Rasteritasojen uusia ominaisuuksia

Ehkä suurimmat muutokset ovat tulleet rasteritasoille. Isoimmat muutokset ovat korkeustietojen määrittelyissä ja asetuksissa. Rastereille voi nyt suodattaa korkeustietoja eli voit valita, mikä korkeustaso näkyy rasteritasolla. Tästä on hyötyä esimerkiksi tulvamallinnuksissa. Sama ominaisuus löytyy myös kanaville, ja kanavakohtaisesti on mahdollista säätää näkyviin tietty korkeusalue.

Toinen merkittävä ominaisuus on dynaaminen aikasäädin. Pikselin arvon voi määrittää temporaaliseksi päiväykseksi. Pikselit häviävät näkyvistä, kun ne ovat arvon ulkopuolella. Tästä on hyötyä esimerkiksi

esityksessä maankäytön muutoksista kuten metsien häviämisestä
tulvien esittämisessä ajan mittaan
liikkumiskustannusten esittämisessä (esim. GRASS’ r.walk)

Rasteritasojen hallintaa helpottaa jatkossa myös, että tyyliluokat ovat käytössä myös rasterikarttatasoille (aiemmin vain vektoritasoille). Voit siis kätevästi kopioida rasteritason tyyliluokat ja liittää ne toiselle rasteritasolle. Myös rasteriluokkien tallennus onnistuu tyylitiedostoksi.

Päivitykset kuvaustekniikkaan

Peruskäyttäjän näkökulmasta yksi näkyvimmistä uusista ominaisuuksista on päivitykset symbologiaan. Niitä on kaiken kaikkiaan useita. Esimerkiksi viiva- ja aluetasoille on tullut uusi symbolitaso “Linear referencing”, suomennettuna Lineaarinen referointi, jolla tarkoitetaan epäsuoran sijainnin ilmaisutapaa, jossa sijainti ilmaistaan etäisyytenä tunnettua käyrää pitkin. Esimerkiksi jos tielinjalle halutaan tasaisin välein mittalukuja (paalulukuja) tien alkupisteestä, niin silloin tämä symbolitaso on juuri oikea työkalu. Lineaarinen referointi perustuu 2D-pituuksille. Myöhemmin on mahdollisesti tulossa vielä ominaisuus 3D-pituuksille.

QGIS 3.40 sisältää viiva ja aluetasoille symbolitason “Linear referencing”

Muita uutuuksia kuvaustekniikassa ovat muun muassa:

Kun symboli täytetään rasterikuvalla, kuvan korkeutta ja leveyttä on mahdollista säätää.
Viivoille on tarjolla uusi tyyppi: täytetty viiva. Viivan voi täyttää millä tahansa täyttösymbolilla.
Uusi yksivärinen piirto rastereille. Rasteritaso on mahdollista renderöidä yksivärisenä.
Wind Barb (tuulen suunta) -piirto mesh-vektoriaineistoille. Mesh-tasoja voi nyt visualisoida kuvaamaan vaihtuvaa tuulen suuntaa ja voimakkuutta.
Näytä värirampin selitys vektorilämpökartan tasoille. Aikasemmin tasot -paneelissa ei näkynyt selitettä, nyt se näkyvissä.
loppupistesymbolit osoitinviivaan puhekuplasymboleille ja pistesymboleille bufferit (ks. kuva alla)

Nimiöiden sijoittelun uudet ominaisuudet

Kun karttakohteille annetaan nimiöt, on mahdollista asettaa projektikohtaisia nimiöintisääntöjä, jotka vaikuttavat nimiöiden automaattiseen sijoittumiseen. Tähän on tullut uusia sääntötyyppejä, ja käyttäjä voi nyt ohjata nimiöiden sijoittumista neljällä erilaisella sääntötyypillä. Näillä voi estää päällekkäisyyksiä, vetää nimiöt kohteiden lähelle tai työntää ne kauemmaksi kohteista tai toisista nimiöistä.

Pistetasojen nimiöinti on saanut uuden asetuksen, ja nyt on mahdollista asettaa maksimietäisyys kohteesta nimiöön. Tämä asetus on saatavilla, kun nimiöiden sijoittamisen tilaksi on valittu kartografinen tai pisteen ympärillä. Tämän asetuksen kanssa on siis mahdollista hallita, kuinka kauaksi nimiö voi kohteesta joutua, mikä auttaa luomaan luettavampia karttoja.

Kun QGISin pisteen nimiöiden sijoittamisen tilaksi on valittu kartografinen, voi nimiöiden sijoittumisen prioriteettia ohjata “position priority” -asetuksella. Tähän toimintoon on tullut uusi valinta “over point” (O) pisteen päällä, jonka avulla voidaan siis jatkossa määritellä onko nimiön sijoittuminen pisteen päälle ensisijainen vai viimeinen toivottava sijainti.

Taiton uudet ominaisuudet

Myös QGISin Taitto-työkalu on saanut uusia ominaisuuksia ja toiminnallisuuksia. Rasteritasojen uusissa ominaisuuksissa mukana oleva korkeusalueen mukainen suodatus on käytössä myös Taitto-työkalussa. Jatkossa on siis mahdollista valita taiton puolella, mitkä korkeusarvot näkyvät tulosteessa.

Aiemmin hieman hankalasti löydettävä sivun asetukset on nyt lisätty taitto-ikkunan päävalikkoon Taitto-osion alle. Toinen pieni mutta käyttäjän hermoja säästävä ominaisuus on kaksi painiketta, joilla selitteen asetuksissa saa laajennettua tai suljettua kerralla kaikki karttaselitteen lukuisat tasot, ryhmät ja luokat .

Mittakaavajana kuuluu perinteisesti jokaiseen karttaan. Maantieteilijän sielua lämmittää uusi ominaisuus, jossa käyttäjä voi valita, miten mittakaava lasketaan, tai tarkemmin sanottuna, mistä kohtaa karttaa mittakaava lasketaan. Mittakaava voidaan laskea karttakehyksen alareunasta, keskeltä tai yläreunassa, tai näiden kolmen mittauksen keskiarvona.

QGISiä kehittämässä

Me Gispolla olemme myös olleet mukana uusimpien QGIS versioiden kehittämisessä – kiitos Maanmittauslaitoksen yhteisprojektin! Uuteen QGIS-versioon on tulossa peräti kolme Gispon kehittämää uutta ominaisuutta, jotka liittyvät digitointityökaluihin ja attribuuttien hallintaan.

Attribuuttitietojen säilyminen, kun geometria jaetaan

Kun kohde jaetaan kahteen osaan, alkuperäisen kohteen attribuutti- eli ominaisuustiedot säilyvät jaetun kohteen suuremmassa osassa. Tämä toiminnallisuus parantaa kohteiden hallintaa ja varmistaa, että alkuperäisen kohteen attribuutit säilyvät parhaalla mahdollisella tavalla.

Attribuuttien oletusarvojen päivittyminen kohteita yhdistettäessä

Kohteita yhdistettäessä attribuuttien oletusarvot päivittyvät nyt välittömästi. Tämä tarkoittaa, että kun yhdistetään kohteita, joiden attribuuteille on asetettu tietokantaan oletusarvoja, nämä arvot päivittyvät heti ilman viivettä. Tämä tehostaa työskentelyä, vähentää virheiden mahdollisuutta ja parantaa siten datan laatua.

Ennen:

Nyt:

Taitepiste-työkalu lisää topologiset pisteet kaikille muokattaville tasoille

Taitepiste-työkalu lisää nyt topologiset pisteet kaikkille muokattaville tasoille. Tämä tarkoittaa, että kun muokattavana on päällekkäisiä segmenttejä eri tasoilla, pisteet lisätään vastaavasti kaikille muokattaville tasoille. Tämä parantaa topologian hallintaa ja vähentää virheiden mahdollisuutta mutkikkaammissa muokkaustilanteissa.

qgis

Lopuksi

QGISissä ehtii tapahtua paljon kahden LTR-version välillä, ja uusissa ominaisuuksissa ja toiminnallisuuksissa voi olla haastavaa pysyä mukana. Yksi asia, joka ei ole pysynyt uusissa ominaisuuksissa mukana, on QGISin suomenkielinen käännös, mikä näkyy selvästi tämän artikkelin kuvakaappauksissa. Me Gispolla teemme QGIS käännöksiä talkootyönä, joten jos tiedät sopivat termit esitellyille uusille vielä kääntämättömille ominaisuuksille, kerro meille ja me huolehdimme käännökset ohjelmistoon!

Jäivätkö QGIS 3.40 LTR:n uudet ominaisuudet vielä hämäriksi? Me esittelemme esittelemme näitä uutuuksia ensimmäisessä Gisponaarissa (= Gispon webinaari) torstaina 6.3. klo 14.15. Lue lisää Gisponaareista ja ilmoittaudu mukaan.

Kenttätyöskentelyssä on nykypäivänä hyödynnettävissä käteviä erilaisia avoimen lähdekoodin ohjelmia, jotka helpottavat ja sujuvoittavat tiedon keräämistä. Mergin Maps ja QField ovat QGISin kanssa yhteentoimivia mobiilisovelluksia, joita kehitetään jatkuvasti. Myös me Gispolla olemme osallistuneet QFieldin kehittämiseen. QField ja Mergin Maps ovat saaneet päivityksiä ja uusia ominaisuuksia sitten edellisen blogikirjoituksen vuodelta 2023.

QFieldin uudet ominaisuudet

QFieldistä on julkaistu uusi versio 3.4.0, joka kantaa nimeä QField Ebo. QFieldin uudessa versiossa on muun muassa uusia algoritmeja, joiden avulla voi hallita digitoituja geometrioita suoraan kentällä, ja ja varmistaa piirrettyjen rakennusten suorakulmaisuus lukitsemalla digitointi ennalta määritettyihin kulmiin. Näiden lisäksi QFieldiin on tullut Geoaita-ominaisuus (eng.Geofencing), jonka ansiosta käyttäjää varoitetaan, jos hän yrittää kerätä tietoja ennalta määritellyn alueen ulkopuolelta. Lisänä mainittakoon, että QFieldin mobiilisovelluksesta voi myös saada suoraan PDF-tulosteen tehdystä projektista.

Mergin Mapsin uudet ominaisuudet

Mergin Maps on saanut käyttöliittymälleen kokonaan uudistetun ulkoasun! Uudistuksia on tullut myös muun muassa sovelluksen räätälöintiin organisaatiokohtaisesti, tuettuja tiedostomuotoja on lisätty ja työtiloja on nyt mahdollista hallita paremmin esimerkiksi projektissa, joka jakautuu useammille tiimeille.

Erot ominaisuuksissa

Vertailimme Mergin Mapsin ja QFieldin välisiä eroja ja yhtäläisyyksiä, ja koostimme tulokset alla olevaan taulukkoon.

Sovellus	Mergin Maps	QField
Tuetut käyttöjärjestelmät	Android, iOS, Windows	Android, iOS, Windows
Tuetut tiedostomuodot	GeoPackage, Delimited Text, Shapefile, PostGIS, Virtual Layer, WMS, WFS, MBTiles, XYZ-Tiles, GeoTIFF, JPEG, PNG, COG, GeoPDF.	GeoPackage, Delimited Text, Shapefile, PostGIS, SpatiaLite, WMS, WFS, MBTiles, WFS-T, Tiff, JPEG2000, WEBP, COG
Tiedontallennus	Online/Offline tai USB-kaapeli	Online/Offline tai USB-kaapeli
Mahdollisuus omille lisäosille	Ei	Kyllä
Sensorit	Ei	Kyllä
Valikoiva synkronointi	Kyllä, kansiokohtaisesti voi määrittää mitä synkronoidaan	Kyllä, voi synkronoida joko kaikki tai vain paikalliset tiedostot
Kuvien tiedostokoon muokkaus	Neljä valintaa: Original, High (2-4mb), Medium (1-2 mb), Low (0.5 mb)	Voi määrittää maksimikoon kuvalle
Edistynyt työtilojen hallinta	Kyllä	Ei
Mediatiedostojen synkronointi omaan tietokantaan	Kyllä	Ei erillistä työkalua
ArcGIS yhteensopiva	Kyllä	Ei
White-labeling*	Kyllä	Ei tiedossa

* Yritys antaa mahdollisuuden tehdä tuotteesta oman version puhelimen sovelluskauppaan ja julkaista sen omalla nimellä

Tarkemmin tarkasteltuna sovellusten keskeisimpänä erona on QFieldin tuki lisäosille, joka antaa käyttäjälle mahdollisuuden lisätä sovelluksen toiminnallisuuksia ja tehostaa käyttöä joko itse tehdyillä tai muiden tekemillä lisäosilla. QFieldille tehtyjä lisäosia on listattu tänne. Lisäosien avulla sovellus on mahdollista räätälöidä juuri omiin tarpeisiin sopivaksi. Toinen merkittävä ero sovellusten välillä on, että QField tukee erillisiä sensoreita. Näin on mahdollista kerätä anturitietoja aktiivisesti taustalla, näyttää kerätyt tiedot ja tallentaa ne uusiin digitoituihin kohteisiin. Tuetuissa tiedostomuodoissa nostamme esiin QFieldin tuen WFS-T -rajapinnalle. Jos virtuaalitasojen käsittely on tärkeää, niin Mergin Maps soveltuu niiden pyörittelyyn paremmin, esimerkiksi kun halutaan luoda näkymiä QGISissä hyödyntäen SQL-lausekkeita.

Kuvia sovellukset käsittelevät hieman eri tavalla. QFieldissä on mahdollisuus määrittää maksimikoko (leveys ja korkeus) kuvalle, kun taas Mergin Mapsissa kuvia voi pakata neljällä eri luokittelulla: Original, High (2-4mb), Medium (1-2 mb), Low (0.5 mb). Tämän lisäksi Mergin Mapsissa on mahdollista synkronoida mediatiedostot media-sync -toiminnolla erilliselle palvelimelle kuten Amazon S3:seen. QField tallentaa kuvat laitteelle, tai pilvipalvelu QFieldCloudiin, mikäli sellainen on otettu käyttöön.

Erot työkaluissa

Paikkatietoja kerätessä ja geometrioita digitoidessa on merkitystä, mitä työkaluja sovelluksessa on tarjolla. Alla olevassa taulukossa vertailemme Mergin Mapsin ja QFieldin työkaluvalikoimaa.

Sovellus	Mergin Maps	QField
Geoaita	Ei	Kyllä
Korkeusprofiili	Ei	Kyllä
Digitointityökalut	Jaa geometria Piirrä geometria uudelleen Nauhoitus/Tracking	Jaa geometria Uudelleen muotoile kohde Muokkaa pyyhekumityökalu Reikien digitointi Attribuuttien monimuokkaus Nauhoitus/Tracking
Tartunta	Kolme valintaa: Ei tartuntaa, Perustartunta, noudata QGISin tartuntaa (tarttumisen työkaluja)	Kolme valintaa: solmupisteisiin, segmentteihin, solmupisteisiin ja segmentteihin Lisäksi mahdollisuus tarttua yleisimpiin kulmiin

Sovellusten työkaluvalikoimaa vertailemalla voimme todeta, että QField on parempi valinta, kun on tarve tehdä edistyksellisimpiä paikkatieto-analyysejä tai esimerkiksi edistyksellisempää digitointia tarttumisen työkalujen avulla. Mergin Mapsissa ei ole näin kattavaa valikoimaa työkaluja, mutta se tekee toisaalta käyttöliittymästä yksinkertaisemman, ja Mergin Maps voikin olla parempi valinta, jos maastosta tietoa keräävillä, ei ole juurikaan paikkatieto-osaamista.

Käyttöliittymät

Vaikka molemmat sovellukset ovat periaatteessa melko samanlaisia, on niissä kuitenkin eroja käyttöliittymiä myöten. QFieldin käyttöliittymä on rakennettu tila-pohjaisesti eli voit olla joko katselutilassa tai muokkaustilassa, kun taas Mergin Mapsissa muokkaukset tapahtuvat suoraan kohteen tiedoista. QField on enemmän kuin QGIS taskukoossa, mikä näkyy muun muassa siinä, että asetuksia voi säätää suoraan sovelluksessa ja valintoja voi tehdä paljon tasokohtaisesti. Esimerkiksi pitkät painallukset tasojen päällä tuovat lisää ominaisuuksia käyttöön tasokohtaisesti. Voit esimerkiksi sallia nimiöt vain tietyllä tasolla ja määrittää lennosta peittävyyttä. Mergin Mapsissa taas kaikki nämä tarkemmat määrittelyt tehdään työpöytäsovelluksen puolella, kuten myös tartuntatilan määrittelyt.

Mergin Maps on optimaalisempi käyttäjille, joilla ei ole aiempaa kokemusta QGISista tai paikkatietomobiilisovelluksista. Sovelluksessa itsessään ei ole niin paljon ominaisuuksia ja valintoja, mutta monet valinnat voidaan asettaa jo ennakkoon QGISin puolella, kuten nimiöintien ja tasojen näkyvyys. Mergin Maps -mobiilisovellusta voisi siis luonnehtia intuitiivisemmaksi ei-teknisille käyttäjille, ja sen käyttöliittymä on QFieldiä helpompi omaksua.

Web-käyttöliittymiä verrattaessa Mergin Mapsin web-käyttöliittymä on aavistuksen monipuolisempi ja siellä on käytössä web-kartta, eli QGISiä ei välttämättä tarvita ollenkaan, jos työnjohto haluaa vain tarkastella, mitä kohteita projektiin on kerätty. Historiatietojen hallinta ja palauttaminen Mergin Mapsissa on myös yksinkertaisempaa ja paremmin hallittavissa. Muutoin perusominaisuudet ovat selain/web-käyttöliittymässä samanlaiset. Katso videolta (avautuu uuteen ikkunaan) demonstroituna Mergin Mapsin käyttöliittymän perustoimintoja.

Seuraavassa klipissä on demonstroitu QFieldin perustoimintoja.

Pilvipalveluista helppoutta projektien ja datan siirtoon

QFieldCloud on QFieldin kanssa verkon yli toimiva synkronointialusta. Se mahdollistaa QFieldillä luodun datan saumattoman synkronoinnin ja jakamisen. QFieldCloud perustuu PostgreSQL- ja PostGIS-tietokantoihin, ja sen voi ostaa valmiina pilvipalveluna tai pystyttää itse.

Myös Mergin Maps tarjoaa käyttöä helpottavan pilven, johon voi tallentaa dataa ja projektin ja avata sen vuorostaan vaikka QGISissä Mergin Mapsin oman QGIS-lisäosan kautta. Myös Mergin Mapsin pilvi on mahdollista ostaa palveluna tai pystyttää itse.

Molempiin sovelluksiin on siis tarjolla synkronointialusta. Kokosimme taulukkoon vertailun Mergin Mapsin pilvipalvelun ja QFieldCloudin ominaisuuksista ja hinnoittelusta (tiedot päivitetty 22.5.2025).

	Mergin Maps	QField Cloud
	Premium	Community	Pro	Organization
Hinta / käyttäjä	15,80 € / tiedontuottaja Rajoittamaton määrä käyttäjiä, joilla vain lukuoikeus	Ei rajattu, mutta tallennustila rajallinen	12 €/käyttäjä* 15 €/käyttäjä	16 €/käyttäjä* 20 €/kuukausi
Tallennustila	1 Gt / tiedontuottaja	100 Mt	1 Gt**	1 Gt**
Versio historia / Tiedostoversiot	Ei rajoitettu	3 versiota	10 versiota	10 versiota
Ilmainen koekäyttö	28 päivää	Täysin ilmainen		28 päivää
Hinta	15,80 €/kk	ilmainen	12 €/käyttäjä* 15 €/käyttäjä 6 kk jälkeen	16 €/käyttäjä 20 €/käyttäjä 6 kk jälkeen

* Ensimmäiset 6 kk mahdollisuus käyttää EarlyBee hintaan.
** Lisää tallennustilaa ostettavissa, 5 €/kk 1 Gt

Ostettu palvelu vai oma pilvi?

Molemmat synkronointialustat on siis mahdollista ostaa pilvipalveluna tai pystyttää itse, sillä avoimen lähdekoodin ohjelmistoina sekä Mergin Mapsin että QFieldin synkronointialustat on mahdollista pystyttää omalle palvelimelle, nk. on-premises ratkaisuna. Kumpi sitten valita? Valmiina ostetun palvelun merkittävä etu on helppous, mutta keskeiseksi kysymykseksi nousee, kuinka arkaluonteista kerättävä data on. Molemmissa palveluissa on omat suojauksensa, mutta on kaikkea tietoa ei yksinkertaisesti voi säilyttää kolmannen osapuolen tietokannassa.

Avoimen lähdekoodin hienouksia on, että palvelun voi pystyttää itselleen haluamallaan tavalla ja haluamaansa paikkaan. Näin sekä QFieldCloudin että Mergin Mapsin cloudin voi liittää osaksi omaa IT-infrastruktuuria ja vapautua näiden palveluiden kuukausimaksuista, sekä tallennustilaa, versiohistoriaa ja käyttäjämääriä koskevista rajoituksista. Oman instanssin pystyttäminen vaatii kuitenkin osaamista ja paljon suuremman alkupanostuksen.

QField vai Mergin Maps?

Puhtaasti paikkatiedon mobiilisovellusta valitessa molemmissa sovelluksissa on vahvuutensa ja erityistoimintonsa, joita voi soveltaa moniin eri tarkoituksiin. Molemmista löytyy erilaisia toimintoja ja päivitettyjä ominaisuuksia, joten valinta voi olla vaikea. Toisaalta molemmat ovat hyviä työkaluja paikkatiedon mobiilikeruuseen, joten väärin on vaikea valita.

Mergin Mapsin yksinkertaisemman käyttöliittymän ansiosta se on oiva valinta sellaiseen organisaatioon, jolla on kenttätyöskentelyssä paljon henkilöstöä, joilla ei välttämättä ole runsaasti paikkatieto-osaamista, sillä Mergin Mapsin käyttöönotto on helpompaa, lisäksi Mergin Mapsin Work packages -työkalu mahdollistaa projektin jakamisen pienemmille tiimeille synkronoinnin vaarantumatta.

QField on oikea valinta, kun tarvitaan monipuolisia digitointityökaluja sekä tartuntatyökaluja. QField on oiva valinta myös silloin, kun on tarve käsitellä suuria kuvatiedostoja.

Sovelluksen valintaan kannattaa siis käyttää hetki, ja punnita sovellusten ominaisuuksien, työkalujen ja palveluiden erot. Mutta kuten todettu, täysin väärää valintaa on vaikea näistä vaihtoehdoista tehdä. Molempia on myös helppo kokeilla ennen lopullisen valinnan tekoa.

Gispo järjestää koulutusta QFieldin ja Mergin Mapsin käyttöön, voit myös kysyä tarpeisiisi sopivaa koulutusta osoitteesta koulutus@gispo.fi. Lisäksi autamme mielellämme muissakin paikkatiedon mobiilikeruuseen liittyvissä asioissa info@gispo.fi!

Tutustu myös aiempiin projekteihimme:

Tämän artikkelin on kirjoittanut Anni Jusslin

Paikkatietoyhteisön suurin kipupiste on, että paikkatiedon valtavaa potentiaalia ei ole teknologisista syistä pystytty hyödyntämään täysimääräisesti. Teknologia kuitenkin kehittyy jatkuvasti ja nyt meillä on (taas) uusi mahdollisuus tehostaa paikkatiedon käyttöä. Olen erityisen innostunut digitaalisista kaksosista, koska niiden avulla paikkatiedon potentiaali voidaan avata laajemmalle käyttäjäkunnalle. Ne tuovat paikkatiedon pois siiloutuneista prosesseista, joissa se jää usein vain erityisasiantuntijoiden hallintaan. Näin paikkatiedon hyödyt voidaan vihdoin ottaa käyttöön täysimittaisesti.

Digitaalisille kaksosille on olemassa monia määritelmiä, mutta itse näen niiden olevan enemmän kuin pelkkiä passiivisia kopioita fyysisestä maailmasta. Niiden todellinen arvo syntyy ennakoivista analyyseistä ja päätöksenteon tukemisesta.

Avoimen lähdekoodin paikkatietoteknologiat ovat keskeisiä työkaluja digitaalisten kaksosten rakentamisessa ja räätälöinnissä. Digitaaliset kaksoset tarjoavat merkittävää lisäarvoa eri toimialoille, mutta niiden hyödyntäminen edellyttää usein sektorikohtaisesti räätälöityjä ratkaisuja. Kaupunkisuunnittelun, liikenteen hallinnan, väyläinfran ja puolustushallinnon tarpeet ovat kaikki erityispiirteiltään niin erilaisia, että jokaiselle sektorille on rakennettava sen tarpeita vastaava digitaalinen kaksonen.

Digitaaliset kaksoset visualisoidaan usein 3D-muodossa. Kuvan visualisoinnissa on hyödynnetty avoimeen lähdekoodin pohjautuvaa MapStore-teknologiaa.

Digitaalisten kaksosten soveltaminen eri aloilla

Digitaalisia kaksosia kehitetään muun muassa kaupunkisuunnitteluun ja liikenteen hallintaan, joissa ne tarjoavat reaaliaikaisen näkymän kaupunki- ja liikenneinfrastruktuuriin. Väyläinfran hallintaan räätälöidyt digitaaliset kaksoset auttavat valvomaan tieverkostojen kuntoa keräämällä reaaliaikaista dataa ja hyödyntämällä ennakoivia analyysejä, jotka mahdollistavat esimerkiksi oikea-aikaiset huoltotoimenpiteet. Puolustushallinnon toimissa digitaalisia kaksosia käytetään strategisten harjoitusten suunnitteluun ja simulointiin turvallisessa ympäristössä.

Laadukkaan datan merkitys

Digitaalisen kaksosen arvo perustuu sen taustalla olevaan dataan. Ilman laadukasta dataa digikaksonen on pelkkä visuaalinen malli, eikä sillä ole kykyä tukea tiedolla johtamista. Laadukas data tekee mahdolliseksi operatiivisen toiminnan kehittämisen, päätöksenteon tukemisen ja tiedolla johtamisen.

Tuotettavan datan debuggaus ja validointi käy entistä tärkeämmäksi. Näytönkaappauksessa esimerkki avoimeen lähdekoodiin perustuvasta Digital Twin Toolbox -teknologiasta.

Ennen kuin digikaksoseen päästään, on fyysinen todellisuus oltava oman käyttötapauksen osalta kartoitettuna eli toisin sanoen on paikkatiedon oltava kunnossa. Ja kyllä, ihan se peruspaikkatieto — tässä vaiheessa ei ole tarpeen olla kartoitettuna useita dataulottuvuuksia (aika-, 3D jne.). Tämä toiminee perustason jäljennöksenä fyysisestä todellisuudestamme. Esimerkiksi infrastruktuurin tarkka kartoitus, kuten rakennusten, liikenneverkkojen ja luonnonpiirteiden yksityiskohtainen kartoitus, on edellytys erilaisten digitaalisten kaksosten toimivuudelle ja oikeellisuudelle. Tämä data on ikään kuin todellisuuden peilikuva, joka toimii pohjana digitaaliselle kaksoselle – varsinainen kaksonen syntyy, kun mukaan tuodaan analyysiä, ennustemalleja ja jatkuvasti päivittyvää dataa.

Esimerkkejä digikaksos-simuloinneista: drone-ilmatilan hallinnasta luonnonsuojeluun

Digitaalisten kaksosten keskeinen hyöty on mahdollistaa kehitysprosessien testaus ja simulointi viemättä kokeiluja fyysiseen todellisuuteen, jossa kokeileminen tulisi erittäin kalliiksi (ja joskus myös kohtalokkaaksi). Esimerkiksi drone-ilmatilan hallintaan voidaan luoda digitaalinen kaksonen, joka sisältää paikkatietoa, kuten rakennuksia, lentoesteitä ja lennonestoalueita. Tässä ympäristössä voidaan suunnitella ja simuloida lentoreittejä sääntöpohjaisesti ja esteiden pohjalta. Näin viranomaiset voivat ennakoida muutosten vaikutuksia ja tehdä tietoon perustuvia päätöksiä turvallisesti digitaalisessa ympäristössä.

Kaupunkitilasta luodut digitaaliset kaksoset palvelevat erilaisia toimialakohtaisia tarpeita.

Toisena esimerkkinä voidaan kuvitella luonnonsuojeluun liittyvä digitaalinen kaksonen, jolla halutaan simuloida ekosysteemien tilaa ja ennakoida ihmistoiminnan vaikutuksia luontoon. Tällainen digikaksonen voi auttaa esimerkiksi simuloimaan, mitä vaikutuksia puuston kaatamisella voi olla liito-oravan liitoväylille tai miten metsien suojelu voi kriittisesti parantaa uhanalaisen lajin elinympäristön laajuutta.

Räätälöinti avoimen lähdekoodin teknologioilla

Avoimen lähdekoodin paikkatietoteknologiat ovat ideaalisia digitaalisten kaksosten rakentamiseen, koska ne mahdollistavat joustavan räätälöinnin toimialakohtaisiin käyttötarpeisiin. Eri sektoreiden vaatimukset eroavat merkittävästi toisistaan, ja avoimen lähdekoodin ratkaisuilla voidaan kehittää tehokkaasti juuri tiettyyn tarkoitukseen sopiva digikaksonen. Tämä lähestymistapa on kustannustehokas ja mahdollistaa räätälöityjen ratkaisujen kehittämisen ja käyttöönoton nopeasti.

Teoriasta käytäntöön

Digikaksosen rakentamiseen on lähdettävä yksi käytännön askel kerrallaan.

Määritä tarkasti käyttäjätarve eli mihin tarkoitukseen digikaksosta tullaan käyttämään
Paranna fyysistä todellisuutta mallintavan datan laatua käyttäjätarpeen mukaan,
Rikasta tietorakennetta vastaamaan digikaksoseen liittyviin käyttäjätarpeisiin (eli simulointitarpeisiin),
Rakenna datapohjaisia säännönmukaisuuksia, joita myöhemmin tulet simuloimaan (mikä vaikuttaa mihinkin),
Lähde pian projektin käynnistyttyä tuottamaan simulaatioita ja testausta, ja siten vastaamaan käyttäjätarpeeseen, jotta varmistat projektisi kulkevan kohti konkretiaa (näissä projekteissa on helppo hukkua teorian, datan ja käsitteiden maailmaan).

Digitaaliset kaksoset avaamassa paikkatiedon potentiaalia

Digitaaliset kaksoset ja avoimen lähdekoodin paikkatietoteknologiat voivat vihdoin murtaa historiaan jäävät teknologiset esteet, jotka ovat estäneet paikkatiedon täysimääräisen hyödyntämisen, tuoden paikkatiedon siiloutuneista prosesseista kaikkien saataville. Ilman laadukasta, saavutettavaa dataa digitaaliset kaksoset eivät voi ylittää niitä rajoitteita, jotka ovat pitkään estäneet paikkatiedon laajamittaisen hyödyntämisen. Avoimen lähdekoodin teknologiat eivät ainoastaan jousta erilaisten toimialojen tarpeisiin, vaan ne myös mahdollistavat kustannustehokkaan ja yhteisöllisen kehityksen, joka murtaa perinteiset siilot paikkatiedon hyödyntämisessä.

Johdanto

Miten toteutetaan kunnan infraomaisuuden tiedon hallinta? Tämä ei ole ihan yksinkertainen kysymys, sillä infrastruktuurin hallinnointi ja ylläpito on kunnalle valtava taloudellinen haaste; pelkästään valotolppien, leikkikenttien ja muun kaupunkiomaisuuden ylläpitoon ja hallintaan voi mennä satoja tuhansia, ellei miljoonia euroja vuosittain. Aiemmassa blogikirjoituksessa kerroimme Infra-O Open -työkalusta, joka tuotettiin Infra-O -hankkeessa kuntien infraomaisuuden hallintaan. Tämä blogikirjoitus on jatkoa Infra-O:n tarinaan. Nyt näytämme, miten infraomaisuuden hallinta tapahtuu Infra-O Open -QGIS-lisäosan avulla.

Tässä blogikirjoituksessa kuvittelemme itsemme kunnan infraomaisuuden tiedon hallinnasta vastaavaksi henkilöksi. Käymme läpi koko lisäosan käyttöönottoprosessin esivalmisteluista alkaen. Näytämme, miten infraomaisuuden kartoittaminen tapahtuu QGISillä.

Seuraamalla ohjeitamme loppuun asti luot paikkatiedon hallintaan enterprise-tason prosessin, joka pohjautuu keskitettyyn tietokantaan. Lukuisista vaikeista termeistä ei kannata hämääntyä. Käymme prosessin kohta kohdalta läpi alla. Aloitetaan!

Askel 1: Tietokanta

Aluksi tarvitaan PostgreSQL-tietokanta. Monet pilvipalveluntarjoajat tarjoavat PostgreSQL-tietokannan palveluna, eli palveluntarjoaja ylläpitää (“hostaa”) tietokantaa palvelinympäristössään ja käyttäjä ottaa yhteyden siihen asiakasohjelmalla esimerkiksi QGISillä. Yksi tällainen palveluntarjoaja on suomalainen Aiven.

PostgreSQL-kannan voit luoda haluamallasi tavalla/ haluamaasi palveluun. Aivenissa se hoituu näin:

Luo tili Aivenin verkkosivuilla (https://aiven.io/), jos sinulla ei vielä ole sitä.
Kirjaudu Aiven-tilillesi ja siirry PostgreSQL-palveluun.
Aloita uuden PostgreSQL-tietokannan luominen valitsemalla ’Luo palvelu’.

Valitse tietokannallesi haluamasi asetukset ja määritykset. Kokeilua varten voit käyttää ilmaista PostgreSQL-tietokantaa.
Kun tietokanta on luotu, saat yhteystiedot, kuten isännän, portin, käyttäjänimen ja salasanan.

Nyt sinulla on tietokanta. Käytä saamiasi yhteystietoja, kun luot yhteyden uuteen etä-PostgreSQL-tietokantaasi paikalliselta tietokoneeltasi esim. QGISillä.

Haluamme kannustaa kokeilemaan tietokannan pystytystä, sillä vaikka mitään lopullista tietokantaratkaisua et tässä rakentaisikaan, oppimisen kannalta on keskeistä saada tietokanta johonkin helposti käytettävään palveluun.

Askel 2: Yhteys tietokantaan

Kun tietokanta on pystyssä ja varustettu PostGIS-laajennuksella, siihen voidaan asentaa kunnallisen infraomaisuuden valtakunnallisen Infra-O-tietomallin mukainen rakenne QGIS-lisäosan avulla. Ensin pitää kuitenkin määrittää QGISissä yhteys uuteen tietokantaan:

Askel 3: Infra-O-lisäosa ja tietokannan alustus

Nyt meillä on tietokanta ja QGISistä yhteys tietokantaan. Seuraavaksi asennamme InfraO-lisäosan QGISiin:

Lisäosalla voidaan nyt alustaa tietokanta Infra-O -malliin, eli asettaa tietokantaan Infra-O-tietomallin rakenne:

Työkaluun valitaan listasta yhteys uuteen tietokantaan ja klikataan ‘Alusta’. Tällöin tietokantaan lisätään tarvittavat skeemat ja taulut. Niiden lisäksi tietokantaan lisätään automaattisesti QGIS-projekti, johon on valmiiksi lisätty tasot tietokantayhteyksineen. Työkalussa on käytetty termiä ‘QGIS-työtila’, jolla tarkoitetaan QGIS-projektia. Lisäosalla voit myös tallentaa tai ladata dataa valtakunnallisessa muodossa (lisätietoa täällä).

Nyt meillä on kaikki valmiina infraomaisuuden kartoittamista varten! Olemme luoneet tietokannan, johon tieto tallennetaan, määrittäneet sen valmiiksi infraomaisuuden keräämistä varten, sekä saaneet QGIS-projektin, jonka avulla tietoa voidaan alkaa kerryttää.

Askel 4: Lähde kartoittamaan infraomaisuutta

Tietokannassa valmiina oleva QGIS-projekti mahdollistaa tietojen lisäämisen tietokantaan kätevästi. Projektiin on määritelty myös lomakkeet, joiden avulla tietojen syöttäminen ja muokkaaminen on helppoa. Näin voitaisiin saada merkitä kartalle esimerkiksi penkki:

Usealle kohteelle on mahdollista syöttää samat tiedot yhdellä kertaa:

Tietokanta mahdollistaa datan yhteiskäytön. Samaa dataa voi reaaliajassa tuottaa, katsella ja muokata useampi käyttäjä. Useampi käyttäjä voi myös käyttää samaa tietokannassa olevaa QGIS-projektia. Jokaisella käyttäjällä voi olla tietokannassa eri käyttäjätunnus. Tällöin tulee huolehtia, että jokaisen käyttäjän autentikaatiotunniste on sama (lue lisää autentikaatiotietojen tallennuksesta toisesta blogiartikkelistamme).

Yhteenveto

Huh! Nyt voit kuvitella, miten kollegasi tai tiimisi yhdessä ryhtyisivät ylläpitämään tietoja infraomaisuudesta QGISilla, kukin omalta koneeltaan ja täysin reaaliajassa. Voisitte myös päästä eroon ärsyttävistä duplikaattitiedostoista (puusto_v1, puusto_vfinal_v2,…), hidastavista käyttäjämäärien rajoituksista ja kelluvista lisensseistä sekä mahdollisesti tarkoista, mutta vaikeasti käytettävistä CAD-mallinnuksista.

Kunnasssa työnkuvat ja vastuut voivat olla infraomaisuuden hallintaa laajempia, sama henkilö saattaa osallistua esimerkiksi yleiskaavan tuottamiseen tai paikallisten liikennemerkkien hallintaan paikkatietomuodossa. Myös näiden aineistotietokantojen kohdalla keskitetty tietokanta ja siihen liittyvät työnkulut voivat tehostaa toimintaa.

Kehotus: toimi jo nyt

Vaikka käsitteet kuten ”keskitetty paikkatietokanta” tai ”valtakunnallinen infraomaisuuden tietomalli” saattavat tuntua hankalilta, rohkaisemme kaikkia asiantuntijoita kuntasektorilla tutustumaan ja kokeilemaan uusia työkaluja sekä työprosesseja käsitteellisen ymmärryksen ja käytännöllisen teknologia-osaamisen kasvattamiseksi.

Tuntuiko hankalalta? Me autamme! Ota yhteyttä ja kysy lisää.

Tämän artikkelin kirjoittivat yhteistyössä Juho Ervasti ja Santtu Pyykkönen.

Plugareista potkua työskentelyyn

Plugareita, eli lisäosia löytyy joka lähtöön QGISistä ja niiden avulla omaan työskentelyyn voi saada monia uusia ulottuvuuksia! Plugarit ovat siis QGISille kehitettyjä lisätoimintoja ja niiden kehittämisestä vastaavat yksittäiset kehittäjät tai jokin itsenäinen yritys. Plugarit auttavat lisätoimintojensa kanssa esimerkiksi irroittamaan rakennusdataa tietyltä alueelta, luomaan interaktiivisia karttoja tai jatkojalostamaan korkeusmalli rinneprofiiliksi. Seuraavaksi käymmekin läpi muutamia Gispolaisten suosimia QGIS-plugareita ja niiden monipuolisia käyttötarkoituksia. Löytyykö Gispolaisten listalta omaa suosikkiasi?

DigitransitGeocoding

Tämä lisäosa on tarkoitettu suomalaisten osoitteiden ja paikkojen geokoodaukseen QGIS-projektissa. Geokoodauksen avulla voit kätevästi hakea eri osoitteita ja paikkoja QGISissä vain näpyttelemällä etsimäsi osoitteen tai paikan nimen hakukenttään! Lisäosan käyttämistä varten tarvitset vain API-avaimen, jonka pystyy hankkimaan näppärästi osoitteesta https://portal-api.digitransit.fi/. Lisäosan käyttöä varten tulee luoda QGIS:ssä globaali muuttuja DIGITRANSIT_API_KEY ja asetettava API-avain sen arvoksi. Tarkemmat ohjeet API-avaimen luontiin löytyy Gispon blogista. Alla olevassa kuvassa on esimerkiksi haettu Suomesta kaikki tiet, joiden nimi on Mannerheimintie.

DigitransitGeocoding-plugarin avulla haettu osoite. Plugari luo osoitteesta pistemuotoisen tason, joten osoitteen sijainti on helppo havaita ja visualisoida.

Qgis2web

Qgis2web-plugarin avulla voit viedä oman QGIS-projektisi kätevästi OpenLayers- tai Leaflet-verkkokartaksi suoraan selaimeen. Tämä plugari kopioi niin monta projektin osaa kuin se vain pystyy, eli muun muassa tasot, laajuudet ja eri tyylit. Plugari huomioi tyylien mukaan ottamisessa myös mahdolliset tyylien luokittelut ja porrastukset. Plugari siirtää projektisi näppärästi selaimeen, jossa siitä muotoutuu kätevä interaktiivinen kartta!

QGIS-projektista qgis2web-plugarilla selaimeen siirretty interaktiivinen kartta Helsingin ydinkeskustan junaradan aiheuttamista melusaasteista.

MapSwipeTool

Tämän plugarin avulla voit vertailla kahta karttatasoa keskenään. Karttatasot asettuvat toistensa päälle ja näin voidaan esimerkiksi vertailla maankäytön muutoksia eri vuosien ajoilta ilmakuvista tai vaikkapa tulvan vaikutuksia tietyllä alueella ennen ja jälkeen! Vertailu tapahtuu liu’uttamalla karttatasojen keskellä olevaa viivaa oikealle ja vasemmalle, jolloin aina toinen karttataso vertautuu toiseen samalta alueelta ja eroavaisuudet ovat nopeasti havaittavissa. Tämä plugari on hyödyllinen myös esimerkiksi georeferoitujen aineiston vertailemiseen!

Ilmakuvien vertailua Helsingistä vuosilta 2014 ja 2023 MapSwipeTool-plugarin avulla.

Profile tool

Profile tool-plugarin avulla voit piirtää rinneprofiilin omasta korkeusmallistasi QGIS-projektissa. Kaavioon piirtyy viiva kuvastamaan korkeusmallin korkeusvaihteluita. Kun siirrät hiirtä rinneprofiilissa, niin näet samalla korkeusmallissa reaaliajassa, missä kohtaa mikäkin korkeuden aste on. Kätevä plugari saamaan korkeusmalleista kaiken informaation irti esimerkiksi valuma-alueanalyyseissä hyödyntäen! Kaavion pystyy tallentamaan svg-, png-, csv- tai pdf-tiedostoiksi.

Korkeuserojen tarkastelua käsivarren Lapin alueelta Profile Tool-plugaria käyttäen.

QNEAT3

QNEAT3 eli QGIS Network Analyst Tool-plugarin avulla voit näppärästi suorittaa erilaisia paikkatietoanalyysejä tieverkkoaineistosi pohjalta. Halusit sitten laskea lyhyimmän reitin paikasta A paikkaan B tai luoda interpoloidun pinnan kahden pisteen väliseltä etäisyydeltä, niin tästä plugarista löytyy työkalut kinkkisimpiin paikkatietopulmiin! Plugari sisältää työkaluja muun muassa nopeimman tai lyhyimmän reitin laskemiseen sekä erilaisia Iso-Area analyysityökaluja esimerkiksi pistepilvien- ja interpolointitasojen luomiseen tieverkkoaineistosta.

QNEAT3-plugarilla laskettu nopein reitti Helsingin päärautatieasemalta Tähtitorninmäelle.

Psst! Tarttumisen työkalu kannattaa klikata aktiiviseksi QGIS-projektissa, jolloin se tarttuu tieverkkotasoon. Näin plugari osaa laskea reitin esimerkiksi siinäkin tilanteessa, jossa aloituspiste sijaitsee metsässä kauempana tieverkosta.

QuickMapServices

Uupuuko sinulta QGIS-projektistasi vielä sopiva taustakartta? QuickMapServices-plugari on juuri tähän tarkoitukseen tehty! Tämä plugari tarjoaa kattavan valikoiman erilaisia taustakarttoja QGIS-projektiisi. Halusit sitten taustakartan luodun korkeusmallisi taustalle sopivaksi tai vaikka paikkatietoanalyysisi pohjalle, josta erottuisi kaupungin tiet ja rakennukset. Tästä lisäosasta löytyy esimerkiksi OpenStreetMapin pyöräilyreittikarttoja, Turun kaupungin karttoja, Landsat-satelliittikuvia ja erilaisia Googlen karttoja. QuickMapServices-plugariin pystyy kuka tahansa yksityishenkilö tai organisaatio lähettämään omia karttojaan julkaistavaksi heidän kotisivujen kautta. Muista kuitenkin, että julkaistavan aineiston lisenssi tulee olla julkinen, jos kartan haluaa tähän lisäosaan mukaan!

QuickMapServices-plugarin kautta avattu pyöräilyreittien kartta ja Google Maps-kartta QGIS-projektissa.

Plugareita joka lähtöön

Plugareita löytyy moneen erilaiseen tarpeeseen ja niitä pystyy hyödyntämään monipuolisesti lukuisiin erilaisiin paikkatieto-ongelmiin. Plugareita myös päivitetään ja kehitetään lisää QGISiin ja tätä kehitystyötä voi tehdä avoimesti monet eri toimijat ja organisaatiot. Gispolta löytyy liuta erilaisia kursseja, joilla hyödynnetään QGIS-lisäosia, sekä myös oma kurssi lisäosien kehitystä varten! Plugareita löytyy jo nyt huikea määrä QGISistä, joten kannattaa ehdottomasti perehtyä lisää plugarien käteviin ominaisuuksiin ja seurata aktiivisesti niiden kehittämistyötä. Ei siis muuta kuin kokeilemaan vaan!

Tämän artikkelin on kirjoittanut Anni Jusslin

Helsingin Esplanadilla kolme LiDAR-valotutkaa on tarkkaillut liikennettä marraskuusta 2023 elokuuhun 2024. Datan keräämisen on tehnyt Flow Analytics ja aineisto on lisäksi ladattavissa (edellyttää tunnusten luomista): https://flow-portal.com/. Tuotettua dataa on paljon, ja enää puuttui työkalu sen analysointiin.

Forum Virium Helsingin kanssa teimme projektin, jonka tavoitteena oli kehittää työkalu LiDAR-tutkilla kerätyn liikennedatan analysointiin sekä tehdä pieni analyysi tästä kokeellisesta datasta. Työkalun loppukäyttäjinä tulisi olemaan Helsingin kaupungin liikennetutkijat. LiDAR-tutkat mahdollistavat laajemman liikennedatan keräämisen kuin perinteisemmät liikennelaskentamenetelmät, joten niiden käytön voi olettaa lisääntyvän ja siten niiden tuottaman datan analysointiin soveltuvalle työkalullekin on tarvetta.

Analyysityökalu päätettiin kehittää QGIS-lisäosaksi, joka sai nimen FVH-3T (Forum Virium Helsinki – Traffic Trajectory Toolkit). Lisäosa muodostuu parista painikkeesta ja kolmesta QGIS-prosessointialgoritmista, ja sen käyttö onkin siten hyvin yksinkertaista: Aluksi käyttäjä tuo tutkittavan pistetason QGISiin ja luo tyhjän portti- ja aluetason lisäosien työkalupalkin painikkeilla. Seuraavaksi käyttäjä piirtää portti- ja aluekohteita niihin sijainteihin, joissa hän haluaa tutkia liikennettä.

Kun portti- ja aluekohteet on piirretty, on aika suorittaa prosessointialgoritmi. FVH-3T -lisäosassa on näitä kolme: kaksi on varsinaista liikennelaskentaa varten ja kolmatta voidaan käyttää, kun halutaan exportoida porttien laskemia tietoja JSON-muotoon. Ennen laskennan suorittamista kahdessa “Count trajectories” -prosessointialgoritmissa käyttäjä voi asettaa laskennan ajanjakson sekä kulkutapaluokan. QGIS-lisäosan prosessointialgoritmin ajaminen muodostaa pistedatasta liikeratoja eli trajektoreja ja laskee sekä näille että piirretyille porteille ja alueille liikkumiseen liittyviä tietoja. Prosessointialgoritmi voidaan suorittaa yksittäisajona halutulle ajanjaksolle tai jakaa se pienempiin aikasarjoihin käyttäen QGISin eräajo-ominaisuutta.

Kuten edellä todettiin, prosessointialgoritmin ajaminen piirtää tarkasteltavan aikavälin pistedatasta liikeratoja; suorittaessa liikennelaskentaa alueilla, prosessointialgoritmi muodostaa trajektorit vain alueiden sisällä olevista pisteistä, kun taas porttien prosessointialgoritmia käytettäessä trajektorit piirretään kaikille valitun kulkutapaluokan pisteille kyseisellä aikavälillä.

Trajektoreille lasketaan niiden pituus ja ajallinen kesto sekä keskimääräinen ja maksiminopeus. Jokaiselle käyttäjän piirtämälle alueelle lasketaan sen leikkaavien liikeratojen lukumäärä sekä niiden keskimääräinen nopeus. Näin voidaan tarkastella esimerkiksi risteyksen ruuhkautumista. Porteille lasketaan puolestaan ne leikkaavien trajektorien lukumäärä per suunta sekä leikkaavien trajektorien keskimääräinen hetkellinen nopeus ja kiihtyvyys.

FVH-3T QGIS-lisäosaa voidaan käyttää mm. liikenteen sujuvuuden analysoimiseen yleisellä tasolla sekä tarkempaan yksittäisten liikkujien tarkasteluun. Trajektorien avulla voidaan esimerkiksi tarkastella kuinka tunnollisesti jalankulkijat käyttävät suojateitä vai ylittääkö moni ajotien väärästä kohdasta. Vastaavasti trajektoreista voidaan analysoida käyttävätkö pyöräilijät heille tarkoitettuja pyöräkaistoja vai ajaako moni esimerkiksi jalkakäytävällä. Porttien avulla voidaan tarkastella liikennemääriä, nopeuksia ja kiihtyvyyksiä halutuissa sijainneissa sekä sitä ajavatko jotkin autoilijat tai pyöräilijät vääriin ajosuuntiin. Alueilla voidaan puolestaan analysoida esimerkiksi liikenteen ruuhkautumista risteysalueilla autojen keskimääräisten nopeuksien avulla.

Suorittamassamme pienessä analyysissä havaitsimme esimerkiksi, että autojen liikennemäärät olivat havainnointiajanjaksolla keskimäärin suurimmat perjantaisin ja matalimmat sunnuntaisin. Toisaalta emme havainneet merkittäviä viikonpäiväkohtaisia eroja ajoneuvojen keskimääräisissä nopeuksissa risteysalueilla. Analyysillä oli mahdollista tunnistaa yksittäisiä päiviä, jolloin autojen keskinopeus oli tavanomaista hitaampi risteysalueilla. Nämä olivat päiviä, jolloin alueella on ollut hyvin paljon jalankulkijoita. Esimerkiksi 15.8.2024 on vietetty Helsingin Taiteiden yötä, jonka vaikutukset näkyvät autojen keskinopeudessa.

Jalankulkijoiden liikkeistä havaitsimme sen sijaan esimerkiksi, että vaikka enemmistö käyttää suojateitä tunnollisesti, on kuitenkin melko yleistä ylittää ajorata väärästä kohdasta. Vastaavasti voitiin havaita, että vaikka Esplanadin alueen pyöräkaistat ovat ahkerassa käytössä, osa pyöräilijöistä ajaa jalankulkijoille tarkoitetuilla väylillä.

Projekti oli mielenkiintoinen, eikä vähiten siksi, että pääsimme kokeilemaan itse luomaamme työkalua tositoimissa sekä tutustumaan liikenneanalyysin alkeisiin. Luodun työkalun suurimpia vahvuuksia on, että liikennetutkija pääsee itse määrittelemään portit ja alueet juuri sellaisille sijainneille, joista on kiinnostunut.

Tämän artikkelin on kirjoittanut Mika Sorvoja.

GeoServer on monipuolinen paikkatietopalvelin, joka mahdollistaa rajapintojen jakamisen tehokkaasti ja joustavasti. Gispo on ollut mukana pystyttämässä ja tukemassa GeoServer-ratkaisuja monille eri organisaatioille, ja tällä kertaa yhteistyö suuntautui uudelle toimialalle: vesilaitoksen tarpeisiin.

Kymen Vesi Oy toimii Kymenlaakson alueella, kattaen Kotkan, Pyhtään ja Kouvolan. Vesihuollon paikkatietoaineistoihin kuuluvat esimerkiksi vesijohdot ja viemäriputket. Vesilaitoksen tavoitteena oli jakaa näitä kriittisiä paikkatietoaineistoja alueen kunnille turvallisesti ja hallitusti. Aineiston kriittisyyden vuoksi oli tärkeää, että jokaiselle kunnalle näytetään vain oman alueensa kohteet.

Ratkaisuna paikkatiedot tuotiin rajapinnan kautta GeoServeriin, jossa ne rajattiin kuntarajojen ja käyttäjien mukaan. Näin saatiin aikaan uusi rajapinta, joka mahdollisti turvallisen ja tarkan tiedonjaon. Gispo avusti sekä GeoServerin asennuksessa että sen konfiguroinnissa Kymen Veden tarpeisiin.

Kun aineisto tuodaan GeoServeriin WMS- tai WFS-rajapinnan kautta, kyseessä on ns. “cascaded”-rajapinta. Cascaded WMS-rajapintaa voidaan jakaa, mutta sen muokattavuus on rajallinen. Cascaded WFS-rajapinnassa kokeiltiin aluksi käyttää CQL-filtteriä (Common Query Language) rajaamaan aineistoja kuntageometrian perusteella. Valitettavasti ratkaisu osoittautui liian hitaaksi käytännössä, vaikka teknisesti se olikin toimiva.

Alkuperäisen suunnitelman sijaan päädyttiin luomaan ajastettu skripti, joka kerran yössä hakee rajapinnasta tarvittavat aineistot ja tallentaa ne palvelimelle GeoPackage-tiedostona. Skripti rajaa aineistot kuntien alueiden perusteella ennen tiedoston luomista. GeoServerin Store määritettiin käyttämään näitä GeoPackage-tiedostoja tietolähteenä, jolloin aineisto päivittyy automaattisesti kerran vuorokaudessa.

Tämä lähestymistapa mahdollisti huomattavasti joustavamman ja tehokkaamman ratkaisun ulospäin jaettavan rajapinnan konfigurointiin verrattuna suoraan Cascaded-rajapintaan.

Projekti osoitti, kuinka tärkeää on joustava suunnitelmien muuttaminen ja tiivis yhteistyö osapuolten välillä. Lopputulos ylitti alkuperäiset odotukset tarjoten sekä toimivamman ratkaisun että tehokkaamman tavan hallita Kymen Veden kriittisiä paikkatietoja.

Kaavoituksen maailma ryhdistyy parhaillaan ja meillä Gispollakin ollaan mukana kahdessa kumppanitestaushankkeessa, joissa testataan Syken kehittämää Ryhti-tietojärjestelmää ja samalla tuotetaan avoimen lähdekoodin paikkatietotyökaluja kuntien ja maakuntien käyttöön. Hankkeita vetävät Varsinais-Suomen liitto ja Paimion kaupunki.

Kaavan tuotanto QGISillä

Gispon ratkaisu pohjautuu siihen, että kaavoittaja hyödyntää QGIS-työpöytäohjelmistoa kaavan tuotannossa. Tässä meillä on jo useamman vuoden kokemus useasta eri kaavoituksen pilottihankkeesta, joten tiimillä on ollut jo aika hyvä käsitys siitä, mihin QGIS yksinään pystyy ja ei pysty.

QGISissä on todella monipuolisia lomakkeiden luomismahdollisuuksia, mutta niissä tulee nopeasti vastaan käytettävyys, kun lomakkeet voivat paisua valtaviksi. Jos lomake on laaja, käyttäjän pitää myös tietää hirveästi asioita: miten ja mitä tietoja tulee täyttää ja mitä ei? Alla esimerkkinä maakuntien hankkeessa tehty ensimmäinen versio kaavamääräysryhmistä.

Tavoitteena olikin, että käyttöliittymää pystyttäisiin kehittämään eteenpäin ja onneksi saimme toisen kumppanitestaushankkeen toteutettavaksi, jossa tätä työtä voidaan tehdä. Käytännössä tarkoitus on nyt toteuttaa yhden QGIS-lisäosan kautta kaksi päätoimintoa, joista toinen huolehtii kaavakohteiden ja kaavamääräysten tuotannosta Ryhdin määrittelyjen mukaisesti ja toinen tietojen viennistä Ryhtiin sekä toisaalta myös tietojen hausta Ryhdistä. Lisäosaa ollaan vasta nyt tuottamassa, joten vielä ei ole testattavaa, mutta keväällä 2025 toivottavasti lisäosat ovat hyödynnettävissä.

QGIS ei riitä yksinään

Koska Ryhdin kaavatietomalli on erittäin laaja ja monipuolinen, se vaatii muutamia asioita kaavan tuotannon sovellukselta. Ensinnäkin Ryhti-mallinen kaava vaatii aina taustalle relaatiotietokannan, jotta tiedot voidaan tuottaa Ryhti-yhteensopivasti. Tässä PostGIS on olennainen työkalu. Olemme testanneet myös tuottaa ratkaisua GeoPackagen avulla, mutta sen mahdollisuudet hallita relaatioita ovat vielä aika rajoittuneet, joten taustalle tarvitaan kunnon tietokantaohjelmisto.

Toiseksi kaavoituksen Katja-asetuksessa on määritelty, miten kaavamääräysryhmät muodostetaan, ja sääntöjä on hirvittävän paljon. Esimerkiksi tuulivoimaan liittyviä koodistoja on useita, ja niistä muodostetaan kaavamääräysryhmiä, jotka taas liitetään kohteelle. Riippuen siitä onko kohde pistemuotoinen vai aluemuotoinen kaavamääräys voi saada vain tiettyjä arvoja. Tällaisten sääntöjen muistaminen ilman toimivaa käyttöliittymää on käytännössä mahdotonta. Siksi meneillään olevissa hankkeissa rakennetaan QGISin päälle työkaluja, jotka hoitavat muistamisen kaavoittajan puolesta. Ajatuksena on, että kaavoittaja voi myös itse kehittää uusia kaavamääräysryhmiä, jos niiden sisällöt ovat Ryhdin puolesta valideja.

Tavoitteena on tuottaa kaavoittajalle helppokäyttöinen ja intuitiivinen työkalu, ja käytettävyyttä edistetään yhteiskehittämisen voimin Paimion vetämässä hankkeessa mukana olevien partnereiden kanssa. Hankkeen alussa määritellyt sekä myöhemmin esiin nousevat käyttäjän toiveet ja tarpeet pyritään huomioimaan läpi koko hankkeen.

Rajapintojen kautta tietojen välitys

Lisäksi Ryhti-järjestelmä vaatii, että käyttäjät tunnistautuvat joko Suomi.fi-tunnistautumisella Ryhdin kehittämän käyttöliittymän kautta, johon viedään validoitu JSON-muotoinen kaavatieto, tai kaavoittajan sovellus välittää rajapintapyynnöt suoraan Ryhtiin Palveluväylän kautta.

Tämän vuoksi päätettiin, että hankkeissa luodaan sovellus, jossa palveluväyläpalikka on mukana. Palveluväyläpalikka, PostGIS ja muut palvelut, joita kehityksen alla oleva sovellus hyödyntää, asennetaan Amazon Web Services -ympäristöön ns. mikropalveluina. Tällä hetkellä sovellusympäristö on siis AWS-ympäristöön spesifi ja sitä ei voi suoraan asentaa vaikkapa Microsoft Azure tai Google Cloud -pilvipalveluympäristöihin. Jotta sen saisi käyttöön muihin pilvipalveluihin, pitäisi sovelluksen komponentteja muuttaa kunkin pilvipalvelun omien käytäntöjen mukaisiksi.

Sovellus tunnistautuu siis Palveluväylän kautta Ryhtiin ja Ryhti varmistaa, että sovelluksella on oikeudet välittää kyseisen kunnan tai maakunnan tietoja Ryhtiin. Lisäksi sovellus varmistaa, että Ryhtiin lähetettävä tieto on lähtökohtaisesti validoitu jo ennen lähetystä. Jos näin ei jostain syystä ole, Ryhdin validaattori herjaa ja palauttaa käyttäjälle tiedon, mikäli jokin tieto puuttuu tai on väärin kirjattu. Käyttöliittymäkehityksen myötä pyrimme Gispolla siihen, että validointivirheitä ei tule. Toki jos jokin asia Ryhti-päässä muuttuu, virheitä voi alkaa tulla. Ajatuksena on, että yhteiskehittämismallilla sovelluksen käyttöönottavien kuntien kanssa hoidamme ylläpidon myös tulevaisuudessa ja uudet kehitystarpeet voidaan toteuttaa kestävällä ja kustannustehokkaalla tavalla.

Kehitystä tarvitaan vielä

Vielä on paljon asioita selvitettävänä ja ymmärtääksemme esimerkiksi Katja-asetuksesta on keväällä 2025 tulossa uusi versio, joka voi vaikuttaa esimerkiksi nyt QGISille luotavaan kaavamääräysryhmätyökaluun. Siksi toivomme, että kaikki, jotka ovat kiinnostuneita QGISin käytöstä kaavoituksen työkaluna tulevaisuudessa, olisivat valmiita kontribuoimaan työkalujen kehitykseen myös jatkossa.

Osa organisaatioista on luopunut viime vuosina konesaleistaan ja vienyt ylläpidettävät palvelunsa pilveen. Niistäkin, jotka eivät vielä ole siirtymää tehneet, pohtivat sitä. Tässä artikkelissa käymme läpi, miksi paikkatietopalveluita ylläpidetään pilvipalveluissa.

Mitä hyötyä pilvisiirtymästä on?

Miksi paikkatiedot kannattaa laittaa pilveen? “Minne muualle?” on nohevan ihmisen vastakysymys.

Oikeastaan pilvipalvelun ainoa vaihtoehto on palveluiden ylläpito konesalissa. Jos organisaatiolla on oma konesali valmiina ja siellä on servereitä tyhjänä, niin palvelut voi pystyttää tietenkin sinne. Kaikilla näin ei tietenkään ole.

Pilvialustat sen sijaan ovat helppo tapa testata esimerkiksi GeoServerin uusinta versiota muutamalla klikkauksella. Jos nopeutta kaivataan, pilvialustat tarjoavat ehdottomasti nopeimman tavan aloittaa uusia palveluita.

Jos palvelut on aloitettu pilvessä ja todettu, että niillä ei ole niin valtavaa liikennemäärää, että oman konesalin hankinta kannattaa, on kustannustehokasta jatkaa palvelun ylläpitoa pilvessä. Jos taas liikennemäärät kasvavat todella korkeiksi, niin kannattaa tehdä laskelmat, tulisiko oma konesali kuitenkin halvemmaksi. Pilvipalveluiden hinta nimittäin riippuu käytön määrästä (ja muista muuttujista, joista lisää tuonnempana).

Palvelu konttiin ja kontti pilveen

Pilvipalvelut tarjoavat usein palvelimien lisäksi muitakin palveluita. Palvelun voi toteuttaa esimerkiksi käyttäen kontteja palvelimien sijaan. Konttitoteutus voi myös laskea palvelun hintaa.

Monista ohjelmistoista on olemassa kontitetut versiot, jotka voi käynnistää yhdellä komennolla joko pilveen tai omalla koneella. Kontti tarkoittaa sitä, että sen sijaan että olisi kokonainen kone, jossa on ohjelmisto, koneella on käynnissä virtuaaliympäristö kuten Docker. Dockerissa puolestaan on sekä haluttu ohjelmisto että sen suljettu ympäristö. GeoServeriä esimerkkinä käyttäen: GeoServer voidaan asentaa joko omalle koneelleen, tai konttiratkaisuna jolloin se on suljetussa ympäristössä ja samalla palvelimella voi olla useita muitakin ohjelmistoja omissa konteissaan. Tämä suljettu ympäristö on vakiomuotoinen ohjelmisto-image, jota kutsutaan konttialustaksi.

Kun ohjelmisto on konttialustalla, sillä mitä muuta samalla palvelimella on, ei ole enää väliä. Samalla koneella tai alustalla voidaan ylläpitää montaa eri palvelua. Sekä Azure että AWS tarjoavat alustoja, joissa voi pyörittää kontteja (Docker-imageja). Palveluita voi käynnistää ja ylläpitää näillä alustoilla, jolloin ei tarvitse enää välittää palvelimesta, vaan asiakas maksaa vain niistä resursseista, mitä kone käyttää. Asiakas ei siis tiedä, millaisella koneella ohjelmisto on, vaan esimerkiksi että se vaatii 4 Gt muistia ja käyttää 2 CPU:ta. Palvelimien sijaan siis ylläpidetään vain ohjelmistoja (ns. serverless eli palvelimeton palvelu).

Muita pilvipalveluiden mahdollisuuksia

Konttien ajamisen lisäksi pilvipalveluissa tehdä paljon muitakin mahdollisuuksia. Esimerkiksi Contend delivery network mahdollistaa nettisivujen tai muiden nettipalveluiden jakamisen tiettyjen pilvessä olevien palveluiden välillä. Samoin voidaan tehdä koodia, jota ajetaan palveluna: esimerkiksi Lambda-funktioita, jotka käynnistyvät pyydettäessä, mutta eivät ole koko ajan pyörimässä.

Tarjolla on myös valvonta- ja lokitustyökaluja. Nämä ovat automatisoituja, eli niitä ei tarvitse asentaa, mutta ne pitää osata konfiguroida. Käyttäjä voi esimerkiksi määrittää palvelun lähettämään sähköpostitse hälytyksen, jos GeoServerin levytila on täyttymässä. Asioiden valvonnan lisäksi voidaan myös kerätä lokitietoja, joista voidaan tarkastella palvelun historiatietoja halutulta aikaväliltä. Se, mitä lokitetaan ja kuinka pitkään lokia säilytetään, riippuu pilvipalvelusta ja siellä ylläpidettävästä ohjelmistosta sekä lokitusasetuksista.

Näiden ominaisuuksien käyttöönotto on konesalien vastaaviin prosesseihin verrattuna erilaista, mutta ei välttämättä helpompaa. Pilven tapauksessa komennetaan jonkun toisen tekemää palvelua, joten sen logiikkaa ja mahdollisuuksia pitää ymmärtää, jotta sen saa toimimaan haluamallaan tavalla.

Turvallisuus

Kun palvelu on laitettu pystyyn pilvessä, vastuu sen toimivuudesta on isolta osin pilvipalvelun tarjoajalla. Jos konesalissa tulee Linuxissa ongelma tai hiiri on nakertanut johtoja, niin organisaatio on omillaan. Jos omassa toteutuksessa ja palvelussa on vika, se pitää osata korjata ja ylläpitää. Pilvipalveluissa palveluntarjoaja huolehtii tällaisista seikoista, minkä vuoksi pilvipalvelut ovat tässä mielessä varmempia. Ei tarvitse osata ylläpitää palvelua tai niihin liittyviä laitteita, ja pilvipalvelun tarjoaja lupaa, että palvelu on olemassa ja vastaa pyyntöihin kuten “pystytä palvelin”.

Omassa konesalissa pitää jatkuvasti huolehtia tietoturvapäivityksistä ja Linux- tai Windows-käyttöjärjestelmäpäivityksistä. Jos taas ylläpitää pilvessä palvelimettomia palveluita, kuten kontteja tai funktioita, ei tarvitse huolehtia serverin tietoturvasta tai välttämättä käyttöjärjestelmäpäivityksistäkään, sillä ei ole niistä vastuussa. Asiakas on kuitenkin vastuussa oman ohjelmistonsa tietoturvasta: vaikka pilvialusta tarjoaisi kaiken muun, pitää silti tietää omien ohjelmistojensa versiot ja päivittää ne, kun haavoittuvuus tulee. Tämä on yhteistä sekä pilvessä että konesalissa.

Myös porttien avaaminen ja palomuuriasetukset pitää sekä konesalin että pilvialustan tapauksessa. Pilvessä ei ole oletuksena portteja auki, vaan ne pitää itse säätää (mitkä portit avataan ja mistä liikennettä sallitaan). Tämä on muistettava palveluita käynnistettäessä. Pilveen voidaan tehdä virtuaalisisäverkkoja, joissa palvelut saavat kommunikoida keskenään, mutta niihin ei pääse ulkoapäin.

On myös mahdollista, että palvelu ei ole aina ja ikuisesti saatavissa. Mitä lähempänä käyttäjää palvelu on, sitä helpommin se on saatavissa. Jos ajatellaan, että Keski-Euroopassa konesali räjähtää tai Suomen edustalla oleva merikaapeli menee poikki, niin Suomessa olevat palvelun käyttäjät eivät pääse siihen käsiksi. Toisaalta Suomen sisälläkin on mahdollista, että verkko-operaattorilla on ongelmia. Nyrkkisääntönä: mitä pidempi yhteys palvelimelle on, sitä enemmän mahdollisuuksia on, että se katkeaa.
Etäisyyksistä päästään omiin konesaleihin: mitä kauempana palvelu on, sitä suurempi sen vasteaika on. Jos haluaa lyhyen vasteajan, fyysinen etäisyys kannattaa minimoida. Ideaalitilanteessa (ajatellen vasteaikaa) palvelu olisi käyttäjän kanssa samassa huoneessa, rakennuksessa tai kaupungissa. Pilvipalvelun tarjoajan valitsemista voikin harkita siis myös sen mukaan, että heillä on datakeskus Suomessa.

Vasteajat voivat aiheuttaa ongelmia, jos pilveen otetaan tietokantayhteyksiä. Jos palvelu on kaukana käyttäjästä, yhteyden avaaminen voi viedä pitkään. Olisi hyvä, jos tietokanta ja sitä tarvitseva ohjelmisto olisivat melko lähellä toisiaan. Ongelman kiertämiseksi voidaan käyttää esimerkiksi pgBouncer-ohjelmistoa, joka pitää tietokantaa koko ajan auki, ja avausviive voidaan välttää.

Osaamisvaatimukset

Sekä konesali että pilvialustat vaativat osaamista. Konesalissa on osattava ostaa ja konfiguroida palvelimia käsin tai vaikkapa Ansiblella. Pilvialustan käyttäminen vaatii, että osaa lukea alustan dokumentaatiota, tuntee erilaisia teknologioita ja ymmärtää palvelimien toimintaa. Käyttäjän pitää myös osata komentaa alustoja konekielellä, eli klikkailemalla konsoleita tai kirjoittamalla Terraformia tai jotain muuta kieltä, jolla voi automatisoida pilvipalvelun hallintaa. Kumpikin tapa vaatii siis erikoisosaamista.

Pilvialustojen automatisoituun hallintaan on useampia tapoja. Tähän käytetyistä Terraformista tai Pulumista ei ole hyötyä oman konesalin tapauksessa, mutta jos on palvelimia, konttialustoja, verkkoja, lokitusta ja muita palveluita tarjoava pilvipalvelu, niin esimerkiksi Terraform-kielellä voidaan automatisoida, mitä sinne halutaan luoda. Toinen vaihtoehto on klikkailla määritykset pilvipalvelun konsolissa, mutta silloin luonti ei ole automaattisesti toistettavissa, jos toimenpiteet haluttaisiin tehdä uudestaan.

Terraformilla sekä yksittäisten palvelimien konfigurointiin käytetyllä Ansiblella on kummallakin eräänlainen oma kielensä, mutta Pulumia voi käyttää haluamallaan ohjelmointikielellä. Ansiblen etu on, että sillä voi hallinnoida pilvipalvelussa olevia palvelimia samaan tapaan kuin oman konesalinkin palvelimia.

Hinta

Lasku tulee pilvialustoilla käytön mukaan ja lopullinen hinta riippuu siitä, mitä palveluita on valittu. Amazonin pilvipalvelu AWS:n tapauksessa alustalle maksetaan resursseista ja niistä palveluista, joita hallinnoidaan. Jokaiselle palvelulle on omat hinnastot, ja jokainen palvelu, mitä pilvestä tilataan, maksaa. Hinnastojen ilo ja kirous on siinä, että yhdistelmiä koneiden, palvelimien tehojen ja eri palveluiden automatiikan ym. muuttujien välillä on lukemattomia, ja niille jokaiselle on oma hintansa.

Laskun minimoimiseksi kannattaa pohtia, mitä palveluita tarjoaa, mille käyttäjäryhmille ja kuinka usein. Nämä vaikuttavat siihen, kannattaako palvelu toteuttaa palvelimella, konttialustana vai funktiona. Palvelin on koko ajan varattuna, ja jos sitä käytetään kerran vuodessa, niin se on paljon tyhjäkäynnillä. Jos taas prosessoritehoa tarvitaan koko ajan, palvelin tulee halvemmaksi. Satunnaisemmin käytettäessä kannattaa valita ratkaisu, jota voi tarvittaessa ajaa.

Toisaalta eri ohjelmistoilla on eri vaatimuksia mm. suorituskyvyn ja muistin suhteen, joten pienin (halvin) mahdollinen palvelin kullekin ohjelmistolle maksaa eri verran. Käytännön esimerkkinä: GeoServer vaatii koko ajan tietyn määrän muistia, vaikka sitä ei kukaan käyttäisi. Kustannuslaskelmissa toinen vaihtoehto on konesalissa oleva fyysinen kone.

Konesalit vai pilvipalvelu?

Olennainen ero pilvipalveluilla verrattuna konesaleihin on se, että pilvessä palveluita on helpompi hallinnoida. Tiettyjä ylläpitoon liittyviä asioita ei tarvitse tehdä fyysisesti itse: ei tarvita omaa konesalia, ei tarvitse miettiä, mihin serverit laitetaan pystyyn, eikä pystytystäkään tarvitse tehdä itse. Kaapeleiden vetämisen ja koneiden kantamisen sijaan palvelut syntyvät pilvialustalle näppäilemällä läppäriä (tai pöytäkonetta).

Erityisen käteviä pilvipalvelut ovat uusien asioiden kokeiluun. Uusien palveluiden pystyttäminen on helppoa, eikä fyysistä palveluiden hallinnointia tarvita. Meillä Gispollakin kokeiluhankkeet tehdään yleensä nimenomaisesti pilvialustalla.

Huonona puolena pilvessä on se, että palveluiden siirto pilveen voi tulla yllättävän kalliiksi. Jos ylläpidettäviin palveluihin on todella paljon liikennettä, voi olla vaikea arvioida koneiden tehokkuutta sekä ennakoida palvelinkuluja. Todella isoja laskentaresursseja tarvittaessa koneiden hankkiminen fyysisesti itselle voi tulla halvemmaksi. Tällöin tosin fyysiset työt joudutaan tekemään itse. Lisäksi konesalissa saa laitteita juuri sen verran kuin tarvitaan.

Startti kohti avoimen lähdekoodin siirtymää

Syke (Suomen Ympäristökeskus) on tehnyt siirtymää avoimen lähdekoodin ohjelmistoihin vuodesta 2019 alkaen. Ajatus avoimen lähdekoodin hyödyntämisestä on herännyt jo vuonna 2015 ja homma nytkähti Sykessä vakavammin liikkeelle vuonna 2019. Syke on ollut siis varsin aikaisin liikkeellä ja suurin työ siirtymän parissa on tehty vuosien 2021–2023 aikana. Avoimen lähdekoodin ohjelmistojen puolesta puhuvat monet hyödyt. Avoimen lähdekoodin myötä mahdollisuudet tietojen ja järjestelmien yhtenäistämiseen kasvavat, räätälöitävyys paranee, lisenssikustannuksia ei ole ja erilaisten standardien sekä INSPIRE-direktiivin vaatimukset ovat paremmin toteutettavissa, muutamia hyötyjä mainitaksemme. Gispon näkökulmasta Syken siirtymä avoimen lähdekoodin ratkaisuihin on valtavan mielenkiintoinen operaatio, ja halusimme haastatella Syken Digipalvelujen yksikön Geoinformatiikkajärjestelmien ryhmäpäällikköä Yki Lainetta aiheesta. Hän toimi projektipäällikkönä Alpakka-projektissa, jonka puitteissa avoimen lähdekoodin paikkatietojärjestelmään siirtyminen toteutettiin.

“Toki tämä on ollut iso muutos laittaa nämä uusiksi, mutta olemme huomanneet kasvavan trendin muissakin organisaatioissa avoimen lähdekoodin käyttöönoton suhteen. Olemme Sykessä tosin olleet jo aikaisessa vaiheessa liikkeellä. Järjestelmäuudistuksen lisäksi siirtymä vaatii myös käyttäjien koulutusta, ja koulutusprosessimme onkin käynnissä. Vielä jonkin aikaa meillä on rinnakkaiset järjestelmät käytössä eli siirtymä ei vielä aivan ole täydellinen.” Kertoo Yki.

Prosessi etenee tuen siivittämänä

Päätös siirtyä avoimen lähdekoodin ratkaisuihin vaati jonkin verran kypsyttelyä Sykessä, mutta prosessiin ollaan oltu tyytyväisiä kokonaisuudessaan. Avoimen lähdekoodin ohjelmistot eivät aiemminkaan olleet Sykessä vieraita, sillä käytössä on ollut jo pitkään mm. GeoServer INSPIRE-aineistojen ja satelliittiaineistotuotteiden rajapintajulkaisua varten. Vielä tämän ja ensi vuoden ajan Sykessä on QGISin ja GeoServerin kanssa rinnakkain käytössä rajoitetusti kaupalliset tuotteet. Kokonaan avoimen lähdekoodin pariin siirtymiseen on tarvittu ja tarvitaan vielä tukea sekä koulutusta.

“Gispolta olemme saaneet räätälöityä tukipalvelua avoimen lähdekoodin paikkatietoinfrastruktuurin käyttöönottoon. Meillä on myös oman asiantuntijamme tekemiä videotietoiskuja ja olemme käyneet Gispon koulutuksissa. Käymme myös Gispon kanssa säännöllisesti läpi koulutustarvettamme.”

Avoimen lähdekoodin käyttöönotossa on jouduttu miettimään turvallisuusluokitellun datan säilytysratkaisuja ja datan turvallisuuteen panostaminen korostuu entistä enemmän nykyisen maailmantilanteen vallitessa. Sykessä on avoimen lähdekoodin paikkatietoinfrastruktuurin siirtymässä noussut esiin yhä tärkeämpänä esimerkiksi erilaisten haavoittuvuusilmoituksien seuraaminen ja entistä tarkempi päivityksistä huolehtiminen. Avoimen lähdekoodin kanssa joutuu siis vieläkin enemmän paneutumaan turvallisuusluokitellun ja salassapidettävän datan suojaamiseen.

“Vastuuta on tässä meille enemmän kyllä siirtynyt. Tietoturva on kustannuksien lisäksi pidetty mielessä pohtiessamme datan mahdollista viemistä pilveen, mutta tämä asia on tosiaan ollut vasta ihan pohdinnan tasolla. Näitä samoja asioita joutuisi miettimään kaupallisten tuotteiden kanssa.”

“Nyt joudumme aktiivisesti seuraamaan esim. GeoServerin sivulta onko haavoittuvuuksia ilmennyt. Sekin on huono puoli, että haavoittuvuudet tulevat näin julki haavoittuvuuksia mahdollisesti hyödyntäville tahoille eli on toimittava mahdollisimman nopeasti.”

Oikea muutossuunta

Näin ison muutoksen kohdalla ongelmien ennakointi voi olla hankalaa ja kyseessä on koordinoinnin kannalta monen ryhmän työn summa. Aluksi siirtymässä arvelutti resurssien riittävyys, tarvitaanko ihmisiä enemmän ja miten saadaan kiinnitettyä oikeat henkilöt.

Siirtymän haasteeksi Sykessä on koettu ohjelmistojen lisäosien asennukset ja niiden yhteentoimivuus Sykessä käytössä olevissa ohjelmaversioissa, kun on siirrytty pois yhdestä tuoteperheestä. Ylläpidosta on sitä myöten tullut työläämpää ja päivityksistä tulee huolehtia aiempaa enemmän. Toisaalta on hyvä, että uusia ominaisuuksia tulee nopeaan tahtiin. Syke toivoisi myös avoimen lähdekoodin ohjelmistojen dokumentaatioon lisää viilaamista. Avoimen lähdekoodin siirtymä on ollut erittäin iso asia koko organisaatiolle, mutta kokonaisuutena siirtymää pidetään Sykessä oikeana suuntana.

“Tuntuu kyllä, että muutos on otettu hyvin vastaan ja useiden muiden valtion organisaatioiden mukana oleminen on myös helpottanut tätä asian sulattelua. EU:sta on saatu suosituksia avoimen lähdekoodin käyttöönottoon, mikä antaa hyvän selkänojan meille. Olemme saaneet ihmiset mukaan hyvin tähän muutokseen ja oikean valinnan olemme ehdottomasti tehneet!”

Syke on mainio esimerkki siitä, miten isokin organisaatio voi rakentaa infrastruktuurinsa avoimen lähdekoodin varaan. Seuraamme mielenkiinnolla, mitkä organisaatiot lähtevät seuraamaan Syken esimerkkiä!

Tämän artikkelin on kirjoittanut Anni Jusslin