Selvitysraportin tiivistelmä KMTK-MAASTOTUO/es-projekti

Selvitysraportin tiivistelmä

itos Selvitysraportin tiivistelmä 1 (24) Sisällys 1. Yleistä... 2 2. KMTK:n vaatimusten toteuttaminen nykyisessä tuotantojärjestelmässä... 2 2.1. Vaatimusten toteuttaminen JAKOmtj:ssa... 2 2.1.1. Kohdekohtaisen pysyvän tunnisteen hallinta ja kohteiden elinkaaren hallinta... 2 2.1.2. 3D-mallinnus... 3 2.1.3. Laadunhallinnan kokonaisuus... 3 2.1.4. Avoimuus ylläpidossa... 4 2.1.5. Avoimen lähdekoodin toteutus... 4 2.1.6. Yhteinen tietomalli... 4 2.1.6.1. Rakennetut tilat ja rakenteet... 4 2.1.6.2. Liikenneverkko... 7 2.1.6.3. Maasto... 9 2.1.6.4. Osoite... 10 2.1.6.5. Hydrografia... 10 2.1.6.6. Muut teemat... 11 2.1.7. CityGML... 12 2.1.8. Linkitetyn tiedon hallinta... 12 2.1.9. Siirtyminen TM35FIN-koordinaatistoon... 13 2.1.10. Siirtyminen N2000-korkeusjärjestelmään... 14 2.1.11. MTK:n tietojen siirto koontitietokantaan... 14 2.1.12. Kohteiden siirto koontitietokannasta MTK:aan... 14 2.1.13. MTK:aa hyödyntävien järjestelmien muutokset... 15 2.2. Vaatimukset KMTK:n koontitietokantaympäristölle... 15 2.2.1. Koontitietokanta ja Digiroad... 15 3. Vaatimuksista uudelle tuotantojärjestelmälle... 17 3.1. Järjestelmän yleinen toiminnallisuus... 17 3.2. Järjestelmän tietojen hallinta... 21 3.3. Muita vaatimuksia... 24 4. Ehdotuksia ja suosituksia... 24

itos Selvitysraportin tiivistelmä 2 (24) 1. Yleistä Vuoden 2017 alussa käynnistyneen KMTK-Tietokanta/to-projektin aikana oli epäselvyyttä, millaista toiminnallisuutta toteutettavan järjestelmän tulisi sisältää. Erityisesti aineiston ylläpitoon liittyvät osat olivat epäselviä. Maaliskuussa projektissa koottiin vaatimuksia KMTK-tietokannan tekniselle arkkitehtuurille ja niiden toteuttamismahdollisuuksia vertailtiin neljällä eri vaihtoehdolla. Ohjelmatoimiston kokouksessa 25.4.2017 päätettiin, että KMTK-Tietokanta/to-projektissa toteutetaan koontitietokanta PostGIS alustalla ja että MML:n ylläpitojärjestelmän alustaratkaisu tehdään myöhemmin. KMTK- MAASTOTUO/es-projekti oli osa ylläpitojärjestelmän selvitystyötä. Projektin lopputuloksena syntyneessä selvitysraportissa on projektiryhmän ehdotus, kuinka olemassa olevan järjestelmän osia tulee kehittää, jotta KMTK:ssa vaadittavia ominaisuuksia voidaan tukea riittävällä tasolla. Lisäksi raportissa on lista vaatimuksista, mitä ominaisuuksia kannattaa kehittää nykyisen tuotantojärjestelmän sijaan rakenteilla olevaan KMTK-järjestelmään tai uuteen tuotantojärjestelmään. Tässä tiivistelmässä on esitetty varsinaisen selvitysraportin ydinkohdat. 2. KMTK:n vaatimusten toteuttaminen nykyisessä tuotantojärjestelmässä 2.1. Vaatimusten toteuttaminen JAKOmtj:ssa Luvussa 2.1 kerrotaan, mitkä KMTK:n asettamista vaatimuksista voidaan toteuttaa nykyisessä tuotantojärjestelmässä kokonaan tai osittain sekä ne, mitä ei voi tai ei kannata toteuttaa. Lisäksi luvussa kerrotaan muista kehityskohteista, joita nykyjärjestelmään tulee toteuttaa KMTK-yhteensopivuuden parantamiseksi. Osa KMTK:n vaatimuksista ovat sellaisia, että ne pitää toteuttaa sekä nykyiseen tuotantojärjestelmään, että myös KMTK:n koontitietokantaympäristöön. Tällaisia kehitystarpeita on dokumentoitu lukuun 2.2. Maastotietokantaan ja JAKOmtj-järjestelmään tehtävät muutokset pyritään suunnittelemaan siten, että niillä pystyttäisiin mahdollisimman hyvin täyttämään KMTK:n asettamat vaatimukset. KMTK ei kuitenkaan tule mahdollistamaan nykyisiä tai nykyisen kaltaisia maastotietotuotteita vielä vähään aikaan, joten nykyiset tuotteet tulee olla tarjolla lähivuosina. Maastotietokannan muutokset pyritään toteuttamaan siten, että nykyisten maastotietotuotteiden tuottaminen on myös mahdollista. 2.1.1. Kohdekohtaisen pysyvän tunnisteen hallinta ja kohteiden elinkaaren hallinta

itos Selvitysraportin tiivistelmä 3 (24) Pysyvien tunnusten hallintaa ei ole mielekästä tehdä kohteiden editointivaiheessa koska sama kohde saattaa muuttua useaan kertaan ennen sen rekisteröintiä. Selvitystä varten tehtiin proseduuri, joka etsii muutoksien kohdalta pysyvän tunnuksen käsittelyssä tarvittavia tietoja tuotantosuunnitelman tai työn rekisteröinnin yhteydessä. Tietojen tunnistaminen tapahtui vertaamalla lisättyjen, muutettujen ja poistettujen kohteiden kohdalla tapahtuneita geometria- ja ominaisuustietojen muutoksia. Selvitysten perusteella tietokantakohteiden pysyvien tunnusten hallinta vaikuttaisi olevan mahdollista toteuttaa JAKOmtj:ssä. Aineiston siirto nykytuotantojärjestelmästä KMTK:n koontitietokantaan tullaan tekemään samalla prosessilla kuin kuntien aineiston lataus. Kohteiden muutokset sekä pysyvien KMTK -tunnisteiden ylläpito tehdään lataus/tallennus -vaiheessa. Nykytuotantojärjestelmän ei siten tarvitse tuottaa paikkatietokohtaisia pysyviä tunnuksia. 2.1.2. 3D-mallinnus Smallworld tietokannan geometriatietomalli ei tue 3D geometriatyyppejä, joten 3D-kohteiden muodostaminen ja hallinta on asetettu vaatimukseksi tulevalle MML:n ylläpitojärjestelmälle. 2.1.3. Laadunhallinnan kokonaisuus JAKOmtj-tuotantojärjestelmän laadunhallinnan päätarkoituksena on estää virheellisen tiedon tallentuminen Maastotietokantaan, vaikka se sisältääkin myös menetelmiä virheiden etsimiseen tietokannasta. Laadunhallinnan työkalut ja menetelmät on rakennettu ja niitä on lisätty JAKOmtj-sovellukseen tarpeen mukaan silloin, kun on havaittu jonkin virheen tai virhetilanteen toistuminen aineistoa käytettäessä. Selvityksessä on kuvattu JAKOmtj:n laadunhallintaa yksityiskohtaisesti eri sovellusosissa ja toiminnoissa: Kohdeikkunat Eheystarkastelut Topologiatarkkailija Rekisteröitävyyden tarkistukset Muita eheystarkistustyökaluja Korkeustiedon laaduntarkistukset Hakutoiminnot Aineiston lataaminen tietokantaan Sisäinen laaduntarkistaminen Ulkoinen laaduntestaus

itos Selvitysraportin tiivistelmä 4 (24) 2.1.4. Avoimuus ylläpidossa 2.1.5. Avoimen lähdekoodin toteutus JAKOmtj-tuotantojärjestelmän laadunhallinnan työkalut ja menetelmät on rakennettu niin kattaviksi, kuin nykyisessä käytössä on arvioitu tarpeelliseksi. Kun MTK:n tietoja jatkossa ladataan KMTK:n koontitietokantaan ja jos KMTK-laatuvahdin tekemissä tarkistuksissa löytyy toistuvasti esiintyvä virhe, pyritään kyseistä laatusääntöä vastaava laatutesti lisäämään JA- KOmtj:än. Selvityksessä on kuvattu JAKO-sovellusten etäkäyttöä internet yhteydellä MML sisäverkon palvelimelle, jossa JAKO-sovellus käynnistetään. MML:n ulkopuolisia JAKOmtj-sovelluksen käyttäjiä ovat Kotuksen (= Kotimaisten kielten keskus) MML Nimistörekisterin nimistönhuoltajat. KTJ-rekisterinpito ja MML KTJkii rekisterinpitosovellus on tarkoitettu kiinteistörekisteriä ylläpitävien kuntien etäkäyttöön. Smallworld ohjelmistotuotteesta on asiakkaiden saatavilla tietoja uusista tuotejulkaisuista sekä roadmap tulevista tuoteversioista. Smallworld ohjelmisto-tuotteen uudet tuoteversiot tukevat uusimpia Windows ja UNIX käyttöjärjestelmien versioita sekä palvelinten virtualisointia (VMWare). Smallworld ohjelmistotuotteeseen kuuluu tehokas oliopohjainen kehityskieli: Smallworld Magik. Smallworld 5 tuoteversiosta alkaen Smallworld Magik ohjelmointikieli tulkataan Java virtuaalikoneelle. 2.1.6. Yhteinen tietomalli KMTK-kohdemallityö oli vielä kesken projektin toimiaikana, joten tämän raportin selvitykset perustuvat kohdemallien ja prosessien määrittelyihin, jotka olivat olemassa joulukuun puolivälissä 2017. 2.1.6.1. Rakennetut tilat ja rakenteet KMTK:n koontitietokantaan on tarkoitus siirtää myös kuntien rakennusaineistoa. Kuntien ylläpitämien alueiden rajaukset tulisi saada käyttöön JA- KOmtj:ssä. Tällöin MTK:ssa tehtävä rakennettujen kohteiden yhteensopivuustyö voidaan kohdistaa alueille, joiden ylläpito on jatkossa KMTK:ssa MML:n vastuulla. Kuntien ylläpitämien alueiden rajauksia ei ole vielä käytettävissä vuoden 2018 alkupuolella. Rajauksia tultaneen saamaan kunnittain sitä mukaa kun kunnan aineisto alkaa olemaan KMTK yhteensopivaa ja kunnan kanssa tehdään sopimus aineiston ylläpitoon liittyen.

itos Selvitysraportin tiivistelmä 5 (24) 2.1.6.1.1. Rakennukset MTK-rakennuksille tulee yhteensopivuusvaatimuksia KMTK-rakennusten geometrian erilaisesta mallinnustavasta ja ominaisuustietojen laajemmasta määrästä. Selvitysraportissa on kuvattu yksityiskohtaisesti seuraavia rakennuksiin liittyviä erityispiirteitä: Geometrian eroavaisuudet MTK-KMTK Rakennusten tasosijainti, ylä- ja alapuoliset kohteet ja vertikaalisuhde Rakennusten varusteista Ominaisuuksien eroavaisuudet MTK-KMTK RHR-linkitys Lentoesteet Yhteenveto JAKOmtj:ssä rakennuksille tehtävistä tietomalli- ja sovellusmuutosten pääkohdista, sekä automaattisista ja vuorovaikutteisista toimenpiteistä Toimenpiteitä ei kohdisteta alueille, joista kunnat ovat toimittaneet oman alueensa rajauksen KMTK:aan. Tietomalli- ja sovellusmuutosten pääkohdat: Tarvittavien uusien ominaisuuksien tallentamisen mahdollistaminen MTK-rakennuskohteiden liittämisen saman rakennuksen eri osiksi mahdollistaminen Päällekkäisten rakennusten ja rakennusten osien tallentamisen mahdollistaminen Tasosijainnin, ylä- ja alapuolella olevan kohteen id:n, sekä vertikaalisuhteen tallentamisen mahdollistaminen rakennukselle Irrotusvaiheessa tehtävät luokitusmuutokset sekä varusteiden muodostaminen Automaattiset toimenpiteet rakennuksille: RHR-rakennusten linkitys MTK-rakennuksiin Rakennuksen yhteydessä olevista savupiipuista, katoksista ja pylväistä muodostetaan siirtotiedostoon KMTK rakennuksen varusteita irrotuksen yhteydessä

itos Selvitysraportin tiivistelmä 6 (24) KMTK:n mukaisen luokituksen tuottaminen MTK:n asuinrakennuksille sekä kirkoille ja kirkollisille rakennuksille irrotuksen yhteydessä Vuorovaikutteiset toimenpiteet rakennuksille: Automaattisen RHR-linkityksen jälkeen linkittämättä jääneiden RHR ja MTK -rakennusten linkitys vuorovaikutteisesti Mikäli RHR-linkitystä rakennukseen ei voi tehdä, vuorovaikutteisesti tulee asettaa ominaisuudet: käyttötarkoitus, kerrosluku maan päällä, elinkaaren tila, korkeus, lentoeste MTK:n laajojen rakennuskohteiden jakaminen omiksi rakennuskohteiksi Osittelua vaativien rakennusten jakaminen osiin Päällekkäisten rakennusten ja rakennusten osien tallentaminen Tasosijaintitiedon tallentaminen rakennuksille jotka eivät ole maanpinnalla Ylä- ja alapuolisen kohdetiedon tallentaminen päällekkäisille rakennuksille Vertikaalisuhdetiedon tallentaminen saman rakennuksen päällekkäisille osille Muu rakennus -luokan rakennusten luokitus tilarakennelmien käyttötarkoitusten mukaan Rakennukset, jotka ovat lentoesteitä, korkeuden kartoitus ja tallennus 2.1.6.1.2. Rakenteet Rakenteiden kohdeluokissa on 8 kohdeluokkaa, joille ei löydy lainkaan vastaavuutta MTK:sta. Nämä kohdeluokat ovat: Silta MaanalainenTila Sisäänkäynti Kaide Portaali Portaat

itos Selvitysraportin tiivistelmä 7 (24) 2.1.6.2. Liikenneverkko Luiska (KMTK:ssa ajoluiska, joka johtaa rakennuksen sisälle. Määritelmä ei vastaa MTK:n luiskan määritelmää,) Tunneli Näiden kohteiden geometrian kuvaamisen tason on niin yksityiskohtainen, ettei niitä ole tarkoituksenmukaista kerätä nykyisillä järjestelmillä. MTK:n portti voi olla portti tai aukko aidassa. KMTK:ssa portti on aina suljettava portti. MTK:n portille lisätään mahdollisuus tallentaa tieto onko portti suljettava. MTK:n portti on pistemäinen kohde. KMTK:n tarvitsema viivageometria voidaan muodostaa irrotuksen yhteydessä automaattisesti ottamalla viivan suunta aitageometriasta ja asettamalla viivalle vakiopituus. KMTK:ssa pato tallennetaan viivana silloin kun pato on virtauksen suuntaiselta leveydeltään alle 5m. Pato tallennetaan alueena kun se on virtauksen suuntaiselta leveydeltään vähintään 5m. MTK:aan lisätään uusi kohde aluemaisen padon tallennusta varten. Selvitysraportissa on kuvattu yksityiskohtaisesti eri rakenne-kohteisiin tehtävät muutokset: KMTK:n käyttötarkoitukset, jotka tulee kerätä täysin uusina kohteina. Tarkempi käyttötarkoitusluokittelu, joka tulee tehdä MTK:ssa olemassa oleville kohteille. Käyttötarkoitus, joka saadaan suoraan johdettua MTK:n kohteesta. Ominaisuustiedot, jotka käyttötarkoituksen lisäksi tulee lisätä kullekin MTK:n kohteelle. KMTK:n Liikennevekot-pienryhmä on vuoden 2017 aikana selvittänyt vaihtoehtoja, jonka mukaisena KMTK:n ja Digiroadin vastuujakoa ja toiminnallisuutta aletaan kehittää. Huhti-toukokuussa MML:n ja Liikenneviraston yhteispalavereissa tehtiin päätös, että tavoitteeksi asetetaan ns. yhden purkin malli, jossa KMTK korvaa nykyisen Digiroadin VVH-tietokannan ja ottaa vastuulleen sen toiminnallisuudet ja palvelut. Tämän vaihtoehdon toteuttaminen edellyttää kuitenkin tiestön ylläpitojärjestelmältä toiminnallisuutta, jota ei nykyisellä JAKOmtj-järjestelmällä kannata/pysty toteuttaa. Vaatimukset on esitetty luvun 3 Vn:ssä. Loppuvuoden 2017 aikana on selvitetty vaihtoehtoja, jotka kannattaa toteuttaa välivaiheen ratkaisuna ennen yhden purkin mallia. Joulukuun puolivälin 2017 käsityksen mukaan todennäköisin vaihtoehto (Kuva 3) on, että koontitietokantaympäristöön rakennetaan osa nykyisen VVH:n toiminnallisuudesta, mutta VVH:lle jää edelleen osa tehtävistä (osa

itos Selvitysraportin tiivistelmä 8 (24) täydentävän geometrian hallinnasta, SURAVAGE-tiestön hallinta sekä Inspire-palvelut). Tämän vaihtoehdon vaatimukset koontitietokannalle on esitetty luvussa 2.2.1. KMTK-Liikenne kohdemallin määrittely tiestön osalta tulee jatkumaan vuoden 2018 aikana. Se tulee määritellä siten, että siinä on mukana kaikki VVH:n toiminnallisuudessa ja palveluissa tarvittavat tiedot. MTK:n tietomalli voidaan pitää lähes nykyisellään vain pienin täydennyksin. Kuva 3. KMTK:n ja Digiroadin välivaiheen vastuut JAKOmtj:ää kehitetään siten, että MTK:n tiestön tietomallia muutetaan o Muutetaan Pinnan alla ominaisuus Pinnan alla 1, Pinnan alla 2, Pinnan alla 3 o Lisätään ominaisuus Tien (pienin) leveys ja sen tietolähde o Mahdollisesti lisätään pistekohde Kääntöpaikka o Mahdollisesti laajennetaan kevyen liikenteen väylien luokitusta Lisätään mahdollisuudet tuoda laajemmin ulkopuolisten organisaatioiden (ELYt, kunnat, Metsäkeskus) tiestötietoja siirtotiedostoina tai mahdollisesti rajapintapalveluna Muutetaan kevytväylien muodostamisohjeistusta siten, että osa nyt Digiroadissa täydentävänä geometriana hallittavista kevytväylistä lisätään MTK:aan Määritellään ja otetaan käyttöön KMTK-kohdemallin mukainen tiestön GML-siirtotiedoston skeema

itos Selvitysraportin tiivistelmä 9 (24) Lisätään MTK:aan mahdollisesti uusi taso Tiestön täydentävä geometria Suunnitelmatiestön tapaisesti Tieverkon kohdemallin ja prosessien määrittely jatkuu 2018 alussa. Rautateiden ja Vesiliikenneverkon kohdemallin ja prosessien määrittely alkaa 2018 alkupuolella. 2.1.6.3. Maasto Maaston kohteiden mallinnusta on tehty yhdessä SYKEen ja Suomen metsäkeskuksen kanssa. SYKEen kanssa on keskusteltu siitä, miten KMTK pysyisi tuottamaan lähtöaineistoa esim. valtakunnallisen CORINE- luokituksen muodostamiseen. Metsäkeskus puolestaan tuottaa aineistoa KMTK:n metsän tuottamiseen. KMTK-maasto teeman aluemaiset kohteet jakaantuvat neljään tasoon, jotka on toistaiseksi nimetty Maasto1, Maasto2, Kasvillisuus ja Taajama. Nämä tasot sisältävät siis ainoastaan aluekohteita. Maaston viiva- ja pistemaiset kohteet sisältyvät tasolle Maaston yksityiskohdat. Määriteltyjen topologiasääntöjen mukaan samalla tasolla olevat kohteet eivät saa KMTK:ssa mennä päällekkäin. Maasto-teeman sisältää kohteita MTK:n kohderyhmistä maasto1, maasto2, taajaan rakennetut alueet ja suojelukohteet. Maasto -teeman suurimmat muutokset nykyisen MTK:n kohderyhmiin Maasto1 ja Maasto2 vesistöön kuuluvien kohteiden siirtyminen Hydrologiateemaan sekä aluemaisen metsän tuominen kasvillisuus tasolle. Lisäksi olemassa olevia kohteita luokitellaan tarkemmin kuin mitä nykyisessä tietomallissa tehdään. Uusina ominaisuuksina tallennetaan Autoliikenne- ja Varastoalueille tieto niiden päällysteestä. Suolle ei enää tarvitse tallentaa tietoa metsäisyydestä, koska tieto on johdettavissa metsäalueista. Alueiden reunaviivoja ei KMTK:ssa mallinneta erillisinä kohteina, joten jakoa yksikäsitteisiin ja epämääräisiin alueenreunoihin ei enää ole. Maasto- teeman vaatimat muutokset JAKOmtj:ään Maasto1 ja Maasto2 Lisätään uusi tietokantaan uusi maasto1:n kohde Satama. Lisätään alaluokat Autoliikennealueelle, Niitylle, Urheilu- ja virkistysalueelle sekä Varastoalueelle. Lisätään päällystetieto Autoliikennealueelle ja Varastoalueelle.

itos Selvitysraportin tiivistelmä 10 (24) Mahdollisia uusia työkaluja helpottamaan Avoimen vesijätön reunojen sovittamista maastokuvionreunoihin. Kasvillisuus Lisätään tietokantaan uusi kohde metsä ja JAKOmtj:tä varten metsän reunaviiva. Metsälle lisätään uusi kohderyhmä (manifoldi). Taajama Lisätään tietokantaan uusi kohde Rakennettu alue ja JAKOmtj:tä varten rakennetun alueen reunaviiva. Rakennetulle alueelle uusi kohderyhmä (manifoldi). 2.1.6.4. Osoite 2.1.6.5. Hydrografia KMTK/PTA-Osoitetietojärjestelmä-projektin suunnitelmissa ei ole tarvetta Osoite-kohteiden käsittelylle nykyisessä JAKOmtj-tuotantojärjestelmässä. Hydrografia kohteiden kohdemallinnusta on tehty yhteistyönä KMTK:n Hydrografia-pienryhmän ja SYKEn kanssa vuoden 2017 aikana. Kohteiden määrittelyt perustuvat SYKEn tekemään järvien ja myöhemmin tehtävien merien ja virtavesien perusyksiköiden määrittämiseen ja niiden yksilöintiin. KMTK:n kohdemallinnuksessa Hydrografiset kohteet on erotettu omaksi teemakseen. Vuoden 2017 kesällä ja syksyllä JAKOmtj-sovelluksella tehdyissä koetöissä SYKEn määrittelemät järvien perusyksiköt pystyttiin muodostamaan MTK:n nykyisen kohdemallin mukaisista Maasto1:n järvi-kohteista. MTK:n kohdemallia ei näin ollen tarvinne muuttaa KMTK:n määritysten mukaiseksi, vaan muutokset voidaan tehdä nykyiseen teemajakoon. Joulukuun puolivälin 2017 käsityksen mukaan Hydrografisten kohteiden käsittelyprosessi SYKEn ja MML:n välillä on seuraava: 1. SYKE määrittelee nykyisten aineistojensa sekä MML:n tausta-aineistojen pohjalta järvien, merien ja virtavesialueiden perusyksiköt ja antaa niille perusyksikkötunnisteet sekä muut tarvittavat ominaisuustiedot 2. SYKE toimittaa perusyksikkötiedot MML:lle 3. MML vastaanottaa em. perusyksiköiden tiedot ja muuntaa ne sellaiseen muotoon, että ne voidaan ladata JAKOmtj-sovellukseen

itos Selvitysraportin tiivistelmä 11 (24) 2.1.6.6. Muut teemat 4. MML:n MARA-prosessi muuttaa MTK:n kohteiden geometrian SY- KEn määrittelemien perusyksiköiden mukaisiksi ja antaa niille perusyksikkötunnisteet sekä muut tarvittavat ominaisuustiedot 5. MTK:n muutetut hydrografiset kohteet irrotetaan KMTK-kohdemallin mukainen Hydrografia skeeman mukaisina GML-siirtotiedostoina 6. GML-siirtotiedostot ladataan KMTK koontitietokantaan 7. KMTK:n kohdemallin mukaiset Hydrografiset kohteet ovat SYKEn käytettävissä KMTK:n tuotteiden ja palveluiden kautta Uomaverkoston rooli SYKEn ja KMTK:n välillä on toistaiseksi määrittelemättä, joten sen käsittelyprosesseista ei vielä ole tarkempaa tietoa. Tarpeita sen tuomiseksi JAKOmtj-sovellukseen ei vielä voi määritellä, mutta koska Smallworld-järjestelmä on tarkoitettu erityisesti verkostomaisen tiedon ylläpitoon, voidaan uomaverkoston ylläpitoon liittyvä tietomalli ja toiminnallisuutta tarvittaessa rakentaa JAKOmtj-järjestelmään. JAKOmtj:ää kehitetään siten, että MTK:n Maasto1:n tietomallia muutetaan o Järvi, meri ja virtavesialueille lisätään ominaisuustietoihin perusyksikkö-id sekä muut tarvittavat ominaisuustiedot o Maastokuvion reunaviivoille lisätään ominaisuusarvo Samantyyppisten_vesialueiden_reunaviiva o Lisätään uudet kohteet Kanava, Sulkualue ja Vesiputous Lisätään mahdollisuus ladata SYKEn perusyksikkötiedot Lisätään tarvittavat vuorovaikutteiset sekä eräluontoiset työkalut perusyksiöiden käsittelemiseen Määritellään ja otetaan käyttöön KMTK-kohdemallin mukainen Hydrografisten kohteiden GML-siirtotiedoston skeema KMTK kohdemallin mukaista Saari kohdetta ei oteta MTK:aan, koska saarien hallinta on hyvin hankalaa niiden sisällä yleensä olevien muiden Maasto1-alueiden johdosta. Hydrografisten kohteiden kohdemallin ja prosessien määrittely jatkuu 2018 alussa. Seuraavien teemojen ja aineistojen KMTK-vaatimuksia ei selvitetty, koska KMTK kohdemallityö ei ole vielä alkanut Paikannimet Maankäyttö (toteutunut maankäyttö = maasto) Pistepilvet

itos Selvitysraportin tiivistelmä 12 (24) Ortokuvat Johtotiedot Suojelu- ja erityiskäyttöalueet (osa Maankäyttöpäätöksiä) Korkeussuhteet ja -mallit (uutena pintamalli) Kiintopisteet 2.1.7. CityGML Smallworld tietokannan geometriatietomalli ei tue 3D geometriatyyppejä, joten kohteiden lataaminen CityGML-muotoisista tiedostoista tai rajapinnasta ei ole välttämätöntä. Jos CityGML-muotoista tietoa jostain syystä kuitenkin pitää saada ladattua MTK:aan, voi tiedostot yrittää muuttaa MTK-GML-muotoisiksi 3DWin-ohjelmalla. KOTIMARA/sk-projektissa, jonka toimiaika oli 2011-2012, JAKOmtj-sovellukseen lisättiin mahdollisuuden tuottaa CityGML-skeeman LoD1-mallin mukaista rakennusaineistoa. 2.1.8. Linkitetyn tiedon hallinta Linkitetyn tiedon hallintaan liittyvät MML:n asiakkaille suunnatut palvelut; sisältöpalvelut, URI-palvelut sekä muutostietopalvelut, ovat koontitietokannan tarjoamia palveluita, eivät ylläpitojärjestelmän vaatimuksia. Sen sijaan joidenkin MTK:n kohteiden ylläpidossa voidaan hyödyntää olemassa olevaa linkitettyä tietoa. Tällaisia ovat VRK:n ylläpitämät rakennusten pysyvät tunnisteet sekä MML:n paikannimet. Selvityksen perusteella MTK:n rakennuksille voidaan pysyvä rakennustunnus johtaa automaattisesti yli puolille taajamien rakennuksista, mutta hajaasutusalueella kohdistuvuus on huomattavasti huonompi. Asuinrakennusten kohdistuvuus on selvästi parempi kuin muiden rakennusluokkien. Linkitettyä tietoa voidaan hyödyntää lisäämällä pysyvä rakennustunnus vastaavien MTK:n rakennusten ominaisuustietoihin tai hakea irrotuksen yhteydessä lennossa rakennustunnus sijaintiyhteyden perusteella. Linkittäminen onnistuu automaattisesti silloin, kun pysyvän rakennustunnuksen sijainti osuu aluemaisen MTK:n rakennuksen sisälle ja luokitus on yhteensopiva. Kattavan linkityksen MTK:n rakennusten ja RHR-rakennusten välillä edellyttää vuorovaikutteisten työkalujen kehittämistä ja erittäin suurta vuorovaikutteista työtä.

itos Selvitysraportin tiivistelmä 13 (24) Nykyisessä MTK:ssa nimi ei ole minkään maastokohteen ominaisuustietona (pl. Teiden nimet). Paikannimet ja niitä vastaavat karttanimet hallitaan Paikannimirekisterissä, jossa jokaisella paikalla on yksilöivä tunniste PNRpaikkaID. MTK:n kohteelle voidaan hakea nimi linkittämällä se Paikannimirekisteriin PNRpaikkaID:n avulla. Nimettyjen paikkojen lukumäärä Paikannimirekisterissä on noin 800 000. Näistä noin 212 000 on sellaisia, joille MTK:sta löytyy vastaava kohde. Paikannimirekisteriin PNRpaikkaID:n avulla linkittämällä voidaan Rautatieliikennepaikkojen, Vakavesien ja Koskien nimille saavuttaa yli 10% kattavuus, muut kohteet jäävät suurimmalta osalta nimeämättä. Linkittäminen onnistuu automaattisesti silloin, kun Paikannimirekisterikohteen sijainti osuu aluemaisen MTK:n kohteen sisälle ja luokitus on yhteensopiva. Viivamaisten ja pistemäisten kohteiden linkittämisessä voidaan käyttää bufferointia vastaavien kohteiden haussa. Linkitettyä tietoa voidaan hyödyntää lisäämällä PNRpaikkaID vastaavien MTK-kohteiden ominaisuustietoihin. Linkitystä voidaan täydentää vuorovaikutteisesti, kun sijaintiyhteyden perusteella tehty automaattiprosessi ei ole saanut yhteyttä aikaiseksi. Tämä edellyttää luonnollisesti linkitetyn tiedon ylläpidon rakentamista kahdensuuntaisesti MTK:n ja Paikannimirekisterin välille. Toinen vaihtoehto on hakea irrotuksen yhteydessä lennossa kohteille nimi Paikannimirekisteristä sijaintiyhteyden perusteella. Tällöin käytössä olisi aina ajantasainen tieto, mutta lopputulos olisi riippuvainen paikannimikohteen sijainnin oikeellisuudesta. 2.1.9. Siirtyminen TM35FIN-koordinaatistoon JAKOmtj-sovelluksessa käytetään nykyisin useita tasokoordinaatistoja: Tietokantakoordinaatisto KKJ/YKJ-pohjainen Karttakäyttöliittymä ETRS-TM35FIN Laskentakoordinaatisto ETRS-GKn 1º kaistoin Aineistojen irrotuksessa vektorituotteita varten voidaan tehdä koordinaatistomuunnoksia useisiin koordinaatistoihin. KMTK:n koontitietokannan koordinaatisto on ETRS-TM35FIN. Koontitietokannan ylläpito MTK:n vektorikohteilla sekä korkeusmalleilla tullaan tekemään GML-pohjaisten muutostiedostojen kautta, joihin tarvittavat tasokoordinaatistomuunnokset voidaan tehdä. Näin ollen JAKOmtj-sovelluksessa ei ole välttämätöntä siirtyä TM35FIN-koordinaatistoon, vaan nykyisten tasokoordinaatistojen pohjalta voidaan toimia jatkossakin.

itos Selvitysraportin tiivistelmä 14 (24) 2.1.10. Siirtyminen N2000-korkeusjärjestelmään 2.1.11. MTK:n tietojen siirto koontitietokantaan JAKOmtj:n ja MTK:n korkeusjärjestelmä on nykyisin N60. KM2-tuotannossa korkeudet lasketaan ensin N2000:ssa, mutta tallennettaessa MTK:aan ne muutetaan N60:een. Aineistojen irrotuksessa vektorikohteiden korkeusjärjestelmää ei voi valita, eli korkeudet ovat aina N60:ssa. Korkeusmallien siirrossa tiedostoon korkeusjärjestelmäksi voidaan valita N60 tai N2000. KMTK:n koontitietokannan korkeusjärjestelmä N2000. MTK:n korkeusjärjestelmän muuttaminen aidosti N2000:een on suuri ja aikaa vievä työ, ja aiheuttaisi katkoksen MARA-tuotantoon. N2000:een siirtyminen ehdotetaan tehtäväksi uudessa MML:n ylläpitojärjestelmässä, eli se kirjataan uuden järjestelmän vaatimuksiin. JAKOmtj:ään vektorikohteiden irrotukseen lisätään mahdollisuus valita korkeusjärjestelmäksi N2000. Muuttuneita kohteita voidaan irrottaa MTK:sta siten, että muutostietoihin tulee eläviä kohteita sekä historiakohteita, joiden alku- tai loppupäivä on halutulta aikaväliltä. Kohteissa itsessään ei ole tietoa siitä, ovatko ne uusia vai muuttuneita tai minkä muutoksen seurauksena ne ovat muuttuneet historiakohteiksi. Vastaanottavan järjestelmän on pystyttävä tulkitsemaan, mikä kohteissa on muuttunut ja miten niitä tulee käsitellä. Tämä MTK:n muutostietojen toimittamistapa MTK-GML-muodossa on käytössä tiestötietojen siirrossa Digiroadiin sekä kaikkien kohteiden osalta visualisointipalveluun. KMTK-Tietokanta/to-projektissa on toteutettu MTK:n muutostietojen tuonti koontitietokantaan visualisointipalvelun MTK-GML-siirtotiedostojen avulla, joten muutosten tulkitseminen on jo hallinnassa. 2.1.12. Kohteiden siirto koontitietokannasta MTK:aan MTK:n muutostietojen siirtoa kehitetään siten, että: Määritellään teemakohtaisesti GML-siirtotiedostojen skeemat KMTK-kohdemallien suhteen optimaalisiksi Määritellään sopivan kokoinen alue (karttalehti), jonka sisältä muuttuneet kohteet irrotetaan leikkaamatta alueen reunaan Rakennetaan irrotusympäristö JAKOerään siten, että sen suorituskyky on riittävä Rakennetaan tuontiputki KMTK:n Tallennuspalveluun hallitsemaan em. MTK:n muutostiedot

itos Selvitysraportin tiivistelmä 15 (24) KMTK:n hajautetun ylläpidon tavoitteena on, että kunnat voisivat ottaa vastuun oman alueensa tai sen osan maastotietojen ylläpidosta. KMTK:n tavoitteena on myös, että paikkatietojen päällekkäisestä keruusta halutaan päästä eroon. Tällöin on luonnollista, että MML:n ei tee oman aineistonsa ylläpitoa omilla prosesseillaan niillä alueilla, joista kunnat vastaavat. MTK tulee kuitenkin pitää kattavasti ajantasalla nykyisiä maastotietotuotteita varten. Maastotiedot, jotka kunnat ylläpitävät suoraan koontitietokantaan, tulee saada MTK:aan. JAKOmtj:ää kehitetään siten, että se pystyy hyödyntämään koontitietokannan muutostietopalvelua MTK:n päivittämiseen. Jotta ylläpito pystyttäisiin kohdistamaan oikeille alueille, tulee eri kuntien kanssa sovitut aluerajaukset mahdollisesti eri teemoille saada JAKOmtj:n käyttöön. 2.1.13. MTK:aa hyödyntävien järjestelmien muutokset Vaikka Maastotietokannan muutokset pyritään toteuttamaan siten, että nykyisten maastotietotuotteiden tuottaminen onnistuu jatkossakin, voi olla mahdollista, että joku muutos halutaan tai on pakko ottaa mukaan MTK:n tuotteisiin. MTK:aa hyödyntäviä järjestelmiä tai tuotteita ovat Visualisointipalvelu Avoimien aineistojen tiedostopalvelu Piekka 3D-Win JAKOkii Muutosten tekeminen näihin järjestelmiin tulee järjestää toteutusprojektin yhteydessä ennen MTK:n muutosten käyttöönottoa. 2.2. Vaatimukset KMTK:n koontitietokantaympäristölle 2.2.1. Koontitietokanta ja Digiroad Osa KMTK:n vaatimuksista, jotka toteutetaan nykyiseen tuotantojärjestelmään, edellyttävät myös KMTK:n koontitietokantaympäristön kehittämistä. Kuten luvussa 2.1.6.2. kerrottaan, osa nykyisen VVH:n toiminnallisuudesta on tarkoitus siirtää KMTK:n koontitietokannan vastuulle. Tämä edellyttää koontitietokannalta seuraavaa toiminnallisuutta: Kohdemalli on määritelty siten, että siinä on mukana kaikki VVH:n toiminnallisuudessa ja palveluissa tarvittavat tiedot.

itos Selvitysraportin tiivistelmä 16 (24) Voimassa olevan linkkiverkon ylläpitäminen MTK:sta tulevien muutostietojen avulla o MTK:sta tullutta geometriaa (tai ominaisuustietoja) ei saa editoida millään tavalla o Muutostiedot luetaan kerran päivässä automaattisesti KMTK-ID = Linkki-ID o Nykyisen Digiroadin ylläpitämän Linkki-ID:n tilalle KMTK-ID Linkin elinkaaren ylläpito o Linkillä elinkaaren määrittelyt johdetaan nykyisen Dgiroadin VVH:n elinkaarisäännöistä Muutostaulun ylläpito o Kertoo geometrialtaan muuttuneen linkin uuden ja vanhan tilanteen vastaavuudet (linkki id, m-arvot) o Yhdestä muutoksesta voi generoitua monta riviä muutostauluun (esim. linkin katkaisu -> minimissään kaksi riviä) o Tunnistettuja muutostyyppejä on yli 10, esim. linkin pidennys tai lyhennys, linkkien yhdistäminen, linkkien katkaisu, uusi, poistunut jne. mutta osa jää kategoriaan tuntematon o Muutokset tunnistetaan MTK-ID:n ja/tai spatiaalisen päättelyn avulla MTK-importin yhteydessä automaattisesti Linkkien historian ylläpito o Linkin kaikki vanhat versiot tallennetaan ominaisuustietoineen historiatauluun automaattisesti o Tieosoiteverkkoa pitää pystyä katsomaan minkä tahansa ajanhetken linkkiverkolta o OTH:ssa voidaan visualisoida nykyisestä geometriasta irti olevat viivamaiset ominaisuustiedot historialinkkien avulla Linkin pituuden määrittäminen o Tarvitaan Digiroadin OTH:n lineaarista referointia varten Rajapintapalvelut ~24/7 o Hyödyntävät järjestelmät käyttävät tietoja rajapinnasta, eikä VVH:n tietoja kopioida mihinkään toiseen järjestelmään o Dataa voidaan hakea rajapinnoista koordinaateilla (bounding box = kartan raahaaminen), ominaisuustiedoilla (esim. valtion tielinkit) ja päivämäärillä (historia) o Voimassa oleva linkkiverkko

itos Selvitysraportin tiivistelmä 17 (24) o Muutosrajapinta o Historiarajapinta KMTK:n muutostietopalvelun toiminnallisuuden rakentaminen sellaiseksi, että VVH-tietokannan teiden ylläpito on sujuvaa Lisävaatimuksia KMTK:lle (VVH:n SURAVAGE-ylläpitoa varten) o Anna seuraava vapaa KMTK-ID o Tien hallinta latauksessa, jolla on jo KMTK-ID 3. Vaatimuksista uudelle tuotantojärjestelmälle 3.1. Järjestelmän yleinen toiminnallisuus Tässä luvussa on määritelty KMTK:n vaatimukset, joita ei pystytä toteuttamaan nykyiseen tuotantojärjestelmään tai muuten kokemusperäisesti ehdotetaan toteutettavaksi tulevaan KMTK-tuotantojärjestelmään. V1. Käyttäjien oikeuksien hallinta ja tuki hajautetulle tiedontuottamiselle Maastotietokannan ylläpitoa tehdään nykyisin hajautetusti MML:n lähes 20 palvelupisteessä. Lisäksi Kotimaisten kielten keskus (KOTUS) tekee nimistönhuoltoa Nimistörekisteriin. Em. ylläpitäjien lisäksi MTK:n kohteiden ylläpito on mahdollistettava myös ulkopuolisille organisaatioille, kuten ainakin seuraaville: Kunnat Rakennukset ja rakenteet, tiestö Liikennevirasto Tiestö ELYt Tiestö SYKE Uomaverkosto Käyttäjien ja käyttäjäryhmien oikeuksia on pystyttävä hallitsemaan siten, että käyttäjillä on pääsy vain kullekin sallittujen tietojen ylläpitoon. V2. Järjestelmä mahdollistaa, että useampi operaattori voi samanaikaisesti muokata tietokannan kohteita Maastotietokannan ylläpitäjiä, jotka rekisteröivät muutoksia tietokantaan, oli MML:n MARA-tuotannossa vuonna 2016 yli 160. Yhtäaikaisten käyttäjien määrä tulee jatkossa lisääntymään huomattavasti, jos MML:n ulkopuolisille organisaatioille mahdollistetaan pääsy muokkaamaan MTK:n kohteita.

itos Selvitysraportin tiivistelmä 18 (24) V3. Järjestelmä tukee pitkän transaktion ja konfliktien hallintaa Maastotietojen ylläpidossa lähes aina kohteiden muutokset pitää tehdä siten, että ylläpidettävän kohteen lisäksi muutokset kannattaa samalla kertaa tehdä topologisessa tai sijainnillisessa yhteydessä oleviin naapurikohteisiin, eli muutokset kohdistuvat lähialueeseen. Lisäksi maastokohteet ovat usein luonteeltaan sellaisia, että ne ulottuvat kauas käsiteltävältä alueelta. Muutosten tekeminen alueen koosta ja ylläpidettävien kohteiden määrästä riippuen voi kestää päiviä tai jopa viikkoja. Kyseessä on pitkän transaktion tapahtuma, jonka hallintaa ylläpitojärjestelmän tulee tukea. Työsuunnittelulla voidaan yrittää järjestellä ylläpitotöitä siten, että eri henkilöiden työt eivät kohdistu samalle alueelle. Kuitenkin aina on olemassa vaara, että muutokset kohdistuvat samoihin kohteisiin. Ylläpitojärjestelmän on tuettava konfliktien hallintaa siten, että järjestelmä tunnistaa konfliktissa olevat kohteet ja pystyy automaattisesti tai käyttäjän avustuksella ratkaisemaan konfliktit. V4. Järjestelmä mahdollistaa riittävän suorituskyvyn hajautetulle ylläpitoympäristölle Maastotietokannan ylläpitoa tehdään nykyisin MML:n lähes 20 palvelupisteessä ja jatkossa myös muiden ulkopuolisten organisaatioiden toimesta. Ylläpitojärjestelmän tulee mahdollistaa Maastotietokannan kohteiden sekä oheisaineistojen käsittelyn riittävän suorituskyvyn hajautetulla puskuroinnilla tai muulla sopivalla teknologialla. V5. Ylläpitotietokannan tietojen on oltava siirrettävissä nopeasti tietopalvelutietokantaan ilman siirtotiedostojen käyttöä Ylläpitojärjestelmässä ylläpidetyt maastotiedot tulee pystyä siirtämään tietopalvelutietokantaan (koontitietokantaan) sujuvasti siten, että edellisenä päivänä tehdyt muutokset ovat saatavissa tietopalvelun kautta seuraavana päivänä. Parhaiten tämä olisi toteutettavissa tietokantojen replikoinnilla, eli ylläpitotietokannasta kopioitaisiin automaattisesti vain muuttuneet tiedot tietopalvelutietokantaan. V6. Järjestelmässä kohteita tulee voida päivittää yksittäin tai suuremmissa erissä Ylläpitojärjestelmässä tulee olla mahdollisuus ylläpitää kaikkia kohteita vuorovaikutteisesti sekä myös tuoda ylläpitoaineistoa eräajotyyppisesti siten, että tietojen laatua voidaan validoida automaattisesti. Tarvittaessa myös manuaalinen aineistojen tuonti ja sovittaminen tulee olla mahdollista. Päivitettäviin kohteisiin tulee voida viitata pysyvän tunnuksen avulla, mutta päivityksen tekeminen ei saa edellyttää pysyvän tunnuksen käyttöä.

itos Selvitysraportin tiivistelmä 19 (24) V7. CityGML:n hallinta Ylläpitojärjestelmän tulee hallita CityGML-muotoisen tiedon tuonti. 3D-tietoa tässä muodossa voidaan saada kunnilta, konsulteilta ja myös MML:n tulevasta 3D-kohteiden mallinnusjärjestelmästä. Ylläpitojärjestelmän tulee hallita myös 3D-kohteiden output CityGML-muodossa. V8. Linkitetyn tiedon hallinta Linkitetyn tiedon hallintaan liittyvät MML:n asiakkaille suunnatut palvelut; sisältöpalvelut, URI-palvelut sekä muutostietopalvelut, ovat koontitietokannan tarjoamia palveluita, eivät ylläpitojärjestelmän vaatimuksia. MTK:n kohteet voivat hyödyntää olemassa olevaa linkitettyä tietoa. Tällaisia ovat VRK:n ylläpitämät rakennusten pysyvät tunnisteet, MML:n paikannimet sekä mahdollisesti kuntienaineistojen pysyvät tunnisteet. V9. Tuotannon suunnittelun- ja seurannan hallinta Nykyiseen JAKOmtj-sovellukseen sisältyy Maastotietojen suunnittelu ja seuranta-osasovellus MASU. MASUlla voi suunnitella tuotantosuunnitelmia, seurata niiden ja töiden toteutumista sekä analysoida sekä Maastotietokannan että suunnitelmien tietoja monin eri tavoin. MASUsta viedään MARAtuotannon toteumatietoja kuukausittain JOHIin csv-muotoisissa siirtotiedostoissa. Vastaavanlainen MARA-tuotannon suunnittelu- ja seurantajärjestelmä tarvitaan myös uuteen ylläpitojärjestelmään. V10. Tietokannan korkeusjärjestelmäksi N2000 Tietokannan korkeusjärjestelmäksi tulee muuttaa N2000. Se kannattaa tehdä seuraavasti, jotta paras tarkkuus sekä aineistojen yhteensopivuus saavutetaan: KM2 lasketaan laserpisteistä uudelleen ja tallennetaan N2000:ssa tietokantaan ETRS-TM35FIN -tasokoordinaatiston mukaisena gridinä Järvien pinnankorkeudet muutetaan N2000:een o Isojen järvien korkeus on sovitettava ääripäiden korkeuksien suhteen, pienten N60->N2000-muunnoksella Johdetaan N2000-korkeudet tietokannan kohteille

itos Selvitysraportin tiivistelmä 20 (24) o Järvien rantaviivoille järvialueiden pinnankorkeuksista o Muille kohteille KM2:sta Uudet N2000-korkeuskäyrät lasketaan laserpisteistä/km2:sta, kun koko Suomen kattavuus on saavutettu V11. Nykyisen Digiroadin VVH-toiminnallisuuden hallinta Kuten luvussa 2.1.6.2. kerrottaan, on MML:n ja Digiroadin vastuunjaon pidemmän tähtäimen tavoitteena ns. Yhden purkin malli, jossa Digiroadin nykyinen VVH-tietokanta poistuisi käytöstä ja kaikki sen toiminnallisuudet ja palvelut siirrettäisiin KMTK-koontitietokannan vastuulle (Kuva 4). Kuva 4. KMTK:n ja Digiroadin tavoitetila VVH:n nykyiset toiminnallisuudet ja palvelut, jotka umtk/koontitietokantajärjestelmään tulee toteuttaa: Voimassa olevan linkkiverkon ylläpitäminen (useita organisaatioita) Digitointisuunnan kääntäminen (etelästä pohjoiseen) Linkin pituuden määrittäminen Linkin elinkaaren ylläpito Muutostaulun ylläpito Linkkien historian ylläpito Suravage-geometrian ja täydentävän geometrian ylläpito

itos Selvitysraportin tiivistelmä 21 (24) Automaattinen Inspire-solmujen ylläpito Rajapinnat ~24/7 o Hyödyntävät järjestelmät käyttävät tietoja rajapinnasta, eikä VVH:n tietoja kopioida mihinkään toiseen järjestelmään o Dataa voidaan hakea rajapinnoista koordinaateilla (bounding box = kartan raahaaminen), ominaisuustiedoilla (esim. valtion tielinkit) ja päivämäärillä (historia) o Voimassa oleva linkkiverkko o Muutosrajapinta o Historiarajapinta o Suravage o Täydentävä geometria o Inspire-solmut 3.2. Järjestelmän tietojen hallinta V12. KMTK-kohdemallien mukaisten tietojen hallinta Tietokannan tietomallit sekä ylläpitotyömenetelmät on pystyttävä kehittämään sellaisiksi, että ne tukevat KMTK-kohdemallimääritysten mukaisia kohteita ja niiden ylläpitoprosesseja. V13. Järjestelmä tukee tarvittavia geometriatyyppejä Järjestelmän tulee hallita KMTK-kohdemallimääritysten mukaisten geometriatyyppien (2D, 2.5D, 3D) ylläpitoa. V14. 2.5D/3D -kohteiden muokkaus ja luominen tulee onnistua (ESPA Systems -) stereotyöaseman digitointiympäristön avulla 2.5D-kohteiden ylläpito tulee olla mahdollista stereomallien avulla stereotyöasemassa nykyisen JAKOmtj-sovelluksen tapaisesti. Myös 3D-tietomallin mukaisten kohteiden hallinta tulee olla mahdollista. Koska MML:lla on nykyisin yli 100 stereotyöasemaa, jossa käytetään ESPA Systemsin ohjelmistoja, tulisi ylläpitojärjestelmä olla integroitavissa tähän ympäristöön.

itos Selvitysraportin tiivistelmä 22 (24) V15. Järjestelmässä on hallittava kohteiden välinen topologia siten, että aineisto säilyy topologialtaan eheänä, topologian hallinnan pitää onnistua myös 2,5D- ja 3D-kohteille Maastotietokannan kohteiden välillä on topologisia yhteyksiä sekä eri teemojen sisällä että eri teemojen välillä. Esimerkiksi tiet edellyttävät verkostomaisen topologian hallinnan linkkien ja solmujen avulla, maastoalueilla voi olla yhteinen reunaviiva ja ne ovat toisiaan poissulkevia ja rakennukset eivät yleensä voi sijaita vesialueiden sisällä. Kohteiden välisen topologian hallinta voi tapahtua ylläpitovälineessä, mutta parempi olisi, että itse tietokanta sisältää topologian hallinnan. Koska KMTK:n kohteiden geometriat voivat olla 2D, 2.5D ja 3D, tulee topologiahallinnan kattaa kaikki em. geometriatyypit. V16. Järjestelmässä kohteille tulee voida antaa pysyvät yksilöivät tunnukset, joita hallitaan kohteiden elinkaarisääntöjen mukaisesti KMTK:n kohteiden pysyvien yksilöivien tunnisteiden hallinta tulee perustua JHS 193 Paikkatiedon yksilöivät tunnukset sekä KMTK-MAASTOID/mä - Määrittelyraportin suosituksiin. Kohteiden elinkaarisääntöjä on pystyttävä tarpeen mukaan lisäämään ja päivittämään. V17. Kohteiden historiatietoja on hallittava (historiakohteiden linkitys) KMTK:n kohteiden ylläpidossa kohteen aikaisemmat versiot tulee säilyttää. Jos kohde poistetaan, ei ilmentymäkohde poistu, vaan se saa poistamispäivämäärän ja siirtyy historiatiedoksi. Kohteiden historiatiedot tulee linkittää toisiinsa siten, että historiakohteeksi muuttunut kohde tietää, että siitä on tullut toinen kohde. Lisäksi siten, että nykykohde tietää, jos se on ollut aiemmin joku historiakohteeksi muuttunut kohde. V18. Järjestelmässä on oltava mahdollisuus tallentaa versioita siten, että vanhoja tallennettuja versioita voidaan katsella ja niihin voidaan tarvittaessa palata Kohdekohtaisten historiatietojen hallinnan lisäksi koko tietokannasta tulee hallita versioita siten, että niihin voidaan tarvittaessa palata. V19. Järjestelmän on tuettava (10m ja) 2m korkeusmallien ylläpitoa

itos Selvitysraportin tiivistelmä 23 (24) KMTK:n rakennettua sekä maastoa kuvaavien kohteiden lisäksi myös korkeusmallit ja pistepilvet kuuluvat ylläpidettäviin teemoihin. Järjestelmän on tuettava KM2:n ylläpitoa siten, että kokonaisprosessiin kuuluvat Terrasolid sekä ESPA Engine on integroitu siihen. KM10 erillisestä ylläpidosta voitaneen luopua ja jatkossa KM10 on KM2:sta yleistettävä tuote. V20. Järjestelmän on tuettava 10m ja 2m korkeusmallien hyödyntämistä KM2 on MML:n korkeustietojen originaali, johon kaikki korkeustietojen hallinta tulee perustaa. KMTK:n 2.5D-kohteiden geometrialle ajetaan korkeudet joko KM2:sta tai sen puuttuessa KM10:stä. Järjestelmässä tulee olla mahdollisuudet tähän aina silloin, kun kohteiden geometriaa on muutettu tai kun korkeusmallia on päivitetty. V21. Tietokannan tietomallien on oltava muokattavissa mahdollisimman joustavasti KMTK:n kohdemallien ensimmäiset versiot julkaistaneen vuoden 2018 alussa. Kohdemalleihin tulee todennäköisesti muutoksia ja täydennyksiä tämän jälkeen vielä useastikin. KMTK tietokannan tietomalleja on pystyttävä päivittämään kohdemallien muutosten jälkeen ja aiemmat versiot tietomallista on oltava hallittavissa. V22. Suunnitelmatietoja on hallittava Kohdekohtaisten historiatietojen hallinnan lisäksi myös KMTK:aan joskus tulevien kohteiden, eli suunnitelmatietojen hallinnan on oltava mahdollista. Tarkemmat määrittelyt suunnitelmatietoihin liittyvistä tarpeista voidaan tehdä jatkossa tapauskohtaisesti. V23. Pistepilven hallinta ja mahdollisuus tuottaa siitä KMTK-tietomallin mukaista tietoa Laserkeilaustuotannossa tehtävät pistepilvituotteet perustuvat nykyisin pitkälti Terrasolid-ohjelmistolla ja ESPA Enginellä tehtäviin työvaiheisiin. KM2 tuotanto on perustunut interaktiivisesti luokitellun pistepilven hyödyntämiseen. Laserkeilaustuotanto tulee jatkossa muuttumaan suuresti Kansallisen laserkeilausohjelman käynnistymisen myötä. Pistepilvituotteisiin tulee suurempia pistetiheyksiä, jotka taas mahdollistavat uusia mahdollisuuksia mm. mallintaa 3D-kohteita.

itos Selvitysraportin tiivistelmä 24 (24) Ylläpitojärjestelmässä tulee olla mahdollisuus hyödyntää tulevia pistepilviaineistoja jatkossa tarkemmin määriteltävillä tavoilla. 3.3. Muita vaatimuksia V24. Tietokannasta on voitava pitää yllä erikseen tuotanto- ja testi/kehitys/koulutusympäristöt Ylläpitojärjestelmän kehittämisessä kannattaa noudattaa DevOps-toimintamallia, jossa ohjelmistojen rakentaminen, testaaminen ja julkaisu voi tapahtua nopeasti, usein ja luotettavasti. Tämän edellytyksenä on, että tietokannasta ja koko ylläpitosovelluksesta pidetään yllä erilliset kehitys-, testaus-, koulutus- ja tuotantoympäristöt. 4. Ehdotuksia ja suosituksia Tämä selvitysraportti on kirjoitettu niiden tietojen pohjalta, jotka KMTK:n määrittelyistä oli käytettävissä joulukuun puolivälissä 2017. Koska erityisesti kohdemallien ja tarkempien ylläpitoprosessien määrittelyt olivat vielä kesken, voi niiden tarkentuminen muuttaa lähtökohtia, jotka tämän selvitystyön pohjana olivat. Toteutusprojektien käynnistämisen yhteydessä ja toteuttamisen aikana määrittelyjen ajanmukaisuus tulee tarkastaa.