Helsingin Esplanadilla kolme LiDAR-valotutkaa on tarkkaillut liikennettä marraskuusta 2023 elokuuhun 2024. Datan keräämisen on tehnyt Flow Analytics ja aineisto on lisäksi ladattavissa (edellyttää tunnusten luomista): https://flow-portal.com/. Tuotettua dataa on paljon, ja enää puuttui työkalu sen analysointiin.
Forum Virium Helsingin kanssa teimme projektin, jonka tavoitteena oli kehittää työkalu LiDAR-tutkilla kerätyn liikennedatan analysointiin sekä tehdä pieni analyysi tästä kokeellisesta datasta. Työkalun loppukäyttäjinä tulisi olemaan Helsingin kaupungin liikennetutkijat. LiDAR-tutkat mahdollistavat laajemman liikennedatan keräämisen kuin perinteisemmät liikennelaskentamenetelmät, joten niiden käytön voi olettaa lisääntyvän ja siten niiden tuottaman datan analysointiin soveltuvalle työkalullekin on tarvetta.
Analyysityökalu päätettiin kehittää QGIS-lisäosaksi, joka sai nimen FVH-3T (Forum Virium Helsinki – Traffic Trajectory Toolkit). Lisäosa muodostuu parista painikkeesta ja kolmesta QGIS-prosessointialgoritmista, ja sen käyttö onkin siten hyvin yksinkertaista: Aluksi käyttäjä tuo tutkittavan pistetason QGISiin ja luo tyhjän portti- ja aluetason lisäosien työkalupalkin painikkeilla. Seuraavaksi käyttäjä piirtää portti- ja aluekohteita niihin sijainteihin, joissa hän haluaa tutkia liikennettä.
Kun portti- ja aluekohteet on piirretty, on aika suorittaa prosessointialgoritmi. FVH-3T -lisäosassa on näitä kolme: kaksi on varsinaista liikennelaskentaa varten ja kolmatta voidaan käyttää, kun halutaan exportoida porttien laskemia tietoja JSON-muotoon. Ennen laskennan suorittamista kahdessa “Count trajectories” -prosessointialgoritmissa käyttäjä voi asettaa laskennan ajanjakson sekä kulkutapaluokan. QGIS-lisäosan prosessointialgoritmin ajaminen muodostaa pistedatasta liikeratoja eli trajektoreja ja laskee sekä näille että piirretyille porteille ja alueille liikkumiseen liittyviä tietoja. Prosessointialgoritmi voidaan suorittaa yksittäisajona halutulle ajanjaksolle tai jakaa se pienempiin aikasarjoihin käyttäen QGISin eräajo-ominaisuutta.
Kuten edellä todettiin, prosessointialgoritmin ajaminen piirtää tarkasteltavan aikavälin pistedatasta liikeratoja; suorittaessa liikennelaskentaa alueilla, prosessointialgoritmi muodostaa trajektorit vain alueiden sisällä olevista pisteistä, kun taas porttien prosessointialgoritmia käytettäessä trajektorit piirretään kaikille valitun kulkutapaluokan pisteille kyseisellä aikavälillä.
Trajektoreille lasketaan niiden pituus ja ajallinen kesto sekä keskimääräinen ja maksiminopeus. Jokaiselle käyttäjän piirtämälle alueelle lasketaan sen leikkaavien liikeratojen lukumäärä sekä niiden keskimääräinen nopeus. Näin voidaan tarkastella esimerkiksi risteyksen ruuhkautumista. Porteille lasketaan puolestaan ne leikkaavien trajektorien lukumäärä per suunta sekä leikkaavien trajektorien keskimääräinen hetkellinen nopeus ja kiihtyvyys.
FVH-3T QGIS-lisäosaa voidaan käyttää mm. liikenteen sujuvuuden analysoimiseen yleisellä tasolla sekä tarkempaan yksittäisten liikkujien tarkasteluun. Trajektorien avulla voidaan esimerkiksi tarkastella kuinka tunnollisesti jalankulkijat käyttävät suojateitä vai ylittääkö moni ajotien väärästä kohdasta. Vastaavasti trajektoreista voidaan analysoida käyttävätkö pyöräilijät heille tarkoitettuja pyöräkaistoja vai ajaako moni esimerkiksi jalkakäytävällä. Porttien avulla voidaan tarkastella liikennemääriä, nopeuksia ja kiihtyvyyksiä halutuissa sijainneissa sekä sitä ajavatko jotkin autoilijat tai pyöräilijät vääriin ajosuuntiin. Alueilla voidaan puolestaan analysoida esimerkiksi liikenteen ruuhkautumista risteysalueilla autojen keskimääräisten nopeuksien avulla.
Suorittamassamme pienessä analyysissä havaitsimme esimerkiksi, että autojen liikennemäärät olivat havainnointiajanjaksolla keskimäärin suurimmat perjantaisin ja matalimmat sunnuntaisin. Toisaalta emme havainneet merkittäviä viikonpäiväkohtaisia eroja ajoneuvojen keskimääräisissä nopeuksissa risteysalueilla. Analyysillä oli mahdollista tunnistaa yksittäisiä päiviä, jolloin autojen keskinopeus oli tavanomaista hitaampi risteysalueilla. Nämä olivat päiviä, jolloin alueella on ollut hyvin paljon jalankulkijoita. Esimerkiksi 15.8.2024 on vietetty Helsingin Taiteiden yötä, jonka vaikutukset näkyvät autojen keskinopeudessa.
Jalankulkijoiden liikkeistä havaitsimme sen sijaan esimerkiksi, että vaikka enemmistö käyttää suojateitä tunnollisesti, on kuitenkin melko yleistä ylittää ajorata väärästä kohdasta. Vastaavasti voitiin havaita, että vaikka Esplanadin alueen pyöräkaistat ovat ahkerassa käytössä, osa pyöräilijöistä ajaa jalankulkijoille tarkoitetuilla väylillä.
Projekti oli mielenkiintoinen, eikä vähiten siksi, että pääsimme kokeilemaan itse luomaamme työkalua tositoimissa sekä tutustumaan liikenneanalyysin alkeisiin. Luodun työkalun suurimpia vahvuuksia on, että liikennetutkija pääsee itse määrittelemään portit ja alueet juuri sellaisille sijainneille, joista on kiinnostunut.
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.
Keväällä 2025 tarjoamme avoimina kursseina joukon suosituimpia kurssejamme. Avoin kurssi on kurssi, jolle me annamme päivämäärän ja kuka tahansa voi ilmoittautua kurssille mukaan.
Jos valikoimasta ei löydy sinulle sopivaa koulutusta, voit aina pyytää meiltä tarjouksen omiin tarpeisiisi – niin sisällöllisesti kuin aikataulullisestikin – sopivasta koulutuksesta
- QGIS-lisäosien kehitys 21.–24.1.2025
- Johdanto QGISin käyttöön 28.–29.1.2025
- Introduction to QGIS 4.–5.2.2025
- QGIS plugin development 18.–21.3.2025
- PostgreSQL ja PostGISin perusteet 1.–4.4.2025
- Paikkatiedon mobiilikeruu QFieldillä 8.–9.4.2025
- Johdanto paikkatietoon ja QGISin käyttöön 13.–16.5.2025
- Johdanto GeoServerin käyttöön 20.–23.5.2025
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ä!
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.
Jos organisaatiossanne on käytössä GeoServer, tarkistakaa viipymättä GeoServerin etusivulla alalaidasta näkyvästä versionumerosta, onko palvelussanne heinäkuussa havaittu merkittävä tietoturva-aukko. GeoServerin virallisilla sivuilla on ohjeet, joiden mukaan kannattaa toimia välittömästi palvelun päivittämiseksi. Jos tarvitsette apua tässä prosessissa, voitte ottaa yhteyttä meihin info@gispo.fi
Jos palvelunne ajan tasalla päivitysten suhteen ja kyseinen tietoturvariski ei koske teitä., voitte lukea GeoServer 3:a koskevan uutisen. GeoServer 3:n kehitystyö on alkamassa ja nyt suunnitelllaan sen kehitystöitä. Työtä varten tarvitaan sekä yksittäisten ihmisten että organisaatioiden tukea, jolla taataan GeoServerin jatko laadukkaana avoimen lähdekoodin alustana. Tukea voi mm. osallistumalla joukkorahoituskampanjaan.
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.