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
Kesäkuussa 2024 julkaistiin QFieldin versio 3.3.0 – Darién, jossa yhtenä uutena merkittävänä ominaisuutena saatiin tuki lisäosien rakentamiselle. Jatkossa siis kuka tahansa voi luoda QFieldille omia lisäosia yleiseen, omaan tai organisaation käyttöön, aivan kuten QGISissä. QGIS-lisäosista poiketen QFieldissä ohjelmointikielenä toimii Pythonin sijaan Qt-ympäristöön kuuluva QML (Qt Modeling Language), jota käytetään lisäosan käyttöliittymän luomiseen ja joka sisältää myös tuen JavaScript-kielelle, jolla toteutetaan lisäosan varsinaiset toiminnallisuudet.
QField-lisäosa
Lisäosia voi QFieldissä käyttää kahdella tapaa, projektikohtaisena tai koko sovelluksen laajuisena. Projektikohtaisen lisäosan lähdekoodi tulee sisällyttää samaan kansioon QField-projektin kanssa ja antaa lisäosan .qml-tiedostolle sama nimi kuin projektitiedostolle. Sovelluslisäosan voi asentaa käyttöliittymän kautta syöttämällä linkin, josta lisäosa on ladattavissa .zip-tiedostona.
Lisäosan kehittämisessä on kätevää käyttää projektikohtaista lisäosaa, koska sen voi päivittää ja asentaa testikäyttöön yksinkertaisesti kopioimalla lähdekoodin projektitiedoston kanssa samaan sijaintiin ja avaamalla projektitiedoston. Vaikka QField on tarkoitettu ensisijaisesti puhelin- ja tablettikäyttöön, siitä löytyy myös työpöytäversio, mikä helpottaa lisäosien kehittämistä ja testaamista. Täältä voit ladata viimeisimmän QField-julkaisun työpöytäkäyttöön.
Näin teet QField-lisäosan
Käydään läpi yksinkertaisen lisäosan kehittäminen vaiheittain. Voit kokeilla pluginia tallentamalla samaan kansioon QGIS-projektin ja QML-tiedoston, esimerkiksi nimillä test_plugin.qgz ja test_plugin.qml. Kun avaat QGIS-projektin QFieldillä, sen pitäisi kysyä otetaanko lisäosa käyttöön.
test_plugin.qml:
import QtQuick // tuodaan QML-standardikirjasto
import org.qfield
Item { // osa QtQuickia
id: examplePlugin // määritellään tunniste lisäosalle
// samoin kuin QGIS-lisäosissa käytössä on "iface"-muuttuja,
// joka antaa pääsyn QFieldin eri komponentteihin
// tallennetaan muuttujaan viittaus sovelluksen ikkunaan
property var mainWindow: iface.mainWindow()
// kun lisäosa on luotu se lähettää "completed()"
// signaalin. Tässä määritellään ns. signal handler
// johon kirjoitetaan JavaScriptillä mitä
// halutaan tapahtuvan kun lisäosa on ladattu
Component.onCompleted: {
// tässä tapauksessa mainWindow-muuttujaa
// hyödyntäen lähetetään viesti, joka
// näkyy käyttöliittymässä hetken ajan
mainWindow.displayToast('Hello world!');
}
}
Esimerkin pitäisi näyttää tältä, kun QField avataan lisäosan kanssa:
Tähän hyvin yksinkertaiseen lisäosaan koodattu toiminto (”Hello world!”) tapahtuu, kun QField avataan. Tässä yksinkertaisessa lisäosassa toimintoa ei voi toistaa mitenkään (paitsi sulkemalla ja käynnistämällä uudestaan). Koska nappulan painaminen on kivaa ja tärkeää, lisätään lisäosaan seuraavaksi painike:
import QtQuick
import org.qfield
import Theme // tuodaan QFieldin teemakirjasto
Item {
id: examplePlugin
property var mainWindow: iface.mainWindow()
Component.onCompleted: {
// lisätään alla määriteltävä painike
// lisäosien työkalupalkkiin
iface.addItemToPluginsToolbar(pluginButton)
}
// QField sisältää valmiita käyttöliittymäelementtejä,
// joita voi hyödyntää. Tässä esimerkkinä QfToolButton
QfToolButton {
id: pluginButton
// iconSource: '' // halutessaan painikkeelle voi määrittää ikonin.
// Tällöin ikonitiedosto pitää sisällyttää osaksi lisäosaa
// Lisätään teksti painikkeelle:
Text {
text: "Toast"
anchors.centerIn: parent
font: Theme.defaultFont
color: Theme.light
}
bgcolor: Theme.darkGraySemiOpaque // määritellään painikkeen väri. QFieldin teemakirjasto sisältää valmiita värejä
round: true
// määritellään JavaScriptillä mitä tapahtuu, kun
// painiketta painetaan
onClicked: {
mainWindow.displayToast('Hello world!');
}
}
}
Nyt lisäosassamme on painike, jota painamalla Hello world! -tekstin saa ruudulle näkyviin.
Lisäosaan halutaan todennäköisesti enemmän toimintoja ja paineltavia nappuloita. Nämä sijoitetaan erikseen avautuvaan dialogi-ikkuna tai käyttöliittymään, jotta niiden käyttäminen olisi kätevää. Tehdään siis seuraavaksi yksinkertainen käyttöliittymä, joka avautuu, kun painiketta painetaan:
import QtQuick
// Uusi import-komento Dialogia varten
import QtQuick.Controls
import org.qfield
import Theme
Item {
id: examplePlugin
property var mainWindow: iface.mainWindow()
// Määritellään dialogikomponentti
Dialog {
id: dialog
parent: mainWindow.contentItem
title: "Example plugin"
// Ei näytetä dialogia heti
visible: false
// Modaalisuus viittaa tässä siihen
// että dialogi täytyy sulkea ennen
// kuin voi vuorovaikuttaa muiden
// käyttöliittymäelementtien kanssa
modal: true
focus: true
font: Theme.defaultFont
// Keskitetään dialogi
x: (parent.width - width) / 2
y: (parent.height - height) / 2
width: 300
height: 400
standardButtons: Dialog.Close
// Lisätään teksielementti
Text {
text: "This is a dialog!"
font: Theme.defaultFont
horizontalAlignment: Text.AlignLeft
}
}
QfToolButton {
id: pluginButton
bgcolor: Theme.darkGraySemiOpaque
round: true
Text {
anchors.centerIn: parent
text: "Dialog"
color: Theme.light
}
onClicked: {
// Näytetään yllä määritelty dialogi
dialog.open();
}
}
Component.onCompleted: {
iface.addItemToPluginsToolbar(pluginButton)
}
}
Nyt meillä on dialogi, muttei sisältöä. Lisätään dialogiin muutama painike, jotka demonstroivat joitakin ohjelmointirajapinnan ominaisuuksista:
import QtQuick
import QtQuick.Controls
// uusi import-komento
import QtQuick.Layouts
import org.qfield
import Theme
Item {
id: examplePlugin
property var mainWindow: iface.mainWindow()
// tallennetaan muutama olio, joita
// tarvitaan myöhemmin
property var layerTree: iface.findItemByObjectName('dashBoard').layerTree
property var mapSettings: iface.mapCanvas().mapSettings
Dialog {
id: dialog
parent: mainWindow.contentItem
title: "Example plugin"
visible: false
modal: true
focus: true
font: Theme.defaultFont
x: (parent.width - width) / 2
y: (parent.height - height) / 2
width: 300
height: 400
standardButtons: Dialog.Close
// käytetään Column- ja RowLayouteja
// järjestelemään eri käyttöliittymän
// komponentit
ColumnLayout {
spacing: 10
RowLayout {
Layout.fillWidth: true
// lisätään toimintoa kuvaava
// tekstikenttä (Label)
Label {
text: "Text Input:"
font: Theme.defaultFont
color: Theme.mainTextColor
Layout.fillWidth: true
}
// lisätään teksikenttä, johon käyttäjä
// voi kirjoittaa tekstiä
QfTextField {
id: textField
text: "Hello"
Layout.fillWidth: true
Layout.preferredWidth: 100
Layout.preferredHeight: font.height + 20
horizontalAlignment: TextInput.AlignHCenter
font: Theme.defaultFont
enabled: true
visible: true
}
// lisätään painike
QfToolButton {
id: textFieldButton
bgcolor: Theme.darkGraySemiOpaque
round: true
Text {
anchors.centerIn: parent
text: "Toast"
color: Theme.light
}
onClicked: {
// näytetään tekstikentän teksti
mainWindow.displayToast(textField.text);
}
}
}
RowLayout {
Layout.fillWidth: true
Label {
text: "List layers"
font: Theme.defaultFont
color: Theme.mainTextColor
Layout.fillWidth: true
}
QfToolButton {
id: listLayersButton
bgcolor: Theme.darkGraySemiOpaque
round: true
Text {
anchors.centerIn: parent
text: "List"
color: Theme.light
}
onClicked: {
let list = "Layers:";
// iteroidaan layerTree-olion rivejä
for (let i = 0; i < layerTree.rowCount(); i++) {
let index = layerTree.index(i, 0);
// haetaan tason nimi
let name = layerTree.data(index, FlatLayerTreeModel.Name);
list = list.concat("\n", name);
}
mainWindow.displayToast(list);
}
}
}
Label {
text: "Jump To Coordinates (WGS 84)"
font: Theme.defaultFont
color: Theme.mainTextColor
}
RowLayout {
Layout.fillWidth: true
Label {
text: "X"
font: Theme.defaultFont
color: Theme.mainTextColor
Layout.fillWidth: true
}
QfTextField {
id: xField
text: "0"
Layout.fillWidth: true
Layout.preferredWidth: 30
Layout.preferredHeight: font.height + 20
horizontalAlignment: TextInput.AlignHCenter
font: Theme.defaultFont
enabled: true
visible: true
inputMethodHints: Qt.ImhFormattedNumbersOnly
}
Label {
text: "Y"
font: Theme.defaultFont
color: Theme.mainTextColor
Layout.fillWidth: true
}
QfTextField {
id: yField
text: "0"
Layout.fillWidth: true
Layout.preferredWidth: 30
Layout.preferredHeight: font.height + 20
horizontalAlignment: TextInput.AlignHCenter
font: Theme.defaultFont
enabled: true
visible: true
inputMethodHints: Qt.ImhFormattedNumbersOnly
}
QfToolButton {
id: addFeatureButton
bgcolor: Theme.darkGraySemiOpaque
round: true
Text {
anchors.centerIn: parent
text: "Jump"
color: Theme.light
}
onClicked: {
let x = Number(xField.text);
let y = Number(yField.text);
if (isNaN(x) || isNaN(y))
{
mainWindow.displayToast('Invalid input!', 'error');
return;
}
mainWindow.displayToast('Jumping to (x: ' + xField.text + ', y: ' + yField.text + ')');
// luodaan piste käyttäjän antamista koordinaateista
let point = GeometryUtils.point(x, y);
// muunnetaan piste projektin koordinaattijärjestelmään
let reprojected_point = GeometryUtils.reprojectPoint(point, CoordinateReferenceSystemUtils.wgs84Crs(), mapSettings.destinationCrs);
// siirretään karttanäkymän keskikohta projisoituun pisteeseen
mapSettings.setCenter(reprojected_point);
}
}
}
}
}
QfToolButton {
id: pluginButton
bgcolor: Theme.darkGraySemiOpaque
round: true
Text {
anchors.centerIn: parent
text: "Dialog"
color: Theme.light
}
onClicked: {
dialog.open();
}
}
Component.onCompleted: {
iface.addItemToPluginsToolbar(pluginButton)
}
}
Tältä lisäosa näyttää käytössä:
Nyt meillä on siis lisäosa, jonka painikkeen takaa aukeaa dialogi-ikkuna. Tässä valikossa meillä on kolme painiketta
- Toast: julkaisee käyttäjän määrittelemän tekstin ruudulle
- List: listaa projektin karttatasot
- Jump: siirtää näkymän käyttäjän määrittämiin koordinaatteihin
Tarvitsetko lisää ominaisuuksia QFieldiisi? Ota yhteyttä ja me autamme.
Suomesta löytyy paljon arkeologisia kohteita (Museoviraston rajapinnan kautta saa ladattua ainakin yli 38 600 pistettä). Arkeologiset kohteet ovat aina sidottuna johonkin paikkaan ja täten niitä on helpoin tarkastella kartan ja paikkatiedon avulla. Sijainnin lisäksi mukana on erilaisia ominaisuustietoja, kuten esimerkiksi tyyppi, ajankohta ja valokuva kohteesta. Näiden tietojen ylläpito ei ole yksinkertaisinta. Inventointeja tehdään jatkuvasti ympäri maata, jotta tiedot pysyvät ajan tasalla.
QGIS on museovirastolle tuttu työkalu. QField on QGISin kanssa yhteen sopiva mobiilisovellus ja me Gispolta olimme mukana projektissa, jossa testattiin kuinka QField voisi auttaa muinaisjäännösrekisterin inventointitehtävissä.
QFieldin käyttö kannattaa useista eri syistä, joita ovat muun muassa
- Maksuton
- Toimii sekä iOS- että Android-laitteilla
- Toimii yhdessä tutun ja ilmaisen QGIS-työpöytäohjelmiston kanssa
- Selkeät ohjeet ja videot
- Mobiilisovellus löytyy myös Windowsille
QField ja avoin lähdekoodi mahdollistavat myös sovelluksen kustomoinnin, jos sovelluksesta ei valmiiksi löydy juuri sitä nappulaa, jota tarvitse. Gispon aikaisemmasta QField-mobiilisovelluksen kehitysprojektista voit lukea täältä.
Projektitiedosto QGISistä QFieldiin
Projektissa lähdimme liikkeelle ensimmäiseksi QGIS-projektitiedoston luomisesta. Projektiin teimme tarvittavat määrittelyt. Museoviraston arkeologisten kohteiden inventointia varten näimme järkevänä luoda pääkohde-, alakohde- ja aluekohde-tasoja. Näihin liittyy muutama koodistotaulu sekä oma taulu valokuvien tietojen tallentamiselle. Tämä runko pysyy kaikilla inventointitehtävissä työskentelevillä yleensä samana. Tämän lisäksi on usein tarvetta erilaisille tausta-ja tukikartoille. Näitä voivat olla esimerkiksi Maanmittauslaitoksen peruskartta, ilmakuva tai georeferoitu historiallinen kartta. Näitä tasoja inventoija voi lisätä ja vaihtaa itse, koska inventointikohteen mukaan.
Kun määrittelyt ovat valmiit, projekti siirretään QFieldiin. Tätä varten luodaan QGISin QField Sync -lisäosan avulla uusi projektitiedosto, joka siirretään puhelimeen ja avataan QFieldillä. Siirron voi tehdä esimerkiksi kaapelilla tai QField Cloud -pilvipalvelun kautta. Kun siirto on tehty, päästään itse asiaan eli keräämään tietoa QField-sovelluksen avulla.
Tietojen kerääminen onnistuu näppärästi maastossakin, kun lomakepohjat on ensin luotu valmiiksi QGISissa. Alla lyhyt esimerkki siitä, miltä kohteen lisääminen näyttää QFieldissä.
Kun tarvittavat tiedot on kerätty, ne siirretään takaisin QGISiin esimerkiksi kaapeliyhteydellä tai vaihtoehtoisesti maksullisen QField Cloud SaaS -palvelun avulla, jolloin tiedot siirtyvät suoraan internet-yhteyden avulla maastosta. Kun tieto on saatu QGISiin, tietoja voidaan vielä tarkastella, muokata ja luoda valmiita raportteja. Tiedot voi viedä esimerkiksi suoraan tietokantaan tai Excel-yhteensopivaan taulukkomuotoon.
Käyttövalmis QField sovellus
Projektin lopputuotteena syntyi inventointiin sopiva QGIS-projektitiedosto, jonka voi suoraan viedä QFieldiin. Teimme myös omat ohjesivut koko prosessista. Projektiin on valmiiksi määritelty tarvittavat tasot ja taulukot, sekä niiden relaatiot toisiinsa.
“QField-sovelluksen toteutus syntyi sujuvan vuorovaikutuksen myötä, jossa sovelluksen versiota testattiin useissa vaiheissa käytännön maastotöissä. Saatujen kokemusten perusteella havaitut ongelmat korjattiin ja lopputuloksena saatiin mielestämme hyvä ja toimiva työkalu arkeologin maastoinventointeihin ja kohdetarkastuksiin”, kertoo Museoviraston Jouni Taivainen.
Tommi Hyvönen Museovirastolta kommentoi projektia näin: “Gispon kanssa löydettiin sujuvasti yhteisymmärrys projektin tavoitteista, ja toteutus eteni ketterästi. Saimme projektin aikana nopeasti ja verrattain pienellä työpanoksella monipuolisen ja toimivan työkalun tiedon keruuseen. Avoimeen lähdekoodiin perustuvan ratkaisun vuoksi voimme jatkossa joustavasti muokata ja jatkokehittää lomaketta tarpeidemme mukaan.”
Gispollakin oltiin hyvin tyytyväisiä tähän projektiin, ja oli hienoa huomata, miten QField soveltuu tähänkin käyttöön. Lisää näitä projekteja kiitos!
Kaipaatko apua QFieldin käyttöönotossa vai haluatko kuulla enemmän QFieldista ja miten se voisi toimia sinun organisaatiossa? Tule seuraavaan QField-koulutukseemme!
Mikä on pääsalasana ja mihin sitä tarvitaan?
Kun QGISissä luo ensimmäisen kerran autentikoinnin, ohjelma pyytää asettamaan pääsalasanan (Master password). Tämä on käyttäjän asettama salasana, jolla salataan pääsy QGISin SQLite-autentikointitietokantaan. Autentikointitietokanta on paikallinen tiedosto, johon voidaan tallentaa QGIS-projekteissa käytettyjen tietokanta- ja rajapintayhteyksien käyttäjätunnukset ja salasanat. Olemme kirjoittaneet aiemmin blogiimme, miksi autentikointitiedot kannattaa tallentaa QGISiin: API-avainten tallennus QGISiin.
Jos QGISissä käytössä on useampi käyttäjäprofiili, jokaisella profiililla on oma autentikointitietokantansa ja pääsalasanansa. Jos käyttäjä vaihtaa QGIS-versiota, autentikointitietokanta siirtyy profiilien mukana versiosta toiseen eikä se vaikuta mitenkään QGISin muihin asetuksiin. Tietokanta on oletuksena kunkin QGIS-profiilin kansiossa ja sen voi halutessaan kopioida profiilista toiseen manuaalisesti. Windowsissa esimerkiksi tiedoston polku on C:\Users\<käyttäjä>\AppData\Roaming\QGIS\QGIS3\profiles\<profiili>\qgis-auth.db.
Salasanan muodostaminen ja tallentaminen
Salasanan muodostamiseksi ohjeet ovat samat kuin nykyään muuallakin: salasanana voi käyttää jotain itselle merkityksellistä, monimutkaisuus (merkkimäärällisesti pitkä, erikoismerkkejä, numeroita, isoja/pieniä kirjaimia) on etu. Tärkeää on kuitenkin kirjata salasana jonnekin talteen, sillä muuten se herkästi unohtuu eikä ole käytettävissä, kun sitä tarvitaan. Salasanan palautustoimintoa QGISissä ei ole, vaan unohtuneen salasanan mukana katoaa myös kaikki sen taakse tallennetut autentikoinnit. Pääsalasanan hallinnassa kannattaa noudattaa oman organisaation salaisuuksien/salasanojen hallintapolitiikkaa. Vaihtoehtoisesti pääsalasanan voi tallentaa käyttöjärjestelmän salasanaholviin.
Salasanaholvia kutsutaan Windowsissa Credential Manageriksi, Linuxissa KeyRing:ksi ja MacOS:ssä KeyChain:ksi. Jos pääsalasana on tallennettu johonkin edellä mainituista, QGISin ei pitäisi kysyä pääsalasanaa ohjelmaa käytettäessä.
Versiosta 3.34. alkaen QGIS on mahdollistanut eri profiilien pääsalasanojen tallentamisen käyttöjärjestelmän salasanaholviin, mutta tätä vanhemmissa versioissa ainoastaan yksi pääsalasana tallentuu. Tämä kannattaa huomioida, mikäli käytössä on vanhempi QGIS-versio ja useampi käyttäjäprofiili. Vanhemmissa versioissa viimeisimpänä salasanaholviin tallennettu pääsalasana ylikirjoittaa aiemmin tallennetun pääsalasana. Tällöin QGIS voi kysyä pääsalasanaa, jos auki olevan profiilin pääsalasana poikkeaa salasanaholviin tallennetusta.
Milloin QGIS kysyy pääsalasanaa?
QGIS kysyy pääsalasanaa, kun autentikointitietokannasta koitetaan lukea jotain, eli yleensä silloin kun jotain projektia, jossa autentikointia on käytetty, koitetaan avata. Jos käyttäjä antaa salasanan, QGIS mahdollistaa pääsyn tietokannassa oleviin tietoihin. Jos taas salasanan täyttämisen sijaan painaa ”Peruuta”, ohjelman kaikki tavalliset toiminnot ovat käytössä, ainoastaan tallennetut autentikointitiedot eivät ole silloin saatavilla.
Jos käyttää esimerkiksi vain paikallisia tiedostoja QGIS-projekteissaan ja syöttää PostGIS-tietokantayhteyksien tai rajapintayhteyksien käyttäjätunnukset ja salasanat käsin aina yhteyksiä muodostaessaan, QGIS-käytössä pääsalasanaa ei välttämättä tarvitse ollenkaan.
Jos sen sijaan käyttäjä on tallentanut QGISiin eri autentikointitietoja em. yhteyksiin manuaalisen näpyttelyn vähentämiseksi, kannattaa ohjelman pääsalasana syöttää heti ohjelmaa avatessa. Näin QGIS hakee kirjautumistiedot tietokantoihin ja rajapintoihin automaattisesti.
Uutta käyttäjäprofiilia luodessa QGIS pyytää asettamaan uuden pääsalasanan. Syy tähän on se, että uuden profiilin luomishetkellä QGIS luo myös uuden autentikointitietokannan ja tarvitsee siihen pääsalasanan.
Käytännössä joillain käyttäjillä pääsalasanaa ei kysytä välttämättä koskaan, toisten käytössä pääsalasanaa tarvitaan useammin.
Jos pääsalasana pääsee unohtumaan, niin QGIS mahdollistaa uuden salasanan luomisen. Tämä tosin nollaa autentikointitietokannan jokaisen käyttäjätunnuksen ja salasanan, joten sinne tallennetut tiedot pitää näppäillä uudestaan salasanan uudelleenluomisen jälkeen.
Nykyinen pääsalasanasysteemi voi olla loppukäyttäjän kannalta hämmentävä, ja QGIS-kehittäjät ovat käyneet keskustelua tehdäkseen ohjelmasta tältäkin osin paremman. Vielä teknisempää selvitystä pääsalasanasta kaipaaville QGISin dokumentaatio antaa lisätietoa.
__________
Gispon tukipalveluasiakkaana voit aina kysyä tukipalvelusta apua autentikointitietokannan ja salasanojen tallennukseen.
Vuosikausien uurastus tuottaa tuloksen, ja siinä se nyt on ihailtavissa näytölläsi. Hartaudella vuosikaudet kerätty aineisto, harmoniseksi kokonaisuudeksi hiottu tietomalli, tehokas ja täsmällinen geoprosessointi ja silmäkarkiksi luonnehdittava visualisointi. Pablo Picasso 1937, Dream Theater 1992, Usain Bolt 2009. Joskus kaikki osuu kohdalleen.
Onnistuminen tuottaa nopeasti ongelman. Tässähän tämä nyt on, mutta miten saada tämä kaikki muidenkin hyödynnettäväksi? Haluaisit esitellä tuotoksesi koko maailmalle tai ainakin kiinnostuneille kollegoille, jotka ovat saattaneet puurtaa vuosikaudet yrittäen jotain samanlaista.
Jos selkäsi takana on sattunut vaanimaan suljetun lähdekoodin paikkatietoteknologian myyntimies, ratkaisu on helppo. Latomalla riittävästi virtuaalista pätäkkää virtuaaliseen tiskiin, saat käyttöösi sopivan palan pilveä, jonne voit paria nappia kääntämällä viedä datasi, tehdä rajapinnat, rakentaa geoprosessoinnit ja loihtia käyttöliittymän. Näin ainakin mainoksissa.
Yhteytesi paikkatietomaailmaan on kuitenkin rajoittunut Gispon blogiin. Pitääkö nyt suunnata palvelinkauppaan, kantaa rautaa kotiin, pystyttää tietokantaklusteri, opetella React, tutustua OGC API -rajapintoihin ja todeta hallinnassa olevan vasta puolet tarvittavista komponenteista?
Vaihtoehtoja toteutukseen on, mutta rajoitteeksi muodostuu kylmä totuus palvelintilan ja verkkoliikenteen kustannusten kattamisesta. Voi osoittautua turhaksi jäädä odottamaan avointa ja täysin ilmaista palvelua, jonne voisit vain työntää tuotoksesi sellaisenaan. On siis syytä pohtia, mitä oikeasti tarvitset.
Onneksi ohjaus oikeaan suuntaan löytyy taas Gispon blogista! Käsittelimme eri vaihtoehtoja selainkartan tuottamiseksi postauksessa syksyllä 2023, eikä tilanne ole siitä oleellisesti muuttunut. Otetaan tällä kertaa lähempään tarkasteluun QGIS Cloud: “Web-GIS-alusta karttojen, tietojen ja palvelujen julkaisemiseen”, kuten kollegani asian vuosi sitten tiivisti.
QGIS Cloudin taustalta löytyy sveitsiläinen 2000-luvun alussa perustettu Sourcepole, jota voidaan pitää avoimen lähdekoodin paikkatietoratkaisujen moniottelijana: vaikuttaa tutulta ja toimivalta konseptilta. QGIS Desktopin kehityksessä Sourcepole on yksi aktiivisimmista toimijoista. QGIS Cloudinkin elinkaari on jo reippaasti toisella vuosikymmenellä.
QGIS Cloudista on tarjolla kaksi versiota: Free ja Pro. Ensin mainittu on nimensä mukaisesti ilmainen, mutta soveltuu lähinnä omaan puuhasteluun ja testailuun. Free tarjoaa käyttöön yhden PostGIS-laajennuksella varustetun PostgreSQL-kannan, jonka maksimikoko on 50 MB, mutta oleellisimpana rajoituksena kaupallinen käyttö sekä käyttö julkisella sektorilla ei ole mahdollista.
Pro-tilaajia ei moiset rajoitukset kahlitse. Peruspaketin 65 eurolla kuukaudessa saa mm. kymmenen tietokantaa (500 MB), päivittäisen varmuuskopioinnin, TLS-tuen sekä mahdollisuuden rajoittaa pääsyä julkaistuille kartoille. Lisämaksusta on mahdollista mm. kasvattaa tietokantojen kokoa.
Koska olet lukenut Gispon blogia, QGIS on sinulle taatusti tuttu. QGIS Cloudin käyttöönoton voi siis olettaa olevan helppoa. Lisäosan lataamisen ja oman QGIS Cloud -tilin luonnin jälkeen sinulla onkin jo kaikki tarvittavat palikat. Käytössäsi on oma pilvessä leijuva SDI (Spatial Data Infrastructure), jonne voit aluksi luoda kannan datojasi varten. Kannan luonti kuten muutkin vaiheet tästä eteenpäin onnistuu tutulla QGIS Desktopilla ja siihen asennetulla lisäosalla.
Kartan julkaisu aloitetaan kopioimalla data SDI:lle. Tämäkin onnistuu suoraan desktopissa QGIS Cloud -laajennuksella. Näppärästi käy, mutta riittävän pitkään paikkatietokantojen kanssa touhunneelle tulee tässä vaiheessa pakottava tarve lausua varoituksen sanoja. QGIS Cloud luo kantaan yhden tunnuksen, jolla ei ole ylläpitäjän oikeuksia, mutta jolla voi tehdä tietokantatasolla mitä tahansa: lisätä dataa tauluihin, poistaa tauluja, luoda dataa muokkaavia triggereitä jne. Pääsyä tunnuksella ei rajata muutoin eli kun tiedät tunnuksen, voit kirjautua SDI:lläsi olevaan kantaan mistä tahansa ja tehdä siellä mitä tahansa, ja niin voi tehdä kuka muu tahansa, joka on kalastanut tunnuksesi tietoonsa.
Itse kartan julkaisun työnkulku on QGIS-käyttäjän näkökulmasta yksinkertaisin mahdollinen. Visualisointi säädetään QGIS Desktopissa kohdalleen viimeiseen piirtoon asti ja sitten hoidetaan julkaisu laajennuksesta nappia painamalla. Lähtökohtaisesti sinun ei siis tarvitse tietää mitään kartan verkkojulkaisussa tarvittavissa tekniikoista ja rajapinnoista.
WMS-rajapinnan julkaisu on tavallaan vielä helpompaa, sillä sellainen tulee julkaistua halusi tai ei. QGIS Cloud tekee julkaistusta kartasta aina WMS-palvelun, joka on käytettävissä avoimesti. Sulavampaa kartansiirtelyä kaipaavat voivat ottaa käyttöön WMTS:n. Kun myös WFS, WFS-T ja WCS:kin onnistuvat, voidaan todeta OGC-kattavuuden olevan kunnossa. Konfigurointimahdollisuudet ovat tietysti rajalliset vaikkapa GeoServeriin verrattuna.
Entä sitten se alussa mainittu geoprosessointi? Onko konsultti ottanut käyttöön halvan tempun unohtaa se tarve, joka ei onnistukaan tarjotulla tuotteella? Ei toki, mutta asia on vähintään yhtä kertaluokkaa kompleksisempi.
Ensinnäkin on oikeasti syytä pohtia tarkasti, onko aito tarve tehdä prosessointia pyynnöstä vai laskea tulokset etukäteen ja panostaa tulosten esittelyyn. Jos geoprosessointipalvelu on todella tarpeen julkaista, on siihenkin vaihtoehtoja, joista tosin yksikään ei ole QGIS Cloud. Kun se kuitenkin on nyt jo otettu käyttöön, on siitäkin huomattava etu: data on jo valmiiksi saatavilla pilvessä!
Kuten edellä kerrottiin, QGIS Cloudiin ladattuun dataan pääsee helposti käsiksi, ja jatkojalostamisen näkökulmasta se kääntyy eduksi. Kun kantaan saa yhteyden mistä tahansa, siihen saa yhteyden helposti myös geoprosessointirajapintojen julkaisemiseen tarvittavista tuotteista. Tässä kohtaa voi olla hyvä ottaa yhteyttä ICT-yksikön Penaan ja kysyä, onnistuisiko vaikkapa pygeoapin saaminen julkiseen verkkoon, kun sinne ei nyt tarvita omaa kantaakaan.
Ohjelmistokoodia pidetään useimmiten tekijänoikeuden alaisena teoksena. Näin ollen ohjelmistokoodin käyttö edellyttää lupaa koodin omistajalta. Ilman lupaa koodia ei saa ottaa sen kirjallisessa muodossa käyttöön tai levittää eteenpäin. Jos tekijänoikeuden teokselle automaattisesti syntyviä rajoituksia kuitenkin haluaa vähentää, koodi kannattaa lisensoida avoimella ohjelmistolisenssillä. Lisenssi määrittää, mitä koodilla on lupa tehdä ja miten. Lisenssejä voi pitää “lupamalleina”, joissa määritetään koodin käyttöön annetut luvat ja rajoitteet silloin, kun ne poikkeavat tekijänoikeudesta.
Jos siis haluat julkaista työsi avoimesti muiden käyttöön, tarvitset sille lisenssin.
Avointen ohjelmistolisenssien käyttö edistää muokkauksia ja koodin kehittymistä, ja haluamme Gispolla aina rohkaista mahdollisimman avoimeen mutta kuitenkin tietoiseen ja harkittuun lisenssien käyttöön. Tässä artikkelissa esitellään lyhyesti avoimia ohjelmistolisenssejä ja pyritään auttamaan avointen ohjelmistojen ja lähdekoodien parissa työskenteleviä lisenssien valinnassa.
Mitkä asiat vaikuttavat lisenssin valintaan?
Kun mietitään miten avoimena julkaistava ohjelmisto tai koodi halutaan lisensoida, muutamalla kysymyksellä päästään alkuun lisenssin valinnassa. Miettimällä vastausta seuraaviin kysymyksiin voidaan ainakin määrittää minkälainen lisenssi sopisi parhaiten omaan julkaisuun. Lisenssien päätyyppejä ovat sallivat lisenssit ja tarttuvat lisenssit, joista kerrotaan tarkemmin myöhemmin artikkelissa.
- Onko julkaistava ohjelmisto tai koodi kaikilta osin täysin omaa, vai onko mukana kolmannen osapuolen komponentteja? Jos mukana on muiden julkaisemaa koodia, sen lisenssi vaikuttaa uudelleenjulkaisussa valittavissa oleviin lisensseihin. Pääsääntönä voidaan pitää, että sallivat lisenssit mahdollistavat uudelleenlisensoinnin melko vapaasti, kun taas tarttuvat rajoittavat uudelleenlisensointia.
- Millä ehdoilla julkaisu voidaan ja halutaan tehdä? Saako koodia tai ohjelmistoa kopioida, muokata ja jakaa täysin vapaasti? Voiko kolmas osapuoli käyttää sitä omiin tarkoituksiinsa julkaisematta sitä uudelleen ja/tai kiristää sen lisenssiä – jopa muuttaa koodin omisteiseksi? Kuten nimikin sanoo, sallivat lisenssit mahdollistavat erilaisia jatkolisensointeja, kun taas tarttuvat lisenssit edellyttävät avoimuudelle vastavuoroista avoimuutta.
- Miten tiukka lisensointi on tarkoituksenmukaista julkaistavan kokonaisuuden osalta? Etenkin pienestä koodinpätkästä kannattaa todennäköisesti tehdä mahdollisimman avoin, jotta pieni koodikomponentti ei rajaa lisensointia isomman kokonaisuuden osana.
- Saako julkaistavaa ohjelmistoa tai koodia käyttää myös kaupallisessa tarkoituksessa? Avoimet lisenssit ovat nimensä mukaan avoimia, joten jos kaupallista käyttöä halutaan rajata, tulee tarkastella muita vaihtoehtoja.
Mitä tarkoittaa salliva lisenssi?
Sallivat lisenssit (engl. permissive license) ovat avoimista lisenssivaihtoehdoista vapaampia ja siksi yleisemmin käytettyjä. Sallivien lisenssien alla julkaistua koodia saa kopioida, muokata ja jakaa vapaasti. Käytettyä koodia ei tarvitse julkaista. Vapaa tarkoittaa myös jatkolisensoinnin osalta todella vapaata, eli koodin voi julkaista joko edelleen avoimena tai sen voi lisensoida tiukemmin ja siitä voi tehdä jopa omisteista. Useimmiten sallivat lisenssit kuitenkin edellyttävät alkuperäiseen lähteeseen viittaamista koodia käytettäessä.
Milloin valita salliva lisenssi?
- Jos haluaa olla vapaa vastuista julkaistun koodin osalta
- Jos haluaa antaa täysin vapaat kädet koodin jatkokäytölle ja -julkaisemiselle
- Jos haluaa mahdollistaa lisenssin muuttamisen toisenlaiseksi myöhemmin
Yleisiä sallivia lisenssejä
- MIT (Massachusetts Institute of Technology License)
- Selkeä ja yksinkertainen, edellyttää lähinnä maininnan alkuperäisestä tekijästä ja lisenssistä
- Yhteensopiva hyvin monien muiden lisenssien kanssa
- BSD (Berkeley Software Distribution License)
- Alkuperäinen 4 lausekkeen BSD-lisenssi on rajoittavin ja edellyttää mm. alkuperäisen kehittäjän mainitsemisen ohjelmiston mainosmateriaaleissa
- 3 lausekkeen BSD-lisenssissä ei ole mainoslauseketta, mutta vastuuvapauslausekkeet ovat mukana (kehittäjät eivät ota vastuuta tuotteen virheistä tai puutteista) ja lisenssi edellyttää niiden säilyttämistä
- 2 lausekkeen BSD-lisenssissä ei ole mainoslauseketta eikä se edellytä vastuuvapauslauseikkeiden säilyttämistä
- Apache
- Sisältää patenttioikeudet, eli lisenssi sallii myös ohjelmiston mukana mahdollisesti tulevien patenttien käytön.
- Ei sisällä tavaramerkkioikeuksia, eli mahdollisesti mukana tulevien tavarmerkkien käytölle tarvitaan erillinen lupa
- Edellyttää kaikkien alkuperäisten tekijänoikeusilmoitusten, lisenssien ym. sisällyttämistä muutoksiin ja jakeluihin
Mitä tarkoittaa tarttuva lisenssi?
Tarttuvat lisenssit (engl. copyleft license) ovat avoimia lisenssejä, joiden alaista koodia saa myöskin kopioida, muokata ja jakaa vapaasti. Olennaisin ero salliviin lisensseihin verrattuna on, että tarttuvalla lisenssillä lisensoitu koodi on yleensä julkaistava samalla avoimella lisenssillä, jos koodia käyttävä sovelluskin julkaistaan. “Tarttuvuus” tarkoittaa, että koodi, joka on otettu käyttöön avoimena, on myös pidettävä avoimena, jos sitä jatkokehitetään tai otetaan käyttöön osana muuta koodia. Vaatimuksen mukana koodin julkaisijalle siirtyy myös vastuu siitä, että julkaistu koodi todella on avointa eikä siinä ole tekijänoikeuksin suojattuja osia.
Milloin valita tarttuva lisenssi?
- Jos haluaa varmistua siitä, että koodin lisensointia ei voi muuttaa (esim. siitä ei voi tehdä omisteista)
Yleisiä tarttuvia lisenssejä
- GPL (General Public License):
- Julkaistaessa koko koodi julkaistava tämän lisenssin alla, eli kaikki julkaistava koodi muuttuu GPL-lisensoiduksi, vaikka se olisi alunperin ollut jotain muuta. Ei salli uudelleenlisensointia.
- Lisenssistä on olemassa eri versioita.
- EUPL (European Union Public License):
- GPL-yhteensopiva lisenssi, eli EUPL:n alaista koodia voi uudelleenlisensoida GPL-lisenssillä.
- Euroopan komission hyväksymä, suunniteltu Euroopan juridiseen kontekstiin (useimmat muut USA:n)
- Käännetty EU:n virallisille kielille
- LGPL (Lesser General Public License):
- Sallii joissakin tapauksissa käytön osana ei-GPL lisensoitua ohjelmistoa (koodi on kyettävä ottamaan käyttöön dynaamisesti linkittämällä)
- Ensisijaisesti tarkoitettu ohjelmakirjastoja varten
Ole huolellinen valitessasi lisenssiä
Lisenssin valinta ei ole yksinkertainen tehtävä. Seuraavat asiat on hyvä pitää mielessä, kun lisenssin valinta on ajankohtaista.
- Käy läpi julkaistava kokonaisuus ja siinä mahdollisesti käytettävät kolmansien osapuolien tuottamat komponentit. Varmistu, että komponentit on lisensoitu ja mitä lisenssit määräävät uudelleenjulkaisusta ja niissä käytettävistä lisensseistä. Lisenssien muuttaminen yhdestä toiseksi ei aina ole sallittua! Lisenssien yhteensopivuuksista löytyy paljon tietoa netistä ja niiden selvittämiseen on olemassa myös skannerityökaluja kuten esim. https://github.com/CycloneDX/license-scanner.
- Ota tekoäly huomioon. Jos koodaamisen apuna on käytetty tekoälypohjaisia työkaluja kuten GitHub Copilot, riski lisensoidun koodin mukanaolosta on olemassa. Käytä tekoälyä harkiten ja katso käyttämäsi työkalun asetukset kuntoon, jotta vältyt (ainakin todennäköisemmin) lisenssiongelmilta.
- Toimi lisenssivalinnoissa tietoisesti ja kirjaa ylös tehdyt toimenpiteet lisensoinnin oikeaoppisuuden takaamiseksi.
_____________________________________________
Tämän artikkelin on kirjoittanut Linda Talve.
Kesälomilta palatessaan gispolaiset saivat huomata, että joukkoomme on liittynyt rautaisa annos paikkatietokokemusta. Me olemme jo hetken saaneet tustustua tulokkaaseen, joten on aika päästää hänet esittäytymään julkisesti
Kuka olet?
Olen Pirjo, suunnittelumaantieteilijä (FM, Helsingin yliopisto), paikkatietoasiantuntija ja karttojen ystävä. Visualisoimalla ja analysoimalla maantieteellistä dataa voidaan tehostaa toimintaa ja tehdä parempia päätöksiä. Nautin uusien teknologioiden hyödyntämisestä sekä luonnossa liikkumisesta koiran kanssa. Vapaa-ajalla viihdyn puutarhanhoidon ja kukkien parissa. Pidän asiantuntijatyöstä, jossa voin auttaa asiakkaita hyödyntämään, ymmärtämään ja visualisoimaan laajoja tietokokonaisuuksia.
Mistä pidät?
Pidän matkustelusta, luonnossa liikkumisesta, retkeilystä ja sähkömaastopyöräilystä. Harrastan puutarhanhoitoa ja kukkien kasvattamista, mikä tarjoaa rentouttavan vastapainon työlle. Nautin uusien asioiden oppimisesta ja niiden hyödyntämisestä paikkatiedon parissa.
Mikä paikkatietoalassa kiehtoo ja miksi juuri Gispo?
Paikkatietoalassa kiehtoo sen kyky yhdistää fyysinen maailma digitaaliseen analytiikkaan, jolloin voimme havaita yhteyksiä, jotka muuten jäisivät huomaamatta. Gispo erottuu avoimen teknologian ratkaisujen avulla, edelläkävijänä edistäen paikkatiedon kehitystä avoimuuden ja yhteistyön kautta. Näin luodaan tulevaisuuden mahdollisuuksia.
Mikä on supervoimasi?
Optimismi ja innostuminen. Uskon, että tulos syntyy tekemällä ja yhdessä olemme enemmän.