Mikä se GeoServer oikein on?

GeoServer on avoimen lähdekoodin palvelinohjelma paikkatietoaineiston jakamiseen. GeoServer julkaisee dataa monista eri paikkatietolähteistä avoimia standardeja käyttäen ja se sallii käyttäjien tarkastella ja muokata dataa. Oiva keino siis saada kaikki ilo irti geospatiaalisesta datasta ja sen eri käyttömuodoista!

Kenelle GeoServer sopii?

Kenelle tahansa, joka haluaa saada kaiken hyödyn irti paikkatietopohjaisesta datasta ja sen jakamisesta rajapinnalla! GeoServer on kaikessa monipuolisuudessaan kuitenkin todella helppokäyttöinen. GeoServeriä voivat hyödyntää muun muassa kuntatyöntekijät, kehittäjät, konsultit, tutkijat ja kansalaiset! GeoServer taipuu siis monen eri paikkatietoa hyödyntävän sektorin tarpeisiin, oli kyse sitten paikkatiedon luomisesta ja analysoinnista tai paikkatiedon jakamisesta.

Helppokäyttöinen käyttöliittymä

Kevyenä aloituksena esittelemme GeoServerin graafisen käyttöliittymän rakennetta. Tässä näemme kuvan GeoServerin etusivusta, kun emme ole vielä kirjautuneet sisälle tunnuksilla. Tästä jo pystyy hyvin havainnoimaan GeoServerin rakennetta. Käyttöliittymässä ei kuitenkaan vielä näy GeoServerin lukuisia eri toimintoja, mutta kirjautumisen jälkeen nämä tulevat näkyviin. Verrataanpas siis, miltä GeoServer näyttää sisäänkirjautumisen jälkeen!

Tältä GeoServer näyttää ennen sisäänkirjautumista:

Ja tältä sisäänkirjautumisen jälkeen. Kuten voimme huomata, niin vasemmalle sivuvalikkoon on ilmestynyt runsas määrä erilaisia toimintoja! Sivuvalikko näkyy kuvassa punaisella vahvistettuna.

Sitten onkin aika sukeltaa syvemmälle GeoServerin maailmaan!

Kaikki alkuun Workspacen ja Storen avulla

Ensin on hyvä ottaa haltuun paikallinen kieli. GeoServerin keskeistä sanastoa ovat: workspace, store ja layer. Workspace on nimensä mukaisesti työtila, eli yksi kokonaisuus, jolla voidaan hallinnoida aineistoja. Sanotaan vaikka, että Gispolan kunnalla on työtila kaavasuunnittelijoille, jonka nimi on “kaava” ja liikennesuunnittelijoille on workspace nimeltä “liikenne”.

Workspacen sisällä voi sitten olla useampi store, eli aineistolähde. Kaavasuunnittelijat tarvitsevat kaavoja ja liikennesuunnittelijat liikennemääriä, joten aineistolähteet ovat näissä workspaceissa erilaiset. Käytännössä store voi olla esimerkiksi PostGIS-tietokanta, GeoPackage-tiedosto tai jopa WFS-rajapinta. Storesta saadaan sitten yksi tai useampi taso. GeoServerissä on myös “Layer Group”, eli ryhmä joka sisältää useampia tasoja. Nämä luodaan GeoServerissä, eli ne eivät tule suoraan aineistolähteestä eli storesta. Gispolan kunnalla Layer Group on käytössä, kun luodaan taustakarttaa, joka koostuu monesta tasosta (tiestö, vesistöt, rakennukset, viheralueet, jne.). Layer Groupin tasoista muodostuva taustakartta jaetaan avoimesti WMS-rajapinnan kautta.

Luovuus valloilleen tyyleillä

Tyylejä on monia. Itse asiassa tyylejä voidaan luoda ja muokata muutamalla eri tavalla GeoServerissä. Oletus on luoda tyylejä SLD, eli Style Layer Descriptor standardin mukaan. Jotkut kokevat SLD:n muokkaamisen hiukan hankalana (siinä on paljon <tägejä> siellä täällä), ja he usein suosivat lisäosan kautta tehtävää CSS-tyylitystä. CSS, eli Cascading Style Sheets on ihmiselle hiukan helpompi lukea ja ymmärtää. Jos haluat tietää lisää CSS-tyyleistä niin lue Gispon blogipostaus aiheesta.

Mitä dataa GeoServer syö?

Tutustutaan seuraavaksi mitä dataformaatteja ja standardeja GeoServer tukee.

Vektori & rasteri

GeoServer pystyy kätevästi käsittelemään niin vektori- kuin rasterimuotoistakin dataa. Koska kertaus on opintojen äiti, niin vektoridatallahan tarkoitetaan dataa, joka sisältää pisteitä, viivoja tai polygoneja, ja rasteridata puolestaan koostuu pikseleistä ja on rakenteeltaan raskaampaa dataa kuin vektorit. Vektoridatan avulla voidaan kuvata esimerkiksi taloja, teitä tai muita kohteita, joita pystytään kuvaamaan geometrisesti. Rasteridata soveltuu esimerkiksi jatkuvien pintojen kuvailuun, korkeusmalleihin ja kaukokartoitusdataan.

Tässä lisätään store, eli vektori-tai rasteriaineiston lähdettä.

Kuten yllä jo annettiin ymmärtää, niin GeoServer osaa lukea useita erilaisia formaatteja. GeoServerin versio 2.25.0 lukee näitä vektoritiedostomuotoja:

GeoPackage
Shapefile (yksittäisenä tiedostona sekä hakemistona)
Java Properties

Sekä näitä rasteritiedostoja:

GeoTIFF
WorldImage
ImageMosaic
GeoPackage

GeoServer osaa myös tuoda dataa seuraavista paikkatietokannoista:

PostGIS
H2

Dataa voidaan myös poimia seuraavista rajapinnoista (eli englanniksi cascaded WFS/WMS/WMTS)

WFS
WMS
WMTS

Tämä ei kuitenkaan ole koko totuus, sillä GeoServerille on paljon laajennuksia (extensions), joilla saadaan helposti tukea monelle muullekin formaatille.

Tuetut OGC standardit

GeoServer tukee monia OGC:n (Open Geospatial Consortium) standardeja:

Web Map Service (WMS) eli karttakuvien rajapinta
Web Feature Service (WFS) eli vektorikohteiden rajapinta
Web Coverage Service (WCS) eli rastereiden raakadatan rajapinta
Web Processing Service (WPS) eli paikkatietoprosessien rajapinta
Catalog Services for the Web (CSW) eli metatietoluettelon rajapinta
Web Map Tile Service (WMTS) eli karttatiilikuvien rajapinta

Tile cachingin eli tiilityksen pariin

Joskus rajapinnan kautta tuleva tieto latautuu hitaasti (eli kartta tarkentuu hitaasti). Silloin yksi tapa nopeuttaa lataamista on luoda “valmiita karttatiiliä”. Ilman mitään tiilitystä rajapinnasta tulevasta tiedosta luodaan jokaisen zoomauksen ja liikahduksen jälkeen uusi kuva. Kun otetaan käyttöön tiilitys, kartta-aineisto pilkotaan paloihin, eli tiiliin, ja rajapinnan kautta haetaan tietoa vain niistä tiilistä, joita karttanäkymässä kulloinkin tarvitaan. Kartta tulee näin näkyviin loppukäyttäjälle nopeammin, sillä joka kerta ei ole tarpeen hakea ja piirtää koko aineistoa. Tämä on iso plussa! Miinuksena taas voidaan mainita, että aineiston päivittyessä pitää käydä luomassa uusia tiiliä, ja jos aineisto on iso ja tiiliä halutaan paljon, niin uudelleentiilitys voi kestää pitkään. GeoServerin käyttöliittymässä on tiilitykselle oma osionsa, jonka nimi on GeoWebCache. Tämä on oma ohjelmistonsa, joka on integroitu GeoServeriin. Siksi myös käyttöliittymä GeoWebCachen puolella on eri näköinen.

Kiinnostuitko?

Jos haluat oppia tekemään itse, tutustu kurssiimme: “Johdanto GeoServerin käyttöön”. Jos taas et halua tehdä itse, niin me Gispolla voimme huolehtia niin GeoServerin pystyttämisessä kuin ylläpidostakin. Ota rohkeasti yhteyttä!

Psst! Gispolla on muitakin blogipostauksia GeoServeristä, täältä näet ne kaikki: www.gispo.fi/tag/geoserver/

Tämän artikkelin on kirjoittanut Anni Jusslin

Kaikki karttapalvelut, jotka käyttävät tai jakelevat rajapintoja, eivät välttämättä ilmoita, jos rajapinnat eivät toimi. Ongelmatilanteista voi kuulla monesti vasta päivien tai viikkojen viiveellä palvelua käyttäviltä asiakkailta, ja ongelmien syyn selvittämiseksi joutuu kahlaamaan virheraportteja ja lokeja läpi käsityönä. Jos rajapintoja on useita kymmeniä tai jopa satoja, ongelmat kasaantuvat. Ideaalitilanteessa rajapinnan omistaja tietää ongelmista ennen käyttäjiä. Tässä artikkelissa esittelemme kaksi ratkaisua, joilla paikkatietorajapintoja ylläpitävien ihmisten työ helpottuu.

Grafana – lähes kaikkea lähes kaikille

Grafana on ekosysteemi, jonka perusperiaate on pohjimmiltaan yksinkertainen: se tekee tietokantaan kyselyitä, joista se piirtää kaavioita. Käyttäjä voi hyödyntää joko Grafanan valmiita kyselyitä tai kirjoittaa koodimuodossa omiaan. Grafanan antamia tietoja ja visualisointeja voi katsella nettiselaimella. Visualisointitavoista löytyvät mm. erilaiset viiva-, pylväs- ja ympyrädiagrammit.

Ekosysteemin pääasiallisella Grafana-ohjelmalla visualisoidaan tietoa, mutta lisäksi Grafanaan kuuluu muita osia, kuten tietokantana Prometheus, jossa tietoja säilytetään ja josta Grafana tekee kyselyitä. Prometheus-tietokannassa voidaan määritellä, kuinka pitkältä ajalta dataa säilytetään. Myös muita tietokantoja voidaan käyttää. Grafanasta löytyy lisäksi kaikenlaista back-endiä monenlaiseen tarpeeseen, myös paikkatietopalveluiden ulkopuolelle.

Grafanan ja Prometheuksen pystyttämiseen löytyy näppärät konttiratkaisut, joiden pystyttäminen on helppoa asiaan perehtyneelle. Mutta kuten aina, mitä monimutkaisempaa asiaa halutaan tehdä, sitä enemmän aikaa saa kulumaan. Grafanalla voi kuitenkin seurata lähes mitä vain, ja monipuolisempien työkalujen (kuten Elastic Stack) käyttö ja pystyttäminen on vielä monimutkaisempaa.

Konttien tarkkailua ja säästöä palvelimissa

Miksi sitten Grafanan pitäisi kiinnostaa ketään? Jos käytössä on esimerkiksi useita palvelimia ja halutaan tietää, tarvitaanko jokaista niistä, Grafanan avulla voi katsoa niiden kuormitusta ja onko osa palvelimista ilman mitään käyttöä. Jo muutamankin turhan palvelimen pois ottaminen tai kapasiteetin vähentäminen voi tuottaa suuren säästön.

Ohjelmiston avulla voidaan myös tarkkailla palvelun saatavuutta: jos vaikka palvelimelta ei saada dataa minuuttiin, Grafana voi hälyttää asiasta ylläpitäjän määrittämään sähköpostiin, porttiin tai web-osoitteeseen. Näin voidaan reagoida nopeasti, mikäli jokin palvelin on kumossa tai muuten jumissa. Käyttäjä voi tietenkin määrittää myös muita raja-arvojen ylityksiä ja alituksia, joista hälytys lähtee.

Olemme käyttäneet Grafanaa myös asiakasprojekteissamme. Äskettäin yhdellä asiakkaallamme oli palvelimella kontteja, joista he halusivat ylläpitoon liittyviä arvoja. Tähän tarkoitukseen käytimme Grafana-Prometheus-C-advisor-yhdistelmää. Pystytimme palvelimelle ensin C-advisor-ohjelman, joka tarkkaili kontteja ja julkaisi niiden tiedot web-serverin tapaan haluttuun porttiin. Tätä porttia Prometheus kävi lukemassa tasaisin väliajoin, tässä tapauksessa kerran 15 sekuntiin. Prometheuksen kannasta Grafana luki datan ja piirsi kyselyiden tuloksista käyriä. Lopulta Grafana näytti tulosten perusteella monta kymmentä parametria konttikohtaisesti – kaikkea muistinkulutuksesta prosessointiaikaan.

Miksi juuri Grafana?

Grafana ei tietenkään ole ainoa ohjelma, jolla tällaisia prosesseja voi tehdä. C-advisorin lukemiseen voi periaatteessa käyttää esimerkiksi Microsoftin PowerBI:tä. C-advisorinkin antama data on lopulta lähinnä nimiä ja numeroita, kuten “C-usage 2,3”, jossa numeroarvo vaihtelee eri aikaväleillä.

PowerBI:hin ja muihin ohjelmistoihin nähden Grafanan etuna on se, että ohjelmisto on avointa lähdekoodia (AGPLv3-lisenssillä) eikä siitä tarvitse maksaa pakollisia kuukausimaksuja. Sen saa pyörimään omaan instanssiin ja asennus käy varsin helposti. Ohjelmistosta löytyy myös valmiiksi hostattu, maksullinen versio, ja siihen voi hankkia käytön tukea.

Merkittävä etu on myös se, että jos tarkkailtavat kontit tai muut kohteet ovat suljetussa verkossa, jonne ei pääse ulkopuolelta, voi Grafanan laittaa samaan instanssiin. Näin asiat pysyvät paremmin turvassa, eikä esimerkiksi palomuuriin tarvitse tehdä muutoksia datan siirtoa varten.

Vaikka me käytämme Grafanaa paikkatietoon liittyvissä prosesseissa, ohjelmistoon voi kytkeä lähes mitä vain, mikä antaa jonkinlaisia numeroita ulos. Grafanan demosivulla voi tutkia ohjelman toimintoja, kuten sisäänkirjautumisten seuraamista, maksujen määrää ja muita muuttujia eri aikavälillä.

Grafanan demo löytyy netistä https://play.grafana.org/

GeoHealthCheck – yksinkertaista rajapintojen seuraamista

GeoHealthCheck on selainpohjainen ohjelmisto, joka tarkkailee paikkatiedon jakeluun tarkoitettuja rajapintapalveluita. Kuten Grafana, GeoHealthCheck seuraa palveluiden saatavuutta, piirtää niistä diagrammeja ja katsoo kuinka nopeasti ne vastaavat erilaisiin kyselyihin. Ohjelmisto on huomattavan yksinkertainen ottaa käyttöön, ja karkeasti voisi sanoa sen tekevän yhden asian ja näyttävän sen yhdellä tapaa.

Käyttäjä voi määritellä, kuinka tarkasti ohjelmisto tutkii rajapintaa. Paikkatietorajapinnoilla on omat logiikkansa, ja GeoHealthCheckiä voidaan käyttää esimerkiksi tarkistamaan WFS-rajapinnasta GetCapabilities-dokumentin ja sieltä muutaman tason tai kohteen. Rajapintaan tehdyt kyselyt näkyvät sivustolla “Probes”-otsikon alla, ja history-kohta näyttää viimeisimmät virheet. Sivulta saa myös täyden raportin kyselyistä.

Serveri ja vähän viitseliäisyyttä

Siinä missä Grafana edellyttää paljon teknistä tietoa seurattavista palveluista (mikä portti on auki serveriin ym.), tarvitsee GeoHealthCheck vain halutun rajapintapalvelun osoitteen.

Ohjelmiston käyttöönotto vaatii serverin ja viitseliäisyyttä – ja jälkimmäistäkin aika vähän. Käyttöympäirstönä voi käyttää useita käyttöjärjestelmiä, sillä se on kevyt eikä vaadi paljoa resursseja.

GeoHealthCheck on luontevinta pystyttää jollekin palvelimelle käyttäen konttiasennusta, joka on tehty käyttäjän kannalta melko suoraviivaiseksi ja voi tapahtua nopeastikin. Nohevimmat käyttäjät voivat ajaa ohjelmistoa kontissa omalta koneeltaan. Tämän jälkeen seurattavat rajapinnat voi joko näppäillä käsin, tai jos rajapintoja on paljon, tuoda JSON:ina.

Ohjelmistossa on myös mahdollisuus luoda eri käyttäjiä ja antaa näille oikeuksia palveluiden tilan seuraamiseksi. Näin palveluiden seurantaan voi käyttää yhtä GeoHealthCheck-instanssia, jota seuraa kokonainen tiimi. (Toinen vaihtoehto olisi pystyttää jokaiselle käyttäjälle oma ohjelmisto.) Käyttäjähallinta mahdollistaa palveluiden näkymisen rajaamisen niin, että osa tiedoista voidaan näyttää julkisesti, osa vain kirjautuneille, tai jopa eri käyttäjille eri palveluita.

Sivuhuomiona mainittakoon, että rekisteröinnin salliminen vaatii hieman säätöä, sillä silloin käytössä pitää olla sähköpostia lähettävä kone, jotta rekisteröinnin vahvistussähköpostit voidaan lähettää. Toisaalta tällaisen koneen käyttäminen on järkevää muutenkin, sillä silloin GeoHealthCheck voi lähettää hälytysviestit suoraan sähköpostiin. Muussa tapauksessa hälytykset voidaan asettaa tulemaan esimerkiksi halutulle nettisivulle.

Kuten Grafana, myös GeoHealthCheck on avointa lähdekoodia ja siihen on mahdollista tehdä omia lisäosia. Ohjelmistoa kehitetään jatkuvasti, ja vaikka se toimii jo nyt mainiosti, se ei ole vielä aivan täydellinen. Esimerkiksi jos käyttäjä haluaa vaihtaa salasanan tilanteessa, jossa ohjelmalla ei ole sähköpostia käyttävää konetta käytössä, joutuu kikkailemaan tarpeettoman vaikeasti JSON-operaatioiden kanssa. Tämän tai vastaavien asioiden korjaaminen ja pienkehittäminen ovat asioita, joita esimerkiksi me Gispolla teemme.

Helpot hyödyt

Ohjelmiston hyödyt ovat selkeät: rajapintojen statuksen näkee helposti ja jos ongelmia ilmenee, niistä saa hälytyksen haluamallaan tavalla. Raportit saa ulos CSV:nä, JSON:ina tai PNG-kuvana. Olemassaolevien rajapintojen testaaminen ja niiden saatavuuden tarkkailu on helppoa. Ohjelmisto mahdollistaa myös live-testaamisen, mikä auttaa kun tekee säätöjä rajapintaan, päivittää GeoServeriä tai on julkaisemassa uutta rajapintaa.

Hälytysten ansiosta ongelmiin voi reagoida nopeammin, ja ongelmien selvittämisessä manuaalisen työn määrä vähenee (esimerkiksiGetCapabilities-raportista ei tarvitse itse kaivaa virheitä, vaan ne näkyvät nätisti eroteltuina selainkäyttöliittymässä). Mitä enemmän rajapintoja on jaossa, sitä enemmän hyötyä ohjelmasta tietenkin on.

GeoHealthCheckin etuna on sen yksinkertaisuus ja havainnollisuus, sekä helposti ymmärrettävä käyttöliittymä. Jos halutaan seurata niitä asioita, joita GeoHealthCheck tarjoaa, ei asiasta kannata tehdä suotta monimutkaista ja virittää Grafanaa tekemään samaa. GeoHealthCheck on suunniteltu nimenomaan paikkatietokäyttöön, mutta sillä voi tarkkailla myös ihan tavallisiakin nettisivuja.

GeoHealthCheckin demo löytyy täältä: https://demo.geohealthcheck.org/

Ruotsin paikkatietomaailman päätapahtuma on karttapäivät, Kartdagar, jonka järjestää Ruotsin kartografinen seura (Kartografiska Sällskapet). Tänä vuonna Kartdagar järjestettiin Göteborgissa 16.-18.4.2024. Osallistujia oli runsaat 650 henkilöä ja näytteilleasettajia 27. Suomesta olivat edustettuina Nordic Geo Center Oy, Terrasolid Oy sekä tietysti Gispo Oy. Kartdagar 2024 ohjelma koostui monipuolisista puheenvuoroista ja työpajoista paikkatietoalalta. Tämän vuoden teema oli “Innovationskraften i geodata” eli paikkatiedon innovaatiovoima. Ohjelmassa korostuivat siten innovaatiot, tekoäly ja uudet teknologiat.

Ohjelma

Kartdagarnan aikataulu on rakennettu lounaalta-lounaalle -konseptilla. Tässä konseptissa jäi aikaa matkustaa tapahtumapaikalle tiistaina aamupäivän aikana, ja kun tilaisuus loppui torstain lounaaseen, saattoi iltapäivän käyttää tapaamisiin, nähtävyyksien ihasteluun tai välittömään kotimatkaan. Tämä olisi oikein toivottava konsepti myös suomalaisiin tapahtumiin välimatkojen ollessa pitkiä.

Ensimmäisen keynote-puheenvuoron piti apulaisprofessori Pontus Wärnestål Halmstadin yliopistosta. Wärnestål kertoi, miten tekoälyavusteisia palveluja pitäisi suunnitella. Luennon keskiössä oli tekoäly, joka muutenkin oli vahvasti esillä tapahtumassa. Myös moni muu puheenvuoro liittyi tekoälyyn tavalla tai toisella.

Suurin osa ohjelmasta oli perinteisiä puheenvuoroja, mutta mukana oli tänä vuonna myös työpajoja sekä yksi paneelikeskustelu. Puheenvuoroja oli monipuolisesti sekä julkiselta että yksityiseltä sektorilta. Valtaosa ohjelmasta oli ruotsiksi, mutta väliin mahtui myös muutamia englanninkielisiä esityksiä.

Esityksistä

Gispon Pekka Sarkola piti työpajan aiheesta “Building an Enterprise GIS workflow with QGIS and PostGIS”. Suositussa työpajassa oli noin 30 osallistujaa. Jälkeenpäin monet halusivat vielä jutella avoimen lähdekoodin ratkaisuista ja gispolaiset saivat vastailla lukuisiin kysymyksiin.

Näyttelyosasto piti Gispon tiimin kiireisenä, mutta myös joidenkin esitysten kuuntelulle löytyi aikaa. Puheenvuorot kertoivat Ruotsin paikkatietoalan kuulumisista ja kertoivat missä alalla mennään. Esimerkiksi Marcus Justesen (Värmdön kunta) puhui aiheesta Webb-GIS 2.0. Justesenin esityksen viestinä oli, että laaja-alainen yhteistyö sekä kunnan sisällä että eri sidosryhmien kanssa on keskeistä rakennettaessa web-pohjaista paikkatietoinfastruktuuria. Useissa kunnissa on käytössä yhteistyössä kehitetty web-karttakäyttöliittymä, HAJK (https://hajkmap.se/). Ruotsissa QGISiä käytetään myös julkisella puolella. Clemens Zuba (Boråsin kaupunki) puhui otsikolla “QGIS i en organisation – Tips som underlättar för användare och administratörer”. Boråsin kaupungissa QGIS on käytössä PostGISiin tallennettujen paikkatietoaineistojen visualisointiin ja hallinnointiin. Käyttövinkkinä Zuba kertoi, miten Boråsissa on räätälöity QGIS käyttöliittymiä erilaisten lisäosien avulla (mm. CustomToolBar ja Menu From Project).

Tapahtuman lopussa toinen keynote-puheenvuoro oli otettu tapahtuman teeman ulkopuolelta ja käsitteli hyvinvointia. Luennoitsija ja pedagogi Ann-Helen Häggrudin otsikkona oli “Hyvinvointia aivojen näkökulmasta”. Puheenvuoron tarkoituksena oli antaa osallistujille hyviä vinkkejä siitä, miten pitää huolta omasta hyvinvoinnistaan. Häggrud kävi läpi erilaiset kemialliset reaktiot, joita aivoissa tapahtuu ja sitä kautta vaikuttavat hyvinvointiin. Tapahtuman aihepiirien ulkopuolelta tullut keynote oli yllättävä, mutta yleisö tuntui pitävän Häggrudin esitystä sekä hauskana että hyödyllisenä.

Tilaisuudessa oli paljon aikaa verkostoitumiselle esitysten välissä (fika on elintärkeä ruotsalainen perinne) sekä iltatilaisuuksissa. Ensimmäisenä iltana oli “utställarmingel”, jonka tavoitteena oli vain minglata (≃kierrellä, tavata ja jutustella, tarjolla voi olla pientä purtavaa ja juotavaa) näyttelyssä, varsinaista jäänsärjentää (Icebreaker) ruotsalaiset eivät näemmä tarvitse. Toisen päivän päätteeksi oli Kartdagsparty, jota saattoi kutsua myös dinneriksi. Alun kuplien jälkeen (minglailua, ilman syömistä) oli tarjolla 3 ruokalajin illallinen. Jälkiruuan jälkeen DJ nosti tehoja ja ruotsalaiset päätyivät tanssilattialle (jokunen suomalainenkin näkyi, vaikka muuta väittäisivät). Suomalaisia euroviisubiisejä valikoimaan ei kuulunut, ja ABBA laulujen sikermä oli aika pitkä.

Osallistujat

Suurin osa osallistujista oli ruotsalaisia paikkatiedon ammattilaisia. Gispon ständille tuli juttelemaan paljon kuntatyöntekijöitä eri puolilta Ruotsia. Myös valtion laitoksista (kuten Lantmäteriet ja Trafikverketillä) oli runsaasti osallistujia Kartdagareilla. Yksityiseltä puolelta etenkin konsulttiyritykset sekä maanmittausalan yritykset olivat edustettuina. Tapahtuma oli opiskelijoille ilmainen ja lisäksi opiskelijoiden oli mahdollista hakea avustusta matkakustannuksiin, joten monet opiskelijat olivat löytäneet tiensä Göteborgiin.

Lopuksi

Tapahtuman viimeisessä sessiossa julistettiin karttanäyttelyn voittajat. Gispolaisten sydämiä lämmitti, että monet kartantekijät olivat hyödyntäneet avoimen lähdekoodin ohjelmistoja (kuten QGIS, Inkscape ja GIMP) karttoja tehdessään. Lopuksi julkaistiin vielä ensi vuoden tapahtumapaikkaa. Seuraavat karttapäivät järjestetään 8.-10.4.2025 Skellefteåssa, Sara Kulturhusin tiloissa. Nähdään siis ensi vuonna Västerbottenissa!

Suomessa on yleisten maanteiden varrella satoja automaattisia liikenteenvalvontapisteitä. Ne tarvitsevat vuosittaista huolto- ja tarkastustoimenpiteitä sekä tarpeen mukaan vikakorjausta. Tästä työstä huolehtii Fintraffic Tie, joka vastaa myös muusta tieliikenteen hallinnasta Suomen maanteillä. Heidän tehtävänään on osaltaan huolehtia turvallisesta ja sujuvasta liikenteestä tieverkolla. Yksi osa tätä kokonaisuutta ovat automaattiset valvontapisteet.

Fintraffic Tie Oy tarvitsee tienvarsilaitteiden hallintaa varten lähtötietoa erilaisista tietolähteistä. Nykyisin tietoa hankitaan eri rajapintojen ja tiedostovaihdon kautta ja tietoja yhdistellään käyttökelpoisempaan muotoon. Toimivaa tapaa kerätä tietoa kentältä ei ole ollut. Mergin Maps -mobiilisovellukseen oli fintrafficilla tutustuttu jonkin verran, ja se vaikutti lupaavalta sovellukselta tähän tarkoitukseen. Mobiilisovellus on täysin yhteensopiva Fintrafficilla jo aiemmin käytetyn avoimen lähdekoodin paikkatieto-ohjelma QGISin kanssa.

Gispon tehtäväksi tuli kehittää konseptitodistus (Proof-of-concept) Fintraffic Tielle eri tavoista ja menetelmistä kerätä, analysoida ja hallita maanteiden tienvarsilaitteisiin liittyvää paikkatietoa ja luoda Mergin Maps -mobiilisovellukselle projektitiedosto, jolla tätä paikkatietoa voitaisiin kerätä ketterästi maastosta ja edelleen jatkokehittää tuleviin tarpeisiin.

Lopputuloksena Mergin Maps -työtila

Projektissa hyödynnettiin ketteriä kehitysmenetelmiä. Viikkopalaverit olivat tärkeässä roolissa, kun kävimme yhdessä läpi tilannetta ja keskustelimme mihin suuntaan projektissa edetään. Projektin lopputuotteena syntyi Mergin Maps -työtila, jota edelleen kehitetään kenttätyön tueksi ja jota voidaan käyttää myös testiympäristönä laajemman käyttöönoton testaamisessa. Projektin aikana tuotettiin myös tärkeitä käyttökokemuksia kokeiltavista työkaluista ja toiminnallisuuksista. Mergin Maps -mobiilisovelluksen työtilojen avulla on tarkoitus kerätä tietoa kentältä automaattisen liikenteenvalvonnan valvontapisteistä, kirjata käytettävyystietoa, syöttää kunnossapitotietoja, tarkastella ja vertailla tietoa sekä liittää valokuvia kohteille.

“Gispon paikkatietoon liittyvä syväosaaminen ja vankka kokemus Mergin Mapsista ja QGISista loi hedelmällisen pohjan projektin läpiviemiselle. Varsinaisen lopputuotteen lisäksi Fintraffic sai paljon vinkkejä ja konsultaatiota miten tämäntyyppinen tiedonkeruu kannattaa toteuttaa.”, Fintrafficin palvelupäällikkö Jussi Nykänen kertoo.

Projektin aikana kerättiin arvokkaita käyttäjäkokemuksia siitä, miten mobiilitiedonkeruun prosesseilla voidaan tuottaa ja validoida tietoa. Ajantasaisen ja validoidun tiedon myötä Fintraffic Tie pystyy edelleen kehittämään dataorientuneempaa päätöksentekoa sekä tiedolla johtamista. Tässä projektissa keskityttiin yhteen mobiilitiedonkeruun käyttötapaukseen, ja lisäksi saatiin paljon uusia ideoita siitä, miten mobiilitiedonkeruuta voidaan soveltaa myös muihin käyttötapauksiin esimerkiksi hankkeiden suunnitteluun ja miten ne voidaan integroida nykyisiin järjestelmiin. Mobiilisovelluksen avulla Fintraffic Tie pystyy tehostamaan tiedon tuotannon prosesseja ja keräämään nopeasti maastosta tärkeää tietoa kunnossapito- ja huoltotoimenpiteistä niin, että tieto on välittömästi käytettävissä myös työpöytäsovelluksissa.

________________________________________

Kiinnostuitko paikkatiedon mobiilikeruusta Mergin Maps -sovelluksella? Tutustu koulutukseemme: Paikkatiedon mobiilikeruu Mergin Mapsilla

Paikkatietoa hyödynnetään monilla aloilla ja yksi kiinnostava ala, jolla näemme paikkatiedon hyödyntämisen lisääntyneen on energia-ala. Siellä paikkatietoa käytetään esimerkiksi hankkeiden suunnittelussa ja hankeviestinnässä. “Käytämme paikkatietoa hankkeidemme koko elinkaaren ajan”, sanoo Myrsky Energian paikkatietoasiantuntija ja hankekehittäjä Saku Saarimaa.

Myrsky on suomalainen tuulivoimaan ja aurinkovoimaan keskittyvä energiayhtiö. Yhtiön kasvu on ollut nopeaa ja sen myötä myös paikkatietojen hallinnan ja siihen liittyvän osaamisen tarve on kasvanut. Gispon ja Myrskyn yhteistyö alkoi pienellä työpajalla, joka järjestettiin Location Innovation Hub:n puitteessa. Työpajassa tunnistettiin, mitä arvoa paikkatiedot tuovat Myrskylle toiminnan eri osa-alueilla. Tämän jälkeen myrskyläisille järjestettiin Johdanto paikkatietoon ja QGISin käyttöön -koulutus. Koulutuksen myötä osaamista kertyi ja paikkatiedon perusteiden lisäksi osallistujille avautui QGISin monipuolisuus työkaluna.

Saarimaa kertoo, että he käyttävät QGISiä ja paikkatietoja monessa tehtävässä. Esimerkiksi tuulivoimahankkeen alussa sitä käytetään suunnitteluun. Hyvän sijainnin löytäminen hankkeelle edellyttää lukuisten aineistojen ja työkalujen hyödyntämistä. QGISin graafinen mallintaja tuo tehokkuutta analyyseihin, sillä sen avulla on mahdollista luoda malleja, jotka ajavat aineistoille monta työkalua ja analyysiä kerralla. Käytettävät aineistot ovat pitkälti avoimia ja Suomen lukuisat avoimet paikkatietoaineistot saavat kiitosta Saarimaalta (sekä meiltä Gispolta!).

Uusien alueiden kartoittamisen ja olemassa olevien hankkeiden suunnittelun lisäksi QGISiä käytetään Myrskyllä infrastruktuurin suunnittelussa. QGISissä suunnitellaan esimerkiksi tielinjauksia sekä hankkeen sisäistä ja ulkoista sähkönsiirtoa.

QGISin tehokäyttäjiä Myrskyllä on viidestä kymmeneen henkilöä, satunnaisia käyttäjiä löytyy myrksyläisistä useita. Analyysityökaluja käytetään paljon, esimerkiksi erilaisten vyöhykkeiden ja buffereiden luominen on keskeisitä työkaluja. Paikkatiedolla on myös tärkeä tukirooli hankeviestinnässä. Karttoja tarvitaan lukuisiin käyttötarkoituksiin. Saarimaan mukaan kartoilla on tärkeä rooli hankkeisiin liittyvässä sisäisessä viestinnässä. Kun pitää keskustella vaikkapa uuden hankkeen sijainnista tai muutoksista suunnitelmissa, on se helpompi tehdä karttojen avulla. Hankeviestinnässä kartat konkretisoivat hankealueita. Ulkopuolisille tahoille esitellään hankkeisiin liittyviä suunnitelmia, ja niiden taustalla olevia selvityksiä ja mallinnuksia. Tällöin karttoja katsovat esimerkiksi kuntatyöntekijä, konsultti ja maanomistaja.

Paikkatietoa kertyy yhden hankkeen aikana paljon, ja sen toimiva hallinta on tärkeää. Monesti on tarpeen siirtää paikkatietoaineistoa joko työntekijältä toiselle tai ulkopuoliselle konsultille. Silloin Saarimaa on suosinut GeoPackage-tiedostomuodon käyttöä, ja sitä käytetäänkin nyt paljon Myrskyllä. GeoPackagen vahvuuksina Saarimaa nostaa esiin projektin, tyylien ja aineistojen tallentamisen samaan tiedostoon, sekä käytettävyyden Selain-paneelin kautta QGISissä.

Myrsky on siis löytänyt tehokkaan työkalun paikkatiedon hallintaan ja analysointiin: QGIS. Paikkatiedon hyödyntämisellä on suuri merkitys tuuli- ja aurinkovoimahankkeiden suunnittelussa sekä niihin liittyvässä hankeviestinnässä. Myrskylle QGIS ei ole vain työkalu, vaan keskeinen osa päivittäistä toimintaa, joka tukee yrityksen kasvua ja kehitystä energia-alalla.

Teemme uusien lisäosien ja toiminnallisuuksien lisäksi myös parannuksia ja kehitystä olemassaolevien FOSS4G-ohjelmistojen ja -sovellusten ytimeen. Viime talvena pääsimme kehittämään QField-mobiilisovellusta.

QField on mobiilisovellus, jolla voi käyttää QGIS-työpöytäohjelmistossa luotuja projekteja maastossa ja esimerkiksi luoda ja editoida kohteita, sekä tuoda aineistot takaisin QGIS:iin. Käytännössä sovellus mahdollistaa vaikkapa kohteiden tietojen päivittämisen (“mikä virkistyskohteen kunto on?”), sijainnin keräämisen suoraan kentältä (“liikennemerkin paikka on tässä”) tai kuvien liittämisen kohteen tietoihin (jolloin työasemalla aineistoa käsittelevät saavat paremman käsityksen kohteesta). Seuraavaksi kerromme lyhyesti projektin vaiheista ja QFieldiin tehdyistä parannuksista.

QFieldin kehitystarpeita

Maanmittauslaitos ottaa QFieldin käyttöön maastokartoitustyössä keväällä 2025. Maanmittauslaitos kehittää nyt uutta maastotietojen tuotantojärjestelmää, jonka yhteydessä QFieldiä on testattu ja tunnistettu esimerkiksi kehitystarpeita sen editointityökaluihin. Tämän vuoksi kaikki projektissamme läpikäydyt tapaukset vaikuttivat ennen kaikkea aineiston editointiin ja uusien kohteiden luomiseen maastossa.

Käytännössä projektin teknisen toteutuksen teki QFieldiä kehittävä OpenGIS.ch, mutta Gispo koordinoi ja testasi ominaisuudet. Aluksi kävimme keskustelua Maanmittauslaitoksen kanssa toiveista ja tarpeista. Näiden pohjalta muotoilimme tarkasti seikat (issue) QFieldin GitHubiin, josta OpenGIS.ch aloitti toimintojen kehittämisen.

Kun korjaukset tulivat sovellukseen, devaajamme pääsivät testaamaan uusia ominaisuuksia, jotta ne toimivat kuten MML:lla oli haluttu. Vaikka QFieldiä voi testata myös tietokoneella, teimme testit älypuhelimella. Pääasiassa maastossa on käytössä puhelin tai tabletti, ja on olennaista, että ominaisuudet toimivat kosketusnäytöllä oikein. Projektia varten kehittäjämme digitoivat esimerkiksi lähiluonnon puita ja muita kohteita.

Uudet ominaisuudet

Uusia ominaisuuksia tuli kehitysprojektin myötä QFieldiin yhteensä neljä.

Undo- ja Redo-napit

QFieldiin luotiin toimintohistoria, johon tallentuvat tasoon tehdyt muutokset. Sovelluksen valikkoon lisättiin nuolet, joilla pääsee toimintohistoriaa eteen- ja taaksepäin. Näin voidaan palata tiettyyn muokkaushistorian hetkeen ja peruuttaa tai tehdä uudelleen toimintoja.

Kosketusnäytön kanssa metsässä esimerkiksi virhepainalluksia tulee hieman herkemmin kuin hiirellä klikkaillessa toimisto-olosuhteissa. Tästä myös Maanmittauslaitokselta projektissa mukana ollut Olli Rantanen oli samaa mieltä: “Muutosten peruminen on tärkeää käyttäjälle, jotta mahdollisista virhetilanteista pääsee sujuvasti palauttamaan tilanteen ennalleen. Esimerkiksi vähän haastavimmissa kenttäolosuhteissa voi vahinkoja käydä tai käyttäjä muuten haluaa palata edeltävään tilanteeseen.”

Toiminnon GitHub-seikka löytyy tästä: https://github.com/opengisch/QField/pull/4849

Editointivaiheen muokkaushistoria

Toinen kehitetty toiminto koskee olemassaolevien kohteiden muokkaamista, esimerkiksi miten muutetaan aluekohteen rajausta tai muotoa. Toiminto mahdollistaa kohteeseen tehtyjen muutosten peruuttamisen ennen kuin ne tallennetaan kohteeseen pysyvästi. Ennen QFieldissä piti perua kaikki kohteeseen tehdyt muutokset, mutta tämän toiminnon ansiosta yksittäisenkin taitepisteen muutoksen voi perua ennen tallennusta. Toiminnon GitHub-seikka löytyy tästä. https://github.com/opengisch/QField/pull/4730

Uuden taitepisteen aloitus lähimmästä sivusta

Tämäkin toiminto koskee olemassaolevien kohteiden muokkaamista. Aiemmin editointi oli QFieldillä hieman hankalaa, sillä käyttäjänäkökulmasta uusi taitepiste meni satunnaiseen kohtaan olemassaolevaa kohdetta. Nyt QFieldin digitointi muistuttaa enemmän QGIS:in digitointia: uusi taitepiste tulee sen sivun keskikohtaan, mikä on sitä lähimpänä. Jos taas lähellä on olemassaoleva taitepiste, kursori alkaa siirtämään sitä uuden taitepisteen luomisen sijaan. Toiminnon GitHub-seikka löytyy tästä: https://github.com/opengisch/QField/pull/4724

Kulman asettuminen valmiiksi määritettyihin asteisiin

Kolmas kehitetty toiminto koskee uusien kohteiden luomista. Toiminto mahdollistaa valmiiden kulmien määrittelyn ennen digitointia, jolloin kohdetta luodessa uusi sivu tulee tässä kulmassa edelliseen sivuun nähden. Esimerkiksi jos tietää, että on tekemässä suorakulmaista kohdetta, voi määrittää 90 asteen kulman valinnaksi ja saada automaattisesti 90 asteen kulmat kohteeseen. Valmiiksi määritellyt kulmat ovat 10, 15, 30, 45 ja 90 astetta. Kulmat voivat olla joko suhteessa näyttöön tai digitoitavaan kohteeseen.

Vaikka kaikki tehdyt muutokset tulivat Maanmittauslaitoksella tarpeeseen, Rantanen nostaa tämän toiminnon Undo- ja Redo-nappien ohella erittäin olennaiseksi parannukseksi: “Samoin hyvin tärkeä ominaisuus on tuo suorakulmaisuuden varmistaminen digitoitavista rakennuksista, jotta maastossa saadaan tarkasti kartoitettua rakennukset. Noiden kulmien asettaminen valmiiksi määriteltyihin asteisiin edesauttaa tätä ja tehostaa kartoittajan työtä.”

Toiminnon GitHub-seikka löytyy tästä: https://github.com/opengisch/QField/pull/4805

Haluaisitko oppia QFieldin käyttöä? Meillä on siihen kurssi: Paikkatiedon mobiilikeruu QFieldillä
QField toimii myös yhteen mittauslaite HappyMiniQ:n kanssa, lue miten tiimimme testasi laitetta kenttämittauksissa.

VOOKA eli Voimassa olevat kaavat rakennetun ympäristön tietojärjestelmään -hanke sai jatkoa ja toteutettiin tällä kertaa Pohjois-Savon maakuntaan. Hankkeessa selvitettiin, miten kaavat siirretään uuteen rakennetun ympäristön tietojärjestelmään (Ryhti). Hankkeen keskeisimpänä tavoitteena on luoda koko Suomen kattava vektorimuotoinen hakemistokartta, jonka avulla alkuperäiset kaava-aineistot on löydettävissä. Pohjois-Savon VOOKA-projekti saatiin päätökseen tammikuussa 2024 ja työn tulokset jatkoivat hyvin käynnistettyä käännöstyötä. Työn lopputuotteena saatiin kerättyä Pohjois-Savon alueelta lähes kaikki oikeusvaikutteiset asema-, ranta-asema- ja yleiskaavat. Koko maakunnasta saatiin kerättyä arviolta noin 78 % kaikista voimassa olevista kaavoista. Jatkohankkeessa luotiin siis yhtenäinen ja topologialtaan eheä paikkatietoaineisto, joka kattaa vajaat 3500 kaavaa. Tämä ylittää koossaan hankkeen pilottiprojektissa Etelä-Savosta kerätyn kaava-aineiston merkittävästi!

Pohjois-Savon toteutuksesta vastasi osittain sama tiimi kuin pilottiprojektissa. Tekijät tulivat Ubigulta, Gispolta ja PlanDisainilta, ja projektia koordinoi Suomen ympäristökeskus (Syke). Lisäksi yhteistyötä tehtiin ympäristöministeriön ja Pohjois-Savon ELY-keskuksen kanssa. Pohjois-Savon toteutuksessa päästiin hyödyntämään pilotista saatuja oppeja sekä työstämään pilotissa havaittuja kehityskohteita eteenpäin.

Pilotissa oli saatu vastauksia kysymyksiin kuten, mistä kaavan ulkorajat saadaan helpoiten, löytyvätkö kaava-asiakirjat ja kuinka kiireiset kuntatyöntekijät ehtivät toimittaa meille aineistojaan. Osa kysymyksistä edelleen mietitytti, esimerkiksi kuinka paljon erilaisia formaatti- ja koordinaattiongelmia paikkatietoaineistoissa tulisi vastaan. Haasteita osattiin tällä kertaa odottaa ja tärkeintä olikin tiimin kyky selättää ne!

Keskiössä hyvä tiimityöskentely

Osaava porukka oli taas onnistumisen avain. Syken Kaarina oli mukana asiakkaan edustajana ja oli koko projektin ajan aktiivisena mukana projektin vetämisessä. Sekä Maanmittauslaitos että kunnat olivat hyvin tavoitettavissa, ja lähes kaikki tarvittavat aineistot saatiin määräaikoihin mennessä. Hankaluudet kaavoissa tai niiden tulkitsemisessa saatiin myös hoidettua nopealla kontaktoinnilla suoraan kuntiin tai MML:n asiantuntijoille. Osa tekijätiimistä oli saanut kokemusta jo pilottiprojektista. Ubigun Samuli toimi mentorina koodauspuolella ja oli jakamassa tietotaitoaan ongelmatilanteissa. Projektipäällikkönä toimi Ubigun Sofia, joka piti projektin hyvin kasassa sekä ohjasi ja toteutti kehitystyötä ja eri työvaiheiden etenemistä. Gispon Ville ja Ubigun Emilia vastasivat kaavojen ja kaava-aineistojen ETL-prosessin kehittämisestä sekä aineiston automaattisesta käsittelystä. Gispon Elisa vastasi kuntien konsultoinnista ja aineiston keruusta sekä aineiston manuaalisesta käsittelystä. PlanDisainin Markus toimi kaava-asiantuntijana projektin eri vaiheissa.

Mitä tuli tehtyä

Projekti tehtiin pilotin pohjalta siten, että esiin nousseita ongelmakohtia ratkottiin kehittämistyön kautta aineiston käsittelyn ohessa. Tarkastelu toteutettiin vain vektorimuotoisille kaavaraja-aineistoille sekä kaava-asiakirjojen osalta jo sähköisessä muodossa oleville aineistoille. Maanmittauslaitoksen kiinteistötietojärjestelmä (KTJ) toimi jälleen vertailuaineistona kunnilta saataville kaavarajatiedoille. Tavoitteena oli selvittää, kuinka yhteneväisiä tiedot ovat ja miten aineistojen vertailu- ja yhdistelyprosessissa voidaan hyödyntää pilottiprojektissa kehitetetyn ETL-työkalun (extract, transform and load) automatisointivaiheita.

Pitkälle hiotusta automatisoinnista huolimatta manuaalista työtä tarvittiin. Kunnista lähetetyt kaavaraja-aineistot tulivat Pohjois-Savossa varsin monipuolisissa formaateissa ja koordinaatistoissa. Kaavoissa ilmeni jonkin verran sisältö- ja geometriatietojen lukuongelmia. Aineistot käännettiin keskenään samaan formaattiin (Geopackage) sekä samaan koordinaattijärjestelmään (EUREF-FIN TM35). Isompien ohjelmallisten ja automaattisten korjausten jälkeen manuaalisia topologia- ja geometriakorjauksia kunnilta saatuihin paikkatietoaineistoihin tarvittiin enää vain noin 100 paikkatietokohteeseen reilusta 5500 kohteesta.

Projektin hyvistä tuloksista huolimatta työtä riittää vielä. Osa vanhoista kaavatiedoista on olemassa vain paperiversioina, hävinnyt arkiston kätköihin tai tiedot olivat vanhentuneita. Kuten pilotissa, Pohjois-Savonkaan osalta ei viisastuttu siinä, kuinka monta kaavaa jäi prosessissa saamatta – olemassa on vain arvioita. Valtakunnallisia VOOKA-projekteja ei tämän jälkeen enää toteuteta, mutta kunnille laaditaan ohje, joiden avulla kunnat voivat tuottaa itse VOOKA-tyyppistä aineistoa tulevaisuudessa. Ohjeistus valmistuu maaliskuun loppuun mennessä. Hankkeessa kehitetyillä työohjeilla pyritään ohjaamaan, miten kaavatietoja toimitetaan jatkossa Ryhti-järjestelmään.

VOOKA toteutettiin Suomen ympäristökeskuksen tilaamana yhteistyössä Ubigun, Gispon ja PlanDisainin kanssa. VOOKAn tavoitteena on tuottaa valtakunnallinen aineisto, joka pitää sisällään kaikki Suomessa voimassa olevien asema- ja yleiskaavojen ulkorajat ja kaava-asiakirjat. Hanke liittyy Suomen ympäristökeskuksen rakennetun ympäristön tietojärjestelmän (RYHTI) kehittämiseen ja alueidenkäytön suunnittelutietojen valtakunnalliseen harmonisointiin. Lue lisää hankkeesta ja sen tuloksista:
https://ryhti.syke.fi/esimerkkeja-ja-toteutuksia/voimassa-olevat-kaavat-tietojarjestelmaan/pohjois-savon-hanke/

Hankkeessa kehitetty ETL-työkalu löytyy Syken GitHubista:
https://github.com/sykefi/vooka

Tämän artikkelin on kirjoittanut Ville Hamunen.

Maanmittauslaitoksen ilmakuvarekisterin uusin versio, jota Gispo on ollut mukana kehittämässä, on otettu alkuvuodesta tuotantokäyttöön. Uusimmassa versiossa ilmakuvien pysyväisarkisto muodostaa kiinteän osan järjestelmää ja mahdollistaa näin ilmakuvien metatietojen sekä itse ilmakuvien saumattoman yhteiskäytön tuotannon ja arkiston välillä.

Uuden ilmakuvarekisterin kokonaisratkaisun ydin on ollut PostGIS-tietokanta ja sen QGIS-lisäosana toteutettu käyttöliittymä. Tietokannassa on noin 1,3 miljoonan ilmakuvan metatiedot koskien kuvattuja alueita, kuvauslentoja sekä itse ilmakuvia ja niiden yhdistelmistä tehtyjä ortokuvia. Nyt käyttöliittymän avulla päästään käsiksi metatietojen lisäksi myös itse ilmakuvien pysyväisarkistoon.

Turun kaupunki vuonna 2023 kuvattujen ilmakuvien perusteella tehdyssä ortokuvassa.
Ortokuvia voi ladata maksutta Karttapaikan tiedostopalvelusta.

Rajapinta yhdistää ilmakuva-aineiston ja sen metatiedot toisiinsa

Ilmakuvarekisterin uusin tuotantokäyttöön otettu osa on ilmakuvien pysyväisarkisto, jossa taltioidaan varsinainen ilmakuva-aineisto. Pysyväisarkistolla oli aikaisemmin oma irrallinen käyttöliittymänsä, ja kuva-aineistoja sekä niitä koskevaa tietoa tallennettiin eri prosesseissa eri paikkoihin. Uuden, ilmakuvarekisterin käyttöliittymästä hyödynnettävän rajapintaratkaisun avulla ilmakuvat on mahdollista viedä pysyväisarkistoon samasta käyttöliittymästä kuin, missä niiden metatietojakin hallinnoidaan. Rajapinnan kautta voidaan samaan tapaan myös hakea ilmakuva-aineistoa metatietojen perusteella.

QGIS-käyttöliittymä säästää usein päivien työn

Suuren tietovarannon tehokasta hyödyntämistä varten ilmakuvarekisterille tarvittiin käyttäjiä mahdollisimman hyvin palveleva, selkeä ja moderni käyttöliittymä. Koska kyseessä on nimenomaan paikkatietoaineiston hallinnointiin tarkoitettu ammattilaisjärjestelmä, QGIS tarjosi käyttöliittymälle erinomaiset lähtökohdat. Paitsi että QGIS tarjoaa jo perustoiminnallisuuksiensa puitteissa paljon valmista, kehitystyössä käytettiin jonkin verran myös avoimen kehittäjäyhteisön tekemiä pieniä komponentteja.

Käyttöliittymä toteutettiin QGIS-lisäosana, jonka avulla käyttäjä voi yhdistellä aineistoja eri lähteistä, tehdä monipuolisia hakuja ilmakuvien metatietoihin ja nyt viimeisimmässä vaiheessa myös hakea niiden perusteella kuvia pysyväisarkistosta. Käyttöliittymässä voi myös georeferoida historiallisia ilmakuvia. Toiminto on välttämätön historiallisten ortokuvien tuotannossa. Monipuolisten toiminnallisuuksien avulla ja niitä yhdistelemällä käyttäjä voi usein säästää jopa päivien työn aiempiin, eri järjestelmien ja paperilappusten välillä tapahtuviin työvaiheisiin verrattuna!

MML:n demovideolla näytetään miten ilmakuvarekisteristä voidaan metatietojen perustella hakea pysyväisarkistossa olevia ilmakuva-aineistoja.

QGIS-lisäosalla saatiin toteutettua vakaa ja monipuolinen käyttöliittymä, joka ei vähästä hätkähdä. Ympäristö toimii MML:n Citrix-palvelimella, joka jaksaa hyvin pyörittää suuriakin aineistomääriä.

Hyödyt käytettävissä nyt vuosiksi eteenpäin

Ilmakuvarekisteriä on kehitetty Maanmittauslaitoksella reilun kahden vuoden ajan. Työ on sisältänyt paljon määrittelytyötä sekä vanhojen tietokantojen rakenteiden läpikäyntiä ja siivoamista. Työtä on tehty Maanmittauslaitoksen sisälle kootun tiimin voimin, jossa myös Gispo on ollut mukana. Johtava asiantuntija Mikko Sippo MML:ltä toteaa, että etenkin työn alkuvaiheessa Gispon asiantuntijat olivat erittäin keskeisessä roolissa. Myös Gispolta mukana ollut Jaakko Lehto kehuu projektia opettavaiseksi ja sanoo itsekin saaneensa siitä monia uusia taitoja ja ideoita.

Kehitystyötä läheltä seurannut Sippo kiittelee sekä kehitystiimiä että kollegoita hyvästä sitoutumisesta yhteiseen projektiin, jonka uskotaan helpottavan ilmakuviin liittyvää työtä vuosiksi eteenpäin. Vaikka tehtävää on ollut paljon ja se on usein tuntunut tulevan oman “varsinaisen” työn päälle, kaikki ovat jaksaneet olla hyvin hengessä mukana ja opetella uusiakin ajattelu- ja toimintatapoja matkan varrella.

Juuri tällä hetkellä järjestelmässä ei nähdä seuraavia isompia kehitystarpeita, vaan nyt keskitytään käyttöönottoon. Jatkokehitystarpeita ja -ideoita tulee varmasti eteen, mutta nyt voidaan hetken aikaa vain nauttia tehdystä työstä, Mikko Sippo toteaa tyytyväisenä.

Tämän artikkelin on kirjoittanut Linda Talve.

GeoPackage-tiedostoformaatin näppäryyttä on hehkutettu blogissamme useaan otteeseen, eikä suotta. Geopackage on erittäin kätevä työkalu – voit pakata siihen yhteen näppärään pakettiin useita tasoja, tasojen tyylejä ja vaikkapa koko QGIS-projektisi ja jakaa tiedoston sellaisenaan esimerkiksi sähköpostin välityksellä. Jos GeoPackage on vielä vieras, käy lukemassa blogikirjoitus muutaman vuoden takaa: Kätevä GeoPackage – mikä se on?

Törmäämme silloin tällöin epäröintiin, voiko GeoPackageen tallentaa rasteridataa – kyllä voi! Eikä edes tarvitse osata niitä kuuluisia koodiloitsuja. Tarkastellaan nyt, miten taso, tyyli, projekti ja ortokuva tallennetaan GeoPackageen.

GeoPackagen valmistelu

Avataan uusi QGIS-projekti ja lisätään siihen WMS-yhteydellä jokin ortokuva. Tässä esimerkissä on käytetty Maanmittauslaitoksen tarjoamaa WMS-ortokuvapalvelua. Sen käyttöön tarvitset API-avaimen, jonka saa pyydettyä Maanmittauslaitoksen nettisivujen kautta (https://www.maanmittauslaitos.fi/rajapinnat/api-avaimen-ohje ). Mikäli käytät jotakin API-avainta vaativaa palvelua usein, avain kannattaa tallentaa QGISiin. API-avaimen tallentamiseen löydät ohjeet täältä (https://www.gispo.fi/blogi/api-avainten-tallennus-qgisiin/).

Haluamme luoda GeoPackagen, jossa on sekä WMS-yhteys että ortokuva tallennettuna Rauman alueelta. Ortokuvan tallentaminen projektiin on hyvä vaihtoehto, mikäli et ole ihan varma, saatko ladattua kuvaa tarvittaessa WMS-palvelusta, Internet-yhteys on heikko tai työskentelet vain selkeästi rajatun, saman kuva-alueen kanssa. Tallennetaan samaan GeoPackageen myös vesistötasoja ja niiden kuvaustyylit.

Maastotietokannasta saa tuotua aineistoa QGIS-projektiin esimerkiksi NLS GeoPackage Downloader -lisäosalla (https://www.gispo.fi/blogi/maastotietokanta-natisti-q). Maastotietokantalisäosan kautta vesistöalueet tuodaan valitsemalla kunnaksi Rauma ja aineistolajeiksi vesistöihin liittyvät alueet, kuten järvet ja virta-alueet.

Tasojen tallennus GeoPackageen

Luodaan nyt uusi Rauma-niminen GeoPackage ja tallennetaan siihen paikannimi-taso. GeoPackagen voi luoda samalla, kun tallentaa ensimmäisen tason.

GeoServer

Kuva 2. GeoPackagen luominen ja ensimmäisen tason tallentaminen.

Nyt QGISin selaimesta vasemmalta voi luoda uuden GeoPackage-yhteyden, jossa näkyy uusi paikannimi-taso.

Tason kuvaustyylin tallentaminen GeoPackageen

Kopioidaan paikannimi-tasolle vielä samanlainen tyyli, joka alkuperäisellä Maastotietokannan paikannimi-tasolla on. Klikkaa tasovalikossa oikealla vanhan paikanimi-tason päällä, ja valitse Tyylit > Kopioi tyyli > Kaikki tyyliryhmät. Sen jälkeen klikkaa oikealla uutta paikannimi-tasoa ja valitse Tyylit > Liitä tyyli > Kaikki tyyliryhmät.

Tallenna myös QGIS-projekti GeoPackageen valitsemalla ylävalikosta Projekti > Tallenna tiedostoon > GeoPackage ja valitse yhteydeksi haluamasi gpkg-tiedosto. Voit nyt avata QGISin uudelleen varmistaaksesi GeoPackageen vietyjen tasojen toimivuuden ja kuvaustyylien toistumisen. QGIS-projektia kannattaa työn lomassa muistaa tallentaa säännöllisesti.

Kaikki tarvittavat tasot ja kuvaustyylit voi viedä samalla periaatteella uuteen GeoPackageen. Kun GeoPackage on jo ensimmäisen tason tallentamisen yhteydessä luotu, valitaan se klikkaamalla tasovalikossa tasoa oikealla, Vie > Tallenna kohteet nimellä ja Tiedostonimi-kohdassa jo luotu geopackage löytyy …-napin takaa.

Kun kaikki tasot on viety uuteen Rauma-GeoPackageen ja alkuperäiset tasot poistettu projektista, tasovalikko näyttää tältä:

Rasteridatan tallennus GeoPackageen

Kirsikkana kakun päällä tallennetaan ortokuva GeoPackageen. Yksinkertainen työkalu tähän on Muunna kartta rasteriksi, joka löytyy Prosessointi-valikosta Työkalujen alta. Valitse kartta-alue kartalta ”Piirrä karttaikkunaan”-työkalulla. Valitse pikselikooksi vaikkapa 1,50, eli yksi pikseli vastaa tällöin puoltatoista metriä kartalla. Pikselikoon valintaan vaikuttaa projektissa vaadittava tarkkuus ja toisaalta myös ortokuvan laatu. Valitaan vielä renderöitäväksi se taso, josta uusi ortokuva kopioidaan ja painetaan “Suorita”. Tadaa! Nyt voit tallentaa uuden ortokuvatason GeoPackageen samalla tavoin kuin edellä maastotasojen kanssa toimittiin. QGIS ehdottaa ortokuvien kohdalla GeoTIFF-tiedostomuotoa, mutta voit vaihtaa tiedostotyypin GeoPackageen.

Näyttää helpolta, ja niin myös on! Valmiin GeoPackagen kaikkine sisältöineen voi lähettää yhtenä tiedostona eteenpäin. Tämä GeoPackage on kooltaan noin 4 Mt, pakattuna alle 2 Mt. Ei muuta kuin kokeilemaan!

Niin tukipalvelussamme kuin koulutuksissammein kuulemme paljon kysymyksiä, jotka alkavat “Olen ennen käyttänyt ArcGISiä ja nyt haluaisin tehdä tämän saman asian QGISillä. Miten se tehdään?” Useimmiten kysymyksiin löytyy ratkaisu ja asiakas on tyytyväinen. Yleensä siinä vaiheessa, kun joku kysyy kysymyksen ääneen, moni muu on jo ehtinyt miettiä samaa asiaa hiljaa itsekseen. Siksi kokosimme tähän artikkeliin näitä pieniä ja isompia ongelmia ratkaisuineen.

Onko mahdollista käyttää ArcGISillä tehtyjä shapefilejä QGISissä?

ESRI Shapefile on ollut muutaman ~~parin~~ vuosikymmenen ajan suosittu tiedostoformaatti vektorimuotoisen paikkatiedon esittämisessä, joten ei ole ihme, että sen käyttökelpoisuus QGISissä mietityttää. Onneksi voimme vastata, että ESRI Shapefile -tiedostoja voi käyttää suoraan QGIS-sovelluksessa. Tiedoston saa auki avaamalla tason vektoritiedostona esimerkiksi Tasot > Lisää taso > Lisää vektoritaso.

GeoServer

Avautuvasta ikkunasta voi etsiä kolme pistettä -ikonin kautta halutun tiedoston.

Suosittelemme kuitenkin luopumaan ESRI Shapefilen käytöstä, jos se vain on mahdollista. Tarkempia perusteluja voi lukea sivustolta: https://switchfromshapefile.org/. Vaihtoehtoisia tiedostomuotoja ovat muun muassa OGC GeoPackage, FlatGeobuf ja GeoJSON.

Miksi ArcGISillä luotu Geodatabase jumittaa QGISissä?

ESRI Geodatabase -termillä voidaan tarkoittaa monta asiaa, yleensä kysymys koskee ESRI File Geodatabasea (FGDB). FGDB on suljettu formaatti, jonka takia on vaikea tietää, miksi se on hidas QGISin puolella. QGIS käyttää monien muiden paikkatieto-ohjelmistojen (kuten ArcGIS, FME) tapaan GDAL/OGR -kirjastoa erilaisten vektori- ja rasteriaineistojen kirjoittamiseen ja lukemiseen. FGDB:n osalta GDAL/OGR:n on toteutettu kaksi ajuria (driver): ESRI File Geodatabase (FileGDB) ja ESRI File Geodatabase vector (OpenFileGDB). Ensimmäinen vaatii toimiakseen erillisiä kolmannen osapuolen kirjastoja, jälkimmäinen on toteutettu ns. reverse-engineering -toteutuksella (tarkempi kuvaus). Kun tiedostoformaatin kuvaus ei ole julkisesti, avoimesti saatavilla, on hyvin vaikea paikantaa mistä mahdolliset ongelmat johtuvat. Todennäköistä on, että QGIS jumittuminen johtuu enemmän QGIS ja GDAL/OGR:n toteutuksesta, kuin varsinaisesti FGDB:n sisällöstä.

Jos mahdollista, suosittelemme siirtymään OGC GeoPackagen käyttöön. Geopackage on avoin, moderni tiedostoformaatti, joka on tuettuna laajasti erilaisissa paikkatieto-ohjelmistoissa. Olemassa olevan FGDB:n voi muuntaa GeoPackageksi, mutta muunnoksessa voi esiintyä ongelmia, jotka liittyvät muun muassa FGDBn rakenteeseen sekä siihen, miten ja millä muunnoksen tekee. Jatkossa on siis järkevintä tallentaa tieto suoraan GeoPackageen.

Miten rasteriaineistolle luodaan ominaisuustietotaulu QGISissä?

Jos rasteriaineistot ovat vielä vieraita, käy kurkistamassa englanninkielinen blogikirjoituksemme: What are rasters?

Raster Attribute Table -lisäosa mahdollistaa attribuuttitaulun tekemisen rasteriaineistolle QGISissä. Lisäosa luo ominaisuustietotaulun käyttäen hyväksi tasolle tehtyä tyyliä ja siihen sisältyvää luokitusta ja värejä. Lisäosan saa asennettua Lisäosat > valitse kaikki ja kirjoita hakukenttään ”Raster Attribute Table”. Lopuksi paina ”Asenna lisäosa”.

Kun lisäosa on asennettu, vaihdetaan visualisointityyli ”yksikanavainen harmaa” -asetuksesta joko monikanavaiseen väriin, Paletted / unique values tai yksikanavaiseen pseudoväriin. Valinta riippuu aineistosta ja käyttötarkoituksesta.

Pääset visualisoimaan aineistoa esimerkiksi painamalla Tasoluettelossa siveltimen kuvaa.

Kun olet valinnut työhösi sopivan tyylin, klikkaa ”Luokittele” ja QGIS luo luokittelun ja värityksen arvoille.

Tämän jälkeen voit muokata luokittelua esimerkiksi määrittelemällä arvojen väritystä uudelleen tai poistamalla tai lisäämällä arvoja. Jos käytät visualisointina yksikanavaista pseudoväriä, voit määrittää yhdelle värille minimi- ja maksimiarvot ja päättää, kuinka moneen luokkaan aineisto jaetaan ja millä tavalla.

Kun olet valmis, voit luoda attribuuttitaulukon klikkaamalla rasteritasoa hiiren oikealla. Avautuvasta valikosta löytyy nyt ”New Attribute Table”.

QGIS kysyy, mihin formaattiin attribuuttitaulukko viedään. Molemmat tarjolla olevat formaatit avautuvat QGISissä samalla tavalla, mutta jos lähetät aineiston eteenpäin, kannattaa varmistaa kumpi on vastaanottajalle parempi. Attribuuttitaulukko tulee uudeksi tiedostoksi samaan kansioon rasteriaineiston kanssa.

Taulukon tietoja voi muokata samaan tapaan kuin vektoriaineistonkin tapauksessa, eli klikkaamalla kynäikonia attribuuttitaulukon vasemmasta yläkulmasta. Sen jälkeen luokkien nimiä, värien väriarvoja ym. voi muokata tai lisätä uusia sarakkeita. RGBA-kanavat saavat omat sarakkeensa ja myös ne käyvät värin määritykseen: Red, Green, Blue ja Alfa (=läpinäkyvyys).

Miten digitointi QGISillä tapahtuu?

Tähän aiheeseen olemme perehtyneet aiemin blogissamme. Digitoinnin perustyökaluja käsitellään artikkelissa Kaavoitus QGISin digitointityökaluilla (osa I), saman artikkelisarjan toisessa osassa perehdytään digitoinnin lisätyökaluihin.

Lisää oppia?

Mikäli mielenkiintosi heräsi, tule kuulemaan ja kyselemään koulutuksiimme QGISin mahdollisuuksista tai ota ongelmatilanteissa yhteyttä tukipalveluumme. Johdanto QGISin käyttöön sopii hyvin toisesta paikkatieto-ohjelmasta QGISiin siirtyville, tutustu myös muuhun koulutustarjontaamme!

Löysitkö virheen? Jäikö joku vaivaamaan?

Korjaamme mielellämme kaikki epätarkkuudet ja virheet, joita mahdollisesti tekstissä on. Voit varata myös henkilökohtaisen neuvonnan, jos asiasi on arkaluonteinen.