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ä.

Open Geospatial Consortiumin (OGC) määrittämät avoimet OGC-standardit ovat yleisesti käytössä paikkatietojen jakamiseen internetissä. OGC-standardit mahdollistavat erilaisten paikkatietojen hyödyntämisen useissa asiakassovelluksissa palveluissa. Standardit ovat yleistyneet myös Suomessa ja Gispo ylläpitää listaa avoimen datan WMS- ja WFS-karttapalveluista Suomessa.

OGC-standardit ovat kokemassa ison uudistuksen tulevan OGC-API-rajapintastandardin (OAPI) myötä. Kaikki nykyisin käytössä olevat OGC-palvelut, kuten WMS, WFS, ja WCS, tulevat saamaan uuden rajapintatoteutuksen. Tämä johtaa muutokseen palveluiden nimeämisessä: esimerkiksi paikkatietokohteiden siirtoon käytetyn Web Feature Service-palvelun (WFS) kehitteillä ollut WFS 3.0-versio tunnetaan nyt nimellä OGC Features API. Kaikki palvelut tulevat rakentumaan yhteisen jaetun OGC-API Common-rajapintastandardin päälle siten, että niitä voidaan modulaarisesti lisätä ja poistaa käytöstä.

Helppokäyttöisempiä rajapintoja

Isoimmat muutokset nykyisiin palveluihin verrattuna koskevat tapaa, jolla rajapintojen kanssa kommunikoidaan. Uudet standardit vastaavat lähemmin web-kehityksessä yleistynyttä REST-arkkitehtuurityyliä nykyisten palveluiden SOAP-protokollan sijaan. Rajapintojen kuvaamisessa hyödynnetään OpenAPI-spesifikaatiota, joka mahdollistaa uusien rajapintapalveluiden helpon ja nopean kehittämisen sekä hyödyntämisen. Teknisten muutoksien lisäksi myös standardien kehittämisprosessi on uudistunut: esimerkiksi Features API:n liittyvää kehityskeskustelua on käyty avoimesti GitHubissa.

Tulevien muutoksien takana on pyrkimys tehdä paikkatietorajapinnoista helppokäyttöisempiä ja helpommin lähestyttäviä sekä kehittäjille että loppukäyttäjille. Nykyiset OGC-palvelut hyödyntävät koneluettavaa XML-merkintäkieltä, joka on monikäyttöistä muttei helposti luettavaa saati hakukoneystävällistä. OAPI ei pakota minkään tietyn formaatin käyttöön: nykyisistä palveluista tuttuja XML:ää ja GML:ää voi siis käyttää jatkossakin, mutta niiden rinnalle tulee myös kehittäjäystävällinen ja helposti luettavissa oleva GeoJSON. Rajapinta voi palauttaa myös esim. HTML-dokumentteja, joka mahdollistaa palvelun tarjoamiin aineistoihin ja muihin resursseihin tutustumisen sekä hyödyntämisen myös suoraan selaimesta.

Lisätoiminnallisuuksia laajennoksien avulla

OGC-API on luonteeltaan modulaarinen: yhteisen common-rajapinnan päälle voidaan lisätä eri rajapintapalveluja. Rajapintapalvelut sisältävät kuitenkin hyvin rajoitetusti ominaisuuksia verrattuna nykyisiin standardeihin. Esimerkiksi nykyinen WFS 2.0-standardi tarjoaa huomattavasti enemmän toiminnallisuuksia tulevaan OGC Feature API:n verrattuna. OAPI:n modulaarinen luonne ulottuu myös itse palveluihin asti. Tarkoituksena on, että palvelun ydin eli core sisältää vain kaikkein oleellisimmat toiminnot palvelun käytön mahdollistamiseksi. Palveluiden perustoiminnallisuuksien päälle voidaan tarvittaessa lisätä lisätoiminnallisuuksia erilaisilla laajennoksilla. Esimerkiksi OGC Features API:n on kehitteillä lisäosa, joka lisää tuen useammalle koordinaattijärjestelmälle. Modulaarisen rakenteen myötä uusien ominaisuuksien ja toiminnallisuuksien lisääminen on helpompaa tarkemmin rajatuihin standardeihin verrattuna.

Ensimmäiset standardit valmiina jo loppuvuodesta

Features API:n lisäksi OGC:n GitHubissa on työn alla standardiluonnokset karttatiilille (OAPI Map Tiles), rastereille (OAPI Coverages), ja prosessoinnille, joita nykyisistä palveluista parhaiten vastaa WMTS, WCS ja WPS. Visualisoinnin ystävien iloksi myös kuvaustekniikalle on kehitteillä oma OAPI-rajapintastandardi, mikä pyrkii helpottamaan karttatyylien löytämistä, muokkaamista ja hyödyntämistä.

Standardiluonnokset ovat yhä keskeneräisiä, eikä niille löydy vielä kokeellistakaan tukea useimmista asiakas- tai palvelinsovelluksista. Kaikkien nykyisten palveluiden toiminnallisuuksien lisääminen eri laajennoksien kautta tulee viemään runsaasti aikaa ja resursseja, eivätkä tutut palvelut kuten WMS ja WFS tule katoamaan uusien standardien valmistuttua. Yleisesti ottaen OAPI on kuitenkin otettu vastaan innolla, ja esimerkiksi Maanmittauslaitos on jo ehtinyt julkaisemaan beta-vaiheessa olevan WFS 3.0-standardiluonnokseen perustuvan Maastotiedot-rajapintapalvelun. Myös esimerkiksi GeoServeriin on kehitteillä oleva laajennos OAPI-tuelle. Standardien kehitys on aktiivista, ja ensimmäisiä julkaisuja odotetaan jo tämän vuoden aikana.

Kiinnostuitko, miten sinä ja organisaatiosi voisivat hyödyntää OGC-APIa? Ota yhteyttä info@gispo.fi.

Globaali FOSS4G-tapahtuma järjestettiin tänä vuonna 26.8.-31.8.2019 Romanian Bukarestissa. Suomessa jo pitkään näkynyt kasvava kiinnostus avoimen lähdekoodin paikkatieto-ohjelmistoja kohtaan kulminoitui Romaniaan, kun suomalaisia oli peräti 42 paikalla. Mitä FOSS4G:stä jäi sitten käteen? Yhteisöä, osaamista ja intoa ellei muuta!

Huippuosaamista työpajoista

Tapahtuma käynnistyi perinteisesti työpajoilla, joissa pääsimme työntämään omat kätemme pullataikinaan.

Gispolaiset olivat melkein koko tiimin muodossa paikalla (8 kaikkiaan!) ja kukin pääsi oppimaan ja kehittämään erityisasiantuntijoiden pitämissä työpajoissa omaa paikkatieto-osaamistaan. Maailman luokan erityisasiantuntijoiden työpajoissa opimmekin muun muassa seuraavista ohjelmistoista ja temaattisista kokonaisuuksista:

QGISin päälle tehty Android-sovellus: QField. QFieldin käyttäjäorganisaatiot keräävät maastossa mobiililla tai tabletilla paikkatietoa esimerkiksi kuvien tai tietolomakkeiden muodossa.
Python ja R:n paikkatietotoiminnallisuuksista
Geonode-paikkatietopalvelin ja -portaali
Pythonin GeoPandas -data science kirjasto paikkatietojen työstöön
Grass GISin ja OrfeoToolboxin anneista automatisointiin satelliittikuvien tulkintaan
PostgreSQL:n Pgrouting-työkalu reitin suunnitteluun ja optimointiin
QGISin 3D-toiminnallisuudet ja Mesh-datan hyödyntäminen (kts. täältä työpajojen kuvaukset)
Maankäytön suunnittelussa käytössä olevista avoimista standardeista paikkatietojen käyttöön (LADM-standardi espanjaksi)
PostGISin toiminnallisuudet rasteriaineistojen hyödyntämiseen

Suomalaiset per capita vertailussa maailman kärkimaita

Suomalaisia oli paikalla niin yrityksien kuin julkishallinnon puolesta. Julkishallintoa edustivat muun muassa Maanmittauslaitos, Väylä, Tilastokeskus ja SYKE. Suomalaisia oli paikalla tosiaan peräti 42, ja Suomi olikin todennäköisesti voittaja kisassa, jos mitattaisiin osallistujia per asukas maakohtaisesti.

Tutustu gispolaisten TOP 5 -listaukseen ja opi videoista!

Keskiviikosta perjantaihin saimme kuulla toinen toistaan kiinnostavampia esityksiä. Kutakin gispolaista puhutteli omia mielenkiinnon kohteita lähellä olevat esitykset, joista olemmekin alle ottaneet esille muutaman TOP 5 -esityskombon gispolaisilta:

Sannan TOP 5

Topin TOP 5

Jaakon TOP 5

Anniinan TOP 5

Santun TOP 5

Huomaa, että kukin videoista on nähtävissä kokonaisuudessaan linkkien kautta. Kaikki FOSS4G:n esityksien videot löytyvät täältä: https://media.ccc.de/c/foss4g2019

Myös gispolaisilta kuultiin esityksiä

Sanna ja Maiju esittelivät hiilineutraalia kaupunkisuunnittelua edistävän paikkatietopohjaisen tietojohtamistyökalun antia. Yleisöä kertyikin ajankohtaisen asian tiimoilta paljon paikalle ja Ubigu Oy:n sekä Tietotakomon kanssa yhteistyössä tehdyn Tampereen kaupungin hankkeen tulokset kiinnostivat myös kansainvälisellä areenalla. Käy katsomassa Sannan ja Maijun esitys täältä.

@SannaJokela1 showing a complete Postgis Database & dataset with a QGIS plugin to compute CO2 emissions here in @foss4g pic.twitter.com/qnrrbWJfpb
— Régis Haubourg (@RegisHaubourg) August 28, 2019

Topi pääsi esittämään vaalidatan liittyvässä esityksessään paikkatieto murskaus -operaatiostaan laaja-alaisella avoimen lähdekoodin paikkatieto-ohjelmistojen osaamisrepertuaarillaan. Topin tunnettavuus yhteisön keskuudessa ja osuva esityksen titteli täytti salin. Käy katsastamassa Topin esitys täältä.

Finland’s #geospatial #superstar @tjukanov has an important point: Always provide a working feedback channel for your open data! pic.twitter.com/TZMfZgAeuv
— Jani Kylmäaho (@JKylmaaho) August 29, 2019

Lopuksi vielä OSGeon code sprinttiin

OSGeo Code sprint on vakinaisesti osa FOSS4G-tapahtumia ja Gispo oli vahvasti mukana sprinttailemassa tänäkin vuonna. Suomen näkökulmasta merkittävää on esimerkiksi QGISin suomenkielisen käännöksen edistäminen ja kohentaminen. Käännöstyö on jatkuva prosessi ja siihen voi kuka vain tulla mukaan. Kääntäminen tapahtuu helposti selainympäristössä; lisätietoja kääntämisestä voi lukea QGISin sivuilta. Jos mukaanlähtemisessä tulee ongelmia tai kysymyksiä, voi kirjoitella Gispon tukipalveluun osoitteesta tuki@gispo.fi.

Ensi vuonna koittaa FOSS4G 2020 paikkana Calgary (Kanada)

Ensi vuonna sitten Calgaryyn! Globaali FOSS4G on massiivinen konferenssi, jonka järjestely on jo täysillä käynnissä. Voit seurata konferenssiin liittyvien tärkeiden päivämääärien (mm. deadline esityksille & early bird -ilmoittautuminen) julkaisemista konferenssin sivustoilla: http://2020.foss4g.org/

Ennen ensi vuotta tapaamme varmasti esim. Paikkatietomarkkinoilla, nimittäin ns. OSGeo Parkissa (kts. markkinoiden sisätilakartta täältä ja etsi OSGeo Suomi ry), josta löydät erityisesti avoimen lähdekoodin paikkatietoratkaisuja edistäviä yrityksiä. Myös Suomen omassa FOSS4G-tilaisuudessa ensi keväänä pääsemme varmasti näkemään ja kuulemaan suomalaisen avoimen lähdekoodin paikkatieto-ohjelmistojen ympärille keräytyneestä yhteisöstä taas sankoin joukoin. FOSS4G Finland 2020 järjestää ja tiedottaa OSGeo Suomi Ry järjestelykomiteoineen alkuvuodesta 2020.

Koulutuksemme avoimen lähdekoodin ohjelmistojen käyttöön rakentuvat yhden hyväksi havaitun rungon ympärille: lyhyehkö johdatteleva luento-osuus käy läpi aiheen kannalta tarpeellisen teorian, ja pian päästään tekemään henkilökohtaisia harjoituksia. Eli vanhaa Äpy-lehteä lainatakseni: Teoria eli Lässyn-lässyn, ja sovellukset eli Temput. Kokemukseni mukaan myös monet muut asiat toistuvat universaalisti, koulutuksen aiheesta ja osallistujajoukosta riippumatta.

Koulutukseen osallistuvilla henkilöillä on erilaiset lähtötiedot, taustat ja tarpeet koulutukselle. Nykyaikana työurat ovat niin monipolvisia, että kahta samaa polkua pitkin samaan tilanteeseen päätynyttä työntekijää tuskin löytää! Erilaisten osaamistasojen sovittaminen samaan koulutukseen onkin kouluttajan arkipäiväinen haaste. Tässä olen havainnut avaintekijäksi kuuntelemisen: kun osallistujilta aluksi kysyy heidän lähtötasostaan ja tavoitteistaan, ei pääse syntymään kokemusta ohittamisesta ja siitä, että koulutus on heille täysin sopimaton ja tarpeeton. Vaikka koulutuksen sisältöä ei pystyisikään lennossa paljoa muokkaamaan, voi kouluttaja ottaa keskivertoa edistyneemmät osallistujat huomioon vaikkapa esittelemällä lyhyesti ohjelmiston lisäasetuksia tai vinkkaamalla tutoriaaleja, blogeja tai GitHub-tilejä joiden avulla aiheeseen voi tutustua syvemmin. Vastaavasti ryhmän aloittelijoista kannattaa pitää huolta tiedustelemalla silloin tällöin heidän fiiliksiään sekä korostamalla, mitkä asiat ovat tärkeimpiä alkuun pääsemisen kannalta.

Kun koulutettavien toiveita kartoitetaan etukäteen, toistuu usein toive käyttää koulutuksessa osallistujien omia paikkatietoaineistoja harjoitusten tekemiseen. Mielellään kouluttajan tulisi tietysti arvata, mitkä on osallistujan tärkeimmät työnkulut ja tehtävät, ja sisällyttää juuri nämä koulutuksen aiheisiin. Koulutusten sisällön räätälöiminen on toki mahdollista, mutta usein aikaa vievää ja haastavaa. Parhaan hyötysuhteen sekä kouluttaja että koulutettavat saavatkin, kun harjoitukset suunnitellaan ja ohjeistetaan niin, että ne voi (tietyin reunaehdoin) tehdä halutessaan omilla aineistoillaan. Toki esimerkkidatat on voitava tarjota niille osallistujille, joilla ei juuri halutunlaista aineistoa löydy, tai joilla esimerkiksi organisaation aineistopolitiikka estää omien aineistojen käytön.

Kolmas asia, joka on toistunut koulutuksissani ja opetuksissani niin usein, että olen itsekin sen oppinut ymmärtämään, on koulutettavien itse tekemisen ja osallistamisen merkitys. Gispon koulutukset harvoin sisältävät niin pitkiä luentoja, että kuuntelijoita tulisi herätellä aktivoivilla välitehtävillä. Siitä huolimatta pari- ja ryhmäkeskusteluilla on merkittävä vaikutus oppimiseen: ne pakottavat sanallistamaan omaa oppimista ja reflektoimaan sitä aiempaan tietämykseen sekä omiin työtehtäviin. Lisäksi keskustelukumppania kuunnellessa voi nähdä opitun asian toisesta näkökulmasta ja saada uusia oivalluksia.

Pari viikkoa sitten vedimme Topin kanssa GIMCS-projektin toisen vaiheen koulutuksia Kigalissa. QGIS-jatkokurssin lopuksi toteutettiin yhden päivän kestävä ryhmätyöt, jossa osallistujat saivat itse määritellä jonkin paikkatietoaiheisen kysymyksen tai tehtävän, jonka yrittivät ratkaista. Ryhmän tuli määritellä analyysin vaiheet, etsiä sopivat aineistot, suorittaa analyysi ja esitellä työnsä tulokset muille. Pyysimme heitä kertomaan myös, mitä oppivat ryhmätyötä tehdessään ja mistä saivat ohjeita ja apua sen suorittamiseen. Tämä osoittautuikin koko viikon parhaaksi ideaksi! Ryhmäläiset selvästi sitoutuivat tehtävän tekemiseen, ja monet tuntuivat yllättyvän positiivisesti omasta suoriutumisestaan. Haasteiden ratkominen yhdessä vaikuttaa valtavasti osallistujien motivaatioon, sitoutumiseen sekä uskomukseen omista kyvyistä. Juuri tätä lähdimme Kigaliin viemäänkin! Lyhytkestoisessa koulutuksessa tärkeää ei lopulta ole yksittäisten temppujen hallitseminen. Sen sijaan on tärkeää, että avoimen lähdekoodin mahdollisuuksiin vasta tutustuva organisaatio pystyy luottamaan omaan kykyynsä oppia, ja että heillä on tarvittavat työkalut kehittymiseen. Osoitimme siis todeksi nykyisin tunnistetun teesin: opettajan rooli on siirtynyt asiantuntijasta fasilitaattoriksi, joka tarjoaa lähtökohdat itsenäiselle oppimiselle.

Usein tietokantojen kanssa työskennellessä koneluettava tietoformaatti Comma Separated Value (.csv) on hyvin laajasti käytetty ja hyödyllinen formaatti. Usein kuitenkin sarakkeiden tietomuodot (teksti, kokonaisluku, geometria, jne.) aiheuttavat päänvaivaa käyttäjälle. Tässä tutoriaalissa näytämme, kuinka OGR-komentotyökalun avulla saadaan helposti ladattua .csv-data PostGISiin. Tällä kertaa haluamme ladata Helsinki Region Infosharen kautta julkaistun kaupungin tuottaman liikennemerkit pilottiaineistonPostGISiin.

Ensin data tutuksi: miltä se .csv-aineisto näyttääkään?

Esimerkiksi kyseisellä datasetilla on perinteiseen tapaan paljon sarakkeita, jotka sisältävät erilaisia ominaistietoja liikennemerkeistä. Sarakkeet ovat eri muodossa ja jos .csv-tiedosto avataan laskentataulukko-ohjelmalla (Excel/Libreoffice Calc tms.), se näyttäisi suurin piirtein tältä (muutama rivin osalta):

GDAL/OGR-ohjelmistokirjasto apuun ja taulukkodata PostGISiin

GDAL/OGR-työkalun avulla voidaan helposti ladata aineisto PostGISiin. GDAL/OGR on ohjelmistokirjasto, joka ei välttämättä ole nimeltään monelle tuttu, mutta käytössä se on ollut lähes kaikilla paikkatiedon kanssa toimineilla. Lue täältä, missä kaikissa paikkatieto-ohjelmissa GDAL-OGR pyörii taustalla tai liitännäisenä. Tutustu myös tukipalveluartikkelistamme, kuinka asennat ohjelmistokirjaston Windows-ympäristöön.

CSV-aineiston tuominen PostGISiin tapahtuu seuraavan komentosarjan avulla. Komennon viimeisenä parametrina AUTODETECT_TYPE=YES auttaa työkalua sananmukaisesti tunnistamaan automaattisesti tietotyyppejä aineistossa.

ogr2ogr -f "PostgreSQL" PG:"host=localhost user=postgres dbname=gisdb password=mypassword" liikennemerkit.csv -nln liikennemerkit -oo AUTODETECT_TYPE=YES

Huomaa personalisoida oman työympäristösi mukaan ainakin user-, dbname- ja password-parametrit, jotka esittävät tietoja käyttämästäsi tietokannasta. Yllä olevan kommennon ajat samaisesta kansiosta, josta löydät aineiston. Jos tiedostosijaintien välillä liikkumisesta on aikaa, voit lukea seuraavista linkeistä, miten Linux-ympäristössä ja Windows-ympäristössä liikutaan kansioista toiseen. Windowsissa OsGeo4W shell -ohjelmiston saa auki ja ogr-työkalua voi testata csv-aineiston kanssa seuraavalla tavalla:

Tulokset

Lopputuloksena löydät aineiston haluamastasi tietokannasta. PgAdminissa data näyttäisi tältä:

Hyödyntäen psql-komentorivityökalua hallitsemaan PostGIS-tietokantaasi saisit samat tiedot esille kyselemällä taulun tietoja helposti komennolla:

\d liikennemerkit

Tämän artikkelin luontihetkellä aineisto sisälläsi seuraavat sarakkeet, joiden tietotyypit asettuivat Type-sarakkeen esittämällä tavalla. Näytönkaappaus on otettu psql-työkalusta.

Jos verrataan tietotyyppejä aineiston lataussivulstolta katsottuun taulukkoon tietotyypeistä huomataan, että tietotyypit täsmäävät aika pitkälti (huomaa, että tietoaineistoon on tullut lisää sarakkeita metadatan päivittämisen jälkeen).

Täältä voit lukea lisää GDAL/OGR:n .csv-driverista ja sen toiminnallisuuksista osana ohjelmistokirjastoa: https://gdal.org/drivers/vector/csv.html

Taulukkodatan koordinaattisarakkeet paikkatietomuotoon tietokantaan

Extrana jos haluat hyödyntää ‘x’- ja ‘y’-sarakketa ja tuottaa paikkatietosarakkeen osaksi tietokantataulua, voit tehdä sen seuraavia komentoja hyödyntäen:

-- lisätään geom_-sarake, joka on tietotyypiltään geometry 
ALTER TABLE liikennemerkit
 ADD COLUMN geom_ geometry;

-- hyödynnetään x- ja y-sarakkeita juuri luomamme geometry-sarakkeen populoimiseen 
UPDATE liikennemerkit 
 SET geom_=ST_SetSRID(ST_MakePoint(x::float8, y::float8), 3878);

Mikäli PostgreSQL:n näppärä psql-komentyökalu ei ole tuttu ja haluaisit testata sitä Windows-ympäristössä, seuraavalta videolta voit katsoa, miten yllä oleva komento ajetaan sen avulla.

Huomaa myös, kuinka loppuviimein x- ja y-sarakkeet eivät sellaisinaan eli double precision -muodossa ole päteviä, mikä johtuu lähinnä siitä, että aineistoissa jotkin x- ja y-koordinaatit ovat tyhjiä tai sitten niiden merkkipituudet ovat keskenään vaihtelevia.

Lopuksi voit vielä visualisoida aineiston vaikkapa QGISissa:

Ilmastotavoitteet ovat entistä keskeisemmällä sijalla kaupunkien maankäytön suunnittelussa. Tampereen kaupunki onkin lähtenyt ratkomaan ilmastohaasteita myös yleiskaavoitustyössä.

Yleiskaavatyön tueksi Tampere laati vuoden 2019 aikana yhdyskuntarakenteen tuottamien ilmastovaikutusten arviointimenetelmää, jonka avulla saadaan suunnittelua ja poliittista päätöksentekoa tukevaa, keskenään vertailukelpoista tietoa sekä nykyisen että tavoitellun yhdyskuntarakenteen päästövaikutuksista.

Ilmastovaikutusten mallinnusmenetelmän kehittämisen lähtökohtana on valtakunnallinen SYKE:n ylläpitämä YKR-ruutuaineisto. Mallinnusmenetelmällä on kytkös Suomen ympäristökeskuksen käynnistämään Yhdyskuntarakenteen hyvät käytännöt ja kokeilut (YKR-demo) hankkeeseen. Hankkeessa toteutetaan yhdyskuntarakenteen analyyseja kaupunkiseuduille ja kuntiin erityisesti MRL:n uudistamiseen liittyen.

Tampereen ilmastovaikutusten arviointimenetelmän tuottamisesta vastasi konsulttiyhteenliittymä, johon kuuluvat Ubigu Oy, Gispo Oy sekä Tietotakomo. Gispon tehtävänä oli kehittää lisäosa QGIS-ohjelmistoon, jolla tietojen hallintaa voidaan lopulta tehdä ja hakea analyysin tulokset kartalle.

Työkalun kuvaus löytyy Gispon GitHub-tililtä. Työkalun testikäyttöä varten tarvitset Ubigulta tietokantayhteyttä varten tunnukset sekä YKR-aineistojen käyttöluvan SYKEltä (väestö, työpaikat, rakennukset). Työkalu laskee nykytilan hiilidioksidipäästötiedot sekä tekee erilaisiin skenaarioihin perustuvia laskelmia tulevaisuutta varten. Tulevaisuuslaskennassa tarvitaan myös kaavan aluevarausaineistot sekä valinnaisesti myös keskusverkkotietoja ja intensiivisen joukkoliikenteen pysäkkitietoja.

Työkalu on testivaiheessa tehty vain Tampereen käyttöön, mutta sitä voidaan laajentaa muille alueille. Tällöin tietoaineistoja pitää muuntaa taustalla. Tästä tietoaineistotyöstä vastaavat Ubigu ja Tietotakomo, Gispon vastuulla on QGIS-työkalun kehitys ja visualisointien tuottaminen.

Lisätietoa hankkeesta antaa:

Pia Hastio, Tampereen kaupunki
Ilpo Tammi, Ubigu Oy
Marko Nurminen, Tietotakomo
Sanna Jokela, Gispo Oy