Gispo pääsi toteuttamaan yhdessä Asiantuntijat N+1 Oy:n Pilvi Nummen kanssa Sipoon kunnalle mielenkiintoista projektia, jonka tavoitteena oli automatisoida, nopeuttaa ja helpottaa kunnan asemakaavavarannon laskentaprosesseja. Lähtötilanne oli Sipoossa samanlainen kuin monessa muussakin pienessä ja keskisuuressa kunnassa: halutut tunnusluvut, kuten rakennettu ja rakentamaton kerrosala, laskettiin pääasiassa manuaalisesti ja prosessi oli tekijöilleen raskas.

Perustukset kuntoon ennen työkalun rakentamista

Ennen varsinaisen työkalun rakentamisen aloitusta määrittelimme yhdessä Sipoon kunnan ja Pilvi Nummen kanssa asemakaavavarannon laskentaprosessin perustukset: tuotimme käsitemallin ja prosessimallin. Käytimme näissä hyväksemme mm. Helsingin seudun ympäristön tekemiä määrityksiä laskennan keskeisimmistä käsitteistä (mm. rakennetusta ja rakentamattomasta kerrosalasta). Prosessimallissa määrittelimme asemakaavavarannon laskennan varsinaisen punaisen langan: mitkä ovat laskennan lähtötiedot, miten niitä prosessoidaan ja mitkä ovat laskennan halutut tulostiedot. Määritetyt käsitteet olivat muuttujia, joiden paikan yhtälössä prosessimalli määrittää.

Työkalun rakentaminen QGISin graafisella mallintajalla

Kun asemakaavavarannon kannalta merkitykselliset esimääritykset ja pohjatyöt oli tehty, siirryimme itse laskentatyökalun rakentamiseen ja automaation tekemiseen. Asemakaavavarannon laskentatyökalu tuotettiin QGISin graafisella mallintajalla. Graafinen mallintaja on varsin hyödyllinen työväline, sillä mallintajalla voidaan automatisoida pitkiä ja monimutkaisia prosessiketjuja. Mallintajan etuja ovat myös nimensä omaisesti graafisuus ja se, ettei mallin tuottamiseen tai muokkaamiseen tarvita Python-koodikielen osaamista – vain QGISin perusteiden ja keskeisimpien prosessien ymmärrys riittää. Mallia tuottaessa prosessiketjut on helppo hahmottaa, sillä mallin elementit ja niiden kytkökset ovat kokonaisuudessaan nähtävissä. QGISin graafinen mallintaja kehittyy tällä hetkellä todella aktiivisesti ja saa jatkuvasti uusia toiminnallisuuksia!

Sipoon kunnan tapauksessa graafisen mallin eri prosessit voidaan jakaa kolmeen eri vaiheeseen: lähtöaineistojen määrittelyyn ja valmisteluun, lähtöaineistojen yhdistämiseen ja ryhmittelyyn sekä tulosten loppulaskentaan. Kaikkien näiden vaiheiden läpivienti manuaalisesti olisi hyvin työlästä ja virhealtista, mutta QGISin graafinen mallintaja saa puristettua kaikki prosessit yhteen näppärään pakettiin. Sipoolle tuotettu graafinen malli (= kaavavarannon laskentatyökalu) vietiin lopuksi QGISin Prosessointityökalut-paneeliin, josta sen voi ajaa kätevästi vain yhdellä klikkauksella. Lopuksi tuotettu asemakaavavarannon laskentatyökalu vie halutut tulostiedot sekä paikkatietoaineistoksi että taulukkomuotoiseksi tiedoksi.

Projektissa aktiivisesti mukana ollut Asiantuntijat N+1 Oy:n Pilvi Nummi luonnehti projektia ja siinä tuotettua työkalua seuraavasti:

“Mielestäni QGISillä toteutettu kaavavarannon laskentamalli on erinomainen välinen keskisuuren tai pienen kunnan asemakaavavarannon laskentaan. Erityisesti Sipoon kaltainen kunta, joka ei itse ylläpidä kiinteistörekisteriä eikä saa varantotietoja suoraan kuntarekisteristä, voi työkalun avulla merkittävästi tehostaa toimintaansa.
Automaattisen laskennan edellytyksenä tietysti on, että kunnalla on asemakaavatiedot paikkatietomuodossa sekä rakennus- ja rakennuslupatiedot kunnossa ja mielellään luettavissa rajapinnan kautta. Sipoossa vektorimuotoinen, CAD-ohjelmistolla tuotettu ajantasa-asemakaava muunnettiin paikkatietomuotoon muutama vuosi sitten. Tämä aineisto toimii nyt lähtökohtana kaavavarannon laskennalle. Projekti on nyt nostanut esiin uusia kehitystarpeita, joista Sipoossa keskeisin on tietomallipohjaiseen asemakaavoitukseen siirtyminen.”

Kuntien sisäisten paikkatietoprosessien automatisointia QGISillä voidaan tehdä monin eri tavoin, joista tässä artikkelissa on esitelty yksi varsin kilpailukykyinen tapa. Yleisesti voidaan todeta, että prosessien automatisoinnilla saadaan kevennettyä kuntien työtaakkaa, parannettua tilanneseurantaa ja vahvistettua tiedolla johtamista, kun aineiston käsittely ja analyysi tapahtuvat helposti ja nopeasti nappia painamalla. Automatisoitu prosessi myös parantaa tulosaineistojen ajallista vertailukelpoisuutta, kun prosessointitapa ja -logiikka pysyvät suhteellisen vakioina.

Kiitämme Asiantuntijat N+1 Oy:n Pilvi Nummea sekä Sipoon kunnan tiimiä tästä hienosta projektista!

Meillä QGIS-gurumme Topi Tjukanov testaili keväällä QGISin digitointityökaluja osana kaavoittajan QGIS-työkalujen kehitysprojektia (QAAVA). Topi esitteli työkalujen mahdollisuuksia meillä Gispolla ensin sisäisesti ja siitä innoittuneena vedimme Gispon Turun possen kanssa webinaarin aiheesta Turun ensimmäisessä virtuaalisessa QGIS-meetupissa (lisää niitä muuten tulossa varmasti). Siinä meidän Jaakko kaavoitti lentokenttää Ruissaloon ja teki hangaareita lentokentän linjojen suuntaisesti.

Kun digitoinnista on vierähtänyt tovi

Itse en ollut ennen Gispon aikaa digitoinut urallani oikeastaan mitään. Graduaikaisesta rantaviivan nakuttelusta oli jo suhteellisen paljon aikaa ja yllättäen paikkatietoasiantuntijan työssä tulee todella harvoin oikeasti tehtyä itse aineistoja alusta asti. Siksi muistin virkistämiseksi lähdin jo pari vuotta sitten tekemään omaa pihasuunnitelmaa QGISillä, jotta saisin harjoitusta ja toisaalta myös silloin oli tarve laskea pihalle tulevan kivetyksen pinta-ala aika tarkkaan.

Nyt kun Topi ja Jaakko näyttivät laajennetun digitoinnin mahdollisuuksia ja kaarien ja ympyröiden tekoa, tajusin että puutarhasuunnitelma pitää viedä ns. nextille levelille. Editointityökaluja muuten käsitellään meidän QGIS erikoiskurssilla, joka seuraavan kerran etäkoulutuksena kesäkuussa.

Rakennusmoodi päälle ja menoksi

Ensinnäkin laajennetun digitoinnin “contruction mode” on mahtava keksintö! Suoria kulmia voi tehdä helposti ja samalla voi määrittää säteen, johon asti viivan voi piirtää.

Näppärä toiminto on myös parallel mode, jonka avulla olemassaolevan linjan avulla voidaan määrittää digitoitavan viivan suunta.

Päätin myös, että pistemäisten puusymbolien sijaan digitoin kaikki pihan puut palloina, näin niiden koon saa helpommin määritettyä eikä tarvitse skaalata niitä mittakaavan mukaan. Tätä ainakin kokenut puutarhasuunnittelija kommentoi, kun näki aikaisemman versioni pihasuunnitelmasta. Kokeilin siis laittaa kirsikkapuun pallona polun keskelle.

Harjoittelu kannattaa

Itse koen, että laajennettujen digitointityökalujen haltuunotto vaatii kyllä jonkin verran kokeilua ja paljon harjoitusta. Työkalun logiikka on lopulta selkeä, mutta hyvä ohjeistus oli kyllä paikallaan, kiitos kollegat!

Topologinen eheys aiheutti välillä haasteita erityisesti kaarissa. Testasin välillä poistaa kohteet (Ctrl-X) ja tuoda ne takaisin, silloin geometriavirheet hävisivät. Tässä olisi mielestäni kehittämisen paikka työkaluissa. Tätä haluaisin ainakin edistää QAAVA-työkalujen kehityksessä.

Muutamia vinkkejä “maankäytön” tai oman pihasuunnitelman digitointiin

Suunnittele tasojen rakenne eli mitkä tiedot liittyvät millekin tasolle. Esimerkiksi pihan rakenteet voivat olla omanaan, maankäyttö omanaan, viivamaiset kohteet, kuten polut omana tasonaan sekä pistemäiset kohteet, kuten sähköpylväät, valotolpat erikseen.
Luo GeoPackage, jonne voi tallentaa kaikki eri tasot ja visualisoinnit. Mieti kohteiden luokittelu kuntoon, luokat voivat olla vaikka 1-10 numeroituja, selitteeseen voi sitten muokata helpommin mitä nuo numerot tarkoittavat.
Tee rakenteet ja monimutkaisemmat kuviot ensin. Kun suurin osa kohteista on valmiina nurmikon ja sora-alueiden täyttäminen on helpompaa autotarcing-toiminnon avulla (joka nykyisin osana topologiatyökaluja).
Muista topologia-asetukset. Ne auttavat paljon ja toisaalta joskus ne pitää laittaa pois päältä, jotta kohteiden tuottaminen toisen päälle onnistuu. Esim. jos nurmikolle pitää laittaa trampoliinin paikka jälkikäteen.

SQL on ohjelmointikieli, josta on paljon hyötyä paikkatietoasiantuntijalle. On raastava pohtia, kuinka paljon aikaa on hukannut tiettyjen paikkatietotehtävien toimittamiseen GIS Desktop -työkaluilla sen sijaan, että olisi osannut toimittaa kyseiset paikkatietotehtävät SQL-komennoilla. Tietokantaohjelmien tapa esittää kyselyjen ajamiseen kulunut aika, usein vain millisekunneissa, ei vähennä tätä tuskaa. Tai ehkä raastavinta on se, että ei aikanaan ryhtynyt opiskelemaan SQL:ää, vaan jäi kamppailemaan kysymyksen “Opinkohan minä ohjelmoimaan?” kanssa.

Kuvitellaan, että emme jääneet tuskailemaan tämän kysymyksen kanssa ja pääsimme opiskelemaan SQL:ää ripeästi. Minua auttoi huomattavasti opittuani, että SQL-komentoja kirjoittaessa on tärkeä aloittaa kysymyksellä: mitä haluan nähdä tuloksena syntyvässä taulussa? Kuulostaa lähtökohtaisesti loogiselta, mutta syvennytään vielä pohtimaan ajatusta: siis minkälaisen tulostaulun haluan nähdä SQL-kyselyn ajamisen tuloksena?

Jos vaikka haluaisimme selvittää, miten Yhdysvallat halkovan tienumero 20 (eng. “US Route 20”) jakautuu eri osavaltioiden välille pituudeltaan, voisimme aloittaa hahmottelemalla mielessämme, minkänäköisen taulun haluamme nähdä kyselyn lopputuloksena.

Emme halua vain tietoa osavaltion nimestä ja tien pituudesta osavaltion sisällä, vaan haluamme myös nähdä osavaltiot halkovat tiegeometriat. Näin tauluun tulee sarakkeet osavaltio, tie_pituus ja geom (paikkatiedon sisältävä sarake). Kuvittelemme mielessämme taulun rakenteen:

osavaltio	tie_pituus	geom
x…	x…	x…

On tärkeä pohtia, miltä taulumme näyttää kyselymme tuloksena, sillä SQL on niin sanotusti deklaratiivinen ohjelmointikieli, jota hyödynnettäessä on tärkeä miettiä vastauksia kysymyksiin “Mitä…?” sen sijaan että vastattaisiin kysymykseen “Miten…?”. Tässä mielessä muodostammekin SQL-kyselymme tapaan: SELECT <jotain> FROM <jostain>, ottamatta kantaa siihen, miten se tieto sieltä tietokannasta haetaan. Näin ollen voidaan todeta, että teemme “deklaraation” siitä, mitä haluamme tulostaulusssa nähdä.

Jos palaamme takaisin käytännön esimerkkiimme, ideanamme on laskea teiden osavaltiokohtaiset etäisyydet ja yhdistää osavaltion sisäiset tiesegmentit toisiinsa. SQL-kyselyn voisi toimittaa esimerkiksi näin:

SELECT s.name AS osavaltio,
    ROUND(SUM(ST_Length(ST_Intersection(r.geom::geography, s.geom::geography)))::numeric, 1) AS tie_pituus,
    ST_Collect(ST_Intersection(r.geom, s.geom)) AS geom
    FROM roads AS r, states AS s
    WHERE ST_Intersects(r.geom, s.geom) and number = '20' and class ='Federal'
    GROUP BY osavaltio
    ORDER BY tie_pituus desc;

Kyselyn ajaminen vei PostGISiltani 328 millisekunttia. Pohja-aineistona meillä oli käytössä Natural Earthilta Yhdysvaltain päätiestö ja osavaltiot US Census Bureaulta. Tuloksena saamme:

Ja karttanäkymältään:

Huomaamme myös, kuinka kunkin osavaltion osalta syntyi yksi tiegeometria usean tiesegmentin sijaan.

Voimme tutkailla myös SQL-kyselyn sisältöä ja siten pyrkiä hahmottamaan kyselyn logiikkaa:

ST_Length-funktio laskee viivan pituuden, kun taas sen sisälle asetettu ST_intersection-funktio ristiinleikkaa teiden geometriat (r.geom) osavaltioiden monikulmiogeometrioilla (s.geom).
ST_Collect-funktio kerää nimensä mukaisesti geometrioita yhdeksi paikkatietokohteeksi ja sen sisälle asetettu ST_Intersection ristiinleikkaa geometriat toisillansa edeltävän kohdan tapaan. Tämän kohdan tuloksena syntyy osavaltiokohtaiset tiegeometriat.
WHERE-ehdon sisälle on asetettu ehdot, joiden avulla filtteroidaan lähtöaineistoja. ST_Intersects-funktio antaa tuloksena totuusarvon sen mukaan, ristiinleikkaavatko paikkatietogeometriat toisensa.
GROUP BY -lauseke ryhmittää tulokset, tässä tapauksessa osavaltion mukaan.

Tärkeintä on hahmottaa SQL-kyselyiden logiikka ja muistaa, että alkutaipaleen jälkeen, perusasiat ymmärrettyä, kyselyiden tuottaminen on huomattavasti helpompaa. Mentyäsi eteenpäin opiskeluissa voit lukea myös kollegani Topin erinomaisen artikkelin PostGISin käytöstä.

Siinä päästään asiaan huomattavasti syvemmälle ja saadaan oiva annos konkreettisia oppeja spatiaalisen SQL:n ja siten PostGISin käyttöön.

Me Gispossa teemme jatkuvasti töitä tietokantojen ja erityisesti PostGISin kanssa. Välillä työn alla on tietomallinnus paikkatietoaineistojen tuottamiseen, mittavien paikkatietoaineistojen analysointi ja ydintietovarantojen tallentaminen ja ylläpito PostGIS-tietokannaksi. Meille on aina ilo keskustella PostGISin käytöstä eri toimintaympäristöissä ja eri paikkatieto-ongelmien ratkomiseen. Jos kiinnostut tästä tematiikasta, olethan yhteyksissä meihin.

Lopuksi, PostGIS-koulutuksiemme kautta pääsee pitkälle myös SQL:än opiskelun suhteen eli pysy myös kärryillä koulutuskalenteristamme tai pyydä tarjous asiakaskohtaisesta koulutuksesta.

GeoServerin avulla voidaan muokata aineistojen kuvaustekniikkaa myös CSS-kielen avulla. CSS on SLD-kieleen verrattuna on käyttäjäystävällisempi tapa muokata kuvaustekniikkaa. CSS-kieltä voidaan hyödyntää GeoServerin CSS Styles -laajennoksen avulla. Laajennos toimii niin, että CSS-kielellä kirjoitettava koodi kääntyy SLD-kieleksi automaattisesti.

Seuraavassa animaatiossa on havainnollistettu joitakin CSS-kielen mahdollistamia toimia GeoServerillä (näe suurena: paina kuvaa hiiren oikealla > Avaa uudessa välilehdessä).

Käytännössä GeoServerin CSS styles -laajennoksen avulla kirjoitetaan haluttu CSS-koodipätkä sille tarkoitettuun kirjoitustilaan ja sitten esikatsellaan ja tallennetaan se tyylinä GeoServeriin.

Havainnollistavassa animaatiossa määritetään muun muassa kuntakohtainen väri, postinumeroalueittainen tekstitys, tekstityksen tyyli ja symboliikan otsikot. Lisäksi olisi mahdollista esimerkiksi monistaa alueiden sisään omia png-kuvia tai vaikkapa tekstittää tieviivoja tietä pitkin kulkevin tekstityksin.

Alla on esitetty CSS-koodipätkä, jota on hyödynnetty edellä esitetyssä animaatiossa.

/* @title Helsinki*/

[kunta=’Helsinki’]

{fill: red;}

/* @title Espoo*/

[kunta=’Espoo’]

{fill: blue;}

/* @title Vantaa*/

[kunta=’Vantaa’]

{fill: green;}

/* @title Kauniainen*/

[kunta=’Kauniainen’]

{fill: gray;}

*{stroke: white;

stroke-width: 0.05;

label: [nimi];

font-fill: white;

halo-color: black;

halo-radius: 1;}

Sitä voi käyttää esimerkinomaisesti omassa CSS-tyylittelyssä tai sitten vilkaista GeoServerin CSS-cookbookiin, osoitteesta: https://docs.geoserver.org/latest/en/user/styling/css/cookbook/index.html. Siellä on lukuisia esimerkkejä, jotka auttavat alkuun CSS-kielen hyödyntämisessä.

GeoServerin lisäosat löytyvät osoitteesta http://geoserver.org/release/stable/.

Oletuksena saatavilla olevien fonttien lisäksi GeoServeriin voidaan asentaa myös omia fontteja. Fontteja voidaan käyttää mm. aineistojen tekstityksissä tai fonttisymboleina GeoServer-tyylejä luodessa. Tämä artikkeli sisältää ohjeet uuden fontin asentamiseksi Gispon koulutuskoneelle. Uuden fontin asentaminen noudattaa samoja vaiheita järjestelmästä riippumatta, mutta esim. hakemistopoluissa voi olla eroja.

Lista GeoServerin käytössä olevista fonteista voidaan ladata GeoServerin REST-rajapinnan kautta. Koulutuskoneella tämä onnistuu avaamalla web-selaimella osoite localhost:8080/geoserver/rest/fonts.json.

Fonttilista on saatavilla myös GeoServerin web-käyttöliittymän kautta. Avaa web-käyttöliittymä koulutuskoneella siirtymällä osoitteeseen localhost:8080/geoserver/web ja kirjaudu sisään admin-käyttäjätunnuksilla. Koulutuskoneella käyttäjänimi on admin ja salasana gispo. Avaa Server status-välilehti ja klikkaa Available Fonts-kohdan linkkiä Full list of available fonts.

Asennetaan seuraavaksi Gispon käyttämä Karla-fontti, joka on saatavilla osoitteesta https://fonts.google.com/specimen/Karla. Valitse sivun oikeasta yläkulmasta Select this font ja lataa fontti oikeaan alakulmaan ilmestyvästä valikosta:

Fonttitiedostot tulee siirtää GeoServerin datahakemiston sisällä olevaan styles-kansioon. Huom. GeoServer tukee vain TrueType-fontteja, joiden tiedostopääte on ttf.

Pura ladatun zip-tiedoston sisältämät fonttitiedostot styles-hakemistoon. Tarvitset hakemistoon kirjoittamiseen admin-oikeudet. Zip-tiedosto voidaan purkaa suoraan styles-kansioon komentoriviltä suorittamalla komento:

sudo unzip Karla.zip -d /var/lib/tomcat8/webapps/geoserver/data/styles

Syötä käyttäjän salasana kysyttäessä, koulutuskoneen salasana on gispo. Purkamisen jälkeen siirretään tiedostojen omistajuus käyttäjälle tomcat8 suorittamalla komento:

sudo chown tomcat8:tomcat8 /var/lib/tomcat8/webapps/geoserver/data/styles/*

Käynnistetään lopuksi Tomcat uudelleen komennolla:

sudo systemctl restart tomcat8

Avaa lopuksi GeoServerin web-käyttöliittymä siirtymällä osoitteeseen localhost:8080/geoserver/web. Kirjaudu sisään admin-käyttäjällä, koulutuskoneella käyttäjätunnus on admin ja salasana gispo. Avaa Server Status-valikko ja klikkaa Clear-painiketta Resource Cache -kohdassa:

Tarkistetaan vielä, että uusi fontti on käytössä. Lataa jälleen lista fonteista siirtymällä osoitteeseen localhost:8080/geoserver/rest/fonts.json.

Varmista asennuksen onnistuminen etsimällä asennettu fontti listasta.

Koko Suomen maakuntakaavat yhdestä rajapinnasta? Kyllä, nykyään ollaan matkalla kohti yhden yhden luukun rajapintapalvelua maakuntakaava-aineistojen jakelussa.

Viimeisten vuosikymmenien aikana eri maakuntiin syntyi omakohtaisia tietomalleja maakuntakaavoista. Tämä on synnyttänyt päänvaivaa niille kaikille organisaatioille ja yksilöille, jotka ovat halunneet hyödyntää maakuntakaava-aineistoja yhtenä kokonaisuutena, koko Suomen kattavana pakettina. Vaikka kaavojen sisältö onkin heijastanut lähestulkoon samoja yhteiskunnallisia maakuntien kehitykseen liittyviä teemoja, kuten energiantuontantoalueille (esim. tuulivoima) tai virkistysalueisiin liittyviä kokonaisuuksia, on tietomallien eroavaisuudet tarkoittaneet hankaluuksia eri maakuntakaava-aineistojen yhdistelyyn. On oletettavaa, että tämänkaltaiset pullonkaulat tietoaineistojen saatavuudessa aiheuttavat merkittäviä hidasteita esimerkiksi Suomeen tehtävien teollisuusinvestointien edistämisessä.

Hankkeessamme hyödynnettiin HAME-nimisessä hankkeessa luotuja yhteentoimivia tietomalleja maakuntakaava-aineistoista.HAME-hankkeessa on työstetty lähivuosien aikana yhteentoimivat tietomallit, joiden pohjalta pystyimme vuoden 2019 loppuvaiheessa yhdistelemään tietokannoista aineistoja toisiinsa. Myös Gispo on ollut HAME-hankkeen eri prosesseissa mukana, lue esim. kuinka hiljattain Gispo oli yhdessä Varsinais-Suomen liiton kanssa auttamassa maakuntien liittoja yhteisen tietomallin hyödyntämisessä:

Maakuntakaavat yhteiseen tietomalliin

Tekninen toteutus

Hyödynsimme PostgreSQL-palvelinklusteria pilvipalveluna, jossa sitten kunkin maakunnan tietoaineistot sijaitsivat. Palvelinklusterin sisällä pystyimme yhdistelemään aineistoja tehokkaasti ja joustavasti, ja jos jokin aineistoja oli virheellinen tai vajaa, kiitos tietokantojen toiminnallisuuksien oli uusia tietotuotteita siltikin helppo tuottaa.

Lopuksi sitten vietiin aineistot, esim. luonnonsuojelualueista rajapintapalveluina datan käyttäjille. Rajapintapalveluratkaisuna käytettiin Varsinais-Suomen liiton olemassa olevaa GeoServer-instanssia. GeoServer on palvelinohjelmisto paikkatietoaineistojen jakeluun palvelimelta käyttäjille vaikkapa kansainvälisien standardinmukaisia rajapintapalveluprotokollia, WMS:ää ja WFS:ää hyödyntäen.

Henkilökohtaisesti hienointa hankkeessa oli avata mukana olleille tahoille mahdollisuuksia, jotka itse aineistoista syntyy kerran kun ne on saatu paikkatietokantaan. PostgreSQL:än paikkatietolaajennos PostGIS on markkinoiden vakain ja toiminnallisuuksiltaan laajin paikkatietokanta. Hyödyntämällä paikkatietokantoja aineistoja voi yhdistellä, muotoilla ja analysoida lennossa, toimintojen automatisaatiosta puhumattakaan.

Lopputuloksia tutkailemaan

Jos konkreettisia tuloksia haluaa tutkailla, voi suunnata Lounaistiedon sivuille, josta löytyy temaattisia tietoaineistoja tuulivoimamerkintöjen, suojeluarvomerkintöjen ja virkistyskäyttömerkintöjen osalta: https://www.lounaistieto.fi/maakuntakaavat/. Huomaa, että aineistot sisältävät vain osan maakuntia, sillä kaikki liitot eivät ehtineet aineistoineen prosessiin mukaan.

Ja jos haluaa tutkailla suoraan aineistoja WFS-rajapinnasta, voi QGISiin tai johonkin muuhun client-ohjelmistoon lykätä seuraavan WFS-rajapintaosoitteen ja ryhtyä tutkailemaan aineistoja*:

http://geoserver.lounaistieto.fi/geoserver/koostetietovaranto/ows?

* Huomaa, että WFS-rajapintaosoitteen osoite saattaa muuttua, jolloin yllä olevasta linkistä Lounaistiedon sivuille löytyy päivitetyin tieto.

Projektin lisätyöpaketteina toteutettiin myös pilottitoteutukset OGC API Feutures -rajapintapalvelureferenssin mukainen esimerkkitoteutus ja GeoPackage-tietoformaattia hyödyntävät tietotuotteet. OGC API Features -toteutuksessa käytetyistä ohjelmistoista voit lukea blogista:

OGC API käytännössä: ldproxy ja pygeoapi

Jos OGC API (OAPI) rajapintastandardin sisältö ja anti ei ole ihan vielä tuttu, siitä voi lukea laajemmin toisesta blogauksestamme:

OGC-API: Rajapintapalvelujen tulevaisuus paikkatietoalalla

Lue myös GeoPackagesta toisesta blogauksestamme.

Open Geospatial Consortiumin (OGC) aktiivisesti kehitteillä oleva OGC API-rajapintastandardi tähtää nykyisten OGC-web-palvelujen, kuten WMS ja WFS, nykyaikaistamiseen. Gispo avasi uuden OAPIn sisältöä syksyllä 2019 julkaistussa artikkelissa OGC-API: Rajapintapalvelujen tulevaisuus paikkatietoalalla. Kerroimme tuolloin OAPIn innostuneesta vastaanotosta ja ennustimme ensimmäisten rajapintatoteutuksien rantautuvan Suomeen lähitulevaisuudessa.

Me Gispolla pääsimme ensimmäistä kertaa kokeilemaan uutta OAPIa käytännössä joulukuussa 2019 uuden OGC Features API-koepalvelun muodossa. Saimme arvokasta kokemusta mm. uuden rajapintastandardin käyttöönotosta sekä nykyisten WFS-palvelujen migraatiosta uuteen Features APIin. Tutustuimme jo tällä hetkellä käytössä oleviin teknologioihin, ja esittelemme seuraavassa niistä kaksi vaihtoehtoa.

ldproxy

Interactive Instrumentsin kehittämä ldproxy lupaa parempaa käytettävyyttä WFS-palveluille. ldproxy on käytännössä adapteri, joka muuntaa olemassaolevan WFS-palvelun OGC Features API-rajapinnaksi. Julkaistavat WFS-palvelut määritetään web-käyttöliittymän kautta yksinkertaisesti antamalla palvelun URL-osoite. ldproxy hakee annetun WFS-rajapinnan GetCapabilities-dokumentin ja osaa sen perusteella automaattisesti määrittää skeeman WFS-palvelussa julkaistuille aineistolle ja julkaista ne OGC Features API-rajapinnan kautta. Hyödynnettävän WFS-palvelun tulee tukea WFS-versiota 2.0 sekä WFS-vastauksien jakamista sivuihin eli Paging-ominaisuutta. Palveluja voidaan lisätä WFS:n lisäksi myös CSW-katalogeista. Uusien aineistojen julkaisu OGC API-rajapintaan onkin ldproxyn avulla todella helppoa.

ldproxyn käyttöönotto kannattaa tehdä Dockerin avulla. Dockerin asentamisen jälkeen ldproxyn saa käynnistettyä komennolla

docker run --name ldproxy -d -p 7080:7080 -v ldproxy_data:/ldproxy/data iide/ldproxy:latest

Web-käyttöliittymä on tämän jälkeen käytettävissä selaimen kautta osoitteessa http://localhost:7080/manager. Palvelun lisääminen on helppoa: lisää uusi palvelu painamalla plus-painiketta, anna palvelulle nimi ja WFS-osoite ja klikkaa lisää. ldproxy konfiguroi palvelun automaattisesti. Kun palvelun tila on Initializing-tilan sijaan Online, on rajapintapalvelu valmiina käytettäväksi. Valitse lisäämäsi palvelu ja klikkaa View avataksesi vastajulkaistun OAPI-rajapinnan selaimella.

Suojattujen palveluiden jakaminen ldproxyllä onnistuu JSON web tokenien avulla, jos hyödynnettävä WFS-palvelu tukee niitä. Kannattaa huomioida, että ldproxyn web-käyttöliittymä on avoin kaikille, eikä sisäänrakennettua tukea käyttäjienhallinnalle ole. Tuotantokäytössä luvaton pääsy web-käyttöliittymään tulee estää esimerkiksi erillisen web-palvelimen kuten Apache tai nginx avulla.

pygeoapi

Toinen vaihtoehto oman OGC Features API-rajapinnan julkaisuun on Python-pohjainen pygeoapi. Sen konfigurointi on ldproxyä haastavampaa, mutta tarjoaa myös enemmän mahdollisuuksia. pygeoapi tukee useita eri tietolähteitä, mikä mahdollistaa esimerkiksi jo olemassa olevien WFS-rajapintojen, PostGIS-tietokantojen sekä Geopackage tai shape-tiedostojen sisältämien aineistojen julkaisun OAPI-rajapinnan kautta. pygeoapi-demopalvelussa on valmiiksi määritetty ja julkaistu esimerkkiaineistoja. Demopalvelun avulla voikin nopeasti testata, miltä uusi OAPI-rajapinta saattaa näyttää ja miten sitä käytetään!

Asennusohjeet opastavat asennukseen Python-virtuaaliympäristössä, mutta helpoin tapa kokeilla pygeoapia on Dockerin kanssa. Ennen Docker-kontin käynnistämistä tulee luoda konfiguraatiotiedosto, jota pygeoapi käyttää julkaistavan rajapinnan määrittelyyn. Konfiguraatiotiedostossa määritetään mm. rajapinnassa julkaistavat aineistot ja niiden metatiedot. Esimerkkikonfiguraation voi kopioida projektin GitHub-repositoriosta. pygeoapin voi käynnistää avaamalla komentorivi hakemistoon joka sisältää konfiguraatiotiedoston my.config.yml ja käynnistämällä pygeoapi komennolla

docker run --name geoapi -p 5000:80 -v $(pwd)/my.config.yml:/pygeoapi/local.config.yml -it geopython/pygeoapi

Rajapinta on käytettävissä osoitteessa http://localhost:5000. Toisin kuin ldproxy, pygeoapilla ei ole hallintaan käytettävää web-käyttöliittymää, vaan konfiguraatiomuutokset tehdään manuaalisesti muokkaamalla konfiguraatiotiedostoa. Muutokset tulevat voimaan Docker-kontin uudelleenkäynnistyksen jälkeen. WFS-rajapintoja julkaistessa WFS-rajapinnan tulee tukea versiota 2.0, ja myös tuki paging-ominaisuudelle on suositeltua. pygeoapin kehitys on aktiivista, ja käytössä olevat konfiguraatioparametrit saattavat muuttua versioiden välillä.

Data on vain bittejä, jos sitä ei analysoida ja visualisoida. GPS-, sensori- ja IoT-dataa tai muunlaista paikkatietoa voi kerätä vaikka kuinka, mutta varsinainen hyöty realisoituu vasta, kun datasta tulee tietoa ja tieto ohjaa toimintaa parempiin tuloksiin. Tietojohtamisen prosessit kiteytyvät muodikkaiden dashboard-ratkaisujen lisäksi myös perinteisiin karttoihin, graafeihin ja muihin tietotuotteisiin, kuten kartta-animaatioihin.

Toteutimme hiljattain yhdessä Tampereen Infra Oy:n ja Business Tampereen kanssa projektin tiekunnossapidon toiminnan tehostamiseksi. Projektin tavoitteena oli mahdollistaa kunnossapidon ajoneuvojen GPS- ja sensoridatan helppokäyttöisyys, tuottaa data-analytiikkaa ja sen tulokset kiteyttäviä datavisualisaatioita sekä tuottaa kokeilevia tuloksia myös tiekunnossapidon toimintojen optimointiin reittipohjaisen suunnittelun avulla.

Hankkeessa pääsimmekin toteuttamaan yhtä mielipuuhistamme eli datavisualisaatioita tietojohtamisen pohjamateriaaliksi:

Autamme asiakkaitamme usein paikkatietoanalyysien ja niiden tuloksien visualisoinnissa. Näiden paikkatiedon visualisointien tarkoitus on viestiä tehokkaasti tuotettujen paikkatietoanalyysien tulokset. Visualisaatiot eivät ole useinkaan konsultointien tavoite, vaan projektien kriittinen vaihe , joka tekee paikkatietoanalyyseistä ja -datasta merkityksellisen ja ymmärrettävän. Ilman helposti omaksuttavaa ja vaikuttavaa datavisuaalitiota, kuten karttaa tai tilastograafia, koko työ voi jäädä merkityksettömäksi pöytälaatikkoprojektiksi.

Usein autammekin Gispossa asiakkaitamme explorativiisen data-analyysin menetelmin, pureutuen dataan ja etsien siitä säännönmukaisuuksia laskennallisesti ja visuaalisesti. Visuaalinen paikkatietojen tutkiminen viittaa prosessiin, jossa paikkatietoja tutkitaan visuaalisesti vaihdellen ja tutkaillen eri visualisointityylien avaamia näkökulmia dataan. Lisäksi samaisessa vaiheessa voidaan esimerkiksi aggregoida tietoa, ja visualiaalisesti tutkia aggregoidun tiedon ilmentymää kartalla.

On tapauksia, jolloin asiakkaalla on jo työn alkuvaiheessa valmiina selvästi määritettyjä tutkimuskysymyksiä datansa suhteen. Tällöin luovuutemme jalkautuu ennen kaikkea analyysimenetelmien ja -vaiheiden valikoitumiseen sekä analyysi-iteraatioiden automatisointiin.

Lopuksi koittaa raportointi, jolloin paikkatietojen visualisaatiolta, kuten kartalta, interaktiiviselta karttapalvelulta tai kartta-animaatiolta vaaditaan viestinnällistä täsmällisyyttä ja vetoavuutta. Kiitos tarkoituksenmukaisen analyysin ja osuvan tuloksien visualisaatiotyylin asianomainen ymmärtää data-analyysien tulokset ja hyödyntää omaksuttua tietoa toiminnan tehostamiseksi.

Liikkuvan kuvan animaatiot ovat nykypäivänä kaikkialla. Myös paikkatietoa voidaan animoida luoda liikkuvaa kuvaa vastaten missä-kysymyksen lisäksi milloin-kysymyksiin.

Kartta-animaatio tuloksena Tampereen Infra Oy:lle toimitetussa edellä mainitussa projektissa. Visuaalisaatio havainnollistaa tiekunnossapidon ajoneuvoille laskettua optimaalista reittiä.

Jos paikkatietoon kytketty datan ajallinen ulottuvuus kiinnostaa laajemmin, kannattaa tutustua kollegamme Topi Tjukanovin tuotoksiin, joita on esillä hänen nettiportafoliossa, Twitterissä ja Gispon eri blogikirjoituksissa (suomeksi / englanniksi) tai suoraan sähköpostitse (topi@gispo.fi).

Jos nämä pohdinnat ja visualisaatiot herättivät ajatuksia omaan liiketoimintatavoitteeseesi ja omaan paikkatietodataasi liittyen, olehan yhteydessä ja keskustelkaamme vaihtoehtoisista ratkaisuista, ja siitä miten Gispo voisi olla organisaationne avuksi (santtu@gispo.fi, puh. 040 1380 288).

Voiko QGISillä tehdä kuntakaavoitusta? Sitä kyseltiin meiltä Paikkatietomarkkinoilla viime vuonna ja päätimme kartoittaa tilanteen. Vastauksena on, että QGIS toimii jo sellaisenaan hyvin kaavoituksen työkaluna, kokemusta tästä on jo muutamissa kaupungeissa ja kunnissa Suomessa.

Isoin kehitystarve on kansallisen kaavan tietomallin huomioon ottaminen kaavoitustyössä jatkossa. Sitä varten tarvitaan tietokanta, jossa hallitaan mm. kaavakohteiden elinkaarta. Ja tietokannan tietojen käsittelyyn ja hallintaan tarvitaan kaavoittajalle helppokäyttöisiä nappuloita, joita voidaan tuottaa olemassa olevien työkalujen tueksi QGISiin.

QGISin ja PostGISin avulla voidaan siis toteuttaa avoin referenssitoteutus kaavoittajan työkaluista. Meillä on sille jo nimikin: QAAVA. Koska nimi on niin hieno, meillä on jo logokin!

QAAVA-lisäosan avulla QGISiin saadaan kaavoittajalle tärkeät työkalut:

Kaavakohteiden ja kaavamääräysten lisäys hoidetaan siten, että taustalla pyörivä tietokanta pysyy eheänä.
Tietoja pitää voida hakea ja suodattaa tietokannasta.
Myös kansallisesti tärkeät lähtötiedot voidaan hallita työkalulla.

Meillä on jo muutama kiinnostunut kunta mukana ideoimassa QAAVAa eteenpäin. Vielä tarvitaan muutama lisää, jotta yleiset kaavoittajien tarpeet saadaan koottua yhteen. Jos kuntanne haluaa mukaan yhteiskehitykseen, ole yhteydessä Sannaan (sanna@gispo.fi)! Yhdessä saadaan kehitettyä hyvät työkalut kaavoittajien tarpeisiin.

Kaikessa mitä teemme, teemme helposti juuri niin kuin aina ennenkin. Kätevää, kun sen osaa – muttei välttämättä läheskään aina tehokkainta.

Erilaisia paikkatietoformaatteja on useita. Niistä tunnetuimpia lienevät vektoripuolella shapefile ja tätä hieman enemmän mahdollisuuksia tarjoava geodatabase, rastereiden käsittelyssä taas GeoTIFF. Miksi kuitenkin kokeilisit jotakin muuta? Mikä GeoPackage? Joku avoimen lähdekoodin oma formaattihömpötys?

GeoPackage (GPKG) on geospatiaalisen tiedonsiirtoon tarkoitettu formaatti, jota voisi kuvailla kannettavaksi tietokannaksi, jossa tieto tallennetaan tauluihin. Saat tallennettua yhteen tiedostoon useita tasoja, mikä on suuri etu verrattuna esimerkiksi shapefilen kaltaisiin yhden tason tiedostoformaatteihin. GeoPackagea käyttettäessä tukitiedostojakin avautuu vain kaksi (SHM, WAL) kirjoitusta ja lukua varten. GeoPackagea siirrettäessä on muistettava sulkea tiedosto, jolloin tukitiedostot katoavat ja tiedosto on valmis siirrettäväksi.

GeoPackage on SQLite-tietokantaan perustuva, OGC-standardoitu tietokanta eli siten esimerkiksi ohjelmistoriippumaton. Voit käyttää sitä siis millä tahansa SQLiteä lukevalla ohjelmistolla, kuten QGISilla. QGIS 3 tukeekin GeoPackagea natiivina. GeoPackagen tehtyä tuloaan ja muutaman vuoden, QGIS3 tekee sen käytöstä helppoa ja suositeltavaa. Se on laajasti implementoitu (mm. GDAL, R, Python, Esri) ja siihen voidaan tallentaa myös tiilitettyä rasteridataa. Koska GeoPackage on avoimen lähdekoodin formaatti, pakkautuu vain yhteen tiedostoon ja toimii alustasta riippumatta, se sopii hyvin myös mobiilimaailman sovellusten kehittämiseen.

Iso plussa GeoPackagessa on sen tuki SQL:n käyttöön. SQL API -ohjelmointirajapinnan tarjoaminen innostaa erityisesti vaikkapa PostGIS-maailmaan perehtyneitä, sillä tietokannan käytöstä tulee huomattavasti tehokkaampaa SQL-kieltä hyödyntämällä.

Näppäriä vinkkejä GeoPackagen käyttöön

Katsotaanpa vielä muutama kätevä vinkki GeoPackagen kanssa työskentelyyn QGISin kanssa.

GeoPackage-tason luominen ja tasojen ryhmittely QGISissa

QGIS-projektiin luodaan uusi GeoPackage-taso Tasot > Luo taso > Uusi GeoPackage-taso.

Tässä kohtaa voi määritellä taulun perustietojen lisäksi sille sopivia ominaisuustietoja jo valmiiksi.

Tauluja voi yhdessä GeoPackagessa olla useita, joten niiden ryhmittely on usein paikallaan. Tämän voi tehdä klikkaamalla klemmari-ikonia tasovalikon yläpuolelta.

Tyylin tallennus GeoPackageen

GeoPackage-tietokantaan voi tallentaa myös tyylejä. Valitse taso, jonka tyylin haluat tallentaa, ja klikkaa tason ominaisuuksiin. Vasemmasta alakulmasta valitse Tyyli > Tallenna tyyli > In database (GeoPackage).

Tallennetut tyylit näkyvät GeoPackagen layer_styles-tasossa. Voit tarkastella sitä avaamalla QGISissä DB Manager -työkalun klikkaamalla QGISin yläpalkista Tietokanta > Tietokannan hallinta. GeoPackage-ikonin päältä klikkaamalla New connection voit lisätä luomasi gpkg-tietokannan. Luomiesi taulujen joukossa on nyt layer_styles-taulu. Esimerkkikuvassa tämä taulu sisältää nyt tyylit puistot- ja puut-tasoille. Huomaa myös, että taulun SLD-sarake sisältää tyylin SLD-koodin. Tätä koodia voi käyttää tason visualisointiin GeoServerillä.

GeoPackagea kannattaa siis käyttää, kun haluaa enemmän irti helposti. Myös vanhojen tiedostojen siirto GeoPackage-muotoon on mahdollista esimerkiksi GDAL/OGR-kirjaston avulla. Kokeilemaan vaan!