Siirry sisältöön

Kommentoi käsitemallia

Puhekupla 17
Keskustelu | Maanmittauslaitos
Keskustelu on päättynyt

Perustiedot

Päättynyt: 12.8.2019

Liitteet

  • Ei liitteitä
Ilmianna

Ristiriitaa mallissa

Profiilikuvan paikka

PTA-Osoitteet itse
20. kesäkuuta 2019 kello 14.58.17

Kuvan 1 mukaan yksittäinen sisäänkäynti voi linkittyä moneen osoitepisteeseen.
Riveillä 245-247 sanotaan kuitenkin, että sisäänkäynti voi linkittyä vain yhteen osoitepisteeseen ja mitä siitä erityistapauksissa seuraa. Riittääkö tuo linkki vain yhteen rakennukseen? Onko moneen rakennukseen johtavia sisäänkäyntejä käytännössä niin paljon, että kannatta toteuttaa sisäänkäynnin ja osoitepisteen(rakennuksen) välille monen suhde moneen?

20. heinäkuuta 2019 kello 6.17.48. Vastaus poistettu.

Näytä lisää vastauksia

Tekstin selkeytys

Profiilikuvan paikka

PTA-Osoitteet itse
20. kesäkuuta 2019 kello 15.01.13

Onpa vaikeaselkoinen lause rivit 253-254. Tässä ehdotus selvemmäksi:
Jos Sisäänkäyntiin linkitetyn Osoitekohteen voimassaolo päättyy ja sen korvaa uusi Osoitekohde (eli Osoitepiste tai -pisteet linkittyvät kuten entiseen Osoitekohteeseen), tällöin Sisäänkäynti linkittyy uuteen Osoitekohteeseen ja saa uuden versionumeron.


Osoitteen kieli

Profiilikuvan paikka

Kielet
24. kesäkuuta 2019 kello 13.02.47

Onko mallissa otettu huomioon, että joskus myös Inarissa voidaan ottaa käyttöön saamenkieliset osoitenimet? Tarvittaisiin siis tilaa inarinsaamenkieliselle ja koltansaamenkieliselle osoitteelle.

Voisiko osoitekohde-termin korvata yksinkertaisesti vain sanalla osoite?


Käsitemalli oikean suuntainen

Profiilikuvan paikka

Helsingin kaupunki, kaupunkimittaus
25. kesäkuuta 2019 kello 12.06.22

Kommentit kokonaisuudesta

1) Käsitemalli on pääpiirteissään hyväksyttävä, mutta yksityiskohdat kaipaavat tarkennuksia. Käsitemalli on hyvä asia, mutta myös tiedonsiirto ja muutossanomat tulee suunnitella. Missä vaiheessa siihen pureudutaan?
2) Tarvitaan oma luku missä termistö selitetty, mahdollisesti myös linkitykset termipankkiin tms
3) Osoitekohde-käsite. Tähän ei keksitty parempaakaan nimeä.
4) Sijainnin ja ominaisuustietojen jako erikseen on hyvä asia.
5) Alueosoite ja rakennusosoite tulee eriyttää (ks rivikommentit jäljessä) tai ainakin perustella miksi ne käsitellään samassa luokassa.
6) Kohdeluokkien ominaisuustiedot ovat riittävät, mutta kohteet vaatinevat kuitenkin linkkiavaimia esim paikannimirekisteriin.

Rivikommentit

Rivit 43-46: Valtakunnallinen osoitetietojärjestelmä; Tämä tulee jatkossa määritellä tarkemmin. Mikä tämä on, kuka vastaa jne. Tiedetään, että riippuu monesta eri asiasta, mm VRK ja ei ole suoraan tämän käsitemallin asia, mutta ilman sitä ei voida toimia. Kunta ei ala pitää yllä kahta eri valtion rekisteriä.

Rivit 47-49: ok, tähän tullee linkki kun uusi ohjeistus valmis?

Rivi 50 termi lähiosoite -> termistöön, vaatii esimerkkiä

Rivi 52: vaatii tarkennusta, tarkoittaako pysyvää huoneistotunnusta, ei kai? Vaatii esimerkkiä

Rivit 50-60 nämä erilliset tapaukset vaativat kuvaa, jotta erot ovat helposti erotettavissa

Rivit 61-64: Hyvät rajaukset. Sisätilaosoitteen ja postin jakeluosoitteen ja -jakelupaikan voisi kuitenkin lisätä termistöön, jotta tiedetään mitä tarkoitetaan.

Rivit 65-68: Osoitenimi pitäisi kokonaisuudessaan linkittää paikannimireksiteriin. Vaarana on esim kirjoitusasujen eroavaisuudet ja nimistön elinkaaren hallinnan ongelmat, jos yhteyttä ei ole.
POI-kohteet tulee olla mukana , tullee seuraavaan versioon?

Rivi 97 Osoitenimi ja osoitenumero termistöön; kunta voisi lukea suoraan kuntanumero (myös monessa muussa kohdassa jatkossa), ettei tule sekaannuuksia

Rivi 106 tontinmittaus-> tulisi lukea että kiinteistönmuodostuksen ja kaavoituksen
Rivit 106-107: purku sinällään ei aiheuta osoitekohteen poistumista vaan osoitepisteen poistumisen. Osoitepäätös termistöön

Kuva1: Tämä sama karttana, kiitos
Taulukko1: ID=KMTK pysyvä id ? (ristiriita taulukkoon 3) Miten tämä hanskataan välillä kuntarekisteri-KMTK? Palautetaanko pysyvää id:ta missään vaiheessa kuntaan paluusanomana? Jos niin, missä vaiheessa tämä suunnitellaan?

Rivi 137: Mitä tarkoittaa lause, joka alkaa "Kulkupisteen sijainti määräytyy…"
Rivi 144: sama kuin kohdassa rivi 97
Rivit 145-146: Ok, sama kommentti kuin rivit 65-68
Rivit 147-150: Osoitenumero-käsitenimi on moniselitteinen. Osoitenumerolla on kuntarekisterijärjestelmissä (ja muissakin järjestelmissä) tarkoitettu sitä osoitenumeroa ilman kirjaimia ja viivaosoitteita. Esim osoitenumeroteksti tai osoiteteksti voisi olla kuvaavampi rekisteriosaajan näkökulmasta. Hyväksyttäneen että tavallisen tallaajan kannalta tuo osoitenumero on kuitenkin parempi. Tämä pitää kuitenkin selittää auki terminologiaan.

Rivi 154: olotilaominaisuustieto puuttuu ominaisuuslistasta. Jos tietokannassa on sekä suunniteltuja, voimassaolevia että poistuneita osoitteita, täytyy olotilatieto olla haettavissa

Rivit 169-171: Vaatii tarkennusta, ei avaudu; mitä historiatiedolla tehdään ja miten ne saadaan linkitettyä keskenään kronologiseen aikasarjaan jos niitä tarvitaan. Pelkkä päivämäärä ei riitä…

Rivit 185-186: miten kronologinen yhteys todennetaan? Mihin linkki laitetaan? (tätä ei ainakaan saa ominaisuustietotaulukoista irti) Minkälaista muutossanomaa tämä vaatisi? Palautetaanko pysyväid lähderekisteriin eli kuntaan? Miten versiointi tässä näkyy (tietojenkorjaus)?

Kappale 4.2 (rivit 195-198):
A. Tämä ajatus vaatii lisää avausta. Lähtökohtana on kuitenkin että asemakaava-alueella tontti (kaavayksikkö) osoitteistetaan ja rakennukset saavat sen osoitteet. Muutostilanteessa (rakennuksen purku, uuden rakentaminen jne) tästä prioriteettisäännöstä saattaa tulla ongelma, jos myös alueen osoitetta ei ole saatavissa. Mikä on tämän käyttötarkoitus? Suositellaan harkitsemaan alueosoitteen pakollisuutta, jota tarvitaan tietopalveluissa, esim osoitehaku karttapalvelussa. Toinen käyttötapaus on rakennuksen haku. Alueosoite on tavallaan "kooste" kun taas rakennusosoitteet ovat vain murto-osa osoitteistosta ja siellä voi olla "duplikaatteja".
B. Miten monipalstaiset kiinteistöt tai toisaalta rakennukset hanskataan tässä mallissa? Esim  091-402-0008-0378 joilla useita eri palstoja (~20 erillistä palstaa, joissa ainakin neljä rakennusta ja osoitteita on ~10 ja osa osoitteistamatta), tai 102310784V (neljä erillistä rakennusta yhdellä tunnuksella). Muita esimerkkejä: 100924280X, 1019929140, 103069402D, 103072785J Mihin osoitepiste sijoitetaan kun yksi tunnus käsittää monta reaalimaailman kohdetta?
C. Miten hanskataan se että kiinteistötunnukset ja vtjprt:t pysyvät aidosti yllä tässä järjestelmässä? Että ei tule ristiriitaisuuksia vrt kiinteistö- ja rakennusrekisterit? Linkitys rekisterien välillä olisi suotuisampaa kuin suoraan tunnukset tässä kohtaa. Esim VRK:n RHR:n kanssa on huomattavia ristiriitaisuuksia (vrt kuntarekisteri), koska tiedetään että muutossanomat eivät mene läpi/tietoja ei yksinkertaisesti oteta vastaan. Ei auta vaikka kertaalleen tiedot korjattaisiin oikein, sillä muutos on jatkuvaa ja muutossanomat puutteellisia.
D. Miksi pitää esittää alueosoitteet ja rakennusosoitteet samassa tietomallissa? (perustelut) Voisiko ne eriyttää omikseen? Alueosoitteissa on kattavasti ja uniikisti (kertaalleen) koko kunnan osoitteisto. Rakennusosoitteissa ei ole mukana kaikki lähiosoitteet, mutta siinä on myös duplikaatteja, koska samassa osoitteessa voi olla useita rakennuksia.

Kappale 4.5 (rivit 212-218): Tämä sinänsä ok. Mietittävä meneekö tämä oikein, kun muuttuvan kaavatilanteen ja/tai täydennysrakentamisen takia joudutaan vanhoja osoitteita muuttamaan; Alueosoite ei muutu jos talo palaa ja tilalle rakennetaan uusi tms. Myös vanha osoite voi siirtyä osoittamaan jotain ihan muuta kohdetta.

Kappaleet 5-6: Sisäänkäynnit ja kulkupisteet: Näiden erottelu ja yhteydet kaipaavat myös karttaa, jotta asia selkiytyy. Sinänsä ok.

Rivi 230 alkava kappale: Kaipaa avaamista ja tarkentamista mitä tarkoittaa. On aika vaikeasti selitetty.

Kappale 7: Tällä tulisi olla yhteys paikannimireksiteriin. Tähän voisi lisätä kohdeluokan "POI-kohteet" eli ne alkukappaleessa tarkoitetut epäviralliset rakennusnimet ym.

Profiilikuvan paikka

Timo Tolkki
3. heinäkuuta 2019 kello 16.32.26

Jälkipohdintaa (edelliseen palautteeseen yhtenä osallisena Helsingissä ):

1. Osoitepisteen (osoitenumerotekstin) suuntaus/kierto:

Kunnan suurempimittakaavaisissa kartta-aineistoissa (opaskartta, kantakartta) osoitepisteen osoittava numerosymboli on yleensä suunnattu/kierretty viereisen tien suunnan mukaisesti. Myös kuntien osoiterekisterien paikkatietoaineistoissa on (paikoin/osittain) käytetty suunnattua pistettä sijainnin tallennukseen. Pistekohteella on tällöin kiertokulma. Tämä on mahdollistanut paikkatietoaineiston osoitteiden ja kartta-aineistojen paremman yhteiskäyttöisyyden kunnan käyttämissä mittakaavoissa. Kohdemallin luonnos ei ota mitään kantaa osoitenumerotekstin mahdolliseen suuntaukseen tilanteessa kun osoitenumeroteksti esitetään karttanäkymässä. Joku kirjaus aiheesta pitäisi olla suuntaan tai toiseen, jotta asia ei unohtuisi jäädä kokonaan käsittelemättä.

Osoitenumeroiden suuntausta ja liittymistä tieverkkoon voi pähkäillä esim. kohteessa Junailijanaukio 4, Helsinki. Kohteessa on kolme kpl osoitenumeroita "4" eri kaduilla noin 50 metrin etäisyydellä toisistaan. Vertailua osoitenumeroiden yksityiskohtaisuudesta ja ymmärrettävyydestä voi tehdä esim. Helsingin karttapalvelussa https://kartta.hel.fi/link/7DCEFF ja Kansalaisen karttapaikassa https://asiointi.maanmittauslaitos.fi/karttapaikka/, jossa valitse aineistoksi ”Taustakartta”.


2.
Liite 2, rivi 379:

Olisiko arvojoukkoon ”Kulkurajoitus” syytä lisätä arvo ”Vesistö” tai ”Vesistön ylitys”?

Tähän suoraan ja kiinteästi liittyen ”KulkupisteenTyyppi” arvoina on hyvin huomioitu ”Ensisijainen kulku mantereelta” sekä ”Rantautumispiste”. Ehdotuksen toteuttaminen voi olla redundantin tiedon keruuta, mutta (epä)loogisesti tarkastellen tässä on virhetulkinnan mahdollisuus esim. osoiteaineiston paikkatietoanalyysissä. Jos kulkupisteelle ei ole asetettu mitään kulkurajoitetta, niin teoriassa kulkupisteen kautta voi edetä rajoituksetta millä tahansa ajoneuvolla tai jalan, mikä ei ole totta ”Ensisijainen kulku mantereelta” ja ”Rantautumispiste” kohdalla. Yksi laajempi ratkaisuvaihtoehto voisi olla, että jo osoitepisteen tasolla pyrittäisiin keräämään tietoa onko se saavutettavissa normaalisti/rajoituksetta yleisen tieverkon kautta ja jos näin ei ole, niin näihin rajoitettuihin kohteisiin kohdistuisi suurempi vaatimus/mielenkiinto kerätä kulkupistetietoa.

Näytä lisää vastauksia

Versiot ja linkitys

Profiilikuvan paikka

Jarkko Aaltonen, Porin kaupunki
27. kesäkuuta 2019 kello 11.19.03

"218 Jos Osoitepisteeseen linkitetty Osoitekohde vaihtuu toiseksi, Osoitepisteestä tulee uusi versio."

Osoitekohteen ja Osoitepisteen välillä on monen-suhde-moneen -relaatio, eli niitä yhdistämään tarvitaan erillinen linkkitaulu, jossa pakollisina sarakkeina ovat ainakin:

Osoitekohteen ID
Osoitepisteen ID

Lisäksi siinä on tietysti suhteeseen liittyvät attribuutit ja järkevää olisi olla myös oma ID itse linkille.

Kun osoitekohde vaihtuu toiseksi, eli reaalimaailmassa esimerkiksi rakennuksen osoite vaihtuu, niin tietokannassa muutokset tapahtuvat vain tuossa linkkitaulussa, eli yhdelle linkille kirjataan päättymispäivämäärä, ja uudelle osoitteelle syntyy uusi rivi. (Toki jos kyseessä on kokonaan uusi osoite, niin tottakai se sitten myös syntyy osoitekohde-tauluun.)

Miksi osoitepisteestä tehdään siis uusi versio, joka on täsmälleen samanlainen kuin edellinen?


Versioiden hallinta onkin sitten jo kokonaan toinen asia, ja siihen kaipaisin vähän tarkennuksia.

Kun saman kohteen eri versiot ovat ilmeisesti samassa taulussa, niin miten niiden ID:t ja varsinkin linkitykset hallitaan?

Esimerkki:

Osoitepisteellä on järjestelmän antama uniikki ID, ja sillä on versionumero 1.
Kun osoitepisteestä syntyy muutoksen myötä uusi versio, eli osoitepiste-tauluun syntyy uusi rivi, sillä täytyy olla oma uniikki ID (pääavain). Käytännössä siis rivi saa joko uuden uniikin ID:n, tai pääavaimena toimii esim. ID:n ja versionumeron yhdistelmä. (Jälkimmäinen olisi siinä mielessä looginen, että saman kohteen eri versiot linkittyisivät silloin toisiinsa tuolla ID:llä.)

Oli pääavain mikä tahansa, niin joka tapauksessa osoitepiste-taulun pääavain on se, jolla kohteet linkitetään linkkitaulujen avulla muihin kohteisiin.

Onko tarkoituksena säilyttää vanhoissakin versioissa niissä olleet linkitykset muihin kohteisiin?

Jos on, niin tämä tulee johtamaan aikamoiseen ylläpitomekanismiin, koska version vaihtuessa pitää aina lisätä kaikkiin linkkitauluihin uudet rivit kaikille kohteen linkeille, ja päivittää niihin uudet kohde-ID:t. Minusta ei voida ajatella, että vanhoilla versioilla säilyisi linkityksessä samat ID:t, koska silloin niihin alkaisi jatkossa linkittymään myös esim. uudet osoitteet, joita version voimassa ollessa ei ollut vielä olemassakaan.

Jos meillä on esim. rakennuspisteestä kaksi versiota linkkeineen, ja sitten niihin linkitetystä osoitekohteesta tulee uusi versio, niin mekanismin pitää taas päivittää linkkitaulua, mutta tietysti vain voimassa olevan rakennuspisteversion osalta.

Ja lisäksi n kpl muita skenaarioita. Toivottavasti näistä nyt kuitenkin selviää mitä haen. Eli versioiden ja linkitysten hallinta on vaikeaa ja monimutkaista, ja kannattanee aika tarkasti miettiä mikä on enää saavutetuihin hyötyihin nähden järkevää.

j.


Osoitteen yksikäsitteisyys, olotilat

Profiilikuvan paikka

Jarkko Aaltonen, Porin kaupunki
27. kesäkuuta 2019 kello 14.30.46

"144 Yksikäsitteinen osoite, jonka muodostavat osoitenimi, osoitenumero ja kunta."

Teknisessä toteutuksessa pitää huomioida, että "sama" osoite voi lakata olemasta ja "syntyä" uudelleen aivan muualla. Tässä tapauksessa tulkintamme mukaan on kyse kahdesta eri osoitteesta, eli Osoitekohteen pitää sallia samoja osoitteita, mutta ei toki yhtä aikaa voimassa olevina. Tätähän hallittaisiin tietenkin niillä Helsinginkin kaipaamilla olotiloilla. Periaatteessa toki noilla voimaan/kumottupäivämäärilläkin tätä voidaan hoitaa, mutta olotila on selkeämpi ja helpompi, eikä tule samana päivänä tapahtuvien muutosten mukanaan tuomia ongelmia.

Tällaisiin tilanteisiin päädytään helposti esimerkiksi kuntaliitoksissa tai kun kadun osoitenumeroinnin suunta vaihdetaan (Tampere, Ojalan asemakaava esimerkkinä).

j.


16. heinäkuuta 2019 kello 2.08.19. Kommentti poistettu.


Selkeytyksiä ja kysymyksiä

Profiilikuvan paikka

@rakoi
25. heinäkuuta 2019 kello 20.57.32



TiedonTila: Esivalmistelu, Hyväksytty - Tämä pitäisi olla kaikissa?
Nyt mainitaan vain Kulkupiste tiedon Status kentässä. Vai käsitelläänkö "Vedos"
muotoista tietoa eri järjestelmässä ja tuodaan tähän järjestelmään vasta, kun se
on hyväksytty?


Miksei kaikelle tiedolle ole kolmea tietoa voimassaoloajan alku, loppu
sekä tallennusaika?
Nyt esim. Osoitekohde : VoimassaolonAlkuPvm/VoimassaolonLoppuPvm
jolloin Taulukon 1 PaikkatietokohteenPäättymisAika on päällekäinen VoimassaolonLoppuPvm kanssa.

Onko Osoitetiedon kohdeluokkien tietorakenteilla versionumeroita? En tarkoita tässä
taulukon 1 "VersioID" joka kuvaa objektin versiota (pitää kirjaa objektin muutoksien versioinnista).
Tarkoitan objektityypin versiointia.
Tämä auttaisi tietämään minkä skeeman mukaan luokka on luotu. Tulevaisuudessa, kun
luodaan esim. 3d dataa olisi mahdollista laajentaa tietoja ja samalla kasvattamalla
tietorakenteen versionumeroa ilmoittaa, että "meillä on nyt uusia kenttiä" tms.
Usein käy niin, että suunnitteluvaiheessa ei oteta huomioon sitä, että tulevaisuudessa
tarpeet muuttuvat ja tietorakenteiden on hyvä ainakin minimaalisesti (versioitumalla)
tukea tätä. Tämän version voisi hyvinkin lisätä kohdeluokkien yhteisiin ominaisuustietoihin.


***


Taulukko 1:
ID - Pitäisi varmaan olla "Osoitetiedon pysyvä tunnus" eikä "Osoitetietojärjestelmän pysyvä tunnus"
tai "Osoitetiedon pysyvä tunnus osoitetietojärjestelmässä".

MuuID - Sekoitetaankohan tässä kaksi eri asiaa? Toisaalta se mitä tietoa pitää tallentaa käsitemallin takia
ja toisaalta se miten se teknisesti tullaan toteuttamaan. Käytännössähän mallin tiedot ovat jonkinlaisessa
kuoressa (tietokannan rivi) jossa on järjestelmän kannalta oleellisia metatietoja. MuuID voi olla yksi tällainen järjestelmän
metatieto (tietokannan rivin tietokantakohtainen yksilöivä avain) mutta tämän ei pitäisi kuulua itse kohdeluokan määrittelyyn.

PaikkatietokohteenAlkuAika / PaikkatietokohteenPäättymisAika - onko mahdollista, että paikkatieto
kirjataan rekisteriin ennen kuin tieto on "todellisuudessa oikein"? Jos tämä on mahdollista niin
pitäisikö erottaa PaikkatietokohteenVoimassaoloaikaAlku, PaikkatietokohteenVoimassaoloaikaLoppu
sekä "PaikkatietokohteenKirjaamishetki" ?

PaikkatietokohteenPäättymisAika - Mistä päätellään onko PaikkatietokohteenPäättymisAika kenttä syötetty
vai ei? Onko "puuttuu" tulkittava niin, että se tarkoittaa, että paikkatieto on voimassa?


Onko paikkatietorekisterillä joku ulkoinen kirjaamisjärjestelmä jonne kirjataan, kuka tai mikä on
muutoksen tehnyt (oikeussuoja, käyttörajoitukset jne.)?

Miksi osassa kenttiä käytetään termiä "Aikamääre" ja osassa "pvm"?
Ainakin kellonaika / päivämäärä kannattaa aina molemmat kirjata koska todennäköisesti järjestelmä
ne pystyy helposti generoimaan. Esim. : ISO 8601 Data elements and interchange formats on hyvä apu tähän.
Yleensäkin standardien käyttö kanttaa koska sillä varmistetaan datan parempi jatkokäyttö ja oikeellisuus.

Kannattaisikohan tuota taulukkoa vielä laajentaa niin, että olisi kirjattu jokaiselle riville
pari/kolme syytä _miksi_ kyseinen tieto pitää tallentaa? Se auttaa ymmärtämään jälkikäteen päätöksiä
joiden pohjalta tietty valinta on tehty.

"Tietolähde" - Lista, missä tämä lista on määritelty (listan sisältö) Onko olemassa joku yleisesti
hyväksytty tietolähdetaksonomia jota tässä voisi hyväksikäyttää raportoinnin yhteismitallismaiseksi/
yhdistelyn helpottamiseksi?

Koskevatko nämä "Osoitetiedon kohdeluokkien yhteiset tiedot" myös luokkaa "Paikannuspiste"
joka on mainittu olevan Osoitetiedosta erillään oleva luokka?
kts rivi 70/71 "Osoitetieto on mallinnettu neljänä toisiinsa linkittyvänä kohdeluokkana:
osoitekohde, osoitepiste, sisäänkäynti ja kulkupiste. Erillisenä kohdeluokkana on paikannuspiste."

"Muutostyyppi" "Muutostyyppi ilmaisee, miksi uusi versio on syntynyt" "Luettelo: muutos reaalimaailmassa, tiedon korjaus, ei tiedossa"
Olisiko "Muutostyyppi":ä kuvaavampi nimi "Muutossyy"?

131: "Osoitetiedossa geometriatieto on aina pistemäistä."
Täytyykö näin tosiaan enää nykyaikana olla? Mikään ei estä nykyisiä tietojärjestelmiä sisältämästä
vaikka pistejoukkoa joka rajaa kyseessä olevan alueen kolmessa ulottuvuudessa.

Tämä taitaa riippua paljon siitä ketkä ovat tiedon käyttäjiä. Jos tulee uusia käyttäjiä jotka
tarvitsevat 3D tietoa joudutaan ehkä perustamaan muita rekistereitä joista on viittauksia tähän
rekisteriin. Ehkäpä se on ok. Tai ehkä tietorakenteiden versiointi mahdollistaisi tulevaisuudessa
3D-tiedon lisäämisen.


134-137: Miten ratkaistaan tilanteet joissa pitäisi määritellä XY pistemäinen koordinaatti
esimerkiksi sisäänkäynneille jotka ovat Z tasossa eri kerroksissa?
Kannattaisikohan ottaa käyttöön joku muu koordinaatiojärjestelmä joka tukisi Z akselia myös
varsinkin, kun nyt tehdään uutta järjestelmää eikä enää olla rajattuna paperin XY tasoon? Lähitulevaisuudessa
tulemme näkemään enemmän lisätyn todellisuuden sovelluksia. Näin on mahdollista, että käyttäjä
näkee todellisuuden päälle lisätyn virtuaalitiedon mutta Z akselitiedon (korkeus) puuttuessa
sisäänkäynnit näkyisivät vain tietyssä oletetussa maatasossa.

147: Voisiko harkita, että jossain liitteessä esitettäisiin yleisesti käytetyissä formaateissa
tarkka määritelmä osoitteen muodolle jolloin kielellinen tulkinta esityksestä katoaisi?
Esimerkiksi näin käyttäen https://fi.wikipedia.org/wiki/Backus%E2%80%93Naur-muoto muotoa,


149-150: Tässä on hauskoja nurkkatapauksia kuten "as.", bad", "dad", "ei" "no". Vai mitähän tarkoitetaan
rivin 150 kommentilla "Osoitenumeron tulee olla kieliriippumattomassa muodossa"?
Millä kielellä osoitenumero ei saa olla sana?
Tarkoittaako se, että osoitenumeron tulee olla sama kaikilla kielillä eikä sitä käännetä eri kielille?


Tällaisessa valmistelevassa tekstissä olisi erittäin hyvä, että jos järjestelmälle esitetään vaatimus
"Osoitenumeron tulee olla kieliriippumattomassa muodossa." sitä seuraisi perustelu tuolle vaatimukselle
"Osoitenumeron tulee olla kieliriippumattomassa muodossa jotta vältytään kieliriidoilta" tms.

Osan vaatimuksista voisi esittää jopa tabuloituna taulukkomuodossa jolloin perustelut niille olisi
helpompi kirjata ja analysoida.

Voidaanko tietokantaa käyttää siihen, että tallennetaan tiettyjä nimiä vedos tilaan joka mahdollistaisi
laajemman osoitetietoehdotusten kommentoinnin? Vai järjestetäänkö tällainen katselmointi järjestelmän ulkopuolella?

Taulukko 2:
Käytetyt kielet. Miksei tässä käytetä listaa nimistä sekä ISO 639-2 mukaista tunnistetta eri kielille?
Tällöin jos jatkossa tulee tarvetta muillekin nimille voidaan ne lisätä (esim. Venäjä tms.). Tällöin
nimi olisi lista pareja joista parin ensimmäinen alkio on kielen ISO639-2 lyhenne ja toinen alkio
on kadun tekstuaalinen nimi.

Pitääkö käytetty merkistö mainita erikseen tässä yhteydessä (UTF-8)?

Pitääkö taulukkoon kaksi lisätä myös "Päivämäärä jolloin osoitekohde on lisätty"?

Voisiko aikamääreiden tyyppi sisältää myös kellonajan eikä vain päivämäärää? (ISO 8601 Data elements and interchange formats)

170-171: "Osoitekohteen voimassaolon alkupäivämäärän tulee olla sama tai seuraava päivä
kuin siihen liitetyn entisen Osoitekohteen voimassaolon päättymispäivä."

Miksi? Tämä kuulostaa jonkinlaisen käsin kirjauksen jäänteeltä. Jos kellonaikaleima tallennetaan,
riittää, että entisen osoitteen päättymisajan tulee olla aikaisemmin kuin uudemman osoitekohteen
voimassaolon alkamisen. Ei nykypäivänä ole mitään tarvetta luoda keinotekoisia vuorokauden
vaihtumiseen liitettyjä rajoitteita. Tästä tietokantaan tallennetusta tiedosta voi riippua
muita prosesseja "Lupa/prosessi/projekti etenee, kun uusi osoitetieto tulee voimaan".
Toisaalta nyt määritelmän mukaan tulee olemaan yksi päivä jolloin ei ole selkeää kumpi
osoitekohteen tiedoista on voimassa (uusi vai vanha koska voi olla yksi yhteinen vuorokausi).

175: "Prioriteetti: onko Osoitekohde Osoitepisteen tarkoittaman kohteen ensisijainen osoite."

Onko nyt selkeää mikä on se "kohde"? Onko se osoitekohde "se primääri asia" vai onko se
"osoitepiste".

196: Mitä tällä tarkoitetaan?
"Jos osoitteistetulla alueella on rakennuksia, osoitteistetun rakennuksen
tallentaminen on ensisijaista, eikä alueen osoitetietoja ole välttämätöntä tallentaa."

Käsitän termin "osoitteistettu" niin, että alueella oleville rakennuksille on annettu osoite.

Jos tämä pitää paikkaansa niin silloin kirjoitettu "alueen osoitetietoja ole välttämätöntä tallentaa."
ei voi olla totta koska alueen osoitetiedot on jo ollut pakko tallentaa koska aluehan
on "osoitteistettu". Vai voiko olla "osoitteistettuja" alueita ilman, että näitä tietoja
on tallennettu? Vai tallennetaanko "osoitteistattessa" jotain muita tietoja kuin "osoitetietoja"?

196:
"Jos osoitteistetulla alueella on rakennuksia, osoitteistetun rakennuksen tallentaminen on ensisijaista,"

Mitä tarkoittaa "osoitteistetun rakennuksen tallentaminen". Rakennuksiahan ei kai tallenneta
vaan niiden "osoitepisteitä"?

taulukko 3:

Onko "KohteenKMKT-ID" tyyppi todellakin UUID kuten taulukossa mainitaan?
"KohteenKMKT-ID" Mitä KMKT:n IDtä tässä todella tarkoitetaan? KMKT-PysyväID?
Määrittely on ainakin eri tyyppiä kuin toisessa "otakantaa.fi" dokumentissa:
"Kansallinen maastotietokanta KMTK" jossa KMTK ID:n tyypiksi määritellään
"Merkkijono". Todennäköisesti tyyppi on "Merkkijono" ja merkkijonon sisältö
muodostaa UUIDn.


"KohteenTyyppi" - Pitäisikö selkeästi eritellä "Ei määritelty" "Muu alue" määritelmästä? Muu aluehan
tarkoittaa, että joku on tietoisesti asiaa miettinyt ja todennut, että rakennus tai tontti tämä ei ole.
"Ei määritelty" taas tarkoittaa, että kukaan ei ole asiaa käynyt tarkastamassa ja siitä on epätietoisuus.
Potentiaalinen kohde tarkennukselle tai kartoitukselle siis.

216:"Osoitepisteestä tulee uusi versio, kun sen sijaintipiste siirtyy tai sen jokin ominaisuustiedoista muuttuu 216 ominaisuuden arvon korjaamisen tai tarkentamisen takia."

Pitäisikö sijaintipiste määritellä osana "Osoitepistettä"?
Mitenkäs sijaintipiste tässä dokumentissa on määritelty? Tarkoittaako se
samaa kuin rivin 133 pistegeometria?
Rivillä 216 mainitaan "Osoitepisteestä tulee uusi versio, kun sen sijaintipiste siirtyy"
tarkoitetaanko tuolla sittenkin "Osoitepisteestä tulee uusi versio, kun sen sijaintipiste vaihtuu/muuttuu"?
Jos ymmärrän "sijaintipisteen" "pistegeometriana" ei tuo geometria käsittääkseni siirry minnekään
vaan se on _se tietty_ koordinaattipiste. "Osoitepisteen" sijaintipiste saattaa
kylläkin vaihtua.


270:

Miten kulkupisteen muutos (ja uusi versio) vaikuttaa siihen linkittyneen kulkupisteen versioihin?
Jos ketjun keskeltä poistetaan yksi osa (sen voimassaolo lakkaa) niin pitääkö jäljelle jäävät
osat linkittää uudelleen yhteen?

280:
Taulukko 5:
Kulkurajoitus - Mihin nämä kulkurajoitukset perustuvat ja kuka niistä päättää?

"Status": Tässä kentässä yhdistyy semanttisesti kolme eri asiaa. Yksi on
"tiedon lähde" (kansalainen, valtuutettu käyttäjä, automaattisesti luotu),
toinen taas on "laatu" eli "varmistettu" (vs. varmistamaton) sekä kolmas eli
"alustava tieto" (vs. voimassa oleva tieto). Tuo kenttä pitäisi jakaa
3 eri kenttään. Suosittelisin
TiedonLähde: Kansalainen, Valtuutettu käyttäjä, Automaattinen tallennus
TiedonTila: Esivalmistelu, Hyväksytty - Tämä pitäisi olla kaikissa tieto-objekteissa, ei vain tässä.
TiedonLaatu: Varmistettu, Varmistamaton (mitä ikinä tämä sitten tarkoittaisikaan)

300: "Kulkupisteen elinkaari päättyy, kun se poistetaan."
Mitä tarkoittaa "poistaminen"? Tarkoittaako se "PaikkatietokohteenPäättymisAika"
asettamista ?


Taulukko 6:
Miksei paikannuspisteellä ole Status kenttää?


324: Onko jossain määritelty

368: "Kulku maan alle"
Miksei symmetrisesti myös "Kulku maan yläpuolelle" esim. parkkitaloon nouseva ramppi?


Nostoja edellisiltä kommentoijilla ja lisäksi pari kommenttia

Profiilikuvan paikka

Aija Holopainen/Lahden kaupunki
12. elokuuta 2019 kello 16.27.51

Nostan edellisten kommentoijien, erityisesti Timo Tolkin kommenteista myös Lahden kaupungin palautteena esiin erityisesti seuraavat:
1) Käsitemalli on pääpiirteissään hyväksyttävä, mutta yksityiskohdat kaipaavat tarkennuksia. Käsitemalli on hyvä asia, mutta myös tiedonsiirto ja muutossanomat tulee suunnitella. Missä vaiheessa siihen pureudutaan?

2) Rivit 43-46: Valtakunnallinen osoitetietojärjestelmä; Tämä tulee jatkossa määritellä tarkemmin. Mikä tämä on, kuka vastaa jne. Tiedetään, että riippuu monesta eri asiasta, mm VRK ja ei ole suoraan tämän käsitemallin asia, mutta ilman sitä ei voida toimia. Kunta ei ala pitää yllä kahta eri valtion rekisteriä.

3) Alueosoite ja rakennusosoite tulee eriyttää (esimerkiksi ominaisuustiedolla määritellen, mistä osoitteesta on kysymys) tai ainakin perustella miksi ne käsitellään samassa luokassa.

4) Olotilaominaisuustieto puuttuu ominaisuuslistasta. Jos tietokannassa on sekä suunniteltuja, voimassaolevia että poistuneita osoitteita, täytyy olotilatieto olla haettavissa

5) Suositellaan harkitsemaan alueosoitteen pakollisuutta ainakin asemakaavoitetuilla alueilla. Lähtökohtana on kuitenkin että asemakaava-alueella tontti (kaavayksikkö) osoitteistetaan ja rakennukset saavat sen osoitteet. Muutostilanteessa (rakennuksen purku, uuden rakentaminen jne) tästä prioriteettisäännöstä saattaa tulla ongelma, jos myös alueen osoitetta ei ole saatavissa.

6) Useammankin edellisen kommentoija pohdinta versiohallinnan haasteista ja kohde-ID:den linkityksen pysymisessä mukana tässä on tärkeää huomioida.

7) 3D-maailmaa esimerkiksi kulkupisteen määrittelyssä ei ole huomioitu.

Lisäksi Lahden yleiskommenttina muutama asia:

Valtion ylläpitämä keskusrekisteri ei ole nykyaikainen ratkaisu todettuun tietotarpeeseen. Kunnilla on viime vuosilta kokemuksia keskitetyistä ratkaisuista, esimerkiksi PTV (Palvelutietovaranto), joiden käyttömäärät ovat vähäisiä, ylläpito alkuvaiheen jälkeen hiipuu ja tosiasiallinen tieto haetaan suoraan palveluntarjoajilta kuten aiemminkin.

Teknisen sisällön ja toteutuksen lisäksi toivotaan rinnalla koko ajan pohdittavan, miten määriteltävä ratkaisu istuu olemassa olevaan reaalimaailmaan, miten määritellään kunnan ja valtionhallinnon vastuunjakoja, mitkä ovat nykytilanteen suurimmat puutteet ja tavoitteiden priorisointi.

Kuntien aineistotuottamisen haasteet vaihtelevat. Lahti ja muut Trimble-kunnat taipuvat niin tähän kuin johonkin muuhunkin käsitemalliin melko helposti mutta monella muulla toimijalla on vaikeampaa.

Käsitemalli huomioi aineistokäyttäjien uudet tietotarpeet, mikä on hyvä asia.





Pari täsmennystä vielä

Profiilikuvan paikka

@timoruohomaki
12. elokuuta 2019 kello 21.42.00

Aiemmat kommentit kattavat jo hyvin tärkeimmät ja yritän olla niitä toistamatta, mutta pari asiaa vielä lisähuomioina:

R65 Nimistöjen tuominen osoitetietoihin tulisi olla hyvin perusteltua ettei osoitetiedosta tule laajempaa PointOfInterest -rekisteriä ja jotta esimerkiksi kieliversioiden ylläpitoon ei tule rajoituksia. Lisäksi nimistöjen hallinnointimalli luultavammin eroaa osoitetiedon hallinnoinnista jos nimistöt viittaavat enemmänkin paikalliskulttuurista tuleviin nimiin.

R87 Käsitteistön ja termistön määrittely ja julkaisu on tosiaan tätä hanketta laajempi kysymys mutta se tulisi kyllä hoitaa kuntoon. Ehkä voisi ajatella yhteistyötä esim. Finton kanssa?

R97 Käsitemallityössä saattaa joskus olla eduksi välttää määrittelemästä asioita jotka voidaan periyttää muusta tiedosta. Esimerkiksi osoitekohteen sijainti sijoittaa sen automaattisesti piiriin/kaupunginosaan ja sitä kautta kuntaan. Myös osoitekohteen sijoittuminen postinumeroalueeseen on joka tapauksessa jotenkin järjestettävä ja nämä ovat jo varsin dynaamisia.

R127 Kohdeluokkien ominaisuustietojen kuvaustaulukoissa olisi suositeltavaa päästä eroon teknisten nimien suomenkielisestä määrittämisestä. Yleisesti tämä tukisi myös vertailua standarditietomalleihin esim. ISO/TC211 -kontekstissa.

R139 Osoitepisteen ja Osoitekohteen yksiselitteinen linkittyminen mahdollisiin GML -kohteisiin olisi hyvä myös määritellä.

R165 Kunta: Kts R97 kommentti

R165 Opastaulu: Tyyppi ehkä kuitenkin yksiselitteisempi MIME -tyyppi, mahdollisesti myös linkki kuvaan. Tarvetta ehkä kannattaa vielä miettiä tai ainakin määritellä käyttö tarkasti jotta toteuttaa tarkoituksen (ilmeisesti kulkupisteiden reitti). Onko esim. Ericalla kyvykkyys ottaa näitä vastaan?

R169 Syytä määritellä minkä tiedon muuttuessa korvaava kohde syntyy. Ehkä muitakin tapoja versioida ja auditoida versiointihistoria on.

R203 Ylläpidetäänkö taulukon 3 tietoja päällekkäin muiden tietokantojen kanssa vai linkitetäänkö muiden tietokantojen paikkatietokohteisiin jolloin eheys olisi helpompi säilyttää?

R224 Määrittelyssä olisi varmaan syytä ottaa kantaa myös sisäänkäynnin kaltaisiin kohteisiin kuten postilaatikko, pelastuslaitoksen avainsäilö jne. jotka voi myös mainita esimerkkeinä jossain Liitteen 1 kohdista

R372 Pelastus- ja huoltoajoa varten tarvittaneen tarkempi paino- ja korkeusrajoitustieto

R380 Tässäkin voisi näkyä suhde GML -malleihin joihin nojataan (esim. KMTK tai ISO/TC211 GML)