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. 

Me Gispolla haluamme olla asiakkaidemme tukena kaikissa paikkatietopulmissa. Tätä tarkoitusta varten meillä on tukipalvelu, jonka kautta asiantuntijamme vastaavat päivän vasteajalla, yleensä jo alle kahdessa tunnissa. Kaikille jatkuva tukipalvelusopimus ei kuitenkaan ole tarpeen, vaan kertaluontoinen apu riittää. Joskus kertaluontoisen tuen tarve on hyvin kiireellinen ja siksi tarjonnassamme on myös palvelu nimeltä SOS-tuki. SOS-tuen myötä asiantuntijamme auttaa juuri käsillä olevassa ongelmassa yksilöllisesti asiakasta kuunnellen.

Tänä keväänä Joensuun kaupungin viherrakentamisen työnjohtaja Heidi Keskitalo oli paikkatietotuen tarpeessa ja kääntyi Gispon puoleen:

Työskentelen puistojenhoitoyksikössä ja talvisin, kun rakentamista ja siihen liittyviä tehtäviä on vähemmän, teen karttoja kaupungin viheralueiden hoidosta. Aikaisemmin kartat väritettiin käsin, mutta halusimme siirtyä nykypäivään ja lähdimme etsimään ohjelmaa, joka palvelisi meitä tässä asiassa parhaiten. Tällä tavalla löytyi QGIS, joka on osoittautunut erittäin hyväksi ohjelmaksi. 

Alkuperäisenä ajatuksena oli tehdä karttoja, joista selviää nurmenleikkuualueet. Kun QGIS tuli tutummaksi, aloin kartoittamaan sen avulla muitakin kohteita, kuten murskaus- ja hiekanpoistoalueita, roskisten määrää yms. Teen ohjelman avulla nykyisin myös rakennuskohteideni liikennesuunnitelmat ja uusia projekteja näyttäisi olevan edelleen tulossa!

QGIS on monipuolinen ohjelma. Jopa niin monipuolinen, että sen haltuunotto voi olla aika työlästä näppärämmällekin tietokonenikkarille, saatikka sitten minunlaiselleni tavan tallaajalle. SOS-tuen ansiosta sain loistavia neuvoja työni helpottamiseksi asioissa, jotka olin aikaisemmin tehnyt vaikeamman kautta. Tällaisia neuvoja tuli paljon erityisesti alueiden piirtämiseen ja muokkaamiseen liittyen. Sain myös apua alueiden mittaamiseen ja karttojen taittoon. Ohjelman avulla saan nyt laskettua näppärästi leikattavat nurmipinta-alat ja vaikkapa erilaisten roskisten määrät. 

Aina kaikki ei toimi niin kuin pitäisi ja erityisesti tällaisissa tilanteissa SOS-tuki on erittäin toimiva ratkaisu. Minun kohdallani suurin ongelma palvelua käyttäessäni oli, että tason pinta-ala ei päivittynyt oikein, vaikka kaava olikin oikein kirjoitettu. Itse en olisi osannut asialle tehdä mitään ja mikäli en olisi saanut tilanteeseen apua, olisi ohjelman käyttö todennäköisesti ainakin vähentynyt, jollei kokonaan loppunut. 

Tiivistettynä: Sain tuen avulla ongelmani ratkaistua ja erittäin tervetulleena lisänä sain myös tärkeitä neuvoja, joita en edes osannut pyytää!

SOS-tuki oli minulle toimivin ratkaisu, sillä avuntarpeeni on ajoittaista, joten ympärivuotisen palvelun ostamiselle ei ollut tarvetta. Yhteydenpito oli helppoa, sain apua heti kun sitä tarvitsin ja omalle osaamistasolleni sopivasti räätälöitynä. 

Yhteydenoton jälkeen jäi luottavainen olo, että nyt tämä taas onnistuu – ja on kyllä onnistunutkin!
– Heidi Keskitalo

Lue lisää Gispon tukipalveluista täällä ja tilaa omasi.

Tämä kevät on mennyt demoillessa asiakkaille, miten työn alla oleva kaavoitussovelluksemme toimii. Meillä on ollut ilo ja kunnia olla mukana nyt jo kolmessa Ympäristöministeriön rahoittamassa Ryhdin kumppanitestaushankkeessa ja iso toive on, että tänä vuonna päästään jo maaliin. 

Työnimellä Arho (Avoimen lähdekoodin kaavoituksen Ryhti-sovellus) kulkeva työkalu rakentuu vahvasti QGISin perustoiminnalisuuksien päälle. QGISiä käytetään jo erityisesti yleiskaavoituksen puolella mutta myös maakuntakaavoituksessa ja asemakaavoituksessa. Arho-sovellus tuo QGISiin Maankäyttö- ja rakennuslain uudistamisen myötä tarvittavat työkalut kaavoittajan käyttöön, jotta kaavoitusta voidaan tehdä lain vaatimalla tavalla. Laki rakennetun ympäristön tietojärjestelmästä astui voimaan 1.1.2024 ja viimeistään vuonna 2029 kaavojen tulee olla Syken ylläpitämän Ryhti-järjestelmän kautta saatavilla.

Työ on ollut valtava ja vielä on tuotantoversioon hetki matkaa. Nyt kuitenkin on mahtavaa sanoa, että “Kyllä! Ryhtiin saadaan Arholla kaava vietyä!”. 

Osalle kaavoittajia Ryhti on ollut hähmäinen ja ehkä vähän pelottavakin uudistus ja ei ihme! Muutos tuo täysin uutta ajattelutapaa ja tietoja käsitellään eri tavoin. Mahdollisuutena Ryhdissä on, että kun kaava-aineistot vihdoin saadaan yhteisessä muodossa käyttöön, vapauttaa se varmasti resursseja turhasta tiedon käsittelystä ja edestakaisin muokkauksesta, ja niin kaavoittajien kuin kaava-aineostoja tarvitsevienkin työ tehostuu.

Mutta mitä se Ryhti käytännössä muuttaa kaavoittajan työssä. Käyn tämän läpi meidän Arho-sovelluksemme kautta:

Kaavan ulkorajalle perustiedot

Kaavan ulkorajaan pitää liittää perusominaisuuksien lisäksi esimerkiksi dokumenttitietoja ja tietysti tarvittavat dokumentit vaihtelevat sen mukaan, missä vaiheessa kaavoitusta ollaan. Alla olevan kuvan tapauksessa Kaavaehdotukselle pitää lisätä OAS-dokumentti eli Osallistumis- ja arviointisuunnitelma, joka esittää miksi kaava laaditaan ja miten kaavoitus etenee. Lisäksi kaavasta pitää toimittaa myös kaavakartta GeoTIFF-muodossa.

Kaavakohteet ovat paikkatietokohteita

Kaavakohteiden geometriat on fiksattu eli paikkatietotasoja on jatkossa vain 5–6 (riippuen kaavatasosta) ja esimerkiksi aluevaraukset luokitellaan ja visualisoidaan niihin liittyvien ominaisuustietojen avulla. Niille on omat topologiset säännöt riippuen kaavatasosta. Esimerkiksi yleis- ja asemakaavatasoilla aluevarausten pitää peittää kaavan alue kokonaan ja ne eivät saa mennä toistensa kanssa päällekkäin. Maakuntakaavojen osalta aluevarausten ei tarvitse täyttää koko kaavaa.

Kaavakohteilla on aina kaavamääräysryhmä

Kaavakohteisiin ja kaavan ulkorajaan liitetään aina 1 tai useampi kaavamääräys. Niistä muodostuu aina ns. kaavamääräysryhmä, joka linkittyy kaavan ulkorajaan tai kaavakohteiden geometrioihin. Tämä on isoin muutos ja vaatii eniten opettelua kaavoittajilla. Arho-sovellukseen on tuotu jo nyt kaikki lakiin liittyvän nk. Katja-asetuksen mukaiset kaavamääräysryhmät, joten kaavatyön aloittaminen on helppoa. Omia kaavamääräysryhmiä voi myös luoda, mutta niissä pitää huomioida Katja-asetuksen ja Ryhdin säännöt. Alla olevassa ryhmässä on valmiiksi luotu Katja-asetuksen mukainen ryhmä nimeltä Retkeily- ja ulkoilualue. Huomioitavana on paljon sääntöjä ja kaavoittajalla menee varmasti hyvä tovi niiden opetteluun, esimerkiksi pistemäisille kaavakohteelle voi antaa vain tiettyjä kaavamääräyksiä. Toki pyrimme siihen, että Arho ohjaisi kaavoittajaa mahdollisimman paljon, mutta varmaa on, että tässä vaaditaan myös kaavoittajan ammattiosaamista luoda järkeviä kaavamääräysryhmiä.

Ryhti vaatii validia kaavaa

Työn aikana kaavatiedot validoidaan ja lopulta viedään Ryhti-järjestelmään. Kaavatietojen pitää siis olla juuri Ryhdin tarvitsemassa muodossa, jotta ne voidaan tallentaa Ryhti-järjestelmään. Esimerkiksi jos jokin dokumentti puuttuu tai jokin pakollinen tieto on kirjaamatta, validoinnista tulee herjaa. Useimmiten ongelmat ovat topologiassa tai kaavamääräysryhmä on tehty väärin ja tästä syystä kaava ei mene läpi. Arhossa validointi voidaan toteuttaa suoraan QGISissä. Ryhtiin vienti tapahtuu joko Palveluväylän kautta (joka on haluttaessa osa Arho-sovellusta) tai kaavoittaja voi tallentaa kaavan tiedostomuodossa ja viedä sen käsin Ryhdin selainpohjaiseen palveluun. Suosittelemme palveluväylän käyttöönottoa, sillä se helpottaa huomattavasti testailua ja käyttöä.

Kehitys jatkuu vielä mutta demoilla jo voi!

Vielä on kuitenkin kehitettävää. Tänä vuonna Arhoon on tulossa paljon pienempiä parannuksia  ja valmistelemme sitä tuotantoon kehittämällä erityisesti käyttäjähalllintaa ja elinkaaren hallintaa. Visualisoinnit ja valmiit kaavan layoutit ovat olleet myös kovasti toiveissa saada mukaan.

Mielelläni demoilen ja kerron toteutuksesta lisää. Demoiluajan voi varata suoraan kalenteristani. Tarjoamme kehitysvaiheiden jälkeen Arhoa palveluna ja kerron tästä myös demoilun ohessa lisää. 

Kumppanitestaushankkeille jo iso kiitos tässä vaiheessa, vaikka homma jatkuu vielä!

• Varsinais-Suomen liiton vetämä maakuntien kumppanitestaushanke (10/2023-03/2025), mukana Uudenmaan liitto, Kymenlaakson liitto
• 0sKaTi-hanke Paimion kaupungin vetämä kuntien kumppanitestaushanke (06/2024-09/2025), mukana Joensuu, Tyrnävä, Asikkala, Sulkava, Heinävesi, Plandisain Oy sekä Asiantuntija N+1 Oy ja Et May Oy.
• MALTTI-hanke Varsinais-Suomen liiton, Lapin liiton ja Hämeen liiton kumppanitestaushanke (04/2025-)

Kuvittele tilanne: kunnossapitoyksikkö saa kuntalaispalautteen huonokuntoisesta tiestä tai painuneesta kaivonkannesta kaupungin toiselta laidalta. Aikaisemmin vaihtoehdot olivat rajalliset – joku lähetetään tarkistamaan tilanne paikan päälle. Entä jos olisi mahdollista tarkistaa tilanne suoraan työpöydän äärestä koneelta – lähes kuin olisi paikan päällä?

Mikä ihmeen katunäkymäkuvaus?

Katunäkymät lienevät monelle tuttuja ainakin Googlen Street View-palvelusta. Kyseessä on siis visuaalinen esitys kaduista ja kulkureiteistä sekä niiden varrella olevista rakennuksista ja muusta infrastruktuurista ja ympäristöstä. Katunäkymät tuotetaan valokuvien ja videoiden avulla. Katunäkymien avulla käyttäjä voi lähteä virtuaaliselle kävelylle tai ajelulle katselemaan, miltä paikat näyttävät. Rakennettu ympäristö ja etenkin kaupungit kehittyvät ja muuttuvat koko ajan, joten katunäkymät vanhenevat nopeasti. Esimerkiksi Street View sisältää pahimmillaan yli 10 vuotta vanhaa aineistoa.

Mapillary on Ruotsissa kehitetty katunäkymien tallennuspalvelu, jonne käyttäjät voivat ladata itse ottamiaan kuvia katunäkymistä.  Mapillary on kasvanut globaaliksi avoimen datan kuvauspalveluksi. Jos kunnalla on käytössä oma kalusto ja Mapillary, se voi itse päättää, mitä ja milloin kuvataan – ja päivittää katunäkymät vaikka vuosittain. Mapillaryn avulla katunäkymätietoja ympäristöstä voi kerätä  ilman raskasta kalustoa ja kamera-autoja. Näin kuvamateriaalia voidaan kerätä myös luontopoluilta ja pyöräteiltä. Joukkoistamalla katunäkymäkuvaukset tehdään kuntalaisten kamerakännyköillä tai GPS:llä varustetuilla action kameroilla – tarvitaan vain vähän muistia ja liikkumisen iloa.

Katunäkymäkuvaus tuo kadut ja kohteet työpöydälle

Katunäkymien kuvaaminen vaikka action-kameralla ja lataaminen palveluun tuo koko alueen visuaalisesti selattavaksi suoraan selaimeen. Mapillary tarjoaa myös edistyneempiä toimintoja, kuten automaattisen kohteiden tunnistuksen: se tunnistaa kuvista automaattisesti esimerkiksi liikennemerkit, roskikset, valopylväät ja muita rakennetun ympäristön kohteita. Tämä data on saatavilla paikkatietomuodossa koordinaatteineen ja ominaisuustietoineen, mikä nopeuttaa tiedon hyödyntämistä ja tukee infraomaisuuden paikkatietopohjaista hallintaa.

Espoo ja Nurmijärvi katunäkymien edelläkävijöinä

Espoossa ja Nurmijärvellä on jo kokeiltu tätä käytännössä. Espoon pyörätiepilotti ja luontopolkujen kartoitus Nurmijärvellä osoittavat, että katunäkymäkuvien avulla voidaan nopeasti kerätä kattava näkymä infraan – oli kyse sitten kevyen liikenteen väylistä tai metsäreiteistä.

Katunäkymäkuvaus maksaa itsensä nopeasti takaisin

Kuvavaamiseen sopiva kalusto – esimerkiksi action-kamera, autoteline ja muut lisätarvikkeet – maksavat alle 1000 euroa. Tällä kalustolla saa kuvattua vaikka pienen kunnan koko tiestön nopeasti ja kattavasti. Kuvausreissut voi myös yhdistää muuhun työliikkumiseen, tai kameran voi kiinnittää vaikka polkupyörään. Haluttaessa tämä on helppo myös joukkoistaa kuntalaisille tai hankkia talkootyönä vaikka urheiluseuralta.

Upotus katunäkymästä

Kuvamateriaali toimii tukena niin kunnossapitotarpeiden arvioinnissa, kunnallistekniikan suunnittelussa kuin asiakaspalautteiden käsittelyssäkin. Mapillary-kuvat ovat helposti jaettavissa myös ulkopuolisille: kuntalaisille, urakoitsijoille tai yhteistyökumppaneille. Näin sama ajantasainen näkymä on kaikkien käytettävissä – ilman lisenssimaksuja tai teknisiä esteitä.

Kuvaus muiden matkojen ohessa säästää erillisiltä kuvausmatkoilta ja kuolettaa nopeasti kaluston hinnan. Kun sovelluksesta pystyy tarkistamaan, missä kaivonkansi, liikennemerkki tai valopylväs sijaitsee – ja millaisessa kunnossa se on – ei tarvita enää arvailua tai karttojen selaamista. Katunäkymät tukevat myös koneoppimista ja automaattista kohteiden tunnistamista, mikä tekee tulevista kartoituksista entistä tehokkaampia.

Katunäkymät ovat käytettävissä heti, kun ne on ladattu palveluun. Katunäkymien hyödyntäminen ei edellytä raskaita ohjelmistoasennuksia tai GIS-osaamista, sillä käyttöliittymä toimii internetselaimessa.

Katunäkymäkuvauksen monipuoliset mahdollisuudet ja käyttötapaukset

Mapillaryn käyttö tarjoaa kunnille ja muille toimijoille monipuolisia mahdollisuuksia. 

• Koulujen oppilaat voivat kuvata ympäristöään opettajien ohjaamina esimerkiksi opetuksen tai ympäristökasvatuksen tueksi. 
• Uusille opiskelijoille voidaan järjestää teemapäiviä, joissa kampusalueita kuvataan ja tutustutaan samalla uuteen ympäristöön. 
• Yhdistysten ja kaupungin välistä vuorovaikutusta voidaan kehittää tarjoamalla visuaalista näkymätietoa yhteisen keskustelun pohjaksi. 
• Matkailijat voidaan innostaa tutustumaan alueeseen kilpailun tai kampanjan avulla, jossa he kuvaavat suosikkikohteitaan. Koulumatkojen arviointi, yhteistyö postin tai taksien kanssa reittitiedon keruussa, ja jopa sisätilojen kuvaaminen ovat kaikki mahdollisia käyttökohteita – osa vaatii enemmän valmistelua, mutta teknologia taipuu moneen. 
• Mapillary toimii myös hyvänä työkaluna kaupunkisuunnittelun tukena esimerkiksi viitoitusten ja rakennetun ympäristön tarkastelussa.

Miten Gispo voi auttaa katunäkymäkuvauksessa?

Katunäkymäkuvaus on helppo, edullinen ja nopeasti itsensä takaisinmaksava tapa parantaa infrastruktuurin hallintaa. Kun tieto on ajantasaisesti näkyvissä, päätökset ovat parempia ja työskentely tehokkaampaa.

Gispo auttaa mielellään alkuun katunäkymäkuvauksessa Järjestämme työpajoja ja koulutuksia esimerkiksi kaupunkien henkilöstölle, aktiivipyöräilijöille tai muille kiinnostuneille kaupunkilaisille. Opastamme Mapillaryn käytössä ja näytämme, miten kuvaaminen ja näkymien hyödyntäminen onnistuu käytännössä. Autamme integroimaan kuvat osaksi muita järjestelmiä. Lisäksi autamme suunnittelemaan ja toteuttamaan joukkoistamiskampanjoita, joilla saadaan kartoitettua esimerkiksi pyörätieverkosto, puistoreitit tai muu paikallinen infra – yhdessä asukkaiden kanssa.

Kysy lisää – laitetaan yhdessä infra näkyväksi ja käyttöön!

QGISiä kehitetään jatkuvasti, ja ohjelmistosta ilmestyy uusia versioita läpi vuoden. QGISin uudet versiot tuovat aina lisää kaivattuja ominaisuuksia ja korjaavat edellisten versioiden bugeja. Myös me Gispolla olemme osallistuneet QGISin bugikorjauksiin.

QGISin versioiden julkaisuprosessi on systemaattinen ja hyvin suunniteltu, mikä varmistaa sekä uusien ominaisuuksien jatkuvan kehittämisen että ohjelmiston vakauden. Käyttäjille on kuitenkin usein epäselvää, miten ja milloin QGIS-versioita julkaistaan, joten avaan prosessia tässä blogissa tarkemmin.

QGISin eri julkaisuversiot

QGISista on olemassa kolme erilaista pääversiota: Long-Term Release (LTR), Latest Release (LR) ja Development.

Long-Term Release (LTR)

LTR-versioita (“pitkäaikaistuettuja”) julkaistaan yleensä yksi vuodessa, ja se tapahtuu aina helmikuussa. Long-Term Release (LTR) on suunniteltu käyttäjille, jotka tarvitsevat vakautta ja luotettavuutta pitkäaikaiseen käyttöön. Se tarjoaa testatun ja vakaan ympäristön, ja kunkin LTR-version tuki kestää noin 12–18 kuukautta.

Kun uusi LTR-versio on julkaistu, versioon tehdään vain kriittisiä bugikorjauksia. Uudet ominaisuudet tuodaan mukaan vasta seuraavaan LTR-julkaisuun. 

LTR sopii tuotantokäyttöön organisaatioille, projekteihin ja koulutukseen, kun ohjelmiston ennakoitavuus on tärkeää. Myös me Gispolla suosittelemme peruskäyttäjille LTR-versioita niin työtehtäviin kuin koulutuksiinkin.

Latest Release (LR)

QGISin Latest Release (LR) sisältää uusimmat ominaisuudet ja parannukset. Tämän vuoksi se on täydellinen valinta käyttäjille, jotka haluavat pysyä teknologian kärjessä ja kokeilla uusia työkaluja ensimmäisten joukossa. 

LR-versio päivittyy noin neljän kuukauden välein ja tarjoaa pääsyn QGIS-kehittäjien tuoreimpiin innovaatioihin. Vaikka versio voi olla hieman vähemmän vakaa kuin Long-Term Release, se sopii erinomaisesti uusien toimintojen testaamiseen ja edistyneeseen käyttöön.

Development-versio

Development-versio on jatkuvasti kehittyvä ohjelmiston testiversio, joka sisältää uusimpia ja vielä keskeneräisiä ominaisuuksia. Versio on suunnattu kehittäjille ja edistyneille käyttäjille, jotka haluavat osallistua ohjelmiston testaamiseen ja kehittämiseen. 

Development-versio ei ole vakaa eikä suositeltu tuotantokäyttöön, mutta tarjoaa mahdollisuuden tutustua tuleviin toimintoihin ennen niiden virallista julkaisua.

Kehityssykli

QGIS-julkaisujen aikataulua pystyy seuraamaan QGISin sivuilla olevan Road Mapin eli julkaisuaikataulun avulla. Tämä “tiekartta” sisältää suunnitellut julkaisuaikataulut sekä tietoa tulevista ominaisuuksista. QGIS-tiimi noudattaa suunniteltua julkaisuaikataulua, joka pitää sisällään sekä säännöllisiä päivitysversioita että pitkäaikaistuettuja LTR-versioita. 

QGISin kehitys kulkee neljän kuukauden sykleissä. Uusi QGISin versio (Latest release) julkaistaan joka neljäs kuukausi. Julkaisun jälkeen ensimmäisten kolmen kuukauden aikana kehitetään uusia ominaisuuksia, kunnes viimeisenä eli neljäntenä kuukautena otetaan käyttöön ominaisuuksien jäädytys (Feature Freeze). Käytännössä tällöin työversiot muutetaan esijulkaisuiksi. 

Ominaisuuksien jäädytysvaihe on olennainen osa kehitysprosessia. Silloin uusia ominaisuuksia ei enää sallita, ja kaikkien keskittyminen siirtyy ohjelmiston parantamisesta sen vakauttamiseen, testaamiseen, bugikorjauksiin, kääntämiseen ja julkaisun valmisteluihin. Tässä vaiheessa käyttäjien on hyvä aloittaa esijulkaisujen laaja testaus omassa ympäristössään, jotta voidaan varmistua, ettei tulevaan julkaisuun päädy ongelmia, jotka löytyisivät käytössä myöhemmin.

Kaikki jäädytysvaiheessa havaitut ongelmat tulisi raportoida, sillä huomaamatta jääneet ongelmat päätyvät seuraavaan julkaisuun. Vain vakavien ongelmien tapauksessa tehdään taaksepäin yhteensopivia korjauksia uusimpaan julkaisuun ja siksi esijulkaisujen testaaminen ja ongelmien raportointi on erittäin tärkeää. Kehittäjät seuraavat bugiraportteja, korjaavat raportoituja ongelmia sekä päivittävät visuaalisen muutoslokin lisäämillään ominaisuuksilla. Ominaisuuksien jäädytyksen alkaessa myös QGISin käännöstiedostot päivitetään, jotta kääntäjät voivat aloittaa työnsä.

Kaksi viikkoa ennen julkaisua aloitetaan tiukempi jäädytys (hard freeze), jonka jälkeen sallitaan vain vakavien ongelmien ja jäädytyksen jälkeen ilmenneiden virheiden korjaukset.

Neljän kuukauden välein julkaistavan Latest Release -version lisäksi QGISistä julkaistaan pienempiä päivityksiä eli korjausversioita noin kuuden viikon välein, ja ne keskittyvät bugikorjauksiin ja parannuksiin ilman suuria muutoksia käyttöliittymään tai ydintoimintoihin.Käytännössä neljän kuukauden kehityssykli tarkoittaa sitä, että kun helmikuussa julkaistaan uusin Long Term Release, on sen testausvaihe alkanut lokakuussa. Jos siis organisaatiossanne päivitetään QGIS aina vuosittain uuteen LTR-versioon, voitte jo lokakuusta alkaen osallistua sen testaukseen ja bugiraportointiin. Tänä vuonna lokakuu on erityisen kiinnostavaa aikaa, sillä QGIS siirtyy 4.0-versioon, mutta siitä lisää myöhemmin!

Tunnetusta maailmasta laadittujen karttojen ja rakennuspiirrosten historia ulottuu kauas menneisyyteen. Vanhimmat tunnetut (ainakin sikäli kuin tätä kirjoittaessa  tiedetään!) pohjapiirrokset kuvaavat ansapyydystysjärjestelmiä Jordaniassa ja Saudi-Arabiassa ja ne kaiverrettiin kiveen noin 7 000 eaa. Vanhin tunnettu topografinen kartta on huomattavasti nuorempi, mutta silläkin on ihan kivasti ikää. Sitä voi poiketa katsomaan Torinossa. Sikäläisessä egyptiläisen kulttuurin museossa on näyttillä kivilouhosta kuvaava papyryskartta, joka piirrettiin noin 1 200 eaa. 

Kaivertaminen kiviin on jo jäänyt kauas taakse, ja kynä ja paperikin ovat vaihtuneet CAD-, BIM- ja GIS-työkaluihin. Mutta ovatko perustarpeet oikeastaan muuttuneet? Haluamme edelleen rakentaa uutta, muokata olemassa olevaa ja tutkia maailmaa horisontin molemmin puolin – sekä dokumentoida työn tulokset.

Fyysisessä todellisuudessa kulmikkaat rakennukset ja kumpuilevat maastonmuodot elävät yhdessä kohtuullisen sopuisasti, mutta digitaalisessa maailmassa ne eivät aina kohtaa saumattomasti.

Rakennus- ja yhdyskuntasuunnittelun, kunnallisen kaavoituksen, kaupunkisuunnittelun ja ympäristövaikutusten arvioinnin parissa työskentelevien ammattilaisten yhteistyön tarve ei myöskään ole katoamassa. 

Eri työkaluja käyttävien asiantuntijoide yhteistyön helpottamiseksi olemme keränneet tähän blogiin käytännön vinkkejä CAD-, BIM- ja QGIS-ohjelmistoja käyttäville.

CAD, BIM ja GIS – mitä ne ovat?

Yhteiset termit auttavat yhteistyötä. Yksinkertaisuuden vuoksi jatkossa käytetään yläkäsitteenä termiä “CAD-aineisto” kun viitataan dataan, joka on tallennettu  .DGN-,  .DWG-, .RVT- ja .DXF-formaateissa.

CAD

CAD (Computer Aided/Assisted Design) on joukko ohjelmistoja, jota arkkitehdit ja insinöörit käyttävät monimutkaisten 2D- ja 3D-mallien, kuten rakennusten ja infrastruktuurin, suunnitteluun. CAD-ohjelmistojen tuottamat tiedostot koostuvat nimetyistä piirustustasoista, joita voivat olla näkyvissä ja piilotettuna. CAD-piirustukset voidaan tulostaa paperille tai tallentaa PDF-muodossa, jotta eri alojen asiantuntijat voivat hyödyntää niitä toteutusvaiheessa.

Haasteena on, että perinteinen piirustus on varsin staattinen, olipa se sitten digitaalista tai ei, vaikka tasojen määrää voikin lisätä. Projektin edetessä ja eri asiantuntijoiden työskennellessä yhdessä versionhallinnasta voi tulla ongelmallista. Lisäksi CAD-ympäristössä voidaan käyttää paikallisia koordinaattijärjestelmiä, joissa origo on esimerkiksi tontin kulmassa. Tämä aiheuttaa hankaluuksia, kun dataa halutaan yhdistää yleisesti käytettyihin koordinaattijärjestelmiin.

BIM

Monet ovat siirtyneet käyttämään CADin sijaan tai asteittain sen rinnalla BIM-mallinnusta. BIM (Building Information Modelling) on kehittyneempi suunnittelutapa, jossa koko rakennushanke mallinnetaan 3D-muodossa. BIM-malli toimii virtuaalisena tietokantana koko rakennuksen elinkaaren ajan. Se sisältää lisäksi paljon attribuuttitietoja, kuten materiaaleja ja elinkaaritietoja. Mallista voidaan milloin tahansa tuottaa ajantasaisia 2D- ja 3D-piirustuksia.

BIM-konseptiin liittyy myös ”digitaalinen kaksonen” -ajattelu, jossa fyysinen rakennus ja sen digitaalinen malli pidetään synkronoituna koko rakennuksen elinkaaren ajan. 

Myös BIM-maailmassa työskennellään joskus omassa, erillisessä koordinaattijärjestelmässä, jolloin ulkopuolisten aineistojen yhdistäminen BIM-malliin aiheuttaa haasteita. 

GIS

GIS GIS (Geographical Information System) juontaa juurensa perinteisiin paperikarttoihin, jotka olivat aikoinaan eri tavoilla kerätyistä paikkatiedoista jalostettu lopputuote. Digitaaliset työkalut omaksuttiin kuitenkin nopeasti, sillä maailma muuttuu jatkuvasti ja karttoja on päivitettävä. CAD- ja GIS-järjestelmissä piirretään karttakohteiden geometria (pisteet, viivat, alueet) eri tasoille, joilla on kuvaavat nimet. GIS:ssä on lisäksi mahdollista liittää suuri määrä ominaisuustietoa (attribuutteja) kuhunkin kohteeseen mikä mahdollistaa monipuoliset analyysit ja erilaisten karttaesitysten luomisen samasta aineistosta. Kaikkea tietoa ei aina kannata näyttää kerralla!

Esimerkiksi karttatasolla ”Puut” voi olla pisteinä esitettyjä puita, joihin on liitetty tietoa lajista, iästä, kunnosta, inventointipäivämäärästä ja koordinaateista. Viiva- ja aluekohteilla voi puolestaan olla pituus- ja pinta-ala-attribuutteja. GISin periaate, jossa graafiset objektit linkitetään dynaamisesti taulukkotietoon, muistuttaa BIM-logiikkaa.

GIS eroaa CAD- ja BIM-järjestelmistä erityisesti koordinaattijärjestelmien osalta. GIS:ssä tunnetut koordinaatit ovat välttämättömiä, jotta eri lähteistä peräisin olevat aineistot, kuten korkeusaineistot, ortoilmakuvat, ympäristön tilaan ja suojeluun liittyvä tieto, kiinteistörajat, rakennukset ja historialliset kartat voidaan yhdistää. Kun karttatasot tallennetaan yleisissä koordinaattijärjestelmissä, ne asettuvat automaattisesti oikein toisiinsa nähden.

Aineistoformaatit 

QGIS tukee satoja tiedostoformaatteja, tarkemmin sanottuna kaikkia formaatteja jotka kuuluvat GDAL/OGR-kirjaston valikoimiin. Eräs kollega kiteyttää tämän napakasti toteamalla, että QGISillä saa avattua kaiken paitsi suljetut formaatit ja isoäidin hillopurkit.

Osa CAD-formaateista on juuri tällaisia suljettuja formaatteja joiden lisenssiehdoista johtuen niitä ei voi avata ja käyttää avoimen lähdekoodin ohjelmistoissa kuten esim. QGISissä.

Formaatti	Huomioita
.DXF (“Drawing Exchange Format”)	Formaatti, jonka kehitti AutoDesk Inc. Tarkoituksena helpottaa aineistojen siirtoa AutoCAD-ohjelman ja muiden piirustusohjelmien välillä.Suositeltavin tiedostomuoto, kun CAD-aineistoja halutaan tuoda QGISiin.
.DWG (”Drawing”)	AutoCAD-ohjelman (AutoDesk Inc) oma formaatti.  Tietyt, vanhemmat versiot DWG-tiedostoista voidaan tuoda QGIS:iin. Uusimmat versiot (2018, 2019, 2020) eivät toimi.
.RVT(“Revit”)	Autodesk Revit -ohjelman (AutoDesk Inc) oma formaatti.Suljettu formaatti. Tässä muodossa oleva data täytyy tallentaa ensin .DXF-tieodostoksi ennen kuin sen voi tuota QGISiin.
.DGN (”Design”)	Microstation-ohjelman (Bentley Inc) oma formaatti.Mikäli aineisto on talletettu DGN-formaatin versiossa 7 tai aikaisemmassa versiossa, sen voi tuoda QGIS:iin. Uudemmat versiot alkaen versiosta 8 eivät enää toimi.

Pähkinänkuoreen tiivistettynä voi sanoa: aina kun mahdollista, pyydä saada aineistot .DXF-muodossa. Mikäli se ei ole mahdollista, netistä löytyy useita maksuttomia  muunnosohjelmia yksinkertaisen haun avulla.

Ja sitten teoriasta käytäntöön – neljä askelta!

CAD-aineiston tuominen QGISiin

Koska CAD- ja GIS-ohjelmistot perustuvat erilaiseen logiikkaan, dataa ei voi vain ”avata” QGISissä, vaan se on tuotava sinne oikeilla asetuksilla. Tässä tulee olla tarkkana, sillä tiedostojen muuntamisessa on aina vaara menettää joitakin tietoja.

Datan tuominen tapahtuu varmimmin QGISin päämenun kautta: Projekti -> Tuo/vie -> Tuo tasoja  DWG/DXF-tiedostoista. 

Tämän menetelmä etuna on se, että käyttäjä pystyy esikatselemaan CAD-aineiston piirtotasot ja valitsemaan mitkä niistä halutaan tuoda QGIS:iin. Muutamia erikoistapauksia on, mutta selkeyden vuoksi säästetään ne vinkit myöhemmäksi. 

Aineisto tallennetaan GeoPackage-formaatissa (.gpkg) ja sille annetaan koordinaattijärjestelmä, minkä jälkeen se voidaan avata QGIS:issä.

Oikean koordinaattijärjestelmän asettaminen QGISissä 

Kun CAD-data tuodaan QGISiin, on tärkeää tietää CAD-tiedoston koordinaattijärjestelmä ja määrittää se QGISissä. CAD-tiedoston laatijan tulisi tietää, mitä koordinaattijärjestelmää on käytetty, ja ilmoittaa se tiedostoa eteenpäin lähetettäessä. Jos olet epävarma koordinaattijärjestelmästä, kysy mieluummin kuin arvaa.

On hyvä idea asettaa koordinaattijärjestelmä sekä yksittäiselle karttatasolle että koko QGIS-projektille (Projektin ominaisuudet -> Koordinaattijärjestelmä).

Jos CAD-tiedostoa ei ole luotu yleisesti tunnetussa koordinaattijärjestelmässä, vaan siinä on paikallinen nollapiste, esimerkiksi ”vasemman alakulman” kohdalla, syntyy ongelmia. Tällöin aineisto päätyy todennäköisesti keskelle valtamerta tai väärälle mantereelle. CAD-tiedoston sijoittaminen oikeaan paikkaan vaatii tunnettujen viitepisteiden löytämistä ja georeferointityökalun käyttöä. Georeferoinnin työkalu tukee nykyään sekä rasteri- että vektoridataa.

CAD-aineistojen tietorakenne ja ominaisuustiedot

Jos CAD-aineiston tietorakenne on alunperin luokiteltu ja nimetty johdonmukaisesti, siirtyminen paikkatietomaailmaan on helppoa. Käytännössä tämä tarkoittaa, että piirustustasot on nimetty loogisesti ja niitä on kohtuullinen määrä. Jos kohteisiin on suoraan talletettu ominaisuustietoja, asiat ovat todella hyvin. On kuitenkin parasta varautua siihen, että pientä hiomista tarvitaan. Usein oletusarvona merkkien koodauksessa käytetty UTF-8 -standardi aiheuttaa sen, että skandinaaviset merkit eivät näy halutussa muodossa.

Useimmiten kuitenkin käy niin, että tasoja on todella monta ja tason nimi (esim. Puut, Tiestö, Rakennukset jne) on yhteinen ominaisuustieto kaikille kyseisen tason kohteille. Varsinainen ominaisuustieto on usein talletettu  erilliselle annotaatio- eli tekstitasolle. Kyseinen taso sisältää pisteitä ja tekstin (etiketin) yhdistettynä pisteisiin, jotka sijoitetaan lähelle karttakohdetta. Tarkoituksena on luoda sellainen graafinen esitys, jonka  inhimillinen katsoja voi tulkita mahdollisimman yksiselitteisesti.

Jonkin verran käsityötä vaaditaan, jotta annotaatio-tason ominaisuustiedot saadaan lisättyä karttakohteiden ominaisuustietotaulukkoon. Tämä onnistuu kohtuullisen hyvin, mikäli kiinteistötunnukset on talletettu omaan Annotaatio-tasoonsa, tiestön nimet omaansa jne. Huomattavasti enemmän työtä aiheuttaa sellainen tapaus, jossa aineiston kaikki tekstit on talletettu yhteen ja samaan Annotaatio-tasoon (kiinteistötunnukset, tiestön nimet ja numerot jne). 

Topologisten virheiden tunnistaminen ja korjaaminen

Loppu häämöttää, mutta vielä pitää ratkaista yksi kysymys: onko kartan geometriset kohteet piirretty topologisesti oikein? Ei nimittäin riitä, että ne vain “näyttävät hyviltä” tietyn mittakaavan tulosteessa.

Topologia on kiehtova aihe, eräs matematiikan osa-alueista ja välttämättömyys GIS-maailmassa. Topografia onkin sitten jotain aivan muuta, vaikka kartoista puhuttaessa ne on välillä helppo sekoittaa keskenään.

Topologiset säännöt määrittelevät, millainen on hyväksyttävä, topologisesti eheä karttakohde. CAD-piirustuksen kohteet saattavat ensi silmäyksellä näyttää aivan asiallisilta, mutta lähempi tarkastelu paljastaa topologisia virheitä. Ne aiheuttavat myöhemmin ongelmia, kun karttakohteille halutaan tehdä paikkatietoanalyysejä.  Karttakohteen täytyy olla eheä, jos halutaan laskea alueen pinta-ala, reitin pituus, luoda vyöhykkeitä tai yhdistää tai leikata kohteita.

Tyypillisiä topologia virheitä ovat mm.

• Yhtenäiseltä näyttävä viivamainen tiekohde koostuukin monesta erillisestä, lyhyemmästä viivasta, joiden väliin jää tyhjää tilaa
• Viivamainen tiekohde on kyllä yhtenäinen, mutta leikkaa itsensä ja muodostaa silmukoita kuten numero 8
• Rakennus tai puisto näyttää suljetulta alueelta (polygoni) mutta se onkin CAD-ohjelmiston viiva-työkalulla piirretty reunaviiva, jolloin syntyy kehä ilman pinta-alaa
• Kaksi aluetta (esim kaksi kiinteistöä), joiden pitäisi olla aivan kiinni toisissaan, on vahingossa piirretty joko osittain päällekkäin tai niin, että alueiden väliin jää turha, tyhjä alue.

Tällaiset topologiset virheet täytyy korjata ennen kuin aineistoa voidaan käyttää kunnolla QGISissä. Osa työstä täytyy ehkä tehdä manuaalisesti, mutta QGIS:issä on nykyään useita automaattisia ja puoliautomaattisia työkaluja topologian korjaamiseen kuten esim. Check geometry-työkalu. Sen lisäksi QGISin piirtotyökalut ovat kehittyneet paljon viime vuosina ja ne ovat saaneet CAD-työkaluille tyypillisiä ominaisuuksia ja esimerkiksi kaarien piirtämiseen löytyy vaihtoehtoisia työkaluja. Lisäksi nykyään on saatavilla myös lisäosa  QAD Tools, joka on kehitetty helpottamaan AutoCADin logiikan tuntevien QGIS-käyttäjien elämää. 

Ja eikun hommiin

Edellä puhuttiin lähinnä ongelmista, mutta pysytään positiivisina. Useimmat haasteet ovat ratkaistavissa! Pitkälle pääsee, kun muistaa tarkistaa ainakin nämä:

• Varmista koordinaattijärjestelmä
• Tarkista geometrian ja topologian oikeellisuus
• Etsi annotaatiosta ominaisuustiedot ja siirrä ne karttakohteiden ominaisuustiedoiksi taulukkomuotoon.

Ja muista, että jos alkaa arveluttaa, me Gispolla tarjoamme koulutusta datan suunnitteluun, editointiin ja hallintaan QGISillä. Lähdemme myös mielellämme kehittämään digitoinnin työkaluja QGISille, jotta ne olisivat jatkossa parempia.  Näitä tarvitaan erityisesti kaavoituksen, kiinteistönmuodostuksen, tonttijaon ja maastotietojen tuotannossa. 

Gispon Juho Rekilä toimii Oskari-karttapalvelun viestintäkoordinaattorina nyt toista vuotta. 2024 alkanut työ sisältää mm. sisällöntuotannon Oskarin nettisivuille, LinkedIn-ryhmään ja blogiin. Juho on tehnyt myös Oskari-verkostoon liittyvää työtä, esitellyt Oskaria GeoForumSummitissa, järjestänyt Oskariin liittyviä tapahtumia. Oskarin viestintäkoordinaattorin kokemusta on myös Gispon toimitusjohtaja Sanna Jokelalla, joka oli viestintäkoordinaattorina 2017-2020. Viestintätöiden lisäksi Gispolla tehdään aktiivisesti Oskari-karttapalveluiden ylläpitoa ja kehitystä.

Jos Oskari ei ole vielä tuttu, suosittelemme lukemaan ”Mikä on Oskari ja mitä sillä voi tehdä?” -blogimme. Oskarista kiinnostuneet ja palvelua jo käyttävät ovat myös lämpimästi tervetulleita Oskarin verkostopäivään 12.5.2025 Pasilaan!

Alla oleva kuvaus kehittäjien päivästä on aiemmin julkaistu englanniksi Oskarin omassa blogissa.

Oskari-kehittäjien päivä 2025

Oskari-kehittäjien päivä järjestettiin 1.4. Espoossa, Sitowisen tiloissa. Kehittäjätapaamisia on ollut aiemminkin, mutta viimeisimmästä on aikaa useampi vuosi. Tapahtuman tartkoituksena oli saada uusia ja vanhoja Oskari-kehittäjiä samaan paikkaan jakamaan tietoa ja kokemuksia Oskarin kanssa toimimisesta. Osa osallistujista tunsi toisensa jo ennestään, mutta eivät silti välttämättä tunteneet toistensa organisaatioinden Oskarin käyttötapauksia ja uusia ideoita.

Kehittäjätapaamiselle oli selvästi tarve, sillä paikalle saapui yhteensä 15 ihmistä eri organisaatioista. Paikalla oli MML:n Oskari-tiimiä sekä Sitowisen, Siilin, Ubigun ja Gispon kehittäjiä ja muita Oskari-projekteissa toimivia henkilöitä. Kehittäjien kokemus Oskarin parissa oli vaihteleva, seniorikehittäjien joukossa oli muutamakin kymmenisen vuotta Oskarin parissa toiminutta kehittäjää, kun taas uudempien Oskari-osaaminen lähti nollasta. 

Tapahtuman ohjelma koostui puheenvuoroista, joissa esiteltiin erilaisia Oskariin liittyviä kehitysprojekteja sekä yleisesti Oskarin päivittämistä uuteen 3.0 versioon. Iltapäivällä osallistujat pääsivät kokeilemaan Oskarin geoportaalin lokaalia pystyttämistä ja RPC-toiminnallisuuksia.

Oskari 3.0 ja React-migraatio

Oskarin tekninen koordinaattori Sami Mäkinen esitteli, mitä uutta Oskarin uusi major release toi mukanaan. Uudessa versiossa Java-version nosto 8:sta 17:ään on tietenkin suurimpia asioita, minkä lisäksi Oskarissa on päivitetty paljon taustakirjastoja. Front-endistä vanhoja jQuery-komponentteja on otettu pois ja vaihdettu Reactiin.

Samalla bundlejen tekoa on helpotettu merkittävästi. Nyt bundle voi olla helpoimmillaan vain yksi .js-tiedosto, kun ennen bundlen teko vaati eri tiedostojen tekoa eri paikkoihin. Uudessa esimerkkibundlessa on myös paljon kommentteja koodin ohessa, jotta bundlejen tekeminen olisi uusille kehittäjille selkeämpää. (Katso uusi SampleInfoBundleInstance.js -tiedosto GitHubista https://github.com/oskariorg/sample-application/blob/master/bundles/sample-info/SampleInfoBundleInstance.js)

Siilin Pekka Helesuo esitteli karttajulkaisijaan tehtyjä muutoksia. Vanha jQuery-koodi on monin osin muutettu Reactiksi ja aihetta koskeva dokumentaatio on muutosten osalta myös päivitetty. Dokumentaatio sisältää myös ohjeet siihen, kuinka julkaisijaan lisätään React-työkaluja.

jQueryä löytyy kuitenkin vielä Oskarista, ja esimerksi Drag and drop -pohjainen työkalujen siirtely karttajulkaisussa on käyttää jQueryä. React-migraatiota saatiin kuitenkin edistettyä niin paljon, että Oskari 3.0:n osalta työ on varsin hyvässä vaiheessä. jQuerystä luopuminen jatkuu seuraavien päivitysten myötä.

3.0. version Changelog on kokonaisuudessaan nähtävissä täällä: front-end https://github.com/oskariorg/oskari-frontend/blob/master/ReleaseNotes.md

server: https://github.com/oskariorg/oskari-server/blob/master/ReleaseNotes.md

OAuth 2 ja EntraID -kirjautuminen Oskariin

Ubigu on ylläpitänyt pitkään Tampereen kaupungin Oskari-instansseja ja kehittänyt niitä. Janne Heikkilä esitteli kehittäjäpäivässä Tampereen Oskari-palveluun tehtyä OAuth 2 ja EntraID -kirjautumista. Näin helpotetaan organisaation käyttäjien kirjautumista Oskariin. 

Oskarissa käyttäjille on annettu rooleja ja luotu erilaisia käyttäjäryhmiä, ja lisäosa tunnistaa jo kirjautumisvaiheessa käyttäjän roolin. Jos siis jollakin ei ole valtuuksia esimerkiksi kirjautua ollenkaan Oskariin, lisäosa tarkistaa sen jo kirjautumisvaiheessa ja antaa “Access denied” -ilmoituksen.

Tampereella ollaan myös siirtymässä Oskarin 3.0. versioon, ja alustavasti tarkoituksena on, että lisäosa tulisi yleistettynä saatavilla Oskariin. Lisäosan koodi on nähtävissä GitHubissa. https://github.com/Tampere/tampere-oskari-server-extension

RPC-toiminnallisuuden laajentaminen

Oskarin geoportaalin ohella RPC-toteutuksia (karttajulkaisuja) on usein käytössä. Tunnetuimpia esimerkkejä lienevät Kalastusrajoitus.fi ja VäyläMap. RPC-ratkaisuja käytetään paitsi yksittäisissä karttajulkaisuissa myös organisaation virallisena Oskari-karttapalveluna perinteisen geoportaalin sijaan. RPC-toteutus mahdollistaa geoportaaliin verrattuna palvelun kehittämisen eri tavalla esimerkiksi ulkonäön ja toiminnallisuuksien osalta.

Timo Aarnio kertoi Gispon Oskari-projektissa tehdyistä RPC-toiminnallisuuksista. Projektissa oli tarve tehdä RPC:hen lisää toimintoja, koska olemassa olleet eivät riittäneet asiakkaan tarpeisiin. Projektissa tehtiin esimerkiksi “getGroupsWithLayerIds()”, joka palauttaa karttatasoryhmähierarkian sekä niihin kuuluvat karttatasot. Tämä mahdollistaa käyttäjälle oman karttatasovalikon tekemisen, joka palauttaa vain ne karttatasot, jotka on valittu karttaupotuksesta ja joihin käyttäjällä on oikeus. Toinen kehitetty toiminnallisuus käyttää karttatasojen description-kenttää kevyenä vaihtoehtona tason metatiedoille, jolloin metatietopalvelua (kuten CSW:tä) ei tarvita.

Toimintojen koodi on nähtävillä GitHubissa ja tuotu myös Oskari 3.0:aan:

https://github.com/oskariorg/oskari-frontend/pull/2815

https://github.com/oskariorg/oskari-frontend/pull/2807

CSW-rajapinta

Sitowise on ollut mukana useamman organisaation Oskari-karttapalvelun ylläpidossa ja kehittämisessä. Heidän asiakkaallaan oli tarve julkaista karttatasoja, jotka ovat näkyvissä vain osalle palvelun käyttäjistä. Tämä on tietenkin Oskarissa helposti tehtävissä käyttäjäroolien avulla, mutta vaade koski myös aineistojen metatietoja. Metatiedot haluttiin jonnekin muualle kuin avoimesti Paikkatietohakemistoon, missä julkisten karttatasojen metatiedot yleensä ovat, ja jota käytetään suomalaisten Oskari-instanssien aineistojen kanssa.

Arttu Pietarinen esitteli prosessia, jossa GeoServeriin asennetaan CSW-lisäosa, joka vie GeoServerissä julkaistujen tasojen metatiedot CSW-rajapintaan. CSW on INSPIRE-direktiivin mukainen rajapinta, joka antaa metadataa standardin mukaisesti. Samaisen GeoServerin kautta voidaan julkaista sekä sisäiseen käyttöön tarkoitettuja aineistoja että niiden metatietoja. 

Oskarin pääkäyttäjä voi admin-työkalujen kautta määrittää “metadataURL”-attribuutin eri tasoille, jolloin metadata haetaan erikseen määritellystä sijainnista. Kun palvelun käyttäjä haluaa katsella metatietoja, ne haetaan joko suljetusta CSW-rajapinnasta tai oletukseksi määritellystä CSW-palvelusta, kuten Paikkatietohakemistosta.

Oskari 3.0. päivitysprojekti Sitowisen, Väyläviraston ja MML:n yhteistyönä

Kehittäjäpäivässä kuultiin myös kehittäjien kokemuksia maaliskuussa julkaistun 3.0:n päivitystyöstä kahden organisaation välillä. Työssä oli Maanmittauslaitokselta neljä henkilöä ja testaajat, sekä Sitowiseltä kaksi kehittäjää ja Sitowisen oma testaaja. 

Yhteistyön takana olivat MML:n, Väyläviraston ja Sitowisen keskenään kohdanneet tarpeet. Maanmittauslaitoksella oli tarve päivittää Oskarin Java- ja Spring-major-versioita, kun taas Sitowisellä on useita Oskari-instansseja ylläpidossa ja kehitettävänä, mukaanlukien Väyläviraston Oskari-projekti, jossa nousi huolia Oskarin tietoturvahaavoittuvuuksista. Major-päivityksissä tulee helposti muutoksia, jotka eivät ole taaksepäin sopivia, ja yhteisprojektin ansiosta Sitowisellä voitiin auttaa 3.0:aan päivittämisessä ja viedä muutokset myös heidän ylläpitämiinsä Oskari-palveluihin.

Keskustelu yhteishankkeesta alkoi syksyllä 2024 ja itse projekti alkoi tammikuun puolivälissä 2025. MML:n Sami Mäkinen teki alustavan suunnitelman, jota varioitiin tarvittaessa, ja tiimillä oli joka päivä daily-kokous, jossa seurattiin päivitysten etenemistä.

Päivitys tehtiin projektina, jossa yritettiin sitoa tiimit mahdollisimman tiiviisti kiinni päivitykseen. Arttu Pietarinen esitteli yhteishanketta ja kiitteli etenkin sitä, että projektimuotoinen työtapa helpotti koko prosessia: Maanmittauslaitoksella ja Sitowisellä oli omat tiimit ja yhteinen tavoite. Intensiivinen työtapa, jossa työntekijät oli sidottu projektiin, madalsi myös kynnystä kysyä apua. Matkalla tulleet haasteet ja niiden ratkaisut löytyivät myös helposti, kun Sitowisen kehittäjät veivät muutoksia suoraan tuotantoon Väylä Map -palvelussa.

Oskarin geoportaalin ja RPC-toteutuksen työpajat

Kehittäjäpäivän iltapäivä koostui suurelta osin työpajoista, joissa osa osallistujista kokeili geoportaalin lokaalia pystyttämistä ja RPC-toteutuksen komentoja. Työpajojen aikana ja tapahtumassa yleisesti oli myös puheenvuorojen väleissä paljon kokemusten jakamista Oskari-kehittämisestä ja -hankkeista (sekä kaikesta muusta aina perhelomista päivänpolttaviin uutisaiheisiin). 

Työpajoihin oli varattu aikaa klo 16 asti, mutta lokaalit geoportaalit näkyivät näytöillä jo vartin yli kolme. Vaikka haasteita oli esimerkiksi oikean Java-version asentamisessa tai siinä, mihin porttiin tietokanta avautuu, ongelmat ratkesivat Samin ja muiden paikallaolleiden Oskari-osaajien avulla. Kaikki pääsivät siis hieman suunniteltua aiemmin kotimatkalle. Tämän kokemuksen perusteella vastaava tapahtuma voisi olla paikallaan myös ensi vuonna.