CAD-ohjelmistoja hyödynnetään usein etenkin insinöörien ja arkkitehtien suunnittelutyössä. CAD-suunnitteluohjelmistoja on myös iso liuta, suurin osa kaupallisia ohjelmistoja. Perinteisesti CAD-ohjelmistoja on käytetty piirtämiseen ja mallintamiseen ja oleellista on ehkä enemmän suunniteltujen kappaleiden ja kohteiden suhde toisiinsa ja ulkoasu, kuin paikkatiedot tai ominaisuustiedot. CAD-maailmassa voi esiintyä myös paikkatieto-ohjelmistolle eksoottisempia geometrioita, kuten kaaria.

Paikkatietomaailma ja CAD-maailma kohtaavat usein erityisesti kaavoituksessa ja johtoaineistojen käsittelyssä ja siten nämä maailmat ovat aika lähekkäin, mutta silti niin kaukana.

Jo pelkästään näistä asioista johtuen CAD-ohjelmistoilla luotujen aineistojen tuominen esimerkiksi QGISiin ei aina ole juhlaa. Jotta aineistot toimisivat ja olisivat sujuvasti käytettävissä muillakin kuin CAD-ohjelmistoilla, kokosimme yhteen ohjelmistojen yhteiskäytön tyypillisiä sudenkuoppia.

Muista siirtoformaatti ja formaattien versiot

QGIS tukee satoja tiedostoformaatteja (GDAL/OGR-kirjastoissa kuvatut), mutta osa tiedostoformaateista on suljettuja, joten niihin ei ole voitu lisenssisyistä tehdä tukea QGISille. 

CAD-aineistoa jaetaan yleensä .DGN-,  .DWG- ja .DXF-formaateissa. 

DGN on Microstationin formaatti ja sen osalta haasteena on Microstationin versio. Versiota 8.0 aikaisempia .DGN-tiedostoja (v7) voi lukea, mutta sen jälkeisiä .DGN-versioita QGIS ei kykene hyödyntämään. Tällaisissa tapauksissa kannattaa tallentaa vanhempaan versioon. 

.DWG on lisensoitu myös siten, että niiden käyttö QGISissä on ongelmallista. Ne eivät avaudu suoraan QGISiin vaan .DWG on importoitava Geopackageksi. 

Parhaiten QGISin kanssa yhteensopiva on  AutoCADin siirtoformaatti .DXF, jonka ominaisuudet ovat suunniteltukin välittämään tietoa eri ohjelmistojen välillä. Usein siis kannattaa pyytää aineistot suoraan .DXF-muodossa tai muuntaa esimerkiksi .DWG tähän muotoon itse. Tämä on onneksi helppo muutos, jonka voi tehdä esimerkiksi netistä löytyvillä ilmaisilla konvertteri-ohjelmistoilla (googleta esim. DWG to DXF). 

Tuo DWG/DXF -työkalu

Tässä ohjeet, kuinka käytetään QGISin “Tuo DWG/DXF”-työkalua (Projekti -> Tuo/vie -> Tuo tasoja DWG/DXF-tiedostoista), joka aineiston avaamisen lisäksi luo GeoPackage-tiedoston sen sisällöstä. Toinen vaihtoehto olisi tuoda aineisto projektiin uutena vektoritasona. Näistä ensinmainittu työkalu antaa paremman näkymän aineistoon, sillä se jakaa aineiston CADissa nimettyihin tasoryhmiin. Sen sijaan aineiston tuonti vektoritasona tuo kaikki polygoni-, viiva- ja pisteaineistot projektiin yksittäisinä tasoina, minkä seurauksena haluamiaan tietoja joutuu kaivelemaan eri tavalla attribuuttitaulukoista. 

Koordinaattijärjestelmän asettaminen

Kun tiedostoa tuodaan QGIS-työtilaan, pitää tietää ja asettaa vielä aineiston koordinaattijärjestelmä. Yleensä QGIS tunnistaa aineistojen koordinaattijärjestelmät automaattisesti, mutta CAD-aineistoissa tämä tieto puuttuu, ja siksi se on hyvä ilmoittaa aineiston vastaanottajalle.

Välillä valitettavasti käy niin, että CAD-piirrosta ei ole missään vaiheessa sidottu koordinaattijärjestelmään. Tällöin ainoa keino saada piirros kohdilleen maailmaan on georeferoida se vastinpisteiden avulla uudelleen tai käyttää Affine- tai Translate-työkaluja. 

CAD-aineistojen sisällöt

Jos aineisto on alunperin luokiteltu ja nimetty johdonmukaisesti, elämä on paikkatietomaailmassa helppoa. Toisinaan kohteiden kuvaustekniikkaa pitää hieman hioa, jotta aineistosta saa korostettua itselleen olennaiset kohteet.

Parhaimmillaan CAD-aineistossa voi olla myös ominaisuustietoja, mutta useimmiten niitä ei ole, vaan kohteiden tiedot on tallennettu vain piirtoteknisesti annotaatio- eli tekstitasoina. Jos käy hyvin, kohteiden tekstitasot ovat loogisesti niihin liittyvien muiden tasojen kanssa samassa tasoryhmässä – esimerkkinä vaikkapa tonttinumerot tonttien rajojen kanssa samassa ryhmässä. Joissain tapauksissa kaikki aineiston tekstit ovat voineet jäädä jo CAD:issa yhdelle tasolle nippuun, jolloin niitä joutuu tulkitsemaan QGISissä attribuuttitaulukosta.

Geometria!

Tietorakenteen lisäksi toinen iso tekijä CAD-aineistojen tarkastelussa paikkatieto-ohjelmistoissa on geometria. Usein CAD-aineistolla piirretyt kohteet ovat viivakohteita, vaikka ne kuvaisivatkin alueita, kuten tontteja tai puistoja. Vaikka aineisto näyttää tässäkin tapauksessa piirtoteknisesti oikealta, esimerkiksi aluemaisten kohteiden pinta-alan laskeminen ei onnistu, ellei käyttäjä muokkaa niitä itse polygoneiksi. Aineiston jatkoanalyysiä ajatellen kohteiden geometrinen ja topologinen eheys (rajatut alueet ovat suljettuja, viivamainen geometria ei saa leikata itse itseään ym.) ovat siis ehdottoman tärkeitä.

QGISin haasteena toisaalta on, että sillä on vielä hankala piirtää “cadimaista” jälkeä eli kaaria ja rakenteita. Työkaluja toki on, mutta ne vaativat kehitystä. Mielenkiintoisia projekteja kuitenkin löytyy, kuten tässäkin keskustelussa läpikäyty Cad Tools, mutta kuten kommenteissa mainitaan, tarvittaisiin pari tonttua hoitamaan homma kuntoon. 

Eikun tekee vaan!

Vaikka tässä artikkelissa on käyty läpi ohjelmistojen eri tarpeista ja toimintatavoista johtuvia ongelmia, kannattaa muistaa, että monet niistä ovat helposti korjattavissa. Tarvittavia korjauksia voi tehdä sekä aineistoja laatiessa CAD-ohjelmistoissa että editoimalla kohteita QGISissä. Jos tavoitteena on käyttää CAD- ja paikkatieto-ohjelmistoja rinnakkain, olisi hyvä laatia ne CAD-ohjelmistossa siten, että yhteiselo olisi mahdollista ja tiedot siirtyisivät hyvin palvelusta toiseen. Tässä vielä lyhyt muistilista:

• Ryhmät kuntoon
• Koordinaattijärjestelmä tietoihin mukaan
• Geometriat kuntoon 
• Ominaisuustiedot mukaan

Meidän kauttamme saa myös koulutusta datan suunnitteluun, editointiin ja hallintaan QGISillä. Lähdemme myös mielellämme kehittämään digitoinnin työkaluja QGISille, jotta editointityökalut kehittyvät – tätä puolta tarvitaan erityisesti kaavoituksen, kiinteistönmuodostuksen, tonttijaon ja maastotietojen tuotannossa. 

Gispon vuosi 2022 alkaa uusilla tuulilla, kun Itä-Suomesta kasvavaan joukkoomme liittyy Jarno Kinnunen. Yli kymmenen vuotta paikkatietoalalla ollut Jarno tunnetaan myös hänen ylläpitämästään Paikkatietomies-blogista.

Kuka olet?

Jarno Kinnunen.

Mistä pidät?

Siimojen uittelusta (jota myös kalastukseksi kutsutaan), erästelystä ja luonnossa liikkumisesta noin yleisestikin. Edellä mainittujen lisäksi positiivisia ajatuksia mielen sopukoihin synnyttävät myös sulkapallon pelaaminen, musiikin kuuntelu sekä kissat.

Mikä paikkatietoalassa kiehtoo ja miksi juuri Gispo?

Paikkatietoalalla minua kiehtovat erityisesti paikkatietojen analysointi ja visualisointi, selainkäyttöiset karttapalvelut, spatiaalitietokannat sekä OGC-rajapinnat. Ja kaikki nämä erityisesti avoimen lähdekoodin teknologioilla toteutettuina. 

Gispolla fokusoidutaan erityisesti avoimen lähdekoodin paikkatietosovellusten ja -teknologioiden hyödyntämiseen, joten yrityksen toiminnan perusfilosofia on juuri sitä, mistä itsekin olen kiinnostunut. Lisäksi Gispolla on mm. mielenkiintoisia julkishallinnon asiakkuuksia, joissa kehitetään tulevaisuuden digitalisoituvan maailman työkaluja ja uusia työn tekemisen tapoja. 

Mikä on supervoimasi?

Lupsakka, ihmisläheinen toimintatapa yhdistettynä intohimoon erilaisia teknologisia ratkaisuja kohtaan – ratkaisuja kehitetään ihmisiä varten. Suustani voi ihan yhtä hyvin kuulla lausahduksen “Elähän hättäile, istuhan mättäälle” kuin “Se, mitä ei vielä osata, pitää opetella”. 

Kuntien, maakuntien ja muiden julkishallinnon toimijoiden palvelutuotannon tuottavuuden lisääminen on avainkysymys koko julkisen talouden kestävyyden näkökulmasta. Miten tuottavuutta sitten lisätään? No, ainakin digitalisaation keinoin.

Autoimme  hiljattain Varsinais-Suomen liittoa ja Lounais-Suomen alueellisena tietopalveluna toimivaa Lounaistietoa rakentamaan automatisoidun dataputken, jonka tehtävänä on kerätä heidän alueellaan sijaitsevien palveluiden tiedot palvelupistetietokantaan. Tietokantapohjaisen ratkaisun käyttöönotto mahdollistaa alue- ja kaupunkisuunnittelijoille sekä muille käyttäjille pääsyn jatkuvasti päivittyvään Lounais-Suomen (= Varsinais-Suomen ja Satakunnan maakuntien) palveluiden kohde- ja sijaintitiedot sisältävään tietovarantoon.

Tieto palveluiden sijainnista osaksi toimeenpanopolitiikkaa

Palvelupisteiden sijainteja ja palveluihin liittyviä tietoja käytetään alue- ja kaupunkiseutujen suunnittelussa. Palveluverkon spatiaalinen jakaantuminen ja mahdolliset muutokset palvelukattavuudessa ovat tärkeitä tekijöitä monien kokonaisuuksien suunnittelussa. Palvelupisteisiin liittyville tietosisällöille tai niistä johdetuille tuotteille (tilastot / kartat) luulisi siis löytyvän innokkaita hyödyntäjiä niin maakuntien liitoista kuin kuntien edustajista. Projektin keskeinen tavoite, ajankohtaisen palveluverkkoihin liittyvän tiedon tarjoaminen avoimesti kaikkien saataville, voidaankin nähdä yhtenä askeleena kohti hyvin toimivaa, datalähtöistä toimeenpanopolitiikkaa.

Projektin lähtötilanne

Varsinais-Suomen liitolla ja Lounaistiedolla oli jo projektin alkaessa olemassa palvelupistetietokanta. Kyseisen palvelupistetietokannan sisältö oli kuitenkin päässyt vanhentumaan, eikä sen sisältämiin tietoihin voinut enää luottaa. Vanhan tietokannan päivityslogiikka perustui tietojen manuaaliseen päivittämiseen ja yhteys viimeisimpään tietojen päivittäjäänkin oli päässyt katkeamaan. Tietovarantoa katsellessa kävi ilmi, ettei tapa, jolla olemassaolevan palvelupistetietokannan kohteet oli luokiteltu, ollut myöskään ajan tasalla. Projektin edetessä huomattiin lisäksi, ettei olemassaolevaan tietovarantoon ollut kerätty tietoa kaikista kohteista, joiden nykyään voidaan ajatella olevan relevantteja palvelupisteitä.

Uuden palvelupistetietokannan muodostuksessa haluttiin ottaa huomioon edellisen tietokannan ylläpitoon liittyvät haasteet ja reagoida niihin niin, ettei tietojen ajantasaisuudesta tarvitsisi tulevaisuudessa kantaa yhtä paljon huolta. On ilmeistä, että aineiston pitäminen ajantasaisena manuaalisin keinoin on hyvin haasteellista. Tästä virisi tarve automatisoidulle ratkaisulle.

Varsinais-Suomen liitto ja Lounaistieto olivat tunnistaneet myös toisen tärkeän seikan; palveluja tarjoaa niin yksityinen kuin julkinenkin sektori. Tämä on keskeistä lähinnä sen vuoksi, ettei kaikkia palvelutietoja ole avoimesti saatavilla yhdestä ja samasta lähteestä. Jakamalla palvelupisteet julkisen ja yksityisen sektorin tarjoamiin palveluihin, ongelma voitiin kuitenkin kiertää. Päätimmekin rakentaa automatisoidun rajapintaratkaisun, jossa yksityisen sektorin tarjoamien palveluiden tiedot haettaisiin OpenStreetMapista (OSM) ja julkisen sektorin tarjoamien palveluiden tiedot Digi- ja väestöviraston palvelutietovarannosta (PTV).

Projektin toteutus

Projektin aikana tuotettiin prosessi, joka kerää dataa kahdesta eri lähteestä, mutta yhdistää ne lopulta samaan tietokantatauluun, josta jalostettuun muotoon muokattu aineisto voidaan julkaista loppukäyttäjien saataville ilman manuaalista / ihmisen työpanosta vaativaa työtä. Lopputuloksena saatiin paikkatiedon rajapintapalveluratkaisu, jonka kautta tuotettua dataa voi käyttää ohjelmistoriippumattomasti. Rajapinnat pohjautuvat avoimiin kansainvälisiin paikkatiedon rajapintastandardeihin.

Palvelupistetietojen keräämisessä keskeistä on sijainti. Rajapintaratkaisussa kerätään ja yhtenäistetään data kahdesta eri tietolähteestä samaan tietokantaan siten, että tiedon kerääminen ja prosessointi (siistiminen + jatkojalostus) on täysin automatisoitu. On tärkeä muistaa, että emme tässä projektissa olleet suinkaan kiinnostuneita kaikista OSMin ja PTV:n sisältämistä kohteista; ainoastaan palveluita tarjoaviin kohdeluokkiin kuuluvista kohteista. Aineiston ajantasaisuus varmistettiin luomalla ajastettuja skriptejä, jotka käyvät hakemassa OSMista ja PTV:stä palvelutietokannan kannalta kiinnostavien kohteiden tiedot kerran vuorokaudessa.

Alla olevasta taulukosta käy ilmi millaisia tietoja uusittu palvelupistetietokanta tällä hetkellä sisältää:

Tekniset rakennuspalikat

PTV-dataputken keskeinen idea oli luoda PTVn JSON-apille Foreign Data Wrapper, jonka avulla relevantit tiedot saatiin imuroitua JSON-apista PostGIS-tietokantatauluun. OSM-dataputken tapauksessa keskeistä roolia näyttelee pgosm-flex, jonka avulla OpenStreetMap-aineistosta voidaan parsia kerättävää dataa OSM-tägi perusteisesti.

Hyödynnetyt teknologiat:

• PostgreSQL + PostGIS
• Docker (ratkaisun paketointi ja implementointi)
• multicorn (PTV-data PostGIS-tauluun)
• pgosm-flex (OSM-data PostGIS-tauluun)
• pg_cron (PTV-datan ajastetut hakutehtävät)
• CRON (OSM-datan ajastetut hakutehtävät)
• ogr2ogr (kahdesta eri datalähteestä haettujen taulujen yhdistäminen)
• Geoserver (palvelupistetietojen luokittelu yläteemoittaisiin kokonaisuuksiin + tiedonjako loppukäyttäjille)

Linkit relevantteihin GitHub-repositorioihin:

• https://github.com/GispoCoding/PTVfdw

• https://github.com/GispoCoding/pgosm-flex

Palveluiden sijainneista analyyseihin ja tiedolla johtamiseen

Nykypäivänä paikkatietojen hyödyntämispotentiaali ei enää ole riippuvainen ohjelmistolisensseihin käytettävästä budjetista, vaan ennemminkin organisaation käytettävissä olevasta teknologia- ja digitalisaatiokyvykkyydestä. Tästä näkökulmasta onkin mielenkiintoista pohtia, kuinka julkishallinnon palvelutarjonnan tuottavuutta voidaan lisätä erinäisin paikkatietosovelluksin.

Esimerkiksi palvelupistetietokannan suhteen voidaan miettiä, minkälaisia automatisoituja analyysejä datasta voidaan tehdä. Voidaan muun muassa luoda jatkuvasti päivittyvä tieto siitä, kuinka pitkä matka kotihoidon palveluyksiköistä on ajallisesti lähinpään pelastustoimen palveluyksikköön. Samalla tavalla voidaan laskea, mikä on terveyspalveluiden ajallinen saavutettavuus kävellen (esim. tarkastella päteekö koko väestön tapauksessa, että lähin terveyspalvelu on saavutettavissa kävelemällä korkeintaan 20 minuuttia).

Lisäksi voidaan laskea automatisoidusti kullekin väestöruudulle ajallinen etäisyys autolla esimerkiksi lähimpään ruokakauppaan, ja näin saada tunnuslukuja siitä, minkälainen palveluverkon saavutettavuus vallitsee esimerkiksi haja-asutusalueilla. Voidaan myös analysoida, minkälainen on tiettyjen palvelutyyppien lukumäärän kehitys 10 minuutin kävelyetäisyydellä turismin kannalta keskeisistä sijainneista.

Onkin helppo huomata, että erilaisia analyysinäkökulmia on paljon. Julkishallinnon tuottavuuden näkökulmasta on tärkeä huomioida, että nykypäivän teknologioilla, avoimella datalla ja riittävällä digiosaamisella nämä analyysit voidaan automatisoida. Tämä vapauttaisi työaikaa muihin ihmisen päätöksentekoa vaativiin tehtäviin. 

Projektissa toteutetusta automaattisesta datankeruuprosessista ja sen tuotteena saadun datan esimerkkianalyysiaihioista voidaan päätellä, että julkishallinnon tuottavuutta voidaan lisätä automatisoimalla datan keruuprosessi ja rakentamalla automaattisesti kerääntyvän datan päälle erinäisiin yhteiskunnallisiin rakenteisiin / ilmiöihin liittyviin kysymyksiin vastaavia analyysejä. Kaikki tietävät, että maailma muuttuu jatkuvasti. Kannattaakin painaa korvan taakse, että tällaisia automatisoituja rajapintaratkaisuja sisältävien dataputkien kautta myös data ja sen päälle rakennetut analyysit ja/tai ilmiöiden seurantaprosessit, pystyvät muuntautumaan jatkuvasti.

Olemme tehneet Gispolla yhteistyöprojekteja Yhdistyneiden kansakuntien kanssa. Tähän blogipostaukseen on koottuna YK:lle tekemiemme projektit ja niiden tulokset.

Koulujen saavutettavuus ja Catchment-lisäosa

Teimme koulujen saavutettavuusalueiden laskentaa YK:n koulutuksesta vastaavalle organisaatiolle (IIEP-UNESCO). Projektissa tutkittiin koulujen saavutettavuutta käyttäen hyväksi OpenStreetMapin aineistoja. Tavoitteena oli tehostaa kouluihin liittyvää suunnittelua, mutta tuloksia voi käyttää muihinkin kouluihin liittyviin matkoihin. Analyysillä voidaan arvioida koulujen potentiaalisia oppilasmääriä, tehdä koulukirjojen toimituksen reittioptimointia tai suorittaa koulujen tarkastusreittien laskentaa. 

Projektin tuloksena julkaisimme Catchment-lisäosan QGISiin. Lisäosa antaa käyttäjän määrittää laskennan parametrit eli kohteena olevat pisteet, liikkumistavan ja etäisyyden, jolta pisteisiin saavutaan. Lisäosa näyttää näin pisteen saavutettavuuden esimerkiksi kävellen, pyöräillen tai autoillen. Lisäosa käyttää laskentaan OpenStreetMapin dataa ja GraphHopper-algoritmia. Testejä tehtiin IIEP:n toimesta kesällä 2021 mm. Pakistanissa, Madagaskarilla, Myanmarissa ja Jamaicalla.

Voit lukea lisää Catchment-lisäosasta  ja projektista blogikirjoituksestamme täältä. Catchment-lisäosan löydät GitHubista. Jos haluat käyttää lisäosaa omiin tarkoituksiisi, saat haluamasi alueen/maan tieaineiston käyttöösi joko ottamalla yhteyttä meihin info@gispo.fi tai pystyttämällä Docker-kontin GitHub-ohjeiden mukaan.

Cloudfree-työkalu eli Cloudfree Remote Sensing Image

Business Finlandin Tempo-rahoituksella toteutimme Un Open GIS -yhteisön käyttöön pilvistä vapaita satelliittikuvia. Samalla saatiin kriisinhallintaan soveltuva työkalu. Pilvet voivat peittää muuten hyvälaatuisista satelliittikuvista isojakin alueita, jolloin alueelle kohdistuvan kenttätyön suunnittelu on vaikeaa. Projektissa pyrittiin automatisoimaan pilvettömien kuvien erottelu valtavasta määrästä satelliittikuvia.

CFSI eli Cloud-Free Satellite Imagery -työkalu yhdistää halutulta alueelta viimeisimmät pilvettömät satelliittikuvat mosaiikiksi. Tekoälyyn perustuva työkalu käyttää  European Space Agencyn (ESA) satelliittikuvia (Sentinel) ja osaa poimia ja yhdistää pilvettömät kuvat aineistosta. Jos alueella tarvitaan esimerkiksi rauhanturvaoperaatiota tai apua luonnonkatastrofin sattuessa, työkalun avulla saadaan kerättyä alueelta tarvittava data. 

Voit lukea projektista lisää blogiartikkelistamme täältä. CFSI:n löydät GitHubista.

E-Resilience Monitoring Dashboard

Keväällä ja kesällä 2021 keräsimme ja visualisoimme internetin käyttöä ja digitalisaatiota kuvavaa dataa UNESCAPin käyttöön. Projektin tavoitteena oli selvittää, millaisia eroja on maiden välillä ja maiden sisällä.

Maakohtaisesti tai ryhmittäin tarkasteltavat visualisoinnit kuvaavat monipuolisesti eri mittareita digitalisaation edistymisen, eriarvoisuuden ja käytön suhteen. Visualisoinneista voi nähdä muun muassa maaseudun ja urbaanien alueiden välisiä eroja sekä sukupuolten välisiä eroja. Yhteistyön tuloksena lanseeratulla nettisivulla voi tarkastella eri maiden tilanteita myös sen suhteen, kuinka isolla osalla yrityksiä on omat nettisivut tai kuinka paljon maassa julkaistaan ja käytetään avointa dataa. Visualisoinnit ja tilastot auttavat päättäjiä ratkaisemaan aiheeseen liittyviä haasteita ja puuttumaan internetin käytettävyyden eriarvoisuuteen.

Visualisoinnit ja tilastot ovat nähtävissä UNESCAPin julkaisemalla sivustolla täällä.

UN Open GIS

Edellä mainittujen projektien lisäksi Gispo on osallistunut YK:n avoimen lähdekoodin paikkatieto-ohjelmistojen yhteisön (UN Open GIS, http://unopengis.org/) toimintaan vuodesta 2018 lähtien. UN Open GIS -yhteisön tavoitteena on edistää avoimen lähdekoodin paikkatieto-ohjelmistojen käyttöä YK:ssa ja sen jäsenmaissa sekä myös muissa kansainvälisissä yhteistyöorganisaatioissa ja kansalaisjärjestöissä (NGO).

FOSS4G Suomi -tapahtuma järjestettiin pari viikkoa sitten 14.10.2021 Helsingin Oodissa –  LIVENÄ! Omalta osaltani tämä taisi olla ensimmäisiä tapahtumia, joihin olen päässyt osallistumaan fyysisesti paikan päälle liki kahteen vuoteen. Täytyy sanoa, että tuntui mahtavalta jättää kaksi vuotta palvelleet pieruverkkarit ja etätyöpiste hetkeksi ja nähdä ihan oikeita ihmisiä! Tapahtumaan saatiin koolle korona-aikaan nähden tosi hyvä porukka ja myös striimin puolella oli hyvä pöhinä loppuun asti.

FOSS4G Suomen keynotena oli Jani Kylmäaho, jonka puheesta ei voinut olla inspiroitumatta. Yllätyin itsekin, kuinka paljon avoimen lähdekoodin komponentteja on jo nyt MML:n toiminnan takana – tulevaisuudessa vieläkin enemmän. Puheen aikana huomasin nyökytteleväni jatkuvasti Janin esiintuomille pointeille – sille yleiselle ajatusmaailmalle, että tekemällä asioita yhdessä päästään paljon pidemmälle kuin käpertymällä kukin omaan nurkkaan tekemään samoja asioita uudestaan ja uudestaan hieman eri tavalla. Mielestäni oli myös hienoa, että Jani toi puheessaan esiin ehkä hieman vähemmän keskusteltuja solmukohtia mm. avoimen lähdekoodin hankintoihin liittyen. Avoimen lähdekoodin käyttö on arkkitehtuuripäätös, eikä se ole hankintalain alainen päätös. Sitten jos hankitaan jotain palvelua avoimen lähdekoodin paikkatieto-ohjelmistoihin liittyen (kuten koulutusta, ohjelmistokehitystä tai tukea), silloin hankintalaki nostetaan pöydälle.

Puheita kuunnellessani oivalsin sen, mitä olin ikävöinyt ehkä eniten kahden vuoden sulun aikana: muiden töistä inspiroitumista. FOSS4G Suomessa oli useampikin esitys, jotka saivat aivonystyräni tuikkimaan ja sormeni syyhyämään. Esimerkiksi Damiano Cerronen esitys väestömäärän vähenemisestä (eng. shrinkage) muualla kuin pääkaupunkiseuduilla oli tämänhetkisiltä tuloksiltaan mielenkiintoinen ja yllättävä – tutkimuksessa pystyttiin tunnistamaan mm. autioituvia rakennustyyppejä. Samaistuin vahvasti myös Kimmo Nurmion esitykseen GTFS-aineistoista ja sen pullataikinan ainesosien kasaamisen ja vaivaamisen tuskaan. Toivottavasti tämä pullataikina saataisiin yhteistyöllä uuniin ja pullat käyttäjille jakoon!

Ja hei! Ubigu lähti mukaan folkoisiin omalla avoimuusprosentillaan, mahtavaa!

Tuhannet kiitokset vielä upeille sponsoreille, järjestäjätiimille, puhujille ja osallistujille – ilman teitä tätä tapahtumaa ei olisi! Toivottavasti nähdään taas pian!

Voit katsoa FOSS4G Suomen jälkistriimin kokonaisuudessaan täältä.

PS. Kuvia puhujista löydät täältä, ja jos tapahtumassa nähty supercool QGIS-huppari kiinnostaa, niitä voi tilata täältä.

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