Gå till innehållet

Kommentoi käsitemallia

Pratbubbla 17
Diskussion | Maanmittauslaitos
Diskussionen har avslutats

Basuppgifter

Avslutat: 12.8.2019

Bilagor

  • Inga bilagor
Ilmianna

Se övriga kommentarer

Selkeytyksiä ja kysymyksiä

Plats för profilbild

@rakoi
25. juli 2019 klockan 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?