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.
Yhteisöllisyydessä on voimaa! Me gispolaiset tuemme FOSS4G-yhteisöä muun muassa säännöllisillä talkoilla avoimuuden kehittämiseksi. Heinäkuun alussa osa meistä matkasi FOSS4G-konferenssiin Viroon oppimaan uutta ja jakamaan vuorostaan omaa osaamistamme. Mutta miksi yhteisöllisyys on niin tärkeää avoimen lähdekoodin projekteissa?
Kehitys ja jatkuvuus
Yhteisöllisyys takaa, että käytössä on laajemman joukon innovatiivisuus ja taidot! Mitä enemmän ihmisiä on kehittämässä, sitä enemmän on myös vaatimuksia ohjelmistolle – eli toisin sanoen motivaatiota kehittää ratkaisuja ja työkaluja yhä useampiin ongelmiin ja käyttäjätapauksiin. Jokaiselle löytyy jotakin tehtävää, sillä vaikket osaisi itse koodata jotakin lisäosaa tai toiminnallisuutta, jo sen ideointi on hyödyllistä. Isoissa avoimen lähdekoodin projekteissa myös jatkuvuudella on suuri merkitys. Innovatiisuus, laadukas kehitys ja pidemmän aikavälin suunnitelmat motivoivat kehittäjiä ja kannustavat myös uusia tekijöitä mukaan!
Laatu ja turvallisuus
Useamman kehittäjän ja testaajan läpikäymä koodi on luonnollisesti virheettömämpää. Toinen voi antaa enemmän käytettävyydelle kun taas toinen keskittyä tehokkuuteen. Esimerkiksi NLS GeoPackage Downloaderin kaltaiselle, suurehkoja datamassoja pyörittävälle lisäosalle on tärkeää, että koodauksessa on huomioitu nopeus ja käytön sujuvuus. Toisaalta myös käyttäjäkunnan laajuus parantaa ohjelmistojen toimivuutta, kun useammat havaitsevat puutteita ja kirjoittavat virheraportteja.
Käyttäjille ja kehittäjille tukea
Hyvä dokumentaatio varmistaa, että pitkään jatkuvissa avoimen lähdekoodin projekteissa, kuten vaikkapa QGISissa, myös uudet kehittäjät pääsevät mutkattomasti mukaan prosessiin. Yhteisöllisyys on elävää ja näkyy parhaimmillaan aktiivisena käyttäjäkuntana, jolla on omat fooruminsa tiedon jakamiselle. Avoimen lähdekoodin paikkatieto-ohjelmistoille tällaisia alustoja ovat esimerkiksi GitHub, StackOverflow, Matrix sekä eri sähköpostilistat. Toisinaan järjestetään myös tapahtumia, kuten vaikkapa FOSS4G- ja QGIS-käyttäjäpäiviä ympäri maailmaa. https://www.osgeo.org/events/
Oppiminen
Kaikki hyvä ei tietenkään valu vain itse tuotoksiin. Osalliset voivat kasvattaa ammattitaitoaan oppimalla tekemisen lomassa ja samalla verkostoitua yhteisössä. Varoitus – verkostoituminen voi johtaa mielenkiintoisiin urapolkuihin ja avata uusia ovia!
Miten päästä mukaan tekemiseen?
Jokaisella on jotakin annettavaa avoimelle kehitykselle, mikäli on vain intoa lähteä mukaan! Aloittaa voi vaikkapa QGISin käännösten parantamisesta, johon voi tutustua Transifexissa. https://explore.transifex.com/qgis/
StackOverflow’ssa voi kysyä apua ja ratkoa muiden käyttäjien ongelmia. https://stackoverflow.com
Rohkeasti mukaan!
Nykypäivän digitaalisissa vuorovaikutteisissa kartoissa käyttäjä voi itse saada näkyviin haluamaansa tietoa. Selain- ja ohjelmistopohjaisissa karttakäyttöliittymissä on tyypillisesti paljon toiminnallisuuksia ja niiden sujuva hyödyntäminen edellyttää palvelulta hyvää käytettävyyttä, joka on suunniteltu ottaen huomioon käyttäjän tieto- ja taitotaso. Parhaimmassa tapauksessa käyttö on tehokasta ja vaivatonta, mutta pahimmillaan palvelun käyttäminen voi aiheuttaa käyttäjässä paljon turhautumisen tunteita.
Mitä käytettävyys on ja miten sitä tutkitaan?
Käytettävyydelle on olemassa useampi määritelmä, joista tunnetuimmat ja käytetyimmät lienevät ISO-standardin (ISO 9241-11:2018) sekä käytettävyyden uranuurtajan Jakob Nielsenin määritelmät. Molemmat määritelmät korostavat sitä, kuinka helppoa käyttöliittymän käyttö on eli kuinka tehokkaasti ja mielekkäästi käyttäjä suoriutuu määritellyistä tehtävistä ja tavoitteista tietyssä käyttöympäristössä.
Käytettävyystutkimuksen keskiössä ovat itse käyttäjät, ja useimmiten tutkimus pohjautuu käyttäjätestaukseen. Käyttäjäkokemusta voidaan kartoittaa muun muassa erilaisten kyselyiden avulla tai havainnointiin perustuvilla tutkimuksilla, kuten silmien liikkeen seurannalla. Toisaalta tutkimus voi pohjautua myös asiantuntijoiden tekemään käytettävyystarkasteluun kuten heuristiseen arviointiin, jossa käyttöliittymää arvioidaan erilaisten käytettävyysperiaatteiden ja heuristiikkojen avulla. Heuristisessa arvioinnissa pääpaino on käytettävyysongelmien löytämisessä ja sitä voidaan tehdä jo suunnittelu- ja testausvaiheessa.
Karttakäyttöliittymä ja sen käytettävyyssuunnittelu
Karttakäyttöliittymällä viitataan karttapalvelun siihen osaan, jonka kautta käyttäjä käyttää palvelua. Kyseessä on tyypillisesti visuaalinen käyttöliittymä, jonka avulla käyttäjä voi hyödyntää palveluun kuuluvia erilaisia toiminnallisuuksia. Esimerkiksi interaktiivisiin karttapalveluihin kuuluu useimmiten lähennys- ja loitonnuspainike, joita painamalla karttanäkymää saa zoomattua lähemmäs tai kauemmas. Karttakäyttöliittymän kautta on yleensä mahdollista vaikuttaa karttanäkymässä näkyvään tietoon ja tarkastella esimerkiksi kohteiden ominaisuustietoja.
Käytettävyyssuunnitelun kohdalla puhutaan yleensä käyttäjäkeskeisestä suunnittelusta (User-Centered Design, UCD), jossa tavoitteena on ottaa huomioon käyttäjän toiveet ja tarpeet ja huomioida myös käyttäjän palveluun liittyvä tieto- ja taitotaso. Esimerkiksi reittisuunnitteluun tarkoitetuissa karttapalveluissa käyttäjä voi olla käytännössä kuka tahansa, jolloin käyttöliittymä tulisi suunnitella niin, että sujuva käyttäjäkokemus ei riipu siitä, kuinka paljon aikaisempaa kokemusta käyttäjällä on vastaavien palveluiden käytöstä tai kuinka hyvin hän tuntee paikkatiedot. Aiheeseen liittyvä osaaminen todennäköisesti kuitenkin helpottaa palvelun käyttöä ja esimerkiksi asiantuntijakäyttöön tarkoitettujen paikkatieto-ohjelmistojen käyttäjäkokemus on usein riippuvainen käyttäjän paikkatietotuntemuksesta ja tietotekniikan käyttötaidoista, jolloin taitotasoltaan aloittelijan voi olla huomattavasti haastavampaa käyttää tällaisia ohjelmistoja.
Karttakäyttöliittymän suunnittelusta erityistä tekee käyttöliittymän sekä paikkatiedon ja sen kartografisen esityksen yhteensovittaminen, sillä saatavilla olevat paikkatiedot ja niiden esitystapa vaikuttavat merkittävästi luettavuuteen ja sen myötä käytettävyyteen. Palvelun toiminnallisuuksien täytyy toimia sulavasti saatavilla olevan tiedon kanssa ja esimerkiksi lähennys- ja loitonnustoiminallisuuksia käyttäessä karttaelementtien tulisi skaalautua niin, että ne eivät häiritse luku- tai käyttöprosessia. Suunnittelussa tulee siis pyrkiä kartan selkeyteen ja yksinkertaisuuteen.
Mikä on käytettävyyden merkitys loppukäyttäjälle?
Jotta tiedosta ja palvelusta olisi käyttäjälle ylipäätänsä hyötyä, on se esitettävä sellaisessa muodossa, jossa käyttäjä sen voi helposti ymmärtää. Muuten käyttökokemus kärsii. Usein käyttäjät tarvitsevat karttaa sellaisessa tilanteessa, jota ei ole suunniteltu tarkasti etukäteen. Tällöin visuaalinen sotku sekä epäintuitiiviset valikot ja toiminnot voivat hidastaa käyttöä merkittävästi. Esimerkiksi kiireessä nopeimman reitin etsiminen voi olla turhauttavaa, jos tehtävän suorittaminen vaatii monen valikon selaamista tai jos palvelu on vaikkapa altis virheklikkauksille, jotka hidastavat palvelun käyttöä.
Kuvassa 1 näkyvät LIPAS-paikkatietojärjestelmästä haetut Helsingin liikunta- ja ulkoilupaikat tuotuna QGISin käyttöliittymään katseltavaksi. Data on luokiteltu liikuntapaikkatyypin mukaan, mitä eri värit kuvastavat. Tässä näkymässä reittiviivat ovat kovin paksuja ja ne sekoittuvat helposti taustakarttaan. Osa kohteista sekoittuu myös helposti keskenään liian suppean väriskaalan takia, sillä eri tyypin kohteiden värisävyt ovat paikoittain hyvin lähellä toisiaan. Lisäksi pistemuodossa oleva data peittää tässä näkymässä alleen paljon tietoa symbolien suuren koon takia.
Kuva 1. Helsingin liikunta- ja ulkoilupaikat (datalähde: LIPAS) QGISin käyttöliittymässä.
Kuvassa 2 puolestaan LIPAS-karttapalvelussa eri värien lisäksi eri liikuntapaikkatyyppejä kuvastavat värin lisäksi eri muodot, mikä helpottaa eri tyypin kohteiden erottamista toisistaan. Toisin kuin kuvan 1 näkymässä, kuvassa 2 karttaelementeillä on myös jonkin verran läpinäkyvyyttä, minkä ansiosta käyttäjä voi huomata kohteiden päällekkäisyyden helpommin.
Kuva 2. Helsingin liikunta- ja ulkoilupaikat LIPAS-karttapalvelussa.
Kuvassa 3 on esitetty loitonnettu näkymä kuvan 1 karttanäkymästä, ja siitä voidaan huomata, etteivät karttaelementit skaalaudu tässä tapauksessa ollenkaan. Nyt karttaelementit peittävät merkittävän osan taustasta, ja kohteiden todellista sijaintia on vaikea hahmottaa. Kaikki kohteet ovat edelleen näkyvissä, ja lukuisia kohteita on päällekkäin niin, että on vaikea hahmottaa esimerkiksi kohteiden todellista lukumäärää alueilla, joilla on paljon kohteita.
Kuva 3. Loitonnettu näkymä kuvan 1 karttanäkymästä.
Kuvassa 4 näkyy loitonnettu näkymä kuvan 2 karttanäkymästä. Tästä voidaan huomata, että karttaelementtien koko on skaalautunut ja osa datasta on kadonnut pois näkyvistä. Jos jokainen saatavilla oleva kohde olisi näkyvillä tässä näkymässä, sotkun määrä lisääntyisi merkittävästi, kuten kuvassa 3 nähtiin. Nyt karttanäkymä näyttää siistiltä, ja halutessaan nähdä tarkemmin tietyn alueen kohteita käyttäjä voi lähentää karttanäkymää, jolloin ne ilmestyvät näkyviin.
Kuva 4. Loitonnettu näkymä kuvan 2 karttanäkymästä.
Kuten näistä esimerkeistä voidaan huomata, jo pelkästään karttaelementtien ulkoasun suunnittelu vaikuttaa merkittävästi karttakäyttöliittymän käytettävyyteen ja karttanäkymän luettavuuteen. Kohteiden huono skaalautuvuus häiritsee merkittävästi yksittäisten kohteiden tarkastelua ja valitsemista karttanäkymässä. Jos kuvan 1 tapaus olisi karttapalveluun viety toteutus, sen käytettävyys voisi kärsiä merkittävästi. Myös karttaelementtien läpinäkyvyyden merkitys korostuu näissä käyttöesimerkeissä, sillä läpinäkyvyyden puuttuminen hidastaa luku- ja havainnointiprosessia merkittävästi kuvan 1 tapauksessa. Lisäksi riittävä kontrasti voisi helpottaa kohteiden erottelua toisistaan sekä taustakartasta. Pahimmillaan huono kartografinen esitys voi siis olla käyttäjälle harhaanjohtava ja hidastaa palvelun käyttöä merkittävästi. Parhaimmillaan taas hyvin suunniteltu karttakäyttöliittymä johtaa sulavaan käyttökokemukseen ja käyttäjä haluaa käyttää palvelua myös jatkossa.
Osaksi kehitysprosesseja
Käytettävyysongelmia voidaan ennaltaehkäistä tehokkaasti jo kehitysvaiheessa kartoittamalla esimerkiksi palvelun kehityksenaikaisia käytettävyysongelmia ja korjaamalla niitä. Kääntöpuolena on se, että kattava käytettävyysanalyysi voi vaatia myös paljon resursseja. Erityisesti avoimien ohjelmistojen käytettävyyden parantamisesta haasteellista tekee se, että projekteissa on harvemmin mukana käytettävyyden asiantuntijoita ja resurssit voivat olla hyvin rajalliset. Vaikka avoimessa yhteisössä käytettävyysongelman löytäjällä on mahdollisuus korjata virhe itse tai raportoida ongelma kehittäjälle, riskinä on, että ongelma voi käytännössä jäädä täysin korjaamatta. Monelta käyttäjältä voi puuttua myös riittävä tekninen osaaminen käytettävyysongelmien korjaamiseksi. Siksi on tärkeää ottaa käytettävyys huomioon jo kehitysprosessissa. Mikäli resurssit ovat tiukalla, on hyvä keskittyä löytämään ongelmat, jotka vaativat välittömästi huomiota ja korjaamista. Esimerkiksi heuristinen arviointi on vähän resursseja vaativa metodi vakavien käytettävyysongelmien löytämiseen.
Tämän artikkelin on kirjoittanut Anna Saarinen
Meillä on maakuntien Ryhti-kumppanuushanketta yli puoli vuotta takana ja ajattelimme kertoa, mitä kehitystiimin kanssa on saatu aikaan. Takana on jo monta pitkää käyttäjätarinaa, paljon koodia sekä keskusteluja. Nyt alkaa jo loppu häämöttää. Jos et tiedä, mikä Ryhti on, niin tutustu kaavoituksen ja rakennetun ympäristön digitalisaatioon ja sen prosesseihin Syken sivuilta.
Yhdessä Lounaistiedon, Varsinais-Suomen liiton, Uudenmaan liiton ja Kymenlaakson liiton kanssa lähdettiin tuottamaan avoimen lähdekoodin paikkatietoratkaisua maakuntakaavoittajille, jolla voidaan viedä kaavatiedot Ryhti-järjestelmään. Tavallaan asia on varsin simppeli: kaavatiedot viedään kansalliseen järjestelmään samassa muodossa. Käytännössä työ vaatii monta eri vaihetta ja tässä niistä kooste.
- Kaavoittajan työkalun pitää tukea kaavoittajan omia prosesseja ja siksi käyttäjätarpeiden määrittely on erittäin olennaista. Eri kaavatasoilla on hieman erilaiset tarpeet ja ne voivat vaikuttaa työkalun sisältöön.
- Kaavatiedot pitää tuottaa tai muuntaa kansallisen kaavatietomallin mukaiseksi. Jos kaavatiedot tuotetaan alusta asti mallia mukaillen, voidaan kaavoittajan työkalussa hyödyntää suoraan esimerkiksi kaavatietomallin koodilistoja.
- Kunnan tai maakunnan kaavatiedot validoidaan ennen kuin ne viedään Ryhti-järjestelmään. Käytännössä validointi on hyvä tehdä valmiiksi kaavoittajan työkaluun, ja Ryhti tarjoaakin validointiin avoimen rajapinnan, jota voimme käyttää.
- Tietojen siirtäminen Ryhti-järjestelmään vaatii palveluväyläyhteyden hankintaa. Palveluväylä on kansallinen turvallinen tiedonsiirtostandardi. Meidän tapauksessamme päädyimme asentamaan kaavoittajan työkalun tietokannan oheen palveluväyläpalvelimen, joka hoitaa tiedonsiirron Ryhtiin.
- Kaavoittajan työkalussa pitää olla valinta, jolla kaavoittaja päättää, milloin kaava on valmis vietäväksi Ryhtiin. Ensimmäisellä kerralla vietäessä tietokantamme saa Ryhdistä kaavatunnuksen, joka säilyy kaavalla koko sen elinkaaren ajan.
- Vaikka Ryhti-tekeminen on pitkälti datan rakenteellistamista, on visualisoinneilla edelleen tärkeä tehtävä ihmisluettavan kaavan tuotannossa. Kaavasta pitää toimittaa Ryhtiin GeoTIFF-muotoinen kaavan visualisointi ja kaavoittaja itse haluaa varmasti visualisoida kaavatiedot perinteisen kaavakartan tapaan joko pdf:nä tai karttapalvelussa.
Maakuntakaavojen tapauksessa kaavoittajan työkalu löytyy työnimellä Hame-Ryhti GitHubista. Nimi johtaa juurensa Hame-työhön, jossa maakuntakaavoittajat ovat jo pitkään harmonisoineet maakuntakaavoja tiiviissä yhteistyössä. Hame-työn tietomallista otettiin inspiraatiota tämän työn toteutukseen.
Tällä hetkellä valmiina on maakuntakaavoitukseen soveltuva kaavatietomalli sekä QGISillä tehty maakuntakaavoittajan projekti lomakkeineen, jolla tietoja voidaan tuottaa. Tiedot tallentuvat PostgreSQL/PostGIS-tietokantaan. Oleellisena osana toteutusta on pilvipalvelun (AWS) muut mikropalvelut, joilla hoidetaan mm. tietokannan tietomallin päivitykset, koodistojen päivitykset sekä kaavatietojen validointi ja vienti Ryhti-rajapintoihin.
Kesän ajattelimme viettää testiaineistoa tuottaen ja validointisääntöjä läpikäyden. Syksyllä pitäisi olla mahdollista vihdoin saada kaavatieto Ryhtiin.
“Maakuntakaavoittajien näkökulmasta Gispo on kumppanitestauksessa tehnyt hyvää pohjatyötä kehittää avoimeen lähdekoodiin perustuva järjestelmä, jolla tuottaa jatkossa Ryhti-muotoista maakuntakaavaa SYKEn ylläpitämään järjestelmään. Kaavoittajat pitävät tärkeänä, että jatkossakin maakuntakaavaa tehdään yhtenäisellä tavalla. Toiveena on, että eri vaihtoehtoja kaavan toteutukselle vielä testataan ennen lopullisen ratkaisun valintaa. Vuosien saatossa yhtenäisistä työkaluista on ollut paljon hyötyä muun muassa koulutuksissa sekä kollegiaalisena vertaistukena maakuntakaavoittajien kesken.”
-Elina, Henri ja Satu, maakuntakaavoittajat
“Lounaistiedon näkökulmasta QGIS-toteutus mahdollistaa maakuntakaavojen keskitetyn tiedonsiirtoratkaisun kansalliseen Ryhti-järjestelmään. Onnistuessaan työkalu tarjoaa kustannustehokkaan tavan tuottaa Ryhti-muotoista maakuntakaavaa ilman, että jokaisen liiton tarvitsee ylläpitää omaa kaavoituksen tietojärjestelmää.”
-Antti, tietopalvelupäällikkö
“Softakehittäjän näkökulmasta maakuntakaava on kaavoista yksinkertaisimpia, ja siksi sillä oli luontevaa lähteä tekemään PostGIS-muotoista kaavatietokantaa. Myös kaavasanoman luominen siirrettäväksi Ryhti-järjestelmään on yllättävän helppoa, kun tietokanta on valmiiksi suunniteltu Ryhti-yhteensopivaksi! Projekti tarjosi mukavan mahdollisuuden kokeilla, miten kaavoitustyökalu saadaan aikaan QGISillä sekä pilvipalvelusta löytyvillä komponenteilla.”
-Riku, kehittäjä
Kaukana ovat löytöretkeilijöiden ajat, jolloin kartat olivat kalliita, harvinaisia ja vain varsin suuntaa-antavia tarkkuudessaan. Erilaisia ulkoiluun ja retkeilyyn liittyviä karttasovelluksia ja karttapalveluita tuntuu olevan joka lähtöön: yksi on kehitetty maastopyöräilijöiden tarpeisiin, toinen purjehtijoille ja kolmas metsästäjille. Käytettävät tausta-aineistot ja sovellusten toiminnallisuudet tuntuvat usein monipuolisilta, mutta lopulta aina joku itselle olennainen juttu tuntuu uupuvan tai on maksullinen jopa testattavaksi. Esimerkiksi, jos pystyn itse piirtämään reitin, en saa sitä jaettua muille. Tai en pysty yhdistämään aineistoja eri lähteistä kuten itse piirtämiäni ja tiedostosta ladattuja. Myös tallennus myöhempää käyttöä varten tai kartan offline-käyttö ovat tyypillisiä rajoitteita.
Ei siis ole ihme, että moni tämänkin päivän retkeilijä arvostaa edelleen fyysistä karttaa. Toisaalta paperikartta on etenkin pidemmillä retkillä ehdottomasti myös turvallisuustekijä. Aina sopivaa paperikarttaa ei kuitenkaan löydy. Eikä karttaa tarvitsekaan aina ostaa kaupasta, vaan sellaisen voi tehdä itse, juuri omien tarpeiden mukaan ja vieläpä aivan ilmaiseksi!
Sähköistä ja paperista kartta-aineistoa ei tarvitse nähdä vaihtoehtoisina tai toisistaan irrallisina. Itse olen jo pitkään haaveillut kokonaisuudesta, jossa retkieni reitit pysyisivät tallessa yhdessä paikassa ja josta voisin tarvittaessa tulostaa haluamani kartat käyttööni tai jakaa aiempia reittejä kavereille.
Koska tämä artikkeli julkaistaan Gispon blogissa, ei ole suuri yllätys, että vastauksen tarjoavat tässä yhteydessä avoimen tiedon rajapinnat sekä avoimen lähdekoodin paikkatietosovellus QGIS. Näillä työkaluilla voi paitsi laatia haluamansa yksittäiset kartat, luoda itselleen omien retkireittien arkiston, johon voi koota kaikki aiemmat, suunnitellut ja vasta haaveiden tasolla olevat mielenkiintoiset reitit omaan käyttöön ja tarvittaessa esimerkiksi kaverille jaettavaksikin. Tarvitaan vain tietokone ja internet-yhteys, sekä ehkä printteri (ja laminointikone).
Kerron seuraavassa, miten tein omalle vaellusporukalleni fyysiset retkikartat QGISilla käyttäen pohjakarttana Maanmittauslaitoksen (MML) maastokartta-aineistoa ja lisäämällä siihen suunnittelemamme vaellusreitin. Lyhyesti vaiheet ovat seuraavat:
- Lataa QGIS
- Luo tili MML:n palveluun ja hae sieltä API-avain
- Hae maastokartta rajapinnalta QGISiin
- Lisää oma reitti kartalle (piirtämällä tai esim. gpx-tiedostosta)
- Tee kartasta haluamasi tuloste(et)
QGISin lataaminen
Jos sinulla ei vielä ole asennettuna paikkatieto-ohjelmistoa, jolla voit käsitellä paikkatietoaineistoja, QGIS on ilmainen ja sen lataus eri käyttöjärjestelmille onnistuu QGISin lataussivulta. On suositeltava ladata viimeisin LTR-versio, joka tätä kirjoittaessa on 3.34. Sen latauslinkki on sivulla suuren vihreän nappulan alapuolella. Syy sille, miksi aivan uusinta versiota (tällä hetkellä 3.36) ei kannata ladata on, että tuo versio on vielä kehitysvaiheessa ja siinä saattaa ilmetä epävakautta.
API-avaimen luominen MML:n palvelussa
Maanmittauslaitoksella on avoimesti jaossa erilaisia koko maan kattavia paikkatietoaineistoja. Näiden käyttö on ilmaista, mutta käyttöön vaaditaan henkilökohtainen API-avain (noin 36 merkkiä pitkä merkkijono), jonka saa muodostettua kirjautuneena käyttäjänä.
Uuden tilin voi luoda täällä. Kun tili on tehty, seuraa MML:n selkeää ohjetta API-avaimen luomiseksi täällä. Kun olet saanut API-avaimen luotua, voit siirtyä seuraavaan vaiheeseen.
Maastokartta QGISiin
Seuraavaksi haetaan maastokartta rajapinnalta QGISiin API-avaimen avulla. Rajapinta-asetus tallentuu QGIS-profiiliin, joten asetukset tarvitsee tehdä yhtä rajapintapalvelua varten vain kertaalleen ja ne ovat jatkossa valmiiksi käytettävissä, kun käytetään samaa QGIS-profiilia. Kun avaat QGISin, profiilin nimi näkyy QGIS-ikkunan yläpalkissa QGIS-sanan perässä hakasulkeissa. Oletusprofiili on nimeltään default.
Kun QGIS on avattu, luo uusi projekti (Projekti > Uusi). Tämän jälkeen lisätään projektiin uusi WMTS-taso (Tasot > Lisää taso > Lisää WMS/WMTS-taso). Avautuvassa ikkunassa luodaan uusi rajapintayhteys kohdasta Uusi.
Avautuvaan ikkunaan (kuva alla) annetaan seuraavat tiedot: yhteyttä kuvaileva Nimi (esim. Maanmittauslaitos) sekä URL-kohtaan rajapinnan osoite https://avoin-karttakuva.maanmittauslaitos.fi/avoin/wmts/1.0.0/WMTSCapabilities.xml . Tämän jälkeen siirrytään syöttämään todennusasetuksia painamalla Autentikointi-kohdasta vihreää +-symbolia.
Autentikointi-ikkunaan annetaan autentikoinnille nimi (esim. MML). Alasvetovalikosta valitaan Basic authentication ja tämän jälkeen kopioidaan MML:n tilillä oleva API-avain kohtaan Käyttäjänimi. Lopuksi painetaan Tallenna.
Nyt todennusasetukset on tallennettu ja yhteyden muodostamista varten MML (Basic) näkyy valittuna. Painetaan OK.
Ikkuna sulkeutuu, minkä jälkeen palataan aiempaan ikkunaan, jossa Maanmittauslaitoksen rajapinta-asetukset ovat nyt valmiit ja voidaan painaa Yhdistä.
Rajapintayhteys aukeaa ja päästään valitsemaan rajapinnalla olevista aineistoista. Valitaan maastokartta Suomessa paremmin toimivalla projektiolla ETRS-TM35FIN ja painetaan Lisää.
Maastokartta aukeaa karttaikkunaan hyvin paljon ulos zoomattuna. Karttaan voi zoomata laittamalla hiiren halutun kohdan päälle kartalla ja pyörittämällä hiiren rullaa.
Reitin lisääminen kartalle
Jos tiedossasi on jo reitti, jonka haluat näkyvän kartalla, sen lisääminen onnistuu joko piirtämällä tai tuomalla reitti esim. gpx-tiedostosta taustakartan päälle. Gpx on saatavilla esim. Stravasta tai muista urheilusovelluksista. Jos vaikka kaverilla on ollut omalla reissullaan kello päällä ja hän haluaa jakaa reittinsä kanssasi, pyydä häneltä reitin gpx-tiedosto.
Reitin piirtäminen
Jos haluat piirtää uuden reitin taustakartan päälle, se tapahtuu luomalla uusi GeoPackage-taso: Tasot > Luo taso > Uusi GeoPackage-taso.
Aukeavassa ikkunassa määritetään ensin Tietokanta eli tässä tapauksessa GeoPackage-tiedosto. Klikkaa oikeassa reunassa näkyvää kolmea pistettä 
. Navigoi sijaintiin, jonne haluat tallentaa GeoPackagen ja anna tiedostolle nimi (esim. Retkireitit). Kohtaan Taulun nimi annetaan piirrettävän reitin nimi (esim. UKK_2024_paiva_1). Geometriatyypiksi valitaan alasvetovalikosta LineString. Toisesta alasvetovalikosta valitaan koordinaattijärjestelmäksi Projektin koordinaattijärjestelmä. Muita kenttiä ei tarvitse täyttää. Paina OK.
Nyt vasemman reunan Tasot-valikossa näkyvät Maastokartta ja äsken luotu uusi viivataso UKK_2024_paiva_1, jolle voidaan alkaa piirtää ensimmäisen päivän reittiä.
Jotta piirtäminen olisi helpompaa, kannattaa himmentää Maastokarttaa tuplaklikkaamalla sen nimen päällä ja valitsemalla avautuvan ominaisuusikkunan vasemmasta reunasta kohta Läpinäkyvyys ja asettamalla Yleinen peittävyys esim. 40 %:iin ja painamalla Käytä. Näin taustakartta himmenee ja piirretty viiva tulee paremmin esille. Myös viivan paksuutta voi lisätä ja väriä muuttaa klikkaamalla viivatason nimen päällä. Kuvaustekniikka-kohdassa voi määritellä viivan värin ja leveyden haluamakseen.
Piirtäminen aloitetaan valitsemalla viivataso UKK_2024_paiva_1 tasovalikosta aktiiviseksi (yksi hiiren klikkaus nimen päällä valitsee tason) ja painamalla ylävalikossa näkyvää kynän kuvaa 
, jolloin taso aukeaa editoitavaksi. Valitaan viivakohteen piirtotyökalu 
, minkä jälkeen voidaan zoomata kartalla sopivaan kohtaan ja alkaa piirtää reittiä hiiren avulla. Jos tulee virheklikkaus, backspace:lla saa poistettua viimeisimmän pisteen. Kun viiva on valmis, painetaan hiiren oikeaa nappulaa. Tason muutokset tallennetaan painamalla uudestaan kynä-nappulaa ja valitsemalla Tallenna. Nyt ensimmäisen päivän reitti on piirretty kartalle. Jos (päivä)reittejä haluaa käsitellä (esim. laittaa näkyviin/pois näkyvistä) erillisinä elementteinä, ne on helpompi piirtää kukin omalle tasolleen.
Reitin tuonti gpx-tiedostosta
Jo olemassa olevan gpx-reitin tuonti onnistuu hyvin helposti vetämällä gpx-tiedosto QGISin tasovalikkoon. Aukeavassa ikkunassa on listattuna paljon asioita, joita gpx-tiedostosta ei tarvitse tuoda. Ensimmäisenä kannattaa poisvalita alareunan valinta Show empty vector layers. Myös valinta Lisää tasot ryhmään voidaan tässä tapauksessa jättää valitsematta. Jäljelle jääneestä listasta kannattaa valita vain routes, koska reittipisteillä ei tässä tapauksessa tee mitään. Paina Lisää tasot. Nyt kartalla näkyy myös kaverilta saatu reitti UKK_2024_paiva_2.
Tietojen tallennus
Edellä piirretty taso (UKK_2024_paiva_1) tehtiin GeoPackage-tasolle, jolloin muodostui myös GeoPackage-tiedosto. Gpx-tiedostosta tuotu reitti puolestaan on osa QGIS-projektia (kunhan projekti on tallennettu).
Jos reittejä ei tarvitse itse piirtää, riittää, että tallentaa QGIS-projektin. Kun projekti avataan uudestaan, projektiin tuodut reitit löytyvät projektista.
Jos taas projektissa on sekä tuotuja että itsepiirrettyjä reittejä, QGIS-projektin voi tallentaa osaksi GeoPackagea, jolloin kaikki tieto pysyy yhdessä paikassa (GeoPackagessa). Suuren taustakartta-aineiston tallentaminen projektiin ei ole suositeltavaa. Projektin tallennus GeoPackageen tapahtuu seuraavasti: Projekti > Tallenna tiedostoon > GeoPackage ja etsimällä haluttu GeoPackage.
GeoPackage on kuin pieni tietokanta. Kun haluat “avata” sen QGISIssa, muodosta yhteys GeoPackageen QGISin Selain-ikkunassa klikkaamalla hiiren oikealla nappulalla ja valitsemalla Uusi yhteys. Tämän jälkeen navigoi sijaintiin, jossa GeoPackagesi on ja avaa se.
Kun yhteys on luotu, se pysyy QGIS-profiilissa ja voit avata siihen tallennetun QGIS-projektin tai muita GeoPackagen tasoja vetämällä niitä Tasot-valikkoon.
Karttatulosteiden tekeminen
Karttatulosteita (QGIS -> pdf -> paperi) voi tehdä maastokartasta vapaasti haluamallaan tavalla, reiteillä tai ilman ja juuri sillä aluerajauksella, joka omaan tarpeeseen parhaiten sopii. Tähän käytetään QGISin taittotyökalua.
Ennen taittotyökalun avaamista valitse näkyviin ne tasot, jotka haluat kartallasi näkyviksi (taustakartta ja mahdolliset reitit). Jos esimerkiksi haluat tehdä reittikartan kullekin vaelluspäivälle erikseen sopivalla zoomaustasolla, valitse vain kyseisen päivän reitti näkyville.
Kun halutut asiat ovat näkyvissä, valitaan Projekti > Uusi taitto ja annetaan taitolle joku sopiva nimi. Aukeaa taittoeditori, josta voi valita paperin koon ja orientaation klikkaamalla auennutta arkkia ja määrittämällä sen koon oikeaan reunaan aukeavasta Elementin ominaisuudet -lomakkeesta. Oma reittini UKK_2024_paiva_1 on melko pohjois-etelä-suuntainen, joten haluan valita pystysuuntaisen arkin. Tämän jälkeen piirrän arkille karttaikkunan, johon haluan karttani piirtyvän painamalla vasemman reunan työkalupalkista löytyvää Lisää Kartta -painiketta 
ja piirtämällä karttani rajaavan suorakulmion arkille. Hetken kuluttua karttani ilmestyy näkyviin, mutta melkolailla uloszoomattuna. Voit liikuttaa ikkunassa näkyvää kartan aluetta (muuttaa rajausta) ja lähentää tai loitontaa sitä valitsemalla Siirrä elementtiä -työkalun 
.
Taittoon voi lisätä haluamiansa elementtejä kuten otsikoita, muita tekstejä, pohjoisnuolen, karttaselitteen, symboleita ym. Omissa kartoissani katsoin mittakaavajanan olevan ainoa olennainen tieto ja lisäsin sen käyttäen Lisää Mittakaavajana -työkalua 
. Erilaisten elementtien ominaisuuksia voi muokata varsin monipuolisesti Elementin ominaisuudet -paneelissa, jonka saa näkyviin ikkunan oikeaan reunaan klikkaamalla QGISin yläreunan työkalupalkin “tyhjässä” harmaassa kohdassa hiiren oikealla ja valitsemalla paneelin näkyviin. Kun elementti on valittuna kartalla, sen muokkausvaihtoehdot näkyvät paneelissa.
Kun taitto on valmis, se kannattaa tallentaa yläpalkin diskettipainikkeesta. Taitot tallentuvat QGIS-projektiin (muista tallentaa myös projekti, kun olet sulkenut taittoikkunan!) ja ovat sieltä jatkossa käytettävissä uusien taittojen pohjaksi tai tulosteiden tekemiseksi. Kartan voi myös viedä pdf:ksi tulostamista varten: Taitto > Vie PDF:ksi. Jotta paperinen kartta sietäisi paremmin ulkoilmaa, jonkinlainen muovitasku tai etenkin laminointi on osoittautunut toimivaksi suojaksi. Kaksi karttaa voi muovittaa “selittäin”, jolloin muovilärpäkkeiden lukumäärä retkivarusteissa puolittuu kätevästi ja kädessä on aina kaksi karttaa kerrallaan.
Paperikartan lisäksi piirretyt reitit voi toki tallentaa QGISista myös gpx-muotoon ja viedä ne gps-laitteeseen tai älykelloon tai jakaa kaverille.
Jälkipyykki ja muut vinkit
Kun olen tallentanut projektin, voin sulkea sen. Nyt minulla on käytössäni GeoPackage, johon voin myöhemmin tuoda myös muiden retkien reittejä ja vähitellen kerätä tiedostoon oman reittiarkistoni. Sen avulla reitit pysyvät tallessa ja voin palata niihin itse tai jakaa niitä muille. QGIS tarjoaa loistavan käyttöliittymän reittiarkistoon, koska voin esimerkiksi ryhmitellä tässä harjoituksessa tehdyt päiväreitit tasoryhmäksi “UKK 2024” ja myöhemmin löydän päiväkohtaiset reitit sen alta.
Kun retkiä ja reittejä kertyy, systemaattinen tiedonhallinta palkitsee. On siis hyvä miettiä tasojen sisällöt ja nimet käyttötarpeiden ja käytettävyyden mukaan heti alusta. Samalle tasolle voi esimerkiksi tallentaa useammankin reitin, mutta se vaikuttaa reittien käyttöön jatkossa. Tasojen nimeäminen informatiivisesti pelastaa, jotta tiedostossa ei aikojen saatossa ole kasautuneena tasoja kuten “reitti1”, “Reitti”, “päivä3” tai “paluumatka”, joista kukaan ei enää ota selvää, että missä ne sijaitsevat, mitkä liittyvät mahdollisesti toisiinsa jne.
Ja jos oikein innostuu, QGIS-projektin voi myös julkaista verkkoon esim. qgis2web-lisäosan avulla, josta voit lukea lisää täältä. Omaa ja kaveripiiriä laajempaa jakelua varten pitää tietysti muistaa tekijänoikeusnäkökulmat.
Tämän artikkelin on kirjoittanut Linda Talve.