KONFLIKTIEN HALLINTA JAKO/MAASTOTIETOJÄRJESTELMÄSSÄ

KONFLIKTIEN HALLINTA JAKO/MAASTOTIETOJÄRJESTELMÄSSÄ Teknillisen korkeakoulun maanmittausosastolla tehty diplomityö Helsinki, toukokuu 2004 Mervi Saario tekniikan ylioppilas Valvoja: Prof. Kirsi Virrantaus Ohjaaja: DI Timo Räsänen

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ Tekijä: Mervi Saario Työn nimi: Konfliktien hallinta JAKO/Maastotietojärjestelmässä Päivämäärä: 21.05.2004 Sivumäärä: 73 Osasto: Maanmittausosasto Professuuri: Maa-123. Kartografia ja geoinformatiikka Työn valvoja: Työn ohjaaja: Prof. Kirsi Virrantaus DI Timo Räsänen Tämän diplomityöntyön tarkoituksena on selvittää, miten konflikteja hallitaan Maanmittauslaitoksen (MML) JAKO/Maastotietojärjestelmässä (JAKO/MTJ). Uuden JAKO/MTJ:n myötä vanha 1:10 000 karttalehtijakoon perustuva maastotietokanta siirrettiin Smallworld:n spatiaalisesti jatkuvaan versiohallittuun VMDS tietokantaan (Version Managed DataStore). Versiohallinta mahdollistaa useamman käyttäjän samanaikaisen työskentelyn tietokannassa ilman, että heidän tarvitsee lukita tarvitsemiaan tietoja. Samalla versionhallinta ja jatkuva tietokanta kuitenkin mahdollistavat saman kohteen samanaikaisen muokkaamisen eri vaihtoehdoissa. Jos samaa kohdetta on muokattu tietokannan eri vaihtoehdoissa, havaitaan näiden vaihtoehtojen tietojen yhdistämisessä konflikti. Maastotietokannan prosessit ja kohteiden topologiset yhteydet aikaansaavat sen, ettei konfliktien hallinta Smallworld:n vakioratkaisuilla onnistu tyydyttävästi. Konfliktien leviäminen topologian kautta ja ratkaisuihin käytettävän ajan rajallisuus ovat pakottaneet käyttäjät konfliktien joukkoratkaisuihin. Nämä joukkoratkaisut saavat joskus aikaan sen, ettei tietokanta enää ole siinä tilassa kuin sen pitäisi konfliktien ratkaisun jälkeen olla. JAKO/MTJ:ssä konfliktien ratkaisua on kehitetty eteenpäin niin, että kaikki konfliktit ratkaistaan automaattisesti muutosten tuonnin yhteydessä. Jottei menettäisi muiden käyttäjien tietokantaan tekemiä muutoksia, automaattinen korvaaminen tapahtuu aina kohteiden isäversioilla. Jos ei voida olla täysin varmoja siitä, että isäversio on oikein, automaattisen ratkaisemisen yhteydessä konfliktikohteen lapsiversiosta luodaan sovitettava kohde. Sovitettava kohde on muuten samanlainen kuin lapsikohde, mutta sen ei-topologinen geometria on nk. epäselvässä geometriakentässä. Muutosten tuonnin jälkeen käyttäjä käy läpi kaikki sovitettavat kohteet ja sovittaa ne. Muodostamalla sovitettavia kohteita säilytetään tieto siitä, mitkä kohteet olivat konfliktissa ja millaisia ne olivat ennen muutosten tuontia ja sen jälkeen. Käyttäjä voi nyt vapaasti muokata kohteita saadakseen tietokannan siihen tilaan, missä sen tulisi olla konfliktien ratkaisun jälkeen. Avainsanat: Maastotietojärjestelmä, konflikti, versio, vaihtoehto, topologia Kieli: suomi

HELSINKI UNIVERSITY OF TECHNOLOGY ABSRACT OF THE MASTER S THESIS Author: Mervi Saario Name of the thesis: Conflict management in JAKO/Topographic Data System Date: 21.05.2004 Number of pages: 73 Department: Department of Surveying Professorship: Maa-123. Cartography and Geoinformatics Supervisor: Instructor: Kirsi Virrantaus, Professor Timo Räsänen, M. Sc. (Eng.) This Master s Thesis discusses the development of conflict management in JAKO/Topographic Data System (JAKO/TDS) of the National Land Survey of Finland (NLS). With the new JAKO/TDS the old Topographic database based on the 1:10 000 map sheet division was replaced with the Smallworld s seamless Version Managed DataStore (VMDS). The VMDS supports multiple alternatives that allow several users to make changes concurrently to the database without the requirement to lock the data before it can be changed. At the same time, the seamless database and version management make it possible to update the same record in different alternatives. If the same record is updated in different alternatives, a conflict is detected when these alternatives are combined. Due to the nature of working processes and topological connections of the objects in JAKO/TDS, the conflict resolution with standard tools of Smallworld was found unsatisfied. The conflict propagation through topology and the time issue have been forced users to use large group replacement. Sometimes these group replacements have caused a situation where the database has not been in the state it should have been. In JAKO/TDS the conflict resolution has been developed further so that all the conflicts are resolved automatically during the merge. In order not to lose information about changes that other users have made, all the replacements are made by parent versions of the objects. During the automatic resolution an object to be resolved is created from the child version of the object whenever it is uncertain that the parent version of the object is the right one. The object to be resolved is a non-topological copy of the child version. After the merge operation the user goes though all these new objects to be resolved and manages them. With the objects to be resolved users maintain the knowledge of the objects that have been in conflict and what they were like before and after the merge. The users can now edit objects in order to get the database to the state it should be after the conflict resolution. Keywords: Topographic Data System, conflict, version, alternative, topology Language: Finnish

4 ALKUSANAT Tämä diplomityö on tehty Maanmittauslaitoksen Kehittämiskeskuksessa. Työn tavoitteena on kuvat JAKO/Maastotietojärjestelmän konfliktien hallinnan periaatteita. Kiitän kaikkia työtovereitani kehittämiskeskuksessa siitä, että he eivät antaneet tämän työn unohtua työpöydälleni vaan tarpeen tullen potkivat minua eteenpäin. Suurin kiitos kaikista kuuluu kuitenkin ohjaajalleni Timo Räsäselle, joka jaksoi kerta toisensa jälkeen lukea ja kommentoida työtäni, kunnes se sai lopullisen muotonsa. Lopuksi kiitän vielä professori Kirsi Virrantausta työni valvomisesta ja ulkopuolisen näkökulman tuomisesta työhöni. Helsingissä, toukokuussa 2004 Mervi Saario

5 SISÄLLYS TIIVISTELMÄ...2 ABSTRACT...3 ALKUSANAT...4 SISÄLLYS...5 LYHENTEIDEN JA TERMIEN SELITYKSET...9 Lyhenteet...9 Termit...10 1 JOHDANTO...12 1.1 Taustaa...12 1.2 Työn tavoite...13 1.3 Työn sisältö...13 2 JAKO/MAASTOTIETOJÄRJESTELMÄ...14 2.1 Yleistä...14 2.2 Maastotietokanta...14 2.2.1 Kohderyhmät...15 2.2.2 Kohteet...16 2.3 Ympäristö...16 2.4 Prosessit...17 2.4.1 Perusparannus...17 2.4.2 Määrävälein tehtävä ajantasaistus...19 2.4.3 Jatkuva ajantasaistus...19 2.4.4 Ylä-Lapin tiedonkeruu...20 2.5 Ajantasaistusrakenne...20 3 TOPOLOGIA...22 3.1 JAKO/Maastotietokannan geometriatyypit...22 3.2 Topologinen malli...22 3.3 Topologia JAKO/Maastotietojärjestelmässä...26 3.3.1 Topologiatasot...29 3.3.2 Topologiasäännöt JAKO/Maastotietojärjestelmässä...30

6 4 TÖIDEN ORGANISOINTI...31 4.1 JAKO/Maastotietojärjestelmän ajantasaistusrakenne...31 4.2 Tuotantosuunnitelmat ja työt...31 4.3 Työalue...32 4.3.1 Työalueen laajeneminen...35 4.3.2 Konfliktiriski...36 4.4 Työskentelyn organisointi...37 4.4.1 Työalueiden seuranta...38 5 TIETOKANNAN VERSIOIDEN HALLINTA...40 5.1 Yleistä...40 5.1.1 Tietojen lukitseminen...41 5.1.2 Versionhallinta...41 5.1.2.1 Vaihtoehdot...42 5.1.2.2 Versiot...43 5.1.3 Vaihtoehtojen tietojen yhdistäminen...44 5.1.4 Konfliktit...46 6 KONFLIKTIEN RATKAISEMINEN...50 6.1 Konflikti...50 6.2 Konfliktin leviäminen topologian kautta...51 6.3 Smallworld:n konfliktien ratkaisu...52 6.3.1 Konflikti -ikkuna...53 6.3.2 Ongelmat...55 6.4 Konfliktien ratkaiseminen JAKO/Maastotietojärjestelmässä...57 6.4.1 Automaattinen ratkaiseminen...58 6.4.2 Sovitettavat kohteet...58 6.4.2.1 Milloin luodaan sovitettava kohde?...59 6.4.2.2 Sovittaminen...60 6.4.3 Ongelmat...62 6.4.3.1 Sovitettavien lukumäärä...62 6.4.3.2 Sovittaminen kohde kerrallaan...63

7 7 JATKOKEHITTÄMINEN...65 7.1 Vahvempi versio...65 7.2 Konfliktien leviämisen pysäyttäminen...66 7.3 PAKANA...67 8 YHTEENVETO...69 LÄHTEET...71 LIITTEET LIITE 1: Maastotietokanta tilanne 31.12.2003. (MML 2004b) LIITE 2: Korkeustietojen perusparannus. (JAKO/MTJ ohje 2004a) LIITE 3: Maastotietojen perusparannus. (JAKO/MTJ ohje 2004b) LIITE 4: Maastotietojen määräaikainen ajantasaistus. (JAKO/MTJ ohje 2004c)

8 KUVAT Kuva 1. ESPA- stereotyöasema. ( Saarikoski 1999b)...17 Kuva 2. JAKO/Maastotietojärjestelmän ajantasaistusrakenne... (JAKO/MTJ-ohje 2001)...21 Kuva 3. Topologinen malli (Aronoff 1991, muokattu)...24 Kuva 4. Linkkien pisteiden koordinaatit. (Aronoff 1991, muokattu)...25 Kuva 5. Topologinen malli Smallworld 3:ssa. (Smallworld 2003, muokattu)...27 Kuva 6. Sähköverkoston linkit ja solmut....28 Kuva 7. Rakennusten linkit ja solmut....28 Kuva 8. Työalue = Karttalehtien alue + 30m...33 Kuva 9. Työalue ja puskurikarttalehdet....34 Kuva 10. Työalueen laajeneminen...35 Kuva 11. Töiden ja tuotantosuunnitelmien sijoittaminen toisiinsa nähden....38 Kuva 12. Smallworld:n tietokannan versionhallinta. (Smallworld 2003)...42 Kuva 13. Esimerkki tietokantaan vahvistamisista työpäivän aikana....44 Kuva 14. Isä- ja lapsivaihtoehtojen tietojen yhdistämisen vaiheet....45 Kuva 15. Kahden alivaihtoehdon muutosten yhdistäminen...46 Kuva 16. Vaihtoehtojen yhdistämisessä konflikti...47 Kuva 17. Kohteiden attribuutit, joiden muutos ei aiheuta konfliktia.... (Räsänen 2001)... 51 Kuva 18. Konflikti ikkuna....53 Kuva 19. Lisätietoja -ikkuna...55 Kuva 20. Sovitettavien kohteiden sovittamistyökalu...61 Kuva 21. Sovitettavia ja nykykohteita....64 Kuva 22. Kartografisten tuotteiden tuotantoympäristö. (PAKANA 2003)...68

9 LYHENTEIDEN JA TERMIEN SELITYKSET Lyhenteet ESPA GIS GPS JAKOMAA JAKO/KII JAKO/MTJ Maagis/MTJ MASU MML MMT MTJ MTK NKRK TOP TUSU VMDS ESPA -stereotyöasema, Espa Systems Oy:n valmistama digitaalinen stereokartoitusohjelmisto (EspaCity), osa JAKO/Maastotietojärjestelmää. Geographical Information System, paikkatietojärjestelmä. Global Positioning System, satelliittipaikannusjärjestelmä. Maanmittauslaitoksessa JAKO/Maastotietojärjestelmän kehittämisestä vastannut projekti. JAKO/Kiinteistötietojärjestelmä. JAKO/Maastotietojärjestelmä. Maanmittauslaitoksessa vuonna 2000 käyttöönotettu uusi maastotietojärjestelmä maastotietojen keruuseen, ajantasaistukseen ja varastointiin. Maagis/Maastotietojärjestelmä. Poistumassa oleva vanha maastotietojärjestelmä, jota käytetään toistaiseksi vielä maastokarttajulkaisujen tuottamiseen. Maastotietojen suunnittelu- ja seurantajärjestelmä. Maanmittauslaitos. Maanmittaustoimisto. Maastotietojärjestelmä. Maastotietokanta. Numeerinen kiinteistörekisterikartta. Maanmittauslaitoksen ylläpitämä karttatietokanta kiinteistöjen rajoista. Tietokannan päävaihtoehto, JAKO/MTJ:ssä rekisteri. Tuotantosuunnitelma. Version Managed DataStore. Smallworld:n versiohallittu relaatiotietokanta.

10 Termit Jatkuva ajantasaistus Kohderyhmä Konflikti Maastotietojärjestelmä Maastotietokanta Määräväleinen ajantasaistus Perusparannus Puskurikarttalehdet Topologia Topologiataso Maastotietokannan ajantasaistuksen prosessi, joka keskittyy pääsääntöisesti tie- ja osoiteaineistoon. Maastotietojen kohdemallissa määritetty ryhmä maastotietokannan kohteita, jotka muodostavat loogisen kokonaisuuden. Kohde on konfliktissa, kun se on muuttunut sekä isäettä lapsivaihtoehdossa. Konflikti havaitaan muutosten tuonnissa lapsivaihtoehtoon. Maanmittauslaitoksen maastotietojen keruu-, ajantasaistus-, varastointi- sekä tuotteiden valmistus- ja jakelujärjestelmä. Maanmittauslaitoksen ylläpitämä yksityiskohtaisin valtakunnallinen maastoa kuvaava aineisto. Maastotietokannan ajantasaistuksen prosessi, joka keskittyy A-laatuluokan aineiston alueelliseen ajantasaistukseen. Maastotietokannan ajantasaistuksen prosessi, joka keskittyy B-laatuluokan aineiston alueelliseen perusparannukseen (B->A). Tuotantosuunnitelmien alaisissa töissä haettavat karttalehdet, jotka jakavat kohteita työalueen karttalehtien kanssa. Kohteiden koordinaateista riippumattomat sijaintisuhteet toisiinsa nähden. Smallworld:ssä manifold. Käsittää topologisesti toisensa tunnistavat kohteet. Vain samassa topologiatasoissa olevat kohteet muodostavat topologisia yhteyksiä keskenään.

11 Transaktio Tuotantosuunnitelma Työ Työalue Rekisteri Tapahtuma. Sisältää johdonmukaisen joukon tietokantamuutoksia, jotka kaikki joko tehdään alusta loppuun tai perutaan. Rekisterin alainen vaihtoehto, jossa suoritetaan alueellinen perusparantaminen tai määräväleinen ajantasaistus. Joko suoraan rekisterin alainen vaihtoehto (jatkuvan ajantasaistuksen työ) tai tuotantosuunnitelman alainen vaihtoehto, joissa tuotantosuunnitelman varsinainen ylläpito tehdään. Työalue käsittää ne 1:5000 karttalehdet, joilla käyttäjä on työskennellyt työssään, laajennettuna 30 metrin bufferilla. JAKO/MTJ:n päävaihtoehto (top), maastotietokanta.

12 1 JOHDANTO 1.1 Taustaa Maanmittauslaitoksessa (MML) siirryttiin syksyllä 2000 maastotietokannan (MTK) ylläpidossa uuteen järjestelmään, kun uusi JAKO/Maastotietojärjestelmä (JAKO/MTJ) korvasi vaiheittain vanhan Maagis/Maastotietojärjestelmän (Maagis/MTJ). JAKO/MTJ on rakennettu Smallworld GIS ympäristöön, jonka version hallintaan (version management) perustuva puumainen ajantasaistusrakenne mahdollistaa useille käyttäjille aineiston samanaikaisen muokkaamisen eri vaihtoehdoissa. Uuden järjestelmän myötä siirryttiin vanhasta 1: 10 000 -karttalehtijakoon perustuvasta tiedostopohjaisesta tietokannasta spatiaalisesti jatkuvaan tietokantaan. Käyttäjät, jotka olivat aikaisemmin tottuneet työskentelemään lukittujen tiedostojen kanssa, pystyivät nyt työskentelemään saumattomasti koko tietokannassa ilman, että heidän tarvitsi varata tai lukita tarvitsemiaan tietoja. Samalla järjestelmä kuitenkin mahdollisti samojen tietokannan kohteiden samanaikaisen muokkaamisen. Jos samaa kohdetta on muokattu tietokannan eri vaihtoehdoissa, näiden tietojen yhdistämisessä havaitaan konflikti. Käyttäjien ohjeistuksesta huolimatta konfliktitapausten yleisyys ja konfliktien ratkaisemisen vaikeus yllättivät JAKO/MTJ:n kehittäjät. Smallworld:n vakioratkaisut konfliktien käsittelyyn havaittiin puutteellisiksi ja vaikeiksi käyttää. Konfliktien ratkaisua kehitettiin niin, että JAKO/MTJ:ssä konfliktien ratkaisu automatisoitiin ja käyttäjille jätettiin konfliktissa olleiden kohteiden jälkikäsittely.

13 1.2 Työn tavoite Tämän työn tarkoituksena on selvittää lukijalle, miten tietokannassa syntyy konflikteja ja mitä tarkoittaa, kun tietokannan kohde on konfliktissa. Mikä vaikutus konflikteihin on JAKO/MTJ:n ylläpitoprosesseilla ja käyttäjien työskentelytavoilla. Mitä eroa on suoralla konfliktilla ja epäsuoralla eli topologian kautta levinneellä konfliktilla. Millaisia topologioita maastotietokannan kohteilla on ja miten konflikti voi topologian kautta levitä. Lisäksi selvitetään mitä eri vaihtoehtoja käyttäjällä konfliktien ratkaisuun on. Pääpaino työssä on kuitenkin konfliktien ratkaisemisen ongelmallisuuden selvittämisessä. Edelleen kuvataan Smallworld:n konfliktien vakioratkaisun ongelmia ja sitä miksi siitä jouduttiin luopumaan. Tarkastellaan konfliktien ratkaisun nykykäytäntöä, sen ongelmia sekä sitä, miten sitä olisi hyvä tulevaisuudessa kehittää eteenpäin. 1.3 Työn sisältö Työn alussa lukijalle kuvataan yleisesti JAKO/MTJ:ää, maastotietokantaa ja sen ylläpitoprosesseja. Seuraavassa luvussa kuvataan JAKO/MTJ:n geometriatyyppejä, topologista mallia sekä topologisia kohteita ja niiden topologiasääntöjä. Neljännessä luvussa keskitytään JAKO/MTJ:n ajantasaistusrakenteeseen, töihin ja tuotantosuunnitelmiin. Lisäksi lukijalle kuvataan miten käyttäjien työskentelyä pyritään organisoimaan konfliktien välttämiseksi. Seuraavassa luvussa kuvataan Smallworld:n versionhallinta, tietokannan vaihtoehdot ja versiot sekä selostetaan lukijalle konfliktien synnyn periaate. Seuraavissa luvuissa keskitytään konfliktienhallintaan syvemmin. Kuvataan konfliktienhallinnan ongelmallisuutta JAKO/MTJ:ssä, miten ongelmat on ratkaistu tällä hetkellä ja miten niiden hallintaa tulisi mahdollisesti kehittää eteenpäin tulevaisuudessa.

14 2 JAKO/MAASTOTIETOJÄRJESTELMÄ 2.1 Yleistä Maanmittauslaitoksen maastotietojärjestelmä (MTJ) on maastotietojen keruu-, ajantasaistus-, varastointi- sekä tuotteiden valmistus- ja jakelujärjestelmä. Maastotietojärjestelmä on määritelty maastotietojen kohdemallin, laatumallin, toimintomallin ja tuotemallin avulla. Maastotietojärjestelmä otettiin käyttöön Maanmittauslaitoksessa vuonna 1992, kun maastotietojen keruu aloitettiin Maagis/MTJ:llä. JAKO/MTJ:n valmistuttua vuonna 2000, se korvasi Maagis/MTJ:n maastotietojen keruussa, ajantasaistuksessa sekä varastoinnissa. Maastokarttajulkaisut 1:20000 (peruskartta) ja 1:50000 (topografinen kartta) valmistetaan toistaiseksi edelleen Maagis/MTJ:llä. 2.2 Maastotietokanta Maanmittauslaitoksen ylläpitämä maastotietokanta on yksityiskohtaisin valtakunnallinen maastoa kuvaava aineisto. Sen aineisto on topologisesti ja kartografisesti yhteen sovitettua. Vuoden 2002 lopussa maastotietokanta kattoi 91.2 % Suomen pinta-alasta lukuun ottamatta Pohjois-Lappia. Aikaisemmin Pohjois-Lapin kartoituksesta vastasi Puolustusvoimien Topografikunta, mutta vuodesta 2002 myös Ylä-Lapin kartoituksesta on vastannut Maanmittauslaitos. Tavoitteena on, että maastotietokanta kattaisi koko Suomen vuoteen 2006 mennessä. (MML 2003a) Liitteessä 1 on kuvattu maastotietokannan tilanne 31.12.2003. Poikkeuksen maastotietokannan aineistoissa tekee tie- ja osoiteaineisto, jota aikaisemmin ylläpidettiin omassa tietietokannassaan ja joka jo nyt kattaa koko Suomen.

15 Maastotietokanta sisältää keskeisimmät maastoa ja rakennettua ympäristöä kuvaavat tiedot. Kohteiden sijaintitietojen tarkkuus vastaa mittakaavoja 1:5 000 1:10 000, joka on ns. A -luokanlaatuluokan alueilla noin 5 metriä ja B -laatuluokan alueilla noin 20 metriä. (MML 2003b) 2.2.1 Kohderyhmät Maastotietokantaan tallennettavat maastotiedot määritellään maastotietojen kohdemallissa. Maastotietokannan kohteet on jaoteltu teemoittain kohderyhmiin, jotka muodostavat loogisia kokonaisuuksia (MML 1996a). Maastotiedot on ryhmitelty maastotietojen kohdemallin mukaisesti seuraaviin kohderyhmiin: 1. Liikenneverkot 2. Johtoyhteydet 3. Maasto/1 4. Maasto/2 5. Korkeussuhteet 6. Rakennukset 7. Erityiskäyttöalueet 8. Suojelukohteet 9. Hallintorajat 10. Kiinteistöjaotus 11. Runkopisteet Ensimmäisten kuuden kohderyhmän kohteita kutsutaan perusmaastotiedoiksi. Näiden kohderyhmien kohteet ovat fyysisesti havaittavia maaston kohteita. Loput kohderyhmistä käsittävät ns. muita maastotietoja. (Salo-Merta et al. 1993)

16 2.2.2 Kohteet Maastotietokanta sisältää 146 kohdetta, jotka on maastotietojen kohdemallin mukaisesti jaoteltu 492 kohdeluokkaan (Vanhamaa 2004). Kohteet on tallennettu maastotietokantaan kohdemallin mukaisesti joko pisteinä, viivoina, alueina tai teksteinä. Kohteille tallennetaan sijainnin ja geometriatyypin lisäksi vielä kohdekohtaisia ominaisuustietoja. Kohteiden sijaintitarkkuudet päivittyvät automaattisesti aina kohdetta muokattaessa ylläpidossa käytetyn aineiston (esim. ilmakuvaus 1: 31 000 tai digitaalinen ortokuva 1: 16 000) ja laitteiston mukaan ( joko 2D -työasema tai 3D -stereotyöasema). 2.3 Ympäristö JAKO/MTJ perustuu Smallworld GIS ohjelmistoon, jota on räätälöity Maanmittauslaitoksen tarpeita varten. Tietojärjestelmä käyttää MML:n tietoverkkoa, joka jakaantuu laitosverkkoon ja toimipistekohtaisiin lähiverkkoihin. (Saarikoski 1999a) Käyttäjien työasemat ovat XP-koneita, toimipisteiden puskuripalvelimet sekä esirekisteröintejä hoitava edustapalvelin ovat Windows 2000 koneita ja varsinainen Smallworld tietokantapalvelin on UNIX-kone (Mansikkamäki 2004). Kolmiulotteinen tiedon keruu suoritetaan JAKO/MTJ:ssä digitaalisilta ilmakuvilta ESPA -stereotyöasemilla. ESPA -stereotyöasemilla on käytössä EspaSystemsin kehittämä EspaCity -ohjelmisto. Työasemien stereomalli perustuu digitaalisiin ilmakuviin ja polarisaatioperiaatteeseen. Työaseman näyttöruudun päälle asetettu polarisaatiopaneeli ja käyttäjän silmillä olevat polarisaatiolasit yhdessä aikaansaavat stereovaikutelman. Maastotietokannan vektoriaineisto voidaan näyttää kolmiulotteisena stereomallilla ns. päällenäyttönä. ESPA stereotyöasemalla kerätty ja muokattu aineisto tallennetaan suoraan JAKO/MTJ:n Smallworld tietokantaan. (Saarikoski 1999b)

17 Kuva 1. ESPA- stereotyöasema. ( Saarikoski 1999b) 2.4 Prosessit JAKO/MTJ:n prosessien tavoitteena on yhteensopivien maasto- ja kiinteistötietojen aikaansaaminen. Prosessit voidaan jakaa kolmeen osaprosessiin: perusparannukseen, 5-10 vuoden määrävälein tehtävään ajantasaistukseen sekä jatkuvaan ajantasaistukseen (JAKOMAA 1999a). 2.4.1 Perusparannus Perusparannuksella tarkoitetaan aineiston laadun korottamista B-laatuluokasta A-laatuluokkaan. B-laatuluokka tarkoittaa, että tiedot on kerätty digitoimalla aineisto vanhoista peruskartoista. Aineistolla ei ole korkeuksia ja sen sijaintitarkkuuksissa on eroja. Perusparannus suoritetaan aina, jos yksikin ajantasaistettavan alueen aineistoryhmistä ei ole A-laatuluokkaa. Perusparannus suoritetaan

18 ESPA -stereotyöasemalla ja tavoitteena on sijaintitarkkuudeltaan parempi 3D -tietokanta. Perusparantaminen suoritetaan korkeustiedoille, maastotiedoille ja kiinteistörajatiedoille. Korkeuskäyrät ovat kattavasti B-laatuluokkaa eli niiden sijaintitarkkuus eroaa myös A-tason aineistossa (JAKOMAA 1999b). Tästä syystä korkeustieto perusparannetaan aina riippumatta siitä, perustuuko aineisto ilmakuvakarttaan vai stereotyöhön. Korkeustiedon perusparannuksessa korjataan korkeuskäyrien selkeät virheet. Maastotietojen laatumallissa korkeuskäyrien korkeussijaintitarkkuusvaatimukseksi määritellään 0.5 * käyräväli, joka on Etelä-Suomessa 2.5 m ja Pohjois-Suomessa 5 m (MML 1995). Tavoitteena on, että korkeustiedoista ja maanpintapisteistä laskettavan 10 m ruutukoon korkeusmallin virheet ovat korkeintaan 2-3 metriä (JAKO/MTJ-ohje 2003). Korkeustiedon perusparannusprosessi on kuvattu kaaviona liitteessä 2. Maastotietojen perusparannus suoritetaan aina ESPA -stereotyöasemalla. Maastokohteiden laatuvaatimus korkeustiedon osalta on 2 metriä (MML 1995). Tätä suuremmat poikkeamat korkeuksissa on korjattava perusparannuksen yhteydessä. Laatuvaatimukset maastokohteiden sijaintitarkkuuksille määritetään kohdekohtaisesti maastotietojen laatumallissa. Jos perusparannettava aineisto on jo A-laatuluokkaa, voidaan perusparannus poikkeustapauksissa suorittaa ortokuvilta. Tällöin on työskentelyn lopuksi ajettava 2D -kohteille Kohteille korkeudet korkeusmallista - työkalulla korkeudet 10 m korkeusmallista. Maastotietojen perusparannuksessa käydään läpi liikenneverkot, rakennukset, pellot ja vesistöt sekä johtoyhteydet. Tämän jälkeen käydään läpi muut maastotietokannan kohteet ja tarkistetaan näiden kohteiden yhteensopivuus stereossa mitattuihin kohteisiin. Maastotietojen perusparannuksen prosessi on kuvattu kaaviona liitteessä 3. Kiinteistötietojen perusparannus on osa perusparannusprosessia, jossa pyritään saamaan aikaan yhteensopivat maasto- ja kiinteistötiedot. Kiinteistötietojen perusparannus suoritetaan JAKO/Kiinteistötietojärjestelmässä (JAKO/KII) ja muutokset tallennetaan JAKO -tietokantaan. Numeerisen kiinteistörekisterikartan (NKRK) rajamerkkien

19 koordinaatit perusparannetaan B-laatuluokasta A-laatuluokkaan signaloimalla rajamerkit, ilmakuvaamalla alue ja suorittamalla ESPA -stereotyöasemalla pisteiden perusparannus. 2.4.2 Määrävälein tehtävä ajantasaistus Määräväleistä ajantasaistusta suoritetaan noin viiden vuoden välein A-laatuluokan alueilla, B-laatuluokan alueilla suoritetaan aina aineiston perusparannus. Määrävälein tehtävä ajantasaistus tehdään vain maastokohteille, ei korkeus- eikä kiinteistötiedoille. Jos ajantasaistettavalla alueella ei ole tehty korkeustietojen perusparannusta, se suoritetaan prosessissa ennen maastotietojen ajantasaistusta. Ajantasaistuksessa lisätään uudet maastokohteet maastotietokantaan ja tarvittaessa muokataan muuttuneita kohteita. Määrävälein tehtävä ajantasaistus voidaan suorittaa joko ESPA -stereotyöasemalla (3D) tai 2D ortokuvatyöasemalla, jolloin työskentelyn lopuksi maastokohteille ajetaan korkeudet korkeusmallista aivan kuten perusparannuksen yhteydessä. Määräväleisen ajantasaistuksen prosessi kuvataan liitteessä 4. 2.4.3 Jatkuva ajantasaistus Jatkuvassa ajantasaistuksessa ylläpidetään lähinnä tietoja, jotka eivät voi odottaa seuraavan perusparannuksen tai määräväleisen ajantasaistuksen valmistumista. Jatkuvan ajantasaistuksen prosessi kohdistuu pääsääntöisesti tie- ja osoiteaineistoon, joiden arvo on suuri ja joihin kohdistuu Maanmittauslaitoksessa merkittävä asiakaspaine. Tiestön ylläpidossa hyödynnetään sekä Maanmittauslaitoksen sisäisiä että ulkoisia nk. vihjetietoja. Sisäisellä vihjetiedolla tarkoitetaan laitoksen oman henkilökunnan esim. mittamiesten tai toimitusmiesten maastokäynneillä keräämää tietoa kartoista puuttuvista teistä. Ulkoinen vihjetieto saadaan asiakaspalautteena sekä maanmittaustoimistojen sopimuskumppaneilta, jotka ilmoittavat uusista rakentamistaan teistä. Tällaisia sopimuskumppaneita ovat esim. kunnat, Tielaitoksen tiepiirit, metsäkeskukset sekä isot metsäyhtiöt. Vihjetietojen perusteella maanmittaustoimisto tekee kerran vuodessa

20 tarvittavat GPS mittaukset. Mitattu aineisto ladataan JAKO/MTJ:hin ja sovitetaan jo kannassa olevaan tieaineistoon. Myös johtoyhteyksien ajantasaistus perustuu yhteistyöhön sähkölinjoja omistavien laitosten ja paikallisten puhelinyhtiöiden kanssa. Vuosittain muuttuneet linjatiedot voidaan suoraan tilata sähkölaitoksilta ja puhelinyhtiöiltä tai näiden kanssa voidaan tehdä osto-, myynti-, tiedonvaihto tai sijaintitiedon parannussopimuksia tietojen ajantasallapidosta. (MML 1996b) Tiestön ja johtoyhteyksien lisäksi jatkuvassa ajantasaistuksessa keskitytään rakennuksiin, hallinnollisiin rajoihin ja asutusnimiin (JAKOMAA 1999a). 2.4.4 Ylä-Lapin tiedonkeruu Ylä-Lapin tiedonkeruu ei kuulu varsinaisiin maastotietokannan ylläpitoprosesseihin. Kun JAKO/MTJ:n muut prosessit kohdistuvat maastotietokannan aineiston parantamiseen ja ajantasaistamiseen, niin Ylä-Lapin prosessi keskittyy maastotietokannasta puuttuvan aineiston keräämiseen. Ylä-Lapin kartoitusvastuu siirtyi Puolustusvoimien Topografikunnalta Maanmittauslaitokselle vasta vuonna 2002. Vuotta aikaisemmin maastotietokanta oli valmistunut muualta Suomesta. Toistaiseksi maastotietokannan kohteista vain tiestö kattaa koko valtakunnan alueen, muut kohteet kerätään prosessissa maastotietokantaan ESPA stereotyöasemilla. Ylä-Lapin uudiskartoitusprosessin tarkoitus on saada maastotietokanta valmiiksi Ylä-Lapista vuonna 2006. Maastotietokannan kattavuus 31.12.2003 on kuvattu liitteessä 1. 2.5 Ajantasaistusrakenne JAKO/MTJ:ssä on käytössä kaksiportainen ajantasaistusrakenne. Maastotietojen perusparannus ja määrävälein tehtävä ajantasaistus tehdään maastotietokannan päävaihtoehdon eli rekisterin (top) alaisissa vaihtoehdoissa, joita kutsutaan tuotantosuunnitelmiksi (TUSU). Tuotantosuunnitelman alue käsittää koko perusparannettavan tai ajantasaistettavan alueen. Varsinainen ylläpitotyö tehdään kuitenkin tuotantosuunnitelman alaisissa alueellisesti pienemmissä vaihtoehdoissa, joita

21 kutsutaan töiksi. Tuotantosuunnitelman alle luotavien töiden luokka vaihtelee aina käynnissä olevan prosessin vaiheen mukaan. Tuotantosuunnitelma rekisteröidään maastotietokannan päävaihtoehtoon vasta, kun koko tuotantosuunnitelman alueen ajantasaistus on valmistunut. Näin rekisteriin saadaan alueellisesti yhtenäistä aineistoa. Jatkuva ajantasaistus tehdään suoraan rekisterin alaisissa vaihtoehdoissa, töissä. Kuva 2. JAKO/Maastotietojärjestelmän ajantasaistusrakenne. (JAKO/MTJ-ohje 2001)

22 3 TOPOLOGIA 3.1 JAKO/Maastotietokannan geometriatyypit JAKO/MTJ:ssä maastotietokannan kohteet tallennetaan maastotietokantaan vektoriaineistona. Kohteet tallennetaan maastotietokantaan maastotietojen kohdemallin mukaisesti joko pisteinä, viivoina, alueina tai teksteinä. Smallworld:ssä kohteiden geometriat tallennetaan tyypeittäin kukin omaan tietokantatauluunsa ja näitä vastaavat tietokantakohteet omiin tietokantatauluihinsa. Maastotietokannan kohteet voidaan jakaa geometriatyypeittäin teksteihin, yksinkertaisiin (simple) ja topologisiin geometrioihin. Yksinkertaiset piste- ja viivakohteet eivät ole minkäänlaisissa yhteyksissä toisiin tietokannan geometrioihin. Yksinkertaiset geometriat eivät siis tunnista lainkaan ympäristönsä muita kohteita. Topologiset piste-, viiva- ja aluekohteet ovat muuten samanlaisia kuin yksinkertaiset geometriat, mutta ne yhdistyvät toisiinsa topologiasääntöjen mukaisesti solmujen, linkkien ja polygonien kautta. 3.2 Topologinen malli Maanmittauslaitoksen paikkatietotekniikan sanastossa (MML 2004a) määritellään seuraavasti: topologia Geometristen yksilöiden keskinäinen asema. Tapa, jolla geometriset yksilöt liittyvät toisiinsa (esim. alueiden naapuruus, viivan ja alueiden naapuruus, viivojen liittyminen toisiinsa solmupisteessä). Matematiikan osa-alue, joka käsittelee (abstraktien) geometristen olioiden piirteitä, jotka eivät muutu esim. koordinaattimuunnoksissa.

23 Paikkatiedossa topologialla tarkoitetaan siis kohteiden sijaintisuhteita toisiinsa nähden. Kohteiden topologiset sijaintisuhteet ovat riippumattomia kohteiden koordinaateista. Kohteen topologia pysyy samana vaikka kohdetta esim. venytettäisiin tai taivutettaisiin. Useita paikkatietoanalyyseja voidaan tehdä topologian avulla ilman kohteiden koordinaattitietoja. Topologinen malli muodostuu solmuista (node) ja linkeistä (link). Solmu voi olla piste, jossa kaksi viivaa leikkaavat toisensa, viivan alku- tai loppupiste tai mikä tahansa annettu piste viivalta. Linkki on viivan osa, jonka molemmissa päissä on solmu. Linkillä on aina alku- ja loppusolmu. Linkit yhdistyvät (solmuttuvat) toisiinsa vain solmuissa. Polygoni muodostuu toisiinsa solmuttuneista linkeistä, jotka muodostavat sulkeutuvan alueen. (Bernhardsen 1999) Kun solmuihin ja linkkeihin lisätään yksiselitteiset tunnukset, voidaan kuvan 3 kohteiden topologinen malli esittää kuvan kolmen taulun avulla. Kukin tauluista kuvaa aina yhden kuvan elementin topologian. Ensimmäisessä taulussa Polygonien topologia kuvataan linkit, jotka rajaavat kutakin polygonia. Esimerkiksi polygonia B rajaavat linkit L2, L3 ja L5. Polygonien sisällä voi olla myös saaria. Tästä esimerkkinä polygoni C, joka on polygonin A saari. Saaret kuvataan polygonien linkkilistassa lisäämällä listaan nolla ennen linkkejä, jotka rajaavat saarta. Myös pistemäinen kohde käsitetään topologisessa mallissa polygonina (esim. polygoni D). Tällaisilla polygoneilla ei ole aluetta ja niiden linkissä on vain yksi piste. Seuraavassa taulussa Solmujen topologia kuvataan kaikki solmuihin yhdistyvät linkit. Esimerkiksi solmussa S2 yhdistyvät linkit L1, L2 ja L5. Kolmannessa taulussa Linkkien topologia kuvataan linkkien yhteydet solmuihin ja polygoneihin. Taulussa kuvataan kunkin linkin alku- ja loppusolmu sekä polygonit linkin vasemmalla ja oikealla puolella. Esimerkiksi linkki L5 alkaa solmusta S2 ja päättyy solmuun S1. Kuljettaessa solmusta S2 solmuun S1 polygoni linkin L5 oikealla puolella on A ja vasemmalla puolella B. (Aronoff 1991)

24 X 20 S2 L2 10 L1 D C S5 L6 S6, L7 A L5 B L4 S4 S3 E S1 L3 10 20 30 Y POLYGONIT LINKIT SOLMUT LINKIT A L1, L5, 0, L6, 0, L7 S1 L1, L3, L5 B L2, L3, L5 S2 L1, L2, L5 C L6 D L7 E L1, L2, L3 Taulu 1. Polygonien topologia. S3 L2, L3, L4 S4 L4 S5 L6 S6 L7 Taulu 2. Solmujen topologia. LINKKI ALKUSOLMU LOPPUSOLMU VASEN OIKEA POLYGONI POLYGONI L1 S1 S2 E A L2 S2 S3 E B L3 S3 S1 E B L4 S3 S4 B B L5 S2 S1 B A L6 S5 S5 A C L7 S6 S6 A A Taulu 3. Linkkien topologia. Kuva 3. Topologinen malli (Aronoff 1991, muokattu)

25 Topologisen mallin ideana on, että kaikki geometriset kohteet voidaan kuvata solmuilla ja linkeillä. Neljännellä lisätaululla Linkkien koordinaatit (kuva 4), jossa kuvataan linkkien pisteiden koordinaatit, voidaan topologinen malli liittää todelliseen maailmaan. Koordinaatit mahdollistavat etäisyyksien, alueiden, leikkausten ja muiden numeeristen arvojen laskemisen. (Bernhardsen 1999) Kuva 4. Linkkien pisteiden koordinaatit. (Aronoff 1991, muokattu) Polygonien topologia taulussa (kuva 3, taulu 1) sama linkki saattaa esiintyä useampaan kertaan, mutta linkin koordinaatit esitetään vain kerran Linkkien koordinaatit taulussa (kuva 4). Tällä tavoin topologinen malli estää vierekkäisten alueiden väliset raot sekä alueiden päällekkäisyyden. Topologien malli mahdollistaa myös useiden paikkatietoanalyysien tekemisen kohteiden viereisyyden (adjacency) ja yhdistyvyyden (connectivity) avulla. Viereisyydellä tarkoitetaan tietoa vierekkäisistä polygoneista, jotka jakavat saman linkin. Viereisyys -analyysejä voidaan käyttää esim. analysoitaessa maaston kasvillisuuden vaihteluja. Yhdistyvyydellä kuvataan linkkejä, jotka yhdistyvät toisiinsa solmuissa. Verkostomaisilla kohteilla voidaan yhdistyvyyden avulla esim. hakea lyhintä reittiä kahden pisteen välillä.

26 Topologisessa rakenteessa kukin polygoni muodostuu joukosta viivoja, jotka vastaavasti kukin muodostuvat tietyssä järjestyksessä olevista koordinaateista. Tätä kutsutaan muodostumiseksi ja sillä tarkoitetaan siis sitä, että pisteet muodostavat viivan, viivat muodostavat alueen ja vastaavasti alue muodostuu viivoista ja viiva pisteistä. (Virrantaus 2003) 3.3 Topologia JAKO/Maastotietojärjestelmässä Kuvassa 5 esitetty Smallworld:n topologinen malli (Smallworld 2003) voidaan kuvata seuraavasti: Piste on yhteydessä aina yksittäiseen solmuun. Viiva muodostuu tietyssä järjestyksessä yhdistyneistä linkeistä. Linkki muodostuu sen reitin määrittävistä sektoreista. Linkillä on kaksi solmua, alku- ja loppusolmu. Jos linkki on itseensä sulkeutuva, ovat sen alku- ja loppusolmu sama solmu. Alue muodostuu yhdestä tai useammasta polygonista, jotka voivat olla vierekkäin tai irrallaan toisistaan. Polygoni muodostuu sen ulkoreunaa pitkin myötäpäivään kulkevista linkeistä, jotka muodostavat sulkeutuvan alueen. Solmuun voi yhdistyä kuinka monta pistettä tai linkkiä tahansa. Solmu, johon tulee kaksi tai useampi geometrioita, yhdistää nämä geometriat topologisesti. Linkkiin voi linkittyä kuinka monta viivaa tai polygonia tahansa. Polygoni kuuluu yleensä vain yhteen alueeseen. Polygoniin voi liittyä muita polygoneja reikinä. Sektori on yhtenäinen viiva geometria, joka muodostuu peräkkäisistä toisiinsa yhdistyneistä segmenteistä, jotka kaikki ovat joko suoria tai käyriä. Sektori sisältää pisteet ja (käyrille) kontrollipisteet, jotka määrittävät segmentit. (Smallworld 2003)

27 Kuva 5. Topologinen malli Smallworld 3:ssa. (Smallworld 2003, muokattu) Smallworld:n oma topologinen malli eroaa hiukan Aronoffin (Aronoff 1991) esittämästä topologisesta mallista (ks. kuva 3). Aronoffin mukaan topologinen pistemäinen kohde sisältää solmun lisäksi aina myös sekä linkin että polygonin. Smallworld:ssa pistemäinen topologinen kohde sisältää ainoastaan solmun. Tästä esimerkkinä kuvaan 6 on ns. liputettu sähkölinjojen linkkien yhteydet. Liputtamisella tarkoitetaan tässä tilanteessa sitä, että karttaikkunaan solmujen kohdille piirretään pienet neliöt, joissa ilmoitetaan solmuun tulevien linkkien lukumäärä. Samalla linkit korostetaan karttaikkunassa ja niiden viereen piirretään numero, joka ilmoittaa linkin jakavien kohteiden lukumäärän. Kuvassa 6 näkyy kaksi sähkölinjan solmua, joista toinen liputtaa numeroa kolme ja toinen numeroa kaksi. Solmu, joka liputtaa kolmosta, yhdistää kolme sähkölinjaa. Tähän solmuun yhdistyy siis kolme sähkölinjan linkkiä. Toinen sähkölinjan solmuista liputtaa kakkosta. Tässä solmussa yhdistyvät sähkölinja ja sähkölinjan symboli. Lipun numero ei kuitenkaan kuvaa solmuun tulevien kohteiden lukumäärää vaan solmuun tulevien linkkien lukumäärän. Tässä tapauksessa solmuun tulevalla symbolilla ei ole linkkiä, vaikka se yhdistyykin solmun kautta sähkölinjaan. Solmu piste katkaisee kuitenkin sähkölinjan linkin, jolloin sähkölinjassa on nyt kaksi erillistä linkkiä. Nämä linkit yhdistyvät solmussa, joka tällöin liputtaa kakkosta.

28 Sähkölinjojen linkit liputtavat kuvassa ykköstä. Tämä tarkoittaa sitä, etteivät sähkölinjat jaa linkkejä muiden kohteiden kanssa. Kuvassa 7 on karttaikkunaan korostettu rakennusten linkit ja solmut. Kuvassa rakennusten reunaviivat ovat itseensä sulkeutuvia. Tällöin reunaviivan linkin alku- ja loppusolmut ovat yksi ja sama solmu. Solmut liputtavat kakkosta, koska solmuun saapuu sama linkki kahdesti (linkin alku- ja loppupää). Rakennuksen reunaviivan viivan linkin jakavat sekä rakennuksen reunaviiva että rakennusalue. Tällöin linkin viereen korostuu numero kaksi. Kuva 6. Sähköverkoston linkit ja solmut. Kuva 7. Rakennusten linkit ja solmut. Toinen eroavaisuus aikaisemmin esitetyssä ja Smallworld:n topologisessa mallissa on linkin jakavien polygonien lukumäärä. Smallworld mahdollistaa useamman kuin kahden polygonin jakavan linkin. Tämä tarkoittaa, että sekä linkin vasemmalla tai oikealla puolella voi olla useampia alueita. Tosin JAKO/MTJ:n kannalta tällainen tilanne olisi virheellinen, sillä samaan topologiatasoon (ks. luku 3.3.1) kuuluvat alueet eivät voi olla päällekkäin.

29 3.3.1 Topologiatasot JAKO/Maastotietokannan kohteet jaotellaan teemoittain 11 kohderyhmään (ks. luku 2.2.1). Tämän lisäksi topologiset kohteet jaetaan 12 topologiatasoon (manifoldiin): 1. Tiestö 2. Rautatiestö 3. Vesikulkuväylästö 4. Maasto 1 5. Maasto 2 6. Rakennukset 7. Sähköverkosto 8. Johtoverkosto 9. Puhelinverkosto 10. Erityiskäyttöalueet 11. Suojelukohteet 12. Hallinnollinen jaotus Vain samaan topologiatasoon kuuluvat kohteet tunnistavat topologisesti toisensa ja esimerkiksi linkittyvät toisiinsa. Topologiatasot ryhmittelevät toisiinsa topologisesti liittyvät kohteet. Eri topologiatasoihin kuuluvat kohteet käyttäytyvät keskenään aivan kuin kohteet, joilla ei ole lainkaan topologiaa. Vaikka topologiatasojen jaottelu muistuttaa maastotietokannan kohderyhmittelyä, näitä kahta ryhmittelyä ei saa sekoittaa keskenään. Huomioitavaa on, etteivät kaikki maastotietokannan kohteet välttämättä kuulu mihinkään topologiatasoon. Tällöin kyse on kohteesta, jolla on yksinkertainen geometria eikä siis lainkaan topologiaa. Joihinkin kohderyhmiin, kuten esim. korkeussuhteet kohderyhmään, ei kuulu lainkaan topologisia kohteita. Tällöin tämän kohderyhmän kohteita ei kuulu mihinkään topologiatasoon. Vastaavasti joihinkin kohderyhmiin kuuluu sekä yksinkertaisia että topologisia geometrioita. Esimerkiksi suojelukohteet kohderyhmään kuuluvista kohteista vain topologiset kohteet kuuluvat topologiatasoon suojelukohteet. Topologiataso ja kohderyhmä voivat olla saman nimisiä, mutta niiden sisältämät kohteet eroavat toisistaan. Liikenneverkot ja johtoyhteydet on topologiatasoissa jaettu useampaan osaan riippuen siitä, millaisia verkostoja kohteet luonnossa muodostavat.

30 3.3.2 Topologiasäännöt JAKO/Maastotietojärjestelmässä Jokaisella topologiatasolla on topologiasääntönsä, jotka määrittelevät tason geometrioiden suhteet toisiinsa. Topologiasäännöt varmistavat, että jokainen uusi kohde linkittyy oikein muihin tason kohteisiin. JAKO/MTJ:ssä kohteiden topologiasäännöt voidaan jaotella pääsääntöisesti kahteen ryhmään riippuen siitä, onko kyse verkostomaisesta vai aluejakoon osallistuvasta kohteesta. Verkostomaisille kohteille kuten esim. sähkölinjoille ja rautateille asetettu topologiasääntö endsplit_chain tarkoittaa, että jos viivaa lisättäessä tai muutettaessa sen pää osuu toiseen saman topologiatason viivaan, tämä viiva katkeaa. Viivojen leikkauskohtaan muodostuu uusi solmu, johon kaikki kolme viivaa solmuttuvat. Verkostomaiset kohteet voivat kuitenkin leikata toisensa ilman, että topologiasäännöt aiheuttavat niiden pilkkoutumisen ja toisiinsa solmuttumisen. Esim. tieviivoilla tämä mahdollistaa tasoliittymien kuvaamisen, koska tieviivat eivät solmutu toisiinsa leikkauksessa. Aluemaisilla kohteilla reunaviivojen päiden lisäksi myös reunaviivojen toisiinsa leikkaaminen aiheuttaa näiden pilkkoutumisen. Topologiasääntö split_chain aiheuttaa samaan topologiatason kuuluvien viivojen katkeamisen ja toisiinsa solmuttumisen aina kun ne koskevat toisiinsa. Toisensa leikkaavien reunaviivojen pilkkoutuminen estää päällekkäisen alueiden muodostumisen tietokantaan.

31 4 TÖIDEN ORGANISOINTI 4.1 JAKO/Maastotietojärjestelmän ajantasaistusrakenne Maastotietojen varsinainen ylläpitotyö tehdään vaihtoehdoissa, joita kutsutaan töiksi. Jatkuvan ajantasaistuksen työt sijaitsevat suoraan päävaihtoehdon eli rekisterin alla. Perusparannuksessa ja määrävälein tehtävässä ajantasaistuksessa on käytössä kaksiportainen ajantasaistusrakenne. Siinä rekisterin alla on ensin tuotantosuunnitelma (TUSU), jonka alla vasta varsinaiset työt sijaitsevat (ks. kuva 2). Jatkuvassa ajantasaistuksessa työt rekisteröidään suoraan rekisteriin. Tuotantosuunnitelman alaiset työt rekisteröidään ensin tuotantosuunnitelmaan. Vasta kun kaikki tuotantosuunnitelman alaiset työt on rekisteröity tuotantosuunnitelmaan ja koko tuotantosuunnitelman alue on kunnossa, rekisteröidään tuotantosuunnitelma. Rekisteröitäessä työ tai tuotantosuunnitelma ylempään vaihtoehtoon, poistuu rekisteröity vaihtoehto samalla tietokannasta. 4.2 Tuotantosuunnitelmat ja työt Perusparannettavalle tai ajantasaistettavalle alueelle luodaan aina ensin tuotantosuunnitelma, jonka alle luodaan työt. Tuotantosuunnitelman lajiksi valitaan prosessin mukaisesti joko perusparannus tai määräväleinen ajantasaistus. Tuotantosuunnitelma nimetään yleensä samalla numerolla, kuin mikä sillä on Maastotietojen suunnittelu- ja seurantajärjestelmässä (MASU:ssa). Luonnin yhteydessä valittava aineisto (esim. ilmakuvaus 1:16 000 tai digitaalinen ortokuva 1:31 000) ja työskentelyssä käytettävä laitteisto (esim. ESPA stereotyöasema tai 2D ortokuvatyöasema) vaikuttavat tuotantosuunnitelmassa muokattavien kohteiden sijainti- ja korkeustarkkuuksiin. Tuotantosuunnitelmalle määritellään myös ne kunnat ja

32 karttalehdet, joiden alueella se sijaitsee. Tuotantosuunnitelman alaisia töitä ei voi luoda näiden määritettyjen karttalehtien ulkopuolelle. Jos työskentelyaluetta on tarve kasvattaa, voidaan tuotantosuunnitelman alueeseen tarvittaessa erikseen lisätä uusia karttalehtiä. Tuotantosuunnitelmien alaiset työt nimetään yleensä sen karttalehden mukaan, jolla työssä on tarkoitus työskennellä. Jatkuvassa ajantasaistuksessa töiden nimeämiskäytäntö on vapaampi. Karttalehden numeron sijasta voidaan käyttää nimeä, joka kuvaa tehtävää ajantasaistusta esim. KULKURAJ tai SAHKOLINJAT. Jatkuvassa ajantasaistuksessa työn luonnissa työn nimen lisäksi määritellään ainoastaan työskentelyssä käytettävä aineisto. Tuotantosuunnitelmissa töille määritellään aina myös työn kohde eli onko kyseessä korkeustietojen perusparannus, maastotietojen perusparannus, maastotietojen määräväleinen ajantasaistus vai maastotarkistus. Lisäksi määritellään alue, jolla työskennellään eli työalue. 4.3 Työalue Työskentelyalueiden hahmottamisen helpottamiseksi kaikille töille määritellään työalue. Työalueen avulla käyttäjä voi seurata aluetta, jolla työskentelee. Työalue ei rajoita käyttäjän työskentelyaluetta vaan ainoastaan havainnollistaa käyttäjälle, missä päin tietokantaa hän työskentelee. Suurin osa käyttäjän tietokantaan tekemistä ajoista ja tarkastuksista voidaan kohdistaa suoraan työalueelle. Luotaessa työ tuotantosuunnitelman alle määritellään työskentelyalueeseen kuuluvat 1:5 000 karttalehdet. Työalue on näiden valittujen karttalehtien alue, johon on lisätty 30 metrin nk. puskurialue. Kuvassa 8 on kuvattu työalue, joka muodostuu karttalehden 441306A alueesta ja 30 m laajennuksesta. Työalueen laajennus mahdollistaa työskentelyn työalueen karttalehtien reunoilla ilman, että työalue laajenee (ks. luku 4.3.1).

33 Kuva 8. Työalue = Karttalehtien alue + 30m. Tuotantosuunnitelmassa ohjelmisto määrittelee töille työalueen lisäksi puskurikarttalehdet. Puskurikarttalehdet ovat karttalehtiä, joilla on yhteisiä kohteita työalueen kanssa. Esimerkiksi työalueen reunalla sijaitseva pitkä korkeuskäyrä saattaa ulottua pitkälle työalueen ulkopuolelle. Puskurikarttalehtiin haetaan kaikki ne 1:5 000 karttalehdet, joille korkeuskäyrä ulottuu, mutta jotka eivät kuulu työalueeseen. Puskurikarttalehdet kuvaavat aluetta, jolla muiden työskenteleminen saattaa aiheuttaa konfliktin. Kuvassa 9 on karttaan korostettu työn 233205A1 työalue vihreällä ja puskurikarttalehdet keltaisella.

34 Jatkuvassa ajantasaistuksessa ei työn luonnin yhteydessä määritetllä työaluetta. Työalue muodostuu jatkuvassa ajantasaistuksessa sitä mukaa kun käyttäjä muokkaa kohteita ja työalue leviää. Työskentelyn nopeuttamiseksi puskurikarttalehtiä ei jatkuvassa ajantasaistuksessa haeta lainkaan. Kuva 9. Työalue ja puskurikarttalehdet.

35 4.3.1 Työalueen laajeneminen Jos käyttäjä muokkaa tietokannan kohdetta, joka on kokonaan työalueen ulkopuolella, työalue laajenee. Työalueen laajetessa siihen lisätään ne karttalehdet, joiden alueella työalueen laajenemisen aiheuttanut kohde sijaitsee. Työalueen laajetessa haetaan tuotantosuunnitelmien töiden työalueille aina myös uudet puskurikarttalehdet. Työn karttalehtiin lisätty 30 metrin puskurialue mahdollistaa käyttäjälle karttalehden reunalla työskentelyn ilman, että työalue laajenee. Työalue ei laajene, vaikka kohdetta muokataan työalueen ulkopuolella, jos kohde sijaitsee edes osittain työalueella. Kuva 10. Työalueen laajeneminen.

36 Sovelluksen havaitessa työalueen laajenevan käyttäjälle kerrotaan ne karttalehdet, joille työalue on laajenemassa. Käyttäjä voi tällöin halutessaan perua toiminnon, joka on laajentamassa työaluetta. Työalueen avulla käyttäjä on koko ajan selvillä työskentelyalueestaan. Jos työalue on laajennut alueelle, jolla käyttäjän ei ole ollut tarkoitus työskennellä, hän voi perua työalueen laajenemisen perumalla tietokantaan tekemänsä muutokset. Sovellus estää tuotantosuunnitelman alaisten töiden leviämisen tuotantosuunnitelman alueen ulkopuolelle. Jos tuotantosuunnitelman alla halutaan työalueita laajentaa tuotantosuunnitelman alueen ulkopuolelle, on tuotantosuunnitelman alueeseen lisättävä ensin uusia karttalehtiä. 4.3.2 Konfliktiriski Konfliktien välttämiseksi tuotantosuunnitelman alla ei voi luoda uutta työtä karttalehdelle, joka kuuluu toisen samassa tuotantosuunnitelmassa olevan työn työalueeseen. Vasta kun toinen työ on rekisteröity tuotantosuunnitelmaan voidaan lehdelle luoda uusi työ. Jos jatkuvassa ajantasaistuksessa työalue on laajenemassa karttalehdelle, joka kuuluu avoinna olevan tuotantosuunnitelman tai toisen jatkuvan ajantasaistuksen työn työalueeseen, ilmoitetaan käyttäjälle konfliktiriskistä. Samalla ilmoitetaan myös konfliktiriskin aiheuttama tuotantosuunnitelma tai työ. Työn laajenemista ei kuitenkaan estetä, vaan ainoastaan ilmoitetaan käyttäjälle mahdollisesta konfliktivaarasta. Käyttäjä voi halutessaan perua tekemänsä muutoksen, jolloin työalueen laajeneminen peruuntuu. Jatkuvan ajantasaistuksen lisäksi konfliktiriskistä ilmoitetaan myös tuotantosuunnitelman alaisissa töissä. Tuotantosuunnitelman tapauksessa tutkitaan kuitenkin vain saman tuotantosuunnitelman alaisten töiden työalueita. Konfliktiriski ei vielä tarkoita, että konflikteja on syntynyt. Se ainoastaan kertoo, että käyttäjä on siirtynyt työskentelemään samalle alueelle kuin joku toinen käyttäjä ja että

37 vaara aikaansaada konflikteja kasvaa. Esimerkiksi kunnan rajojen muuttaminen jatkuvassa ajantasaistuksessa ei yleensä aiheuta konflikteja, vaikka samalla alueella tehtäisiinkin tuotantosuunnitelmassa perusparannusta. Perusparannuksen prosessissa ei yleensä muokata hallinnollista jaotusta, joten tällöin ei kosketa samoihin kohteisiin kuin jatkuvassa ajantasaistuksessa. Konflikteja voi myös syntyä, vaikka työt eivät leviäisikään samoille karttalehdille. Konflikti syntyy, kun samaa kohdetta muokataan kahdessa eri työssä. Konflikti on siis mahdollinen, jos työalue leviää toisen työn puskurikarttalehdille. 4.4 Työskentelyn organisointi JAKO/MTJ:ssä on käytössä karttalehtijaosta riippumaton Smallworld:n versiohallittu relaatiotietokanta. Jatkuva tietokanta ja versioiden hallinta mahdollistavat käyttäjille työskentelyn missä päin Suomea tahansa (ks. luku 5.1.2). Käyttäjän työskentelyalue on siis täysin hänen itsensä päätettävissä. Jos samaa kohdetta muokataan samanaikaisesti useammassa työssä, tästä aiheutuu konflikti. Konfliktien välttämiseksi ei töitä saisi luoda samalle alueelle. Suositus on, että työalueiden väliin tulisi aina jättää ainakin 1:10 000:n lehteä vastaava alue. Sama suositus koskee myös tuotantosuunnitelmia. Jotta useampi käyttäjä ei vahingossa työskentele samalla alueella ja siten aiheuta konflikteja, on työskentelyalueista sovittava etukäteen. Pelkkä työskentelyalueista sopiminen ei kuitenkaan takaa sitä, etteikö samoilla alueilla vahingossa työskenneltäisi. Ongelmia on aiheuttanut käyttäjien siirtyminen vahingossa sovitun työskentelyalueen ulkopuolelle. Toinen ongelma on, ettei aina tiedetä, kenelle kaikille työskentelyn aloittamisesta tietyllä alueella tulisi ilmoittaa. Riittääkö tieto oman maanmittaustoimiston (MMT) väelle vai tulisiko asiasta ilmoittaa myös naapuritoimistolle. Yrityksistä huolimatta tieto työskentelyn aloittamisesta ei aina välttämättä tavoita kaikkia osapuolia.

38 Kuva 11. Töiden ja tuotantosuunnitelmien sijoittaminen toisiinsa nähden. 4.4.1 Työalueiden seuranta Työskentelyn organisoinnissa käyttäjien on tärkeää pystyä hahmottamaan oma työskentelyalueensa. Näin voidaan välttää turhia työalueen laajenemisia. Oman työalueensa lisäksi käyttäjien on pystyttävä havaitsemaan myös muut lähiympäristössä työskentelevät käyttäjät ja heidän työnalueensa. JAKO/MTJ:hin on kehitetty työkaluja, joiden avulla työalueiden hahmottaminen helpottuu. Monet sovelluksen joukkotoiminnoista, kuten esim. kohteille korkeuksien ajaminen korkeusmallista tai eheys- ja rekisteröitävyyden tarkastukset, voidaan kohdistaa joko suoraan työalueelle tai kartalta rajatulle alueelle. Rajattaessa alue karttaikkunasta sovellus tarkistaa, että rajaus on kokonaisuudessaan työalueella. Tuotantosuunnitelman alla ajoa ei voi suorittaa virheellisellä rajauksella. Näin minimoidaan mahdolliset joukkotoiminnot työalueiden ulkopuolelle. Jatkuvassa ajantasaistuksessa työalue laajenee ajon aikana, jos rajaus on työaluetta suurempi. Ajon lopuksi käyttäjälle ilmoitetaan karttalehdet, joille työalue on levinnyt ajon aikana.

39 Oman työalueen hahmottamisen helpottamiseksi käyttäjä voi Piirtämisen ohjauksen kautta piirrättää karttaikkunaan oman työalueensa reunan. Työalueenreuna piirtyy kartalle sinisellä viivalla ja puskurikarttalehdet korostuvat vaalean keltaisella (ks. kuva 8). Näin käyttäjä havaitsee karttaikkunassa visuaalisesti, milloin hän lähenee työalueensa reunaa. Työalueet -ikkunan kautta käyttäjä pysyy tarkastelemaan oman työnsä tietoja kuten esim. työn luonti- ja viimeisimmän muutostentuontipäivämäärän sekä paikantamaan ja korostamaan työalueensa. Oman työnsä lisäksi käyttäjä voi hakea ja tarkastella valitulta alueelta muita jatkuvan ajantasaistuksen ja/tai tuotantosuunnitelmien töitä sekä tuotantosuunnitelmia. Tutkimalla töitä ja tuotantosuunnitelmia esim. paikantamalla ja korostamalla niiden työalueita käyttäjä voi varmistaa, ettei hänen työskentely alueellansa samanaikaisesti työskentele muita. Myös myöhemmin esim. konfliktien havaitsemisen yhteydessä käyttäjä voi Työalueet -ikkunan avulla jäljittää konfliktien aiheuttajan. Konfliktien ratkaisemisen kannalta on usein tärkeää tietää, miten ja milloin konflikti on mahdollisesti syntynyt.

40 5 TIETOKANNAN VERSIOIDEN HALLINTA 5.1 Yleistä Yksi haastavimpia ongelmia paikkatietojärjestelmien kehittämisessä on ollut, kuinka mahdollistaa useamman käyttäjän samanaikainen työskentely jatkuvassa tietokannassa. On suhteellisen helppoa mahdollistaa tietokannasta lukeminen ja siihen kyselyiden suorittaminen samanaikaisesti useammalle käyttäjälle. On kuitenkin vaikeampaa välttää konflikteja ja säilyttää tietokannan eheys, kun useampi käyttäjä päivittää tietokantaa samanaikaisesti. (Longley et al. 2001) Tietokannan ajantasaistamiseen voidaan ottaa joko pessimistinen tai optimistinen lähestymistapa. Pessimistisessä lähestymistavassa käyttäjä lukitsee kaikki ne tietokannan kohteet, joita aikoo päivittää. Näin kukaan toinen käyttäjä ei voi samanaikaisesti päivittää samoja tietoja. Kun käyttäjä on saanut päivityksen valmiiksi, hän poistaa lukituksen. Optimistisessa lähestymistavassa tietoja ei lukita. Lähtökohtana on, ettei kukaan toinen päivitä samoja tietoja samaan aikaan käyttäjän kanssa. Käyttäjä päivittää tietojaan omassa transaktiossaan ja mahdolliset muutosten aiheuttamat konfliktit ratkaistaan vasta kun tiedot päivitetään päätietokantaan. (Newell 2003) Transaktio (tapahtuma) tarkoittaa johdonmukaista joukkoa tietokantamuutoksia. Kaikki transaktioon kuuluvat muutokset suoritetaan johdonmukaisesti alusta loppuun tai perutaan. (Longley et al. 2001) Transaktio on sarja tietokantaan tehtyjä muutoksia, joiden avulla tietokanta siirtyy ristiriidattomasta tilasta toiseen. Transaktion eri vaiheissa tietokannan ei tarvitse olla yhdenmukainen, kunhan se on sitä transaktion lopussa. (Date 1990) Jos kesken transaktion esim. havaitaan virhetilanne, perutaan kaikki transaktiossa tehdyt muutokset. Tämä tarkoittaa sitä, että jos yksikin transaktion operaatioista epäonnistuu, myös kaikki onnistuneet operaatiot perutaan.

41 5.1.1 Tietojen lukitseminen Monet tietokantaohjelmistot on suunniteltu käsittelemään vain nk. lyhyitä transaktioita, jotka kestävät yleensä pisimmillään vain sekunteja. Hyvä esimerkki tämän tyyppisestä lyhyestä transaktiosta on pankin tietojärjestelmässä rahan siirtäminen käyttötililtä säästötilille. Rahojen siirron ajaksi molemmat tilit lukitaan, jottei kukaan toinen pysty päivittämään niitä samanaikaisesti. Paikkatietojärjestelmille ominaisia ovat paljon pidemmät transaktiot. Kun pankin tietojärjestelmässä rahojen siirron transaktio kestää vain hyvin lyhyen ajan, niin GIS järjestelmissä voivat transaktiot pisimmillään kestää päiviä tai jopa viikkoja. Esim. tietojen lukitseminen näin pitkäksi aikaa on usein mahdotonta. (Batty et al. 2003) Kaupallisissa järjestelmissä yksi yleisimpiä tapoja hallita pitkiä transaktiota on nk. check-out menetelmä. Siinä käyttäjä kopioi haluamansa osan tietokannasta erilliseen tietokantaan tai tiedostoon, missä ylläpitotyö tehdään. Työn valmistuttua tiedot palautetaan takaisin tietokantaan. Ongelmana tässä ratkaisumallissa ovat mm. tietokannan kopioinnin hitaus ja rajoitettu työskentelyalue sekä kopioitavan aineiston yhteydet varsinaiseen tietokantaan. (Batty et al. 2003) Maagis/MTJ:ssä on käytössä tämän tyyppinen tietojenhallinta. Siinä tietokanta muodostuu 1 :10 000 -karttalehtijaon mukaisista tiedostoista, joita käyttäjät kopioivat itselleen ylläpitoa varten. 5.1.2 Versionhallinta Toinen lähestymistapa hallita pitkiä transaktioita on versionhallinta. JAKO/MTJ perustuu Smallworld GIS ohjelmistoon, jonka versionhallinta mahdollistaa useamman käyttäjän samanaikaisen työskentelyn tietokannassa. Ohjelmisto pystyy hallitsemaan lukuisia tietokannan eri versioita tallentamatta kuitenkaan samaa tietoa useampaan kertaan. Sen tietokannan puumaista rakennetta kutsutaan vaihtoehtohierarkiaksi. Tietokannan ylintä vaihtoehtoa kutsutaan päävaihtoehdoksi (top). Sen alla voi olla

42 useita alivaihtoehtoja, joilla puolestaan voi olla omia alivaihtoehtoja jne. (Batty et al. 2003) Kuva 12. Smallworld:n tietokannan versionhallinta. (Smallworld 2003) 5.1.2.1 Vaihtoehdot Smallworld:n versiohallitussa VMDS relaatiotietokannassa (Version Managed DataStore) vaihtoehdoilla (alternative) on tarkka hierarkkinen järjestys. Tietokannassa on aina ainakin yksi vaihtoehto, nk. päävaihtoehto (top alternative). Kaikilla muilla paitsi päävaihtoehdolla on aina yksi yksiselitteinen ylempi isävaihtoehto (parent alternative). Kullakin vaihtoehdoilla voi olla yksi tai useampi alivaihtoehto nk. lapsivaihtoehto (child alternative). Luotaessa uusi vaihtoehto siitä tulee aina nykyisen vaihtoehdon alivaihtoehto. Kukin alivaihtoehto (lapsi) on kuin kopio ylemmästä vaihtoehdosta (isä). Todellisuudessa alivaihtoehtoon tallennetaan kuitenkin vain käyttäjän vaihtoehdossa tietokantaan tekemät muutokset. Käyttäjä voi vaihtoehdossaan muokata koko tietokantaa ilman, että hänen tekemänsä muutokset näkyvät muille käyttäjille.

43 Vastaavasti muiden käyttäjien tekemät muutokset eivät näy käyttäjän vaihtoehtoon ennen kuin käyttäjä aloittaa vaihtoehtojen tietojen yhdistämisen. Kussakin vaihtoehdossa voi olla kerrallaan vain yksi käyttäjä kirjoitusoikeuksin muokkaamassa ja tallentamassa tietoja. Samanaikaisesti vaihtoehdossa voi kuitenkin olla useita muita käyttäjiä lukijoina. Lukijat voivat tarkastella vaihtoehdon tietoja, mutta eivät muokata niitä. 5.1.2.2 Versiot Versionhallinta antaa käyttäjälle mahdollisuuden muokata aineistoa ja tallentaa sitä uusiksi versioiksi. Työskentelyn aikana käyttäjän vaihtoehdossa tekemiä muutoksia pidetään väliaikaisina, kunnes hän vahvistaa (commit) tekemänsä muutokset. Vahvistettaessa muutokset tietokantaan syntyy aina uusi versio, joka ei koskaan muutu. Käyttäjän vahvistaessa seuraavan kerran tietokantaan tehdyt muutokset syntyy taas uusi versio. Käyttäjän viimeksi vahvistamaa versiota kutsutaan levyversioksi (disk version). Käyttäjä voi perua (rollback) edellisen tietokantaan vahvistamisen jälkeen tekemänsä muutokset ja palata näin levyversioon. Edellistä tietokantaan tekemäänsä vahvistusta (levyversiota) aikaisempaan versioon käyttäjä ei voi palata, ellei tietokantaan ole tehty varmistuspistettä (checkpoint). Varmistuspisteen voi luoda, kun se tuntuu tarpeelliselta. Käyttäjä voi palata varmistuspisteeseen aina halutessaan esimerkiksi virhetilanteen sattuessa, jolloin varmistuspisteen versiosta tulee uusi levyversio. Lukija tarkastelee vaihtoehdon sitä versiota, jonka oli käyttäjän levyversio lukijan siirtyessä vaihtoehtoon. Lukija saa käyttäjän uusimman levyversion käyttöönsä ajantasaistamalla vaihtoehdon (rollforward). Kuvassa 13 kuvataan käyttäjän työpäivän aikana tietokantaan tekemiä vahvistuksia. Työpäivän päätteeksi kello 16 käyttäjä voi palata kello 14 vahvistamaansa versioon (levyversio) yksinkertaisesti perumalla tietokantaan tekemänsä muutokset. Kello 10 vahvistettuun versioon käyttäjä voi palata versionhallinnan kautta palaamalla

44 varmistuspisteeseen, joka tehtiin klo 10. Versioihin, jotka ovat syntyneet kello 8, kello 11 ja kello 13, käyttäjä ei voi enää palata. Kuva 13. Esimerkki tietokantaan vahvistamisista työpäivän aikana. 5.1.3 Vaihtoehtojen tietojen yhdistäminen Vaihtoehtojen tietojen yhdistämisen käynnistää aina käyttäjä. Yhdistäminen tapahtuu aina vaihtoehdon ja sen isävaihtoehdon välillä. Käyttäjä tuo ensin isävaihtoehdossa tapahtuneet muutokset alas nykyiseen vaihtoehtoon komennolla Tuo muutokset (merge). Muutosten tuonnin jälkeen vaihtoehto sisältää kaikki isävaihtoehdon tiedot sekä vaihtoehdossa tehdyt muutokset. Käyttäjän vaihtoehdon muutokset viedään ylös isävaihtoehtoon komennolla Vie muutokset (post). Onnistuneiden muutosten tuonnin ja viennin jälkeen vaihtoehto on identtinen sen isävaihtoehdon kanssa.

45 Kuva 14. Isä- ja lapsivaihtoehtojen tietojen yhdistämisen vaiheet. Muutosten tuonti ja vienti voidaan suorittaa yhdellä komennolla Tuo ja vie muutokset (merge&post), joka on erillisiä komentoja nopeampi tapa yhdistää vaihtoehtojen tiedot. Yhden komennon käyttö ei kuitenkaan ole suositeltavaa, ellei tiedetä isävaihtoehdon olevan muuttumaton, tai jos käyttäjä on aivan varma, ettei muutosten yhdistäminen aiheuta konflikteja. Jos muutosten yhdistäminen suoritetaan yhdellä komennolla ja muutosten tuonnissa sovellus havaitsee konfliktin (ks. luku 5.1.4), se ilmoittaa kyllä käyttäjälle konfliktista, muttei anna tälle mahdollisuutta itse ratkaista konflikteja. Jos isävaihtoehdolla on useampi lapsivaihtoehto, vaatii lapsivaihtoehtojen yhdistäminen sarjan muutosten tuonteja ja vientejä. Tästä esimerkki esitetään kuvassa 15. Yhdistäminen aloitetaan yleensä aina muutosten tuonnilla vaihtoehtoon, jonka jälkeen vaihtoehdon muutokset viedään ylös. Muutosten vienti onnistuu ainoastaan silloin, jos isävaihtoehto ei ole muuttunut edellisen muutosten tuonnin jälkeen tai vastaavasti sen jälkeen kun lapsivaihtoehto on luotu. Käytännössä tämä tarkoittaa, että muutokset on aina ensin tuotava vaihtoehtoon ennen kuin muutosten vienti onnistuu.

46 Kuva 15. Kahden alivaihtoehdon muutosten yhdistäminen. JAKO/MTJ:n kaksitasoinen hierarkia mahdollistaa tuotantosuunnitelman alaisissa töissä työskentelyn ja näiden töiden tietojen yhdistämisen ennen kuin muutoksia viedään rekisteriin asti. Näin voidaan esim. perusparantaa koko tuotantosuunnitelman alue alusta loppuun, ennen kuin perusparannettu alue yhdistetään rekisterin (top) aineistoon. 5.1.4 Konfliktit Versionhallinnan etuna on, että käyttäjällä on aina vaihtoehdossaan käytettävissään koko tietokanta eikä hänen tarvitse lukita käsittelemiänsä tietoja. Samalla järjestelmä kuitenkin mahdollistaa saman kohteen samanaikaisen muokkaamisen eri

47 vaihtoehdoissa. Jos samaa kohdetta on muokattu eri vaihtoehdoissa, muutosten tuonnin yhteydessä havaitaan konflikti. Pelkkä kohteen muokkaaminen eri vaihtoehdoissa ei vielä konfliktiin riitä, vaan kohteen tulee myös erota toisistaan isä- ja lapsivaihtoehdossa. Konfliktin aiheuttamaa muutosta ei aina ole välttämättä tehty suoraan isä- tai lapsivaihtoehtoon. Vaihtoehdot ovat voineet päivittyä konfliktoivasti, kun niihin on yhdistetty muiden vaihtoehtojen muutoksia. Tästä esimerkki kuvassa 16. Kuva 16. Vaihtoehtojen yhdistämisessä konflikti.

48 Jos muutosten tuonnin yhteydessä havaitaan konflikteja, on konfliktit ratkaistava konfliktissa oleva kohteen isä-, lapsi- tai perusversiolla, ennen kuin muutosten tuonti saatetaan loppuun. Isäversio Kohteen versio isävaihtoehdossa muutosten tuonnin alkaessa. Lapsiversio Kohteen versio nykyisessä vaihtoehdossa muutosten tuonnin alkaessa. Perusversio Kohteen versio nykyisessä vaihtoehdossa edellisen muutosten tuonnin jälkeen tai, jos muutoksia ei ole aikaisemmin tuotu, niin kohteen versio vaihtoehdon luontihetkellä. Kohteen isä- ja lapsiversio ovat helppoja hahmottaa. Isäversio on kohde sellaisena kuin se on isävaihtoehdossa. Lapsiversio on taas kohde lapsivaihtoehdossa eli vaihtoehdossa, johon muutokset tuodaan. Kohteen perusversiota (base version) ei ole niin helppo hahmottaa, koska sitä ei periaatteessa enää ole missään vaihtoehdoista. Perusversio on eräänlainen kohteen isä- ja lapsiversioiden yhteinen esi-isä. Se on kohteen versio vaihtoehdossa edellisten tietojen yhdistämisen eli muutosten tuonnin jälkeen. Tällöin kohteen isä- ja lapsiversio ovat olleet identtisiä. Jos vaihtoehtoon ei ole aikaisemmin tuotu muutoksia, perusversio kuvaa kohdetta vaihtoehdon luontihetkellä. Jos tietojen yhdistämisessä yhdellä komennolla Tuo ja vie muutokset (ks. luku 5.1.3) havaitaan konflikteja, ei käyttäjä pääse vaikuttamaan konfliktien ratkaisuun. Konflikteista kyllä varoitetaan käyttäjää, mutta ohjelmisto ratkoo kaikki konfliktit automaattisesti kohteiden lapsiversiolla. Pääsääntöisesti käyttäjä ratkoo konfliktit kohde kerrallaan. Jos konfliktissa oleva kohde on kuitenkin osa isompaa rakennetta, tällöin kaikki rakenteeseen liittyvät kohteet on aina korvattava samalla versiolla. JAKO/MTJ:ssä tällaiset rakenteet syntyvät

49 pääsääntöisesti topologian kautta. Esimerkiksi korvattaessa konfliktissa oleva pelto sen isäversiolla niin myös mahdollisesti konfliktissa olevat pellon reunaviivat (maastokuvion reunat) on korvattava isäversiolla. Käyttäjä ei siis voi valita konfliktissa olevista reunaviivoista yhtä kerrallaan ja päättää millä versiolla hän sen korvaa. Ohjelma vaatii käyttäjää korvaamaan kaikki reunaviivat aina samalla versiolla, koska se pyrkii pitämään sovelluksen topologisen rakenteen hallinnassa.

50 6 KONFLIKTIEN RATKAISEMINEN 6.1 Konflikti Kohde on konfliktissa silloin, kun se on muuttunut sekä isä- että lapsivaihtoehdossa. Mahdolliset konfliktit havaitaan muutosten tuonnin yhteydessä isä- ja lapsivaihtoehdon välillä. Kohteen muuttuminen havaitaan sen muuttuneesta versioleimasta (version stamp), joka päivittyy automaattisesti aina kohdetta muokattaessa. Jos muutosten tuonnissa havaitaan kohteen versioleiman muuttunen sekä isä- että lapsivaihtoehdossa, ohjelmisto tarkastaa, onko kohde mahdollisesti konfliktissa. Pelkkä kohteen muuttaminen eri vaihtoehdoissa ei konfliktiin vielä riitä, vaan kohteen isä- ja lapsiversion tulee myös erota toisistaan. Ohjelmiston itse generoimat muutokset kohteissa, kuten esim. versioleiman muutos, eivät vielä aiheuta konfliktia. Konfliktiin tarvitaan olennainen muutos (material change) joko kohteen geometriassa tai nk. merkitsevissä attribuuteissa. Kohteen merkitsevillä attribuuteilla tarkoitetaan konfliktien ratkaisussa tutkittavia attribuutteja. Jos vain kohteen muissa kuin merkitsevissä attribuuteissa on eroja, ei kohde ole konfliktissa, vaikka se olisikin muuttunut sekä isä- että lapsiversiossa. Konfliktittoman kohteen tuonnissa voimaan jää sen lapsiversio. JAKO/MTJ:ssä on määritelty geometriatyypeittäin konfliktien tarkastelun ulkopuolelle jätettävät attribuuttikentät. Nämä attribuutit on kuvattu kuvassa 17. Kohteiden versioleiman (ds!version) sekä alku- ja loppupäivämäärien muutokset kohteille generoi aina sovellus. Vastaavasti kohteiden tarkkuudet (sijainti- ja korkeustarkkuus) määräytyvät ylläpidossa käytetyn aineiston ja laitteiston mukaan. Koska käyttäjä ei suoraan pääse näitä arvoja muuttamaan, voidaan niitä käsitellä ei-merkitsevinä attribuutteina.

51 Viivakohteet Symbolikohteet Tekstikohteet Aluekohteet :ds!version :alkupvm :loppupvm :sijaintitarkkuusluokkakoodi :korkeustarkkuusluokkakoodi :ds!version :alkupvm :loppupvm :sijaintitarkkuusluokkakoodi :korkeustarkkuusluokkakoodi :ds!version :alkupvm :loppupvm :sijaintitarkkuusluokkakoodi :ds!version :alkupvm :loppupvm :sijaintitarkkuusluokkakoodi Kuva 17. Kohteiden attribuutit, joiden muutos ei aiheuta konfliktia. (Räsänen 2001) 6.2 Konfliktin leviäminen topologian kautta Konfliktien käsittelyssä puhutaan suorista ja topologian kautta levinneistä konflikteista. Jos kohde on suorassa konfliktissa, se on muuttunut sekä isä- että lapsiversiossa. Yleensä konflikteista puhuttaessa tarkoitetaan juuri näitä suoria konflikteja. Topologian kautta levinneessä konfliktissa kohteen isä- tai lapsiversioista on todellisuudessa muuttunut vain toinen. Se versioista, joka on muuttumaton on siis edelleen samanlainen kuin kohteen perusversio.

52 Topologian kautta konfliktiin joutunut kohde on osa topologista rakennetta, jonka joku osa on suorassa konfliktissa. Konfliktit eivät siis voi levitä kohteisiin, joilla on yksinkertainen geometria eikä siis lainkaan topologiaa. Konfliktit leviävät versiossa muuttuneiden solmujen ja linkkien kautta. Konfliktien leviäminen pysähtyy vasta kun topologisesta verkostosta löytyy versiossa muuttumaton solmu tai solmu, joka on samassa kohdassa sekä isä- että lapsiversiossa. Kohteen poistaminen versiossa, jossa leviämistä tutkitaan, pysäyttää myös konfliktin leviämisen. Kohteet, joiden kautta leviäminen kulkee, ovat nyt topologiansa kautta konfliktissa. Topologian kautta konflikti voi levitä myös versiossa lisättyyn kohteeseen. Vaikkei kohteella olekaan muita versioita se on silti osa topologista rakennetta ja siksi konfliktissa. Käyttäjille topologian kautta levinneet konfliktit ovat vaikeita käsittää, sillä tällöin konfliktissa olevan kohteen isä- ja lapsiversioista vain toinen on muuttunut. Topologian kautta levinnyt konflikti näkyy käyttäjälle aivan kuten suora konflikti eikä käyttäjällä monestikaan ole mahdollisuutta saada selville, mikä tai mitkä konfliktissa olevista kohteista olivat alun perin suorassa konfliktissa ja aiheuttivat konfliktien leviämisen topologian kautta muihin kohteisiin. 6.3 Smallworld:n konfliktien ratkaisu Muutosten tuonnin yhteydessä konfliktien ratkaisemista valvotaan tietokantanäkymän konfliktimoodilla. Konfliktissa olevat kohteet voidaan pakottaa muutosten tuonnin yhteydessä automaattisesti joko niiden lapsi-, isä- tai perusversion mukaisiksi tai konfliktien ratkaiseminen voidaan jättää käyttäjälle. Smallworld:n GIS -tietokannassa mahdolliset konfliktit ratkoo käyttäjä. Konflikti -ikkunassa käyttäjä voi konflikti kerrallaan päättää, suoritetaanko korvaaminen kohteen perusversiolla vai isä- tai lapsiversion levyversiolla.

53 6.3.1 Konflikti -ikkuna Konflikti -ikkuna avautuu automaattisesti, jos sovellus havaitsee konflikteja muutosten tuonnin yhteydessä. Jokainen konfliktissa oleva kohde lisätään Konflikti -ikkunan listaan, josta käyttäjä voi valita konfliktin ratkaisua varten yhden tai useampia kohteita kerrallaan. Kuva 18. Konflikti ikkuna. Kukin konflikti kohde voidaan ratkaista yhdellä sen kolmesta versioista: Lapsiversio on kohde nykyisessä vaihtoehdossa muutosten tuonnin alkaessa. Isäversio on kohde isävaihtoehdossa muutosten tuonnin alkaessa.

54 Perusversio on isä- ja lapsiversion yhteinen esi-isä eli kohde lapsivaihtoehdossa edellisen muutosten tuonnin jälkeen tai kohde lapsivaihtoehdon luonti hetkellä. Näiden kolmen version lisäksi Konflikti -ikkunalla voidaan tarkastella myös kohteen nykyversiota. Nykyversio on kohteen versio, jonka käyttäjä näkee karttaikkunassa ja jota hän voi muokata esim. kohdeikkunalla. Korvattaessa kohde, joko sen lapsi-, isä- tai perusversiolla, tästä versiosta tulee uusi nykyversio. Konfliktissa olevan kohteen eri versioita voi Konflikti -ikkunalla tutkia paikantamalla ja korostamalla niitä. Käyttäjä saa Konflikti -ikkunasta avattua lisätietoja -ikkunan, josta hän näkee mitkä kohteen ominaisuudet ovat versioissa muuttuneet ja miten muuttuneet ominaisuudet eroavat toisistaan. Tietojen avulla käyttäjä tekee valinnan, millä kohteen versioista hän korvauksen suorittaa. Hyväksyttäessä lopuksi konfliktien ratkaisu (Suorita) kaikkien konfliktissa olevien kohteiden nykyversiot jäävät voimaan. Jos käyttäjä ei halua suorittaa konfliktien ratkaisua, hän voi perua muutosten tuonnin. Alivaihtoehto palautuu siihen tilaan, jossa se oli ennen muutosten tuontia. Konfliktit tulevat uudelleen ratkaistaviksi, kun käyttäjä seuraavan kerran tuo muutokset vaihtoehtoonsa.

55 Kuva 19. Lisätietoja -ikkuna. 6.3.2 Ongelmat Konflikti -ikkunalla konfliktien ratkaisu toimii hyvin silloin, kun on kyse muutamasta konfliktissa olevasta kohteesta. Jos kohteita on useampia kymmeniä tai jos konfliktit

56 lähtevät leviämään topologian kautta, konfliktien ratkaiseminen Konflikti -ikkunalla ei välttämättä onnistu hallitusti. Suurin ongelma JAKO/MTJ:ssä on konfliktien leviäminen topologian kautta. Ohjelmisto pyrkii pitämään ratkaisun aikana tietokannan rakenteet koossa eikä tällöin salli yksittäisen kohteen korvaamista ilman, että siihen liittyvät muut kohteet korvataan samalla versiolla. Riippuen versiosta, jolla käyttäjä kohteen korvaamisen suorittaa, ohjelmisto saattaa tuoda korvaamisen yhteydessä uusia kohteita konfliktilistaan. Uudet kohteet eivät ole alunperin suorassa konfliktissa, mutta ne täytyy lisätä ratkaistavien kohteiden joukkoon, jotta tietokannan eheys saadaan säilytettyä. Koska ohjelmisto ei salli hybridiratkaisuja, ei käyttäjä aina voi korvata kaikkia kohteita haluamillaan versiolla. Tilanteen tekee vielä ongelmallisemmaksi se, ettei käyttäjä aina voi edes olla varma, millä versiolla yksittäinen kohde loppujen lopuksi on ratkaistu. Ongelma ilmenee käyttäjälle seuraavasti: Käyttäjä valitsee Konflikti -ikkunan listalta ratkaistavan kohteen ja tekee päätöksen, millä kohteen versioista hän korvaamisen suorittaa. Käyttäjän tehdessä korvaamisen ohjelma tarkastaa korvattavan kohteen rakenteen. Ohjelma valitsee automaattisesti listalta kaikki ne kohteet, jotka kuuluvat samaan rakenteeseen ja asettaa ne valituksi. Tarvittaessa listaan haetaan uusia kohteita, jotka tulee myös korvata valitulla versiolla. Ohjelma ilmoittaa käyttäjälle, ettei korvaamista ole suoritettu ja että korvaaminen tulee suorittaa uudelleen kaikille valituille kohteille. Käyttäjä voi suorittaa nyt korvaamisen uudelleen. Käyttäjä on nyt suorittanut useamman kohteen korvaamisen, mutta Konflikti -ikkunan listasta ei käy selville, mitkä kohteista on jo korvattu ja millä versiolla kohteen korvaaminen on tapahtunut. Listassa kohteesta ei käyttäjälle näy suoraan muuta kuin mistä kohdeluokan kohteesta on kysymys. Lisäksi ohjelman hakiessa listaan uusia kohteita muuttuu listassa olevien kohteiden järjestys. Käyttäjä ei pysty hallitsemaan, mitä kohteita hän on jo käynyt läpi ja mitkä ovat vielä jäljellä.

57 Riippuen versiosta, jolla käyttäjä korvaamisen suorittaa, kohteeseen liittyvät kohteet vaihtelevat. Näin kohde saattaa korvaantua liittyvänä kohteena ensin esim. lapsiversiolla ja myöhemmin johonkin toiseen kohteeseen liittyvänä kohteena isäversiolla. Millä versiolla korvaaminen on loppujen lopuksi tapahtunut, on useissa tapauksissa hankala selvittää. Toinen suuri ongelma konfliktien ratkaisemisessa on aika. Konfliktit tulisi ratkaista aina sen istunnon aikana, jossa ne havaitaan. Käytännössä isojen konfliktimäärien läpikäynti ei kuitenkaan onnistu yhden istunnon aikana. Kohteiden riippuvuudet toisistaan sekä käytettävissä olevan ajan rajallisuus on johtanut siihen, että konfliktien ratkaisussa on jouduttu suorittamaan joukkoratkaisuja. Käytännössä tämä tarkoittaa sitä, että kohderyhmä kerrallaan on jouduttu päättämään versio, jolla korvaaminen suoritetaan. Konflikti -ikkunan listasta on valittu kaikki kohderyhmän kohteet ja korvattu kaikki valitut kohteet kerralla. Joukkoratkaisut aikaansaavat sen, ettei tietokanta ole siinä kunnossa kun sen pitäisi olla konfliktien ratkaisun jälkeen. Konfliktissa olleet kohteet on varmuuden vuoksi käytävä uudelleen läpi ja tarvittaessa korjattava. Ongelmana on, ettei käyttäjälle jää tietoa kohteista, jotka ovat olleet konfliktissa. Tieto puuttuu myös siitä, miksi kohde on ollut konfliktissa. Lopputuloksena on, että joukkoratkaisut hävittävät osan tallennettua tietoa, eikä aina pystytä sanomaan mitä tietoa on menetetty. 6.4 Konfliktien ratkaiseminen JAKO/Maastotietojärjestelmässä Konfliktien ratkominen JAKO/MTJ:ssä perustuu Smallworld:n omaan konfliktien käsittelyn periaatteeseen. Konfliktien ratkominen suoritetaan JAKO/MTJ:ssä automaattisesti, mutta tarvittaessa konfliktikohteista luodaan nk. sovitettava kohde. Muutosten tuonnin jälkeen käyttäjä käy läpi kaikki sovitettavat kohteet.

58 6.4.1 Automaattinen ratkaiseminen Konfliktien automaattisessa ratkaisemisessa JAKO/MTJ käyttää hyväksi Konflikti - ikkunan metodeita. Kun muutosten tuonnin yhteydessä havaitaan konflikteja, Konflikti -ikkuna avautuu. Konfliktissa olevat kohteet tulevat normaalisti ikkunan listaan, mutta kaikki painikkeet asetetaan harmaiksi. Näin käyttäjä ei pääse käyttämään Konflikti -ikkunaa. Konfliktien ratkaiseminen suoritetaan taustalla ja Konflikti - ikkunalle annetaan komennot suoraan ohjelmakoodilla. Konfliktissa olevien kohteiden rakenteiden takia ei konfliktien ratkaisua voida tehdä kohde kerrallaan. Koska toisiinsa liittyvät kohteet on aina korvattava samalla versiolla, joudutaan myös automaattisessa ratkaisussa päätymään joukkokorvaamisiin. Koska ei haluta menettää mitään toisten käyttäjien toisissa vaihtoehdoissa tekemiä muutoksia, suoritetaan konfliktien ratkaiseminen aina kohteiden isäversiolla. 6.4.2 Sovitettavat kohteet Korvattaessa kaikki konfliktikohteet näiden isäversioilla menetetään tieto kohteiden muiden versioiden ominaisuuksista. Tärkein näistä versioista on lapsiversio, josta käy ilmi, millainen kohde oli vaihtoehdossa ennen muutosten tuonnin alkua. Vertailemalla toisiinsa kohteen isä- ja lapsiversiota voidaan pääsääntöisesti päätellä millainen kohteen tulisi olla. Jotta tieto lapsiversion ominaisuuksista säilyisi automaattisen ratkaisun yhteydessä, tehdään lapsiversiosta tarvittaessa sovitettava kohde. Sovitettava kohde on muuten samanlainen kohde kuin lapsiversion kohde, mutta sen geometria on nk. epäselvässä geometriakentässä. Epäselvässä geometriakentässä olevalla kohteella ei ole topologiaa ja se piirtyy karttaikkunaan eri tyylillä. Vertaamalla sovitettavaa kohdetta todelliseen tietokannassa olevaan kohteeseen (nykykohde) käyttäjä tekee päätöksen, kumpi kahdesta kohteesta on oikea ja sovittaa kohteen.

59 6.4.2.1 Milloin luodaan sovitettava kohde? Kaikista konfliktissa olevista kohteista ei aina luoda sovitettavaa kohdetta. Sovitettavaa kohdetta ei luoda silloin, kun voidaan olla varmoja, että isävaihtoehdon versio on oikein eikä sitä ole tarpeen verrata kohteen lapsiversioon. Säännöt, joiden perusteella sovitettava kohde luodaan, ovat erilaiset alue, piste ja viiva geometrioille. Aluekohteiden käsittely eroaa muista kohteista siinä, ettei niistä koskaan luoda sovitettavaa kohdetta. Alueiden konfliktit aiheutuvat yleensä aluegeometrioiden muutoksista, jotka puolestaan aiheutuvat alueen reunaviivojen muutoksista. Alueen geometria korjaantuu sen reunaviivojen sovittamisen yhteydessä. Versioiden vertailu on alueiden osalta tältä osin turhaa. Jos aluekohde on lisätty lapsiversiossa (sekä kohteen perus- että isäversio puuttuu), muodostetaan aluekohteesta aluetunnuspiste. Näin varmistetaan, ettei alue jää vahingossa kokonaan pois tietokannasta. Jos aluekohteen konflikti ei ole aiheuttanut muutoksesta kohteen aluegeometriassa vaan muutos on tapahtunut merkitsevissä attribuuteissa (vrt. ei-merkitsevät attribuutit kuva 17), menetetään tieto muutoksesta, joka oli syynä konfliktiin. Sovitettavaa kohdetta ei muodosteta kohteesta, joka on kokonaan vaihtoehdon työalueen (ks. luku 4.3) ulkopuolella. JAKO/MTJ:ssä laajennetaan työaluetta aina, kun käyttäjä muuttaa kohdetta, joka on kokonaan työalueen ulkopuolella. Jos siis konfliktissa olevan kohde on kokonaan työalueen ulkopuolella, sitä ei ole muokattu lainkaan lapsivaihtoehdossa. Konflikti on syntynyt topologian kautta ja kohde on muuttunut vain isävaihtoehdossa, joten sovitettava kohde on tarpeeton. Symboli- ja tekstikohteilla muodostetaan sovitettava kohde, jos kohteen isäversio on poistettu. Näin tietokantaan jää jälki lapsivaihtoehdon kohteesta, joka poistuu automaattiratkaisun aikana. Sovitettava kohde tehdään myös, jos versioiden merkitsevissä attribuuteissa on eroja tai jos versioiden tasogeometriat eroavat toisistaan. Viivakohteilla sovitettava luodaan, jos konfliktikohde on lisätty lapsivaihtoehtoon. Jos kohde on poistettu isävaihtoehdosta ja sitä on muokattu lapsivaihtoehdossa niin,

60 että sen merkitsevissä attribuuteissa tai tasosijainnissa on tapahtunut muutoksia, luodaan sovitettava kohde. Sovitettava kohde luodaan myös, jos lapsiversio on muuttunut niin, että lapsi- ja isäversioiden merkitsevissä attribuuteissa tai tasosijainneissa on eroja. Jos isäversio on muuttunut ja lapsiversio on poistettu, luodaan sovitettava kohteen perusversiosta. Tarkasteltaessa versioiden geometrioita ei z-koordinaattien muutoksia pidetä niin merkittävinä, että niiden katsottaisiin aiheuttavan kohteelle konfliktin. Jos versioiden geometriat eroavat ainoastaan korkeudeltaan, on versioiden välinen muutos syntynyt todennäköisesti korkeuksien ajon aikana eikä vuorovaikutteisessa työskentelyssä. Vuorovaikutteinen työskentely aiheuttaa yleensä muutoksia myös kohteen tasosijainnissa. Koska prosesseissa ajetaan aina uudelleen kohteille korkeudet korkeusmallista, ei menetetä korvaamatonta tietoa, vaikka geometrioiden z-koordinaattien muutoksista ei konfliktien ratkaisemisen yhteydessä välitetäkään. 6.4.2.2 Sovittaminen Sovitettavat kohteet on käytävä läpi ja sovitettava, ennen kuin vaihtoehto (työ tai tuotantosuunnitelma) voidaan rekisteröidä. Sovittaminen tapahtuu erillisellä työkalulla (kuva 20), joka hakee kaikki karttaikkunassa näkyvät sovitettavat kohteet työkalun ylempään listaikkunaan. Käyttäjä valitsee listalta yhden kohteen, jonka haluaa sovittaa. Työkalu vertaa sovitettavaa kohdetta ja sitä vastaavaa nykykohdetta toisiinsa. Alempaan listaikkunaan päivittyvät kohteiden toisistaan eroavat attribuuttikentät ja näiden attribuuttien arvot. Listassa tähdellä merkityt kentät kuvaavat sovitettavan kohteen arvoja. Käyttäjä voi paikantaa ja korostaa sekä sovitettavan että nykykohteen. Kohteita korostamalla ja ominaisuuksia vertaamalla käyttäjä tekee päätöksen miten kohde sovitetaan. Sovittamisessa sovitettava kohde joko poistetaan turhana, lisätään uutena nykykohteena tai korvataan kannassa oleva nykykohde sovitettavalla kohteella.

61 Kuva 20. Sovitettavien kohteiden sovittamistyökalu. Korvaaminen on sovittamistavoista yleisin. Korvaamisessa kannassa oleva nykykohde päivitetään sovitettavan kohteen ominaisuuksilla. Tämän jälkeen sovitettava kohde tuhotaan. Korvaamisen yhteydessä käyttäjä voi valita, käytetäänkö korvaamisessa sovitettavan kohteen vai nykykohteen attribuutteja. Attribuutin vaihdon voi suorittaa klikkaamalla alemmasta listaikkunasta sitä nykykohteen attribuutin arvoa, jonka haluaa korvaamisessa säilyttää. Ainoastaan sijainti- ja korkeustarkkuudet ovat arvoja, joita ei voi valita. Jos käyttäjä vaihtaa kohteen attribuuttien arvoja, korvaamisessa syntyy eräänlainen hybridiversio, joka normaalissa konfliktien ratkaisussa on mahdoton.

62 Sovitettava kohde lisätään tietokantaan, jos sitä vastaavaa nykykohdetta ei ole olemassa ja jos kohteen todella kuuluisi olla kannassa. Lisäys voidaan suorittaa myös siinä tapauksessa, että sovitettavalla kohteella on sitä vastaava nykykohde, mutta molemmat kohteet tulisi olla kannassa. Poistettaessa tuhotaan sovitettava kohde tietokannasta. Sovitettava kohde poistetaan tietokannasta, jos siihen verrattava nykykohde on kunnossa eikä korvaamista ole tarpeen suorittaa. Jos sovitettavalla kohteella ei ole nykykohdetta, johon verrata eikä sovitettavaa kohdetta ole tarpeen lisätä nykykohteena tietokantaan, poistetaan sovitettava. 6.4.3 Ongelmat 6.4.3.1 Sovitettavien lukumäärä Konfliktitapauksissa sovitettavien lukumäärä on suoraan verrannollinen vaihtoehdossa tehtyihin muutoksiin. Konfliktien mahdollinen leviäminen isävaihtoehdossa ei vaikuta sovitettavien kohteiden lukumäärään. Suorassa konfliktissa saattaa alun perin olla vain muutama kohde, mutta vaihtoehdossa tehtyjen muutosten lukumäärä saattaa nostaa sovitettavien kohteiden lukumäärän kymmenistä jopa satoihin kohteisiin. Ongelma ei ole niin suuri töissä kuin tuotantosuunnitelmissa, joissa esim. perusparannusprosessissa on tehty paljon muutoksia laajalle alueelle. Hyvä esimerkki konfliktien leviämisestä rekisterin ja tuotantosuunnitelmien välillä on Varsinais-Suomen maanmittaustoimiston perusparannuksen tuotantosuunnitelma 1653. Tuotantosuunnitelmaan muutoksia tuotaessa havaittiin konflikti ja sovitettavia kohteita syntyi kaikkiaan 1462 kpl. Tapauksen tarkempi tutkiminen kuitenkin paljasti, että alun perin suorassa konfliktissa oli ollut vain yksi maastokuvion reuna. Tälle maastokuvion reunalle oli rekisterissä laskettu uusi kartografinen koodi. Tuotantosuunnitelmassa kohteelle oli laskettu uusi kartografinen koodi ja sen sijaintia oli muutettu. Liittyviin

63 kohteisiin (1461 kpl) oli koskettu ainoastaan tuotantosuunnitelmassa, mutta silti niistä kaikista luotiin sovitettavat kohteet. Tässä tapauksessa muutosten tuonnin peruminen, muutosten tuonti uudelleen Smallworld:n vakio konfliktien ratkaisulla ja maastokuvion reunan konfliktin ratkaiseminen sen lapsiversiolla ei aiheuttanut lainkaan konfliktin leviämistä. Sovitettavien suuret lukumäärät ovat aiheuttavat usein käyttäjille tunteen, että heidän täytyy tehdä työnsä uudelleen. Pahimmissa tapauksissa suurin osa käyttäjän muokkaamista kohteista palautuu alkuperäiseen muotoonsa ja hänen tekemistään muutoksista tulee sovitettavia kohteita. 6.4.3.2 Sovittaminen kohde kerrallaan Konfliktien leviämisen kautta syntyneet sovitettavat kohteet sovitetaan yleensä korvaamalla nykykohde sovitettavalla kohteella. Jos sovitettavia kohteita on paljon ja käyttäjä voi päätellä niiden syntyneen topologian kautta, olisi useamman kohteen korvaaminen samalla kertaa mielekästä. Ongelmana on kuitenkin kohteiden sovittamisjärjestys. Sovitettaessa kohteita käyttäjä ei voi suoraviivaisesti valita kohteita järjestyksessä sovitettavien listalta. Kohteiden sovittamisjärjestykseen vaikuttaa niiden sijainti kartalla. Sovitettaessa kohdetta on otettava huomioon niin muut sovitettavat kohteet kuin nykykohteetkin. Jos käyttäjä ei ole tarkkana kohteiden sovittamisjärjestyksen kanssa, hän saa helposti aikaa topologiasääntöjen takia pilkkoutuneita viivoja. Korvattaessa tai lisättäessä sovitettava kohde on käyttäjän tarkastettava, ettei sovitettavan geometrian alla ole saman topologiatason nykykohdetta. Jos sovitettavan alla on nykykohde, tämän geometria pilkkoutuu topologiasääntöjen takia. Kuvassa 21 sovitettavat maastokuvion reunaviivat kuvautuvat kartalle ohuina sinertävinä viivoina. Nykykohteet näkyvät kartalla mustina viivoina. Kartalle on korostettu punaisella konfliktissa olleen maastokuvion reunan nykyversio ja turkoosilla sitä vastaava sovitettava kohde.

Kuva 21. Sovitettavia ja nykykohteita. 64

65 7 JATKOKEHITTÄMINEN Konfliktien automaattinen ratkaiseminen JAKO/MTJ:ssä toimii tällä hetkellä, mutta sovitettavien kohteiden suuri lukumäärä koetaan käyttäjien taholta usein turhauttavaksi. Vaikka konfliktien välttämiseksi töiden organisointia on jatkuvasti kehitetty, niin konfliktitapausten lukumäärää ei enää pystytä pienentämään. Seuraavassa vaiheessa konfliktienhallinnan kehittämissä tulisi pyrkiä lisäämään automatiikkaa ja päättelyä, jotta käyttäjälle jäävä jälkikäsittelyn työmäärä vähenisi. 7.1 Vahvempi versio Tällä hetkellä kaikki konfliktissa olevat kohteet korvataan aina samalla versiolla. Samaa versiota on käytettävä, jotta kohteiden topologiset rakenteet pysyvät kunnossa. Jottei konfliktien ratkaisussa menetettäisi toisten käyttäjien tietokantaan tekemiä muutoksia, tapahtuu konfliktien ratkaiseminen aina kohteiden isäversioilla. Ei-topologisilla kohteilla ei tällaista kohteita yhdistävää topologista rakennetta ole. Ne eivät siis myöskään voi levitä topologian kautta konfliktiin vaan ovat aina suorassa konfliktissa. Näillä kohteilla voitaisiin siis aina valita vapaasti versio, jolla kunkin kohteen korvaaminen suoritetaan. Korvaaminen tulisi tällöin tehdä versiolla, joka voidaan ominaisuuksiensa puolesta katsoa vahvemmaksi. Ratkaisevin ominaisuus kohteella on tavallisesti sen sijaintitarkkuus. Jos kohteen versioissa ei ole merkitsevissä attribuuteissa eikä tasogeometriassa eroja, vahvempi versio määräytyy versoiden sijainti- tai korkeustarkkuuden mukaan. Mutta entä jos kohteen versioiden tasosijainneissa on eroja? Voidaanko tällöinkin määritellä vahvempi versio tarkkuuksien perusteella? Voidaanko päätellä, että tarkemmalla aineistolla tehty muutos on aina oikeampi? Vahvemman version päättely esim. symboleille olisi kannattavaa ja vähentäisi käyttäjien työmäärää, mutta vaatii tarkan selvityksen, millaisia tarkkuuksia kohteet saavat prosessien eri vaiheissa.

66 7.2 Konfliktien leviämisen pysäyttäminen Sovitettavien kohteiden lukumäärää pystytään tehokkaasti pienentämään ainoastaan pyrkimällä katkaisemaan konfliktien leviäminen topologian kautta. Topologian kautta konfliktien leviäminen jatkuu tarkasteltavassa versiossa kunnes tullaan solmuun, joka sijainti on sama sekä isä- että lapsiversiossa. Vastaavasti myös kohteen poistaminen versiossa, jossa konflikti leviää (JAKO/MTJ:ssä aina lapsiversio), pysäyttää leviämisen. Vanhamaa (Vanhamaa 2003) on esittänyt seuraavan ratkaisumallin, jolla konfliktien leviäminen todennäköisesti voidaan suurelta osin pysäyttää. Vanhamaan ratkaisumalli perustuu konfliktissa olevien kohteiden esikäsittelyyn ennen varsinaista muutosten tuontia lapsivaihtoehtoon. Mallissa tutkitaan kohteiden isä-, lapsija perusversioiden eroja ja haetaan mahdollisesti konfliktissa olevat kohteet esikäsittelyä varten. Esikäsittelyn ensimmäisessä vaiheessa haetaan aluekohteet, joissa versiot eroavat toisistaan ja joiden lapsiversio on vielä olemassa. Pudotetaan kaikkien haussa löytyneiden alueiden aluegeometriat pois (aluetunnuspisteet jäävät tietokantaan). Seuraavaksi haetaan kaikki topologiset viivakohteet, jotka ovat suorassa konfliktissa ja joiden lapsiversiota ei ole poistettu kannasta. Haetaan edelleen näiden viivakohteiden solmut, jotka ovat eroavat toisistaan isä- ja lapsiversioissa. Haetaan näihin solmuihin topologisesti liittyvät viiva- ja pistekohteet. Muodostetaan löytyneistä kohteista uudet sovitettavat kohteet ja poistetaan vanhat kohteet tietokannasta. Samalla myös poistettuihin viivoihin linkittyneet alueet putoavat pois. Vasta näiden operaatioiden jälkeen tuodaan muutokset vaihtoehtoon. Muutosten tuonnin yhteydessä havaitut aluekohteiden konfliktit ratkaistaan lapsiversiolla, joilla ei esikäsittelyn jälkeen enää ole alue geometriaa. Näin konfliktit eivät voi lähteä leviämään alueiden kautta. Muiden kuin aluekohteiden konfliktit ratkaistaan isäversiolla. Jos isäversiolla korvatun kohteen lapsiversiota ei ole poistettu tietokannasta, kyseessä on

67 ei-topologien kohde tai kohde, joka ei ole suorassa konfliktissa (näitä ei pitäisi käytännössä olla lainkaan). Jos tarkasteltava kohde sijaitsee työalueella, tehdään tämän lapsiversiosta uusi sovitettava kohde. Lopuksi käyttäjä käy läpi sovitettavat kohteet sekä tarkastaa pudotettujen alueiden reunaviivojen geometriat ja muodostaa pudonneet alueet. Esitetty malli vähentäisi varmasti konfliktien leviämistä topologian kautta, mutta sen esikäsittelyprosessi saattaa olla raskas. Lisäksi tiedossa on, ettei kaikkia konflikteja aina saada tietoon ilman muutosten tuontia vaihtoehtoon. Näin ollen ei kaikkia tarpeellisia kohteita pystytä aina esikäsittelemään. Yksi esitetty vaihtoehto kaikkien konfliktissa olevien kohteiden löytämiseen on ollut ylimääräinen muutostentuonti. Tällöin muutokset olisi ennen esikäsittelyä tuotu lapsivaihtoehtoon, jolloin olisi varmasti saatu selville konfliktissa olevat kohteet. Tämän jälkeen muutostentuonti olisi peruttu ja kohteet esikäsitelty aivan kuten edellä selostettiin. Tämän jälkeen olisi muutokset tuotu uudelleen vaihtoehtoon ja konfliktit ratkottu. Toteutusmallina muutostentuonti vaihtoehtoon kahdesti on aivan liian raskas, hidas ja riskialtis ainakin tuotantosuunnitelmille. Toteutusideana Vanhamaan malli on varmasti hyvä, mutta vaatii paljon testaamista ennen mahdollista käyttöönottoa. 7.3 PAKANA Suurin haaste JAKO/MTJ:n konfliktienhallinnassa on pysyä jatkuvasti kehittyvän sovelluksen mukana. Suurimpia uusia haasteita on vuoden 2004 aikana käynnistyvä projekti, jonka tarkoituksena on siirtää painettujen maastokarttojen 1:20 000 ja 1:50 000 tuotanto Maagis/MTJ:stä JAKO/MTJ:hin. Projektista tullaan käyttämään lyhennettä PAKANA. Painettujen maastokarttojen tuotanto perustuu tällä hetkellä VAX-ympäristössä toimivan Maagis:n käyttöön. Maagis:n käyttämät VAX/VMS- ja Alpha/VMS-työasemat kuitenkin vanhenevat ja vikaantuvat jatkuvasti. Joistain yksiköistä nämä laitteet on jo poistettu käytöstä. Tämän takia on painettujen maastokarttojen tuotantosovellukset

68 uudistettava. Suunnitelmissa on laajentaa JAKO/MTJ:tä niin, että sillä pystytään suorittamaan painettujen maastokarttojen tuotannon edellyttämät kartografiset käsittelyt maastotietokannan aineistolle. (PAKANA 2003) Kuva 22. Kartografisten tuotteiden tuotantoympäristö. (PAKANA 2003) Tarkoituksena on, että sekä 1:20 000 että 1:50 000 painettujen maastokarttojen aineistolle luodaan omat vaihtoehtonsa JAKO/MTJ:n päävaihtoehdon (top, rekisteri) alle. Näissä vaihtoehdoissa tehdään maastotietokantaan maastokarttojen tarvitsemat kartografiset käsittelyt. Tehdyt muutokset talletetaan vaihtoehtoihin. Tarkoituksena on, että näihin vaihtoehtoihin tuodaan maastotietokannassa ajantasaistuksen myötä tapahtuneita muutoksia rekisteristä, mutta näissä vaihtoehtoehdoissa tehtyjä muutoksia ei koskaan viedä ylös rekisteriin. On todennäköistä, että nykyinen konfliktienhallinta ei sellaisenaan sovellu konfliktien ratkaisuun rekisterin ja pakana -vaihtoehtojen välille. Konfliktien käsittelyyn on todennäköisesti muokattava oma versionsa näiden vaihtoehtojen ja rekisterin välille.