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.

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.

1. 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.
2. 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.
3. 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ää.
4. 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.
5. 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. 
6. 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:

1. Lataa QGIS
2. Luo tili MML:n palveluun ja hae sieltä API-avain
3. Hae maastokartta rajapinnalta QGISiin
4. Lisää oma reitti kartalle (piirtämällä tai esim. gpx-tiedostosta)
5. 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.

Syksyllä 2024 Gispon koulutuskalenteri on täynnä monipuolista koulutusta. Tarjoamme koulutusta sekä QGISin käyttöön että moneen muuhun avoimen lähdekoodin paikkatieto-ohjelmistoon. Alla on listattuna syksyn 2024 avoimet kurssimme. Avoimille kursseille voi ilmoittautua kuka tahansa. Jos haluat koulutuksen vain omalle väellesi, ota yhteyttä ja pyydä tarjousta omasta koulutuksesta.

Tänä syksynä tarjoamme kursseista kahdenlaisia pakettitarjouksia. Aloittelijoille paikkatietoihin ja QGISiin perehtymisen paketin, sekä edistyneemmille paikkatieto-osaajille relaatiotietokanta-asiaa PostgreSQL ja PostGIS -paketin muodossa.

• Pakettitarjous: Paikkatiedot tutuksi 21.8. ja Johdanto QGISin käyttöön 29.–30.8. yhteishintaan 1138 €
• Pakettitarjous: Paikkatiedot tutuksi 2.12. ja Johdanto QGISin käyttöön 12.–13.12. yhteishintaan 1138 €
• Pakettitarjous: Johdanto PostgreSQL:n käyttöön 29.10.–1.11. ja PostgreSQL ja PostGISin perusteet 19.–22.11. yhteishintaan 3228 €

Elokuu

Paikkatiedon mobiilikeruu MerginMapsilla 15.–16.8.
Paikkatiedot tutuksi 21.8.
Johdanto QGISin käyttöön 29.–30.8.

Syyskuu

Tilastot ja analyysit QGISillä 5.–6.9.
QGIS perusteet kunnille 10.–11.9.
Kartat ja taitot QGISillä 19.–20.9.
Johdanto GeoServerin käyttöön 24.–27.9.

Lokakuu

QGIS-lisäosien kehitys 1.–4.10.
Johdanto QGISin käyttöön 3 x 2h 9.–11.10.
Introduction to QGIS 21.–23.10. 13–15 (3 x 2h)
Johdanto PostgreSQL:n käyttöön 29.10.–1.11.
Johdanto QGISin käyttöön 31.10.–1.11.

Marraskuu

Paikkatiedon mobiilikeruu QFieldilla 5.–6.11.
Suunnittelu ja editointi QGISillä 7.–8.11.
PostgreSQL ja PostGISin perusteet 19.–22.11.
QGIS-perusteet kunnille 3 x 2h 27.–29.11.

Joulukuu

Yleiskaavoitus QGISilla 3.–4.12.
Paikkatiedot tutuksi 2.12.
Johdanto QGISin käyttöön 12.–13.12.

Mikä se GeoServer oikein on?

GeoServer on avoimen lähdekoodin palvelinohjelma paikkatietoaineiston jakamiseen. GeoServer julkaisee dataa monista eri paikkatietolähteistä avoimia standardeja käyttäen ja se sallii käyttäjien tarkastella ja muokata dataa. Oiva keino siis saada kaikki ilo irti geospatiaalisesta datasta ja sen eri käyttömuodoista! 

Kenelle GeoServer sopii?

Kenelle tahansa, joka haluaa saada kaiken hyödyn irti paikkatietopohjaisesta datasta ja sen jakamisesta rajapinnalla! GeoServer on kaikessa monipuolisuudessaan kuitenkin todella helppokäyttöinen. GeoServeriä voivat hyödyntää muun muassa kuntatyöntekijät, kehittäjät, konsultit, tutkijat ja kansalaiset! GeoServer taipuu siis monen eri paikkatietoa hyödyntävän sektorin tarpeisiin, oli kyse sitten paikkatiedon luomisesta ja analysoinnista tai paikkatiedon jakamisesta.

Helppokäyttöinen käyttöliittymä

Kevyenä aloituksena esittelemme GeoServerin graafisen käyttöliittymän rakennetta. Tässä näemme kuvan GeoServerin etusivusta, kun emme ole vielä kirjautuneet sisälle tunnuksilla. Tästä jo pystyy hyvin havainnoimaan GeoServerin rakennetta. Käyttöliittymässä ei kuitenkaan vielä näy GeoServerin lukuisia eri toimintoja, mutta kirjautumisen jälkeen nämä tulevat näkyviin. Verrataanpas siis, miltä GeoServer näyttää sisäänkirjautumisen jälkeen!

Tältä GeoServer näyttää ennen sisäänkirjautumista:

Ja tältä sisäänkirjautumisen jälkeen. Kuten voimme huomata, niin vasemmalle sivuvalikkoon on ilmestynyt runsas määrä erilaisia toimintoja! Sivuvalikko näkyy kuvassa punaisella vahvistettuna.

Sitten onkin aika sukeltaa syvemmälle GeoServerin maailmaan! 

Kaikki alkuun Workspacen ja Storen avulla

Ensin on hyvä ottaa haltuun paikallinen kieli. GeoServerin keskeistä sanastoa ovat: workspace, store ja layer. Workspace on nimensä mukaisesti työtila, eli yksi kokonaisuus, jolla voidaan hallinnoida aineistoja. Sanotaan vaikka, että Gispolan kunnalla on työtila kaavasuunnittelijoille, jonka nimi on “kaava” ja liikennesuunnittelijoille on workspace nimeltä “liikenne”. 

Workspacen sisällä voi sitten olla useampi store, eli aineistolähde. Kaavasuunnittelijat tarvitsevat kaavoja ja liikennesuunnittelijat liikennemääriä, joten aineistolähteet ovat näissä workspaceissa erilaiset. Käytännössä store voi olla esimerkiksi PostGIS-tietokanta, GeoPackage-tiedosto tai jopa WFS-rajapinta. Storesta saadaan sitten yksi tai useampi taso. GeoServerissä on myös “Layer Group”, eli ryhmä joka sisältää useampia tasoja. Nämä luodaan GeoServerissä, eli ne eivät tule suoraan aineistolähteestä eli storesta. Gispolan kunnalla Layer Group on käytössä, kun luodaan taustakarttaa, joka koostuu monesta tasosta (tiestö, vesistöt, rakennukset, viheralueet, jne.). Layer Groupin tasoista muodostuva taustakartta jaetaan avoimesti WMS-rajapinnan kautta. 

Luovuus valloilleen tyyleillä

Tyylejä on monia. Itse asiassa tyylejä voidaan luoda ja muokata muutamalla eri tavalla GeoServerissä. Oletus on luoda tyylejä SLD, eli Style Layer Descriptor standardin mukaan. Jotkut kokevat SLD:n muokkaamisen hiukan hankalana (siinä on paljon <tägejä> siellä täällä), ja he usein suosivat lisäosan kautta tehtävää CSS-tyylitystä. CSS, eli Cascading Style Sheets on ihmiselle hiukan helpompi lukea ja ymmärtää. Jos haluat tietää lisää CSS-tyyleistä niin lue Gispon blogipostaus aiheesta.

Mitä dataa GeoServer syö?

Tutustutaan seuraavaksi mitä dataformaatteja ja standardeja GeoServer tukee.

Vektori & rasteri

GeoServer pystyy kätevästi käsittelemään niin vektori- kuin rasterimuotoistakin dataa. Koska kertaus on opintojen äiti, niin vektoridatallahan tarkoitetaan dataa, joka sisältää pisteitä, viivoja tai polygoneja, ja rasteridata puolestaan koostuu pikseleistä ja on rakenteeltaan raskaampaa dataa kuin vektorit. Vektoridatan avulla voidaan kuvata esimerkiksi taloja, teitä tai muita kohteita, joita pystytään kuvaamaan geometrisesti. Rasteridata soveltuu esimerkiksi jatkuvien pintojen kuvailuun, korkeusmalleihin ja kaukokartoitusdataan.

Tässä lisätään store, eli vektori-tai rasteriaineiston lähdettä.

Kuten yllä jo annettiin ymmärtää, niin GeoServer osaa lukea useita erilaisia formaatteja. GeoServerin versio 2.25.0 lukee näitä vektoritiedostomuotoja: 

• GeoPackage
• Shapefile (yksittäisenä tiedostona sekä hakemistona)
• Java Properties

Sekä näitä rasteritiedostoja:

• GeoTIFF
• WorldImage
• ImageMosaic
• GeoPackage

GeoServer osaa myös tuoda dataa seuraavista paikkatietokannoista:

• PostGIS
• H2

Dataa voidaan myös poimia seuraavista rajapinnoista (eli englanniksi cascaded WFS/WMS/WMTS)

• WFS
• WMS
• WMTS

Tämä ei kuitenkaan ole koko totuus, sillä GeoServerille on paljon laajennuksia (extensions), joilla saadaan helposti tukea monelle muullekin formaatille. 

Tuetut OGC standardit

GeoServer tukee monia OGC:n (Open Geospatial Consortium) standardeja:

• Web Map Service (WMS) eli karttakuvien rajapinta
• Web Feature Service (WFS) eli vektorikohteiden rajapinta
• Web Coverage Service (WCS) eli rastereiden raakadatan rajapinta
• Web Processing Service (WPS) eli paikkatietoprosessien rajapinta
• Catalog Services for the Web (CSW) eli metatietoluettelon rajapinta
• Web Map Tile Service (WMTS) eli karttatiilikuvien rajapinta

Tile cachingin eli tiilityksen pariin

Joskus rajapinnan kautta tuleva tieto latautuu hitaasti (eli kartta tarkentuu hitaasti). Silloin yksi tapa nopeuttaa lataamista on luoda “valmiita karttatiiliä”. Ilman mitään tiilitystä rajapinnasta tulevasta tiedosta luodaan jokaisen zoomauksen ja liikahduksen jälkeen uusi kuva. Kun otetaan käyttöön tiilitys, kartta-aineisto pilkotaan paloihin, eli tiiliin, ja rajapinnan kautta haetaan tietoa vain niistä tiilistä, joita karttanäkymässä kulloinkin tarvitaan. Kartta tulee näin näkyviin loppukäyttäjälle nopeammin, sillä joka kerta ei ole tarpeen hakea ja piirtää koko aineistoa. Tämä on iso plussa! Miinuksena taas voidaan mainita, että aineiston päivittyessä pitää käydä luomassa uusia tiiliä, ja jos aineisto on iso ja tiiliä halutaan paljon, niin uudelleentiilitys voi kestää pitkään. GeoServerin käyttöliittymässä on tiilitykselle oma osionsa, jonka nimi on GeoWebCache. Tämä on oma ohjelmistonsa, joka on integroitu GeoServeriin. Siksi myös käyttöliittymä GeoWebCachen puolella on eri näköinen.

Kiinnostuitko?

Jos haluat oppia tekemään itse, tutustu kurssiimme: “Johdanto GeoServerin käyttöön”. Jos taas et halua tehdä itse, niin me Gispolla voimme huolehtia niin  GeoServerin pystyttämisessä kuin ylläpidostakin. Ota rohkeasti yhteyttä!

Psst! Gispolla on muitakin blogipostauksia GeoServeristä, täältä näet ne kaikki: www.gispo.fi/tag/geoserver/ 

Kaikki karttapalvelut, jotka käyttävät tai jakelevat rajapintoja, eivät välttämättä ilmoita, jos rajapinnat eivät toimi. Ongelmatilanteista voi kuulla monesti vasta päivien tai viikkojen viiveellä palvelua käyttäviltä asiakkailta, ja ongelmien syyn selvittämiseksi joutuu kahlaamaan virheraportteja ja lokeja läpi käsityönä. Jos rajapintoja on useita kymmeniä tai jopa satoja, ongelmat kasaantuvat. Ideaalitilanteessa rajapinnan omistaja tietää ongelmista ennen käyttäjiä. Tässä artikkelissa esittelemme kaksi ratkaisua, joilla paikkatietorajapintoja ylläpitävien ihmisten työ helpottuu.

Grafana – lähes kaikkea lähes kaikille

Grafana on ekosysteemi, jonka perusperiaate on pohjimmiltaan yksinkertainen: se tekee tietokantaan kyselyitä, joista se piirtää kaavioita. Käyttäjä voi hyödyntää joko Grafanan valmiita kyselyitä tai kirjoittaa koodimuodossa omiaan. Grafanan antamia tietoja ja visualisointeja voi katsella nettiselaimella. Visualisointitavoista löytyvät mm. erilaiset viiva-, pylväs- ja ympyrädiagrammit. 

Ekosysteemin pääasiallisella Grafana-ohjelmalla visualisoidaan tietoa, mutta lisäksi Grafanaan kuuluu muita osia, kuten tietokantana Prometheus, jossa tietoja säilytetään ja josta Grafana tekee kyselyitä. Prometheus-tietokannassa voidaan määritellä, kuinka pitkältä ajalta dataa säilytetään. Myös muita tietokantoja voidaan käyttää. Grafanasta löytyy lisäksi kaikenlaista back-endiä monenlaiseen tarpeeseen, myös paikkatietopalveluiden ulkopuolelle.

Grafanan ja Prometheuksen pystyttämiseen löytyy näppärät konttiratkaisut, joiden pystyttäminen on helppoa asiaan perehtyneelle. Mutta kuten aina, mitä monimutkaisempaa asiaa halutaan tehdä, sitä enemmän aikaa saa kulumaan. Grafanalla voi kuitenkin seurata lähes mitä vain, ja monipuolisempien työkalujen (kuten Elastic Stack) käyttö ja pystyttäminen on vielä monimutkaisempaa.

Konttien tarkkailua ja säästöä palvelimissa

Miksi sitten Grafanan pitäisi kiinnostaa ketään? Jos käytössä on esimerkiksi useita palvelimia ja halutaan tietää, tarvitaanko jokaista niistä, Grafanan avulla voi katsoa niiden kuormitusta ja onko osa palvelimista ilman mitään käyttöä. Jo muutamankin turhan palvelimen pois ottaminen tai kapasiteetin vähentäminen voi tuottaa suuren säästön.

Ohjelmiston avulla voidaan myös tarkkailla palvelun saatavuutta: jos vaikka palvelimelta ei saada dataa minuuttiin, Grafana voi hälyttää asiasta ylläpitäjän määrittämään sähköpostiin, porttiin tai web-osoitteeseen. Näin voidaan reagoida nopeasti, mikäli jokin palvelin on kumossa tai muuten jumissa. Käyttäjä voi tietenkin määrittää myös muita raja-arvojen ylityksiä ja alituksia, joista hälytys lähtee.

Olemme käyttäneet Grafanaa myös asiakasprojekteissamme. Äskettäin yhdellä asiakkaallamme oli palvelimella kontteja, joista he halusivat ylläpitoon liittyviä arvoja. Tähän tarkoitukseen käytimme Grafana-Prometheus-C-advisor-yhdistelmää. Pystytimme palvelimelle ensin C-advisor-ohjelman, joka tarkkaili kontteja ja julkaisi niiden tiedot web-serverin tapaan haluttuun porttiin. Tätä porttia Prometheus kävi lukemassa tasaisin väliajoin, tässä tapauksessa kerran 15 sekuntiin. Prometheuksen kannasta Grafana luki datan ja piirsi kyselyiden tuloksista käyriä. Lopulta Grafana näytti tulosten perusteella monta kymmentä parametria konttikohtaisesti – kaikkea muistinkulutuksesta prosessointiaikaan. 

Miksi juuri Grafana?

Grafana ei tietenkään ole ainoa ohjelma, jolla tällaisia prosesseja voi tehdä. C-advisorin lukemiseen voi periaatteessa käyttää esimerkiksi Microsoftin PowerBI:tä. C-advisorinkin antama data on lopulta lähinnä nimiä ja numeroita, kuten “C-usage 2,3”, jossa numeroarvo vaihtelee eri aikaväleillä.

PowerBI:hin ja muihin ohjelmistoihin nähden Grafanan etuna on se, että ohjelmisto on avointa lähdekoodia (AGPLv3-lisenssillä) eikä siitä tarvitse maksaa pakollisia kuukausimaksuja. Sen saa pyörimään omaan instanssiin ja asennus käy varsin helposti. Ohjelmistosta löytyy myös valmiiksi hostattu, maksullinen versio, ja siihen voi hankkia käytön tukea.

Merkittävä etu on myös se, että jos tarkkailtavat kontit tai muut kohteet ovat suljetussa verkossa, jonne ei pääse ulkopuolelta, voi Grafanan laittaa samaan instanssiin. Näin asiat pysyvät paremmin turvassa, eikä esimerkiksi palomuuriin tarvitse tehdä muutoksia datan siirtoa varten. 

Vaikka me käytämme Grafanaa paikkatietoon liittyvissä prosesseissa, ohjelmistoon voi kytkeä lähes mitä vain, mikä antaa jonkinlaisia numeroita ulos. Grafanan demosivulla voi tutkia ohjelman toimintoja, kuten sisäänkirjautumisten seuraamista, maksujen määrää ja muita muuttujia eri aikavälillä.

Grafanan demo löytyy netistä https://play.grafana.org/

GeoHealthCheck – yksinkertaista rajapintojen seuraamista

GeoHealthCheck on selainpohjainen ohjelmisto, joka tarkkailee paikkatiedon jakeluun tarkoitettuja rajapintapalveluita. Kuten Grafana, GeoHealthCheck seuraa palveluiden saatavuutta, piirtää niistä diagrammeja ja katsoo kuinka nopeasti ne vastaavat erilaisiin kyselyihin. Ohjelmisto on huomattavan yksinkertainen ottaa käyttöön, ja karkeasti voisi sanoa sen tekevän yhden asian ja näyttävän sen yhdellä tapaa.

Käyttäjä voi määritellä, kuinka tarkasti ohjelmisto tutkii rajapintaa. Paikkatietorajapinnoilla on omat logiikkansa, ja GeoHealthCheckiä voidaan käyttää esimerkiksi tarkistamaan WFS-rajapinnasta GetCapabilities-dokumentin ja sieltä muutaman tason tai kohteen. Rajapintaan tehdyt kyselyt näkyvät sivustolla “Probes”-otsikon alla, ja history-kohta näyttää viimeisimmät virheet. Sivulta saa myös täyden raportin kyselyistä.

Serveri ja vähän viitseliäisyyttä

Siinä missä Grafana edellyttää paljon teknistä tietoa seurattavista palveluista (mikä portti on auki serveriin ym.), tarvitsee GeoHealthCheck vain halutun rajapintapalvelun osoitteen. 

Ohjelmiston käyttöönotto vaatii serverin ja viitseliäisyyttä – ja jälkimmäistäkin aika vähän. Käyttöympäirstönä voi käyttää useita käyttöjärjestelmiä, sillä se on kevyt eikä vaadi paljoa resursseja.

GeoHealthCheck on luontevinta pystyttää jollekin palvelimelle käyttäen konttiasennusta, joka on tehty käyttäjän kannalta melko suoraviivaiseksi ja voi tapahtua nopeastikin. Nohevimmat käyttäjät voivat ajaa ohjelmistoa kontissa omalta koneeltaan. Tämän jälkeen seurattavat rajapinnat voi joko näppäillä käsin, tai jos rajapintoja on paljon, tuoda JSON:ina.

Ohjelmistossa on myös mahdollisuus luoda eri käyttäjiä ja antaa näille oikeuksia palveluiden tilan seuraamiseksi. Näin palveluiden seurantaan voi käyttää yhtä GeoHealthCheck-instanssia, jota seuraa kokonainen tiimi. (Toinen vaihtoehto olisi pystyttää jokaiselle käyttäjälle oma ohjelmisto.) Käyttäjähallinta mahdollistaa palveluiden näkymisen rajaamisen niin, että osa tiedoista voidaan näyttää julkisesti, osa vain kirjautuneille, tai jopa eri käyttäjille eri palveluita.

Sivuhuomiona mainittakoon, että rekisteröinnin salliminen vaatii hieman säätöä, sillä silloin käytössä pitää olla sähköpostia lähettävä kone, jotta rekisteröinnin vahvistussähköpostit voidaan lähettää. Toisaalta tällaisen koneen käyttäminen on järkevää muutenkin, sillä silloin GeoHealthCheck voi lähettää hälytysviestit suoraan sähköpostiin. Muussa tapauksessa hälytykset voidaan asettaa tulemaan esimerkiksi halutulle nettisivulle.

Kuten Grafana, myös GeoHealthCheck on avointa lähdekoodia ja siihen on mahdollista tehdä omia lisäosia. Ohjelmistoa kehitetään jatkuvasti, ja vaikka se toimii jo nyt mainiosti, se ei ole vielä aivan täydellinen. Esimerkiksi jos käyttäjä haluaa vaihtaa salasanan tilanteessa, jossa ohjelmalla ei ole sähköpostia käyttävää konetta käytössä, joutuu kikkailemaan tarpeettoman vaikeasti JSON-operaatioiden kanssa. Tämän tai vastaavien asioiden korjaaminen ja pienkehittäminen ovat asioita, joita esimerkiksi me Gispolla teemme.

Helpot hyödyt

Ohjelmiston hyödyt ovat selkeät: rajapintojen statuksen näkee helposti ja jos ongelmia ilmenee, niistä saa hälytyksen haluamallaan tavalla. Raportit saa ulos CSV:nä, JSON:ina tai PNG-kuvana. Olemassaolevien rajapintojen testaaminen ja niiden saatavuuden tarkkailu on helppoa. Ohjelmisto mahdollistaa myös live-testaamisen, mikä auttaa kun tekee säätöjä rajapintaan, päivittää GeoServeriä tai on julkaisemassa uutta rajapintaa. 

Hälytysten ansiosta ongelmiin voi reagoida nopeammin, ja ongelmien selvittämisessä manuaalisen työn määrä vähenee (esimerkiksiGetCapabilities-raportista ei tarvitse itse kaivaa virheitä, vaan ne näkyvät nätisti eroteltuina selainkäyttöliittymässä). Mitä enemmän rajapintoja on jaossa, sitä enemmän hyötyä ohjelmasta tietenkin on. 

GeoHealthCheckin etuna on sen yksinkertaisuus ja havainnollisuus, sekä helposti ymmärrettävä käyttöliittymä. Jos halutaan seurata niitä asioita, joita GeoHealthCheck tarjoaa, ei asiasta kannata tehdä suotta monimutkaista ja virittää Grafanaa tekemään samaa. GeoHealthCheck on suunniteltu nimenomaan paikkatietokäyttöön, mutta sillä voi tarkkailla myös ihan tavallisiakin nettisivuja.

GeoHealthCheckin demo löytyy täältä: https://demo.geohealthcheck.org/

Ruotsin paikkatietomaailman päätapahtuma on karttapäivät, Kartdagar, jonka järjestää Ruotsin kartografinen seura (Kartografiska Sällskapet). Tänä vuonna Kartdagar järjestettiin Göteborgissa 16.-18.4.2024. Osallistujia oli runsaat 650 henkilöä ja näytteilleasettajia 27. Suomesta olivat edustettuina Nordic Geo Center Oy, Terrasolid Oy sekä tietysti Gispo Oy. Kartdagar 2024 ohjelma koostui monipuolisista puheenvuoroista ja työpajoista paikkatietoalalta. Tämän vuoden teema oli “Innovationskraften i geodata” eli paikkatiedon innovaatiovoima. Ohjelmassa korostuivat siten innovaatiot, tekoäly ja uudet teknologiat.

Ohjelma

Kartdagarnan aikataulu on rakennettu lounaalta-lounaalle -konseptilla. Tässä konseptissa jäi aikaa matkustaa tapahtumapaikalle tiistaina aamupäivän aikana, ja kun tilaisuus loppui torstain lounaaseen, saattoi iltapäivän käyttää tapaamisiin, nähtävyyksien ihasteluun tai välittömään kotimatkaan. Tämä olisi oikein toivottava konsepti myös suomalaisiin tapahtumiin välimatkojen ollessa pitkiä.

Ensimmäisen keynote-puheenvuoron piti apulaisprofessori Pontus Wärnestål Halmstadin yliopistosta. Wärnestål kertoi, miten tekoälyavusteisia palveluja pitäisi suunnitella. Luennon keskiössä oli tekoäly, joka muutenkin oli vahvasti esillä tapahtumassa. Myös moni muu puheenvuoro liittyi tekoälyyn tavalla tai toisella. 

Suurin osa ohjelmasta oli perinteisiä puheenvuoroja, mutta mukana oli tänä vuonna myös työpajoja sekä yksi paneelikeskustelu. Puheenvuoroja oli monipuolisesti sekä julkiselta että yksityiseltä sektorilta. Valtaosa ohjelmasta oli ruotsiksi, mutta väliin mahtui myös muutamia englanninkielisiä esityksiä. 

Esityksistä

Gispon Pekka Sarkola piti työpajan aiheesta “Building an Enterprise GIS workflow with QGIS and PostGIS”.  Suositussa työpajassa oli noin 30 osallistujaa. Jälkeenpäin monet halusivat vielä jutella avoimen lähdekoodin ratkaisuista ja gispolaiset saivat vastailla lukuisiin kysymyksiin. 

Näyttelyosasto piti Gispon tiimin kiireisenä, mutta myös joidenkin esitysten kuuntelulle löytyi aikaa. Puheenvuorot kertoivat Ruotsin paikkatietoalan kuulumisista ja kertoivat missä alalla mennään. Esimerkiksi Marcus Justesen (Värmdön kunta) puhui aiheesta Webb-GIS 2.0. Justesenin esityksen viestinä oli, että laaja-alainen yhteistyö sekä kunnan sisällä että eri sidosryhmien kanssa on keskeistä rakennettaessa web-pohjaista paikkatietoinfastruktuuria. Useissa kunnissa on käytössä yhteistyössä kehitetty web-karttakäyttöliittymä, HAJK (https://hajkmap.se/). Ruotsissa QGISiä käytetään myös julkisella puolella. Clemens Zuba (Boråsin kaupunki) puhui otsikolla “QGIS i en organisation – Tips som underlättar för användare och administratörer”. Boråsin kaupungissa QGIS on käytössä PostGISiin tallennettujen paikkatietoaineistojen visualisointiin ja hallinnointiin. Käyttövinkkinä Zuba kertoi, miten Boråsissa on räätälöity QGIS käyttöliittymiä erilaisten lisäosien avulla (mm. CustomToolBar ja Menu From Project).

Tapahtuman lopussa toinen keynote-puheenvuoro oli otettu tapahtuman teeman ulkopuolelta ja käsitteli hyvinvointia. Luennoitsija ja pedagogi Ann-Helen Häggrudin otsikkona oli “Hyvinvointia aivojen näkökulmasta”. Puheenvuoron tarkoituksena oli antaa osallistujille hyviä vinkkejä siitä, miten pitää huolta omasta hyvinvoinnistaan. Häggrud kävi läpi erilaiset kemialliset reaktiot, joita aivoissa tapahtuu ja sitä kautta vaikuttavat hyvinvointiin. Tapahtuman aihepiirien ulkopuolelta tullut keynote oli yllättävä, mutta yleisö tuntui pitävän Häggrudin esitystä sekä hauskana että hyödyllisenä.

Tilaisuudessa oli paljon aikaa verkostoitumiselle esitysten välissä (fika  on elintärkeä ruotsalainen perinne) sekä iltatilaisuuksissa. Ensimmäisenä iltana oli “utställarmingel”, jonka tavoitteena oli vain minglata (≃kierrellä, tavata ja jutustella, tarjolla voi olla pientä purtavaa ja juotavaa) näyttelyssä, varsinaista jäänsärjentää (Icebreaker) ruotsalaiset eivät näemmä tarvitse.  Toisen päivän päätteeksi oli Kartdagsparty, jota saattoi kutsua myös dinneriksi. Alun kuplien jälkeen (minglailua, ilman syömistä) oli tarjolla 3 ruokalajin illallinen. Jälkiruuan jälkeen DJ nosti tehoja ja ruotsalaiset päätyivät tanssilattialle (jokunen suomalainenkin näkyi, vaikka muuta väittäisivät). Suomalaisia euroviisubiisejä valikoimaan ei kuulunut, ja ABBA laulujen sikermä oli aika pitkä.

Osallistujat

Suurin osa osallistujista oli ruotsalaisia paikkatiedon ammattilaisia. Gispon ständille tuli juttelemaan paljon kuntatyöntekijöitä eri puolilta Ruotsia. Myös valtion laitoksista (kuten Lantmäteriet ja Trafikverketillä) oli runsaasti osallistujia Kartdagareilla. Yksityiseltä puolelta etenkin konsulttiyritykset sekä maanmittausalan yritykset olivat edustettuina. Tapahtuma oli opiskelijoille ilmainen ja lisäksi opiskelijoiden oli mahdollista hakea avustusta matkakustannuksiin, joten monet opiskelijat olivat löytäneet tiensä Göteborgiin. 

Lopuksi

Tapahtuman viimeisessä sessiossa julistettiin karttanäyttelyn voittajat. Gispolaisten sydämiä lämmitti, että monet kartantekijät olivat hyödyntäneet avoimen lähdekoodin ohjelmistoja (kuten QGIS, Inkscape ja GIMP) karttoja tehdessään. Lopuksi julkaistiin vielä ensi vuoden tapahtumapaikkaa. Seuraavat karttapäivät järjestetään 8.-10.4.2025 Skellefteåssa, Sara Kulturhusin tiloissa. Nähdään siis ensi vuonna Västerbottenissa! 

Heinäkuun alussa Tartossa Virossa järjestetään FOSS4G Europe -konferenssi. Kyseessä on eurooppalainen versio OSGeon (Open Source Geospatial Foundation) vuosittain järjestämästä avoimen lähdekoodin paikkatieto-ohjelmistoihin keskittyvästä konferenssista. Gispo osallistuu naapurimaassa järjestettävään tapahtumaan isolla tiimillä. Nähdäänkö siellä?

Konferenssin koko aikataulu löytyy täältä: https://2024.europe.foss4g.org/schedule/

Gispolaisten esitykset aikatauluineen:

• Building Enterprise GIS with FOSS4G, 3.7. 12:00–12:30
• Planning for rainy days: optimizing school calendars with precipitation data and QGIS, 3.7. 16:00–16:30
• Learning path with FOSS4G, 3.7. 16:30–17:00
• Complexity of Land use planning – simplicity from FOSS4G, 3.7. 16:30–17:00
• Exploring the use of 3D tiles in QGIS – case Helsinki, 4.7. 11:30–12:00
• Managing airport data with Open Source Software, 5.7. 12:00–12:30
• How to set up a QGIS plugin project and development environment in minutes, 5.7. 14:30–15:00

Suomessa on yleisten maanteiden varrella satoja automaattisia liikenteenvalvontapisteitä. Ne tarvitsevat vuosittaista huolto- ja tarkastustoimenpiteitä sekä tarpeen mukaan vikakorjausta. Tästä työstä huolehtii Fintraffic Tie, joka vastaa myös muusta tieliikenteen hallinnasta Suomen maanteillä. Heidän tehtävänään on osaltaan huolehtia turvallisesta ja sujuvasta liikenteestä tieverkolla. Yksi osa tätä kokonaisuutta ovat automaattiset valvontapisteet. 

Fintraffic Tie Oy tarvitsee tienvarsilaitteiden hallintaa varten lähtötietoa erilaisista tietolähteistä. Nykyisin tietoa hankitaan eri rajapintojen ja tiedostovaihdon kautta ja tietoja yhdistellään käyttökelpoisempaan muotoon. Toimivaa tapaa kerätä tietoa kentältä ei ole ollut. Mergin Maps -mobiilisovellukseen oli fintrafficilla tutustuttu jonkin verran, ja se vaikutti lupaavalta sovellukselta tähän tarkoitukseen. Mobiilisovellus on täysin yhteensopiva Fintrafficilla jo aiemmin käytetyn avoimen lähdekoodin paikkatieto-ohjelma QGISin kanssa.

Gispon tehtäväksi tuli kehittää konseptitodistus (Proof-of-concept) Fintraffic Tielle eri tavoista ja menetelmistä kerätä, analysoida ja hallita maanteiden tienvarsilaitteisiin liittyvää paikkatietoa ja luoda Mergin Maps -mobiilisovellukselle projektitiedosto, jolla tätä paikkatietoa voitaisiin kerätä ketterästi maastosta ja edelleen jatkokehittää tuleviin tarpeisiin. 

Lopputuloksena Mergin Maps -työtila

Projektissa hyödynnettiin ketteriä kehitysmenetelmiä. Viikkopalaverit olivat tärkeässä roolissa, kun kävimme yhdessä läpi tilannetta ja keskustelimme mihin suuntaan projektissa edetään. Projektin lopputuotteena syntyi Mergin Maps -työtila, jota edelleen kehitetään kenttätyön tueksi ja jota voidaan käyttää myös testiympäristönä laajemman käyttöönoton testaamisessa. Projektin aikana tuotettiin myös tärkeitä käyttökokemuksia kokeiltavista työkaluista ja toiminnallisuuksista. Mergin Maps -mobiilisovelluksen työtilojen avulla on tarkoitus kerätä tietoa kentältä automaattisen liikenteenvalvonnan valvontapisteistä, kirjata käytettävyystietoa, syöttää kunnossapitotietoja, tarkastella ja vertailla tietoa sekä liittää valokuvia kohteille.

“Gispon paikkatietoon liittyvä syväosaaminen ja vankka kokemus Mergin Mapsista ja QGISista loi hedelmällisen pohjan projektin läpiviemiselle. Varsinaisen lopputuotteen lisäksi Fintraffic sai paljon vinkkejä ja konsultaatiota miten tämäntyyppinen tiedonkeruu kannattaa toteuttaa.”, Fintrafficin palvelupäällikkö Jussi Nykänen kertoo.

Projektin aikana kerättiin arvokkaita käyttäjäkokemuksia siitä, miten mobiilitiedonkeruun prosesseilla voidaan tuottaa ja validoida tietoa. Ajantasaisen ja validoidun tiedon myötä Fintraffic Tie pystyy edelleen kehittämään dataorientuneempaa päätöksentekoa sekä tiedolla johtamista. Tässä projektissa keskityttiin yhteen mobiilitiedonkeruun käyttötapaukseen, ja lisäksi saatiin paljon uusia ideoita siitä, miten mobiilitiedonkeruuta voidaan soveltaa myös muihin käyttötapauksiin esimerkiksi hankkeiden suunnitteluun ja miten ne voidaan integroida nykyisiin järjestelmiin. Mobiilisovelluksen avulla Fintraffic Tie pystyy tehostamaan tiedon tuotannon prosesseja ja keräämään nopeasti maastosta tärkeää tietoa kunnossapito- ja huoltotoimenpiteistä niin, että tieto on välittömästi käytettävissä myös työpöytäsovelluksissa.

________________________________________

Kiinnostuitko paikkatiedon mobiilikeruusta Mergin Maps -sovelluksella? Tutustu koulutukseemme: Paikkatiedon mobiilikeruu Mergin Mapsilla

Paikkatietoa hyödynnetään monilla aloilla ja yksi kiinnostava ala, jolla näemme paikkatiedon hyödyntämisen lisääntyneen on energia-ala. Siellä paikkatietoa käytetään esimerkiksi hankkeiden suunnittelussa ja hankeviestinnässä. “Käytämme paikkatietoa hankkeidemme koko elinkaaren ajan”, sanoo Myrsky Energian paikkatietoasiantuntija ja hankekehittäjä Saku Saarimaa. 

Myrsky on suomalainen tuulivoimaan ja aurinkovoimaan keskittyvä energiayhtiö. Yhtiön kasvu on ollut nopeaa ja sen myötä myös paikkatietojen hallinnan ja siihen liittyvän osaamisen tarve on kasvanut. Gispon ja Myrskyn yhteistyö alkoi pienellä työpajalla, joka järjestettiin Location Innovation Hub:n puitteessa. Työpajassa tunnistettiin, mitä arvoa paikkatiedot tuovat Myrskylle toiminnan eri osa-alueilla. Tämän jälkeen myrskyläisille järjestettiin Johdanto paikkatietoon ja QGISin käyttöön -koulutus. Koulutuksen myötä osaamista kertyi ja paikkatiedon perusteiden lisäksi osallistujille avautui QGISin monipuolisuus työkaluna.

Saarimaa kertoo, että he käyttävät QGISiä ja paikkatietoja monessa tehtävässä. Esimerkiksi tuulivoimahankkeen alussa sitä käytetään suunnitteluun. Hyvän sijainnin löytäminen hankkeelle edellyttää lukuisten aineistojen ja työkalujen hyödyntämistä. QGISin graafinen mallintaja tuo tehokkuutta analyyseihin, sillä sen avulla on mahdollista luoda malleja, jotka ajavat aineistoille monta työkalua ja analyysiä kerralla. Käytettävät aineistot ovat pitkälti avoimia ja Suomen lukuisat avoimet paikkatietoaineistot saavat kiitosta Saarimaalta (sekä meiltä Gispolta!).

Uusien alueiden kartoittamisen ja olemassa olevien hankkeiden suunnittelun lisäksi QGISiä käytetään Myrskyllä infrastruktuurin suunnittelussa. QGISissä suunnitellaan esimerkiksi tielinjauksia sekä hankkeen sisäistä ja ulkoista sähkönsiirtoa. 

QGISin tehokäyttäjiä Myrskyllä on viidestä kymmeneen henkilöä, satunnaisia käyttäjiä löytyy myrksyläisistä useita. Analyysityökaluja käytetään paljon, esimerkiksi erilaisten vyöhykkeiden ja buffereiden luominen on keskeisitä työkaluja. Paikkatiedolla on myös tärkeä tukirooli hankeviestinnässä. Karttoja tarvitaan lukuisiin käyttötarkoituksiin. Saarimaan mukaan kartoilla on tärkeä rooli hankkeisiin liittyvässä sisäisessä viestinnässä. Kun pitää keskustella vaikkapa uuden hankkeen sijainnista tai muutoksista suunnitelmissa, on se helpompi tehdä karttojen avulla. Hankeviestinnässä kartat konkretisoivat hankealueita. Ulkopuolisille tahoille esitellään hankkeisiin liittyviä suunnitelmia, ja niiden taustalla olevia selvityksiä ja mallinnuksia. Tällöin karttoja katsovat esimerkiksi kuntatyöntekijä, konsultti ja maanomistaja. 

Paikkatietoa kertyy yhden hankkeen aikana paljon, ja sen toimiva hallinta on tärkeää. Monesti on tarpeen siirtää paikkatietoaineistoa joko työntekijältä toiselle tai ulkopuoliselle konsultille. Silloin Saarimaa on suosinut GeoPackage-tiedostomuodon käyttöä, ja sitä käytetäänkin nyt paljon Myrskyllä. GeoPackagen vahvuuksina Saarimaa nostaa esiin projektin, tyylien ja aineistojen tallentamisen samaan tiedostoon, sekä käytettävyyden Selain-paneelin kautta QGISissä. 

Myrsky on siis löytänyt tehokkaan työkalun paikkatiedon hallintaan ja analysointiin: QGIS. Paikkatiedon hyödyntämisellä on suuri merkitys tuuli- ja aurinkovoimahankkeiden suunnittelussa sekä niihin liittyvässä hankeviestinnässä. Myrskylle QGIS ei ole vain työkalu, vaan keskeinen osa päivittäistä toimintaa, joka tukee yrityksen kasvua ja kehitystä energia-alalla.