Metsaregistri andmed

[tormi]

Ei märganud, et metsaregistri andmed oleks siin kättesaadavad. Kas saaks/peaks?

[tkardi]

Saab ja peab :). Väga hea, et õssu tegid.

[tkardi]

[re:MET-605]
Metsaregistri andmetest on võimalik avaldada kaks andmehulka - eraldised ja eraldiste puuliikide rinnete kirjeldused. Eraldiste ja rinnete vahel 1-* seos, s.t ühel eraldisel võib olla kirjeldatud 1 kuni N erineva puuliigi rinnet. Väljendi "tabel" kasutamine edaspidi natuke meelevaldne, pean silmas WFS päringu typeName'i, samuti "veerg" = propertyName.

Atribuutandmete koosseis oleks tabelitel selline:

eraldis

shape - eraldise ruumikuju
id - eraldise identifikaator
invent_kp - inventariseerimise kuupäev
registreerimise_kp - registreerimise kuupäev
katastri_nr - katastriüksuse tunnus
kvartali_nr - kvartali tunnus
eraldise_nr - eraldise number
kuivendatud - true|false lipuke, mis näitab kuivenduse olemasolu
kasvukoha_kood - eraldise kasvukohatüübi kood
peapuuliigi_kood - eraldise peapuuliigi kood
omandivormi_kood - eraldise omandivormi kood

element

eraldis_id - eraldise identifikaator (s.t element.eraldis_id == eraldis.id)
rinde_kood - kirjeldatava taimkatte rinde tunnus (ainult esimene või selguseta, muude rinnete koosseisu ei saa avaldada)
puuliigi_kood - kirjeldatava puuliigi kood
osakaal - kirjeldatava puuliigi osakaal (rindes)
vanus - kirjeldatava puuliigi vanus (rindes) (inventariseerimise hetkel)
korgus - kirjeldatava puuliigi kõrgus (rindes)
enamus - true|false lipuke

Nendest veergudest eraldis.kasvukoha_kood, eraldis.peapuuliigi_kood, eraldis.omandivormi_kood, element.rinde_kood, element.puuliigi_kood oleks täidetud klassifikaatorite koodidega.

Kas vajalikud seotud klassifikaatorite koodidele vastavad kirjeldused esitada eraldi FeatureType'ina (või iga klassifikaator veel omakorda eraldi?) või oleks parem kui need oleks vastavasse tabelisse juba (lisaks koodi väärtusele) juba juurde lisatud? Ehk siis võimalused:

a) üks klassifikaatorite tabel struktuuriga: tabeli_nimi, veeru_nimi, kood, kirjeldus. Kasutaja ise peab siduma (kui peab vajalikuks)
b) iga klassifikaator omaette tabelina: kl_puuliik, kl_kasvukoha_kood, kl_omandivorm, kl_rinne. Iga klassifikaatori tabel struktuuriga: kood, kirjeldus. Kasutaja ise peab siduma (kui peab vajalikuks)
c) eraldi klassifikaatorite tabeleid pole, eraldis ja element tabelites on lisaks koodidele olemas ka vastavad kirjeldused. (kasutaja ise ei pea midagi siduma, kuid vahetatav andmemaht kasvab oluliselt).

Kuidas arvate/paremaks peate?

[tormi]

Üks väga oluline andmehulk tundub puudu olema - teatis (näide). See on katastriüksuse eraldistel (näide) lubatud tööde loetelu + metaandmed.

Ka tuleks lisaks eraldise puistu keskmisele vanusele ja puistu keskmisele kõrgusele kättesaadavaks teha puistu keskmine läbimõõt, sest seda kasutatakse teatise väljastamisel juhul, kui puistu ei ole raiumiseks piisavalt vana, kuid on piisavalt jäme.

[tiitmats]

metsateatised on oluliselt teistsugune andmehulk kui metsaeraldised ja nende avalikustamine on palju keerukam (õiguste mõttes). Põhimõtteliselt me soovime, et kõik metsateatised oleksid avalikud, alates sellest kui nad kehtima hakkavad, ja teistpidi soovime, et need ei oleks avalikud enam, siis kui nad on kehtivuse kaotanud. aga iseenesest on kiht olema ja ma (me) oskame kirjeldada ka avaldatava andmete koosseisu.
Puistu keskmist läbimõõtu (või õigemini küll puistuelemendi keskmist diameetrit) pole avalike andmete hulgas sellepärast, et mingitel tingimustel on selle alusel võimalik välja arvutada puude maht. Puude maht loetakse metsaomanike majandusseisu sisaldavateks andmeteks, ja selle tõttu ei saa neid avaldada.

[tormi]

Aitäh! Diameetrit kasutatakse raieteatise (sh lageraie) koostamisel juhul, kui vanus ei vea välja. Seega on need andmed (vanus ja diameeter) teatises kasutamise mõttes omavahel võrreldavad ja peaks seda olema ka avaldamise vaates.

[tiitmats]

Raieteatiste koostamisel kasutatakse (võib kasutada) ka teisi andmeid, mida me avalikult ei näita: rinnaspindala (täius) - harvendusraie kavandamise üks oluline tunnus, teise rinde/järelkasvu olemasolu.
Avaliku väljanäitamise aluseks ei saa olla kavandava raie aluseks olemine (sest seda saab teha metsaomanik, kes nagunii teab kõiki andmeid).

[tkardi]

@tiitmats, kas me saaks nt järgmine nädal (algab 18.09 kuupäevaga) teatiste andmete osas ka mingi atribuutandmete koosseisu nimekirja kokku panna? Ma tahaks gsavalik kihtide tagiks 0.4.3 metsaka kihid ka sisse panna ning püüda need septembri lõpuks (+ nädal?) livesse paigaldada. Alternatiiv (kui ei jõua järgmine nädal) oleks minna praegu edasi ainult eraldiste ja eraldis_elemendiga ning lisada teatised mingi hetk hiljem. Kuidas tundub?

[tiitmats]

Jah, mul läks natuke aega andmete ülevaatamisega. Aga koos teatise andmetega peaks avaldama ka metsakaitseekspertiiside (MKE) andmed (need on Metsaregistris oluliselt keerulisema struktuuriga), kuna ka need annavad raieõiguse.
Aga esialgu teatiste andmed.. Avalik peaks olema raieteatise andmestik, mis kehtib (teatis.olek=6 ja teatis.menetluse liik =T või L). Kehtivaid teatisi ei muudeta, vaid ainult tühistatakse ja arhiveeritakse (st meil on olemas ka muutmise protseduur, aga selle tulemusena tühistatakse vana teatis ja luuakse uus).
Teatis muutub kehtivaks, kui täidetakse otsus_kinnitatud_kp, teatis muutub kehtetuks, kui täidetakse arhiveerimise_aeg.
Avalikud teatise andmed:
teatis-tabel:
pind - teatise ala
teatise_nr - Teatise nr
katastri_nr - Katastritunnus
kvartali_nr - Kvartal
eraldise_nr - Eraldis
pindala - Pindala
too_kood - Tööliik
raiutav_maht - Hinnanguline raiutav maht (tm)
otsus - Kuna kuvatakse ainult JAH-otsused, siis ei sisalda see sisulist informatsiooni..
otsuse_pohjendus juhul kui pohjendus_avalik=true ?
otsus_kinnitatud_kp - Kehtiv alates (otsuse kinnitamise kuupäev)
Kehtiv kuni - arvutatav (otsus_kinnitatud_kp + 1 aasta – 1 päev).

Lisaks peaks yksus-tabelist (seos on teatis.yksus_id=yksus.id (n teatist ühe üksuse kohta)) lisama järgmised väljad:
nimi - kinnistu nimetus
kinnistu_nr - kinnistu number
metskond - Metskond
Ma eraldi üksus tabelit ei lisaks, sest see sisaldab palju muid üksusi ka.

[tiitmats]

Lisan ka esialgse MKE kirjelduse:
Metsakaitseekspertiisi (MKE) alad on kirjas valitoo-tabelis, mis on seotud tabeliga mke_akti_rida (mke_akti_rida.valitoo_id=valitoo.id, seos peaks olema 1:1le). mke_akti_rida on seotud tabeliga mke (mke.id=mke_akti_rida.mke_id, seos on 1 MKE: mitu MKE_akti_rida). mke on seotud tabeliga yksus (mke.yksus_id=yksus.id, samuti 1(yksus):n(mke) seos). Mõistlik oleks neis luua üks tabel.
Valikusse tuleks need alad kus mke_akti_rida.too_kood on täidetud ja mke.olek='KINNITATUD' (võib olla piisab ka kinnitamise kuupäeva kontrollist).
MKE andmed ei muudeta (st muutmisel tekitatakse uus MKE ja vana tühistatakse), ja ei arhiveerita (vajab täpsustamist). Kuna me soovime selliseid MKEsid avalikult välja näidata ainult ühe aasta jooksul kinnitamise kuupäevast, siis tuleks seda eraldi reeglina teha.
Avalikud andmed:
yksus.nimi - kinnistu nimetus
yksus.kinnistu_nr - kinnistu number
yksus.metskond - Metskond
valitoo.ala - geoobjekt
mke.akti_nr - MKE nr
valitoo.katastri_nr - Katastritunnus
valitoo.kvartali_nr - Kvartal
valitoo.eraldise_nr - Eraldis
MKE_AKTI_RIDA.soovitatav_raie_pindala - Pindala (ha)
MKE_AKTI_RIDA.too_kood - Tööliik
MKE_AKTI_RIDA.maht - Maht (tm)
mke.kinnitamise_kp - Kehtiv alates (MKE kinnitamise kuupäev)
Kehtiv kuni - arvutatav väli (MKE kinnitamise kuupäev + 1 aasta – 1 päev)

[Janek-K]

RMK eraldise andmed on täies mahus avalikud ja see info võiks olla ka selliselt teenuse kaudu kätte saadav.

[tkardi]

@Janek-K jah, eraldistes peaks olema nii era- kui riigiomandis olevad. Omandivorm on eristatav eraldis.omandivormi_kood järgi.

[Janek-K]

@tkardi RMK puhul peaks olema saadaval kõik kavas olevad andmed, mitte piiratud andmed nagu erametsa puhul. Vanas metsaregistris olid ka osad erametsa andmed täies mahus avalikud kui omanik seda ise soovis. Kui omanik saab ka uues registris oma andmed teha avalikuks, siis peaks olema kaks eraldise andmestruktuuri - kõikide kavas olevate andmete jaoks üks ja piiratud andmete jaoks teine.

[tkardi]

Ok. Nüüd ma sain aru :) Räägin mr inimestega, kuidas seda organiseerida. Ja aitäh kommentaari eest, Janek.

[Janek-K]

Vanas avalikus teenuses sai avada kaardi õige katastri asukohtaga kui kasutasid linki http://register.metsad.ee/avalik/?kataster=xxxxx:xxx:xxxx
Kas uues avalikus teenuses on võimalus kasutada otselinkimist?

[tiitmats]

me oleme mõelnud selle peale, aga hetkel Ei.

[tkardi]

@Janek-K kui pead silmas WFS teenust, siis jah, katastriga seotud eraldise saaks kätte GetFeature päringus cql_filter parameetriga:

?service=WFS&request=GetFeature&cql_filter=katastri_nr='xxxxx:xxx:xxxx'&...

cql_filter töötab ka WMSi jaoks, aga seal on vaja siis ka õiges suuruses/asukohas bbox päringusse kaasa panna.

[tormi]

@tiitmats, PURL on avaandmete lahutamatu osa, sellele tuleks edaspidi kindlasti mõelda. http://opendata.muis.ee/#purl-overview

[tkardi]

Heips, kuna see küsimus puudutab metsaregistri avalikku kaardirakendust https://mets-ave.envir.ee/, siis kas saaksite selle üles võtta nt mravalik@envir.ee? Ma tuletan meelde, et siin räägime "KeM avaliku GeoServeri teenuste kaardikihid ja SLD kujundused" teemal :)

[tormi]

Õige märkus ;) 25. sept 2017 08:24 kirjutas kuupäeval "Tõnis Kärdi" < notifications@github.com>: Heips, kuna see küsimus puudutab metsaregistri avalikku kaardirakendust https://mets-ave.envir.ee/, siis kas saaksite selle üles võtta nt mravalik@envir.ee? Ma tuletan meelde, et siin räägime "KeM avaliku GeoServeri teenuste kaardikihid ja SLD kujundused" teemal :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI9cDEb7E6nqOn_e54Kwnq_fE7pTnaAks5slzkHgaJpZM4OGnkY> .