Open tormi opened 7 years ago
Saab ja peab :). Väga hea, et õssu tegid.
[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:
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
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?
Ü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.
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.
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.
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).
@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?
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.
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)
RMK eraldise andmed on täies mahus avalikud ja see info võiks olla ka selliselt teenuse kaudu kätte saadav.
@Janek-K jah, eraldistes peaks olema nii era- kui riigiomandis olevad. Omandivorm on eristatav eraldis.omandivormi_kood
järgi.
@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.
Ok. Nüüd ma sain aru :) Räägin mr inimestega, kuidas seda organiseerida. Ja aitäh kommentaari eest, Janek.
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?
me oleme mõelnud selle peale, aga hetkel Ei.
@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.
@tiitmats, PURL on avaandmete lahutamatu osa, sellele tuleks edaspidi kindlasti mõelda. http://opendata.muis.ee/#purl-overview
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 :)
Õige märkus ;)
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 https://github.com/e-gov/kem-gsavalik/issues/24#issuecomment-331780092, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI9cDEb7E6nqOn_e54Kwnq_fE7pTnaAks5slzkHgaJpZM4OGnkY .
Ei märganud, et metsaregistri andmed oleks siin kättesaadavad. Kas saaks/peaks?