Ohessa muutama meiltä sisäisesti kerätty kommentti lähinnä muutosten hallintana liittyen. Tiedostamme tuon tietomallin tarpeet, mutta haluaismme kuitenkin tuoda esiin, miten tämä näyttäytyy hyödyntäjän näkökulmasta.
Verkkotietomalli sisältää useita ominaisuustietoja, joita ylläpidetään linkeillä ja jotka olisi mahdollista sisällyttää tietomalliin myös lineaarisesti referoitavina kohteina. Vaikkakin ominaisuustietojen tallentaminen linkeille voi olla käytännöllistä, voi se johtaa tarpeettomiin päivityksiin ja linkkien versiointeihin, kun linkin geometrian tai topologian muutosten sijaan vain ominaisuustieto on muuttunut.
Suosituksemme on, että suoraan linkille liitettyjä ominaisuustietoja vaihtoehtoista siirtämistä lineaarisesti referoitaviksi tiedoiksi tarkasteltaisiin, jotta linkkeihin kohdistuvat päivitykset voitaisiin minimoida.
Mikäli olemme ymmärtäneet oikein tielinkin muutosten hallinnan periaatteen oikein (kappale 13.), tieverkon muutokset hallitaan kertomalla muuttuneen tielinkin uudet alku ja loppu M-arvot. Tästä johtuen M-arvot eivät pysy vakaina (linkin id ei pysy vakiona ja sen M-arvot eivät osoita samaan pistesijaintiin mahdollisen päivityksen jälkeen).
Toimintamalli aiheuttaa suuria vaatimuksia ulkoisille hyödyntäjille, jotka varastoivat tietoa lineaarisella referoinnilla linkitettynä verkkomalliin (esimerkiksi vakuutusyhtiöiden onnettomuussijaintidata). Muutosten hallintatapa johtaa siihen, että ulkoisten järjestelmien on päivitettävä referenssitietonsa muutostietojen perusteella. Tästä aiheutuu useita haittoja:
1) Ulkoisella järjestelmällä on oltavat yhteys muutostietoihin (sekä linkkeihin) päivityksiä varten. 2) Ulkoisen järjestelmän on prosessoitava ja päivitettävä kaikki varastoidun datan referenssitiedot oikeassa järjestyksessä muutostiedoissa kuvatulla tavalla. 3) Epävakaat referenssiarvot ovat hyvin monimutkaisia käsitellä, kun kyseessä on historiallinen data (esimerkiksi vuonna 2015 aiheutuneen onnettomuuden linkin X mitta Y - mikä on vastaava mitta nykyisessä versiossa, jolla voidaan viitata samaan sijaintiin ja joka oli validi vuoden 2015 verkolla). 4) Miten huomioidaan ja käsitellään referenssiarvojen uudelleen laskenta, kun M-arvot muuttuvat arvoista 0...200 arvoihin 0...100, kun uusi linkki kuvaa vanhan linkin viimeistä sataa metriä.
Jos kommenteissa on jotakin epäselvää, keskustelemme mielellämme asiasta kanssanne ja voimme esitellä erilaisia käyttötapauksia muutosten hallinnasta muissa järjestelmissä, joissa ulkopuolinen liiketoiminnan operatiivinen data on lineaarisesti referoitu tieverkolle ja joissa on siten mahdollista yhdistää liiketoiminnan datan ominaisuustiedot verkkotietokannan tietoihin analyysien yhteydessä.
Jari Andersin, MML 28. helmikuuta 2019 kello 16.17.59
Kiitos kommenteista! Muutostietojen hallinta ja sen toteutus on tällä hetkellä aktiivisesti työn alla. Tässä vaiheessa toteutuksen lähtökohtana on tosiaan ollut Digiroadin nykyinen jako (milloin ominaisuus on tallennettu linkille / ominaisuus linkitetty verkkomalliin lineaarisella referoinnilla). Käymme kommentit läpi ja palataan sitten yhdessä vielä aiheeseen ja eri käyttötapauksiin.
Kommentteja ulkoisen hyödyntäjän näkökulmasta
Timo Mouhu, Triona Oy
28. helmikuuta 2019 kello 15.27.05
Ohessa muutama meiltä sisäisesti kerätty kommentti lähinnä muutosten hallintana liittyen. Tiedostamme tuon tietomallin tarpeet, mutta haluaismme kuitenkin tuoda esiin, miten tämä näyttäytyy hyödyntäjän näkökulmasta.
_Yleisesti ominaisuustiedon sisällyttämisestä referenssi linkeille_
Verkkotietomalli sisältää useita ominaisuustietoja, joita ylläpidetään linkeillä ja jotka olisi mahdollista sisällyttää tietomalliin myös lineaarisesti referoitavina kohteina. Vaikkakin ominaisuustietojen tallentaminen linkeille voi olla käytännöllistä, voi se johtaa tarpeettomiin päivityksiin ja linkkien versiointeihin, kun linkin geometrian tai topologian muutosten sijaan vain ominaisuustieto on muuttunut.
Suosituksemme on, että suoraan linkille liitettyjä ominaisuustietoja vaihtoehtoista siirtämistä lineaarisesti referoitaviksi tiedoiksi tarkasteltaisiin, jotta linkkeihin kohdistuvat päivitykset voitaisiin minimoida.
_Kommentit koskien ehdotettua linkkien päivitystapaa_
Mikäli olemme ymmärtäneet oikein tielinkin muutosten hallinnan periaatteen oikein (kappale 13.), tieverkon muutokset hallitaan kertomalla muuttuneen tielinkin uudet alku ja loppu M-arvot. Tästä johtuen M-arvot eivät pysy vakaina (linkin id ei pysy vakiona ja sen M-arvot eivät osoita samaan pistesijaintiin mahdollisen päivityksen jälkeen).
Toimintamalli aiheuttaa suuria vaatimuksia ulkoisille hyödyntäjille, jotka varastoivat tietoa lineaarisella referoinnilla linkitettynä verkkomalliin (esimerkiksi vakuutusyhtiöiden onnettomuussijaintidata). Muutosten hallintatapa johtaa siihen, että ulkoisten järjestelmien on päivitettävä referenssitietonsa muutostietojen perusteella. Tästä aiheutuu useita haittoja:
1) Ulkoisella järjestelmällä on oltavat yhteys muutostietoihin (sekä linkkeihin) päivityksiä varten.
2) Ulkoisen järjestelmän on prosessoitava ja päivitettävä kaikki varastoidun datan referenssitiedot oikeassa järjestyksessä muutostiedoissa kuvatulla tavalla.
3) Epävakaat referenssiarvot ovat hyvin monimutkaisia käsitellä, kun kyseessä on historiallinen data (esimerkiksi vuonna 2015 aiheutuneen onnettomuuden linkin X mitta Y - mikä on vastaava mitta nykyisessä versiossa, jolla voidaan viitata samaan sijaintiin ja joka oli validi vuoden 2015 verkolla).
4) Miten huomioidaan ja käsitellään referenssiarvojen uudelleen laskenta, kun M-arvot muuttuvat arvoista 0...200 arvoihin 0...100, kun uusi linkki kuvaa vanhan linkin viimeistä sataa metriä.
Jos kommenteissa on jotakin epäselvää, keskustelemme mielellämme asiasta kanssanne ja voimme esitellä erilaisia käyttötapauksia muutosten hallinnasta muissa järjestelmissä, joissa ulkopuolinen liiketoiminnan operatiivinen data on lineaarisesti referoitu tieverkolle ja joissa on siten mahdollista yhdistää liiketoiminnan datan ominaisuustiedot verkkotietokannan tietoihin analyysien yhteydessä.
Jari Andersin, MML
28. helmikuuta 2019 kello 16.17.59
Kiitos kommenteista! Muutostietojen hallinta ja sen toteutus on tällä hetkellä aktiivisesti työn alla. Tässä vaiheessa toteutuksen lähtökohtana on tosiaan ollut Digiroadin nykyinen jako (milloin ominaisuus on tallennettu linkille / ominaisuus linkitetty verkkomalliin lineaarisella referoinnilla). Käymme kommentit läpi ja palataan sitten yhdessä vielä aiheeseen ja eri käyttötapauksiin.