Varoitus! Tämä on hyvin tekninen kirjoitus josta saattaa olla iloa ja apua lähinnä niille jotka käyttävät tai haluavat käyttää QGIS:ä vaellusreittien suunnitteluun. Jälkimmäisille siis ehkä apua, ensimmäisille varmaan enemmänkin huvitusta käsittämättömästä tumpeloinnistani.

Olen käyttänyt QGIS-nimistä ilmaista GIS-sovellusta (geographic information system) matkareittien suunnitteluun sekä reittikarttojen tulostamiseen. Se on osoittautunut erinomaisen käyttökelpoiseksi työkaluksi – mutta siinä miten olen sen konfiguroinut itselleni on ilmennyt muutamia pieniä ongelmia. Aiemmin olin niistä selvinnyt sitkeydellä (eli sulkemalla silmät ongelmilta) mutta tässä talvitauolla mitta täyttyi, tartuin härkää sarvista, rupesin taittamaan peistä ja niin edelleen ja niin edelleen.

Oireet

QGIS-projektissani oli aika monta ongelmaa joihin olin törmännyt matkan varrella:

1. LIPAS-kannan tietojen lataaminen toimi kehnohkosti, joskus se kesti loputtomiin ja päädyin painelemaan F5:sta (refresh) turhan tiheästi.
2. Kartassa siirtyminen ja erityisesti zoomauksen muuttaminen (hiiren rullalla sisään-ulos) selvästi kesti turhan kauan.
3. Reittisuunnitelmissani oli myös nippu muita pienempiä kämmejä jotka oli myös syytä korjata.

QGIS:n suhteen olen edelleen aika ummikko, ja käytän sitä lähinnä tavalla “tälleen sen vaan saan tekemään mitä haluan” ymmärtämättä sen syvällisemmin mitä oikeastaan olen tekemässä.

Tutkimus

Vaikka kirjoitan tätä lineaarisesti, älä kuvittele että asiat oikeasti menivät “ensin A sitten B” tapaan suoraviivaisesti. Oikeasti tutkimukset polveilivat ja poukkoilivat 😃 Mutta yksinkertaisuuden vuoksi en listaa tähän umpikujia.

LIPAS-kannan hitaus

Olin konfiguroinut LIPAS-palvelimen WFS-yhteydeksi, ja aina välillä kun siirryin kartalla, näin QGIS:n lokeissa erilaisia virheitä LIPAS:n palvelimelta. Jotain boundingBoxiin liittyen. Lokit eivät kuitenkaan kertoneet riittävästi ja rupesin etsimään keinoa saada parempi näkyvyys verkkoliikenteeseen. Tähän avuksi tuli verkkologgeri (löytyy View > Panels > Debugging/Development tools), jolla sain helposti seurattua mitä pyyntöjä QGIS lähettää ja millaisia vastauksia se niihin saa.

Sieltä paljastui, että QGIS ei syystä tai toisesta pitänyt mahdollisena laittaa vastauksia välimuistiin. Täh? Kokeilin lipaksen WMS-kerroksia (eli sama data, mutta kuvina jotka kerrostettiin kartan päälle) ja niissä välimuisti näytti toimivan. Jäin rapsuttelemaan päätäni. Halusin kuitenkin pystyä filtteröimään ja muuttamaan kohdepisteiden esitysmuotoa, joten WMS ei voinut olla kuitenkaan lopullinen ratkaisu.

Huomasin, että tiedot olisi mahdollista saada ladattua (“ladattat aineistot”). Kokeilin muutamaa esimerkkipyyntöä isommalla kohdemäärällä—halusin kuitenkin kaikki—mutta sain vain 504 Gateway Timeout virheitä).

Tässä vaiheessa tajusin, että olin käyttänyt WFS-palvelua oikeastaan ihan väärin. Tuntuu ehkä luontevalta tehdä online-kyselyjä palvelulle, saahan sillä tavalla varmasti aina ajantasaiset tulokset. Mutta. Lipaksen GeoServer on kuitenkin rajallinen resurssi ja sitä varmaan kuormittavat muutkin tahot. Ei ihme, että se saattaa tökkiä. Eivätkä esim. retkipaikan kaltaiset palvelut suinkaan käytä sitä jatkuvasti — ne hakevat kaiken datan silloin tällöin ja lopun aikaa käyttävät paikallisia kopioita niistä. Minunkin pitäisi toimia samoin, ja ladata LIPAS-kannan paikkatietoaineisto paikalliselle levylle.

Onneksi aineistosta on helposti saatavilla otokset jotka päivitetään noin puolen vuoden välein. Päivitystahti on minulle ihan riittävä. Latasin tuoreen datasetin, purin sen projektikansioon ja lisäsin datat paikallisesti käyttöön. WFS-palvelussa oli eri tietuetyypit erotettu omiksi kerroksikseen, tässä ne olivat kaikki samassa joukossa joten piti vähän lisäillä ("tyyppikood" IN (301, 302, 304, 3230)) filttereitä¹ poimiakseni vain itseäni kiinnostavat pisteet, reitit ja alueet, sekä kopioida tyylitiedot vanhoista uusiin kerroksiin (kerrokselle oikea hiiren namikka ja Style > Copy styles > All ja vastaavasti Styles > Paste styles > All).

Lopputulos: Ei enää verkkovirheitä. Koko LIPAS-aineisto tuli suit sait viiveettä näkyviin. Onnistuminen!

Karttaongelmat

Huomasin saman välimuistin käyttämättömyyden vaivaavan myös WMS-karttapohjia. Ihmettelin hetken verkkoliikennettä, mutta syy oli helpompi tällä kertaa paljastaa. Käytin kapsia, eikä se näyttänyt käyttävän HTTP-vastauksessaan Cache-Control tai Expires headereita asettamaan parametrit välimuistin käytölle. QGIS näyttää olettavan että ellei vastaus erikseen kerro sille, että välimuistia voi käyttää, niin se olettaa ettei voi. Noh.

Kapsi oikeasti kuitenkin vain käyttää Maanmittauslaitoksen avointa kartta-aineistoa, joten lähdin katsomaan MML:n sivuja. Muistelen, että olisin niitä alunperinkin katsonut mutta silloin olin vielä ihan sormi suussa ja terminologia meni yli hilseen. Siksi taisin päätyä kapsiin jossa oli tarjolla helpommat ohjeet.

MML:llä on sivustossaan osa “Asiantuntevalle käyttäjälle” josta oleellinen tieto löytyy. Karttapohjia varten prosessi oli loppujenlopuksi melko yksinkertainen, joskin sen hahmottamiseen meni tovi:

1. Rekisteröidy OmaTili-palvelussa ja luo API-avain.
2. Lisää QGIS:ssä uusi WMTS-yhteys MML:n osoitteeseen (https://avoin-karttakuva.maanmittauslaitos.fi/avoin/wmts/1.0.0/WMTSCapabilities.xml), ja aseta API-avain Basic-tunnistautumiseen käyttäjänimeksi (salasana jää tyhjäksi).

Siinä se! Ei se sittenkään ollut niin vaikeaa. (Yllä oleva pätee yksityishenkilöille—kaupalliseen käyttöön on eri lisenssi!)

Käytin WMTS:ää WMS:n sijaan koska verkossa joku oli sanonut sen olevan parempi (“uudempi ja parannettu”). En tiedä onko totta, mutta toiminut silti on. Sekä tärkein: karttakuvat tarttuivat nyt myös välimuistiin. Seurasin verkkolokista miten pystyin zoomailemaan sisään ja ulos ilman ylimääräistä verkkoliikennettä. Nyt mennään niin kovaa että tukka on putkella!

Lisäbonuksena vanhaan konfiguraatioon oli WMTS-aineistossa mukana oleva ilmakuvat (“ortokuva”). Nyt ei tarvitsisi vaihdella google mapsin karttakuvaan katsoessani maaston detaljeja.

Lopputulos: Karttakuvat päätyvät välimuistiin ja kartalla siirtyminen oli nyt mukavan virtaviivaista. Onnistuminen!

Välinäytös: Reitin pilkkominen päivämatkoihin

Olen yrittänyt monia eri tapoja suunniteltujen reittien pituuksien määrittelyyn. Olettaisin, että olen missannut sen “oikean” tavan hoitaa homma koska olen keksinyt vain varsin työläitä virityksiä. Osan olen säilyttänyt käytössä ja osan hylännyt ajan kanssa. Näistä helpoimmat ja suoraviivaisimmat ovat $length arvon käyttö reitin “labelina”, sekä reitin symbolimerkistöön “marker line”:n määrittely jossa merkin intervalliksi on asetettu 1000 metriä.

Vaikka nämä kaksi toimivat ihan hyvin, on niissä pari isoa puutetta suunnittelun suhteen.

Teen yleensä reitin siten, että laitan reitin ensin hyvin karkeasti, ja rupean sitten säätämään sitä tarkemmin. Tällöin voi käydä niin, että pätkä on esimerkiksi 70 kilometriä. Selvästi liian pitkä päivämatkaksi, joten rupean tyypillisesti etsimään jostain 20-25 kilometrin tienoilta sopivaa leiripaikkaa. Ongelma on vain se, että miten löydän sen “noin 20 kilometriä” kohdan? Aiemmin tein sen jollain näistä tavoista:

1. Katkaistaan reitti kahteen osaan jostain silmämääräisesti sopivasta kohdasta (Edit Geometry > Split Features), jolloin kumpikin pätkä saa oman $length lasketun metrimäärän. Saattaa olla että ensimmäinen pätkä on nyt 18 kilometriä, jolloin joko teen undon ja leikkaan uudesta kohdasta, tai rupean siirtelemään kyseisen pätkän loppua vähän eteenpäin.
2. Lasketaan (sormilla) kilometrimarkkerit pätkän alusta ja leikataan kun tullaan riittävän pitkälle. Ongelmana on, että QGIS laskee merkkien välin siitä mistä viivaa juuri nyt ruvettiin piirtämään eikä koko reittiviivan alusta! Eli kun siirryn kartalla, myös kilometrimerkit hyppivät paikasta toiseen. Tämä ei yleensä hirveätä virhettä tee, koska pystyn laittamaan häiritsevän karttapohjan piiloon ja zoomata riittävästi ulos jotta näen riittävän pituuden.

Nykyään teen homman vähän eri tavalla. Käytän QChainage-plugaria joka tekee … ööö, jotain GIS-magiaa ja laskee valittujen reittien perusteella uuden kerroksen jossa kyseiset reitit on pilkottu halutun pituisiksi pätkiksi, siten että mukana on myös sopiva juoksumitta (cngmeters 1000 metrin välein siis). Tähän tarvitaan enää päälle vain symbolikerros jossa formatoidaan cngmeters/1000 tekstiksi. Ja vot! Nyt minulla on reitin varrella siistit ja kiinteästi asetetut kilometrilukemat!

Tämä olisi muuten ihan toimiva prosessi, mutta tuon “chainage” kerroksen tekeminen on manuaalinen prosessi. Pöh. Tällä hetkellä hyväksyn tuon pienen vaivan, eli 1) aja QChainage reitille 2) kopioi tyylit vanhasta kerroksesta 3) poista vanha kerros, mutta voi olla että jossain vaiheessa tutkin tarkemmin plugarin koodia ja selvitän olisiko mahdollista saada se päivittämään “chainage” kerros automaattisesti.

Mutta tästä välinäytöksestä päästään siihen, että mitä piti tehdä ennenkuin sain QChainagen toimimaan, koska …

Päivitys 25.2.2002: QGIS:n dokumentaatio ei todellakaan ole kovinkaan helppolukuista kun haluaa tehdä vähän jotain ohjelmallista! Mietiskelin pystyisinkö Geometry Generator toiminnallisuudella tekemään jotain noiden kilometrimarkkereiden suhteen. Kokeilin eri juttuja, ja sitten ihan sattumalta törmäsin tähän vastaukseen GIS StackExchangessa jossa kuvattiin to-del-la yksinkertainen ratkaisu! Minun tarvitsi tehdä geometry generator-symbolikerros jossa generaattori oli näin yksinkertainen:

collect_geometries(
  array_foreach(generate_series(1, length($geometry) // 1000),
    line_interpolate_point($geometry, @element * 1000)))

Siihen vain sitten lisäksi Font Marker ja sen Character kenttään to_string(@geometry_part_num) ja nyt kyllä rulettaa! Ei tarvitse erikseen ajaa chainage päivityksiä vaan merkit ovat sekä stabiilit että ajan tasalla. Pieniä rajoituksia tässä on, sillä km-teksti ei tule label-merkintänä vaan osana symbolikerrosta jossa tekstin asemointi ei ole yhtä joustava. Olin aiemmin laittanut viidellä jaolliset kilometrit boldattuna mutta tällä metodilla se olisi ollut sen verran kömpelömpää että jätin tekemättä. Mutta ei se haittaa!

Sekalaiset källit

Ihmettelin aluksi urakalla miksi QChainage jakoi reitit asteiden mukaan eikä etäisyyden mukaan. Sain koko ajan vain uuden kerroksen jossa pätkien mitta laskettiin cngdegrees yksiköissä kätevästi joidenkin asteen kymmenyksien välein. Ei metreissä, jaardeissa tai edes kubitteina. Tässä vaiheessa <hissimusiikkia ja turhautumista noin kaksi pitkää ajanjaksoa> … eli kyse oli karttaprojektiosta. Minulla oli käytössä projektio joka (älkää kysykö minulta miten tai miksi) käytti etäisyysmittoina asteita, ei metrejä.

Ja jos käytin Set Layer CRS niin reitit päätyivät jonnekin päiväntasaajan tienoille, siispä … <lisää hissimusiikkia ja googlaamista> … ratkaisu oli exportoida kerros uudessa projektiossa tiedostoksi, ja tuoda tiedosto uutena kerroksena. Miksi tämä toimii ja muuten ei niin älä minulta kysy. Kysy GIS-asiantuntijalta. Jokin hyvä syy sille varmaan on.

Koska MML:n WMTS-kartat käyttivät EPSG:3857 projektiota, niin valitsin QGIS:n tarjonnasta EPSG:3067 - ETRS89 / TM35FIN(E,N) projektion koska siinä puhuttiin metreistä eikä asteista². Ja se sitten toimi lopulta, QChainage antoi mitaksi cngmeters kiltisti kilometrin välein.

Paitsi että nyt osassa reiteistä kilometrit menivät kiltisti 0, 1, 2 ja niin edelleen ja joissain 24, 23, … eli väärin päin. Pieni kosmeettinen virhe, mutta kuitenkin. QGIS:ssä reiteillä on suunta, eli kullakin viivajoukolla on alkupiste ja loppupiste. QChainage ehkä vähän yllättäen ei osaa tulkita datasta aikeita ja laskee etäisyydet siis alusta loppuun. Minä se vain olen väärässä, kun kuvittelen ettenkö voisi vaikka kävellä reittejä takaperin. Noh, Edit Geometry > Reverse Line toimii, varsinkin kun lisäsin symbolikerroksen joka lisää reittiviivoihin nuolet. Niiden avulla löysin helposti kaikki väärään suuntaan osoittavat pätkät ja vaihdettua suunnat.

Minulla on useita kerroksia ja symboleita joita käytän vain ongelmien selvittelyssä, ja pidän ne normaalisti pois päältä. Nuolikerros on yksi niistä, samoin “juoksevat” kilometrimerkit.

Debug-kerroksessa on myös LIPAS-datajoukon reitit ja kiintopisteet suodattamattomana siten että niiden tyyppikood on lisätty tekstiin. Sillä tavalla voin tarvittaessa tarkistaa oliko lähistöllä jotain muuta kiinnostavaa—jotain mitä en nyt yleensä tarvitse reittiä suunnitellessa, mutta joka saattaisi ihan muuten olla kiva tietää.

Parannettavaa

Reitit olen tallentanut GeoPackage-muodossa (GPKG) joka on käytännössä sisäisesti SQLite-kanta. En ole ihan varma, mutta ilmeisesti (ehkä?) jos pitäisin reittitiedot PostGIS-kannassa, voisin siellä tehdä taulukkonäkymän johon saisin automaattisesti reiteistä kilometrin välein olevia pisteitä. (Käyttäen joko tavallista tai materialisoitua näkymää eli VIEW tai MATERIALIZED VIEW, tai mahdollisesti triggeriä.) Harmi että Postgresistä ei ole sulautettua versiota, sillä minulla ei ole mitään hinkua ajaa erikseen tietokantapalvelinta pelkästään tätä projektia varten. Harmi.

Täytyy pitää silmät auki jos on vielä joku helppo tapa saada automaattisesti päivittyvät kilometrimerkit reiteille. Tai sitten alkaa rukkaamaan QChainagea itseään. Katsotaan.

Retkikartta ja LIPAS-kanta

Valitettavasti edes kaiken tämän virittelyn jälkeen en voi sataprosenttisesti luottaa siihen, että kaikki mitä QGIS:ssä näen on se mitä minun olisi syytä nähdä. Alla olevassa kuvaparissa on retkikartan näkymä Puolangan seudulta ja oikealla se mitä QGIS:ssä näen LIPAS-aineiston pohjalta. WAT?!?! 😦😕😰

Iso pätkä UKK-reittiä puuttuu LIPAS-kannasta, samoin monet laavut ja autiotuvat Lapissa! Sen olen tiennyt että lippaassa ei ole kaikkia kartalta löytyviä laavuja, eikä kaikkia nuotiopaikkoja (joita ei aina ole kartallakaan). Tulikartta.fi-sivustolla olen jo aiemminkin törmännyt paikkoihin joita ei ole löytynyt kummastakaan. On siis jokatapauksessa hyvä idea tarkistaa ennen reittivalinnan lukkoon lyömistä löytyykö retkikartasta tai tulikartasta reitin varrelta jotain mitä on lippaasta tai karttapohjalta puuttunut.

Mutta että kokonainen UKK-reitti?

Syy on aika yksinkertainen, mutta vaati vähän miettimistä. Retkikartan UKK-sivulta löytyy maininta:

“Retkikartalla näkyy Metsähallituksen ylläpitämät kohteet, sekä Lipas.fi:hin tallennetut kuntien ylläpitämät kohteet.”

Eli… retkikartasta löytyy kaikki mitä lippaassa on, sekä Metsähallituksen omat kohteet. Lähetin tarkentavan kysymyksen palvelun ylläpidolle ja sain vahvistuksen epäilykselleni, eli esimerkiksi iso osa UKK-reitin paikkatiedosta tulee suoraan Metsähallitukselta—eikä sitä ole siis tallennettu LIPAS-kantaan. Eikä näitä Metsähallituksen paikkatietoja ole julkaistu avoimena datana, joten en pysty niitä myöskään saada QGIS:ssä näkyväksi. Toivoa kuitenkin on, sillä “Myöhemmin omien tietojärjestelmiemme uudistuksen myötä uskoakseni tilanne [datan avoimen saatavuuden suhteen] tulee kuitenkin muuttumaan.”

Sitä odotellessa… pitää katselmoida reitti myös muissa retkitietopalveluissa.³