Liidestujate korduvad küsimused

ADS-iga liidestuja ja RIHA-s oma andmekogu ADS-iga kooskõlastaja korduma kippuvad küsimused.

RIHA kooskõlastusel tekkinud küsimused:

Tagasi üles  

1. Aadressid salvestatakse andmekogusse otse või kaudselt ADS-ist. Mida veel peab tegema?

Lisaks aadressi esmasalvestamisele on vaja jälgida, et varem salvestatud andmed on samuti ADS-ga seostatud (nt identifikaatoritega) ja tagatakse andmete uuendused (ajakohasus).

Andmekogu on ADS-iga korrektselt liidestunud, kui on täidetud ADS-i määruse § 4 lg 4 nõuded, st:

• Andmekogus kasutuses olevad koha-aadressid viiakse vastavusse ADS-i struktuurielementidega.
• Andmekogu koha-aadressid seostatakse ADS-i infosüsteemi identifikaatoriga.
• Tagatakse andmete ajakohastamine ADS-iga nt X-tee teenuste kaudu.

Tagasi üles  

---

2. Mida peab ADS-i X-tee teenuste kasutamiseks tegema?

X-tee V6-s on kõik ADS-i päringuteenused kõigile tarbijatele (alamsüsteemidele) kõigis keskkondades juba vaikimisi avatud, st teenuste avamist maa-ametilt taotlema ei pea. ADS-i teenuseid saab seega kohe kasutama hakata, kui andmekogu on liidestatud X-teega.

Tagasi üles  

---

3. Mis on peavõti?

Peavõti on ADS-i infosüsteemi identifikaator, mida kasutatakse salvestatud aadressiandmete sidumiseks ADS-iga. Kui seos salvestatakse ainult aadressiga, siis on peavõtmeks üldjuhul aadressi identifikaator ADS-is ehk ADR_ID või koodaadress; kui seos salvestatakse aadressiobjektiga (nt selleks, et hakata jälgima aadressiobjekti aadressimuudatusi), on peavõtmeks objekti identifikaator ADS-is ehk ADS_OID või ADOB_ID.

Tagasi üles  

---

4. Andmekogu on loodud asutusesiseseks kasutamiseks ega ole X-teega liitunud - kuidas siis ADS-iga liidestuda?

Täpne tehniline lahendus sõltub konkreetse andmekogu vajadustest - kui aadressid peavad olema igal ajahetkel andmekogus ajakohased, st uuenema automaatselt, on üldjuhul vajalik siiski ADS-i X-tee teenuseid kasutada. Kuid teatud regulaarsusega andmete uuendamiseks või ADS-i aadresside baasi salvestamiseks (nt aadressikomponentide klassifikaatori loomiseks ja uuendamiseks) sobivad ka ADS-i avalikud väljavõtted, mida toodetakse automaatselt iga 30 päeva järel. ADS-i avalikud väljavõtted ja kirjeldused on kättesaadavad ADS-i avalikus rakenduses.

Lisaks on võimalik ADS-i aadressid ja täiendavad andmeväljad (identifikaatorid, objektiseosed jne) salvestada In-ADS-i veebiteenusest. Loe In-ADS-i kohta lähemalt.

Tagasi üles  

---

5. Aadressid tulevad andmekogusse muuhulgas ka käsitsi kodanike vm poolt täidetud vormidelt, st tegemist on n-ö ütluspõhiste aadressidega. Kas need peab ka kuidagi ADS-iga siduma?

Jah. Aadressi eesmärk on viia kohale ehk viidata konkreetsele objektile looduses. Aadresse peab koguma andmekogus omakorda mingisuguse praktilise eesmärgiga - nt kontaktaadressi kasutatakse isikuga ühenduse võtmiseks, tegevuskoha aadressi kontrollide läbiviimiseks jne.

Ütluspõhised aadressid on n-ö aadressilaadsed kirjed, mis võivad, aga ei pruugi viia kohale, seega ei ole selliste kirjete andmekogusse salvestamine eesmärgipärane. Seega peavad andmekogusse salvestatud aadressid olema ADS seosega. St, et ütluspõhised aadressid tuleb vormidelt andmekogusse sisestamisel normaliseerida ehk viia ADS kujule ja varustada ADS-i identifikaatoriga. Kui aadress ei normaliseeru, tuleb andmeandjaga aadressi täpsustamiseks ühendust võtta.

---

Üldine äriloogika, lisainfo:

Tagasi üles  

---

1. Millist lahendust saaks erasektori tarbija (näiteks pank) kasutada, kui aadresse oleks tulevikus vaja ajakohastada?

Tarbivates andmekogudes on enamasti mitu erineva eesmärgi ja sisuga aadressivälja, nt kliendi kontaktaadress, kindlustatud objekti aadress, sündmuse toimumiskoht jne. Liidestumine võib iga aadressivälja osas olla erinev: mõni fikseeritakse ainult sündmuse toimumise ajahetkel, mõni peab olema alati ajakohane, mõne puhul piisab, kui uuendatakse nt uue lepingu sõlmimisel või kord aastas.

Seega täpne tehniline lahendus sõltub konkreetsest vajadusest. Liidestumise juhendis on kirjeldatud erinevad liidestumise tasemed, millest tarbija valib endale sobiva.

In-ADS sobib hästi esmaseks aadressi ja aadressiobjekti valikuks, aga aadresside automaatseks uuendamiseks tuleb kasutada ADS-i X-tee teenuseid. Väiksemate mahtude korral võib saada ka (nt kord kuus) ADS-i avalike csv väljavõtete alusel uuenduste tegemisega hakkama.

Osa erasektori tarbijate jaoks on piisanud ka ainult In-ADS-i kasutamisest, st teatud regulaarsusega (nt kord aastas) palutakse kliendil endal oma kontaktandmeid uuendada. Või võib ka ADS-i aadressiobjekti identifikaatori (ADS_OID) alusel kliendi eest püüda võimalusel aadress ära uuendada. Nt kui aadresse ja toiminguid nendega on vähe, võib igas olukorras, kus aadressi kasutatakse (nt mingi sündmus või päring) kontrollida In-ADS-i automaatpäringuga, kas antud objekti aadress on ikka sama ja kas objekt on endiselt kehtiv. Kõik sõltub sellest, mis eesmärgil ja kui ajakohasena on aadressiandmeid vaja hoida.

Tagasi üles  

---

2. Mis on In-ADS teenuse saadavus, näiteks protsentides (%)? Mis kellaaegadel toimuvad planeeritud katkestused ja kui pikalt kestavad keskmiselt katkestused, mis mõjutavad In-ADS teenuste kasutamist?

Enamus In-ADS-i planeeritud katkestusi toimuvad ajal, millal tarbimine on võimalikult väike. Üldjuhul ei ole selliste tööde käigus teenus kunagi päriselt "maas", vaid selle toimimises võib esineda tõrkeid (kiiruse langus jne). Maa-ameti poolt on tehtud kõik, et In-ADS oleks maksimaalselt kättesaadav. Plaanis on ka In-ADS-i jätkuarendus, mis võimaldab In-ADS-i teenuse täielikult kolida pilveteenustesse ja seeläbi toimekindlust veelgi tõsta. Lisaks on In-ADS juba kasutusel mitmetes riigi jaoks väga olulistes teenustes (nt isikut tõendavate dokumentide iseteenindus, äriregistris ettevõtte asutamine jne), seega on teenuse toimekindlus piisavalt kõrgel tasemel. Kuna tegemist on ikkagi tasuta teenusega, siis teenustaseme lepingut Maa-amet In-ADS-ile hetkel ei paku.

Tagasi üles  

---

3. Miks on mõnikord aadressis 2. ja 3. tase topelt ja mõnikord 3. tase puudu? Kuidas sellise tühja välja puhul toimida?

Alati ei ole aadressis asustusüksuse tase täidetud. 3. tase puudub aadressis, kui linn on samades piirides nii omavalitsus kui ka asustusüksus. Siis 3. tasemel linna nime ei dubleerita. Sellisel juhul peate omal ka vastava taseme tühjaks jätma. Omavalitsusliku linna aadressis võib olla 3. tase täidetud siis, kui seal on linnaosi või kui linnas on täiendavalt asustusüksuseid, sh samanimeline linn. Viimasel juhul dubleeritakse linnasisese linna aadressides linna nimi nii 2. kui ka 3. tasemel.

Selgituseks:

• Eestis on 47 linna kui asustusüksust, millest 10 on samades piirides ühtlasi ka omavalitsused ja 5 n-ö linnasisesed linnad.
• Omavalitsuslikke linnu on 15.
• 10 linna kui omavalitsuse piirid kattuvad täpselt samanimelise linna kui asustusüksuse piiridega - aadressides esineb linna nimi vaid ühe korra 2. tasemel, nt "Ida-Viru maakond, Narva linn, Anne tn 10"; 2-s omavalitsuslikus linnas ehk Tallinnas ja Kohtla-Järve linnas on ametlikud linnaosad, mida kasutatakse ka adresseerimisel (linnaosa on 3. tasemel).
• Ülejäänud 5-s omavalitsuslikus linnas on lisaks samanimelisele linnasisele linnale (asustusüksusena) ka lisaks aleveid, alevikke ja/või külasid, st omavalitsusliku linna ja linna kui asustusüksuse piirid ei kattu. Nendes 5 omavalitsuslikus linnas, mis on Paide linn, Haapsalu linn, Tartu linn, Pärnu linn ja Narva-Jõesuu linn, tuleb linnasisese linna aadressides kirjutada linna nimi kaks korda (2. ja 3. tasemel), näiteks "Pärnu maakond, Pärnu linn, Pärnu linn, Aasa tn 10". Pärnu linna teiste asustusüksuste aadress on näiteks kujul "Pärnu maakond, Pärnu linn, Audru alevik, Aia tn 12".
• 32 linna on tavapärased vallasisesed linnad - linna nimi on 3. tasemel, näiteks "Järva maakond, Türi vald, Türi linn, A. Haava tn 2".

Tagasi üles  

---

4. Kuidas leitakse hoonete kõrgusandmed, mida aadressiobjekti otsingu ja objekti muudatuste teenustesse väljastatakse? Mille poolest need erinevad?

hooneKorgusR on hoone räästa kõrgus meetrites sellise täpsusega nagu on Eesti topograafia andmekogu (ETAK) andmetes.
ETAKis digiteeritakse hoone ruumikuju 3D keskkonnas räästa kõrgusega. Atribuudi hooneKorgusR väärtus leitakse hoone ruumikuju kõrgusväärtuste (igale hoone nurgapunktile arvutatakse suhteline kõrgus) ning aerolaserskaneerimise (ALS) ehk LiDAR andmete alusel koostatud maapinna kõrgusmudeli keskmistatud vahena, mis ümardatakse täismeetriteks. Kvaliteeti ei kontrollita, negatiivsed väärtuseid ei näidata. Negatiivseid väärtusi otseselt ei kõrvaldata. Elu- ja kõrvalhoonetel jäetakse keskmistamisest välja nurgapunktid, mille suhteline kõrgus on -1.

hooneKorgusM on hoone maksimaalne (harja) kõrgus meetrites sellise täpsusega nagu on ETAK andmetes.
Leitakse automaatselt aerolaserskaneerimise (ALS) andmetest aladel, kus kõrguspunkte on ruutmeetril 15 või enam. Korstnad ja antennid püütakse välistada. Andmeid uuendatakse iga nõuetekohase ALS tulemina. Reeglina toimub see kord aastas suuremates linnades ja nende ümbruses ning vastavalt ALS andmete laekumisele iga paari aasta järel ka väiksemates linnades. Stereokaardistajal on võimalik andmeid kontrollida ja vajadusel parandada. Suurem uuendus maksimaalse kõrguse osas saabub siis, kui 2019. aasta lidaripunktid on töödeldud (tõenäoliselt 2020. aasta alguses).

Tagasi üles  

---

5. ADS-i aadressiotsingu teenusest salvestatud tunnuspunkti koordinaadid ei ühti maa-ameti kaardi koordinaatidega. Miks nii?

ADS-is on kolme liiki viitepunkte, millel tuleb vahet teha:

1. Objekti viitepunkt ehk tsentroid - paikneb alati objekti ruumikuju tsentris. 
2. Objekti aadressipunkt ehk objekti ja aadressi seospunkt - võib paikneda hoonel nt sissepääsu juures või mujal, st on käsitsi redigeeritav. Näiteks osal paralleelaadressidega hoonetel on iga aadress nihutatud konkreetse tänava poolele, kuid seda ei ole tehtud lausaliselt. Üldjuhul siiski paikneb automaatselt objekti tsentroidis, aga objekti kuju muutumisel automaatselt üle ei arvutata, kuna võib olla käsitsi muudetud. Seega võib objekti elutsükli jooksul olla tsentroidiga võrreldes pisut nihkes. 
3. Aadressi esinduspunkt ehk aadressi viitepunkt - valitakse objektide aadressipunktide hulgast prioriteetsusreeglite alusel, et aadress viitaks üldjuhul kõige olulisemale selle aadressiga seotud objektile. St aadressi esinduspunktiks on primaarobjekti aadressipunkt.

Objekti viitepunkt iseloomustab aadressiobjekti, objekti aadressipunkt iseloomustab objekti ja aadressi seost, aadressi esinduspunkt iseloomustab aadressi. Üldjuhul on teenuse või väljavõtte kirjelduses öeldud, millise konkreetse punktiga on tegu.

Kaardil otsingutulemustest objekti valides kuvatakse kaardil objekti tunnuspunkt ja aadressiotsingu teenuse kaudu väljastatakse aadressi viitepunkt. Need võivad kattuda, aga ei pruugi. Maa-ameti kaardil infopäringu funktsiooni kasutades kaardil klikkides kuvatakse infoaknas täpselt selle punkti koordinaadid, kus kasutaja klikkis, mitte objekti ega aadressi tunnuspunkti koordinaadid.

Tagasi üles  

---

6. Miks on X-tee teenuses ja ADS-i väljavõttes koordinaadid erinevad, st pööratud kujul? Näiteks:
Teenuse koordinaadid (X, Y): 6497517.42, 628966.65
Väljavõtte koordinaadid (X, Y): 628966.65, 6497517.42

Väljavõtetes ja In-ADS-is on koordinaadid matemaatilises süsteemis nagu ADS-i baasis ja X-tee teenustes antakse tarbijatele L-Est X ja Y. 

Tagasi üles  

---

7. Mis on selle põhjuseks, et aadressil XY koordinaate ei kuvata?
Näiteks aadress: Ida-Viru maakond, Jõhvi vald, Tammiku alevik, Tamme tn 41.

ADS-is on Ehitisregistri ja Eesti topograafia andmekogu (ETAK) kaardistusandmetele tuginedes olemas suur enamus hooneid koos ruumikujudega. Mõningad erandid võivad olla ebaseaduslikud uusehitised, mis on tõenäoliselt pigem kõrvalhooned.

ADS-is ei ole hulgal aadressiobjektidel veel ruumikuju - see tuleneb juhtumitest, kus Ehitisregistris olev ilma ruumikujuta hoone kirje on kaardistatud ruumikujuga veel sidumata. Eelkõige on selliseid seostamata ruumikujuta hooned kas tootmis- või kõrvalhooned. Elu- või ühiskondlikel hoonetel on valdavalt ruumikujud olemas ning ka eelkirjeldatud seosed kaardistatud hoonete ja Ehitisregistri hoonete vahel tehtud.

99,99% aadressidest on viitepunkt olemas. See on tagatud seetõttu, et enamasti on sama aadressiga mitu objekti ja üldjuhul vähemalt ühel neist on ka ruumikuju (aadressi viitepunkt valitakse aadressiga seotud kujuga objektide hulgast ehk aadressi viitepunkt on üldjuhul kõige primaarsema objekti tunnuspunkt).

Väga väike hulk on juhtumeid, kus ruumikujuta objekt on ainuke objekt vaadeldava aadressiga. Siis puudub ka aadressil viitepunkt - selline on ka toodud näide.

Kõik eelpuudutatud andmevead on ADS-is märgitud ja nende andmete korrastamisega tegelevad omavalitsused.

Tagasi üles  

---

8. Palun infot selle kohta, mille alusel ja kui tihti muutuvad objektide ADS_OID-d kehtetuks.

Alati on soovitatav siduda andmekogusse salvestatud aadressid aadressiobjektiga ja edaspidi hakata jälgima aadressiobjekti muudatusi, sh aadressimuudatusi.

Aadresse muutub kehtetuks iga päev, enamasti seetõttu, et aadressiobjektide aadresse muudetakse, kuid ADR_ID muutub ka siis, kui aadressitekst jääb samaks, kuid muutunud on aadressis nt EHAK tase (EHAK kood).

Aadressiobjekte (ADS_OID-e) muutub kehtetuks iga päev. Osadel juhtudel tähendab see, et looduses samuti enam seda objekti ei ole (nt hoone on lammutatud või korter on jagatud või ehitatud kokku teisega, katastriüksused liidetakse või jagatakse vms). Osadel juhtudel on tegemist tehnilist laadi tühistamisega, nt kui aadressikorrastustöö käigus seotakse omavahel EHR (ehitisregistri) ja ETAK (Eesti topograafia andmekogu) hooned (tegemist on sisuliselt sama objektiga, kuid on olnud ADS-is eraldi objektidena ehk eraldi ADS_OID-dega). Hoonete andmete ühendamisel ETAK hoone ADS_OID tühistatakse ja tema andmed kantakse EHR hoonele (EHR hoone ADS_OID jääb kehtima).

EHR hoone ADS_OID on küllaltki püsiv, st tühistatakse ainult siis, kui hoone määratakse EHR-is kasutuselt maha või lammutatakse (või alles püstitamise ehitusloa staatuses oleva hoone ehitusluba tühistatakse). Samuti katastris registreeritud katastriüksuste (KÜ-de) ADS_OID on küllaltki püsiv, st tühistatakse ainult siis, kui KÜ suletakse mingi toimingu tõttu (liitmine, jagamine, piiride oluline muutmine).

Liidestumise tehnilised detailid:

Tagasi üles  

---

1. Kuidas valida objektiseost?

Objektiseose valik sõltub eelkõige konkreetse andmekogu vajadusest ja andmevälja eesmärgist, nt kas andmekogu tegeleb katastriüksuste aadressidega või konkreetsele andmeväljale salvestatakse isikute elukoht ehk hoone või hooneosa seos jne. Aadressiotsinguks, sh esmaseks objektivalikuks sobib kasutada näiteks In-ADS-i, kus saab mh kitsendada, milliste objektiliikide hulgast otsitakse jne. Lisaks võib olla vajalik "sundida" kasutajat valima hooneosa tasemel aadressi. Näiteks teatud juhtudel ei ole hoone tasemel aadress õigustatud, st kui hoones on ka kortereid, siis peab valima korteri täpsusega aadressi.

In-ADSi väljundis on primary atribuut, mille alusel saab valitud aadressile salvestada prioriteetseima objektiseose. Primaarobjekti andmeid väljastatakse ka ADS-i X-tee teenustes.

Kui täpne objektiseos on oluline, on mõistlik kasutaja suunata kaardiaknaga varustatud In-ADSi otsingusse, kus ta saab kaardil konkreetse objekti välja valida või ripploendist tehtud valiku üle kontrollida.

Täpsemalt saab aadressi ja objekti valiku kohta lugeda liidestumise juhendist.

Tagasi üles  

---

2. Kuidas saab uuendada aadresse täisautomaatselt?

Aadresside ajakohasena hoidmiseks on mõistlik kasutada objektiseoseid. Esmase objektiseose kvaliteet määrab ka edasisite muudatuste kvaliteedi. Konkreetne aadresside uuendamise äriloogika sõltub konkreetse andmekogu/andmevälja spetsiifikast, aga üldjuhul võiks aadresside uuendamine toimuda objekti ja aadressi koosmõjul selliselt:

1) Kui objekti aadress muutub:

1. Objekti uus versioon on seotud ainult 1 aadressiga - uuendatakse andmed üks ühele
2. Objekti uus versioon on seotud mitme aadressiga:
   1. Kui ühel aadressil on sama adr_id, mis hetkel isikul kasutuses, uuendatakse andmed (objekti andmed, sest aadress ei muutu)
   2. Kui sama adr_id pole, kuid ainult täpselt ühel aadressil on sama koodaadress, uuendatakse andmed (nt kui aadressis on toimunud Tallinna linn > Tallinn muudatus)

2) Kui objekt tühistub ja järglaseid on 1:

1. Järglasega on seotud ainult 1 aadress: uuendatakse isiku andmed vastavalt
2. Järglasega on seotud mitu aadressi, valitakse vastavalt järgnevale loogikale prioriteetide järjekorras:
   1. Valitakse aadress, millel on sama adr_id, mis hetkel kehtib isikul
   2. Valitakse aadress, millel on sama koodaadress, mis hetkel kehtib isikul (ainult 1 aadress tohib olla selle koodaadressiga, et automaatselt tuvastada)

Kui eelnevate punktide käigus aadressi automaatne uuendamine ei õnnestu, st objekti uuel versioonil on mitu aadressi ja kõik on täiesti uued või objektile järglast ei tule või neid on mitu jne, siis siinkohal peab tarbiv süsteem otsustama:

1. kas andmekogu spetsiifikast tulenevalt on õige luua uus seos mingitele täiendavatele kriteeriumitele vastava objekti/aadressiga automaatselt:

• näiteks mitmese järgnevuse korral valitakse neist objektidest prioriteetseim ja/või objekt, mis on sama aadressiga, mis isikuga seotud vmt;
• järglase puudumise korral juhul kui aadress on kehtiv, otsitakse aadressile uus prioriteetseim objektiseos (näiteks kui hooneid enam ei ole, siis seotakse isik katastriüksusega jne);

2. või sekkub inimene:

• näiteks antakse rakenduses teavitus, et isik peab minema aadressi täpsustama, kuna sellist objekti ega aadressi enam ei ole.

Täpsemalt loe ADS-iga liidestumise juhendist.

Tagasi üles  

---

3. Oma süsteemis kasutame kliendi aadressi identifikaatorina objekti ADS_OID-i. Me tahaks oma süsteemis teha nii, et kui ADS_OID muutub kehtetuks, siis vastava teenuse kaudu leiame objekti järglase ja paneme kliendi aadressi ADS_OID-iks järglase ADS_OID-i. Vanal objektil võib reaalselt olla null kuni teadmata arv järglasi. Kuidas süsteem automaatselt selle ühe järglase välja saaks valida?

Küsimus, kas järglased leitakse täisautomaatselt või peab inimene (nt infosüsteemi haldaja) sekkuma ja ise järglase leidma ja/või kinnitama, vajab pikemat vastust ja sellest sõltub ka ADS-iga liidestumise keerukuse aste - vt lähemalt ADS-iga liidestumise juhendist. Kuna aga lisaks mitmestele järglastele esineb ka olukordi, kus järglast üldse ei pruugi olla, siis teatav käsitöö on vältimatu. Mida saame soovitada aadressiobjekti valikul mitmese järgnevussuhte korral, on eelistada sama täisaadressi (või vähemalt lähiaadressi) kandvat objekti. Aadresside puhul sellist reeglit aga rakendada ei saa. Seega võib ju proovida mitme järglase puhul süsteemi targemaks teha, aga üldjuhul peaks selline olukord kukkuma analoogsesse töövoogu juhtumiga, kus järglasi üldse ei ole. St keegi peab sekkuma ja andmeid täpsustama ja/või kinnitama. Selliseid juhtumeid ei tohiks olla väga palju. Oleneb muidugi ka teie infosüsteemi fookuseks olevatest aadressiobjektidest - nt katastriüksuste puhul esineb mitmeseid järgnevussuhteid KÜ jagamiste tõttu sagedaselt.

Tagasi üles  

---

4. Kuidas peaks kliendi aadressi registris kehtivana hoidma, kui ADS_OID on kehtetuks muudetud ja seda objekti enam pole, aga sama ADR_ID-ga aadress on kehtiv? Aga kui on mitu järglast?

Üldiselt tuvastatakse järgnevus ruumianalüüsi alusel, kuju puudumisel tuvastatakse järgnevus aadressi alusel. Järgnevussuhete kohta saab täpsemalt lugeda ADS-iga liidestumise juhendist.

Lühidalt: mitmene järgnevus on võimalik. Enamasti tulebki sellistel juhtudel täpsustada koos andmeandjaga, milline aadress/objekt on õige järglane. Unikaalaadressi nõudeta objektide puhul ei pruugi mitmese järgnevuse korral järglastel erinevaid aadresse olla, kuigi üldjuhul see nii on.

Tavaliselt ongi ühe aadressiga seotud mitu objekti ja võib olla samal ajal ka mitu unikaalaadressi nõudega objekti, kui KOV ei ole veel UN-tunnusega objektidele unikaalseid aadresse määranud. Ka siis on vaja koos andmeandjaga tuvastada, milline objekt on õige, et andmekogus subjektiga seotud aadressile ühene objektivaste leida. Või kasutada ühese objektiseose loomiseks automaatselt ADS-i primaarobjekti.

Alati tuleb jälgida ikkagi ainult selle väljavalitud objektiga seotud aadressi muudatusi (sest on teada, et isik või muu subjekt on seotud selle konkreetse aadressiobjektiga ja selle objekti aadressi muutumisel peab muutma ka subjektiga seotud aadressi). Kui objekt tühistatakse ja tal on olemas järglane, siis siduma subjekti selle järglasobjekti ja tema aadressiga. Kui aadressiobjektil järglast ei ole või on neid mitu, siis leidma tühistatud objektiga seotud aadressile uue prioriteetseima objekti või täpsustama koostöös andmeandjaga aadressi (seda ka juhul, kui koos objektiga tühistatakse ka aadress, st selle aadressiga ei ole ADS-is enam ühtegi objekti) jne.

Tagasi üles  

---

5. Tekkis probleem seoses kliendi postiaadressi muutumisega. Tundub, et tühistatud aadressi järglased ei ole korrektsed. Näiteks: Vana ADR_ID=511978 on olnud Västriku tn 33 kohta, kuid tühistamisel saanud järglaseks ADR_ID 3091983 (Räni tn 18a) ja ADR_ID 3043227 (Västriku tn 33).

Aadressidele järglaste leidmine on küllaltki keerukas protsess, st tühistatud aadressidele leitakse võimalikke järglaseid ligi 10 erineval meetodil, sh võib tühistatud aadressile tekkida/lisanduda võimalik järglane ka aastaid hiljem. Antud näitel on tühistatud aadressidele järglased leitud korrektselt. Nt on aadressile ADR_ID-ga 511978 võimalikud järglased leitud läbi hoone ME03244749, millel olid kuni 26.01.2018 paralleelaadressid: Tartu maakond, Tartu linn, Tartu linn, Västriku tn 33 // Tartu maakond, Tartu linn, Tartu linn, Räni tn 18a.

Aadressidele ei ole sageli ühest järglast võimalik pakkuda ja sellises olukorras peab ADS-i andmeid tarbiva andmekogu pidaja sekkuma ning omale sobiva järglase n-ö käsitsi välja valima.

Kui aadresse on vaja hoida ajakohasena, on seda kõige otstarbekam teha läbi objektiseoste. St valitakse välja konkreetne aadressiobjekt (nt hoone, kus isik elab) ja hakatakse jälgima selle objektiga seotud aadressimuudatusi. Sellisel juhul on kehtival aadressiobjektil alati konkreetne aadress ja üldjuhul probleemseid olukordi aadressimuudatustega ei teki (käsitöö võib-olla siis vajalik vaid juhul, kui objekti endaga midagi juhtub, nt see tühistatakse).

Tagasi üles  

---

6. Kas see, et ADS_OID muutub vahepeal kehtetuks ja siis uuesti kehtivaks, on tavapärane praktika? Kui ADS_OID versiooni number muutub, siis ei peaks ju ADS_OID ise kehtetuks muutuma või vähemalt on kohe uus oid järglasena olemas?

Aadressiobjekti taastamine on ADS-is lubatud olukord. 

Kui objekt tühistatakse, siis tema viimase versiooni (ADOB_ID) olek märgitakse tühistatuks (st tühistatud olekuga ADOB_ID ei ole uus, vaid kasutusele jääb viimase versiooni ADOB_ID). Kui objekt hiljem taastatakse, siis tekib objektist uus versioon (uus ADOB_ID).

Kui objekti versioonitakse (muutub ADS_OID) ja tegemist ei ole objekti tühistamisega, siis selle peale ei lähe ADS-OID kehtetuks. Objekti eelmine versioon saab oleku V ehk tegemist on vananenud ajaloolise versiooniga. Objektist on aga ka uuem versioon (ADOB_ID), mille olek on K ehk Kehtiv.

Kui objekt muutub kehtetuks, siis on tal tihtipeale olemas ka järglane, aga mitte alati. Nt kui hoone lammutatakse ja sellel kohal ühtegi teist hoonet ei ole, siis ei ole ka tühistatud hoonel järglast seni kuni kunagi tulevikus samale kohale hoone tekib. Kui ei tekigi kunagi, siis ei teki ka järglast.

Tagasi üles  

---

7. Kas on korrektne, kui kasutame objektide muudatuste pärimiseks teenust ADSobjaadrmuudatused (st võtame sealt objekti lisandumise, muutumise ja eemaldamise info) ning OBJEKTI järglaste leidmiseks realiseerime teenuse ADSobjjarglased (teenus ADSobjaadrmuudatused tagastab tegelikult samuti järglaste info, aga kuna järglased võivad ajas hiljem tulla, siis see ei ole täielik lahendus). Ning teenust ADSobjmuudatused me üldse ei kasutaks (st vajaliku info võtaksime ADSobjaadrmuudatused teenusest)?

Antud käsitlus on sobilik, kui teid huvitavad ainult aadressiobjektide aadressid, st teid ei huvita nende ruumikuju, UN-tunnus ega muud lisaatribuudid. Sest juhul, kui objekti versioonitakse ruumikuju või muu lisaatribuudi muutuse tõttu, aga tema aadress jääb samaks, siis ADSobjaadrmuudatused teenuses U sündmust ei teki.