INFRA-TUOTEMALLIN HYÖDYT

INFRA-TUOTEMALLIN HYÖDYT Luonnos 21.12.2007 Juha Liukas Sito Oy Jari Niskanen Vianova Systems Finland Oy Esityksen kohderyhmänä ovat tuotemalliteknologiaa vähemmän tuntevat loppukäyttäjät, päätöksentekijät, kehityshankkeeseen potentiaaliset tilaaja- ja rahoittajatahot. Esityksen tavoitteena on havainnollistaa tuotemallitekniikasta saatavia käytännön liiketoimintahyötyjä, pääpaino ei ole tekniikassa. 1

Esityksen sisältö OSA 1: Infran tuotetietojen hallinta, nykytilanne - esimerkkinä suunnittelu ja rakentaminen Infran elinkaaren hallinta - dokumenttien vai mallin avulla? Infran tuotetietojen hallinta tuotemallipohjaisesti Tuotemallipohjainen hanke - tiedon jakaminen, tuotannonohjaus Rakentamisesta hoitoon ja ylläpitoon Järjestelmien yhteistoiminnallisuus miksi? Miksi tuotemallistandardi kannattaa kehittää ja ottaa käyttöön? Tuotemallistandardin kehittämisen lähtökohtia OSA 2: Tuotemallintamisen avainkäsitteitä Mitä asioita tuotemalli voi kuvata Kehityspolku tiedonsiirrosta yhteiseen tuotemalliin Inframodel -tiedonsiirto Yhteydet paikkatietojen mallintamiseen Kansainvälinen paikkatietostandardointi 2

INFRA-TUOTEMALLIN HYÖDYT OSA 1: Infran tuotetietojen hallinta, nykytilanne - esimerkkinä suunnittelu ja rakentaminen Infran elinkaaren hallinta - dokumenttien vai mallin avulla? Infran tuotetietojen hallinta tuotemallipohjaisesti Tuotemallipohjainen hanke - tiedon jakaminen, tuotannonohjaus Rakentamisesta hoitoon ja ylläpitoon Järjestelmien yhteistoiminnallisuus miksi? Miksi tuotemallistandardi kannattaa kehittää ja ottaa käyttöön? Tuotemallistandardin kehittämisen lähtökohtia Esityksen kohderyhmänä ovat tuotemalliteknologiaa vähemmän tuntevat loppukäyttäjät, päätöksentekijät, kehityshankkeeseen potentiaaliset tilaaja- ja rahoittajatahot. Esityksen tavoitteena on havainnollistaa tuotemallitekniikasta saatavia käytännön liiketoimintahyötyjä, pääpaino ei ole tekniikassa. 3

Infran tuotetietojen hallinta, nykytilanne Infrajohtaminen Tavoitteen määrittely Suunnittelu Eri osa-alueilla ja vaiheilla omat järjestelmänsä ja tietomallinsa Toiminta perustuu tiedonsiirtoon: konversiot ja kopiointi paikasta toiseen Oleellista tietoa jää käyttämättä ja tietoa häviää konversioissa Ylläpito ja käyttö Rakentaminen Malli ei palvele infran elinkaarenaikaisia tarpeita Infran tietojen hallinta, nykytilanne Eri osa-alueilla ja vaiheilla on omat järjestelmänsä ja tietomallinsa. Toiminta perustuu tiedonsiirtoon: tietoa muunnetaan eri muotoihin ja kopioidaan paikasta toiseen. Oleellista tietoa jää käyttämättä ja tietoa häviää konversioissa. Malli ei palvele infran elinkaarenaikaisia tarpeita. Esimerkiksi: -tiensuunnittelija mallintaa kohteen suunnitteluohjelmistolla ja toimittaa sen erilaisina tiedostoina ja tulosteina rakentajalle, jolloin tehty väylämalli jää siirtämättä ja on vain suunnittelijan käytössä -urakoitsija rakentaja kohteen ja toimittaa tietyt tiedot tierekisteriin, mutta suuri osa tiedoista jää käytännössä hyödyntämättä muutoin kuin arkistoinnin kautta -hoidon, ylläpidon ja käytön tarpeisiin saatetaan joutua tekemään maastomittauksia ja inventointeja jopa äskettäin rakennetuista kohteista, joiden tiedot ovat juuri olleet suunnittelijan ja rakentajan järjestelmissä -tien- tai kadunpidon verkkotason suunnittelu ja ohjelmointi saa lähtötietonsa pääasiassa hoidon ja ylläpidon järjestelmistä tai tarkoitusta varten toteutetuista rekisteri- ja paikkatietojärjestelmistä, joiden verkkomalli ja tietomalli poikkeavat täysin suunnittelijan järjestelmästä, josta kierros lähti liikkeelle 4

Suunnittelu ja rakentaminen - lähtötiedot Lähtötiedot Pohjakartat + paikkatiedot Kartoitukset ja korkeusmalli Kaava- ja kiinteistötiedot Väylärekisterien tiedot Ympäristö, maa- ja kallioperä Pohjatutkimukset Verkostojen tiedot Aiempi suunnitelma Suunnittelija...... tarvitsisi helposti koottavan lähtötietomallin, mutta joutuu yhdistelemään ja tulkitsemaan eri formaateissa ja luokituksissa olevia aineistoja.... kokoaa lähtötiedot mahdollisimman sähköiseen muotoon suunnittelussa hyödynnettäväksi. Lähtötiedot Pohjakartat: eri formaatteja useista lähteistä Maankäyttö: kaavat paperilla tai kuvatiedostona Muut paikkatiedot, mm. ympäristö, kiinteistötiedot ja maaperäkartat eri organisaatioilta eri siirtomuodoissa Täydennysmittaukset: esim. tekstitiedosto tai kartoittajan tekemä korkeusmalli ja kartta tiedostona Pohjatutkimukset: siirtotiedosto, vanhat ehkä paperilla Verkostojen tiedot: useilta organisaatioilta eri muodoissa Aiempi suunnitelma: raporttikansiot + geometria ja mahdollisesti muita osia siirtotiedostona Suunnittelija...... tarvitsisi helposti koottavan lähtötietomallin, mutta joutuu yhdistelemään ja tulkitsemaan eri formaateissa ja luokituksissa olevia aineistoja.... kokoaa lähtötiedot mahdollisimman sähköiseen muotoon suunnittelussa hyödynnettäväksi. Aineiston hakemista eri lähteistä joudutaan tekemään myös tuotemallipohjaisessa ympäristössä, mutta aineisto on homogeenista ja yhtenäistä infra-tietomallin mukaista sekä mahdollisesti luettavissa suoraan tietolähteestä. 5

Infrahankkeen suunnittelu Suunnittelija...... tekee suunnitelman, jolloin suunnittelukohde on mallinnettu suunnittelujärjestelmän tietomallin mukaisesti.... voisi toimittaa mallin, mutta tuottaakin sähköisiä ja paperisia piirustuksia, siirtotiedostoja, luetteloita ja muita dokumentteja. Nykytilanteessa tiedonsiirron peruskysymyksiä ovat mm.: Mitä ja minkälaista tietoa siirretään? Onko tieto virheetöntä? Sopivatko rakenteet yhteen? Minkälainen rakenne on kyseessä? Vastaavatko lähtötiedot nykytilaa? 6

Infrahankkeen suunnittelu ja rakentaminen - työmaa Rakentaja...... tarvitsee malleja, mutta saa sähköisiä ja paperisia piirustuksia ja siirtotiedostoja..... tekee suunnitelmasta malleja työmaan tarpeiisiin. rakentaa kohteen. mittaa ja dokumentoi toteutuneen kohteen tiedot. toimittaa sovitut tiedot ylläpidon järjestelmiin (rekistereihin) siirtotiedostoina, taulukoina ym. Nykytilanteessa tiedonsiirron peruskysymyksiä ovat mm.: Mitä ja minkälaista tietoa siirretään? Onko tieto virheetöntä? Sopivatko rakenteet yhteen? Minkälainen rakenne on kyseessä? Vastaavatko lähtötiedot nykytilaa? 7

Infran elinkaaren hallinta - dokumenttien vai mallin avulla? Dokumenttipohjainen tiedonhallinta 1. Raaputa ja korjaa? tiedon eheyden hallinta vaikeaa 2. Ihminen tulkitsee dokumentin korkeat kustannukset suuremmat virhemahdollisuudet 3. Dokumentti on staattinen eri tarpeisiin omat dokumentit esitystavat usein 2D:ssä tekniikka-alueiden yhdistely työlästä 4. Tietojen elinkaari katkeaa arkistoon ei yhteyttä ylläpidon järjestelmiin uusiin tarpeisiin uusi tiedonkeruu arkistojen hyödyntäminen vaihtelevaa Tuotemallipohjainen tiedonhallinta 1. Suunnitellaan eheä malli suunnittelun vaatimukset kasvavat 2. Mallin voi tulkita ohjelmallisesti tehokkuus parempi virheet havaitaan helpommin 3. Malli on dynaaminen mallin suora hyödyntäminen tuotemalli voidaan esittää 2D...3D tuotemallin osat yhdisteltävissä 4. Tuotemalli siirrettävissä eteenpäin rekistereistä suunnitteluun suunnittelusta rakentamiseen rakentamisesta rekistereihin 8

Infran tuotetietojen hallinta tuotemallipohjaisesti Infrajohtaminen Tavoitteen määrittely Suunnittelu Tavoitteena yleisesti hyväksyttyjen ja kattavien tuotemallien määrittely Tuotemallit Malleja hyödynnetään eri tarkkuustasoilla eri vaiheissa Tuotemalliajattelu palvelee infran elinkaarenaikaisia tarpeita Ylläpito ja käyttö Rakentaminen Infran tietojen hallinta tuotemallipohjaisesti Tavoitteena on yleisesti hyväksyttyjen ja kattavien tuotemallien määrittely. Mallia hyödynnetään eri tarkkuustasoilla eri vaiheissa ja se palvelee infran elinkaarenaikaisia tarpeita. Esimerkiksi: -tiensuunnittelija mallintaa kohteen suunnitteluohjelmistolla ja toimittaa tuotemallin rakentajalle, jonka massanoptimointi-, mittaus- ja koneohjausjärjestelmät tukevat standardia ja pystyvät lukemaan tehdyn väylämallin suoraan ilman tietohäviöitä -urakoitsija rakentaja kohteen ja toimittaa tietyt tiedot tierekisterin pitäjälle standardin mukaisena tuotemallina -hoidon, ylläpidon ja käytön (esim. talvi- ja kesähoito, rakenteen parantaminen, päällystäminen, varusteiden ja laitteiden ylläpito, navigointi, liikenteenohjaus jne.) tarpeisiin toteutetut järjestelmät tukevat standardia ja pystyvät suoraan hyödyntämään suunnittelijan ja rakentajan järjestelmistä peräisin olevaa tietoa -tien- tai kadunpidon verkkotason suunnittelun ja ohjelmoinnin järjestelmät tukevat standardia ja voivat käyttää lähtötietoina esim. rekisterijärjestelmien tietoja, joiden tietomalli ja verkkomalli ovat samat kuin suunnittelijan järjestelmässä, josta kierros lähti liikkeelle 9

Tuotemallipohjainen hanke - tietoa jaetaan CAD -sovellukset Windows -sovellukset Visualisointi ja esittely Hankkeen tuotemalli Tietokanta Ulkoiset järjestelmät Rekisterit Rekisterit Paikkatieto Mobiilit järjestelmät Mittausjärjestelmät Hankekohtainen esimerkki Tavoitetilanteessa hankkeen tiedot ovat tuotemallistandardin mukaisessa muodossa. Tällöin ne ovat helposti käytettävissä suunnittelusovelluksissa, laskentaohjelmistoissa, raportoinnissa, mittausjärjestelmissä, mobiilisovelluksissa ja hankkeen esittelyssä. Tietoja voidaan lukea lähtötiedoiksi muista alan standardia tukevista järjestelmistä ja tietoa voidaan toimittaa niihin. 10

Tuotemallipohjainen hanke - tuotannonohjaus Suunnittelu väylät rakenteet geo ympäristö varusteet ym. Tuotannonsuunnittelu ja -ohjaus 3D-tuotemalli Rakentaminen väylät rakenteet geo ympäristö varusteet ym. + Aikataulu Kustannukset Perussuunnittelu Muutokset Tuotemallin ylläpito Laadunvarmistus Tuotannonsuunnittelu Rakentamisen simulointi Mittaus ja koneohjaus Määrälaskennat Toteutuman mittaus 3D-tuotemallinnuksen avulla rakennuskohde voidaan mallintaa kokonaisuudessaan. Kun kohteen osat sidotaan aikatauluun ja niille annetaan kustannustietoja, voidaan rakentamista simuloida edullisesti ja havaita sekä 3D-mallin puutteet että prosessiin ja aikataulutukseen liittyviä ongelmia, jotka muutoin tulisivat esille vasta työmaalla. 11

Rakentamisesta hoitoon ja ylläpitoon Suunnitelmatiedoista ei tällä hetkellä viedä suoraan ylläpidon järjestelmiin (juuri) mitään. Suurin osa tiedoista inventoidaan maastossa tai muulla tavoin. Suunnitelmatiedon ja toteutumatiedon käyttäminen rekisteritiedon lähteenä olisi mahdollista, jos järjestelmien tietomallit olisivat yhtenevät. Valaistus XY, koodi XY, koodi Väylä Rakenteet Liikennemerkit Kaiteet XY, koodi Ympäristö XY, koodi XY, koodi XY, koodi Suunnitelmatiedoista ei tällä hetkellä viedä suoraan ylläpidon järjestelmiin (juuri) mitään. Suurin osa tiedoista inventoidaan maastossa tai muulla tavoin. Suunnitelmatiedon ja toteutumatiedon käyttäminen rekisteritiedon lähteenä olisi mahdollista, jos tietomallit olisivat yhtenevät. Viivat ja pisteet, joilla on vain x, y, z ja lajikoodi riittävät paikalleenmittaukseen, mutta eivät tuota suurta lisäarvoa työmaalle. Tuotemallintamisen idea alkaa toimia, kun voidaan kertoa mittalaitteelle (esim. GPS tai takymetri), esim. että ollaan mittaamassa paikalleen kaivoa, jonka materiaali on betonia, halkaisija 1 m, korkeus 2,5 m ja toteutumamittausten yhteydessä voidaan dokumentoida takaisin tietojärjestelmään, että kohteen korkeusasema oli muutettu korkeuteen Z sekä purkusuunnan vesijuoksun korkeuteen z ja lisäksi 1 m kaivo oli korvattu halkaisijaltaan 0,80 -metrisellä kaivolla. 12

Järjestelmien yhteistoiminnallisuus miksi? Esimerkki: kadunrakentaminen Katualueella monia toimijoita: kadunpitäjä liikennelaitos energialaitos vesilaitos teleoperaattorit jne. Useimmat tekevät tai teettävät: suunnittelua rakentamista hoitoa ja ylläpitoa On pyrittävä näiden järjestelmien yhteistoiminnallisuuteen Kuva: HKR Tuotemallipohjaisuudella hyötyjä: Ylläpitojärjestelmä palvelee kadunpidon suunnittelua ja ohjelmointia Suunnittelija käyttää katurekisterin tietoja ja paikkatietoja suunnittelun lähtötietoina Rakentaja palauttaa toteutumatiedot ylläpidon käyttöön Järjestelmien yhteistoiminnallisuuden (interoperability) perusteluja: Katualueella on monia eri toimijoita; esim. kadunpitäjä, liikennelaitos, energialaitos, vesilaitos ja teleoperaattorit. Nämä kaikki tekevät tai teettävät suunnittelua, rakentamista, hoitoa ja ylläpitoa. Kadunpidossa on tästä syystä järkevää pyrkiä suunnittelun, rakentamisen ja ylläpidon järjestelmien yhteistoiminnallisuuteen. Tuotemallipohjaisuudella voidaan saavuttaa merkittäviä hyötyjä. Kunnossapidon (hoito ja ylläpito) järjestelmä, ts. katurekisteri, palvelee kadunpidon suunnittelua ja ohjelmointia. Katusuunnittelija voi käyttää tuotemallipohjaisen katurekisterin tietoja ja paikkatietoja suunnittelun lähtötietoina ja toimittaa tuotemallin rakentajalle. Rakentaja palauttaa toteutumatiedot ylläpidon käyttöön standardin mukaisena tuotemallina. 13

Case Kuusamon pilotti: Hoidon ja ylläpidon yhteisalueurakan tietovirrat Tiehallinto Pitkäkestoinen Pitkäkestoinen palvelusopimus: palvelusopimus: - - urakan urakan vaatimukset vaatimukset - - urakan urakan raportointi raportointi - - infran infran tietojen tietojen ylläpito ylläpito Urakoitsija Tienpitäjä + Kadunpitäjä Urakoitsijan järjestelmä lähtötiedot luokittelut toimivuusvaatimukset muutokset tieverkolla muutokset katuverkolla Tierekisteri TIEH Katurekisteri Digiroad / TIEH katurekisterin perustiedot Kunta lähtötiedot luokittelut toimivuusvaatimukset Muut järjestelmät Inventointi Järjestelmien yhteistoiminnallisuuden (interoperability) perusteluja, Case Kuusamon pilotti: Toteutuneen rakennuskohteen tiedot muuttuvat paikkatiedoiksi ja ne viedään hoidon ja ylläpidon järjestelmiin. Näitä ovat mm. Tiehallinnon tierekisteri ja kuntien katurekisterit. Visiona on mm. pystyä hakemaan rekistereistä saman standardin mukaista lähtötietoa suunnittelujärjestelmiin. Tiehallinto ja kunnat ovat kokeilleet yhteistyötä hoidon alueurakoiden kilpailuttamisessa. Jotta yhteistoiminnallisuus olisi mahdollista tarvitaan yhteistoiminnallisuutta järjestelmien välillä. Kuva havainnollistaa Infra 2010 ohjelman pilottihankkeen (ns. Kuusamon pilotti) tietovirtoja. Urakoitsija operoi omalla järjestelmällään, johon haetaan urakan lähtötiedot, mm. luokittelut ja mahdolliset toimivuusvaatimukset. Urakan sopimusvalvonta ja taloudellinen raportointi tapahtuu tilaajan ja urakoitsijan välillä sähköisesti. Urakoitsija päivittää tapahtuneet muutokset katuverkolla katurekisteriin ja muutokset tieverkolla tierekisteriin. 14

Case Helsingin kaupunki: Liikennemerkkien hallinta - suunnittelun, rakentamisen ja ylläpidon yhteydet Liikennemerkkien hallintajärjestelmä: suunnitelmat tallennetaan rekisteriin toteumatiedot uusien suunnitelmien lähtötiedoksi rakentaja merkitsee suunnitelman mukaiset merkit asennetuiksi tiedot kunnossapidon käytettävissä järjestelmä käyttöönottovaiheessa Infra-alan yhteinen tuotemalli lisäisi järjestelmän käytettävyyttä Rekisteri Järjestelmien yhteistoiminnallisuuden (interoperability) perusteluja Case Helsingin kaupunki: Liikennemerkkien hallinta - suunnittelun, rakentamisen ja ylläpidon yhteydet - Myös tässä on toteutettu oma 'avoin' tietomalli, koska yhteistä mallia ei ole - Järjestelmä on käyttöönottovaiheessa, rekisteriin on päätetty tässä vaiheessa viedä uudet suunnitelmat 15

3D -mallin yhdistäminen liikenteen simulointiin (Finnoontie) Esimerkki tuotemalliajattelusta. Kuvassa on 3D-malli Finnoontien kiertoliittymähankkeesta Espoossa. Malliin on yhdistetty mm. katusuunnitelma, siltasuunnitelmat, katuympäristösuunnitelma ja liikenteenohjaussuunnitelma. Lisäksi mallissa pyörii Hutsim ohjelmistolla simuloitu liikennetilanne. 3D -malliin on siis lisätty fyysisten ulottuvuuksien lisäksi aikaan sidottu ilmiö. Tästä ajattelusta lähtee myös rakentamisen simulointi: 3D-tuotemallin oliot sidotaan aikatauluun ja niille voidaan antaa kustannustietoja. 16

Miksi tuotemallistandardi kannattaa kehittää ja ottaa käyttöön? Tehokkain tapa parantaa alan tuottavuutta on parantaa infran eri tietojärjestelmien yhteensopivuutta. Hyödyt julkiselle sektorille: Tehokkaampi sähköinen kilpailuttaminen Tuoteriippuvuuden väheneminen Läpimenoaikojen pieneneminen Kokonaiskustannusten pieneneminen tietohäviöiden ja kopioinnin vähentyessä Julkinen sektori on infran omistajana myös suurin hyötyjä Hyödyt konsulteille ja urakoitsijoille Kansainvälisesti yhteensopiva toimintamalli Tehokkaampi resurssien käyttö Parempi kannattavuus Paras tapa parantaa alan tuottavuutta on parantaa infran eri tietojärjestelmien yhteensopivuutta yhdenmukaistamalla tietojen keruumenetelmiä, tiedonsiirtoa sekä varastointia ja tätä kautta parantaa tietojen laatua ja käytettävyyttä. Esimerkkinä suunnitteluohjelmistot: Kaikkia tietoja ei voida siirtää niin kauan kuin suunnitteluohjelmien tiedonhallinnan perustana olevat tuotetietomallit ovat erilaisia. Tilanne on johtanut siihen, että asiakkaat suosivat samaa ohjelmaa käyttäviä konsultteja, josta puolestaan on seurauksena IT-ylläpidon kalleus ja prosessien tehottomuus konsulttien joutuessa hankkimaan useita ohjelmia ja kouluttamaan suunnittelijat niiden käyttöön. Urakoitsijat ja suunnittelukonsultit hyötyvät tuotemallipohjaisuudesta ottamalla käyttöön toimintaa tehostavia uusia välineitä ja siten pystyvät parantamaan tuottavuutta. Jotta tämä saavutettaisiin, niin heidän on investoitava uusien prosessien kehittämiseen, koulutukseen, laitteisiin ja ohjelmiin. Tuotemallin kehittämisen merkittävin vaikutus saattaa alan kannalta olla suunnitelmien laatutason nousu, joka realisoituu elinkaaren aikana asiakkaille ja omistajille. Uusi siirtostandardi myös tehostaa ohjelmistojen käytettävyyttä ja avaa markkinoita vapaalle kilpailulle. Infra-alan toimijoille tulee kaikille hyötyjä, mutta ei ilman investointeja. Tuotetietomallistandardin kehittäminen on rakennuttajien tehtävä, ohjelmistotalot investoivat ohjelmien uusien versioiden tekoon sekä urakoitsijat ja suunnittelukonsultit investoivat uusiin toimintatapoihin, ohjelmiin ja laitteisiin. Seuraavassa esitetään joitain odotettavissa olevia hyötyjä. Julkinen sektori: - Tehokkaampi kilpailuttaminen - Läpimenoaikojen pieneneminen - Kokonaiskustannusten pieneneminen tietohäviöiden ja kopioinnin vähentyessä - Julkinen sektori on infran omistajana myös suurin hyötyjä Ohjelmistotalot: - Uusi kansainvälistymisen mahdollistava liiketoiminta Konsultit ja urakoitsijat - Kansainvälisesti yhteensopiva toimintamalli - Tehokkaampi resurssien käyttö - Parempi kannattavuus 17

Tuotemallistandardin kehittämisen lähtökohtia Tuotemallistandardi kattaa koko infra-alan Tiet Kadut Rautatiet Vesihuolto- ja energiaverkostot Tuotemallistandardi kattaa koko elinkaaren suunnittelun, rakentamisen ja ylläpidon järjestelmät Kehitystyö ja käyttöönotto etenee vaiheittain tukeudutaan alalla käynnistyviin tietojärjestelmien kehityshankkeisiin Tuotemallistandardi on vähintään pohjoismaista tasoa käytetään nykyistä osaamista ja kansainvälistä yhteistyötä dokumentointi toteutetaan yhdessä pohjoismaisten organisaatioiden kanssa saavutetaan kansainvälisen standardoinnin kestäviä tuloksia Tuotetietomallistandardin kehittämisen lähtökohtia Tuotemallistandardi kattaa koko infra-alan: - tiet, kadut, rautatiet sekä vesihuolto- ja energiaverkostot Kattaa koko elinkaaren - suunnittelu, rakentaminen ja ylläpito Kehitystyö ja käyttöönotto etenee vaiheittain - tuotetietomallistandardi kehitetään ja otetaan käyttöön vaiheittain tukeutumalla alalla käynnistyviin tietojärjestelmien kehityshankkeisiin Dokumentointi toteutetaan yhdessä Pohjoismaisten organisaatioiden kanssa - näin saavutetaan näin kansainvälisen standardoinnin kestäviä tuloksia Käytetään nykyistä osaamista ja kansainvälistä yhteistyötä - mm. Norjan tiehallinto on jo rahoittanut merkittävästi teiden ja ratojen lähtötieto- ja toteumamallien kehitystä - myös käytetyn tierekisterin kanssa yhteensopivan suunnitelmamallin kehityshanke on käynnissä - kehitystyön kokemuksia on mahdollista hyödyntää Suomessa. Tuotemallistandardi on vähintään pohjoismaista tasoa - tämä laajentaa markkina-aluetta - hyödyn vastapainona on merkittävä investointi kaupallisiin ohjelmistoihin, jotka on kirjoitettava uudelleen, jotta tuotemallistandardiin voidaan liittyä. 18

Miten tuotemallistandardin kehittämisessä tulisi edetä? 1. Nimikkeistön laajentaminen 2. Inframodel menetelmän laajentaminen 3. Infran tuotemallin määrittely ja toteutus Nimikkeistön laajentaminen Inframodel menetelmän laajentaminen Parempi tuki rakentamiselle Nimikkeistölaajennukset LandXML:n uudet versiot Tukee tuotemallin määrittelytyötä Infran tuotemallin määrittely ja toteutus 19

Miksi infra-alan yhteinen tuotemallistandardi kannattaa kehittää ja ottaa käyttöön? Nimikkeistön laajentaminen Inframodel menetelmän laajentaminen Parempi tuki rakentamiselle Nimikkeistölaajennukset LandXML:n uudet versiot Tukee tuotemallin määrittelytyötä Infran tuotemallin määrittely ja toteutus 20

INFRA-TUOTEMALLIN HYÖDYT Luonnos 21.12.2007 OSA 2: Tuotemallintamisen avainkäsitteitä Mitä asioita tuotemalli voi kuvata Kehityspolku tiedonsiirrosta yhteiseen tuotemalliin Inframodel -tiedonsiirto Yhteydet paikkatietojen mallintamiseen Kansainvälinen paikkatietostandardointi Esityksen kohderyhmänä ovat tuotemalliteknologiaa vähemmän tuntevat loppukäyttäjät, päätöksentekijät, kehityshankkeeseen potentiaaliset tilaaja- ja rahoittajatahot. Esityksen tavoitteena on havainnollistaa tuotemallitekniikasta saatavia käytännön liiketoimintahyötyjä, pääpaino ei ole tekniikassa. 21

Tuotemallintamisen avainkäsitteitä Dokumenttitieto Dokumenttitieto on kohdetta tekstinä, graafisesti tms. kuvaava esitys, josta ihminen pystyy tulkitsemaan kohdetta kuvaavaa tietoa. Esimerkiksi rakennuspiirustus sisältää dokumenttitietoa, jonka ihminen pystyy tulkitsemaan. Tietomalli (tuotetietomalli) Tietomalli kuvaa reaalimaailman kohteet ja käsitteet esim. tie, silta, kaide, hanke, jne. Tietomalli määrittelee yhteisen, standardin mukaisen säännöstön ja nimikkeistön, kuten puhutun kielen kielioppi ja sanasto Tietomallin pohjalta voidaan toteuttaa tuotemallipohjaisia ohjelmistoja ja rajapintoja Tuotemalli Tuotemalli on em. määrityksen mukainen tietyn kohteen kuvaus. Tuotemallipohjainen järjestelmä edellyttää toimiakseen määritysten mukaisten ohjelmistojen ja rajapintojen toteuttamista; saman tietomallin mukaista tuotemallia voidaan haluttaessa siirtää (tiedostoissa) tai jakaa (mallipalvelimilla) eri toteutustavoilla. Standardi Standardi on jonkin organisaation esittämä määritelmä siitä, miten jokin asia tulisi tehdä. Kansainväliset, alueelliset ja kansalliset standardit: esim. ISO-, EN- ja SFS-standardit Lisäksi on olemassa myös laajalle levinneitä de-facto -standardeja (ns. teollisuusstandardeja), joita ei ole luotu standardointiorganisaatioissa, esim. LandXML Dokumenttitieto on kohdetta tekstinä, graafisesti tms. kuvaava esitys, josta ihminen pystyy tulkitsemaan kohdetta kuvaavaa tietoa. Esimerkiksi rakennuspiirustus sisältää dokumenttitietoa, jonka ihminen pystyy tulkitsemaan. Tuotetieto on tuotetta ja siihen liittyviä asioita kuvaava tieto, joka on digitaalisessa, tietokonesovelluksilla tulkittavassa muodossa. Tuotetiedosta tietokonesovellus pystyy tulkitsemaan esimerkiksi rakennusosan sijainnin ja muodon, materiaalin ja muut ominaisuudet sekä liittymisen muihin rakennusosiin. Tietomalli (tuotetietomalli) kuvaa reaalimaailman kohteet ja käsitteet esim. tie, silta, kaide, hanke, jne. Tietomalli määrittelee yhteisen, standardin mukaisen säännöstön ja nimikkeistön, kuten puhutun kielen kielioppi ja sanasto. Tietomallin pohjalta voidaan toteuttaa tuotemallipohjaisia ohjelmistoja ja niiden välisiä rajapintoja. Tietomalli määrittelee mitä tietoja eli mitä olioita tuotemallissa voi olla ja mitä ominaisuuksia ja relaatioita olioilla on. Keskeisimpiä tietomallien määrittelyn tarkoituksia on tuotetietojen standardoitu tiedonsiirto eri tietokonesovellusten välillä. Olio on tiettyä asiaa kuvaavien tietojen kooste, jota tietojärjestelmässä käsitellään yhtenä kokonaisuutena. Tuotemalli on em. määrityksen mukainen tietyn kohteen kuvaus, esim. Vt18 = tietyn kohteen tuotetiedot (vrt. puhutun kielen kirja). Tuotemalli on rakennuskohteen ja rakennusprosessin elinkaaren aikaisten tuotetietojen kokonaisuus, joka kuvaa ainutkertaiset kohteen tuotetiedot tuotetietomallin mukaisesti jäsennettynä. Rakennuskohteen tuotemalli voi olla tallennettuna tietokonesovelluksen tietokantana tai tiedonsiirtotiedostona. Tietokonesovelluksilla ja tiedonsiirrossa kohteen tuoteosat ja rakennusosat kuvataan sovellusten käsittelemillä tuoteosa- ja rakennusosa-olioilla. Tuotemallintaminen on reaalimaailman käsitteiden kuvaamista tietokoneohjelmistoille ja tiedon tallentamista soveltuvassa muodossa. Tuotemallipohjainen järjestelmä edellyttää toimiakseen määritysten mukaisten ohjelmistojen ja rajapintojen toteuttamista (implementation). Saman tuotetietomallin mukaista tuotemallia voidaan haluttaessa siirtää (tiedostoissa) tai jakaa (mallipalvelimilla) eri toteutustavoilla. Infra-alalle keskeinen elementti on myös rekisteritietojen kääntäminen tuotemallimääritysten mukaiseksi. 22

Tuotemallintamisen avainkäsitteitä Edellä kuvattuja käsitteitä kaaviokuvana. 23

Mitä asioita tuotemalli voi kuvata Fyysisiä esineitä tai tuotteita: silta, liikennemerkki, vapaa korkeus, vaikutusalue, aikataulu jne. Abstrakteja käsitteitä: prosessi, ympäristövaikutukset, laatu, jne. Oliopohjaisessa mallintamistavassa käsitteet kuvataan olioluokkina, jotka määrittelevät tuotemallin olioiden merkityksen, ominaisuudet, suhteet toisiin objekteihin ja niiden käyttäytymisen Tuotemallissa sama konsepti voidaan esittää useassa eri muodossa: geometria (2D, 3D), topologia, materiaalit, erilaiset tarkkuustasot jne. Kaikki 3D-mallit eivät ole tuotemalleja, eikä 3D-geometria ole tuotemallin ehdoton edellytys - joskin yleensä 3D-geometria on oleellinen osa mallia. Fyysisesti tuotemalli voi olla tallennettuna esim. yhdessä tiedostossa tai tietokannassa tai hajautettuna useassa tietokannassa Eri tuotemallien välillä voi olla viittauksia muihin tietovarastoihin kuten erilaisiin dokumentteihin. Tuotetietomallin käsitteet voivat kuvata joko fyysisiä esineitä tai tuotteita, mittoja, alueita, päivämääriä jne. (silta, liikennemerkki, vapaa korkeus, vaikutusalue, aikataulu) tai abstrakteja käsitteitä kuten prosessi, ympäristövaikutukset, laatu, jne. Oliopohjaisessa mallintamistavassa käsitteet kuvataan tuotetietomallissa olioluokkina (class, entity), jotka määrittelevät tuotemallin olioiden (object) merkityksen (semantics) sekä niiden ominaisuudet (attributes), suhteet toisiin objekteihin (relationships) ja käyttäytymisen (behaviour). Tuotemallissa sama konsepti voidaan esittää useassa eri muodossa (representations): geometria (2D, 3D), topologia, materiaalit, erilaiset tarkkuustasot jne. Kaikki 3D-mallit eivät ole tuotemalleja, eikä 3Dgeometria ole tuotemallin ehdoton edellytys joskin yleensä 3D-geometria on oleellinen osa mallia. Fyysisesti tuotemalli voi olla talletettuna esim. yhdessä tiedostossa tai tietokannassa tai hajautettuna, useassa tietokannassa kuitenkin loogisesti yhtenä kokonaisuutena; toisaalta eri tuotemallien välillä voi olla viittaussuhteita tai viittauksia muihin tietovarastoihin, kuten erilaisiin dokumentteihin (nk.hybridimalli). 24

Kehityspolku tiedonsiirrosta yhteiseen tuotemalliin Tiedonsiirron nykytilanne Tietoa siirretään eri toimijoiden, eri ohjelmistojen ja eri elinkaarenvaiheiden välillä Siirto tapahtuu kuvatiedostojen ja tekstitiedostojen avulla. Ominaisuustietojen siirto perustuu koodaukseen ja vain murtoosa tiedosta saadaan siirrettyä. Tiedonsiirtomenetelmä nykyisten tarpeiden pohjalta Inframodel tiedonsiirtomenetelmän kehittäminen on mahdollistanut uudenlaisen toimintamallin, jossa ohjelmistot tuottavat tiedon vakiomuotoisena siten, että se on mahdollista lukea muihin järjestelmiin. IM2 Tavoitetila: avoin ja yhtenäinen infra-tuotemalli ohjelmistoriippumattomuus ei sidoksissa kuva- tai paikkatietoformaatteihin standardirajapinnat eri tietovarastoihin tuotemalli perustuu kansainvälisiin standardeihin ja infranimikkeistöön laajat integrointimahdollisuudet järjestelmien välillä Kehityspolku tiedonsiirrosta yhteiseen tuotemalliin Tiedonsiirron nykytilasta ja kehittämismahdollisuuksista tehtiin SKOL:in toimeksiannosta esiselvitys vuonna 2001. Esiselvityksessä todettiin kaikkien niin suunnittelun lähtötietoja kuin varsinaisia suunnittelutietoja tarvitsevien kannalta tiedonsiirron tehottomuus: Erilaisia formaatteja ja luokituksia on paljon. Formaattien dokumentointi on vanhentunutta ja puutteellista. Aineistojen tietosisältöä ei dokumentoida. Läheskään kaikki tiedot eivät siirry ja aineistoissa on virheitä. Osaamisen taso vaihtelee, prosessit ovat sekavia. Siirretään kuvia ja dokumentteja, ei varsinaista tietoa. Tehokasta työaikaa kuluu turhaan tiedonsiirtoon. Ylin kuva: Tiedonsiirron nykytila eri toimijoiden, eri ohjelmistojen tai eri elinkaarenvaiheiden välillä. Suunnitelmatiedon siirtäminen tapahtuu kuvatiedostojen ja tekstitiedostojen avulla. Ominaisuustietojen siirto perustuu koodaukseen ja vain murto-osa tiedosta saadaan siirrettyä. Menetelmät ovat kansallisellakin tasolla kirjavia eivätkä sisällä mainittavia kansainvälisiä ulottuvuuksia. Keskellä: Tiedonhallinnan ja tiedonsiirron parantamiseksi hahmoteltiin kehityspolku, jonka seuraavana tavoitteena oli nykyisten formaattien yhtenäistäminen ja dokumentointi ja mahdollisesti uuden tiedonsiirtoformaatin käyttöönotto. Inframodel tiedonsiirtomenetelmän kehittäminen on mahdollistanut uudenlaisen toimintamallin, jossa ohjelmistot tuottavat tiedon vakiomuotoisena siten, että se on mahdollista lukea muihin järjestelmiin ja vaikkapa työmaan koneohjaukseen tai mittalaitteisiin. Menetelmässä on vielä tietoteknisiä ja prosessin kehittämiseen liittyviä pullonkauloja ratkottavana. Alimpana: Pitkällä tähtäimellä tavoitteena on avoin, yhteinen infra-alan tuotemalli. Siinä tiedot on tallennettu standardilla tavalla ja ohjelmistoriippumattomasti. Tuotemalliin pohjautuvassa toimintamallissa voidaan käyttää standardia, dokumentoitua rajapintaa tietojen lukemiseksi eri tietovarastoista. Infran tuotemallin tulee perustua kansainvälisiin standardeihin ja infranimikkeistöön. Tuotemallipohjainen ratkaisu vapauttaa sidonnaisuudesta kuva- tai paikkatietoformaatteihin. Tuotemallipohjaisuus tarjoaa laajat integrointimahdollisuudet järjestelmien välillä (hoidon ja ylläpidon järjestelmät, kustannushallinnan järjestelmät ym.). 25

Inframodel -tiedonsiirto Infamodel on avoin, kaikkien infra-alan toimijoiden käytettävissä oleva menetelmä infran suunnittelutiedon siirtoon. Inframodel-menetelmä perustuu kansainväliseen LandXML-standardiin, jota laajennettiin pohjoismaisen käytännön mukaisilla InfraModellisätiedoilla. LandXML on ns. teollisuusstandardi, joka on käytössä yli 40 maassa ja lähes 600 organisaatiossa. Rekisteröityneitä ohjelmistoja on yli 60. Pilotoitiin ST-hankkeessa valtatien 18 parantaminen Seinäjoella välillä Kiikku Pultra 2001 2002 2003 2004 2005 2006 IM-ylläpito 2007 2008 Esiselvitys (SKOL) inframodel (VTT) IM-jatkokehitys IM2-pilotointi InfraModel2 Infra-teknolgiaohjelma 2001-2005 KÄYTTÖÖNOTTO KOULUTUS Inframodelin esiselvitys ja sitä seuraavat vaiheet kuuluivat Infra2005- teknologiaohjelmaan. Inframodel1-projektissa (2002-2003) VTT:n johdolla selvittiin, miten tiedonsiirtoa voidaan kehittää ja mihin aisoihin pitää siinä keskittyä. Inframodel1:n tuloksena julkaistiin mm. yhtenäinen dokumentaatio Infra-pohjatutkimusformaatista. Infamodel1:n tärkein tulos oli, että päähuomio tulisi keskittää suunnitelmatiedon siirtoon ja siinä kannattaisi hyödyntää jo olemassa olevaa kansainvälistä LandXML-standardia. Huomattavia parannuksia olisi saatavissa etenkin väylien ja putkiverkostojen tiedonsiirrossa. Inframodel2-projektissa (2005-2006) kolme ohjelmistotoimittajaa (Tekla, Vianova, Sito) yhteistyössä VTT:n kanssa ensin määrittelivät ja dokumentoivat Inframodeltiedonsiirtomenetelmän. Tämän jälkeen ohjelmistoihin toteutettiin määrittelyn mukaiset rajapinnat tiedonsiirtoa varten. Ohjelmistotoimittajat testasivat keskenään tiedonsiirron toimivuuden kolmen eri suunnittelujärjestelmän välillä. Pilotoinnissa (2006-2007) menetelmää testattiin todellisella suunnitteluaineistolla. Pilotointiin osallistui viisi suunnittelukonsulttia, joille annettiin yhteinen yleiskoulutus Inframodel-menetelmästä. Ohjelmistokohtaista koulutusta ovat antaneet ohjelmistotalot. Inframodel-tiedonsiirto on tarkoitus ottaa vaiheittain käyttöön Tiehallinnon ja RHK:n tarjouspyynnöissä. Menetelmää tullaan ylläpitämään kehittämään edelleen ja se toimii hyvänä perustana Infra-tuotemallin määrittelyssä ja toteutuksessa. Suurempina kokonaisuuksia kehitetään omina projekteinaan. Sitä on myös tarkoitus hyödyntää tuotemallipohjaisen tiedon siirrossa. 26

Inframodel2: toteutus Suunnitelman yleistiedot projekti, suunnitelma, ohjelmisto, yksiköt, koordinaattijärjestelmät Perusaineisto maastomallin ja maaperämallin pinnat lähtöaineisto: pisteet ja viivat sekä näiden lajikoodaus kolmiopinnat Liikenneväylät (tie, rata, katu, vesiväylä) geometrialinjat rakenne taiteviivoina pinnoittain ryhmiteltyinä sekä kolmiopintoina mitoitusparametritietoa soveltuvin osin informaationa Vesihuoltoverkostot kaivot (laitteet) ja putket ominaisuuksineen rummut Pohjanvahvistus, aluesuunnittelu voidaan soveltaa pintamaisten rakenteiden tiedonsiirtoon (maisemoinnit, vastapenkereet, massanvaihdot jne.) Pohjatutkimukset Infra-formaatti (de facto Suomessa, ei kuulu LandXML:ään) Inframodel1:n lueteltujen kehittämiskohteista valittiin Inframodel2-projektissa asiat, jotka pystyttiin aikataulun ja käytettävien resurssien puitteissa toteuttamaan: Suunnitelman yleistiedot projekti, suunnitelma, ohjelmisto, yksiköt, koordinaattijärjestelmät Perusaineisto maastomallin ja maaperämallin pinnat lähtöaineisto: pisteet ja viivat sekä näiden lajikoodaus kolmiopinnat Liikenneväylät (tie, rata, katu, vesiväylä) geometrialinjat rakenne taiteviivoina pinnoittain ryhmiteltyinä sekä kolmiopintoina mitoitusparametritietoa soveltuvin osin informaationa Vesihuoltoverkostot kaivot (laitteet) ja putket ominaisuuksineen rummut Pohjanvahvistus, aluesuunnittelu voidaan soveltaa pintamaisten rakenteiden tiedonsiirtoon (maisemoinnit, vastapenkereet, massanvaihdot jne.) Tärkeimpinä kokonaisuuksina voidaan pitää väylän rakennepintojen sekä vesihuoltoverkostejen ja rumpujen tiedonsiirtoa. Merkittävää on myös se, että tiedosto sisältää nyt aina yleistiedot mm. itse projektista, koordinaattijärjestelmistä ja tekijästä. 27

Inframodel: dokumentaatio LandXML:n suomenkielinen kuvaus ja selostus IM2:ssa toteutetuista osista Havainnollistettu kuvin Käytetyt ominaisuudet ja rajaukset Suositukset käytöstä http://cic.vtt.fi/projects/inframo del2/documentation/ Inframodel-dokumentaatio on selainpohjainen dokumentti, jossa on helppo siirtyä asiakokonaisuudesta toiseen. Vasemmalla on aina sisällysluettelo, josta klikkaamalla voi siirtyä valittuun kohtaan. Dokumentaatio sisältää LandXML-standadin suomenkielinen kuvauksen ja selostuksen Inframodelissa toteutetuista osista käytetyt ominaisuudet ja niiden rajaukset (raja-arvot) runsaasti havainnolistavia kuvia esimerkkejä linkitykset vastiiviin kohtiin varsinaisessa LandXML-dokumentissa. Dokumentti on vapaasti kaikkien käytettävissä ja löytyy osoitteesta http://cic.vtt.fi/projects/inframodel2/documentation/ Se tarjoaa tietoa sekä ohjelmistojen että infan suunnittelijoille. 28

Inframodel-tiedosto: esimerkkinä vesihuoltoverkostot Verkosto: kaivot ja laitteet solmuja, joihin putket liittyvät Kaivon tiedot: sijainti, dimensiot, materiaali, rakentamis- ja ylläpitotietoja Dokumentaatiossa määritetty pakolliset ja valinnaiset tiedot Sivun yläosassa on esimerkki Inframodelin mukaisesta LandXML-tiedoston alusta, joka sisältää aina yleistiedot: projekti, yksiköt, sovellus, tekijä,.. XML standardi esitysmuoto, jossa on tiedon merkitys on kuvattavissa tiedon sekaan. XML-kieltä käytetään sekä formaattina tiedonvälitykseen järjestelmien välillä että formaattina dokumenttien tallentamiseen. XML perustuu tagien ('<' ja '>'-merkein erotetut sanat) ja attribuuttien (muotoa nimi="arvo") käytölle, esimerkin LandXML-tiedostossa projketin yleistiedot esitetään näin <Project name= Infrapilot desc Vt18 välillä Kiikki-Pultra state= proposed /> Muoto on kehitetty itseään selittäväksi ja helposti ohjelmallisesti käsiteltäväksi, mutta sitä voi myös ihminen lukemalla tulkita eli projekti, jonka nimi on Infrapilot ja kuvaus Vt18 välillä Kiikku-Pultra jne Tavallisilla tekstieditoreilla tiedostoja ei kuitenkaan kannata editoida. Sivun kuvat ovat suoraan Inframodel-dokumentista ja vasemmalla on kuvattu kaivo-putki (solmu-linkki) periaate ja oikealla on kuva kaivosta siihen liittyvine tietoineen eli kannen korkeus, keskipisteen koordinaatit, materiaali, halkaisija, kannen kuormitusluokka, Vasemmalla alhaalla on kaivon (rakenteen, Struct) tiedot tiedostossa LandXMLmuodossa. 29

Inframodel-pilotointi Lähtötietoaineisto: tiesuunnitelman ja radan yleissuunnitelman lähtötiedot IM-muotoon Viisi konsulttia tekivät ns. kevennetyn rakennussuunnitelman Rakennussuunnitelmat IM-muodossa edelleen ohjelmistotaloille analysoitavaksi Inframodel Inframodel IM, tie IM, rata Copyright: Maanmittauslaitos IM-rakennussuunitelma IM-rakennussuunitelma IM-rakennussuunitelma IM-rakennussuunitelma IM-rakennussuunitelma Pilotointiprojektiksi valittiin Vt18 Seinäjoella välillä Kiikku-Pultra. Suunnitelma käsittää valtatien 18 oikaisun välillä maantie 7035 (Kiikuntie) ja valtatie 19 (Pultran eritasoliittymä). Valtatie 18 alittaa Seinäjoki-Oulu -radan. Hanke toteutetaan ST-hankkeena ja tarjouspyynnöt lähetettiin urakoitsijoille syksyllä 2006. Tiehankkeesta on laadittu tiesuunnitelma, josta on tehty hyväksymispäätös kesällä 2006. Seinäjoki-Oulu -radan yleissuunnitelma valmistui kesällä 2006. Suunnitelmat laatineet konsultit tuottivat lähtöaineiston Infamodel-muodossa. Lähtötietoaineisto sisälsi maastomallin, kalliopinnan sekä hankkeeseen liittyvien teiden, katujen ja radan geometrialinjat sekä rakennekerrosten viiva- ja pintamallit ja kuivatuksen. Tilaaja lähetti lähtöaineiston viidelle konsultille. Suunnittelijat lukivat ne omiin ohjelmistoihinsa, laativat ns. kevennetyn rakennussuunnitelman (suunniteltiin tiedonsiirron kannalta oleelliset asiat, mutta ei yksityiskohtia tavallisesti vaaditulla tarkkuudella). Rakennussuunnitelma-aineistot toimitettiin tilaajalle. Suunnittelijat laativat testausraportit tiedonsiirron toimivuudesta ja käyttökokemuksista suunnitelmien jatkamisessa. Tilaaja toimitti Inframodel-muotoiset rakennussuunnitelmat ohjelmistotaloille, joista jokainen luki kaikki viisi aineistoa ohjelmistoihin ja raportoivat tulokset. Kokemukset menetelmän käytöstä olivat pääosin myönteisiä. Erityisesti putkijohtoverkostojen tietojen älykäs siirto koettiin hyväksi. Pilotointi poiki myös parannus- ja kehitysehdotuksia, jotka huomioidaan Inframodelin ylläpito- ja kehitystyössä. Tiehallinnon ja RHK:n toimeksiannosta onkin jo laadittu tarjouspyyntöasiakirjohin liitettävä ohje mm. tiedostojen jakamisesta ja nimeämiskäytännöistä. 30

Inframodel, johtopäätöksiä Inframodel Saavutettu Yhtenäinen, dokumentoitu, testattu tiedonsiirtomenetelmä Infra-alan käyttöön, joka perustuu kansainväliseen standardiin Tehostaa suunnittelutyötä: yhtenäinen formaatti, yksityiskohtaisempi tietosisältö Pitkäjänteinen kehitystyö alan aktiivisten toimijoiden kanssa tuottaa hyvän tuloksen ja eri näkemykset tulevat huomioitua Menetelmä on hyödynnettävissä elinkaaren eri vaiheissa lähtötiedoista suunnitteluun ja rakentamiseen Inframodelin edelleen kehittäminen on kannattavaa ja tarjoaa hyvän pohjan ja etenemispolun tietomallityölle. Inframodelissa on saavutettu Yhtenäinen, dokumentoitu, testattu tiedonsiirtomenetelmä Infra-alan käyttöön, joka perustuu kansainväliseen standardiin. Kansainvälinen standardi sovitettiin pohjoismaiseen käytäntöön ja päästiin vaikuttamaan myös LandXML:n kehitystyöhön. Eri tyyppisten tiedostoformaattien tarve vähenee ja tiedot tulevat yhdenmukaisena pakettina. Virhemahdollisuudet vähenevät ja vähemmän työaikaa kuluu tiedon siirtoon ja käsittelyyn. Pystytään siirtämään enemmän ja yksityiskohtaisempaa tietoa suoraan järjestelmästä toiseen. Aikaisemmin samoja tietoja koottiin eri piirustuksista ja dokumenteista. Mahdollistaa tiedonsiirron myös monien muiden LandXML-formaattia tukevien suunnittelu- ja mittausohjelmistojen (esim. Trimble, Leica) kanssa. Tämä helpottaa ja yhtenäistää toimintaa myös kansainvälisesti sekä ohjelmistotalojen että suunnittelijoiden kannalta. Pitkäjänteinen kehitystyö alan aktiivisten toimijoiden kanssa tuottaa hyvän tuloksen ja eri näkemykset tulevat huomioitua. Hanke toteutettiin säännöllisinä projektikokouksina, joka auttoivat löytämään yhteisiä ratkaisuja. Menetelmä on hyödynnettävissä elinkaaren eri vaiheissa lähtötiedoista suunnitteluun ja rakentamiseen. Vaikka tavoitteena oli ensisijaisesti tiedon siirron parantaminen eri suunnittelujärjestelmien välillä, on menetelmä hyödynnettävissä myös rakentamiseen. Inframodelin edelleen kehittäminen on tarpeellista ja tarjoaa hyvän pohjan ja etenemispolun tietomallityölle. Osittainhan esim. putkijohtoverkostojen osalla Inframodel on lähellä tietomallin vaatimuksia. Tehty yhteistyö tarjoaa hyvän alustan jatkokehitykselle. 31

Inframodel, johtopäätöksiä Kehitettävää LandXML:n uusien versioiden ominaisuuksien hyödyntäminen Yhtenäinen lajikoodaus: Infra2006-nimikkeistö vaatii laajennusta Väylän suunnittelutiedon ja rakennemallin muodostuksen logiikan määrittely Laajennukset esim. laitteisiin ja varusteisiin Inframodelissa kehitettävää LandXML:n uusien versioiden ominaisuuksien hyödyntäminen. LandXMLmenetelmää kehitetään jatkuvasti ja se tulee hyödyntää myös meillä: ottaa käyttöön uusia ominaisuuksia ja toisaalta vaikuttaa kehitystyöhön. Väylän suunnittelutiedon ja rakennemallin muodostuksen logiikan määrittely. Nyt siirrämme valmiita väylän tien tai radan pintoja, mutta varsinaisista suunnitteluparametreista siirtyy vain osa informaationa eikä menetelmä sisällä alkuperäisiä mittoja ja niiden välistä logiikkaa, jolla rakenne on muodostettu. Yhtenäistä lajikoodausta: Infra-nimikkeistö vaatii laajennusta. Väylärakenteen tiedon siirto tulisi perustua yhtenäiseen nimikkeistöön. Infra2006-nimikkeistö tukeutuu rakennusosiin, joka tarkkuus ei vielä riitä tiedon siirrossa tai mallinnuksessa. Tarvitaan yhteinen nimikkeistö esim. tierakenteen mittapisteille, esim. ajoradan reuna, asfaltin reuna, pientareen reuna, ojan pohja. Nämä asiat ovat nimetty ja luokiteltu eri tavoin eri suunnittelujärjestelmissä. Sivun alareunassa toinen kuva on Infra2006-nimikkeistöstä, toinen taas E18 Muurla-Lohja hankkeessa käyttetyistä tien mittapisteistä. Muita seuraavaksi mukaan otettavia laajennoksia voisivat olla Paalutukset, stabiloinnit ym. Varusteet ja laitteet Maaperän ominaisuudet 32

Yhteydet paikkatietojen mallintamiseen INSPIRE -direktiivi 2007/2/EY Yhtenäinen eurooppalainen standardi, jolla mahdollistetaan paikkatietojen laajamittainen saatavuus ja käyttö Euroopassa kansallisten paikkatietoinfrastruktuurien yhteentoimivuuden vaiheittainen kehittäminen Direktiivi tuli voimaan 15.5.2007 ja direktiivin mukainen kansallinen lainsäädäntö tulee saattaa voimaan 15.5.2009 mennessä KuntaGML Standardimuotoiset paikkatietopalvelurajapinnat, jolla kunnat toimittavat kartta-aineistoa Kantakartat ja asemakaavakartat XML/GML toteutus + palvelurajapinta VerkkoGML Johtoverkkojen mallintaminen: tietoliikenne, vesi ja viemäri, kaasu, sähkö, kaukolämpö Palvelee johtotietojen siirtoa eri organisaatioiden välillä EuroRoadS Tieverkon ja teihin liittyvän tiedon eurooppalainen standardi Visiona Euroopan kattava tieverkon infran tietojen palvelurajapinta ja yhteensopivien tiestötietokantojen kehittäminen EU25+ -alueella INSPIRE yhteensopivuuden varmistaminen INSPIRE:n tavoitteita Paikkatietojen laajamittaisen käytön mahdollistaminen -Hallinnollisten ja poliittisten esteiden poistaminen -Yhtenäinen eurooppalainen standardi Tietopalveluiden aikaansaaminen suoraan tietoa keräävästä organisaatiosta Helppokäyttöiset tietopalvelut -Standardien käyttöönotto -Lisäarvopalveluiden syntymisen tukeminen -Luotettavien toimintamallien luominen Kuva: Paikkatietojen ja infran tietojen yhteensopivuustasot 33

Kansainvälinen paikkatietostandardointi Tällä hetkellä kolme tärkeintä paikkatietostandardoinnin foorumia ovat: ISO/TC 211: Geographic information/geomatics CEN/TC 287: Geographic information OGC: Open Geospatial Consortium ISO- ja CEN-standardoinnin kansallisena vastuutahona toimii Suomen Standardisoimisliitto SFS. Paikkatietostandardointia koordinoi Maanmittauslaitos yhteistyössä SFS:n kanssa. OGC:n jäseniä ovat suoraan monet kansainväliset paikkatietojärjestelmien toimittajat ja organisaatiot. Kansainvälisten paikkatietostandardien käyttöönottoa Suomessa pyritään helpottamaan julkisen hallinnon suosituksilla, joita ylläpitää julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA). Lähde: Maanmittauslaitos 2007 Kansainvälinen paikkatietostandardointi Tällä hetkellä kolme tärkeintä paikkatietostandardoinnin foorumia ovat: ISO/TC 211: Geographic information/geomatics CEN/TC 287: Geographic information OGC: Open Geospatial Consortium ISO- ja CEN-standardoinnin kansallisena vastuutahona toimii Suomen Standardisoimisliitto SFS. Paikkatietostandardointia koordinoi Maanmittauslaitos yhteistyössä SFS:n kanssa. OGC:n jäseniä ovat suoraan monet kansainväliset paikkatietojärjestelmien toimittajat ja organisaatiot. Kansainvälisten paikkatietostandardien käyttöönottoa Suomessa pyritään helpottamaan monilla julkisen hallinnon suosituksilla, joita ylläpitää julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA). Lähde: Maanmittauslaitos 2007. 34

ISO -standardit soveltuvat infra-alalle ISO/TC 211 (ISO Technical Committee 211): Conceptual Schema Language (ISO/TC211 19103) Spatial Schema (ISO/TC211 19107) Rules for application schema (ISO/TC211 19109) Feature Cataloguing (ISO/TC211 19110) Spatial referencing by coordinates (ISO/TC211 19111) Spatial referencing by geographic identifiers (ISO/TC211 19112) ISO Technical Committee 211 (ISO/TC 211) Keskeisin paikkatietostandardoinnin kansainvälinen foorumi on International Standardization Organization -järjestön (ISO) tekninen komitea 211. Sen työstämät aiheet löytyvät linkistä http://www.isotc211.org/pow_all.htm. Standardit muodostavat pohjan sektorikohtaisten sovellusten kehittämiselle. Mm. KuntaGML ja Norjan tierekisteri perustuvat näihin standardeihin 35