Erilaisten tiedostoformaattien kanssa toimiminen on kaikille paikkatietoasiantuntijoille tuttua. On kuitenkin muutamia formaatteja, jotka aiheuttavat käyttäjillä harmaita hiuksia. Varsinkin, jos ei ole myynyt sieluaan jollekin järjestelmätoimittajalle. 

Toimiiko KuntaGML QGISillä? Tätä kysellään tasaisin väliajoin. Gispon tukipalveluartikkeli KuntaGML:n käytöstä on kerää edelleen kohtuullisen tasaisesti klikkauksia Googlesta. Selkeästi KuntaGML:n käyttöön QGISillä on siis kiinnostusta. Myös Jarno Kinnunen (a.k.a. Paikkatietomies) on blogissaan tarkastellut tapoja lukea kyseistä formaattia. 

Rajapintojen hyödyntäminen komentorivipohjaisten ratkaisujen tai epävarmasti toimivien lisäosien kautta ei ehkä ole tavalliselle käyttäjälle kovinkaan houkuttelevaa. Voisiko siis olla joku yksinkertainen lisäosa QGISiin, jolla vain voisi lukea dataa sisään? Kyllä voisi. 

KuntaGML:n taustaa

Mikäs tämä KuntaGML oikein on? KuntaGML on Suomen paikkatietokentän formaattikummajainen, joka pompsahtelee esille aina erilaisissa yhteyksissä. Edellisellä vuosikymmenellä osana KRYSP-hanketta kehitetyn formaatin oli tarkoitus olla yleinen paikkatietojen siirtoformaatti Suomessa. Tai kuten hankesivuilla asia on määritelty: 

“Yleisenä toiminnallisena tavoitteena on ottaa kunnissa käyttöön standardimuotoiset paikkatietopalvelurajapinnat ja mahdollistaa kaupallisten sekä viranomaisten järjestämien, kuntien tuottamaa paikkatietoa hyödyntävien tietopalvelujen toteuttaminen.”

Hieno tavoite, mutta valitettavasti 10 vuotta myöhemmin voidaan todeta että ihan tähän ei päästy. Yhteensopimattomuus INSPIRE-direktiivin kanssa, epäselvä hallintamalli, hankala hyödynnettävyys ja yleinen avoimen datan politiikka olivat kaikki tekijöitä, jotka eivät varsinaisesti tukeneet KuntaGML:n toimintamallia. Kuntatietopalvelun kuoppaamista voidaan pitää yhtenä KuntaGML:n kuoliniskuna. 

Rajapintoja kuitenkin on edelleen toiminnassa ja niitä käytetään. Tai olisi mukava käyttää jos siihen olisi sopiva työkalu. No nyt on ainakin pohja sellaiselle. 

Lisäosan kehitysprosessi

Meillä Gispolla Joona lähti tutkimaan vielä helpompia  tapoja lukea KuntaGML-formaattia QGISiin ja lähti kehittämään QGISin lisäosaa aineistojen lukemiseen.  Jo muinaiset Gispolaiset (i.e. Mäkisen Erno) olivat tehneet työkalun kehitykseen ansiokasta pohjatyötä, mutta kokonaisuuden paketointi helppokäyttöiseen ja toimivaan kokonaisuuteen oli syystä tai toisesta jäänyt vielä tekemättä. 

Formaatti perustuu OGC:n GML-formaattiin, mutta skeemat ovat rakenteeltaan hyvin vaihtelevia ja käytännössä kattavaa dokumentaatiota rajapinnoista ei oikeastaan ole saatavilla. KuntaGML-pohjaisia rajapintoja löytyy kuitenkin avoimina (siis jotka eivät vaadi tunnistautumista) esimerkiksi Turusta ja Riihimäeltä. Näillä myös testattiin kehitettyä lisäosaa. 

Joona itse kommentoi tätä lyhyttä kehityssprinttiä seuraavasti:

“Erno oli onneksi tehnyt jo raskaan työn havaitessaan ja korjatessaan virheitä tietyissä KuntaGML:n XML-skeemoissa. Lisäosan tehtäväksi jäikin skeemojen korjaaminen ja haluttujen tasojen lisääminen QGISiin. Lisäosa tallentaa halutut tasot kätevästi Spatialite-tiedostoon, jotta niiden käsitteleminen QGISin puolella olisi mahdollisimman vaivatonta. Haastavinta kehitystyössä oli KuntaGML:n aineistojen saaminen yksinkertaisempaan muotoon siten, että kaikki oleellinen tieto pysyy mukana ja on helposti käytettävissä myös QGISin puolella.”

Aineistot käyttöön lisäosan avulla 

Kehitetty lisäosa on julkaistu Gispon GitHubissa. GitHubista löytyy myös ohjeet työkalun käyttöönottoon, mutta tässä askeleet vielä pähkinänkuoressa:

• Lataa kyseisen repositorion releaseista uusin  zip-paketti (ei siis koko tätä repoa, vaan erikseen releaseista tiedosto KuntaGMLLoader.zip)
• Avaa QGIS ja mene käyttöliittymässä lisäosavalikkoon ja sieltä etsi vasemmanpuoleisesta valikosta kohta josta voit asentaa lisäosia zip-tiedostosta (Plugins → Install from ZIP)
• Etsi lataamasi tiedosto ja asenna. Kun näet sinisen palkin lisäosadialogissa, on asennus onnistunut. 

Tämän jälkeen lisäosavalikon alle ilmestyy uusi työkalu. KuntaGML Loader. Syötä KuntaGML-rajapinnan osoite ja lisäosa lataa sinulle sieltä löytyvät kohteet. Alla vielä sama animaationa.

Tämän jälkeen saat geometriat ja ominaisuustiedot esimerkiksi rakennuksista projektiisi. Jotta kyselyt eivät rajottaisi rajapintoja liikaa, on lisäosassa vielä rajoitus kohteiden hakemisen määrän suhteen. 

Tiedot esimerkiksi rakennusten sijainnista ja ominaisuustiedoista on tallennettu erillisiin skeemoihin, joten ne ladataan erillisiksi tasoiksi projektiin. Nohevalle QGISin käyttäjälle näiden tietojen yhdistäminen ei kuitenkaan pitäisi aiheuttaa suurta päänvaivaa joko taululiitoksen tai projektin sisäisen relaation avulla. 

Toteutimme siis toimivan konseptin työkalusta. Tämä ei ole lopullinen ratkaisu, mutta eräänlainen MVP, jonka pohjalta on hyvä rakentaa lisää mikäli tarpeita on. Jos sinulla on aiheesta kysymyksiä tai kehitystarpeita, ota yhteyttä!

Olemme lähteneet Gispolla kehittämään kaavoituksen käyttöön suunnattuja työkaluja QGIS- ja PostGIS-ohjelmistoille. QGIS-ohjelmistoa on jo käytetty mm. yleiskaavan teossa ja näiden kokemusten innoittamina olemme päättäneet kehittää työkaluja kaavoittajalle joustavammaksi ja tehokkaammiksi.

QAAVA-työkalulla QGIS kaavoittajan työvälineeksi

Kehitämme kesän ja syksyn 2020 aikana kaavoittajan käyttöön työkaluja, joilla QGISin avulla voidaan tuottaa kaavakohteita ja linkittää ne lähtötietoihin ja päätöstietoihin. QGIS on avoimen lähdekoodin paikkatieto-ohjelmisto, jolla on jo todella monipuoliset mahdollisuudet ja työkalut digitointiin ja visualisointiin. Nyt on jo valmiina asemakaavan tietomalli vietynä PostGISiin sekä visualisointikirjasto asemakaavan osalta QGISille.

Seuraavaksi lähdetään yleiskaavan tietomallin ja visualisointikirjaston puolelle. Sekä QGISiin tuotettaan QAAVA-lisäosa, jonka avulla on tarkoitus tehdä mm. seuraavat asiat:

• Ottaa yhteys ja alustaa PostGIS-tietokantaan asema- tai yleiskaavan tietomalli
• Lisätä kaavan perustiedot (liitetään kaavan ulkorajaan)
• Lisätä kaavakohteita
• Lisätä kaavakohteille ja ulkorajalle kaavamääräyksiä
• Lisätä kohteille päätöstietoja tai lähtötietoja
• Tuoda olemassa olevista paikkatietoaineistoista kohteita osaksi kaavaan
• Helpottaa usean kohteen yhtäaikaista editointia
• Suodattaa usein tarvittuja tietoja

Jatkokehityslistalla on myös CAD-tyyppisten työkalujen kehitys QGISissä sekä QGIS työtila, jossa valmiina tuotuna visualisointikirjastot, työkalut ja tulostepohjat. Näiden kehitykseen tarvitsemme vielä tukea!

Taustalla tietomallipohjaisuus

QAAVA-lisäosa tarvitaan, koska tieto halutaan tuottaa alusta asti rakenteisessa muodossa hyödyntäen Ympäristöministeriön kehittämää tietomallia ja koodilistoja. Näin kaavaa tuotetaan digitaalisesti eheässä ja harmonisoidussa muodossa heti lähteeltä asti. Tietomallipuoli hoidetaan PostGIS-ympäristössä. PostGIS on PostGreSQL-tietokannan spatiaalilisäosa, jolla hoidetaan paikkatietoaineistojen ylläpito, tietomallin taulujen yhteydet ja versiointi. Jos kunnalla ei ole omaa PostGIS-palvelinta, voimme hostata tai asentaa sen kunnan puolesta. 

Avointa yhteiskehitystä

Kaikki käytetyt ohjelmistot sekä tuotetut materiaalit ja koodit ovat avoimesti saatavilla ja lisensoitu avoimen datan ja avoimen lähdekoodin lisensseillä. Materiaalit projektiin löytyvät GitHubista. Mukaan yhteiskehittämiseen pääsee kuka vain ja otamme kaikki kommentit ja kontribuutiot ilolla vastaan. Nyt projektin eri osioita ovat rahoittamassa Paimio, Espoo, Joensuu, Seinäjoki sekä Kuntaliitto. Mukana olevat organisaatiot muodostavat projektin kehittämisryhmän joka testaa ja kommentoi tehtyjä toteutuksia. 

INSPIRE-direktiivi velvoittaa – lokakuussa 2020 deadline

Jos kunnassasi on huoli siitä miten Inspiren tietotuote kaava-aineistoista tehdään, Gispo voi auttaa. Nyt kehitettävän QAAVA-projektin myötä kaavatiedot saadaan tietomalliin, jonka avulla voidaan tuottaa myös EU:n Inspire-direktiivin vaatimassa muodossa kaavasta tietotuote (julkaistu rajapinta). Huomaattehan, että maankäyttö-teeman Inspire-aineistot tulisi olla saatavilla Inspire:n mukaisissa tietomalleissa jo lokakuussa 2020 (MML, 2013). Tämä vaatii kuitenkin vielä rajapintaratkaisun tuottamista kaavasta. Sen voi toteuttaa avoimen lähdekoodin ohjelmistoilla esimerkiksi GeoServerin avulla. Tästä voimme mielellämme tuottaa myös toimivan esimerkin.

Avoimen lähdekoodin QGIS-paikkatieto-ohjelmisto kehittyy hurjaa vauhtia ja kerää taakseen vinon pinon versionumeroita. Tarkoituksenani on nyt avata hieman logiikkaa eri QGIS-versioiden takana: mitä ohjelmiston versionumerot pyrkivät kertomaan käyttäjälleen? Kaikki tieto, minkä jaan tässä artikkelissa, pohjautuu täältä löytyvään QGISin tiekarttaan.

Ohjelmiston versionumerointi ja QGISin kehityksen vaiheet

Tutustutaan ensimmäiseksi ohjelmiston versionumeroinnin taustoihin sekä QGIS-ohjelmiston kehitysprosesseihin. Ohjelmiston versionumero (esimerkiksi 3.12.1) rakentuu yleensä 2-3 eri luvusta, jotka kertovat ohjelmiston kehitysvaiheesta. Lukujen sisään kätkeytyy erilaisia prosesseja ja logiikoita, joiden kautta siirrytään versionumerosta toiseen.

Major-, Minor- ja Patch-julkaisut

Versionumeron ensimmäinen luku viittaa Major-versioon, johon ohjelmiston päärakenne pohjautuu. Jos ohjelmisto siirtyy Major-versiosta toiseen, ohjelmistoon tehty kehitys on laaja-alaista eikä ohjelmisto ole enää yhteensopiva aikaisemman Major-version ominaisuuksien kanssa (esimerkiksi lisäosat). Esimerkiksi QGISin kehittyessä 2.18-versiosta 3.0-versioon, monet QGIS 2.18-versiolle tehdyt lisäosat eivät enää toimineet QGIS 3.0-versiossa. Myös QGISin graafinen ilme muuttui merkittävästi uudessa Major-versiossa.

Major-luvusta seuraava on Minor-versiota ilmaiseva luku. Minor-julkaisussa ohjelmisto on edelleen joko yksi tai useampi uusi ominaisuus, mutta ohjelmisto pysyy edelleen yhteensopivana aikaisempien Minor-versioiden kanssa. Yleensä ennen uutta Major-julkaisua seuraa liuta pienempiä Minor-julkaisuja (esimerkiksi 3.1, 3.2, 3.3, 3.4…).

Minor-julkaisuakin pienempiskaalaisempi on Patch-julkaisu. Tässä versiossa kehittäjät ovat yleensä korjanneet raportoituja bugeja tai lisänneet ohjelmistoon yhden uuden ominaisuuden. QGISin kohdalla Patch-julkaisuja nimitetään myös vaihejulkaisuiksi eli Point releaseiksi (PR). Eri ohjelmistojen versionumerointi voi edetä Patch-julkaisuakin pidemmälle, mutta pääperiaate on yleensä sama: mitä kauempana numero on Major-luvusta, sitä pienempialaisempaa tehty ohjelmistokehitys on.

QGISin kehitys ja ohjelmistokehitys noin yleisestikin (poislukien pienet nyanssit) noudattavat tiettyjä prosesseja versionumerosta toiseen siirryttäessä. Kehitysprosessi voidaan karkeasti jaotella kolmeen eri vaiheeseen: varsinaiseen kehitysvaiheeseen (development phase), jäädytysvaiheeseen (freeze phase) sekä julkaisuvaiheeseen (release phase). Sekä QGISin viimeisin versio että pitkäaikaisversio (LTR) noudattavat näitä kehitysvaiheita omissa kehityslinjoissaan.

Kehitysvaihe (development phase)

Kehitysvaiheessa QGISiin lisätään uusia toiminnallisuuksia tai olemassaolevia toimintoja kehitetään eteenpäin. Kehitysvaihe jakautuu yleensä useampiin pienempiin vaiheisiin, joissa keskitytään vain tietyn toiminnallisuuden kehitykseen. Jokaisesta pienemmästä kehitysvaiheesta ja uuden toiminnallisuuden lisäämisestä julkaistaan aina oma vaihejulkaisu (PR) tai Patch-versio. Esimerkiksi QGIS-versiot 3.12.1 ja 3.12.2 ovat Patch-julkaisuja/vaihejulkaisuja, joissa ohjelmistoon on lisätty jokin pienempi toiminnallisuus (tai vaihtoehtoisesti korjattu bugeja tai tehty molempia). Kehitysvaiheessa luodaan liuta erilaisia Patch-julkaisuja.

Jäädytysvaihe (freeze phase)

Jäädytysvaiheessa QGISiin ei lisätä enää uusia toiminnallisuuksia, vaan aikaisemmassa kehitysvaiheessa lisättyjä ominaisuuksia pyritään stabiloimaan. Stabiloinnilla tarkoitetaan sitä, että uudet ominaisuudet pyritään saada niin luotettaviksi kuin mahdollista. Käytännössä siis eliminoidaan käytössä havaittuja bugeja, ongelmia ja muita uuden ominaisuuden suoritusta heikentäviä tekijöitä. Jäädytysvaiheessa QGISistä ei yleensä julkaista kuin 1-2 Patch-versiota.

Jotta QGIS pysyisi mahdollisimman stabiilina ja luotettavana, tulisi käyttäjien aina laatia bugiraportti kohtaamistaan ongelmista. Ilman raportointia kehittäjät eivät välttämättä edes tiedä ongelman olemassaolosta, eikä bugi näin ollen katoa! Kerron lisää QGISin bugiraportoinnista artikkelin lopussa.

Julkaisuvaihe (release phase)

Julkaisuvaihe on QGIS-ohjelmistokehityksen viimeinen vaihe. Tässä vaiheessa QGISiin on lisätty uusia ominaisuuksia ja nämä ominaisuudet on stabiloitu niin hyvin kuin mahdollista. QGIS ja sen uudet stabiloidut toiminnallisuudet siirtyvät paketointiin ja lopuksi se julkaistaan myös loppukäyttäjän saataville. Tässä kehityksen loppuvaiheessa QGISistä julkaistaan Minor-versio, joka sisältää kaikki kehitysvaiheessa lisätyt ja jäädytysvaiheessa stabiloidut uudet ominaisuudet. Kun julkaisu on tehty, koko prosessi alkaa alusta ensimmäisestä vaiheesta ja versionumerointi etenee 0 Patch-versiosta eteenpäin. Esimerkiksi QGIS-versio 3.10.0 on kehitysprosessin lopputuote, josta alkaa jälleen uusi kehityssykli.

QGISin kehitys perustuu aikajänteisiin

Jokaiselle edellä mainitulle vaiheelle on määritelty tietty aikajänne, minkä aikana vaihe tulee aloittaa ja saatta loppuun. Tällä vältetään “lipsumista”, kun jokaisesta vaiheesta on olemassa deadline. QGISin kehitys on suunniteltu niin, että joka neljäs kuukausi julkaistaan uusi QGISin Minor-versio. Kehitysvaiheeseen pyritään varaamaan kolme kuukautta (3 x 4 viikkoa) ja jäädytysvaiheeseen yksi kuukausi (1 x 4 viikkoa). Julkaisuvaihe pyritään tekemään samanaikaisesti seuraavan kehitysvaiheen alun kanssa.

Bugiraportin laatiminen

Kun QGIS siirtyy jäädytysvaiheeseen, on aika laittaa kokeiluhattu päähän ja lähteä oikein urakalla testaamaan QGISin uusimpia ominaisuuksia! Mistä sitten uusimman ominaisuudet oikein löytää? Eri QGIS-versioiden muutoksista pidetään kirjaa muutoslokissa (changelog). Tätä kautta voi napsia testiin juuri sinua kiinnostavia uusia ominaisuuksia.

Kuten aiemmin mainitsin, QGISin jäädytysvaiheessa kehittäjät pyrkivät stabiloimaan uusimman version ja sen uudet ominaisuudet. Bugien kokonaisvaltainen korjaus on kuitenkin haastavaa ilman käyttäjäyhteisön tukea, minkä vuoksi bugiraporttien laatiminen on äärimmäisen tärkeää. QGISin kohdalla raportointi on pyritty tekemään mahdollisimman helpoksi, sillä raportti laaditaan valmiille bugiraporttipohjalle QGISin GitHubissa. Raporttipohja sisältää kaiken tiedon siitä, mitä sinun tulee kertoa kehittäjälle, jotta bugi saadaan nitistettyä.

Jos bugiraportin kirjoittaminen englanniksi tai GitHubin käyttö ei jostain syystä luonnistu, QGISin bugilöydöistä voit kertoa myös esimerkiksi Gispon tukipalvelussa! Tukipalvelussa haluamme tietää etenkin käyttämäsi QGIS-version, käyttämäsi aineiston sekä mahdollisimman tarkan ohjeistuksen miten saisimme replikoitua bugin vielä itse (= eli kerro mitä teit, että sait bugin näkyviin QGISissä).

Bugiraportteja saa ja pitääkin kirjoittaa aina, kun löydät ohjelmistosta jotain hämärää – jäädytysvaihe on tavallaan vain tehovaihe, jossa kehittäjät keskittyvät uusien ominaisuuksien bugikorjauksiin ja stabilointiin. Avoimen lähdekoodin QGIS-ohjelmiston kunnossapito ei ole vain kehittäjien työtä, vaan vastuu kuuluu myös käyttäjille!

Lähteet:

https://www.qgis.org/en/site/getinvolved/development/roadmap.html#

https://www.qgis.org/en/site/forusers/visualchangelogs.html

Viimeistään taloudellisesti vaikeina aikoina organisaatioiden on etsittävä kustannussäästöjä toimintojen varmistamiseksi. Jos kustannuksia pitäisi nipistää pois myös paikkatietoprosessien saralla, mitä organisaatiot voisivat karsia ja tehostaa? Gispon asiakkaat ja yhteistyökumppanit kysyvät usein, minkälaisia kustannussäästöjä avoimen lähdekoodin paikkatietoratkaisut synnyttävät pitkällä tähtäimellä ja mistä säästöt syntyvät suhteessa eri suljetun lähdekoodin (eng. proprietory) paikkatieto-ohjelmistovalintoihin. Usein keskustelu kohdistuu seuraaviin kolmeen pääsääntöön, jotka pätevät niin julkisen kuin yksityisen sektorin piirissä:   

1. Katse ohjelmistovalintoihin: lisenssikustannukset kuriin
2. Tuottavuuden kasvattaminen avoimuudella: avoimilla ohjelmistolisensseillä ja lähdekoodilla voidaan räätälöidä organisaatiokohtaisia ratkaisuja tehokkaasti
3. Palvelutoimittajien kilpailuttaminen: yhdestä palvelutoimittajasta useampaan

Nämä kolme sääntöä auttavat näkemään kokonaisuuden yleisellä tasolla. Organisaatioiden tilanteet vaihtelevat tosin suuresti, jolloin Gispossa selvitämme tarkemmin, mitä eri ohjelmistovalinnat tarkoittavat kustannuksina. 

Paikkatietoarkkitehtuureja joka lähtöön

Syventyessämme organisaatiokohtaisiin analyyseihin, käymme läpi kysymyksiä, kuten:

• Mitä erilaisia paikkatiedon käyttötapauksia organisaatiossa on?
• Minkä suuruinen organisaation paikkatietotiimi on?

Näin voisi syntyä esimerkiksi seuraavanlainen arkkitehtuurikuvaus:

Tässä kyseessä on pelkästään avoimen lähdekoodin paikkatieto-ohjelmistoja hyödyntävästä hypoteettisestä organisaatiosta. Asiakkaillamme on kylläkin tilanteita, joissa paikkatietoinfrastruktuuri on hybridi eli käytössä on niin avoimen kuin suljetun lähdekoodin ohjelmistoja, jolloin onkin selvitettävä, mikä ohjelmistojen kombinaatio on sopivin.

Miten kustannussäästöt sitten syntyvät?

Palataan taas takaisin ohjenuoriin ja alkuperäiseen kysymykseen, mistä kustannussäästöjä saadaan? Ensimmäiseksi, jättämällä pois suljetun lähdekoodin paikkatieto-ohjelmistoihin liittyvät lisenssikustannukset säästetään merkittävästi. 

Sitten tuottavuushyödyt toiminnanvapaudesta: myös organisaation paikkatietoratkaisujen tuottavuus kasvaa, koska avoimen lähdekoodin ohjelmistot mahdollistavat toiminnanvapauden ja siten omien paikkatietoratkaisujen räätälöimiseen ja innovoimisen organisaatiokohtaisissa toimintaympäristöissä. Innovoimisen lisäksi ei voida painottaa tarpeeksi sitä, kuinka suuria kustannushyötyjä organisaatiot saavat siitä, että avoimen lähdekoodin ohjelmistoja voi helposti kytkeä olemassa oleviin IT-arkkitehtuureihin. Usein tämä on jopa mahdotonta suljetun lähdekoodin paikkatietoratkaisujen kanssa, mikä tarkoittaa sitä, että ohjelmistojen kytkemisen sijaan, on hankittava kokonaisia ohjelmistoperheitä, jotta paikkatietoratkaisuista saadaan kokonaisvaltaisia. Tässä tärkeitä seikkoja ovat muun muassa avoimien rajapintastandardien eli Open Geospatial Consortiumin (OGC) asettamien standardien noudattaminen ja myös se, että avoimen lähdekoodin ohjelmistojen usein sallivat lisenssit mahdollistavat organisaatiokohtaisten ratkaisujen näppärän räätälöimisen modernin ohjelmistokehityksen periaatteita noudattaen.

Tuottavuutta kasvattaa myös mahdollisuus skaalata paikkatieto-ohjelmistojen käyttöä: QGISin voi asentaa vaikkapa kaikille organisaation tietokoneille ja paikkatietotietokantoja tai -palvelimien määrää ja kapasiteettia voi lisätä tarpeen mukaan ilman yllätyksellisiä lisäkustannuksia käyttömäärien kasvaessa. 

Lopuksi, avoimen lähdekoodin palveluntarjoajat toimivat vapailla, ei-rajoitetuilla markkinoilla, tarkoittaen että lisäarvopalveluiden, kuten konsultoinnin, koulutuksen ja tukipalveluiden, tarjoamista tai niiden hintaa ei voida rajoittaa yhden palveluntarjoajan tai ohjelmistotalon  puolesta. Tämä itsessään kasvattaa kilpailua ja siten tasapainottaa palveluiden hintoja. kilpailuttamisen mahdollisuuksia    tarjoamista  suljetun lähdekoodin paikkatieto-ohjelmistoihin liittyviä lisäarvopalveluita, kuten konsultointi-, koulutus- ja tukipalveluita, voi hyvin harvoin hankkia useammalta palveluntuottajalta, jolloin tilaajan on ostettava palveluita tai ohjelmistokokonaisuuksia vain yhdeltä toimittajalta ilman mahdollisuutta kilpailutukseen.

Kustannusten kasvaminen pitkällä tähtäimellä

Jos halutaan analysoida avoimen ja suljetun lähdekoodin oletettavia kustannuksia yllä olevan hypoteettisen paikkatietoarkkitehtuurin  näkökulmasta, eriytyisivät kustannusrakenteet todennäköisesti kasvavia kustannuksia analysoivan seuraavan kaavion mukaisesti.    

Graafissa on esitetty arvioidut kulut suomalaiselle keskiverto paikkatiedon hyödyntäjäorganisaatiolle, joka tarvitsisi käyttöönsä paikkatietokannan, GIS-sovelluspalvelimen, GIS-työasemaohjelmistoja ja selainpohjaisen paikkatietojen visualisointiratkaisun. Kaaviossa on kuvattu kumulatiiviset kustannukset avoimen lähdekoodin ja suljetun lähdekoodin ohjelmisto- ja IT-infrastruktuurivalinnoille paikkatiedon toimialalla. Näin avoimen ja suljen lähdekoodin käyrät kuvaavat, miten kustannuksien yhteenlaskettu summa viidennen vuoden päätteeksi eroaa kummankin ohjelmistostrategien suhteen. 

Käyrien väliin jäävä osio kuvaa vuosi vuodelta kasvavia kustannussäästöjä avoimen lähdekoodin ohjelmistovalintojen hyväksi. Tässä mielessä organisaatioiden paikkatietotiimien ja hankintaosaston on pystyttävä katsomaan pitkän tähtäimen kustannusrakenteita, ja etsiä kustannussäästöjä ja tuottavuushyötyjä useamman vuoden aikasäteellä. 

Kustannukset eri vaiheissa ja eri palveluista 

Tehdessä strategisia päätöksiä ohjelmisto- ja IT-infrastruktuurivalinnoissa, voidaan jakaa kustannukset eri kategorioihin, kuten ohjelmistojen käyttöönotosta, kouluttamisesta, tukipalvelusta, ohjelmitsojen ylläpidosta ja lisensseistä syntyvistä kustannuksista. Avoimen lähdekoodin paikkatieto-ohjelmistoja hyödynnettäessä esimerkiksi seuraavanlainen kustannusrakenne viiden vuoden aikasäteellä olisi todennäköinen. 

Taulukosta huomataan, kuinka ensimmäiseen vuoteen kasautuu suurimmat investoinnit kuten minkä tahansa IT-hankinnan tapaan. Ensimmäisen vuoden jälkeen kustannusrakenne tasaantuu eikä ohjelmistojen lisensseistä synny kustannuksia.

Arvioi nyt omaa organisaatiotasi

Nyt voidaan taas palata kolmeen kustannussäästön periaatteisiin ja arvioida oman organisaation paikkatietoinfraa: 

1. Lisenssi- ja ylläpitokustannukset:
   1. Arvioi organisaation käyttämiä ohjelmistoja, ja jätä pois korvattavissa olevat lisenssi- ja ylläpitokustannuksia aiheuttavat ohjelmistot.
2. Tuottavuus:
   1. Panosta tuottavuuden kasvattamiseen työvoiman osaamisen kerryttämisellä. 
   2. Käytä ohjelmistoja, jotka mahdollistavat ohjelmistojen ja ohjelmointikirjastojen räätälöimisen organisaation omiin tarkoituksiin kustannustehokkaasti ja ilman ajautumatta ongelmiin muun muassa suljetun lähdekoodin ohjelmistoihin liittyvien lisenssien kanssa. 
3. Kilpailutus:
   1. Kilpailuta ostopalvelusi ja ohjelmistosi usealla palveluntarjoajilla ja ohjelmistotoimittajilla. 
   2. Älä ajaudu yhden toimittajan lock-in tilanteeseen, jossa et voi kilpailuttaa käyttämiäsi ohjelmistoja ja palveluita.

Mikäli sinua kiinnostaisi tutkia organisaatiosi paikkatietostrategiaa ohjelmistovalintojen ja kustannusrakenteiden suhteen, me Gispossa autamme myös näiden strategisten päätösten valmistelussa. Voimme aloittaa lyhyellä palaverilla organisaationne nykytilan kartoittamiseksi ja kustannussäästömahdollisuuksien tunnistamiseksi. 

Jos haluat vielä itse tutkia suomalaisen julkishallinnon tekemiä paikkatieto-ohjelmistoihin liittyviä ICT- ja muita hankintoja, voit tutustua valtion ja kuntien hankintoihin valtiovarainministeriön ja Hanselin ylläpitämästä tietopalvelusta: https://tutkihankintoja.fi/

Meillä on ollut tänä keväänä aivan mielettömän kiva projekti käynnissä! Ollaan opittu hirveästi uutta, saatu tehdä tiiminä hommia juuri omien vahvuuksien kautta ja tehty karttoja, mikä parasta!

Uudenmaan liitto, Varsinais-Suomen liitto ja Turun kaupunki pyysivät toteutuksia Pohjoisen kasvuvyöhykkeen alueen esittelystä karttapohjaisesti ja wau-efekteillä ryyditettynä. Gispon Topi ja Joona pistivät kehityshanskat käteen ja meillä on nyt suunniteltu toinen toistaan upeampia visualisointeja Pohjoisen kasvuvyöhykkeen alueen liikkumisesta, työpaikoista ja vapaa-ajasta. 

Ensimmäisenä toteutuksena julkaistiin Itämeren aamu- ja iltapäiväruuhkia esittelevä laivavisualisointi, jossa hyödynnetään laivojen AIS-signaalia. Se on niin hypnoottista, että tätä voisi tuijottaa vaikka koko päivän. Data kerätään edellisen 24 tunnin ajalta ja eri laivatyypit Suomen aluevesillä seilaavat kartalla yötäpäivää. Aineistot ovat Traffic Management Finlandin avointa dataa. Mukana visualisoinnissa esitelty myös rahtimääriä kasvuvyöhykkeen satamissa.

Kaikki visualisoinnit julkaistaan Pohjoisen kasvuvyöhykkeen tietopalvelussa, joka on toteutettu avoimen lähdekoodin ohjelmistolla nimeltä Kepler.gl. Keplerin kehityssivustolla voi kokeilla myös itse testidatan kanssa miten Kepler toimii. 

Meillekin Kepler oli ihan uusi tuttavuus ja se osoittautui erittäin monipuoliseksi paikkatiedon visualisointityökaluksi. Sen avulla voi renderöidä esimerkiksi isosta datamassasta kaarivisualisointeja ja Topin rakastamia hunajakennoja. Kepler hyödyntää MapBoxin taustakarttoja ja niihin projektissa tehtiin myös omia virityksiä visualisointien parantamiseksi. 

Ainoa ongelma oli, että Kepleristä puuttui kielituki. Noh, Joona vähän käpisteli konepellin alla ja hauskasti suomenkieli oli hetken Keplerissä englannin lisäksi ainoa toinen kielimahdollisuus! Nopeasti sinne on tullut lisäksi myös portugali, espanja ja katalaani, eli muutkin ovat alkaneet hyödyntää kielitukea. Muutenkin tehtiin pieniä aineistoihin liittyviä vimpaimia, joilla saadaan paremmin esiteltyä aineistojen visualisointeja. Niistä myöhemmin lisää.

Projektissa oli mahtavaa päästä työskentelemään hyvinkin aktiivisessa kehityksessä olevan Keplerin kanssa. Oli erityisen hienoa huomata, että kaikki löytämämme kehityskohteet otettiin lämmöllä vastaan ja osa niistä ehdittiin toteuttamaan projektin aikana. Myös toteuttamani kielisyystuki lähti leviämään kulovalkean lailla. Kepler on toteutettu paitsi visuaalisesti näyttäväksi ja käyttöliittymältään monipuoliseksi, myös helposti laajennettavaksi ja käyttöön otettavaksi omassa sovelluksessa. Kattavan dokumentaation ja hyvien esimerkkien avulla Keplerin räätälöinti projektin tarpeisiin sujui suoraviivaisesti ja nopeasti.

Joona Laine, Gispo

Voisin melkein sanoa, että tämän tyyppinen projekti on itselleni unelmaprojekti. Päästään rakentamaan jotain uutta ilman teknologiarajoitteita ja käyttämään omaa luovuutta aineistojen informaatiomuotoilussa. Avoimia aineistoja ja asiakkaan hankkimia aineistoja yhdistelemällä voidaan analyysien ja visualisointien kautta löytää jotain kokonaan uutta ja informatiivista.

Topi Tjukanov, Gispo

Visualisointeja on tarkoitus julkaista pikkuhiljaa, joten herkkua on luvassa infografiikan ja giffereiden janoajille jatkossakin. Seuraa siis esim. Kasvuvyöhykkeen Twitter-tiliä, niin saat uusimmat visualisoinnit heti tietoosi. 

Projektin tavoitteena oli Pohjoisen kasvuvyöhykkeen ihmis- ja liikennevirtojen visualisoiminen kartalla tuoreella ja näyttävällä tavalla. Tehtävä oli haastava, mutta projektitiimi onnistui teknisessä toteutuksessa ja etenkin informaatiomuotoilussa yli odotusten!

Antti Vasanen, tietopalvelupäällikkö, Varsinais-Suomen liitto

On ollut innostavaa, miten hienosti projektitiimi on pystynyt tekemään näkyväksi kiinnostavilla datan visualisoinneilla koko Suomen pärjäämiselle oleellisen vyöhykkeen ominaisuuksia. Erityisesti koronan aikanakin on tärkeää, että keskeiset satamamme ovat toiminnassa ja vastaavat koko Suomen huoltovarmuudesta. Pohjoisen kasvuvyöhykkeen yhteistyöverkosto perustuu kumppanuuksille yhteisten haasteiden ratkaisemiseksi. Sellaiselle on erityisen suuri tarve juuri nyt.

Marjo Uotila, yhteysjohtaja, Turun kaupunki

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

1. 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.
2. 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.
3. 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). 
4. 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:

1. ST_Length-funktio laskee viivan pituuden, kun taas sen sisälle asetettu ST_intersection-funktio ristiinleikkaa teiden geometriat (r.geom) osavaltioiden monikulmiogeometrioilla (s.geom).
2. 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. 
3. WHERE-ehdon sisälle on asetettu ehdot, joiden avulla filtteroidaan lähtöaineistoja. ST_Intersects-funktio  antaa tuloksena totuusarvon sen mukaan, ristiinleikkaavatko paikkatietogeometriat toisensa. 
4. 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.