PostgreSQL-tietokanta PostGIS-laajennoksella sekä GeoServer-palvelinohjelmisto muodostavat monen paikkatietoja käsittelevän ja jakelevan organisaation arkkitehtuurin keskeiset komponentit. Pienimuotoisessa käytössä tämä ohjelmistot toimivat oikein hyvin ilman laajempia konfigurointitarpeita, mutta vaativampi käyttö edellyttää nopeasti syvempää asiantuntemusta ja esimerkiksi klusterointia. Tässä blogikirjoituksessa käydään läpi muutamia vinkkejä, jotka nousivat vahvimmin esille hiljattain toteuttamassamme asiakasprojektissa. 

Niin tylsältä ja ympäripyöreältä kuin se kuulostaakin, parhaat ratkaisut riippuvat aina täysin käyttötapauksesta. Muutamia kysymyksiä kannattaa kuitenkin pohtia etukäteen:

• Käsitteletkö vain rasteri- tai vektoriaineistoja? 
• Onko aineistoa megoja, gigoja vai teroja? 
• Käytetäänkö aineistoja dynaamisesti selainsovellusten kautta vai esimerkiksi satunnaisesti QGISillä aineistoa muokaten? 
• Millaisia ovat aineistojen käyttäjämäärät?
• Millaisella syklillä aineistot päivittyvät?

Nämä ja monet muut tekijät määrittävät optimoinnin askeleet. Tämän blogin tarkoitus on kuitenkin antaa yleiskatsaus aiheeseen ja vinkkejä etenemisen suunnista. 

Paikkatietoaineistot kuntoon 

Suorituskyvyn optimointi kannattaa aina tehdä systemaattisessa järjestyksessä, eli aloittaa helpoista muutoksista, joilla voi saada isoja vaikutuksia aikaan. Käytännössä tämä tarkoittaa, että kannattaa käydä ensin läpi aineistoformaatit ja matalan tason konfiguraatiot huolella, ennen kuin lähtee muokkaamaan esimerkiksi tietokannan tai GeoServerin edistyneitä konfiguraatioita. 

Rasteriaineistojen osalta esikäsittely on tärkeää. Yleisenä hyvänä käytäntönä voi seurata Cloud Optimized Geotiff (COG)-määritystä. Se mahdollistaa aineistojen tehokkaan tallennuksen objektivarastoihin (esim. Amazon S3) ja tehokkaan kyselyn, mutta samaan aikaan se näyttäytyy aivan samankaltaisena aineistona kuin normaali GeoTiff. Tärkeintä rasteriaineiston suhteen on muistaa seuraavat seikat:

1. Aineisto on kompressoitu käyttötarkoitukseen sopivalla tavalla.
2. Aineisto on tiilitetty käyttötarkoitukseen sopivalla tavalla.
3. Aineistolle on generoitu sisäiset overview-kuvat.

Vektoriaineistojen kanssa on hyödyllistä muistaa seuraavat asiat:

1. Vektoriaineistot tulee varastoida paikkatietokantaan (PostgreSQL/PostGIS).
2. Aineistojen kaikille geometriatiedoille on luotu tietokantaan spatiaaliset indeksit.
3. Aineistoille on luotu muilta osin järkevät tietokantaindeksit ml. primääriavaimet.
4. Aineistot on tallennettu yleisimmin käytettyihin koordinaattijärjestelmiin, joten koordinaattimuunnoksia ei tarvitse tehdä lennossa.
5. Mittakaavarajoja kannattaa hyödyntää GeoServerin tyyleissä tietokannasta kyseltävien kohteiden lukumäärän rajoittamiseksi.

Esimerkiksi aineistojen yleistysoperaatio on yksi esimerkki suuresta suorituskykyhyödystä, joka on täysin riippuvainen käyttötapauksesta. Jos aineistoilla tehdään tarkkaa laskentaa, ei mahdollisuuksia yleistyksiin juurikaan ole. Jos sen sijaan käyttökohteena on vain karkean tason visualisointi, voi aineistoja yleistämällä saavuttaa merkittäviä suorituskykyhyötyjä. 

Rasterit tietokantaan? 

Edellä mainitut vektoriaineistojen käsittelyvinkit ovat hyvä lähtökohta PostGISin optimointiin. Suorituskykyhyötyjen hakeminen rasteriaineistojen tallennuksella kokonaan tietokantaan on järkevää vain harvoissa erityistapauksissa. 

PostGISin rasteriaineistojenhallinta on versiosta 3 ylöspäin siirretty jälleen omaan laajennokseensa. Jos rasteriaineistoille tehdään paljon analyysejä ja niiden käyttötapaukset ovat monipuolisia sekä ne liittyvät muihin samassa tietokannassa sijaitseviin vektoriaineistoihin, voi rasterilaajennoksen käyttö olla tarkoituksenmukaista. Jos sen sijaan rasteriaineistoja vain tallennetaan ja jaetaan eteenpäin, ei rasteriaineistojen tallentamisesta tietokantaan ei ole juurikaan mainittavaa hyötyä suhteessa niiden käyttämiseen suoraan levyltä. Tästä syystä rasteriaineistojen suorituskyvyn parantamisen näkökulmasta keskeiset tekijät ovat aineistojen tiilitys ja  tallennus välimuistiin mahdollisuuksien mukaan.

Rasteriaineistojen tallennusmenetelmissä PostGISin näkökulmasta puhutaan in-DB ja out-DB ratkaisuista. 

• in-DB:n tapauksessa rasteri tallennetaan objektina tietokantaan byte stream -muodossa. Käytännössä tässä ei tapahdu pakkausta. Hyvänä puolena tässä ratkaisussa on, että kaikki rasterit tallentuvat yhteen paikkaan. Kuitenkin jos käyttötapauksiin ei liity rastereiden analyysiä (esim. useat ilmakuvat), ei tällöin ole tarvetta hyödyntää esimerkiksi PostGISin rasterianalyysifunktioita, ja konkreettiset hyödyt tietokantaan tallentamisesta jäävät vähäiseksi. Lisäksi jos tarkoitus on vain hakea rasteridataa, ei PostGIS ole tähän nopein ratkaisu. 
• Out-DB on huomattavasti tyypillisempi tapa tallentaa rastereita PostGISiin. Tällöin tietokantataulu sisältää rasterin rajauksen (bounding box) ja viittauksen ulkoiseen tiedostoon levyjärjestelmässä.

Enemmän irti PostgreSQL:stä shardauksella

Jos tietokannassa käsitellään valtavia aineistomassoja, voivat aineistojen peruskäsittelyn jälkeen tietokannan optimoinnin ratkaisut tulla ajankohtaisiksi. Kannattaa siis siirtää katse PostGISistä PostgreSQL:n suuntaan. Optimoinnin keinoja ovat esimerkiksi PostgreSQL-konfiguraatiotiedostojen kautta tehtävät muutokset tai koko ympäristön skaalaus.  

Vertikaalinen skaalaus (scaling up) tarkoittaa yhden palvelimen muistin, prosessoritehon tai levytilan lisäämistä.  Yhden palvelimen sisällä tietokanta voidaan myös osioida (partitioning), jolloin data kirjoitetaan uudelleen pieniin kokonaisuuksiin yhden tietokantapalvelimen sisällä. Horisontaalinen skaalaus tarkoittaa tietokannan hajauttamista useammalle palvelimelle.  Suoraviivaisin ratkaisu on tehdä replikoituja tietokantoja, joiden lukua ja kirjoitusta hallinnoi yksi master-kanta.

Koko tietokannan replikoinnin sijaan data voidaan myös hajauttaa osiin useammalle tietokantapalvelimelle. Tällöin puhutaan optimointimenetelmästä nimeltään sharding. Siinä valitaan yksi avainsarake, jonka mukaan tiedot hajautetaan eri tietokantanoodeille.  Shardaus tuo suorituskykyhyötyjä, mutta myös yhden abstraktiokerroksen lisää kokonaisuuteen. Shardaus ei välttämättä sovi parhaalla tavalla analyyttisiin kyselyihin, jossa haetaan kerralla lähes kaikki taulun data. Tällöin kyselyn pitää käydä hakemassa ja yhdistämässä datat eri palvelimilta. Datalle pitää myös tehdä ajoittain uudelleenshardaus, jossa data hajautetaan palvelinten välille. 

Yksi esimerkki PostgreSQL:n shardaukseen on avoin klusterointiratkaisu Citus, josta on tarjolla oma avoin PostgreSQL-laajennusosa. Cituksen rakenteessa yksi koordinaattori (Coordinator node) jakaa kyselyitä eteenpäin toisilla palvelimilla sijaitseville tietokannoille (Worker node). Citus mahdollistaa myös automaattiseesti replikoinnin kautta high availability -ympäristön, jossa yhden palvelimen ongelmatilanteessa kyselyt ohjautuvat automaattisesti muille klusterin noodeille. Citusta on hyödynnetty juuri paikkatietoaineistojen ja PostGISin kanssa.

GeoServerin optimointi ja klusterointi

Klusteroinnilla voi parantaa myös GeoServer-ympäristön suorituskykyä ja toimintavarmuutta. Klusteroinnilla tarkoitetaan usean GeoServer-instanssin pyörittämistä rinnakkain jaetulla konfiguraatiolla. Klusterointiin on kaksi eri ratkaisuvaihtoehtoa; aktiivinen ja passiivinen. 

• Passiivinen klusterointi tarkoittaa useamman GeoServer-instanssin toimintaa klusterissa jaetun datahakemiston kanssa. Valtaosa GeoServerin asetuksista, kuten julkaistut tasot ja tietolähteet, varastoidaan nk. datahakemiston sisällä oleviin XML-tiedostoihin. Passiivisessa klusterissa kaikki klusteriin osallistuvat GeoServer-instanssit lukevat konfiguraationsa samasta datahakemistosta, joka voi sijaita esim. verkkolevyllä. Täten tehdyt konfiguraatiomuutokset vaikuttavat kaikkiin klusterin instansseihin tietyin varauksin, joista lisää myöhemmin.
• Aktiivisessa klusterissa jokainen klusteriin osallistuva GeoServer säilyttää oman paikallisen datahakemistonsa ja täten oman konfiguraation. Tiettyyn instanssiin tehdyt konfiguraatiomuutokset eivät täten vaikuta muihin klusterin instansseihin. Eri instanssien konfiguraatioiden synkronoinnista vastaa erityinen middleware-ohjelmisto, joka vastaa konfiguraatiomuutosten havaitsemisesta ja migraatiosta instanssien välillä.

Eräiden GeoServerin kehittäjien mukaan passiivinen klusterointi sopii aktiivista klusterointia paremmin 90% eri käyttötapauksista. Passiivisen klusteroinnin etuna on verrattainen yksinkertaisuus, sillä sen toteuttaminen ei edellytä ylimääräistä middleware-kerrosta.

Klusterointi on järkevintä toteuttaa kontitusratkaisuja hyödyntäen (esim. Docker). Sovelluskonttiin voidaan asentaa GeoServerin lisäksi kaikki sen tarvitsemat riippuvuudet. Mukaanpakattujen riippuvuuksien myötä kontitus helpottaa myös järjestelmän ylläpidettävyyttä. Useissa valmiissa imageissa on lisäksi esikonfiguroitu GeoServeriä ja Tomcatia yleisten hyvien käytäntöjen mukaan. 

Yksittäisen GeoServer-instanssin suorituskykyä voidaan parantaa Java Virtual Machinen (JVM) konfiguraatiolla sekä GeoServerin omien asetusten optimoinnilla. On kuitenkin huomioitava, että tätä kautta ei monissakaan käyttötapauksissa saavuteta merkittävää parannusta suorituskyvyssä. Keskeinen seikka GeoServerin optimoinnissa on myös välimuistikerros ja karttatiilien hyödyntäminen mahdollisuuksien mukaan esimerkiksi GeoWebCachen avulla. Dynaamiseen WMS-tasoon verrattuna tiilitetty WMTS-karttataso latautuu 10 – 100 kertaa nopeammin, mikäli taso on kokonaan välimuistissa. 

Optimaaliset ratkaisut asiakaskohtaisesti

Ei ole olemassa yleisesti parhaita käytäntöjän aineistojen käsittelyyn tai optimaaliseen paikkatietoarkkitehtuuriin. Englanniksi puhutaan usein termistä “low hanging fruit”, jonka kautta voi ajatella optimoinnin askelmerkkejä. Nämä matalalla roikkuvat hedelmät tarkoittavat helposti tehtäviä muutoksia, joilla saa eniten muutosta aikaan. 

Jos haluat syventyä edistyneempien konfiguraatioiden maailmaan tai kuulla mikä voisi olla paras ratkaisu juuri sinun tarpeisiisi, otathan meihin yhteyttä!

Suurta osaa paikkatietodatasta ei voida luoda ja käsitellä pelkästään etäältä, toimiston työpisteeltä käsin, vaan tieto syntyy paikan päällä “kentällä”. Nopeasti mieleen tulevat ainakin erilaiset luontokartoitukset ja havaintojen tarkistukset sekä infraomaisuuden hallintaan ja huoltoon liittyvät tehtävät tai vaikkapa joukkoistamisen käyttö datan keruussa.

Mobiililaitteista ei varsinaisesti tänä päivänä ole pulaa, ja myös erilaisia helposti käyttöönotettavia mobiiliratkaisuja paikkatiedon keruuseen löytyy useita. Toisaalta mobiililaitteiden koko ja suorituskyky asettavat rajoitteita sille, mitä kaikkea niillä voi ja kannattaa tehdä. Onkin mielenkiintoista tarkastella, miten eri mobiilisovellukset solahtavat yhteen käyttäjän muun paikkatietoinfrastruktuurin ja -ohjelmistojen kanssa, ja millaisiksi paikkatiedon keräämisen työprosessit kokonaisuudessaan muodostuvat. Mitä kaikkea kannattaa kerätä? Millaisiin tilanteisiin mobiilisovellusratkaisut soveltuvat ja mihin kaikkeen ne kykenevät?

Keväällä testasimme Väyläviraston kanssa QField-mobiilisovellusta ja erityisesti sen soveltuvuutta liikenneohjauslaitteiden (jatkossa lyhenteellä LOL) inventointiin. Kerroimme tästä aiemmin myös täällä Gispon blogissa.  Sittemmin QField-kehittäjien leirissäkin on ehtinyt tapahtua paljon, ja mobiilisovelluksen pilvipalveluversio, QFieldCloud, on tullut ennakkoon rekisteröityneiden käyttäjien beta-testaukseen. Jatkoa tuohon aiempaan LOL-projektiin onkin seurannut, ja olemme Gispossa kesän ja syksyn aikana olleet ensimmäisten joukossa testailemassa QFieldCloud-sovelluksen käyttöönottoa.

Mikä QField?

Kerrataan ensin, mikä olikaan tuo aiempi, perusmallinen QField-sovellus, ja tarkastellaan sitten, mitä Cloud-liite tuo siihen mukanaan lisää. QField on siis paikkatiedon mobiilikeruuseen ja -käyttöön tarkoitettu avoimen lähdekoodin sovellus, jonka pääkehittäjä on sveitsiläinen OpenGIS.ch. Sovellus on kehitetty pääasiassa Android-laitteille, joskin Applen laitteilla toimiva iOS-versiokin on tuloillaan. Lisäksi myös Windows-käyttöjärjestelmää käyttäville mobiililaitteille on versio nykyisellään beta-testauksessa. 

Sovelluksen kehityksen alkuhämärä ulottuu jonnekin noin 10 vuoden päähän, kun taas uusin julkaisuversio on keväällä ilmestynyt QField 1.9 “Taivaskero”. Kuten QGISissä, myös QFieldissä julkaisuversiot nimetään eri maantieteellisten paikkojen, tarkemmin ottaen vuorten ja muiden huippujen mukaan. Tuolla jo mainitulla LOL-projektissa toteutetulla Suomen osoitteiden osoitehaulla saattaa olla jotakin tekemistä uusimman version nimen sijoittumisen kanssa Suomeen ja Pallastunturille! 

Q-alkukirjain nimessä viittaa kuin viittaakin QGISiin, ja sovellus on kehitetty käytettäväksi sen kanssa. Työnkulku QFieldissä on jotakuinkin seuraavanlainen: 

1. Projektin työtila määritellään QGISissa  
2. Projektitiedostot konfiguroidaan ja paketoidaan QGISin QFieldSync-lisäosalla siirrettäväksi mobiililaitteeseen (esimerkiksi usb-johdolla)
3. Itse tieto kerätään kentällä QFieldillä
4. Projektitiedosto ja data synkronoidaan QGISin työtilaan. Dataa on tämän jälkeen mahdollista tietysti muokata ja jatkojalostaa QGISissä.

Sovelluksen uusimmalla versiolla QGISin käyttö ei periaatteessa joka tilanteessa ole pakollista, vaan mobiililaitteella olevia vektori- ja rasteriaineistoja pystyy avaamaan ja tarkastelemaan myös suoraan. Kuitenkin varsinaisia paikkatiedon keruuprojekteja varten QGISin tuntemusta tarvitaan. Tietojen syöttäminen manuaalisesti käsin saattaa olla aikaavievää, joten lomakkeiden tehokas käyttö on avainasemassa ja tiedon syöttötapojen fiksu suunnittelu eri vimpaimineen (widgets) sekä oletusarvoineen QGISin puolella kannattaa. Samoin QGISissa määritetyt tasojen kuvaustyylit, karttateemat ja -tulosteet (jopa kartta-atlakset) toimivat QFieldissä sellaisenaan. Toisaalta mobiililaitteella valokuvien suora liittäminen lisättäviin kohteisiin on erittäin kätevää. 

Myös QField itsessään vaatii tietysti jonkin verran perehtymistä ja mobiilikeruu tuo omat erityispiirteensä, joihin pitää osata kiinnittää keruuprosessien suunnittelussa huomiota. Ensinnäkin on esimerkiksi etukäteen mietittävä, työskennelläänkö ilman verkkoyhteyttä (offline-keruu) vai meneekö data suoraan laitteelta vaikkapa PostGIS-tietokantaan (online-työskentely). QFieldin käyttöliittymän filosofiana on ollut yksinkertaisuus, ja ylimääräisiä näppäimiä ei ole ruutua täyttämässä. Käyttäjän kannalta tämä vaatii hieman opettelua ja tottumista.  

Tehokkaan digitoinnin kannalta QField sisältää toisaalta kyllä monia QGISista tuttuja toiminnallisuuksia. Esimerkiksi tarttumisen työkalut ja topologisen editoinnin mahdollisuus auttavat geometrisesti eheiden kohteiden ja alusta alkaen hyvälaatuisen datan luonnissa. Toisaalta mobiililaitteilla stylus-kynää käyttäen geometrioiden lisäys onnistuu myös kätevästi vapaalla kädellä piirtäen. 

Muista mobiililaitteiden erityisominaisuuksista on mainittava laitteen paikannus, joka mahdollistaa lisättävien kohteiden tarkkojen koordinaattien määrittämisen sekä viivojen ja monikulmioiden automatisoidun digitoinnin käyttäjän sijaintia seuraamalla (jäljitys/tracking). Laitteen sisäisen paikannuksen lisäksi on mahdollista käyttää ulkoista antennia, jonka avulla on päästään tarkempiin sijaintitietoihin.

Näihin ja muihin QFieldin ominaisuuksiin pääsee perehtymään myös uudella, marraskuussa järjestettävällä kurssilla “Paikkatiedon mobiilikeruu QFieldillä”. Gispon koulutuksiin pääset tutustumaan tästä: https://www.gispo.fi/koulutus/ 

Mikä QFieldCloud?

Käytännössä edellä mainitun kaltaisessa työnkulussa suurimmaksi hankaluudeksi muodostuu projektitiedostojen ja datan synkronointi tietokoneelta mobiililaitteelle ja takaisin. Projektitiedosto on paketoitava ja siirrettävä manuaalisesti kaikkiin laitteisiin, joilla keräystä suoritetaan, esimerkiksi usb-johdon välityksellä. Tämä on parhaimmillaankin kuitenkin  ylimääräinen työvaihe, puhumattakaan mahdollisesta “versionhallintakaaoksesta”, joka seuraa, kun projektitiedostoa jaellaan edestakaisin monien laitteiden välillä datankeruuprojektin jatkuessa pidempään. Lisäksi aina ei ole käytännöllisintä määritellä etukäteen, tulisiko projektin olla offlline vai online. Mitä tehdä esimerkiksi, jos online-projektissa mobiilidatayhteys ei olekaan aina ja joka paikassa käytettävissä?

Käytännössä QFieldin pilvipalveluversio QFieldCloud vastaa näihin käyttötapauksiin, ja moniin muihinkin! Projektitiedostojen ja kerättävän datan synkronointi helpottuu huomattavasti niiden siirtyessä ilman ylimääräisiä kaapeleita laitteiden ja pilven välillä. Lisäksi muutokset voidaan joustavasti ajaa pilveen silloin kun tarvittava datayhteys on käytettävissä. Sinällään itse digitointi ja muu mobiililaitetyöskentely sekä niihin liittyvät työkalut säilyvät entisenlaisina. 

Uutena komponenttina QFieldCloudissa tulee selaimella käytettävä hallintapaneeli, jonka avulla onnistuu projektien hallinta pilvipalvelun ja muiden laitteiden välillä. Sen myötä tulee myös esimerkiksi mahdollisuus projektikohtaisten tiimien ja käyttöoikeuksien määrittelyyn, eli voi helposti määritellä, kenellä on oikeus nähdä tai muokata mitäkin aineistoja. Paneelista pystyy myös näkemään kaikki yksittäisetkin muutokset projektiin ja sen dataan (mitä on muutettu, kuka on muuttanut ja milloin?) sekä tarvittaessa kumoamaan nämä muutokset. Kyse on siis täydellisestä versionhallinnasta, jossa käyttäjien ristiriitaisten muokkausten aiheuttamat “konfliktit” voidaan ratkoa, ja jossa mikä tahansa projektin aiempi versio on myös ladattavissa myöhemmin. 

Lopuksi

Aiemman QField-postauksen lopuksi Sanna pohti QFieldin toimivuutta ja ennakoi silloin vielä tulossa ollutta QFieldCloud-ratkaisua. Onko lupaukset nyt siis lunastettu? Voi sanoa, että valtaosaltaan kyllä. Itse mobiilisovelluksen käyttöön ei tule suurta muutosta, mutta projektien suora synkronointi pilveen jouhevoittaa monia työkulkuja ja tekee eri laitteilla työskentelystä oikeastaan varsin mukavaa. Mukana tulevan käyttäjähallinnan ja versioinnin myötä se myös esimerkiksi automaattisesti selkeyttää eri henkilöiden työnkuvaa datan keräämisessä.

Kuten sanottua, QFieldCloud on vielä beta-testausvaiheessa ja valtaosa käyttökokemuksesta onkin saatu käyttämällä sovelluksen pääkehittäjän ylläpitämää testikäyttöön tarkoitettua pilvipalvelua. Ennakkotietojen mukaisesti OpenGIS.ch tulee sovelluksen julkaisuversion myötä tarjoamaan vastaavaa hostauspalvelua eritasoisilla vaihtoehdoilla (ilmainen Community-versio sekä maksulliset Pro- ja Team-versiot). Avoimen lähdekoodin sovelluksella mikään ei kuitenkaan estä pystyttämästä vastaavanlaista pilvipalvelua myös itse räätälöiden, ja me Gispolla testasimme myös tätä ratkaisua. Kaiken kaikkiaan QFieldCloud tarjoaa mobiilisovelluksen, joka kätevästi integroituu käyttäjän jo olemassa olevien paikkatietoratkaisujen, kuten oman Postgis-tietokannan, kanssa.

Google Earth Enginen (GEE) avulla pääset helposti käsiksi hyvin pitkälle prosessoituun maantieteelliseen aineistoon tyypillisesti hankalasti säilytettävän ja paljon tallennustilaa vaativan datan sijasta. GEE tarjoaa yhteyden useisiin kaukokartoitusaineistoihin ja niistä johdettuihin tuotteisiin kuten DMSP-OLS- ja VIIRS-DNB-satelliittikuvakokoelmiin. Kun GEEn usean petatavun kokoisen aineistoluetteloon yhdistää erittäin korkean suorituskyvyn omaavan rinnakkaislaskentapalvelun (GEE hyödyntää prosessoinnissaan tuhansien ympäri maailmaa sijaitsevien Googlen datakeskusten tietokoneiden laskentatehoa), pienille alueille kohdistuvat tehtävät valmistuvat minuuteissa ja koko maailman mittakaavan operaatioitkin saadaan suoritettua muutamassa päivässä.

Vaikka GEE ei ole avoimen lähdekoodin ratkaisu, palvelu on kuitenkin kaikille avoin mahdollistaen sen, että kuka tahansa voi käyttää GEEtä omiin (ei-kaupallisiin) tarkoituksiinsa. Käyttäjäksi pääsee rekisteröitymällä alustalle Google-tilin avulla. Google myöntää tavallisesti uusille hakijoille käyttöoikeuden 24 tunnin sisällä. Rekisteröitymisen jälkeen pääset nauttimaan GEEn käyttövalmiista kuvatuotteista sekä vaikuttavasta laskentatehosta.

GEEn sisältämään dataan pääsee käsiksi sekä Javascriptin että Python APIn (ohjelmointirajapinnan) kautta. GEEn oma koodieditori käyttää Javascriptiä, mutta GEEn aineistojen interaktiivinen tarkastelu ja analysointi onnistuu kätevästi myös Pythonilla minkä tahansa IDEn (kehitysympäristön) kautta. IDE eroaa APIsta tyypillisesti sillä, että se mahdollistaa nopean prototyyppien luomisen ja tulosten visualisoinnin.

GEEn Python APIn dokumentaatio on huomattavasti JavaScript APIn vastaavaa suppeampi (linkki). Tämä ei kuitenkaan tarkoita sitä, ettei Python APIlla pärjää. Itse asiassa kahden Python APIn avainmoduulin, earthengine-apin ja geemapin, avulla saa käyttöönsä hyvin pitkälti samat toiminnallisuudet kuin mitä JavaScript APIn kauttakin saisi.

GEEn aineistot

Silläkin uhalla, että toistan itseäni, mainitsen asiasta uudelleen: parasta GEEssä on data. Pelkästään Earth Engine Data Catalogin vilkaisu riittää kertomaan, miten valtavasta datavarannosta on kyse. Jokainen datan parissa töitä tehnyt tietää, kuinka vaikeaa sopivan aineiston löytäminen ja siirtäminen analyysikuntoisena omaan työskentelyjärjestelmään voi olla. GEEn kanssa elämä on helpompaa; dataa ei tarvitse ladata minnekään eikä sen hallinnoinnista tarvitse murehtia sen enempää kuin mahdollisista omiin tarkoituksiin epäkätevistä tiedostomuodoista tai koordinaattijärjestelmistäkään. Haluaisin tietenkin esitellä tässä yhdessä blogissa kaikki mahdolliset GEEn sisältämät aineistot, mutta keskitytään nyt jatkossa kuitenkin vain kahteen kiinnostavaan kaukokartoitusaineistoon: DMSP-OLS- ja VIIRS-DNB-sensoreiden havaitsemaan yöaikaiseen valosäteilyyn.

Sekä DMSP-OLS- että VIIRS-DNB-sensorit ovat kaukokartoituslaitteita, jotka pyrkivät kuvaamaan monenlaisia Maan pinnalla tapahtuvia ilmiöitä keräämällä avaruuteen emittoituvaa elektromagneettista säteilyä (esimerkiksi valoa). Kaukokartoituslaitteista puhuttaessa keskeisiä termejä ovat spatiaalinen, spektraalinen ja temporaalinen resoluutio. Tyypillisesti näiden kaikkien yhtäaikainen parantaminen on hyvin vaikeaa ja usein joudutaankin tekemään hieman kompromisseja esimerkiksi temporaalisen resoluution suhteen, jos halutaan parantaa kaukokartoituslaitteiden vastaanottamien signaalien perusteella tuotettujen kuvatuotteiden spatiaalista tai spektraalista resoluutiota.

DMSP-OLS on ensimmäinen sensori, jonka keräämistä tiedoista tuotettiin globaaleja “vakaiden valojen” kuvatuotteita vuodesta 1992 vuoteen 2013 asti. VIIRS-DNB on DMSP-OLS-sensorin seuraaja, joka DMSP-OLSin tapaan ehtii kiertää maapallon 14 kertaa vuorokaudessa kuvaten sekä päivä- että yöpuolen maapallosta joka 24. tunti. Yhtäläisyyksistä huolimatta VIIRS-DNB on onnistunut ratkomaan monia DMSP-OLS-datan haasteita esimerkiksi spatiaaliseen resoluutioon (~4.9km -> ~750m), radiometriseen resoluutioon (6-bittinen -> 14-bittinen), blooming-efektiin & saturaatioon liittyen (kaupunkialueita liioitteleva hehku on vähentynyt ja saturaatio-ongelma on poistunut kokonaan). Huomionarvoista on myös se, että DMSP-OLS-sensoria vaivaava on-board-kalibraation puute ei koske VIIRS-DNB-sensoria, sillä VIIRS-DNB mittaa pikselikohtaista yöaikaista valoa säteily-yksiköissä (nanowatts/cm²/sr). Halutessasi voit lukea lisää DMSP-OLS- tai VIIRS-DNB-sensoreiden avulla kerättyjen aineistojen historiasta, ominaisuuksista ja haasteista esimerkiksi täältä.

Mainittakoot lopuksi, että toki VIIRS-DNB-aineistoonkin liittyy ongelmia. Näistä keskeisimmät liittyvät siihen, ettei tämän sensorin tuottaman datan kanssa olla ehditty vielä kehittyä kuvatuotteiden tuottamisen kanssa samalle tasolle kuin DMSP-OLS-sensorin datan kanssa vuosien karttuessa päästiin. Kuvatuotteiden tuottaminen on siinä mielessä tärkeää, että yöaikaista valonsäteilyä kuvaavaa aineistoa ei ollut koskaan tarkoitettu stand-alone-tuotteeksi, jonka vuoksi avaruuteen säteilevän valon määrään voivat vaikuttaa myös monet luonnolliset ilmiöt (pilvet, tulipalot, saasteet), joista emme ole niin kiinnostuneita. Tästä epävarmuustekijästä huolimatta DMSP-OLS- ja VIIRS-DNB-sensoreiden keräämää NightTimeLights-aineistoa on tutkittu paljon, ja sen seurauksena tuotettujen merkittävien tutkimustulosten kautta on saatu todistettua, että ko. data korreloi useiden hyödyllisen sosioekonomisten muuttujien kehityksen kanssa.

Jupyter Notebook ja GEE

Jupyter Notebook on avoimen lähdekoodin selainpohjainen sovellus, joka soveltuu niin koodia, visualisointeja kuin tekstiä sisältävien dokumenttien luomiseen ja jakamiseen. Jupyter Notebookin kautta pystyy siis käyttämään myös GEEtä lisäämällä tiedoston alkuun muutaman rivin koodia:

Datan visualisointi

GEE mahdollistaa aineistojen visuaalisen tarkastelun interaktiivisten karttaupotusten kautta

Videosta 1 käy ilmi, että karttaupotus voi sisältää useita eri aineistoja, joiden näkyvyyttä voi säädellä paikkatieto-ohjelmistojen tapaan klikkaamalla tason aktiiviseksi tai säätämällä tasojen läpinäkyvyyttä. Kannattaa kiinnittää huomiota siihen, että varsinaisten aineistojen (videossa on ladattu DMSP-OLS-kuvakokoelmasta vuoden 1992 komposiitti ja VIIRS-DNB-kuvakokoelmasta vuoden 2020 kuukausittaisten komposiittien mediaani) lisäksi GEEssä on saatavilla valikoima erilaisia taustakarttoja. Karttaupotuksen interaktiivisuus mahdollistaa karttapohjalla liikkumisen ja näkymän lähentämisen / loitontamisen joko karttaupotuksen vasemmasta reunasta löytyvillä painikkeilla tai hiiren rullalla.

GEEn interaktiiviset työkalut

GEEn karttojen interaktiiviset ominaisuudet eivät kuitenkaan rajoitu karttapohjalla liikkumiseen. Saatoit huomatakin videota 1 katsoessasi, että karttaikkunan oikean yläreunan jakoavainsymbolin alta löytyy kaksi vaihtoehtoista valikkoa. Toiselta voi säätää karttatasojen näkyvyyttä ja toiselta löytyy kokoelma GEEn interaktiivisia työkaluja. Videolla 1 esiteltiin yhtä näistä; info-työkalua. Napsauttamalla i-symbolia työkalu muuttuu aktiiviseksi, ja klikkaamalla mitä tahansa kohtaa karttapohjalla, saat nähdä mitkä arvot kyseiseen sijaintiin liittyvät. Mikäli karttaikkunassasi on useita tasoja aktiivisena, näet kerralla kaikkien tasojen tiedot.

Info-työkalun lisäksi annetaan tässä blogissa erityismaininta Timelapse / Timeslider -ominaisuudelle. Monet GEEn aineistoista liittyvät luonteeltaan ajan mittaan muuttuviin ilmiöihin, ja siksi onkin kätevää pystyä luomaan animaatiota helposti GEEn omien interaktiivisten työkalujen avulla. Tarkastellaan esimerkinomaisesti vaikkapa kuukausittaisia keskilämpötiloja (kelvineinä) Japanissa. Videosta 2 pääset näkemään, miten animaation luominen käytännössä toimii ja miltä lopputulos näyttää.

Huom! Jo olemassa olevaan karttaikkunaan voidaan jälkikäteen lisätä uusia aineistoja:

Saatat ihmetellä miten ihmeessä noin monimutkaisia tiedostopolkuja voi muistaa ulkoa. Hyvä uutinen on se, ettei niitä tarvitsekaan muistaa. Karttaupotuksen oikeasta yläreunasta löytyy nimittäin maapallosymboli, jonka data-välilehden alta pystyt avainsanoilla hakemaan itseäsi kiinnostavia GEE-aineistoja. Kun löydät mieluisasi, napsauta Import, ja yllä näkyvien koodirivien pohja ilmestyy uuteen Jupyter Notebook -soluun.

Mainittakoot lopuksi vielä, että maapallosymbolin alta löytyy myös mahdollisuus hakea kartalta kohteita osoitteen, paikan nimen tai koordinaattien perusteella. GEEn karttaikkunan vasemman reunan työkaluilla pystyy myös mittaamaan etäisyyksiä tai lisäämään markereita karttapohjalle. GEEn työkalujen joukosta (jakoavaimen alta) löytyy kamerasymboli, jonka avulla pystyy tallentamaan luomansa karttanäkymät kuvina tai HTML-tiedostoina. On huomionarvoista, että osa GEEn karttaupotusten työkaluista eivät ole enää HTML-tiedostoksi tallentamisen jälkeen käytettävissä.

Puolitetun karttanäkymän luominen

GEEn avulla pystytään luomaan myös puolitettuja karttanäkymiä. Nämä ovat erityisen käteviä silloin, jos halutaan vertailla kahta eri karttatasoa.

Videolla 3 on luotu jaettu karttanäkymä vuosien 1992 ja 2012 DMSP-OLS-komposiiteista. Videolta käy hienosti ilmi, miten havainnollistavaa jaetun karttanäkymän käyttö voi olla. Kytkintä liikuttelemalla voimme interaktiivisesti säätää kumman “ikkunan” läpi haluamme alla olevaa maailmaa katsoa. Havainto valoisten alueiden laajenemisesta ko. 20 vuoden aikavälillä on helppo tehdä.

Vyöhykeanalyysi

GEEn avulla voidaan suorittaa myös hieman monimutkaisempia analyysiketjuja. Lähdetään tarkastelemaan vuoden 2018 VIIRS-DNB-dataa ja keskitetään analyysi Floridan keskipisteen ympärille luodun 200km bufferin alueelle.

Vyöhykeanalyysin muodostamisessa on tärkeää ymmärtää, millainen jakauma datassa on. Histogrammit ovat yksi tapa tutkia dataa. Alla olevasta kuvasta näkee selkeästi, miten keskimääräinen säteilyintensiteetti on keskittynyt kahteen arvoalueeseen, lähelle nollaa ja 6-8 nanowatts/cm²/sr välille. Nyt jos haluttaisiin tunnistaa alueet, joissa on korkea säteilyintensiteetti, voitaisiin valita raja-arvoksi kuvassa ehdotettu säteilyintensiteettiarvo, sillä sitä suuremman arvon omaavia pikseleleitä on selvästi olemassa ja ne erottuvat selkeästi isommasta matalamman valosäteilyintensiteetin tiheyspiikistä.

Mikäli luomme maskin näistä “korkean säteilyintensiteetin alueista” tarkastelemamme bufferin sisällä, saamme seuraavanlaisen karttatason:

Toinen vaihtoehto on tarkastella histogrammia vain sen verran, että tiedämme mille välille säteilyintensiteettiarvot asettuvat ja valita sieltä itseämme kiinnostavia arvovälejä toisistaan poikkeavilla väreillä visualisoitaviksi vyöhykkeiksi. Tällöin tulos voisi muodostua esimerkiksi alla olevan kaltaiseksi:

Ajan suhteen tehtävä analyysi

GEEn avulla voidaan tuottaa karttatuotteiden lisäksi myös erilaisia ilmiön kehittymistä kuvaavia käyriä. Tyypillinen kiinnostuksen kohde on selvittää, miten jokin mitattava ominaisuus on kehittynyt ajan suhteen. Esimerkinomaisesti voimme mainita, että tällaisia kiinnostavia metriikoita ovat esimerkiksi tarkasteltavalle alueelle osuvan valon määrä (Sum of Lights, SOL) tai säteilyintensiteetin jakauman kehitys ajan suhteen. Alla olevissa kuvioista paljastuu, miten Sri Lankasta tuleva valonsäteilyn määrä vaihtelee toki paljon vuodenaikojen mukaan, mutta myös millaisia trendejä siellä on viime vuosina ilmennyt. Yleisemmät trendit huomaa paremmin jälkimmäisestä kuviosta, jossa ollaan otettu SOL-keskiarvo 12 kk liikkuvan ikkunan sisällä. Käyrä tekee kaksi selvää sukellusta tarkastellun aikaikkunan sisällä. Syiden selvittäminen menee hieman salapoliisityön puolelle, mutta esim. lähteistä uutinen1 ja uutinen2 voisi päätellä, että 2016-2017 ajoittuneeseen radikaaliin muutokseen ovat saattaneet vaikuttaa alueelle osuneet luonnonkatastrofit. Toki ilmiötä on saattanut voimistaa myös esimerkiksi se, jos vuosi 2016-2017 on ollut erityisen pilvinen. Jälkimmäisen notkahduksen voisi kuvitella liittyvän globaaliin koronapandemiaan. Mikäli näin on, käyrän häntäpäässä on nähtävillä jo jälleen uutta valoa.

Toisena esimerkkinä tarkastelimme Bangkokin aluetta ja vuosien 2014-2016 aikana tapahtuneita muutoksia keskimääräisessä VIIRS-DNB-säteilyintensitetiin jakaumassa. Kuviosta on tehtävissä ainakin pari kiinnostavaa huomiota: käyrien piikit vaikuttavat systemaattisesti siirtyvän vuosi vuodelta hieman oikealle. Tämä tarkoittaa sitä, että keskimääräisen valosäteilyn intensiteetti on kasvanut (valoisten alueiden kehittyminen yhä valoisimmiksi). Lisäksi voidaan havaita isoimman piikin korkeuden kasvamista siirryttäessä vuodesta 2014 vuoteen 2016, joka puolestaan kertoo siitä, että kirkkaasti valaistujen alueiden osuus on kasvussa (enemmän valoisia alueita).

Säteilyintensiteetissä tapahtuneen muutoksen visualisointi kartalla

Ajan suhteen tapahtuneiden muutosten tarkastelu on GEEn avulla mahdollista tehdä myös karttapohjalla. Alla olevista kuvista näet miten Iranin (lähikuvissa Teheranin ja Ahwazin kaupungit) VIIRS-DNB-satelliitin keräämän keskimääräisen valon säteilyintensiteetin määrä on muuttunut vuoden 2014 alusta vuoden 2018 loppuun. GEEn aineistoilla voidaan nimittäin suorittaa myös pikselikohtaista analyysiä. Tässä tapauksessa meidän kannattaa vähentää vuoden 2018 joulukuun komposiitista vuoden 2014 tammikuun komposiitin arvot ja jakaa saatu tulos 60:llä (näin monta kuukautta tarkastellulle aikavälille mahtuu) saadaksemme numeraalisen arvion sille, mikä on ollut keskimääräinen kuukausittainen muutos valon säteilyintensiteetissä. Visualisointiparametrit kannattaa valita siten, että väri kuvaa muutoksen suuntaa (sininen vähenemistä, punainen lisääntymistä) ja värin voimakkuus muutoksen suuruutta. Huomaa, että tässä esimerkissä emme hakeneet Iranin valtion rajoja GEEn omista aineistoista vaan hyödynsimme tietokoneen muistissa olevaa lokaalia shapefilea muuntamalla sen ee-objektiksi.

Tässä kohtaa kannattanee mainita, että esimerkiksi tällaisia karttatasoja voi exportata ulos GEEstä esimerkiksi QGISiin GeoTIFF-tiedostoina. Tason exporttaus tapahtuu oletusarvoisesti omaan Google Drive -kansioon esim. seuraavasti:

Koropleettikartat

Pikselikohtaisten karttatuotteiden lisäksi GEEllä voi tuottaa myös koropleettikarttoja, joista esimerkkinä Italian ensimmäisen tason hallintoalueiden vuoden 2019 toukokuun keskimääräisistä VIIRS-DNB-satelliitin mittaamista valon säteilyintensiteettiarvoista tuotettu karttataso.

Muut mahdollisuudet

Muista GEEn tarjoamista mahdollisuuksista mainittakoot nyt ainakin DMSP-OLS-datan interkalibrointi (eri satelliiteilla tuotetut kuvatuotteet eivät ole keskenään suoraan vertailukelpoisia niin kuin VIIRS-DNB-data on), koneoppiminen (esim. Random Forest -luokittelija löytyy GEEstä implementoituna samoin kuin työkaluja ohjatun oppimisen menetelmien tarvitsemien harjoitusaineistojen muodostamiseen) ja GIFien tuottaminen. Alla yksi esimerkki Kiinan Wuhanin alueelta tuotetusta GIFistä, jossa on kuvattu VIIRS-DNB-datan säteilyintensiteetin kuukausittaista vaihtelua.

Testaa itse!

Koodit tässä blogissa esiteltyjen esimerkkien takaa löytyvät kokonaisuudessaan täältä:JupyterNotebookGEELataa

Mikäli haluat oppia hyödyntämään GEEtä syvällisemmin ja monipuolisemmin, kannattaa tutustua tähän blogiin liittyvän Jupyter Notebook -tiedoston lisäksi esimerkiksi World Bank’s Open Night Lights -tutoriaalisarjaan. Ei sitten muuta kuin kivoja tutkimusretkiä GEEn avaamaan uuteen maailmaan!

Kesäkuun puolessa välissä pidetyn Gispon QGIS-webinaarin innoittama päätin kirjoittaa pienen ohje-tyylisen blogin siitä, miten Gispon kehittämistä lisäosista ja yksinkertaisista QGISin geoprosesseista voi saada tukea päätöksentekoon. Kuten moni teistä varmasti tietääkin, QGIS on paikkatietojen hyödyntämiseen kehitetty työasemaohjelmisto, jota voi muokata omanlaisekseen paitsi kustomoimalla työtilaa myös lataamalla erilaisia lisäosia, joita on saatavilla yli 1400 virallista. Kuka tahansa voi kehittää uusia lisäosia luomalla OSGeo-käyttäjätunnuksen, lataamalla kehittämänsä pluginin QGIS Python Plugins Repositoryyn ja tekemällä mahdollisesti pyydettävät korjaukset / muokkaukset. Huomaa, että huolimatta siitä, että QGISin ohjelmointikieli on C++, lisäosat ja skriptit tuotetaan Pythonilla. Alla näet listan Gispon tuottamista QGISin lisäosista:

Mainittakoot, että yllä listattujen QGISin lisäosakirjastosta saatavilla olevien pluginien lisäksi Gispo on kehittänyt KuntaGML pluginin, jonka saa asennettua QGISiin käymällä lataamassa Release ZIPin Githubista.

Tässä blogissa hyödynnettävien lisäosien lyhyet esittelyt

Catchment – saavutettavuusalueen laskenta GraphHopperin avulla

• Matkustusaika/-matka määritetään OpenStreetMapin tieverkkoon perustuen

Digitransit.fi Geocoder – suomalaisten osoitteiden geokoodaus

• Hyödyntää MMLn, Digi -ja väestötietoviraston ja OpenStreetMapin aineistoja

FMI2QGIS – työkalu Ilmatieteen laitoksen (WMS- tai WFS-rajapintojen kautta saatavilla oleviin) avoimien aineistojen lataamiseen ja tarkasteluun

• Esimerkkejä näyttävistä FMI2QGISin avulla tuotetuista visualisoinneista voit tarkastella täältä

NLS GeoPackage Downloader – MMLn aineistojen jakelua ja visualisointia helpottava maastotietokantalisäosa

• Yhteen GeoPackageen voidaan varastoida useita eri maastotietokanta-aineistoja ja niihin yhdistettyjä tyylejä

Paras tapa oppia on esimerkkien kautta, joten lähdetään pidemmittä puheitta pohtimaan seuraavaa ongelmaa

Asut Helsingissä ja olet harkitsemassa muuttoa kaupungin sisällä. Olet löytänyt kiinnostavan asunnon, mutta et osaa päättää kannattaisiko muutto vai pitäisikö uuden asunnon etsintää jatkaa samalta alueelta, jossa tällä hetkellä asut. Rakastat ulkoilua ja liikkumista, josta mieleesi tuleekin, että jos pystyisit vertailemaan löytämäsi asuntovaihtoehdon ja nykyisen asuinalueesi ulkoilu- ja virkistysaluetarjontaa, niin päätös voisi olla helpompi tehdä. Tosin, voisit olla halukas antamaan hieman periksi lähialueen tarjoamista ulkoilu- ja liikuntamahdollisuuksista, mikäli uuden työpaikkasi lähistöllä sattuu olemaan paljon puistoja, joissa ulkoilla työpäivän jälkeen, lounastauoilla tai vaikka kävelypalavereita pitäessä. Et pidä kovinkaan tärkeänä sitä, mikä varsinainen etäisyys työpaikaltasi on kotiisi, sillä tulet kulkemaan työmatkat kuitenkin julkisilla. Tärkeintä olisi löytää kiva asunto viihtyisässä ja vehreässä asuinympäristössä.

Esimerkkiongelman ratkaisemiseen soveltuva workflow

1. Lataa Catchment-plugin Githubista (Releases → Assets). Asenna se QGISiin avaamalla QGIS ja navigoimalla Plugins →Manage and Install plugins → Install from ZIP.

2. Navigoi jälleen Plugins →Manage and Install plugins, mutta tällä kertaa siirry All-välilehdelle ja kirjoita ikkunan yläreunassa näkyvään hakupalkkiin “Gispo” (tai etsimäsi pluginin nimi). Asenna tällä tavalla itsellesi Digitransit.fi Geocoder, NLS GeoPackage Downloader ja FMI2QGIS lisäosat.

• Huomaa, että Catchment-plugin olisi voitu asentaa myös tällä tavalla

3. Geokoodaa Digitransit.fi-pluginin avulla osoitteet, joista olet kiinnostunut:

• Uuden potentiaalisen asunnon osoite on Mannerheimintie 1

• Asut tällä hetkellä Vallilassa (analyysin tarkkuudeksi riittää asuinalueen keskipiste, sillä mielessäsi ei ole mitään tiettyä asuntoa Vallilassa)
• Aloitat työskentelyn Ilmatieteen laitoksella ensi syksynä

• Säätämällä minimaalista hyväksyttävää luotettavuustasoa voidaan kontrolloida miten suurilta osin näytettävien tulosten tulee olla yhteensopivia hakukentän syötteen kanssa

4. Selvitä Catchment-pluginin avulla mitkä alueet voit tavoittaa vartin pyöräilyllä sekä potentiaalisesta uudesta asunnosta että nykyiseltä asuinalueeltasi. Selvitä myös miten kauas voit ehtiä kävellen 10 minuutissa uudelta työpaikaltasi. Huomaa: videossa näkyvä osoite ei ole enää toiminnassa. Suomen OpenStreetMap-tieaineiston voit saada käyttöösi joko ottamalla yhteyttä meihin info@gispo.fi tai pystyttämällä Docker-kontin GitHub-ohjeiden mukaan.

5. Lataa NLS GeoPackage Downloader -pluginin avulla QGISiin ongelmamme kannalta relevantit maastotietokanta-aineistot (kansallispuistot, puistot, retkeilyalueet ja urheilu- ja virkistysalueet). Tarkastele ennen latauksen aloittamista minkä UTM karttalehtien alueelle Catchment-pluginin avulla määritetyt saavutettavuusalueet ulottuvat, jotta voit minimoida ladattavan aineiston määrän.

• Ladataan tässä vaiheessa MMLn ainestosta myös merialueet, jotta saadaan myöhemmin suoritettavat pinta-ala-analyysit toteutettua realistisesti

• Huomaa, että tutkimusalueemme ei sisällä yhtään kansallispuistoa tai retkeilyaluetta

6. Navigoi Vector → Geoprocessing Tools → Union ja luo uusi karttataso, joka sisältää sekä puistoja että urheilu- ja virkistysalueita kuvaavat polygonit.

7. Navigoi Vector → Geoprocessing Tools → Clip ja leikkaa vaiheessa 6 tuotettua yhdistelmätasoa vaiheessa 4 tuotetuilla saavutettavuusalueilla. Nimeä tuloskarttatasot uudelleen, jotta pystyt erottamaan ne toisistaan jatkossakin.

8. Luo vaiheessa 7 tuotettuihin karttatasoihin uusi polygonin pinta-alatiedon sisältävä sarake. Polygonin pinta-alan saat laskettua kaavalla $area.

9. Navigoi Processing → Toolbox → Basic Statistics for Fields ja analysoi vaiheessa 8 luotua pinta-ala-saraketta. Tällä tavoin saat selville mm. montako puisto tai urheilu-/virkistysaluetta kukin saavutettavuusalue pitää sisällään. Tuotetuista tilastoista saat selville myös saavutettavuusalueiden sisältämien viheralueiden kokonaispinta-alan.

• Vaihtoehtoisesti voit tarkastella saavutettavuusalueiden välisiä eroja karttapohjalla. Karttapohjalta näkee kivasti miten saavutettavuusalueet menevät osittain päällekkäin. Tämä tieto voi olla tarpeellinen, jos mielessäsi on vaikka jokin tietty lempipuisto tai seurajoukkueesi kotikenttä, jonka sisältyminen saavutettavuusalueelle on erityisen tärkeää

10. Pinta-alatietoa voidaan hyödyntää myös laskemalla puisto ja urheilu- ja virkistyalueiden pinta-ala prosentteina saavutettavuusalueiden pinta-alasta. Mikäli latasit merialueet NLS pluginilla jo vaiheessa 5, voit siirtyä suoraan leikkamaan merialueet sisältävää karttatasoa saavuttetavuusalue-karttatasoilla. Jokaiselle tuloksena saadulle saavutettavuusalueen X merialueet sisältävälle karttatasolle navigoi Vector → Geoprocessing Tools → Dissolve.

• Dissolve-prosessi yhdistää kaikki saavutettavuusalueen merialueet yhdeksi polygoniksi ja mahdollistaa merialueiden pinta-alan selvittämisen napauttamalla info-työkalulla ko. polygonia (Derived-osio → Area)

Viheralueiden prosentuaalinen osuus saavutettavuusalueiden pinta-alasta:

Ilmatieteen laitos: 147332,55 / (1237586,49 – 0) = 0,119
Mannerheimintie 1: 2279067,75 / (27308189,33 – 7360203,73) = 0,114
Vallila: 2324743,47 / (30265091,38 – 4700377,86) = 0,091

• Huomaa, että myös yksittäisten saavutettavuusalueiden pinta-alat saa helposti selville info-työkalun avulla (ja valitsemalla oikean saavutusalueen karttatason aktiiviseksi Layers-paneelissa)

Prosentuaalisten viheralueiden peitto-osuuksien laskeminen kannatti, sillä niistä käy ilmi, että vaikka Vallilan alueella on neliömetreinä mitattuna enemmän viheralueita, silti Mannerheimintie 1sen lähistössä on yli kaksi prosenttiyksikköä enemmän viheralueita tarjolla suhteutettuna 15 minuutin pyörämatkan määrittämän saavutettavuusalueen pinta-alaan.

BONUS! Navigoi Plugins → FMI2QGIS → Add WFS Layer ja tarkastele lähes reaaliaikaisesti 20 metrin resoluutioisena Helsingin metropolialueelta saatavilla olevaa ENFUSER ilmanlaatudataa (tarkemmin sanottuna ladataan ilmanlaatua kuvaavan indeksin arvot ja typpioksidikonsentraatiotiedot). Ennen FMI2QGIS-pluginin käyttöä kannattaa navigoida Vector → Geoprocessing Tools → Dissolve ja sulauttaa yhteen Mannerheimintien ja Vallilan saavutettavuusalueet, sillä tästä tuloskarttatasosta saamme kätevästi tutkimusalueen rajat. Jotta pystyisimme silmämääräisesti vertailemaan potentiaalisen uuden asuinpaikan ja nykyisen asuinalueen välisiä ilmanlaatueroja, muokataan myös hieman saavutettavuusalueiden visualisointityylejä.

• Huomaa, että FMI2QGISin käynnistäminen aktivoi automaattisesti Temporal Controllerin. Tämä on luontevaa, sillä ilmanlaatudata on luonteeltaan paitsi spatiaalista myös temporaalista. Temporal Controller mahdollistaa tilanteen kehittymisen tarkastelun ajan suhteen ja paljastaa mm. merkittävät erot yö- ja päiväajan välillä.

• Huomaa, että video on kuvattu 23.6.2021 noin klo 13.30, joten ENFUSER-aineisto sisältää paitsi lähihistoriatietoja myös ennustuksen tilanteen kehittymisestä

Yhteenvetona voitaisiin sanoa, että tekemämme analyysin perusteella muuttoa Mannerheimintielle kannattaisi harkita. Mannerheimintien saavutettavuusalue sisälsi prosentuaalisesti Vallilan saavutettavuusaluetta enemmän puistoja ja urheilu- ja virkistysalueita. Lisäksi silmämääräisesti arvioituna siellä saattaisi olla hieman parempi ilmanlaatu. Jälkimmäinen väite perustuu siihen, että viimeisimmästä videosta käy selkeästi ilmi miten ilmanlaatu on heikoimmillaan isojen teiden läheisyydessä; ja Vallilan saavutettavuusalue näyttäisi sisältävän enemmän tällaisia valtaväyliä. Mikäli tälle havainnolle haluaa saada validaatiota, voi harkita tieaineiston lataamista NLS GeoPackage Downloaderilla ja jatkaa analysointia omin päin!

• Määrittelyn kautta prosessit ja datatarpeet selville
• Maamassarekisteri
• PostGIS taustalla
• Jätteenkuljetusrekisteri
• QGIS käyttäjien keskiössä ja tiedost siistiksi
• Retkeily- ja ulkoliikuntatiedot

QGIS on alkanut muodostua välineeksi, jolla voi tehdä melkein mitä vain. Se toimii usein käyttäjien väylänä monimutkaisiin tietorakenteisiin sen lisäksi, että sillä voidaan analysoida ja visualisoida paikkatietoaineistoja. PostGIS puolestaan hanskaa isot datamassat, relaatiot, käyttäjänhallinnan ja historiatiedot.

Etenkin Tampereen kaupungin kanssa tekeillä olevissa hankkeissa QGIS on kuitenkin käyttäjäkokemuksen keskiössä ja taustalla tietokannoissa pyörivistä tietovirroista ei tarvitse loppukäyttäjän välttämättä välittää ollenkaan. 

Viimeisen vuoden aikana Tampereen kaupungin kanssa on ollut meneillään useita mielenkiintoisia projekteja, joissa on ollut sama ydinidea:

1. Paikkatiedot pitää saada tietorakenteeltaan eheäksi ja tallennettua paikkatietokantaan (PostGIS)
2. Paikkatietoja pitää voida tutkia ja päivittää paikkatieto-ohjelmistolla (QGIS)

Määrittelyn kautta prosessit ja datatarpeet selville

Tampereen kanssa (kuten muidenkin asiakkaidemme projekteissa) ongelman työstäminen lähtee nykytilan analyysistä sekä tulevaisuuden toiveiden ja tarpeiden määrittelystä: mikä on prosessi nyt, mikä nykytilanteessa on hyvää tai huonoa, mitä halutaan, mitkä ovat käyttäjien tarpeet? Usein määrittelyvaiheessa työpajaillaan tai haastatellaan sidosryhmiä. Olennaisena osana tietojärjestelmäsuunnittelua on myös prosessien kuvaus ja käsittemallien teko. Joku voisi kutsua tätä määrittelyvaihetta myös palvelumuotoiluksi!

Vaikka Tampereen kanssa viime aikoina työstetyt hankkeet ovat teemaltaan hyvin erilaisia, teknisestä näkökulmasta perustilanne on yllättävän samankaltainen: 

1. Tietoja saadaan eri lähteistä
2. Tiedot halutaan yhdistää
3. Tietoja halutaan analysoida ja tutkia
4. Tiedoista halutaan jalostaa uutta tietoa

Maamassarekisteri

Maamassojen kuljetuksista ja varastoinnista aiheutuu vuosittain miljoonien eurojen kustannuksia sekä hiilidioksidipäästöjä. Kun maamassavarastojen tilannetieto ja työmaiden tuottamat maamassamäärät sekä tarpeet ovat näkyvissä samalla karttapohjalla, voidaan kuljetuksia ohjata paremmin ja kustannustehokkaammin.

Tällä hetkellä toteutamme Tampereelle Maamassatietovarantoa, jossa QGISille toteutetaan työtila tietojen hallintaa ja tarkastelua varten. Taustalla pyörii PostGIS-kanta.

“Kehitettävän maamassarekisterin avulla saadaan koostettua tietoja pitkällä ja lyhyemmällä aikavälillä kaupungin eri yksiköiden toiminnassa syntyvistä, käytettävissä olevista ja tarvittavista materiaalivirroista. Maa-ainesten hallinnan kannalta kokonaiskuvan syntyminen eri toiminnoista mahdollisimman hyvissä ajoin auttaa toiminnan suunnittelua, auttaa tunnistamaan selvitettäviä asioita ja mahdollistaa vaiheistamista ja aikatauluttamista entistä paremmin.”

Matti Pokkinen, maamassakoordinaattori, Tampereen kaupunki

PostGIS taustalla

Kaikissa näissä tapauksissa tiedot eivät ole pelkästään yhteen tauluun mahtuvia rekistereitä, vaan pisteisiin, viivoihin ja alueisiin liittyvää monipuolista dataa.

Lisätiedot voivat olla toimenpiteitä (esim. työmaalta maamassojen vienti, luistelukentän auraus, jäteastian tyhjennys), luokitteluja (retkeilykategoria, jäteastian koko ja tyyppi) tai erilaisia rooleja erityyppisille datan käsittelijöille (pääkäyttäjä, editoija, katselija).

PostgreSQL:n spatiaalilisäsosan PostGISin avulla voidaan rakentaa suhteellisen nopeasti moniulotteisia relaatiotietokantoja, joiden tarkasteluun, analysointiin ja päivittämiseen tarvitaan hieman enemmänkin PostGIS- ja SQL-osaamista. Monissa hankkeissa paikkatietoaineistoja tarkastelee ja käsittelee käyttäjiä eri taustoista ja siiloista, joiden tietokantaosaaminen voi olla vaihtelevaa. Tästä syystä käyttäjäkokemuksen keskiössä on usein QGISin, jonne voidaan rakentaa valmiita näkymiä tietokannassa olevaan tietoon.

Jätteenkuljetusrekisteri

Jätehuoltoviranomaisen pitää jätelain mukaan seurata mm. kotitalouksien jätteiden kuljetuksissa siirrettyjen jätelajien määriä ja loppusijoitusta. Oleellista on myös ympäristön takia havainnoida, jos jokin taho ei ole liittynyt syystä tai toisesta jätteenkuljetuksen piiriin. Syitä tähän ovat esimerkiksi poikkeamisluvat tai kohde on asumaton, mutta joissain tapauksissa voi paljastua myös ympäristörikoksia.

Kun liittyneet kotitaloudet saadaan kartalle, voidaan helposti havaita myös ne tahot, jotka eivät ole liittyneet jätehuoltoon. Jätehuoltoviranomaiselle toteutetetaan parhaillaan jätteenkuljetusrekisteriä tietojen seurantaa varten. Siinä isossa roolissa on PostGIS-tietokantaan vietävät tiedot ja niiden seuranta QGIS-työkalulla. Jätteenkuljetusrekisterin tuottamisessa haastavinta on ollut kääntää monitahoinen jätelakivelvotteiden, arkisten jätekuljetuksien ja jätehuoltoviranomaistehtävien maailma tietomalliksi.

“Jätehuoltoviranomaisen toimialue kattaa 17 Pirkanmaan kuntaa, joten päivittäisessä työssä joudutaan hallitsemaan suuria tietomassoja, paikkatiedon hyödyntäminen on kuitenkin ollut vasta alkutekijöissään. Kehitettävän jätteenkuljetusrekisterin avulla pystytään aiempaa tehokkaammin seuraamaan, että kiinteistöjen jätehuolto on järjestetty asianmukaisella tavalla. Näin varmistetaan, ettei ympäristö- tai terveyshaittoja aiheudu puutteellisesta jätehuollosta. QGIS-ratkaisuun pohjautuva rekisteri mahdollistaa myös aiempaa sujuvammat viranomaisprosessit, kun yksittäisten kiinteistöjen tarkastelusta pystytään siirtymään kohti laajempia kokonaisuuksia.”

Anu Toppila, jätehuoltoinsinööri, Tampereen kaupunki

QGIS käyttäjien keskiössä ja tiedot siistiksi

QGISin attribuuttilomakkeiden avulla voidaan rakentaa tiedon päivitykseen näppäriä apuvälineitä tai QGIS-työtilaan voidaan hakea valmiita kyselyitä tietokannasta. Samaa problematiikkaa on hahmoteltu Tampereen kanssa mm. jätteenkuljetusrekisterissä, maamassoissa, kiinteistönmuodostuksessa ja retkeily- ja ulkoiliikuntapaikkojen hallinnassa.

Tähän mennessä useimmiten kaikki kulminoituu siihen, että lähtötietojen pitää olla kunnossa, jotta voidaan tuottaa hyviä palveluita käyttäjille. Datan laatua pitääkin matkan varrella parantaa ja jalostaa. Datan puutteellisuus pitää myös sallia ja tehdä toimenpidesuunnitelmat sen parantamiseksi pikkuhiljaa.

Useimmiten laatuongelmat havaitaan vasta, kun tiedot nähdään kartalla. Tässä helppona vinkkinä ennen varsinaisen mobiilisovelluksen tai web-karttojen toteuttamista on laittaa olemassa olevat datat QGISiin ja tutkia niitä sitä kautta. Datan laatua voidaan arvioida nopeasti jo tässä vaiheessa ja voidaan kokeilla miltä mahdollinen kuntalaisen tai loppukäyttäjän sovellus voisi tuntua. Yleensä käyttäjät havaitsevatkin nopeasti, että “tuolta puuttuu reitti tai kohde” tai  “tuolla on kiinteistöjä, joilla ei ole jostain syystä jätehuoltorekisterissä liittymää”. Ja sitten dataa korjataan tai selvitetään mistä asia johtuu.

Retkeily- ja ulkoliikuntatiedot

Lähimatkailu on koko ajan lisännyt suosiotaan. Jotta retkeilijät eivät ruuhkauttaisi suosituimpia reittejä, tarpeena on esitellä muitakin kohteita. Tiedot ovat kuitenkin todella hajallaan. Onneksi retkeily- ja ulkoilutietoja kerätään jo laajalti Jyväskylän yliopiston ylläpitämään LIPAS-aineistoon (liikuntapaikkarekisteri). Matkailijaa voi kiinnostaa myös muut tiedot kuten mistä löytyy parkkipaikka, mitä nähtävyyksiä alueella on tai missä kunnossa kohteet ovat, kuten milloin luistelukentät on huollettu tai latu ajettu. Koostetietokanta PostGISissä ja sieltä rajapintojen tuottaminen eteenpäin mahdollistaa tietojen hyödyntämisen useissa eri palveluissa.

“Tampereen kaupungin retkeily ja ulkoliikunnan palvelut löytyvät useista eri sijainneista. Kaupunkiseudun kuntien palvelut sitäkin useammasta sijainnista. Käytännössä tämä näkyy latutietojen tai retkeilyreittien loppumisena kuntarajalle ja samojen tietojen esittämisenä eri tavoin eri kunnissa. Kaupunkiseudun kuntien Lipas-järjestelmän kautta tiedot voidaan esittää kuitenkin yhtenäisesti, samalla alustalla ja siten, että jokainen kunta vastaa silti oman aineistonsa ajantasaisuudesta.

Samalla käyttäjälle on mahdollista tuottaa ylikunnallista lisäarvoa esimerkiksi bussipysäkkien tai latutietojen kautta. Käyttäjän kannalta tämä on merkittävä askel kohti parempaa toiminnallisuutta, edistää turvallisuutta ja mahdollistaa kuntien tehokkaan viestinnän retkeily- ja ulkoliikkumisen saralla ja enne kaikkea edistää metsien hyvinvointi- ja terveysvaikutusten hyödyntämistä.”

Anne Tuominen, metsätalouspäällikkö, Tampereen kaupunki
Petri Mäkelä, retkeily- ja luontopalvelut, Ekokumppanit Oy

Mitkä ihmeen Folkoot? FOSS4G + talkoot = Folkoot!

Avoin lähdekoodi on Gispon liiketoiminnan kovaa ydintä. Olemme jo aiemminkin tukeneet yhteisöä monella eri tavalla. Sponsoroimme projekteja ja tapahtumia suoraan rahallisesti ja jaamme kaikki asiakasprojekteissa tehdyt tuotokset avoimesti aina kun se on mahdollista. Avoimen lähdekoodin kentällä kuitenkin voi helposti käydä niin, että ottaa enemmän kuin antaa ja me haluamme ehdottomasti olla siellä antavalla puolella. Siksi haluamme entistä organisoidummin kontribuoida meille keskeisiin projekteihin myös ns. normaalin työpanoksen lisäksi. 

Ajatuksena on tehdä paremmin näkyväksi se panostus, jonka näille projekteille tarjoamme. Itsellemme ja myös muille. Folkoo-hengessä gispolaiset voivat allokoida viisi prosenttia kokonaistyöajastaan avoimen lähdekoodin projekeihin kontribuoimiseen. Tämä saattaa kuulostaa vähältä ajallisesti, mutta kun tälle laitetaan hintalappu, se kuulostaakin aika mahtavalta panostukselta. Nykyisellä työntekijämäärällämme tämä tarkoittaisi konsultointityön hinnoittelulla pitkälle  yli 100 000 euron panostusta vuosittain. Mittasuhteita tälle antaa esimerkiksi se, että QGIS-projektin korkein Flagship-sponsoritaso on vuosittain 27 000 € hintainen. 

Yhteisön osana voi olla monella tavalla

Helteisenä kesäkuun perjantaina lähdimme toteuttamaan ensimmäisiä sisäistä Folkoot-tapahtumaamme. Aloitimme päivän yhteisellä alustuksella, jossa kävimme läpi muutamia tapoja kontribuoida päivän aikana. Osalla oli jo oma miniprojekti mielessä tai issue ratkottavana, mutta yhdessä kävimme läpi eri tapoja osallistua ja mietimme kaikille sopivaa tekemistä. 

Yksi esimerkki matalan kynnyksen kontribuutiosta on muiden avaamien issueiden replikointi ja testaaminen. Käytännössä siis joku käyttäjä on huomannut esimerkiksi ohjelmistossa virheen ja kirjannut sen kehittäjille korjattavaksi. Testaamalla ja validoimalla näitä ongelmia, voidaan testaajille antaa lisätietoja mahdollisesta ongelmasta ja varsinainen korjaus helpottuu huomattavasti. Kaikki jotka osaavat käyttää ohjelmistoa ja pystyvät seuraamaan ohjeita voivatsiis tällä tavalla tuoda oman panoksensa pöytään vaikka C++:lla ohjelmointi tai binäärikirjastojen kääntäminen ei olisikaan omaa juttua. Myös dokumentaation kirjoitus ja käännöstyö ovat arvokkaita töitä joihin kaikki pystyvät osallistumaan. Tietysti varsinainen ohjelmistokehitys ja esimerkiksi bugien korjaaminen on erittäin arvokas panos ja se on myös keskeinen osa Gispon Folkoot-filosofiaa. 

Yhden työpäivän aikana saatiin todella paljon aikaan. Useita QGISin tikettejä suljettiin, myös muutamia uusia issueita avattiin, mutta niiden syntyjä lähdettiin myös etsimään lähdekoodista. StackExchangessa vastailtiin useisiin kysymyksiin, QGIS-projektia käännettiin suomeksi ja tekipä Mikael myös pull requestin pygeoapiin. Avoimen lähdekoodin lisäksi toimintamme ytimessä on avoin data ja erityisesti OpenStreetMap, joten Folkoot soveltuivat hyvin myös HOT-OSM:n digitointiin. Muutama Gispon kehittäjä ratkoi bugeja parityöskentelynä, joka on erityisen hyvä menetelmä osaamisen jakamisessa ja ongelmien ratkomisessa. 

Folkoohenkeä myös jatkossa

Päivän päätteeksi kävimme läpi miten kukin oli aikansa käyttänyt ja mitä oli saanut aikaan. Kollegoiden omatoimisuus ja aktiivisuus oli jo ennestään tiedossa, mutta silti se ylitti odotukset ja oli mahtavaa seurattavaa. Tärkeänä lopputuloksena tunnistimme yhdessä kuinka tällä tavalla pystyttiin madaltamaan kynnystä kontribuoida suoraan projekteihin. Yhteisöt ovat aidosti avoimia ja jos me emme niitä issueita avaa ja sulje, niin kukas sitten? Analogia perinteisiin talkoisiin tuntui toimivan myös oikein hyvin: kaikki tekivät sen mitä osasivat ja toivat pöytään oman panoksensa.  

Folkoot palvelivat tarkoitustaan erinomaisesti ja kuukausittainen talkoopäivä jää pysyväksi osaksi työskentelyä Gispolla. Haluankin haastaa muut alan toimijat mukaan folkoilemaan! Olet sitten töissä paikkatietoalan konsulttitoimistossa tai julkisen sektorin organisaatiossa, konsepti on siirrettävissä kaikkialle. Sen lisäksi, että tällä tavalla voi tarjota panoksensa avoimen lähdekoodin projekteille, oppii siinä sivussa myös paljon uutta lyhyessäkin ajassa. Kirsikkana kakun päällä, on yhdessä kehittäminen ja ongelmien ratkominen myös hauskaa. 

Aiemmin kirjoitimme, että Gispo on osallistunut HSL:n uuden Reittioppaan kehittämiseen ja samassa yhteydessä mainitsimme, että työtä on vielä tehtävä, jotta sovellus olisi erityisryhmille, kuten näkövammaisille ja liikuntarajoitteisille, sopiva. HSL onkin tehnyt ja tekee edelleen työtä Reittioppaan ja monien muiden, kuten Mobiililippu-sovelluksen, esteettömyyden parantamiseksi. HSL mm. tilasi keväällä Annanpuralta näkövammaisille suunnatut käytettävyystutkimukset Mobiililippu- ja Reittiopas-sovelluksille ja tutkimuksien tulokset ovat juuri valmistuneet tai valmistumassa. Myös Gispo oli toukokuussa mukana HSL:n esteettömyystyössä.

OPENSTREETMAP JA ESTEETTÖMYYS

Gispo selvitti toukokuussa muun työn ohella erityisesti OpenStreetMapin osalta miten Reittiopasta voitaisiin parantaa erilaisten erityisryhmien näkökulmasta. Tuloksena työstä syntyivät yhteenvetokalvot sekä wiki-sivu, joista muun muassa selviää, että OpenStreetMapiin voi lisätä vaikkapa hissejä wheelchair=yes -tagien kera, ramp=yes -tageja erilaisten luiskien merkitsemiseen tai traffic_signals:sound=yes -tageja äänimerkillisille liikennevaloille.

HSL jatkaa esteettömyystyötä sovellustensa parissa ja myös Gispo toivottaa erittäin tervetulleiksi kaikki OpenStreetMapin esteettömyyteen liittyvät näkemykset ja ideat.

Älypuhelimen karttasovelluksen avulla löydämme helposti reitin vieraaseen paikkaan tai lähimmän huoltoaseman uudella seudulla. Paikkatieto on kuitenkin paljon muutakin kuin navigointia. Paikkaan sidotun tilasto- tai havaintoaineiston analysoimisesta on hyötyä kaikilla aloilla. Yritykset keräävät dataa asiakkaistaan, hallinnoivat projektejaan ja omaisuuttaan tai seuraavat toteutumaa ja suunnittelevat tulevaa. Kaikessa tässä paikkaulottuvuuden mukaan ottaminen tehostaa analyyseja ja voi paljastaa uusiakin asioita. 

Tilannekuva kertoo, mitä, missä ja milloin tapahtuu. Pääpaino on nykyhetkessä: mikä on tilanne juuri nyt? Vuoden kestänyt pandemia on varmasti viimeistään tehnyt tartuntojen tilastoteemakartoista, rokotekattavuuden kehittymisestä ja liikkumisanalyyseista tuttuja meille kaikille. Sama periaate on monissa muissa tilastoissa. Asukkaiden ikä- ja tulorakenne, asuntojen hintojen kehitys, muuttovoitto ja -tappio jne. ovat kaikki sijaintiin sidottua tilastotietoa. Siis paikkatietoa. Gispon asiakkaiden kirjo kuvastaa hyvin paikkatietojen hyötyjen monipuolisuutta: olemme tukeneet eri projekteissamme viime aikoina esimerkiksi ilmanlaatu-, matkailupalvelu-, kaavoitus– ja liikennedatan hyödyntämistä.

Tilannekuva ei kuitenkaan itsessään selitä, miksi jotain tapahtuu. Paikkatietojen monipuolisuus avautuukin kunnolla vasta analysointivaiheessa. Tilastotieteestä tutut menetelmät, esimerkiksi klusterit, regressioanalyysit ja erilaiset luokittelumenetelmät ovat kaikki sovellettavissa paikkatietoihin. Lisäksi käytettävissämme on ihan uusi ulottuvuus: eri aineistojen ja tekijöiden väliset sijainnilliset yhteydet. Vaikka kahdella ilmiöllä ei näyttäisi olevan esimerkiksi ajallisesti mitään yhteyttä, sijaintitarkastelu saatta paljastaa yllättäviäkin riippuvuuksia niiden välillä. 

Jotta eri aineistoja voidaan analysoida yhdessä, täytyy tietolähteiden yhteiskäytön olla sujuvaa. Paikkatieto-ohjelmistolle erilaiset tiedostoformaatit, aluejaot, aikasarjat ja koordinaattijärjestelmät eivät ole ongelma. Monipuolisia, ajantasaisia aineistoja saa rajapinnoista usein avoimesti ja ilmaiseksi. Suomessa esimerkiksi Tilastokeskus, Suomen ympäristökeskus, Kuntaliitto ja yksittäiset kunnat sekä yliopistot ja muut tutkimuslaitokset julkaisevat aineistojaan hyödynnettäväksi avoimesti, myös kaupallisiin tarkoituksiin. Toki tarjolla on muutakin kuin tilastodataa: Maanmittauslaitoksen korkeusmalli, Väyläviraston tietyöt ja kaupunkien kaavoitustiedot ovat vain muutamia esimerkkejä avoimen datan monipuolisuudesta.

Koska analyyseja tehdään aina päätöksentekoa varten, niiden tulosten täytyy olla ihmiselle ymmärrettäviä. Paikkatieto-ohjelmistolla tietokoneen laskemat tunnusluvut voidaan visualisoida helppolukuiseksi, datan tärkeitä piirteitä korostavaksi kartaksi tai infografiikaksi. Kun paikkatietojen tuottama uusi informaatio siirtyy kokoushuoneen kalvoille tai verkkosivun karttapalveluun, sen voima kirkastuu koko organisaatiolle ja se voi tuottaa lisäarvoa. 

Paikkatietoja hyödyntämällä voi optimoida ja tehostaa organisaation toimintoja. Hyvänä esimerkkinä tästä on logistiikka, jossa kuljetusten reittisuunnittelulla voidaan säästää kuljetuskustannuksissa sekä vähentää hiilidioksidipäästöjä. Toinen perinteinen käyttötapaus on esimerkiksi toimipisteen sijaintisuunnittelu – millaisia resursseja toimipiste tarvitsee ja millainen asiakaskunta tai muu toimittajaverkosto läheltä löytyy? Vastaava toteutus julkisella puolella voi olla vaikkapa uuden koulun sijoittaminen sopivalle alueelle huomioiden väestöpohjan tai ambulanssien asemapaikkojen määritys. Kunnossapito ja omaisuudenhallinta on myös tehokasta toteuttaa karttapohjaisesti, jolloin pääkäyttäjät näkevät nopeasti minne huoltotoimenpiteitä pitää kohdentaa. Paikkatietoja voidaan käyttää myös viestinnän ja markkinoinnin välineenä – esimerkiksi houkutella matkailijoita tutustumaan alueen palveluihin.

Jos lähdetään liikenteeseen aivan alkuvaiheesta ja perustetaan vasta organisaation paikkatietojärjestelmiä on hyvä huomioida, että toteutus vaatii aikaa ja osaajien kouluttamista. Täysi hyöty paikkatietojen käytöstä voi näkyä organisaatiossa vasta ajan kuluessa. Siksi kannattaakin lähteä liikenteeseen pienin askelin ja vaikkapa määritellä tärkeimmät haasteet ja miten ne ratkaistaan sekä kouluttaa pääkäyttäjät ja tukea heitä työssään.

Gispolla teemme töitä avoimen lähdekoodin paikkatietoratkaisujen parissa. Niissä hyötynä on pienet aloituskustannukset, koska työkalut ovat testattavissa ja käytettävissä ilmaiseksi. Niitä voi räätälöidä organisaation omiin tarpeisiin, jolloin on kuitenkin huomioitava kehittämisen ja ylläpidon kustannukset. Avoimen lähdekoodin maailmassa tärkeää onkin osata valita oikeat työkalut sekä ymmärtää yhteiskehittämisen potentiaali, joka parhaimmillaan tuo kehitykseen tukea globaalisti. Hyviä esimerkkejä avoimen lähdekoodin työkaluista, jotka ovat monien meidän käytössä ovat mm. Linux- ja  Android-käyttöjärjestelmät, Suomessa kehitetty Reittiopas tai vaikkapa Omaolo-palvelu. Paikkatietopuolella käytetyimpiä työkaluja ovat työpöytäohjelmisto QGIS, tietokantapuolella PostgreSQL/PostGIS ja aineistojen julkaisupuolella GeoServer. Web-karttapalveluita taas on todella monipuolisesti saatavilla eri tarpeisiin.

Gispon paikkatietoasiantuntijat auttavat kaikissa näissä vaiheissa – tiedon etsimisessä, muotoilussa oikeaan formaattiin, tiedon analysoinnissa, raportoinnissa ja visualisoinnissa. Lisäksi koulutamme ja tuemme avoimen lähdekoodin paikkatieto-ohjelmistojen käyttäjiä ja teemme ohjelmistojen kehitystyötä, jotta työskentely sujuu yhä joustavammin.

QField on QGISin kenttätyöhön soveltuva sovellus, joka on ilmaiseksi saatavilla Play-kaupasta Android-laitteille. Se on käytännössä mini-QGIS eli sisältää paljon samoja juttuja kuin QGIS itsekin. Kaikkea ei kuitenkaan mobiililaitteella kannata tehdä, joten QField on nimensä mukaisesti suunniteltu kenttätöiden tekoon. 

Teimme Väyläviraston pyynnöstä testausta kevään 2021 aikana siitä, miten QField soveltuu liikenteenohjauslaitteiden tiedonkeruuseen. Liikenteenohjauslaitteilla tarkoitetaan liikennemerkkejä, liikennevaloja ja ajoratamaalauksia.

“Halusimme selvittää open source -välineiden soveltuvuutta tähän tiedonkeruuseen, jota Väyläviraston ja kuntien tulee nyt tieliikennelain mukaan tehdä”

Matti Pesu, Väylävirasto

Tiedonkeruun taustalla käytettiin Väyläviraston liikenteenohjauslaitteiden (tuttavallisemmin LOL) käsitemallia, jonka pohjalta luotiin ensin tietojen tallennusta varten relaatiotietokanta PostGISiin ja sen avulla tuotettiin QGISin avulla työtila lomakkeineen. Tämä on työnkuvana hyvin samanlainen mitä tällä hetkellä Gispolla muutenkin tehdään: tietojen hallinta PostGISissä, QGIS toimii käyttöliittymänä. Nyt vain vietiin asia askeleen eteenpäin eli kentälle. 

Projektissa testasimme Tampereen infra Oy:n, Nurmeksen, Kouvolan ja Ylöjärven kanssa miten käytännön työ QFieldin ja LOL-tietokannan kanssa toimi. Projektin havainnot on koottu yhteen loppuraporttiin sekä ohjeet QFieldin käyttöön sekä offline moodissa että PostGISin kanssa löytyy Väyläviraston GitHubista. 

Havaintoja LOL-tietomallista ja QFieldistä

LOL-käsitemallia ei oltu aiemmin testattu ns. fyysisen toteutuksen kanssa ja tämä oli ensimmäinen kerta, kun tietoja pystyttiin tallentamaan sen mukaisesti. Tässä QGIS ja PostGIS toimivat hienosti yhteen. Nyt kun työtila QGISille on tehty, voi sitä käyttää myös ilman QFieldiä haluttaessa. 

Itse LOL-tietokanta on hyvin kattava ja liikennemerkkejä on paljon, siksi niiden etsiminen pitkästä listasta oli vähän haastavaa, mutta jos liikennemerkin nimen tiesi, työkalu mahdollisti sen hakemisen listalta. Testaajia mietitytti mm. alueellisuus – porovaroituksia kun ei ihan joka paikasta löydy.

Muutenkin kenttätyöhön koko LOL-tietomalli oli aika laaja. Käytännön työssä varmasti prosessista karsiutuu pois suuri osa tietokentistä ja käyttäjät luultavasti täyttävät kentällä vain pakolliset ja jatkavat tietojen täyttöä lämpimissä ja ilmastoiduissa sisätiloissa. 

Mittatarkkuuslaitteilla saatiin todella tarkkaa sijaintitietoa tallennettua QFieldin avulla ja tietojen tallennus yhteiseen tietokantaan onnistui hyvin. Testaajat suhtautuivat yllättävän positiivisesti sovellukseen, vaikka Gispon paikkatietoväki oli hieman skeptinen miten tässä nyt käy. Lopulta oikein hienosti onnistuttiin kovissa testiolosuhteissa!

Kehitystä ja kehitystoiveita

QFieldiin tehtiin projektissa suomenkielisten osoitteiden haku, kiitos OpenGIS.ch:lle nopeasta työstä! Se hyödyttää nyt kaikkia QFieldin käyttäjiä Suomessa.

QFieldin akilleen kantapää on ollut pitkään se, että sovellukseen pitää erikseen hakea QGISistä paketoitu työtila tiedostona (esim. USB-piuhalla tai nettisivun kulmalta). Tämä aiheuttaa ylimääräisen työprosessin, josta olisi kiva päästä eroon. Tulossa on kuitenkin ratkaisu lähiaikoina QField Cloudin muodossa ja toivottavasti jatketaan sen osalta vielä testailuja.

No toimiiko se?

Loppujen lopuksi voimme hyvillä mielin suositella QFieldiä kenttätöiden tekoon.

Liikenteenohjausmerkkien osalta työkalua kannattaa käyttää tietojen ylläpitoon, ehkä ihan alusta asti 10 000 liikennemerkin keruu kännykällä voi olla aikamoinen urakka. Mutta jos tarpeena on päivittää tietoja, siihen QField toimii hyvin. 

QFieldiä voisimme suositella mihin tahansa kenttätöihin. QGISin avulla valmiit lomakkeet saa todella näppärästi tehtyä eri tarpeisiin. Kunhan QField Cloud tulee, vain taivas on rajana!

Tässä blogisarjan toisessa osassa tarkastellaan avoimen lähdekoodin työkaluja joiden avulla minimaalisen kustannuksen tuottavaa polkua voidaan lähteä etsimään. Blogisarjan edellisessä osassa käsiteltiin aiheeseen liittyvää teoriaa.

Periaatteessa minimikustannuspolun määrittämiseen ei vaadita paikkatieto-ohjelmistoja. Tämä väite on kuitenkin totta oikeastaan vain sellaisissa tilanteissa, joissa käyttäjä saa kustannuspinnan valmiina tai haluaa tarkastella ongelmaa hyvin pitkälle abstrahoidun maailman kautta. Mikäli käyttäjä haluaa käyttää analyysinsa pohjana todellista karttapohjaa tai maastomalleja, QGIS:in kaltainen avoimen lähdekoodin paikkatieto-ohjelmisto on ensiarvoisen tärkeä työkalu kustannuspinnan muodostuksessa. Tämän blogin työkaluvertailussa oletuksena on, että kustannuspintarasteri on jo muodostettu ja tavoitteena on löytää optimaalinen reitti liikkua pitkin tätä rasteripintaa.

QGIS lisäosa Least-Cost path

QGISin lisäosavalikoimasta löytyy ratkaisu useimpiin yleisiin paikkatietohaasteisiin. Sama pätee myös pienimmän kustannuksen tuottavan polun etsimiseen. Paitsi että QGISillä voi tehokkaasti muodostaa varsinaisen kustannuspinnan, edellisessä blogissa kuvatut työvaiheet 2 ja 3 voi myös hoitaa QGIS:n avulla asentamalla QGIS:iin ongelman ratkaisemiseen soveltuvan laajennuksen (Plugins – Manage and Install Plugins – Least-Cost Path).

Laajennuksen käyttö on hyvin yksinkertaista. Laajennukselle annetaan syötteenä kustannuspinta (rasterimuotoisena) sekä aloitus- ja päätepisteet (vektorimuotoisena). Halutessaan voi määrittää tulostiedoston nimen ja valita mihin polkuun tulostiedosto tullaan tallentamaan. Käyttäjä voi myös vaikuttaa hieman laajennuksen toimintalogiikkaan mikäli hän on etsimässä minimikustannuspolkua useasta mahdollisesta päätepisteestä koostuvaan ongelmaan.

+ Helppo käytettävyys
+ Pystyy käsittelemään syötetiedot oletusmuotoisina
+ Tuottaa ratkaisun selkeässä ja havainnollistavassa muodossa
– Hitaus (algoritmin suorittamiseen kuluu 5-10 min koneen tehosta riippuen)

WhiteBox tools: komentorivityökalu rasterianalyyseihin

WhiteboxTools on MIT-lisenssillä varustettu kokoelma analyysityökaluja ja on kehitetty alkujaan Guelphin yliopistossa Kanadassa. WhiteboxTools on komentorivipohjainen hyvin laaja työkalukirjasto, jonka voi asentaa omalle koneelleen standalone asennuksena (binääritiedostot yleisimmille käyttöjärjestelmille löytyvät osoitteesta, mutta myös lähdekoodista asentaminen on mahdollista). Työkalun voi asentaa myös Docker imagesta ja algoritmeja on mahdollista hyödyntää myös QGIS-lisäosan kautta. Kannattaa kuitenkin huomioida, että QGIS-lisäosan ylläpito on lakkautettu ja resurssit on kohdennettu komentorivipohjaisen työkalukirjaston kehittämiseen.

Asennuksen jälkeen  työkalua Whitebox Tools toimii suoraan komentorivin kautta seuraavasti:

1. Kustannusetäisyystiedon tuottaminen

.\whitebox_tools.exe --run=”CostDistance” -v --wd=”path_to_input_data_folder” --source=”start_point.tif” --cost=”cost_rast.tif” --out_accum=”acc_cost.tif” --out_backlink=”back.tif”

2. Pienimmän kustannuksen tuottavan polun etsiminen

.\whitebox_tools.exe --run=”CostPathway” --wd=”path_to_input_data_folder” --destination=”points.tif” --backlink=”back.tif” --output=”path.tif” -v

tai kirjoittamalla yksinkertaisen python-ohjelman ja suorittamalla sen (tallenna skripti samaan kansioon whitebox_tools.exe tiedoston kanssa):

import os
import sys
from whitebox_tools import WhiteboxTools
 
wbt = WhiteboxTools()
 
# Aseta polku syöte- ja tulostetiedostot sisältävään kansioon
wbt.work_dir = os.path.dirname(os.path.abs_path(__file__)) + “\\testdata\\”
 
# Kustannusetäisyystieto
wbt.cost_distance(start_point.tif, cost_rast.tif, acc_cost.tif, back.tif)
 
# Pienimmän kustannuksen tuottava polku
wbt.cost_pathway(points.tif, back.tif, path.tif)

WhiteboxTools määrittää minimikustannuksen tuottavan polun kahdessa osassa. Luonnollinen seuraus tästä on se, että käyttäjä saa tällöin enemmän informaatiota tutkittavasta ilmiöstä. WhiteboxToolseja käyttämällä käyttäjä ei saa tulokseksi pelkkää vektorimutoista ratkaisupolkua vaan myös rasterimuotoiset tiedostot siitä, miten kerrytetty kustannus muuttuu tutkittavassa avaruudessa (acc_cost.tif) ja mistä suunnasta löytyy kunkin ruudun pienimmän kerrytetyn kustannuksen omaava naapuriruutu (back.tif). 

Suurin ongelma WhiteboxToolsin algoritmeissa on, että ne eivät osaa käsitellä vektorimuotoista tietoa. Tämä puute vaikuttaa sekä siihen, miten paljon esikäsittelyä syöteaineistot vaativat että siihen, miten havainnollistavassa muodossa ratkaisu saadaan tuotettua. Kuitenkin, jos puutteen tiedostaa, siihen voi reagoida jo ratkaisuprosessin alkuvaiheessa tuottamalla esimerkiksi QGIS:n avulla kustannusrasterin ohessa myös toisen, dimensioiltaan kustannusrasteria vastaavan ruudukon, jonka ainoat nollasta eroavat ruudut ovat päätepisteet sisältävät ruudut (aloitusruudun / aloitus- ja päätepisteruudun arvoksi voi asettaa minkä tahansa positiivisen vakion).

+ Huomattavasti tehokkaampi kuin QGIS-laajennus
+ Tuottaa paljon relevanttia kustannusetäisyysanalyysitietoa
– Tuki vektoritasojen käsittelyyn puuttuu
– Komentorivipohjainen (riippuu mistä tykkää)

GRASS: vanhassa vara parempi

GRASS on alkujaan jo vuonna 1984(!) kehitetty työkalu spatiaaliseen analyysiin. Se on kuitenkin edelleen aktiivisessa käytössä ja kehityksessä erityisesti tiedeyhteisössä. GRASS GIS on monipuolinen rasteri- ja vektoritiedostomuotojen analysointiin soveltuva ohjelmisto. 

GRASS tarjoaa vaihtoehdon kahden edellisen ratkaisun välimaastoon sijoittuvan vaihtoehdon. GRASS:n suurin vahvuus verrattuna edellä esiteltyihin lähestymistapoihin on se, että se on paitsi erittäin tehokas ja toimiva, myös huomattavasti WhiteboxToolseja käyttäjäystävällisempi. GRASS GIS on yksi QGIS:n ydinlaajennuksista ja sen voi käydä aktivoimassa QGIS:n asetuksista (Settings – Options – Processing – Providers) tai asentaa Plugin Managerin avulla. GRASS GIS:llä on sekä komentotulkkipohjainen että graafinen käyttöliittymä. Minimikustannuspolku saadaan määritettyä molemmilla tavoilla yhtä tehokkaasti.

Hyödyntämällä GRASSin omaa komentoriviä

1. Luo GRASS Mapset (linkki)

2. Vie tarvittava data Grass Mapsettiin syöttämällä GRASS Shelliin

r.in.gdal input=path_to_data/cost_rast.tif output=cost_rast2.tif

v.in.ogr input=path_to_data/start_point.gpkg output=start_point2

v.in.ogr input=path_to_data/end_point.gpkg output=end_point2

3. Suorita kustannusetäisyysanalyysi syöttämällä GRASS Shelliin

r.cost input=cost_rast2 output=acc_cost2 outdir=back2 start_coordinates=x1,y1 stop_coordinates=x2,y2

• start_coordinates=x1,y1 stop_coordinates=x2,y2 tilalle voi laittaa start_points=start_point2 stop_points=end_point2

4. Etsi pienimmän kustannuksen tuottava polku

r.path input=back2 format=degree vector_path=path2 start_coordinates=x1,y1,x2,y2

• start_coordinates=x1,y1,x2,y2 tilalle voi laittaa start_points=start_point2,end_point2

Huomaa, että tieto polun päätepisteistä voidaan antaa koordinaattimuotoisen tiedon lisäksi yhtä hyvin myös rasterimuotoisina karttatasoina (tällöin start_points avainsanan tilalla tulee vain olla start_raster). Myös tulospolun voi tallentaa halutessaan rasterimuotoisena (avainsananana toimii tällöin raster_path).

Hyödyntämällä GRASSin moduuleja

1. Suorita kustannusetäisyysanalyysi

• Processing Toolbox – GRASS – Raster – r.cost
• Mahdollisuus asettaa ylärajan sallitulle kustannukselle (mikäli käyttäjä ei halua määrittää polun päättymispistettä, tulos kertoo minne asti tietyllä resurssilla voi kuhunkin suuntaan edetä)
• Mahdollisuus kontrolloida prosessin suorittamiseen allokoitavan muistin määrää
• Tuottaa kolme tulostiedostoa (kerrytetyt kustannukset, suuntatieto pienimmän kerrytetyn kustannuksen naapuriruutuun ja tieto kustannusten kohdentamisesta)

2. Etsi pienimmän kustannuksen tuottava polku

• Processing Toolbox – GRASS – Raster – r.drain
• Syöteaineistoina toimivat edellisessä vaiheessa ajetun r.cost algoritmin tulostiedostot ja tieto polun päätepisteistä (vähintään aloituspiste tulee antaa syötteenä, mutta myös molemmat on mahdollista antaa, kunhan nämä pisteet sisältyvät samaan karttatasoon)
• Mahdollisuus laskea erinäisiä tunnuslukuja (esimerkiksi polun kokonaiskustannus)
• Tuottaa kaksi tulostiedostoa (ratkaisupolku rasterimutoisena ja vektorimuotoisena)

Huomaa, että vaikka GRASS komentorivin kautta käskyt toimivat millä tahansa QGIS versiolla, niin moduulien kanssa kannattaa käyttää LTR-versiota (esim. QGIS 3.14).

+ Erittäin tehokas (algoritmit menevät läpi sekunneissa)
+ Tuottaa paljon relevanttia kustannusetäisyysanalyysitietoa
+ Tuki niin vektori- kuin rasterimuotoisellekin tiedolle
+ Valittavissa komentorivipohjainen lähestymiskulma tai graafinen käyttöliittymä (ainut eroavaisuus on siinä, että r.path algoritmia ei ole implementoitu graafisen käyttöliittymän työkaluksi, mutta r.drain algoritmilla saa saman asian selville)
– GRASS Mapsetin käyttö, jos halutaan ajaa käskyjä komentorivin kautta

Muut työkaluvaihtoehdot

Myös SAGA tarjoaa minimikustannuspolun määrittämiseen soveltuvia algoritmeja (Accumulated cost, Least cost paths), mutta nämä algorit kärsivät niin vakavista suorituskykyongelmista, ettei niiden avulla pystynyt ratkaisemaan tässä blogissa käsiteltyä esimerkkiongelmaa. Samaan lopputulokseen päätyi myös GDAL & Skimage kirjastoihin perustuva python-ohjelma, jonka suoritus keskeytyi “Killed”-ilmoitukseen. Mainittakoot vielä, että on tietenkin mahdollista ohjelmoida myös itse algoritmi, joka kykenee määrittämään kustannusetäisyys- ja suuntarasteritiedostot ja niiden  perusteella löytämään minimikustannuspolun.

Tällaiset “brute force” algoritmit ovat kuitenkin vaarallisia, sillä mahdollisten polkujen määrä räjähtää helposti käsiin ja ohjelmien ajaminen syö tietokoneen koko muistin ja/tai laskentakapasiteetin. Jonkin verran helpotusta skaalautuvuusongelmiin voi hakea dynaamisesta ohjelmoinnista ja muistia säästävistä rakenteista (mm. priority queue). Kannattaa kuitenkin pitää mielessä, että avoimen lähdekoodin maailmassa on jo olemassa varsin toimivia keinoja pienimmän kustannuksen omaavien polkujen löytämiseen.

Yhteenveto

Tätä klassista paikkatieto-ongelmaa voi ratkoa siis useammalla avoimen lähdekoodin työkalulla. On kuitenkin tärkeä muistaa, että analyysin lopputulos on vain niin hyvä kuin lähtöaineisto. Eli vaikka tässä blogissa ei kustannuspinnan muodostamista käsitelty tarkemmin, se näyttelee keskeistä roolia lopputuloksen luotettavuuden kannalta.

Kenties lähtöaineistojen kerääminen ja muokkaaminen on blogisarjan seuraava osa. Mukavia reitityshetkiä minimikustannuspolkujen parissa!