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

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

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

Maakuntakaavat yhteiseen tietomalliin

Tekninen toteutus

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

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

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

Lopputuloksia tutkailemaan

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

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

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

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

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

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

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

OGC-API: Rajapintapalvelujen tulevaisuus paikkatietoalalla

Lue myös GeoPackagesta toisesta blogauksestamme.

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

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

ldproxy

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

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

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

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

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

pygeoapi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GeoPackage-tason luominen ja tasojen ryhmittely QGISissa

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

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

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

Tyylin tallennus GeoPackageen

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

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

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

Maakuntakaavojen yhteiskäyttöisyyttä, erityisesti katselu- ja latauspalveluiden osalta, on valmisteltu ympäristöministeriön ja SYKEn johdolla useamman vuoden ajan harmonisoidut maakuntakaava-aineistot e-aineistoiksi -hankkeessa (HAME). Tavoitteena on saada kaikkien maakuntien maakuntakaavat yhteiseen tietokantaan yhtenäisen tietomallin mukaisena (HAME-tietomalli). Käytännössä tämä tarkoittaa, että maakuntakaavoja on tulevaisuudessa mahdollista tarkastella yhdestä karttapalvelusta myös visuaalisesti yhtenäisinä. Hanke parantaa näin maakuntakaava-aineistojen käytettävyyttä.

Gispo osallistui syksyn ajan HAME-hankkeeseen. HAME-tietomalli syynättiin vielä tarkasti läpi, jotta se vastaa EU:n INSPIRE-direktiivin asettamiin vaatimuksiin. INSPIRE- eli paikkatietodirektiivillä tavoitellaan yhdenmukaisempaa paikkatietoinfrastruktuuria Euroopassa. Samalla keräsimme tarpeita ja toiveita tietomallin kehitykselle maakuntaliittojen suunnalta. Avoimuutta silmällä pitäen tietomallin file geodatabase -formaatin rinnalle tuotettiin myös GeoPackage-versio, jonka avulla maakuntakaavatyötä voi tehdä myös QGIS-ohjelmistolla. GeoPackageen on tuotu valmiit lomakkeet tietojen syöttöä varten, mutta se ei sisällä taulujen välisiä relaatioita, ne kannattaa toteuttaa QGIS-työtilassa.

Myös maakuntaliittojen yhteiset HAME-visualisoinnit käytiin läpi ja korjattiin niiden puutteita. Ymmärrettävät ja yhdessä sovitut visualisoinnit ovat tärkeä osa rajapintapalveluiden vaivatonta käyttöä jatkossa. Ensivaiheessa mahdollistetaan ajantasamaakuntakaavojen saatavuus WMS-rajapintoina.

Keskityimme projektissa erityisesti auttamaan maakuntaliittoja tuottamaan kaava-aineistoja tietomalliin. Jalkauduimme siis syksyn aikana ympäri Suomea kouluttamaan maakuntaliittoja HAME-tietomallin käyttöönotossa. Lopputuloksena jo 12 maakuntaa on vienyt ajantasamaakuntakaava-aineistonsa yhteiseen tietokantaan! Haastetta ovat aiheuttaneet etenkin erilaiset tarpeet visualisoinneille eri osissa Suomea. Luonnollisesti myös kaava-alueet ovat maakunnissa eri kokoisia, joten maakuntakaavoja saatetaan tarkastella eri mittakaavatasoilla. Haasteita saatiin kuitenkin ratkottua, ja nyt toiveissa siintääkin samanlaisen sisällöllisen ja ulkoisen rakennemuutoksen tuominen myös kuntakaavoitustasolle!

Kiitämme hanketta koordinoinutta Varsinais-Suomen liittoa hyvästä yhteistyöstä! Lisää hankkeesta voit lukea sivuilta maakuntakaavat.fi.

Maailman ja Suomen urbanisoituessa ihmisten, työpaikkojen ja muiden kohteiden saavutettavuuden analysointi nousee kasvavaan merkitykseen. Esimerkiksi uusien asuinalueiden suunnittelu ja toimipaikkasuunnittelu vaativat suurta panosta saavutettavuusanalysoinnin näkökulmasta.

Saavutettavuus kaupungeissa on asia, joka puhuttaa ja mietityttää: se tulee usein vastaan ihan arkipäiväisissä keskusteluissa. Omassa arkipäivässäni saavutettavuus tuli vastaan esim. muutama kuukausi takaperin, jolloin vierailin opiskelukaupungissani Tampereella. Saapuessani kaupunkiin yllätyin ilokseni, kuinka ratikkaprojekti oli edennyt kohti loppukiriään. Samaisena päivänä ystävieni kesken keskustelimme vielä uuden raitiolinjan saavuttamista kaupunginosista ja kaupungin yleisestä kasvun suunnasta ja kehityksestä. Tässä valossa innostuin analysoimaan raitiotiepysäkkien saavutettavuutta R-ohjelmointiympäristössä pohjadatana OpenStreetMap (OSM), ja sainkin mitä mielenkiintoisimpia karttoja ja numeroita nähtäväkseni.

Laskin myös Tampereen kaupungin avoimen datan avulla asuinrakennuksien suhdetta saavutettavuusvyöhykkeisiin. Muun muassa huoneistojen määrästä nousi esille hyvinkin alustavia, mutta sitäkin mielenkiintoisempia tuloksia:

Tämänkaltaisien kokeellisten analyysien loppuunvieminen ohjaisi toimeenpanopolitiikkaa ja yksityisen sektorin päätöksiä merkittävästi. Yllä olevaan analyysissa tarkasteltiin aikaetäisyyttä kävellen raitiolinjan pysäkkeihin. Prosenttiosuus-tieto kuvastaa taas kunkin aikaetäisyys-vyöhykkeen sisäänjäävien huoneistomäärän suhdetta koko datasetin yhteenlaskettuun huoneistomäärään.

Liiketoimipaikkasuunnittelun, logistiikan ja kaupunkisuunnittelun sekä lukuisten muiden toimialojen keskiöstä löytyvät nämä saavutettavuuden dilemmat, joiden ratkaisemiseen nykypäivänä löytyy mittavasti erilaisia teknologisia työkaluja. Yllä olevien analyysien tapaan voitaisiin analysoida esimerkiksi työpaikkojen saavutettavuutta tai vaikkapa eri kulkumuotoja edustavien sähköpotkulautojen tai sähköpyörien markkinapotentiaalia.

Lisäksi huomionarvoista on globaali paine kestävän kehityksen arvoihin ja tavoitteisiin perustuvaan kaupunkisuunnitteluun, jonka ytimessä nämä kaupunkien tie- ja katuverkkoa analysoivat työkalut ovat. Ilmastotavoitteet ovatkin kasvavasti myös suomalaisten kaupunkien tavoiteilmapiirissä. Tästä esimerkkinä viime vuonna yhteistyössä Tampereen kaupungin, Ubigu Oy:n, Tietotakomo Oy:n kanssa toteutettu konsultointihanke liittyen maankäytön suunnittelun ilmastotyökaluun.

Nykypäivänä avoimen lähdekoodin paikkatieto-ohjelmistot tarjoavat tähän oivia ratkaisuvaihtoehtoja. Gispossa käytämme tapauksesta riippuen eri ohjelmistoja saavutettavuuden analysoimiseen. Muun muassa paikkatietokanta PostGIS tarjoaa pgRouting-laajennoksineen ratkaisun järeisiin, jatkuvaa automatisointia vaativiin järjestelmiin reitin suunnittelun ja optimoinnin sekä saavutettavuusanalyysien toimittamiseksi. Gispossa olemme toimittaneet työpajoja ja konsultointihankkeita pgRoutingin käyttöönottoon.

Tämän lisäksi reititysmoottorit GraphHopper ja OSRM tarjoavat myös näppäria ratkaisuja nimenomaan OpenStreetMapin (OSM) hyödyntämiseen pohjadatana. Voit lukea GraphHopperin käytöstä kollegani Mikaelin kirjoittamasta blogauksesta liittyen kaupunkipyörähaasteeseen, jossa hän pohti optimaalisien reittien suunnittelua. Blogi siitä löytyy tästä.

Myös kollegani Topi on kirjoittanut blogauksia GraphHopperin käyttöön. Katsasta nekin, ja käy testailemaan aineistollasi: Animated routes with QGIS.

Python- ja R-ohjelmointiympäristöihin on tehty lähivuosien aikana kirjo kirjastoja, joilla saavutettavuuden analysointi on helpottunut. Näistä mainittakoon:

Python: pandana, osmnet
R: osmdata, dodgr, stplanr, moveability

Jos saavutettavuutta analysoivia työkaluja tarkastelee kokonaisvaltaisesti teknisestä näkökulmasta, näyttää siltä, että kaupunkisuunnittelun asiantuntijat ympäri maailmaa etsivät nyt työkaluja, jotka pystyvät:

Skaalautumaan kasvavien datamäärien mukaisesti
Tukevat automatisoituja skripti-pohjaisia työprosesseja
Pohjautuvat joustavasti eri datasetteihin, kuten OpenStreetMapiin

Tätä kehitystä olemme seuranneet mielenkiinnolla lähivuosien aikana asiakkaidemme kanssa Gispossa.

Jos saavutettavuuteen ja reitinsuunnitteluun liittyvät ongelmat ovat lähellä kiinnostuksenkohteita, niin tervetuloa pyörittelemään keskusteluaihioita meidän gispolaisten kanssa. Olkaamme yhteyksissä (santtu@gispo.fi, puh. 040 1380288)!

Lyhyt johdanto vektoritiiliin

Internetin eri karttapalveluissa hyödynnetään yleisesti karttatiilipalveluita kuten WMTS. Nämä palvelut toimittavat pieniä, tyypillisesti 256×256 pikseliä kooltaan olevia karttakuvia, eli karttatiiliä. WMS-karttakuvapalveluihin verrattuna WMTS-palveluiden merkittävin etu on suorituskyky. Karttatiilet muodostavat karttatiiliruudukon, ja ruudukon tiilet voidaan tallentaa valmiiksi palvelimen välimuistiin. Pienien, valmiiden karttatiilien lähettäminen on nopeampaa kuin yhden ison karttakuvan generoiminen. Karttaa siirtäessä käyttäjä näkee kartan latautuvan paloittain sitä mukaa kun tiiliä ladataan palvelimelta.

Karttatiilet ovat yleensä olleet kuva- eli rasterimuodossa, sillä valmiiden karttakuvien piirtäminen selaimessa on teknisesti yksinkertaisin toimiva ratkaisu. Viime vuosina nk. vektoritiilet ovat kuitenkin alkaneet herättää entistä enemmän kiinnostusta. Yksittäinen vektoritiili sisältää karttaruudun piirtämiseen tarvittavan datan vektorimuodossa: geometrian lisäksi mukana saattaa siis olla myös kohteiden ominaisuustietoja. Kuviin verrattuna vektorimuotoisen datan käyttämisessä on omat hyötynsä ja haasteensa. Toisin kuin rasteritiilien kanssa, vektoritiilten kuvaustekniikka määritetään täysin käyttäjän päässä. Tämä tarkoittaa, että samoja vektoritiiliä voidaan hyödyntää useammassa sovelluksessa tai kartassa, ja kartan ulkoasua voidaan muuttaa dynaamisesti. Vektoritiili saattaa myös olla tiedostokooltaan kuvatiiltä pienempi, joskin tämä etu riippuu vektoridatan tiheydestä. Järkevästi käytettynä vektoritiiliä hyödyntämällä on mahdollista saavuttaa rasteritiiliä parempi suorituskyky ja avata uusia mahdollisuuksia vaikuttaa karttojen ulkoasuun.

Vektoritiilten jakelu GeoServerillä

Vektoritiilten tarjoaminen GeoServerillä perustuu GeoServeriin integroidun GeoWebCachen hyödyntämiseen. GeoServer ei valmiiksi sisällä tukea vektoritiilille, vaan sen lisäämiseksi tulee asentaa erillinen Vector Tiles-laajennos. Laajennoksen asentaminen on helppoa: lataa ensin GS-versiotasi vastaava laajennospaketti GeoServerin lataussivuilta. Pura paketin sisältö GeoServer-kansiosi alta löytyvään WEB-INF/lib hakemistoon, ja käynnistä GeoServer uudestaan.

Vector Tiles-laajennoksen asentamisen jälkeen vektoritasoja voidaan julkaista GeoServerillä vektoritiilinä valitsemalla haluttu formaatti tason Tile Caching-valikosta. Oletuksena löytyvien gif, jpeg ja png-tiedostomuotojen lisäksi laajennoksen asentamisen myötä Tile Caching-valikkoon tulee vaihtoehdoiksi myös GeoJSON, TopoJSON ja MVT. Kaikki uudet vektoritasot voidaan myös julkaista automaattisesti vektoritiilinä valitsemalla haluttu vektoritiiliformaatti Caching Defaults-valikosta.

Avoimia paikkatietostandardeja kehittävä ja ylläpitävä Open Geospatial Consortium järjesti vuonna 2018 Vector Tiles Pilot-pilottiprojektin, jonka toinen vaihe on parhaillaan käynnissä syksyllä 2019. Vektoritiilet ovat yhä verrattain uusi teknologia, eikä selkeää standardia ole vielä vakiintunut. Tähän mennessä yksi suosituimmista formaateista vektoritiilien jakeluun on ollut Mapbox Vector Tiles-spesifikaatio eli MVT. MVT-tiilet varastoidaan ja välitetään usein binäärimuotoisessa Protocol Buffer eli PBF-muodossa. PBF-koodattu data on esimerkiksi tekstipohjaista XML-dataa tiheämpää, minkä ansiosta se soveltuu hyvin vektoritiilien välitykseen. Protocol buffer on yleisesti käytössä oleva formaatti, eikä sitä ole erikseen optimoitu paikkatiedoille. Paikkatietojen binäärimuotoon muuntamista varten on myös omia vaihtoehtoja kuten FlatGeoBuf, mutta toistaiseksi näitä ei voida vielä hyödyntää GeoServerissä vektoritiilten kanssa.

Vektoritiilitasoja voi esikatsella muiden tiilitettyjen tasojen tapaan Tile Layers-valikosta. MVT-formaatissa julkaistut tasot näkyvät esikatseluvalikossa pbf-nimellä. Kuten kuvatiilienkin kanssa, GeoServer generoi vektoritiiliä esikatselukarttaa liikuttaessa ja tallentaa ne automaattisesti välimuistiin.

Tiilien valmiiksi välimuistiin generoiminen eli seedaus toimii samaan tapaan kuin muiden tiiliformaattien kanssa valitsemalla Tile Layers-valikosta halutun tason kohdalta Seed/Truncate. Aukeavassa ikkunassa valitaan MVT-tiiliä generoitaessa vaihtoehto application/vnd.mapbox-vector-tile, joka on MVT:n ns. MIME-tyyppi. Kuvamuotoisiin karttatiiliin verrattuna välimuistiin tallennetut vektoritiilet vievät usein huomattavasti vähemmän levytilaa.

MapBox-tyylien käyttö

GeoServerillä julkaistujen MapBox-vektoritiilitasojen kuvaustekniikan määrittämiseen voidaan käyttää MapBox-tyylejä. GeoServerin käyttämiin SLD-tyyleihin verrattuna MapBoxin omat tyylit ovat määritetty selainystävällisessä JSON-muodossa. MapBox-tyylejä voidaan kirjoittaa itse suoraan asiakassovelluksessa tai luoda graafisesti esimerkiksi MapBox Studiolla tai selainpohjaisella Maputnik-työkalulla. MapBox-tyylikieltä voidaan käyttää tyylien määrittämiseen myös suoraan GeoServerissä MBStyle Styling-laajennoksen avulla.

MapBox-tyylien käyttö GeoServerillä julkaistujen MapBox-vektoritiilten kanssa edellyttää, että palvelin tukee CORS-mekanismia. CORS:in käyttöönotto riippuu palvelinympäristöstä. GeoServer-asennuksen mukana tulee tyypillisesti Jetty-sovelluspalvelin, jossa CORS:in voi kytkeä päälle muokkaamalla web.xml-konfiguraatiotiedostoa hakemistossa webapps\geoserver\WEB-INF ja käynnistämällä GeoServer uudestaan. Avaa tiedosto tekstieditorilla ja poista kommenttimerkinnät kohdasta:

<web-app>
  <filter>
      <filter-name>cross-origin</filter-name>
      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
 </web-app>

Palvelimen CORS:in päällekytkemisen jälkeen MapBox-tyylejä voidaan käyttää kaikkien MapBox-vektoritiiliformaatissa julkaistujen tasojen kanssa. Muita palvelinpuolen muutoksia ei tarvita, sillä asiakassovellus vastaa vektoritiilien piirtämisestä. MapBox-tyylien käyttämiseksi tarvitaan siis tuki asiakassovelluksen päässä: esimerkiksi OpenLayers-kirjastoon tuen voi lisätä ol-mapbox-style -komponentilla. GeoServerillä julkaistu taso voidaan määrittää tyylin lähdemäärityksessä seuraavasti:

"<source-name>": {
  "type": "vector",
  "tiles": [
    "http://localhost:8080/geoserver/gwc/service/wmts?REQUEST=GetTile&SERVICE=WMTS
        &VERSION=1.0.0&LAYER=<workspace>:<layer>&STYLE=&TILEMATRIX=EPSG:900913:{z}
        &TILEMATRIXSET=EPSG:900913&FORMAT=application/vnd.mapbox-vector-tile
        &TILECOL={x}&TILEROW={y}"
  ],
  "minZoom": 0,
  "maxZoom": 14
}

Hyödyntäminen nyt ja tulevaisuudessa

Vaikka vektoritiilet sisältävätkin vektorimuotoista dataa, ovat ne ensisijaisesti suunnattu karttojen piirtämiseen. Käyttäjien kannattaakin muistaa, ettei vektoritiiliä suositella käytettäväksi paikkatietoanalyysien tekemiseen. Analyyseissä käytettävien vektorimuotoisten aineistojen lataamiseen kannattaa siis jatkossakin hyödyntää esimerkiksi WFS-palveluita. Huomioimisen arvoista on myös, että vektoritiiliä käytettäessä vastuu aineiston piirtämisestä siirtyy palvelimelta loppukäyttäjälle. Tämä asettaa rasteritiiliin verrattuna enemmän kuormitusta käyttäjän järjestelmälle, mikä kannattaa ottaa huomioon erityisesti mobiililaitteille suunnitelluissa sovelluksissa.

Vektoritiilet ovat olleet viime vuosina kovassa nosteessa, ja niihin liittyvä tekniikka kehittyy edelleen nopeaa vauhtia. Maanmittauslaitos julkaisi jo vuonna 2018 beta-rajapinnan teknologian kokeilemista varten, ja HSL tarjoaa jo esimerkiksi liityntäpysäköintialueiden ja kaupunkipyöräpysäkkien sijaintitietoja avoimen rajapinnan kautta vektoritiilimuodossa. Vektoritiilten tarjonta sekä hyödyntäminen tuleekin varmasti hiljalleen yleistymään myös muissa karttapalveluissa sitä mukaa, kun tietoisuus niiden tarjoamista hyödyistä ja mahdollisuuksista kasvaa.

Kiinnostuitko vektoritiilien hyödyntämisestä tai heräsikö sinulla kysymyksiä? Lähetä viesti osoitteeseen info@gispo.fi!

“Yksityistiet muodostavat pituudeltaan suurimman tieliikenneväylien ryhmän. Yksityisten tieosakkaiden ylläpitämiä yksityisteitä on Suomessa noin 360000 kilometriä” (MML)

360 tuhannen kilometrin yksityisteiden huolto- ja kunnossapitokustannuksien jakaminen tien omistajien välillä on keskeisesti paikkatieto-ongelma. Teiden hoidosta koituvat kustannukset jakautuvat sen mukaan, minkälainen käyttötarkoitus tien eri osilla on, ja minkälaisia etäisyyksiä kullekin tieosuudelle osuu. Merkityksellistä on, että teiden omistajien keskuudessa ollaan yhtä mieltä siitä, miten kustannukset jakautuvat.

Kyseessä olevan liiketoiminnallisen ongelman ratkaisemiseksi voitaisiin parhaassa tapauksessa hyödyntää keskitetttyä tietokantapohjaista ratkaisua, jossa tehokkaasti yhdistettäsiiin paikkatietoatietoa eri tietolähteestä metsänhoitajien saataville ja mahdollistettaisiin prosessiin liittyvien laskennallisten toimien ajaminen. Avoimen datan standardeja noudattaen ja modulaariseen sovelluskehitykseen pohjautuen jokin tämänkaltainen yhteishankinta voisi nopeuttaa ja kohentaa huomattavasti kaikkien tieyksiköintiin liittyvien asianomaisten työprosesseja.

Tämänkaltaista tietojärjestelmäratkaisua ei tällä hetkellä kuitenkaan ole asianomaisten käytettävissä. Metsänhoitajat ja muut asianomaiset voivat kuitenkin hyödyntää avoimen lähdekoodin QGIS-paikkatieto-ohjelmistoa paikkatietoaineistojen yhdistämiseen ja paikkatietoanalyysien tekemiseen. Näin jokaisessa metsänhoitoon tai teiden kunnossapitoon liittyvässä organisaatiossa pystytään hyödyntämään vapaasti QGISia, sillä se perustuu avoimeen lähdekoodiin ja itse paikkatieto-data on nykypäivänä avoimena datana asianomaisten käytössä.

Datoina tieyksiköintiin liittyyvät ennen kaikkea seuraavat datat:

Metsävarakuviot, Suomen metsäkeskus
Kiinteistöt, Maanmittauslaitos
Tieaineisto, Väylä

Linkeistä pääsee tutustumaan ja sitä kautta myös hyödyntämään kyseisiä avoimen datan tietolähteitä.

Gispo olikin apuna metsänhoitoyhdistykselle, jonka työprosesseja paikkatiedon tehokäytössä oli syytä kohentaa. Näin pystyttiin ratkaisemaan tieyksiköintiin liittyvät ongelmat. QGISin avulla oli mahdollista ketjuttaa työprosessin eri osia yhteen ja minimoida manuaalinen työ sekä automatisoida useampi työvaihe. Myös tuloksien laatu pystyttiin vakioimaan paremmaksi.

“Ilman QGIS-apua tässä olisi mennyt ikä ja terveys”

Metsänhoitoyhdistyksen edustaja

Lopulta tärkeää on mahdollistaa paikkatieto metsänhoitajien ja tieyksiköintiin liittyvien tahojen saatavaksi nopeasti ja helppokäyttöisesti. Tärkein asia on eri tietolähteiden tehokas yhdistäminen ja laskennallisten toimien automatisoiminen.

Sanottakoon vielä että QGISin prosessimalleja hyödyntämällä paikkatietoprosessien automatisaatio on erityisen hyödyllistä johtuen dokumentaation, ketjutettujen työvaiheiden ja sarjaprosessoinnin hyödyistä.

Jos tuntuu, että paikkatiedot eivät ole vielä tehokäytössä organisaatiossasi, niin ole yhtyeksissä Gispoon. Autamme Gispossa asiakkaitamme edistämään organisaatioiden liiketoiminnallisia tavoitteita maksimoimalla paikkatiedoista koituvat hyödyt.

PostGIS on ollut 7 vuotta versioissa 2.x, mutta tänä vuonna spatiaalisen datan tallentamisen ja analysoinnin työhevonen on saamassa versiopäivityksen kun se siirtyy kolmanteen sukupolveen. Avoimen lähdekoodin PostgreSQL tietokantaohjelmiston viimeisin versio on 12 ja PostGIS on tällä hetkellä versiossa 2.5.3, mutta release candidate PostGIS 3.0 on myös jo saatavilla.

PostGIS on PostgreSQL:n spatiaalinen laajennos, eli siinä missä PostgreSQL on relaatiotietokanta, joka pystyy käsittelemään normaaleja tietotyyppejä (numerot, tekstit, binääridata jne), tuo PostGIS sille toiminnallisuudet käsitellä paikkatietokohteita. Tämä on sinulle ehkä tämän blogin lukijana jo tuttua, mutta mitä uusi PostGIS versio tuo tullessaan?

Lisää tehoa

Uusi PostGIS tuo mukanaan ennen kaikkea lisää tehoa.

PostgreSQL on jo useamman vuoden hyödyntänyt rinnakkaisia kyselyjä (parallel query), joissa SQL kyselyn työ jaetaan prosessoreiden kesken ja suoritetaan samanaikaisesti. Tämä useita ytimiä hyödyntävä tehokeino on ollut tähän asti käytössä vain muutamissa PostGISin kyselyissä. Versiossa 3.0 PostGIS alkaa kuitenkin laajemmin hyödyntämään rinnakkaisia kyselyitä, mikä parantaa paljon prosessointitehoa vaativien spatiaalisten kyselyiden suorituskykyä huomattavasti.

PostGISin taustalla toimivat monet eri kirjastot, kuten kolmiulotteisista operaatioista vastaava CGAL, perusgeometrian hallinnasta vastaava GEOS ja koordinaattimuunnoksista vastaava Proj.

Siirtyminen uuteen Proj kirjaston versioon 6 tarkoittaa käytännössä esimerkiksi paljon tarkempaa koordinaattijärjestelmien hallintaa. Aiemmin myös koordinaattimuunnokset ovat käyttäneet usein WGS84:ää välivaiheena ST_Transform() funktiossa, mikä on voinut aiheuttaa virheitä kun muunnos on tehty kahteen otteeseen (alkuperäisestä WGS84:ään ja siitä haluttuun). Nyt tätä taustalla tapahtunutta välivaihetta ei enää Proj 6 versiossa ole.

Uuden version myötä siirtyminen uuteen GEOS 3.8 kirjastoon tuo hyötyjä tehokkuuden kautta, kun kirjaston C++ koodia on siivottu ja kehitetty.

Lisää ominaisuuksia

Vektoritiilet ovat tehneet tuloaan karttapalveluihin jo useamman vuoden ja nyt ne ovat vähitellen vakiinnuttamassa asemaansa karttakuvatiilien rinnalla. PostGISissä on ollut jo jonkin aikaa funktio ST_AsMVT, joka on palauttanut MapBoxin vektoritiilispesifikaation mukaisia vektoritiilielementtejä suoraan tietokannan taulusta tai näkymästä. Tähän on tulossa kuitenkin useita suorituskyvyn parannuksia.

Muita vektoritiilien parannuksia on mm. Uusi ST_TileEnvelope() -funktio, joka ottaa parametreina tiilien zoom-tason sekä x- ja y -arvot ja muodostaa näiden avulla halutun alueen rajauksen vektoritiilien generointia varten Web Mercator projektiossa.

Samalla kun rasteritiilet ovat muuttumassa vektoriksi, ollaan paikkatiedon kentällä hivuttautumassa XML:stä kohti JSONia. Tämä näkyy esim. OGC API:n kehityksessä, mutta myös PostGISin puolella. PostGIS on sisältänyt jo pitkään ST_AsGeoJSON funktion, mutta se on ottanut parametrikseen vain PostGISin geometrian ja palauttanut vain GeoJSON geometrian. Uudessa PostGISissä on mahdollista antaa suoraan funktiolle myös muita sarakkeita, jolloin se palauttaa täydellisen GeoJSON kohteen ominaisuustietoineen!

Yksi pieni, mutta mielenkiintoinen muutos on myös rasteriaineistojen tuen siirtäminen pois PostGISin ytimestä. Käytännössä tämä tarkoittaa ainoastaan sitä, että postgis_raster pitää ottaa käyttöön erikseen. Rastereiden käsittely tietokannassa ei yleisesti tuo läheskään vektoriaineistojen kaltaisia hyötyjä tai sisällä läheskään yhtä laajoja toiminnallisuuksia, mutta tietyissä tapauksissa se voi hyvinkin olla järkevää. Rasterituen siirtäminen ei siis varsinaisesti poista mitään toiminnallisuuksia, vaan PostGISin ydintoiminnallisuudet koitetaan pitää tällä tavoin hillityn kokoisina.

Kolmiulotteisen datan hallinta tulee tällä hetkellä paikkatiedon kentällä monesta suunnasta esille ja sillä saralla tapahtuu kehitystä myös PostGISin puolella. Monet kolmiulotteisia datoja käsittelevät funktiot ovat saaneet korjauksia ja myös jotain kokonaan uusia toiminnallisuuksia on tulossa, kuten esimerkiksi kolmiulotteisesta viivaelementistä tietyllä etäisyydellä olevan pisteen interpoloiva funktio.

Jos ennen versiota 2.5 on käyttänyt SQL-kyselyssään järjestämään kohteet geometrian mukaan (ORDER BY geom), on se järjestänyt rivit X-koordinaatin mukaiseen järjestykseen. Uudessa versiossa PostGIS käsittelee kohteita niin, että toisiaan lähellä olevat kohteet ovat myös vastauksessa entistä “lähempänä” toisiaan ja myös algoritmin tehokkuutta on parannettu.

Lisää vielä merkittävämpiä uusia funktioita ja toiminnallisuuksia tulee varmasti seuraavissa 3.x versioissa. Tämän versiomuutoksen isoimmat vaikuttajat ovat taustalla tapahtuvia suorituskyvyn parannuksia ja uusien toiminnallisuuksien mahdollistajia.

Milloin kannattaa päivittää?

Kannattaako päivitys? Päivitys kannattaa aina. Varsinkin jos teet (työ)ajallasi jotain muuta kuin odotat SQL kyselyiden valmistuvan. Jo nyt voi olla hyvä aika lähteä kokeilemaan uusia ominaisuuksia omalla sandboxilla, jotta valmiin version ilmestyessä voi tehdä päivitykset myös tuotantoympäristössä.

On aina tärkeä muistaa, että PostGIS on PostgreSQL:n laajennusosa. Isoimmat muutokset tehokkuuden parannuksessa ja uusissa toiminnallisuuksissa voidaan nähdäkin tulevan PostgreSQL:n kehityksen myötä. PostGIS 3.0 on tarkoitettu käytettäväksi yhdessä PostgreSQL:n version 12 kanssa, joten hyvä ajatus on päivittää molemmat samaan aikaan.

Jäämme siis jännityksellä odottamaan spatiaalisen datan murskauksen uusia mahdollisuuksia!

PostGIS kurssimme löydät täältä. Jos nyt aikatauluihisi sopivaa kurssia ei löydy, ole suoraan yhteydessä!

Blogikirjoitukseni (englanniksi) PostGISin perusteista löytyy täältä.

Vuoden 2019 FOSS4G-konferenssissa pidetty puheenvuoro PostGISin uusista ominaisuuksita on katsottavissa täällä.