Kansallisten maankäyttöpäätöstietojen tietomallien arviointi

1(18) Kansallisten maankäyttöpäätöstietojen tietomallien arviointi Sisällysluettelo Johdanto 2 Arvioinnin perusteet 2 Tekniset taustaehdot 3 Testiaineistot ja tietomallien versiot 3 Olemassaolevien ohjelmistojen kyky lukea kompleksista tietomallia 4 OGC:n vaatimukset ja geometria-tiedot KuntaGML:ssä 5 INSPIRE:n tietomallien mukaisuus 7 KuntaGML:n asemakaavat ja yleiskaavat tietomallit 8 Maakuntakaavojen tietomalli 9 Käyttökokemukset 10 Arvioinnin tulokset 12 KuntaGML:n arvioinnin tulokset 12 Ohjeistuksen ja dokumentoinnin lisääminen 12 Kompleksinen rajapinta & tekniset haasteet 13 KuntaGML skeeman kansainvälisten vaatimusten ongelmat 13 Maakuntakaavojen tietomallin arviointi 14 Kuntien kyvykkyys tuottaa tietomalleja kansainvälisten vaatimusten mukaisesti 14 Kustannushyötyanalyysi 16 Yhteenveto 17 Loppupäätelmät skenaarioihin 18 Lähteet 19

2(18) Johdanto Tulevaisuuden maankäyttöpäätöstietojen kansainväliset vähimmäisvaatimukset -selvityksen yhtenä osana oli arvioida nykyisten kansallisten maankäytön tietomallien kyvykkyys vastata kansainvälisiin vaatimuksiin. Käytännössä maankäyttöpäätöstietoihin liittyviä kansallisia tietomalleja ovat Kuntaliiton ylläpitämää KuntaGML- skeema ja Maakuntakaavojen tietomalli (tuotettu SYKE:n ja Maakuntien liittojen toimesta HAME-hankkeessa). KuntaGML sisältää maankäyttötietoihin liittyen asemakaavojen ja yleiskaavan skeemamäärittelyn sekä erikseen myös poikkeamispäätös ja suunnittelutarveratkaisu -tietomallin. Tämän selvityksen tuloksena haluttiin vastaus KuntaGML-skeeman hyödyntämiseen liittyviin toimintamalliskenaarioihin: A) KuntaGML:ää kehittämällä voidaan luoda tulevaisuudessa tietomalli, joka vastaa kansainvälisiin vaatimuksiin tai B) KuntaGML:ää ei pystytä kehittämään tulevaisuuden maankäyttöpäätöstietojen tietomalliksi. Arvioinnin perusteet Arviointi tehtiin toteuttamalla tietomalleille vastaavuustaulukointi INSPIRE-direktiivin maankäyttöpäätöstietoja koskeviin tietomalleihin perustuen [ 12 ] ja tekninen testaus toteutettin testikunniksi valituille muutamalle kunnalle, joilla oli KuntaGML:n mukaiset rajapintatoteutukset (Turku, Lahti, Jyväskylä). Teknisen testauksen referenssinä käytettiin myös muiden testikuntien aineistorajapintoja: Hyvinkää, Tampere, Helsinki ja Riihimäki. Huomioitava on myös että esimerkiksi Helsingin kaupunki on tuottamassa omaa asemakaavan tietomallia, jota tehdään erillisessä hankkeessa, eikä aineisto ole vielä valmis. Tampereen kaupunki on puolestaan aloittamassa yleiskaavan tietomallityötä. Lisäksi 4 kuntaa haastateltiin (Turku, Paimio, Lahti, Joensuu) [ 13 ]. Alunperin suunniteltu Rovaniemen haastattelu peruuntui. Muilta sidosryhmiltä saatiin arvioita tietomallien käytettävyydestä (mm. Maanmittauslaitos, Hyvinkään kaupunki). Arviointi perustuu seuraaviin taustatietoihin: Maanmittauslaitoksen Kuntatietopalveluun ja KuntaGML-rajapintoihin tuottamat testaukset keväällä 2017 ja Gispo Oy:lle lähetetyt arviot palveluiden käytettävyydestä syksyllä 2017 [ 1 ] Gispo Oy:n ja Kuntaliiton toimesta kesällä 2017 toteutetun QGIS / KuntaGML työkalun kehitykseen tarkoitettujen tarjouspyyntöjen vastaukset (Oslandia Ltd & CampToCamp Ltd). [ 2 ] SITO Oy :n keväällä 2017 tuottama raportti maankäyttöpäätöstietojen ja INSPIRE:n vertailusta [ 3 ] Hyvinkään kaupungin arvio KuntaGML:n käytöstä (sähköposti, luottamuksellinen) [ 4 ] Evolta Oy:n keväällä 2017 tuottama selvitys kuntien maankäyttöpäätöstietojen digitaalisuusasteesta [ 9 ] Kuntien paikkatieto- ja kaavoitusasiantuntijoden haastattelut selvityksen osana: Turku, Paimio, Joensuu ja Lahti [ 13 ] Lisäksi tämän selvitystyön ohjausryhmän kommentteja on pyydetty selvitystyön eri osiin.

3(18) Tekniset taustaehdot Testiaineistot ja tietomallien versiot Testikuntien maankäyttöpäätöstietoihin liittyviin WFS-rajapintoihin tutustuttiin (taulukko 1). Lisäksi WMS-palveluita tarkasteltiin myös. Ainoastaan Tampereen kaupungilla oli INSPIRE:n vaatimat WFS 2.0 ja WMS 1.3.0 palvelut käynnissä, tosin myös Tampereen WFS-palvelun osalta INSPIRE:n validointityökalut [ 5 ] antoivat virhe-ilmoituksia. Testatut KuntaGML:n mukaiset WMS-palvelut olivat WMS 1.1.1 versiolla toteutettuja ja WFS palvelut versioilla 1.0.0 tai 1.1.0. Maakuntakaavoista ei ole toteutettu WFS 2.0 mukaisia rajapintoja vaan INSPIRE-velvoitteet toteutuvat ATOM-syötteen avulla. Taulukko 1. Eri kuntien WFS-rajapintojen testausta. Kunta / KuntaGML Asemakaava Yleiskaava Poikkeamis -päätökset Suunnittelutarveratkaisut Rakennuskiellot Suojelu INSPIRE-arvio Hyvinkää, Ulkorajat, linkit pdf:ään Ei Ei On, ei geometriaa? On, ei id:tä, ei geometriaa Ei INSPIRE:n mukainen, ei identifioivia tunnuksia, lisäksi WFS 1.0 versio Turku, KuntaGML Myös suojelumääräyks et, suojelualueet Ei Ei Ei Ei ks. asemaka ava ja kanta-kar tta Ei INSPIRE:n mukainen, WFS 1.0.0 ja 1.1.0 -versiot, ei GML 3.2.1 -tukea Tampere Indeksi, viheralueet, suojelu Kyllä, myös suojel u Ei On, suunnittelualu e Ei ks. asemaka ava ja yleiskaav a Ainakin INSPIRE-määrittelyt löytyvät XML:stä, meni läpi pääosin Monitor Test Run palvelusta, mutta muutamassa kohtaa "Failed", eivät näyttäneet kriittisiltä, joten pienillä korjauksilla pitäsi toimia Lahti, KuntaGML Kyllä, suojeltavia kohteita myös Ei Ei Ei Ei ks. asemaka av Ei INSPIRE:n mukainen, WFS 1.0.0 ja 1.1.0 -versiot, ei GML 3.2.1 -tukea Jyväskylä, KuntaGML Kyllä, myös suojelualueet ja suojelumääräyks et Ei GetCapabilit ies-kyselyn mukaan Poikkeamis asia, mutta GetFeaturekysely palauttaa vain <gml:null>u nknown</g ml:null> GetCapabilities -kyselyn mukaan Suunnittelutarv easia, mutta GetFeature-kys ely palauttaa vain <gml:null>unkn own</gml:null> ks. asemaka ava Ei INSPIRE:n mukainen, WFS 1.0.0 ja 1.1.0 -versiot, ei GML 3.2.1 -tukea Riihimäki, KuntaGML akaava:kaava palauttaa tyhjän vastauksen, GetCapabilities vastaus sisältää myös suojelumääräyks et, suojelualueet Ei Ei Ei Ei ks. asemaka ava ja yleiskaav a Ei INSPIRE:n mukainen, WFS 1.0.0 ja 1.1.0 -versiot, ei GML 3.2.1 -tukea

4(18) Tarkastelluista kunnista suurin osa käytti asemakaavan osalta KuntaGML:n versiota 2.1.1. ja poikkeamispäätös ja suunnittelutarveratkaisun osalta versiota 2.2.1. (testikunnista ainoastaan Jyväskylän rajapintapalvelusta löytyi vastaava aineisto). Tämänhetkiset (23.10.2017) paikkatietopalvelut.fi sivustolta löytyvät KuntaGML versiot olivat niiden osalta 2.1.3. ja 2.2.3. Yleiskaavan KuntaGML:n mukainen tietomalli ei ollut vielä kunnissa käytössä ollenkaan. Yleiskaavan tietomalli myös päivittyi selvityksen teon aikana. Päivitykseen ei ole ehditty tutustua. Lupapiste.fi palvelu hyödyntää KuntaGML:ää ja sinne on päivitetty mahdollisuus hyödyntää uusimpia KuntaGML-versioita [ 8 ]. Oletuksena siis on, että uusimmat versiot ovat tarkistettu ja kuntien hyödynnettävissä. Tämän vuoksi INSPIRE-vastaavuustaulukointi toteutettiin uusimmille versioille ja tekninen tarkastelu kuntien aineistoille, jotka olivat toteutettu aiemmilla versioille. Testitunnuksia Kuntatietopalveluun, josta uusimmilla versioilla toteutettu testiaineisto olisi ilmeisesti löytynyt, ei saatu selvityksen teon aikana. Kovin syvälle kuntien tulkintaan tietomallin kenttien sisällöissä ei tässä selvityksessä menty, sillä tekniset ongelmat estivät aineistojen kyselyn. Olemassaolevien ohjelmistojen kyky lukea kompleksista tietomallia KuntaGML on ns. rakenteista eli kompleksista GML:ää, joka tarkoittaa, että tietotyyppi voi sisältää toisia tietotyyppejä, jotka linkittyvät toisiinsa. Erilaisten asiakasohjelmistojen vastaanottokyky kompleksiselle GML-tiedolle on vielä heikko. Pitää ottaa myös huomioon, että myös INSPIRE:n tietomallit ovat kompleksista GML:ää. Yksi varteenotettava ilmainen työkalu GML-tyyppisen datan lukemiseen on QGIS:lle toteutettu WFS 2.0 lisäosa, jota testattiin Hampurin kaupungin INSPIRE-skeemaan tuotetun testirajapinnan [ 10 ]osalta onnistuneesti (kuva 1). KuntaGML ei tue vielä WFS 2.0 rajapintastandardia, joten kyseistä työkalua ei voi hyödyntää KuntaGML:n testauksessa. Ainoa tunnistettu asiakasohjelmisto, jolla KuntaGML:n mukaista tietomallia saa auki on Gaia GIS, jota on kehitetty osana Carbon Project yrityksen toimintaa vuosina 2006-2010 [ 7 ]. Myös GRASS-komennoilla tasoja saa KuntaGML:stä auki, mutta rajapinnassa olevat mahdolliset tyhjä tasot kaatavat ohjelmiston [ 2 ]. Testauksessa hyödynnettiin myös Postman- ja ogrinfo-ohjelmia. Kaupallisia ohjelmistoja ei testattu.

5(18) Kuva 1. Hampurin kaupungin testiaineistoa WFS-rajapinnan kautta haettuna. QGIS-ohjelmistoon kehitetty WFS 2.0 Client- lisätyökalu (versio 0.9.8 beta, kehittänyt Jürgen Weichand) pystyy purkamaan kompleksisen GML-rajapinnan. Hampurin kaupungin testirajapinnat on tehty INSPIRE:n maankäyttöskeemaa (PLU) vastaavaksi [ 10 ]. OGC:n vaatimukset ja geometria-tiedot KuntaGML:ssä Paikkatietorajapintojen standardeista vastaa OGC eli Open Geospatial Consortium. KuntaGML:n mukaisille kuntien WFS-rajapinnoille toteutettiin tekninen testaus, jossa tutkittiin OGC:n mukaisuutta. Taustatietona käytettiin myös Maanmittauslaitoksen raportoimaa testitulosta keväältä 2017 [ 1 ]. Testatut KuntaGML:n mukaiset kuntien rajapinnat eivät vastaa täysin OGC:n mukaisten palvelujen vaatimuksia, vaan aiheuttavat ongelmia asiakasohjelmistoissa. Lisäksi tällä hetkellä (10/2017) api.kuntatietopalvelu.fi-rajapintaan ei voi tehdä OGC:n standardin mukaista GetFeature-kyselyä. DescribeFeature-kyselyjen vastausten skeemat viittaavat myös vanhoihin versioihin. Lisäksi huomionarvoista on, että Gispo Oy ja Kuntaliitto pyysivät QGIS-ohjelmistoon tarjouksia KuntaGML-laajennoksen toteuttamista varten kesällä 2017 kolmelta toimijalta Euroopassa. Toteutukseen saatiin 2 asiantuntija-arvioita, joista toinen taho kieltäytyi toteutuksesta ellei päivitystä XSD-tiedostoon, WFS version migraatiota 2.0 -versioon sekä merkistöongelmien korjausta wsd-tiedostossa tehtäisi. Myös toinen tarjoaja ehdotti migraatiota WFS 2.0 versioon. Huomioitava on, että testaukset on tehty siis aiempiin skeeman versioihin, sillä testirajapintoja ei ole ollut saatavilla uusimpiin versioihin. Havaittuja ongelmia kuntien KuntaGML-rajapinnoissa: Kyselyiden vastaukset eivät ole sisällön osalta validia XML:ää [ 6 ] vaan sisältävät koodaamattomia varattuja merkkejä. WFS 1.1.0 -versiota käytettäessä %-merkki ei ole koodattu. WFS 1.0.0 -versiota käytettäessä myöskään &-merkki ei ole koodattu. Pakollinen gml:id-kenttä puuttuu osalta kohdetyyppejä (ainakin akaava:suojelualue) HTTP-protokollan POST-metodia ei tueta kyselyissä vaikka WFS:n GetCapabilities-kyselyn mukaan POST-metodi on tuettu WFS:n GetFeature-kysely FEATUREID-parametrilla ilman TYPENAME-parametria ei toimi

6(18) Muita huomioita: Erityisesti tarkastelussa olleiden KuntaGML-skeemojen viittaamat skeema-määrittelyt ovat saavutettavissa, mutta ainakaan rakval:rakennusvalvontaasia-skeeman tapauksessa näin ei ole Havaittuja ongelmia api.kuntatietopalvelu.fi-rajapinnassa (rajapinta löytyi KTP:tä esittelevästä esityksestä [ 14 ]): GetCapabilities-kysely: mikään krysp.kunnat.net -skeema ei ole saatavissa (403 forbidden), esim. http://krysp.kunnat.net/gml/poikkeamispaatos_ja_suunnittelutarveratkaisu DescribeFeatureType POST-kysely ei toimi vaikka GetCapabilities-kyselyn mukaan sen pitäisi toimia Mikään GetFeature-kysely ei toimi Muita KuntaGML-teknisiä ongelmia: Uusin KuntaGML:n yhteiset-skeemaversio vaatisi teknisiä korjauksia. Ainakin: <xs:pattern value="[0-9][0-9][0-9][0-9][0-9][0-9][0-9][-][0-9]"/> pitäisi olla <xs:pattern value="[0-9][0-9][0-9][0-9][0-9][0-9][0-9][\-][0-9]"/> Maanmittauslaitos havaitsi ongelmia keväällä 2017, joiden korjaamisen tilannetta ei ole tällä hetkellä mahdollista selvittää, koska GetFeature-kyselyä ei voi tehdä. Ilmeisesti Kuntatietopalveluun ei anneta tällä hetkellä testitunnuksia ja palvelu avautuu mahdollisesti vasta keväällä 2018 laajempaan käyttöön. Sivustolla asiasta ei ole tietoa. Maanmittauslaitos on myös tehnyt testejä soveltuuko KuntaGML KMTK:n rakennustietojen esittämiseen. Geometriaongelmiin viittaavista havainnoista on raportoitu seuraavaa: KMTK-kohdemallissa rakennuspohjien geometriaksi hyväksytään alue tai komposiittialue (polygon/multipolygon), joka kuvaa rakennuksen kivijalkaa tai räystäslinjaa. Pistegeometrioista ei pystytä muodostamaan kohdemallin mukaisia rakennuksia. Rakennusten reunaviivoista pystytään latauspalvelussa muodostamaan polygoneja, mutta vain reunaviivojen ollessa sulkeutuvia. Osittaisista reunaviivoista pystytään muodostamaan rakennuskohteen geometria varmimmin ja helpoimmin, jos niillä on jokin yhteinen ja uniikki tunniste. Myös reunaviivojen osien yhdisteestä pitää muodostua sulkeutuva reunaviiva. Näyteaineistoissa rakennukset pisteitä, polygoneja ja reunaviivoja - jotka eivät sulkeudu tai ovat vain rakennuksen osia eli ne eivät ole hyödynnettävissä Lisäksi Maanmittauslaitoksen testeissä löydettiin kohteita, joilla ei ole pakollisia ominaisuustietoja ja epäiltiin skeemanmukaisuudessa ongelmia, sillä esim. FME:n KuntaGML-reader ei avannut tiedostoja. Osa ongelmista voi selittyä tiedontuottajan järjestelmistä tai tiedontuottajasta, mutta skeeman ei tulisi sallia yllä kuvattuja geometria- ja kyselyongelmia. Maanmittauslaitoksen testit jatkuvat nyt syksyllä 2017 uudempiin versioihin perustuen. INSPIRE:n tietomallien mukaisuus Tietomallien vastaavuustaulukointi INSPIRE:n maankäytön tietomalleihin toteutettiin uusimpiin KuntaGML-versioihin, olettaen että ne ovat virallisia malleja, joita pitäisi hyödyntää.

7(18) Tietomallien osalta vertailu INSPIRE:n tietomalleihin toteutettiin erilliseen dokumenttiin [12]. INSPIRE:n maankäyttöpäätöstietoja eniten vastaava tietomalli on PLU eli Planned Land Use - tietomalli. Tulkinnanvaraista on halutaanko Suomessa käyttää PS ( Protected Sites ) skeemaa kaava-aineistojen suojelutietojen esittämiseen. AM-skeemassa ( Area Management Restrictions and Regulation Zones) ja yleiskaavan tietomallissa on myös joitain yhteneviä osioita, mutta sen osalta asia pitää yhteisesti päättää. Nämä asiat on kuvattu tämän selvitystyön loppuraportissa. Päähavaintona vertailusta on, että nykyisellään kansalliset maankäyttöpäätöksiin liittyvät tietomallit (KuntaGML:n asemakaava ja yleiskaava sekä Maakuntakaavat) eivät vastaa INSPIRE:n vaatimuksia, mutta niitä on mahdollista kehittää sen mukaiseksi tai laskennallisesti tuottaa puuttuvat tiedot. Tietomallien kehittämisessä toteutusmallina voi käyttää Hampurin kaupungin testiaineistoja [ 10 ] sekä ottaa oppia HAME-hankkeen hyvästä dokumentaatiosta [ 11 ]. Kaikkien tietomallien osalta pitää kehittää mm. INSPIRE id:n muodostamisen periaatteet. Kansalliset kaavamerkintöjen koodilistat pitää myös luoda yhteisesti. Terminologian yhteneväisyyteen ja tietomallien yhteneväisyyteen kannattaa kiinnittää huomiota. Alla on listattu tärkeimmät havainnot tietomallien vastaavuuksista. Erillisessä vastaavuustaulukointi-dokumentissa on tarkemmat tulokset [12]. KuntaGML:n asemakaavat ja yleiskaavat tietomallit KuntaGML:n asemakaavojen ja yleiskaavojen tietomallien osalta havaittiin paljon puutteita INSPIRE-vastaavuudessa. Osa tiedoista voidaan johtaa olemassa olevista tiedoista, osalle ei löytynyt sopivaa vastinkenttää. Dokumentaation puute myös vaikeutti selvityksen tekoa. Vaikka INSPIRE ei vaadi kuin muutamia pakollisia kenttiä, tietyt kentät olisi hyvä olla mukana kaavan tulkinnan vuoksi. Huomioitavaa on myös, että tietyissä kentissä on ehtona, että jos tiedot löytyvät, ne pitää raportoida sekä luoda niiden yhteyteen mahdollisesti tarvittavat koodilistat. Pakolliset tiedot, jotka puutteellisia: INSPIRE id puuttuu kaikilta osin PLU-skeema (Zoning Element osio) Begin Lifespan version > jos ei löydy kohteen muutos/lisäyspäivämäärää tietomallista, se pitää lisätä tietomalliin (tässä epävarmuutta löytyykö kyseinen tieto KuntaGML:n sisältä esim. toimituspvm -kohdasta) PLU-skeema (Zoning Element osio) Regulation Nature > yleiskaavan osalta KuntaGML:ssä ei omaa kohtaa tälle tiedolle kaavakohteissa. Kaikkiin lainvoimaisiin kohteisiin pitäisi lisätä Regulation Nature Value koodilistan perusteella: Defined in legislation. Olisi hyvä olla: PLU-skeema Official documentation > olisi hyvä löytää virallinen dokumentti kaavasta. Nyt osa tiedoista on löydettävissä KuntaGML:stä, mutta jotta vastaavuus tämän osion kanssa on selkeä, tietoja pitää täydentää.

8(18) PLU-skeema (Spatial Plan) Background map > viittaus taustakarttaan puuttuu, olisi hyvä olla, jos käytetty kaavassa. Jos tieto on, siitä pitää lisätä tiedot ComplexTypes luetteloon (date, reference, URI) PLU-skeema (Spatial Plan) Ordinance > Luettelot päätöspöytäkirjoista olisi hyvä lisätä, jos ne saatavilla (lisäksi lisättävä tällöin näistä pvm & linkki) PLU-skeema (Spatial Plan) Process Step General > Kaavan vaihe luettelona. Asemakaavan tietomallista tieto löytyi, yleiskaavan tietomallissa ei erikseen tätä kohtaa. PLU-skeema (Zoning Element) HILUCS Land Use > EU:n vaatima koodilista aluevarausmerkinnöistä pitää liittää mukaan tietomalliin ja tehdä vastaavuus kansallisen koodilistan kanssa (ks. tämän selvityksen loppuraportti). PLU-skeema (Zoning Element) Specific Land Use > kansallinen aluevarausten kaavamerkintälista tietomalliin mukaan (kannattaa toteuttaa kansallisesti yhteisesti) PLU-skeema (Supplementary Regulation) Specific Regulation Nature > Määrittelee onko maankäyttö kansallisen lainsäädännön mukainen. Asemakaavan tietomallista tieto löytyi, yleiskaavan tietomallissa ei erikseen tätä kohtaa PLU-skeema (Supplementary Regulation) Specific Supplementary Regulation > osa-alueille, viivoille, pisteille kansallinen koodilista mukaan tietomalliin PLU-skeema (Supplementary Regulation) Supplementary Regulations > EU:n vaatima HSRCL koodilista osa-alueille, viivoille ja pisteille PLU-skeema (Supplementary Regulation) Inherited From Other plans > False/True -tieto kenttään riippuen onko kohde periytynyt toisesta kaavasta Muuta: PLU-skeema (Zoning Elements & Supplementary Regulation) Valid to > jos jokin yksittäinen kohde lopettaa olemassaolonsa olisi se tieto oleellista, tärkeää mm. vaihekaavojen yleistyessä Terminologia yhteneväksi (ks. esim Process Step General Value -tiedot) Koodilistat pitäisi olla kansallisesti tallessa ja linkitettävissä Kaavan yleiset tiedot olisi hyvä olla linkitettynä ja arkistoituna jossain yhteisesti Tulkintaa helpottaisi huomattavasti UML-mallit (Yleiskaavan osalta päivityksen myötä tämä olikin toteutunut) Maakuntakaavojen tietomalli Maakuntakaavojen tietomallit olivat pääosin tehty INSPIRE:n skeemat huomioiden. Niiden osalta INSPIRE Id:n puuttuminen oli isoin puute. Kohdemerkinnöissä osa tiedoista mahdollisesti periytyy kaavatiedoista, jolloin ne voidaan laskennallisesti toteuttaa. Pakolliset tiedot, jotka puutteellisia: INSPIRE id Olisi hyvä olla:

9(18) Background Map > tieto löytyy, mutta käytetyistä taustakartoista pitää lisätä tiedot vielä ComplexTypes luetteloon (date, reference, URI) PLU-skeemassa: Saavatko kohdemerkinnät kaikki tiedot kaavan ulkorajalta? Mm. Regulation Nature, process Step General, jos periytyy, ei ongelmaa. PLU-skeemassa: Inherited From Other plans > False/True -tieto kenttään riippuen onko kohde periytynyt toisesta kaavasta (esim. Viheralue yleiskaavasta) PLU-skeemassa: Spatial Plan > plan Type Name > Plan Type Name Value listassa eri nimeämiskäytänteet kuin http://www.luettelopalvelu.fi/codelist/kaavatyyppi PLU-skeema (Supplementary Regulation) Specific Regulation Nature > Määrittelee onko maankäyttö kansallisen lainsäädännön mukainen, ei löydy maakuntakaavasta. PS-skeemassa INSPIRE:n Protection Classification Value lista pitää tarkistaa PS-skeemassa Legal Foundation Document > löytyy, mutta pitää lisätä CI_Citation määritykset dokumenteista Käyttökokemukset KuntaGML-tietomallin käytettävyyttä pohdittaessa erilaisten sidosryhmien kokemukset on myös huomioitava. KuntaGML:ää jo hyödyntävien kuntien sekä niiden kuntien jotka ovat harkinneet KuntaGML:n käyttöönottoa näkemys KuntaGML:n tietomallista ja hyödyntämisestä on pääosin positiivinen. Nämä kunnat olivat sitä mieltä, että kansallinen tietomalli on hyvä asia ja joissain kunnissa KuntaGML:n käyttöönotto oli vaikuttanut positiivisesti oman tiedontuotannon prosesseihin. Hyödyksi koetaan, että aineistojen käyttöpotentiaali valtakunnallisesti yhteensopivassa muodossa esim. kiinteistöihin ja kaavayksiköihin liittyvän tiedon osalta. Kun hyödynnetään usean kaupungin tietoja yhdessä, niin syntyy hyöty käyttäjälle tietenkin. Tämä hyöty ei kuitenkaan koske meitä yksittäisenä kuntana. Esimerkiksi konsulttien kanssa tehdään työtä perinteisellä tavalla tiedostopohjaisesti. Omien tietoaineistojen tietomalleja ja aineiston laatua on kyllä parannettua KuntaGML-prosessissa pakosta, koska on pitänyt tuottaa aineistot tietomallin mukaisesti. Peruskäyttäjän työprosesseihin tämä ei tosin ole juurikaan näkynyt kaupungissa - ainoastaan paikkatiedon ylläpidon puolella tämä on ollut relevanttia Kunnilla on kuitenkin omissa järjestelmissään pääsy dataan suoraan ja näin ollen kansalliset saavutettavuuden haasteet eivät niinkään koske kuntia. Kunnilla on silti toiveena tuottamiensa aineistojen laajempi hyödyntäminen ja sen vuoksi toivovat vahvasti KuntaGML:n teknistä kehittämistä ja asiakasohjelmistojen vastaanottokyvyn kehittämistä. Myös ohjeistusta ja mahdollista asiantuntijatukea tietomallien tuottamiseen toivottiin. Huomionarvoista on myös, että kunnat myös kokivat, että KuntaGML:n ja KTP:n hyödyntäminen tarkoittaa heidän osaltaan sitä, että mm. INSPIRE-velvoitteet on jo hoidettu mikä ei teknisten testien ja tietomallin vastaavuustaulukoinnin myötä ainakaan tällä hetkellä pidä paikkaansa. Yksi viestinnällinen haaste liittyi KTP:n rooliin Paikkatietoalustan kehityksessä ja näkyi myös kuntien kommenteissa - mihin suuntaan kehitystyö on menossa ja mitä tahoa kuunnella? Myös avoimena datana tarjottavat rajapinnat haastavat KTP:n roolia. Osa ei nähnyt KTP:lla suurta merkitystä kokonaisuudessa, koska aineistot ovat avattu.

10(18) Osa kunnista on myös tietoisesti päättänyt jättäytyä pois KuntaGML:n toimeenpanosta, johtuen resursseista ja tiedon/dokumentaation puutteesta. Emme ole julkaissut mitään Kuntatietopalveluun, siitä syystä että meidän (standardin mukaisen) rajapinnan saaminen KuntaGML:ksi vaatii konvertointia, joka jokaisen luokan osalta maksaa useita tonneja. Lisäksi meillä ei ole mitään tietoa käyttääkö KuntaGML:ää kukaan ja mikä sen status tulevaisuudessa on. Yllä olevan kommentin sävyn mukainen epätietoisuus vallitsee laajemmin kuntien keskuudessa. Kunnat toivovat suoraviivaisempaa ohjeistusta KuntaGML-tietomallin käyttöönottoon. KuntaGML-skeeman mukainen tietoaineisto on pystyssä asemakaavan ja kantakartan osalta. Sen hyödyntäminen on kuitenkin hyvin vähäistä, mahdollisesti jopa olematonta: niin sisäisesti kuin ulkoisestikin. Työprosessina liikutetaan tietoa tiedostopohjaisesti niin kaupungin sisällä kuin konsulttiprojekteissa. KuntaGML:n käyttö on vähäistä ennen kaikkea siksi, että sen käytettävyys on alhainen puuttuvan kaavakohtaisen kuvaustekniikan takia. Suurin puute on tosiaan se, että kuvaustekniikka ei mene läpi ja asiakasohjelmistossa joudutaan muokkaamaan kuvaustekniikkaa. Yleisesti ottaen kaikki haastateltavat kunnat halusivat että nykyisiä tietomalleja kehitetään, ottaen huomioon loppukäyttäjän tarpeet, kuka tietoa hyödyntää ja kuka maksaa kehitystyön. KuntaGMLn kanssa on tehty niin pitkään töitä, että ei olisi järkevää heittää hukkaan työtä. Tietomallin ja kaiken muun oheistoiminnan uudelleen tekeminen ja rahoittaminen koetaan oudoksi. Mitä hyötyjä uusi ratkaisu voisi tuoda ja mikä takaisi sen, että tällä kertaa työssä saavutettaisiin parempia tuloksia? Uusia malleja ei ole kiinnostusta lähteä kehittämään tai maksamaan. Nykyisten hyödyntäminen ja kehittäminen on varmaan se paras ratkaisu. Tärkeätä on kuitenkin suunnitella, mihin tarpeeseen tietomallia kehitetään ja mitkä ovat kunnan tarpeet tässä? Lisäksi pohdittava, ovatko tarpeet enemmän valtion puolella ja kohdentuvatko hyödyt esim. paikkatiedon liiketoiminnan puolelle. Kunnan intressiä ei tässä nähdä. Kunnan sisällä tästä ei välttämättä ole kauheasti hyötyä. Kunnan sisällä KuntaGML ei ole näyttänyt konkretiana eikä käytäntönä juuri mitenkään näiden viimeisen kymmenen vuoden aikana. Myös kustannuksien kattaminen on asia, johon on paneuduttava: kunnille syntyy valtakunnallisten tietomallien hyödyntämisestä kustannuksia, sen sijaan hyödyt koituvat lähinnä valtakunnan tasolle. KTP:n eli Kuntatietopalvelun toimivuutta sivuttiin haastatteluissa ja sidosryhmien kommenteissa, sillä sitä kautta rajapinnat pitäisi saada käyttöön. Sivustolla www.kuntatietopalvelu.fi kerrotaan, että KuntaTietoPalvelu avaa kuntien tietovarannot helposti löydettävässä muodossa. Sen vuoksi myös KTP:n toimintaa testattiin. Selvityksen tuottamisen aikana Gispo Oy:n henkilökunta ei ole päässyt testaamaan KTP:tä, sillä saadut Katso -alitunnukset eivät ole toimineet. Kuntaliiton Reseptikoneeseen, johon löytyi viittaus Kuntaliiton esityksestä [ 14 ], ei ole myöskään ollut pääsyä. Reseptikoneeseen ei ole myöskään viittauksia KTP:ssä. Kuntatietopalvelun tukipalveluun lähetettyihin kyselyihin ei ole vastattu selvityksen teon aikana.

11(18) Tekniset ongelmat ovat esiintyneet myös Maanmittauslaitoksen testeissä liittyen KMTK-hankkeen edistämiseen. Keväällä 2017 tehtyjen testausten ja raportoinnin jälkeen asia on pitänyt olla Kuntaliiton ilmoituksen mukaan työn alla ja korjattuna. Syksyllä 2017 jatkettujen testien aikana tilanne on kuitenkin ollut sama. Tämän dokumentin kommentointikierrokselta on kuitenkin saatu lisätietoa, että testit ovat jatkumassa. Näin Maanmittauslaitoksen edustaja kuvaili asiaa. Vaikka Kuntaliiton lupaamia teknisiä parannuksia tulisi käyttöön, se ei poista palvelun dokumentoinnin ja tuen puutetta eikä kaikkia muitakaan maaliskuun dokumentissa mainittuja ongelmia. Nykytiedon valossa ainut järkevä etenemismalli hankkeen kannalta on rakentaa suoria yhteyksiä kuntien rajapintapalveluihin, sillä KTP ei siinä välissä tuota prosessiin mitään lisäarvoa. 6.11.2017 MML on saanut toimivat tunnukset KTP palveluun, mutta vielä (16.11.2017) testejä ei oltu ehditty tuottaa kattavasti. MML:n alustavan arvion mukaan KTP:n käyttö ei tuo lisäarvoa verrattuna siihen, että samaa aineistoa käytetään suoraan kuntien omista rajapintapalveluista. Arvioinnin tulokset KuntaGML:n arvioinnin tulokset Ohjeistuksen ja dokumentoinnin lisääminen Ongelma : KuntaGML:n tietomallin maankäyttöpäätöksiin liittyvät käsitteelliset kohteet ovat monitulkintaisia. Tiedontuottajat ovat julkaisseet tietomallin kohdetietoja keskenään eriävissä tietotuotteissa, koska vaihtoehtoisia skeemoja on useita ja dokumentaatio heikkoa. Ohjeistusta ei ole tietomallin käyttöön ja esimerkit puuttuvat kenttien täytöstä Ratkaisu : Tarvitaan UML- ja ER-mallit KuntaGML:n tietomalleista ja selkeät ohjeistukset esimerkkiaineistojen kera sekä määritykset mitä versiota pitää käyttää. KuntaGML-tietotuotteista on saatava toimivia testipalveluita, jotka antavat konkreettisen kuvan tietomallin toimivuudesta käyttäjille ja tietomallin testaajille. Huom! Selvityksen aikana yleiskaavan tietomalliin on ilmestynyt UML-mallit, joihin ei ole ehditty perehtyä. Kompleksinen rajapinta & tekniset haasteet Ongelma : Yksittäinen hyödyntäjä ei helposti pääse käsiksi KuntaGML:n mukaisiin rajapintoihin johtuen erityisesti asiakasohjelmistojen puutteista vastaanottaa GML-muotoista dataa, mutta myös itse tietomallin ongelmien ja rajapinnan teknisten ongelmien myötä. KTP ei ole tuonut ratkaisua tietojen yhteiskäyttöön. Liian monimutkainen tietomalli johtaa vähäiseen käytettävyyteen Asiakasohjelmistoihin ei ole tukea GML-muotoisen datan käsittelyyn vielä Dokumentaation puute johtaa monitulkintaisiin tuloksiin tiedon tuottajan puolella

12(18) Kuntatietopalveluun ei ole pääsyä KuntaGML:n mukaiset aineistorajapinnat eivät noudata OGC:n määrityksiä. KuntaGML:n rajapinnat eivät ole INSPIRE-direktiivin vaatimusten mukaisia (WFS 2.0 & INSPIRE-skeemat) Ratkaisu : Tietomallin suunnittelu uudelleen ja raportoitujen teknisten ongelmien korjaus ja mahdollisuus tuottaa tietomallista myös kevyempää WFS-rajapintaa, joka avautuu useimmilla asiakasohjelmistoilla. Toinen vaihtoehto on tuottaa valmiita kyselyitä rajapintaan ja ohjeistaa niiden tuottaminen. WFS 2.0 version hyödyntäminen olisi myös suotavaa INSPIRE:n suositusten mukaan. Tämä mahdollistaisi myös ns. stored query -kyselyiden teon tietomalliin. Toinen ratkaisuvaihtoehto on siirtyä käyttämään uudella pohjalla tehtävää tietomallia ja standardia, jossa yllä mainitut asiat on huomioitu. KuntaGML skeeman kansainvälisten vaatimusten ongelmat Ongelma : KuntaGML-tietomalli eroaa tällä hetkellä merkittävästi INSPIRE-tietomallista, joka on todettu jo aikaisemmissa selvityksissä [ 3 ]. KuntaGML-tietomallia tulisi kehittää, jotta se vastaisi paremmin INSPIRE-tietomallia [ 12 ]. KuntaGML:n tietomallit eivät ole INSPIRE:n mukaisia Elinkaaren hallintaa ei ole mietitty osaksi KuntaGML:ää. Ratkaisu : Ottaa huomioon INSPIRE:n vaatimukset ja lisätä puuttuvat kentät ja koodilistat hyvän dokumentaation kera. Elinkaaren hallinta tulee tulevaisuuden maankäyttöpäätöstietojen osalta ottaa huomioon. Jokaisella kohteella pitäisi olla myös kuolinhetki ja tähän tietoon pitäisi päästä jatkossa käsiksi, muuten mahdollista on, että tietoa häviää matkan varrella. Maakuntakaavojen tietomallin arviointi Maakuntakaavojen osalta HAME-hankkeessa on tehty kattavaa työtä tietomallin harmonisoinnin osalta ottaen huomioon INSPIRE:n ja kaavoittajien toiveet, joten tässä raportissa niitä ei käydä erityisesti läpi. Ainoastaan INSPIRE:n tietomallien mukaisuus -osiossa maakuntakaavojen tietomallia on arvioitu. Yleisesti ottaen tietomalli vastaa kansainvälisiä määrityksiä, mutta muutamia lisätietoja olisi hyvä lisätä tietomalliin. Kuntien kyvykkyys tuottaa tietomalleja kansainvälisten vaatimusten mukaisesti Edellisten selvitysosioiden perusteella arvioitiin kuntien kykyä tuottaa rajapintoja tietomallien mukaisesti. Arvioinnin tueksi toteutettiin haastattelut etäyhteyden avulla 4 kunnan paikkatietovastaaville ja kaavoittajille kysymällä heiltä millainen ratkaisu toimisi parhaiten asian toteuttamiseksi. Alla on poimittu haastatteluista nousseita teemoja.

13(18) Kauttaaltaan haastattelut kunnat pitävät hyvänä asiana sitä, että kansallinen tietomalli on olemassa kaavoitusdatalle. Vaikka itse käytännön hyöty kunnille kansallisen tietomallin käyttöönotosta on joskus jopa häilyvä, pidetään kansallista mallia arvossa. Kunnissa ollaan pitkälti tyytyväisiä oman tietomallin/-aineiston laatuun oli se tai ei INSPIRE-direktiivin ja KuntaGML-tietomallin mukaista. Tämä seikka puhuu siitä, että kunnat pitävät suuressa arvossa tietoaineistossaan erityisesti niiden käytännöllisyyttä heidän omassa toimintaympäristössään. Toiveena onkin esimerkiksi saada yhteinen kuvaustekniikkamalli osaksi standardia, mikä lisäisi tietomallin käytännöllistä arvoa. Lisäksi se toki säästäisi huomattavasti työresursseja kuntien päässä. Tämän mahdollistamiseksi olisi toki tehtävä tietojärjestelmäyhteydet kuntoon. Evolta Oy:n selvityksen [ 9 ] mukaan yleiskaavoja tarjoaa INSPIRE:n mukaisesti 5 kuntaa ja WFS-tasoja 0 kpl kuntia. Samaisen selvityksen kunnille tehdyn kyselyn tulosten mukaan asemakaavojen osalta n. 74% kuntien asemakaavoista on vektorimuodossa. Haastatelluista kunnista kaikilla oli asemakaavojen osalta tätä parempi tilanne (80-100%). Haastateltava eivät osanneet arvioida muiden kuntien tilannetta. Moni tosin arveli, että pienemmissä kunnissa luku olisi matalampi. Tämän lisäksi painotettiin, että tärkeätä ei ole vain saavuttaa mahdollisimman korkea kattavuus prosenttina, vaan myös kaava-aineistojen tietosisältöä ja sen laatua on arvioitava. Evoltan selvityksen mukaan INSPIRE:n vaatiman WFS-rajapinnan toteuttamiseen ei ole kunnilla teknisiä välineitä. Tämän osalta ne kunnat, joilla WFS rajapinta oli (kuntagml:n mukainen), kokivat että ne on toteutettu INSPIRE:n vaatimusten mukaisesti. Kunnat haluavat toimia tiedontuottajina ja luoda rajapintapalvelut omista järjestelmistä. INSPIRE:n seurantaraportointi on pieni vaiva tuottaa, mutta ei hyödytä kuntia itseään. Kansallisesti pitäisikin pohtia, mitä yhteistä tietoa Suomessa maankäyttöpäätöstiedoista tarvitaan ja mitä kunnat haluavat omasta datastaan irti. 3D-kaupunkimallit, lisätyn todellisuuden hyödyntäminen ja virtuaalitodellisuuden sovellukset halutaan mukaan erityisesti vuorovaikutuksen prosesseihin kaavoituksessa, mutta niiden merkitystä ei myöskään pidetään mitenkään elintärkeänä. CityGML kiinnosti haastateltuja kuntia, mutta sitä ei ole otettu vielä käyttöön taikka siihen ei ole vielä ehditty tutustua tarkemmin. Selvityksen aikana Ympäristöministeriön teettämän digikaavoituksen verkkoaivoriihen tuloksien mukaan vastanneista 40 % edellytti kuitenkin kansainvälisten standardien käyttöä tulevaisuudessa. Sähköiseen arkistointiin on myös erilaisia käytänteitä, toisilla pidemmälle viety, toisilla ei ole vielä ollenkaan. Monien järjestelmien käytöstä halutaan päästä yksinkertaisempaan malliin ja pdf-tietojen tai paperikarttojen arkistoinnista eroon. Myös valtion tahon vastaanottokyky tiedoille pitäisi olla standardoitua ja perustua rajapintoihin, sillä nyt eri virastot pyytävät tietoja kunnilta eri formaateissa. Historiatietojen tallentamista ei oltu huomioitu kaava-aineistojen osalta kaikissa kunnissa, mutta esimerkiksi kiinteistön tietoihin voi jäädä merkintöjä kohteen kaavoituksen aiemmasta tilanteesta. Pelkona oli myös että aineistonhallinta paisuu, jos tietoja tallennetaan eri vaiheista turhaan. Myös vanhojen kaavojen digitaalistamisprosessit ovat vaihtelevia. Osa kunnista on

14(18) harmonisoinut ja digitoinut myös vanhoja kaavoja (esim. Turku asemakaavojen osalta), osa kunnista on päättänyt että vanhat kaava-alueet digitaalistetaan vasta kun alue tulee uudelleen kaavoitettavaksi (esim. Joensuu). Vaiheasemakaavan mahdollisuutta ei oltu vielä huomioitu omissa kaavaprosesseissa. Osalla pieniä kuntia ei ole omaa aineistontuotantoa, jolloin konsultit ovat avainasemassa tiedon saatavuuden osalta. Kunnat kokevat, että esimerkiksi yhteisistä konsulttipalveluiden hankintaohjeista koituisi suoria kustannushyötyjä kunnille. Kaivattiin siis yhteisiä pelisääntöjä tilauksissa ja tarjouspyyntöjen määrittelyissä. Vastuulliseksi tahoksi mainittiin Ympäristöministeriö. Yhdenmukaista tietoa pitäisi jakaa kunnille. Eri tahot puhuvat liikaa omista näkökulmistaan ja omia intressejä painottaen. Se on rasittavaa toimialalla eikä ole hyödyllistä millekään taholle. Yhdenmukaisuuteen liittyen töiden vaatimusmäärittelytyö pitäisi tehdä myös valtakunnallisella tasolla, jotta esimerkiksi konsulteilla toimitettavat työt voitaisiin hankkia helpommin ja tehokkaammin. Usein pienissä kunnissa ostetaan työ konsulteilta. Lopputulos pitäisi olla hyvin määritetty, jotta kaikki kunnat voisivat sitten tehdä hankinnat näppärämmin. Kunnat tarvitsevat myös entistä parempaa ja ajantasaisempaa ohjeistusta miten tietomallit ja lakiin tulevat muutokset pitää ottaa huomioon. Tällä hetkellä ohjeistusten tulkinta on kirjavaa, mikä on rasite yhteismitallisen tiedon saavuttamiseksi tietosisältöjen laadun kärsimisen lisäksi. Ohjeistusta tarvitaan muun muassa: Työprosessien vaiheisiin, jotta tiedon laatu paranee ja yhteismitallistuu. Tietomallien käyttöönoton ja kehityksen tukemiseen (ohjeet, asiantuntijatuki ja projektirahoitus) Sähköiseen arkistointiin Elinkaariasioiden huomioimiseen ja milloin historiatietoja tallennetaan ja milloin ei Vaihekaavojen huomioimiseen tietomalleissa Vanhojen kaavojen digitaalistamisprosessihin ja harmonisointiin Hankintatoimia varten esim. konsultointiprojekteissa Muita huomioita: Lainsäädäntöön liittyen mainittiin selvitysten laatuvaatimusten kasvaminen, mikä on johtanut joissain kunnissa yliselvittämiseen eri teemojen osalta. Tietohallinnon osalta kaikki haastateltavat kunnat toivoivat lisää resursseja. Kunnat toivoivat myös seudullista yhteistyötä prosessien kehittämiseksi. Kustannushyötyanalyysi Kansallisten maankäyttöpäätöstietojen eri toimintamalliskenaarioiden kustannushyötyanalyysi on tehty pohjautuen valtiovarainministeriön kehityshankkeiden kustannus-hyötyanalyysien mallipohjaan. Taulukkoa voi tarkkailla erikseen raportin liitetaulukossa [ 15 ]. Analyysiä ei ole tehty perinteisesti täysin mallipohjan periaatteiden mukaisesti, sillä pohja on tarkoitettu ja erityisen hyödyllinen sellaisenaan konkreettisia

15(18) kehityshankkeita analysoidessa. Tässä vaiheessa Maankäyttöpäätökset-hanketta ei ole vielä sellaisia määritelty. Toimintamalliskenaarioiden osalta on arvioitu niiden toteuttamisesta koituvia kustannuksia ja kustannushyötyjä. Kustannuksia ja hyötyjä on arvioitu perustuen kuntien haastatteluihin ja eri sidosryhmiltä saatuihin arvioihin. Analyysin tuloksena nähtiin, että kummankin skenaarion kustannushyödyt (niin taloudelliset kuin ei-taloudelliset) muistuttavat hyvin paljon toisiaan, sillä niin KuntaGML-skeeman jatkojalostaminen kuin uuden tietomallin kehittäminen -skenaarioilla on samoja tavoitteita. Tavoitteiden saavuttaminen synnyttää mahdollisesti taloudellisia hyötyjä, kuten: Kuntien tehostunut tiedon tuotanto Kaavoitukseen liittyvän tiedon tehostunut käyttö Tehostunut hankintatoimi johtuen yhteisestä ohjeistuksesta Toimintamallien tehostunut käyttöönotto jaetun tuen ja koulutuksen avuin Ei-taloudellisia hyötyjä voidaan nähdä olevan mm. prosessien jouhevoitumisesta johtuva työtyytyväisyys ja ajankäytön tehostuminen. Toimintamalliskenaarioiden tuloksien eroja voidaan etsiä skenaarioiden aiheuttamista kustannuksista, kuten tietomallien välisten migraatiotyökaluiden kehittämisestä tai tietomallin kehittämisestä INSPIRE-skeeman mukaiseksi. Suurimmat kustannukset kummankin skenaarion kohdalla syntyvät tietomallien käyttöönotosta tiedontuottajien eli kuntien tasolla. Myös skenaarioiden vaikuttavuutta olisi tärkeä pohtia ja suunnitella: on todennäköistä, että skenaarioiden välillä on eroja siinä, kumman avulla tuotetaan tehokkaammin laajempi hyöty kansantalouden näkökulmasta. Tässä vaiheessa hanketta vaikuttavuutta on hyvin vaikea arvioida; itse tiedontuottajien näkökulmaa pitäisi selvittää laajemmin, jotta päästäisiin laajemmin selville heidän roolistaan skenaarioiden tavoitteiden toteutumiseen. Yhteenveto Selvityksessä käytiin läpi kansallisia maankäyttöpäätöstietojen tietomalleja, pääasiassa KuntaGML:n asemakaava- ja yleiskaavatietomalleja, KuntaGML:n WFS-muodossa olevia kuntien asemakaavarajapintoja sekä maakuntakaavan tietomallia. KuntaGML:n hyödyntämisessä havaittiin useita ongelmia: Testatuissa KuntaGML:n mukaisissa WFS rajapinnoissa on teknisiä ongelmia, jotka estävät niiden käytön nykyisellään Asiakasohjelmistot eivät pysty vastaanottamaan KuntaGML:n mukaisia tietomalleja johtuen puutteista standardinmukaisuudessa, mutta myös johtuen kompleksisesta WFS-rajapinnasta ja asiakasohjelmistojen kyvystä vastaanottaa GML-muotoista tietoa Tietomallit eivät noudata nykyisellään INSPIRE:n vaatimuksia Rajapinnat eivät noudata nykyisellään INSPIRE:n vaatimuksia WFS 2.0 version käytöstä

16(18) Tietomallien dokumentaatio on heikkoa ja aiheuttaa tulkinnanvaraisuutta Elinkaari-asioita ei ole vielä huomioitu selvityksen kohteena olevissa KuntaGML:n rajapinnoissa Käyttökokemukset: Osa hyödyntäjistä ei nähnyt järkeä KuntaGML:n jatkokehittämisessä Kunnat, erityisesti jo KuntaGML:n mukaisesti tietomallinsa tuottaneet, halusivat että tietomallia kehitetään, jotta tiedon hyödyntäminen laajenisi. Jos tietomallia ei kehitetä tai siitä luovutaan, joutuvat kunnat maksamaan lisää migraatiotyöstä. Kaikki kunnat eivät nähneet hyödyllisenä tuottaa kansallista mallia, sillä oma tiedontuotannon prosessi ja tietojen hyödyntämien oli erillään KuntaGML:stä. Siksi kunnille pitäisi löytää yhteiseen tietomalliin siirtymisestä selkeitä hyötyjä. KuntaGML:n myötä osa kunnista koki että tiedot ovat valtakunnallisesti yhteismitallisia ja näin INSPIRE:n mukaisia, vaikka selvityksen mukaan näin ei ole Moni kunnista kuitenkin toivoi standardinmukaista mallia, jotta tietojen tuottaminen helpottuu varsinkin lainsäädännön muuttuessa ja toimintatapojen muuttuessa KuntaGML:n käytöstä aiheutuvat hyödyt: Osa kunnista koki tietomallin hyvänä ja sen lisänneen oman aineiston eheyttä KuntaGML-tietomallin laajemman käytön esteeksi on koettu tietomallin monimutkaisuus ja tietomalliin pohjautuvien rajapintojen käyttöongelmat alan ohjelmistoissa. Tietomallin käytettävyyden näkökulmasta tulevaisuudessa on syytä panostaa tietomallin yksinkertaistamiseen ja selkeään dokumentaatioon, jotta käyttäjien keskuudessa tulkinnanvaraisuus jää pienemmäksi. Lisäksi tekniset ongelmat on ratkaistava, jotta hyödynnettävyys paranee. Kuntien näkökulmasta KuntaGML:n kehittäminen on tärkeää, sillä siihen on panostettu etenkin kunnissa, jotka ovat ottaneet tietomallit käyttöön. Yleisesti ottaen halutaan yhteinen kansallinen malli selkeine ohjeistuksineen, joka täyttää INSPIRE:n vaatimukset mutta erityisesti myös kansalliset vaatimukset niin, että kunnat kokevat itse myös hyötyvänsä prosessista. Loppupäätelmät skenaarioihin A) KuntaGML:ää kehittämällä voidaan luoda tulevaisuudessa tietomalli, joka vastaa kansainvälisiin vaatimuksiin tai B) KuntaGML:ää ei pystytä kehittämään tulevaisuuden maankäyttöpäätöstietojen tietomalliksi. KuntaGML ei täytä nykyisellään kansainvälisiä vaatimuksia ja sitä täytyy merkittävästi kehittää. Päätettävä on luovutaanko nykyisestä mallista vai voiko tietomallia kehittää selkeästi paremmaksi, jotta tavoitteet toteutuvat. Molemmissa tapauksissa kunnat tarvitsevat tukea nykyisten palveluiden kehittämiseen. Ne kunnat, joilla kuntagml:n mukaiset rajapinnat ovat, joutuvat muuntamaan tai lisäämään tietomalliin osia. Mahdollisesti myös koko rajapintapalveluun pitää tehdä muutoksia, joiden kustannukset vaihtelevat varmasti

17(18) palveluntuottajan tarjousten mukaan. Migraatio pitää siis suunnitella hyvin. Ne kunnat, jotka vasta harkitsevat tietomallin käyttöönottoa, tarvitsevat selkeää ohjeistusta ja tukea työn toteutukseen. Ehdotus : KuntaGML:n maankäyttöpäätöstietoja koskevat tietomallit suunnitellaan uudelleen ottaen huomioon INSPIRE:n tietomallit ja tekniset vaatimukset. Samalla migraatioon / tietomallin kehitykseen annetaan selkeät ohjeistukset kunnille. Uusi tietomalli pitää dokumentoida kattavasti ja koodiluetteloita on ylläpidettävä kansallisesti.

18(18) Lähteet [1] Maanmittauslaitos. 2017. Kuntatietopalvelun hyödynnettävyys-raportit ja sähköpostit (09-11/11/2017). [2] Gispo Oy. 2017. Oslandia Ltd & CampToCamp Ltd tarjouspyyntöjen yhteydessä annetut arviot KuntaGML:stä. Osana hanketta KuntaGML- laajennoksen kehittäminen QGIS-ohjelmistoon. (06/2017) [3] Sito Oy. 2017. INSPIRE-vertailutaulukot. [4] Gispo Oy. 2017. Hyvinkään kaupungin arviot omista rajapintapalveluista ja KuntaGML:stä, sähköpostikeskustelu (09-2017) [5] INSPIRE Validator. 2017. INSPIRE Sandbox. [6] Microsoft. 2017. XML Reserved Characters [7] The Carbon Project. 2017. Gaia software. [8] Lupapiste.fi. 2017. Tiedote 11.10.2017. [9] Evolta Oy. 2017. Esiselvitys kuntien digitaalisista maankäyttöpäätöksien kyvykkyyksistä. [10] Hampurin kaupunki 2017. Hampurin INSPIRE:n mukaiset WMS ja WFS -rajapinnat saatu testikäyttöön selvityksen tueksi. [11] SYKE 2017. Hame-hankkeen tietomallin dokumentaatio. [12] Gispo Oy 2017. Vastaavuustaulukoiden muodostaminen. YM:n Tulevaisuuden maankäyttöpäätöstietojen vähimmäisvaatimukset-hanke. [13] Gispo Oy 2017. Turun, Paimion, Lahden ja Joensuun haastattelumuistiot. YM:n Tulevaisuuden maankäyttöpäätöstietojen vähimmäisvaatimukset-hanke. [14] Suomen Kuntaliitto. 2017. KuntaTietoPalvelu - ajantasaista tietoa suoraan kunnista. [15] Gispo Oy 2017. Kustannushyötyanalyysi - tietomallien hyödyntämisen kustannukset ja hyödyt. YM:n Tulevaisuuden maankäyttöpäätöstietojen vähimmäisvaatimukset-hanke.