Izskatās, ka mums ir iezīmēti gandrīz necik mikroliegumi https://data.gov.lv/dati/lv/dataset/mikroliegumi https://osmlatvija.github.io/Osmalyzer/Micro%20Reserves%20report.html
Teorētiski šos datus būtu automatizēti jāuztur, tāpat kā pārējās ĪADT.
Dāvis Kļaviņš said:
Teorētiski šos datus būtu automatizēti jāuztur, tāpat kā pārējās ĪADT.
Jā, labākais brīdis automatizēt, kamēr iezīmēti tikai kādi 1,5%.
P.s. Par liegumiem kopumā runājot: šobrīd publiskajā apspriešanā ir noteikumu projekts par 76 jauniem liegumiem:
"Noteikumu projekts [["Noteikumi par dabas liegumiem"]][ paredz noteikt 76 jaunus dabas liegumus un paplašināt 6 esošus dabas liegumus, tostarp aktualizējot šo teritoriju administratīvo iedalījumu atbilstoši Administratīvo teritoriju un apdzīvoto vietu likumam, kā arī visu dabas liegumu kartogrāfisko materiālu atbilstoši mūsdienu kartogrāfijas prasībām.
Noteikumu projekts kopumā paredz noteikt aizsardzības statusu 21 871 ha, tajā skaitā 2130 ha biotopam Veci vai dabiski boreāli meži, 480 ha biotopam Veci jaukti platlapju meži, 295 ha biotopam Lakstaugiem bagāti egļu meži, 18 ha biotopam Skujkoku meži uz osveida reljefa formām, 2088 ha biotopam Staignāju meži, 65 ha biotopam Ozolu meži (ozolu, liepu un skābaržu meži), 5 ha Nogāžu un gravu meži, 2813 ha biotopam Purvaini meži, 605 ha- Aluviāli meži (aluviāli krastmalu un palieņu meži), 8 ha biotopam - Ķērpjiem bagāti priežu meži."
Noteikumu projekts pieejams te: https://tapportals.mk.gov.lv/legal_acts/d0296438-1a87-40fc-9b9c-548fa94cfccf?fbclid=IwAR3FtW-W5LrVaE0awwv0C3GUxr29FuGu-oXgwRxmAMuRg1FmgEY6Y7Ui0HU#
Tas viss laikam bija sakarā, ka ES prasīja kaut kādu noteiktu skaitu liegumu teritoriju, bet mums nebija savākts tik daudz un tad kaut kāds finansējums nebūs, ja nesavāks. Tur vēl plānoja nomainīt statusu liegumiem ar to palielinot skaitu... tipisks risinājums :face_with_peeking_eye:
Pirms es kaut kur sāku rakstīt importa info, kādus tegus vajadzētu likt mikroliegumiem (bez buferzonām)? Piemēram, https://www.openstreetmap.org/way/894506883, kas ir no šī paša dataseta.
Cik es saprotu, tiem ir it kā jābūt vienkārši boundary=protected_area bez leisure=nature_reserve, ja nav citas informācijas. Tie ir paši par sevi liegumi nevis dabas parki. Var būt arī abi tegi, bet boundary tik un tā vienmēr pirmais. nature_reserve ir vairāk apmeklētājiem, bet te pārsvarā teritorijas ir vienkārši dabas gabali dēļ kaut kāda aizsardzības mērķa. Bet ja sakrīt ar dabas apmeklējamu vietu, tad būs tas leisure, bet tas ir katram individuāli jāskatās.
protect_class=4 - it kā ir pareizi priekš "Habitat/Species Management Area"? Bet es neko par šitiem nezinu. Vai Ozols lieto kaut kādas IUCN klases? Ir vēl protect_class=7, kas ir kā 4, bet bez IUCN. Bet tad arī ir kaut kādi protect_class=14, kas konkrēti kaut kādām sugām. Bet tad katram mikroliegumam ir dokumenti jālasa, kam tas veidots. Nezinu vai kāda no vērtībām datos to apraksta īsti, varbūt "Mikrolieguma tips".
protection_title=mikroliegums - kā piemērā tikai bez lielā sākumburta - tas nav īpašvārds. Tikai te ir vēl variants - "mikrolieguma teritorija", kas ir oficiālais nosaukums likumā. Nezinu, vai tas būtu labāk.
Bez name=* - tiem nosaukumu automātiski nav. Piemēros salikti name=Mikroliegums bet tas ir mapping for renderer. Personīgi, man nav nekas daudz pretīm šitiem, bet tas nav korekti un importam tas diez vai ies cauri. Dažiem ir reāli nosaukumi, kā https://www.openstreetmap.org/way/132054195, bet tikai šitajos datos tāda nav.
Pašlaik ir salikti ID_OZOLS=1826, bet tas nav pēc OSM ref principiem. Var ref:OZOLS=####. Vienkārši ref=#### laikam nederētu, jo tas nav oficiāls ref, bet konkrēti no ozols.lv sistēmas. Ja kaut kad likumos saliks citus ID, būs tizli.
Datos vēl ir citas visādas vērtības, kuras teorētiski var pielikt. Labs piemērs start_date=*, kas nemainīsies un nav jāuztur.
Ir "Mikrolieguma tips" - es nezinu, kas tas ir. Vērtībās sastopami visi cipari izņemot 1: 0, 2 .. 9. Mājas lapā piemēram "Mikrolieguma tips" "Putni" vai "Biotopi" vai "Bezmugurkaulnieki", bet tikai kurš cipars kuram (varētu datus ar viņu karti salīdzināt, bet to gan darīšu, ja reāli tas ir nozīmīgi)? Un kā to OSM norādīt. It kā protect_class ir speciāli kodi, bet ne visam.
Ir "Mikrolieguma objekts" ar vērtībās 0, 1, 2, 3 - arī nezinu, ko tas nozīmē.
ATIS kods ir visiem 7313100100, kas pēc likuma ir "mikrolieguma teritorija" - nezinu, vai to iekļaut vajag? Neesmu redzējis nekam citam, bet tas protams nav šķērslis (var visam citam arī likt).
Nekur Natura 2000 kodi un info nav datos, bet pēc piemēriem daudz kas importēts tieši no Naturas. Iespējams sakrīt teritorijas un var sasaistīt. Bet tikai tas jau atsevišķs imports vai arī šitais būs mega-sarežģīts.
Citas vērtības neizskatās lietojamas.
Protams, tas viss jāuztur. Bet cerams tas pats Osmalyzer reports varēs pateikt, ja datos vērtības vairs nesakrīt ar OSM. Automatizēt es nezinu kurš īsti ņemsies klāt. Varbūt pēc tam kad viss sazīmēts var.
Šeit datu lauki:
Field name (shapefile) Field type (shapefile) Field name (XML) Field label (XML)
ID Int32 ID ID
MR_OBJECT Int32 MR_OBJECT Mikrolieguma objekts
BUFFERZONE Int32 BUFFERZONE Buferzonas esamība
APPL_DATE DateTime APPL_DATE Iesniegšanas datums
EXPERT_DAT DateTime EXPERT_DATE Ekspertīzes datums
FROM_DATE DateTime FROM_DATE Izveides datums
AREA_DOC Double AREA_DOC Platība, ha (dokumentos)
MRCODE Int32 MRCODE ML kods
MR_TYPE Int32 MR_TYPE Mikrolieguma tips
ATIS_CODE String UNMATCHED UNMATCHED
ATIS_veids String UNMATCHED UNMATCHED
Shape_area Single UNMATCHED UNMATCHED
Shape_len Single UNMATCHED UNMATCHED
Tips un objekts - varbūt datu avots ir komunikabls un parāda, kur ir mappings.
Pirms ar to aizrauties - vai OSM to vispār varēs pievienot? Vai mēs reāli gribam izdomāt precīzākus protect_class priekš tiem? Vai vispār protect_class=4 ir pareizi bez UICN koda? Vai tik un tā visi nebūs protect_class=7?
Negribētos to info pazaudēt. Kaut vai kā tekstu pielikt pirmajā piegājienā, ja salāgot klasifikāciju neizdodas...
Nosūtīju jautājumu.
almost-got-me.png
Teorētiski es tipam varu QGIS sameklēt katram kodam piemēru un viņu saitā paskatīties, kam atbilst. Bet uuuuurgh.
Dubultrezervāts https://www.openstreetmap.org/way/372169773 https://www.openstreetmap.org/way/372173164
Atbildēja
MR_OBJECT vērtības:
0 – Nav definēts
1 – Biotops un suga
2 – Biotops
3 – Suga
MR_TYPE vērtības:
0 – Abinieki
1 – Rāpuļi
2 – Bezmugurkaulnieki
3 – Zivis
4 – Putni
5 – Zīdītāji
6 – Vaskulārie augi un paparžaugi
7 – Ķērpji
8 – Sūnas
9 – Sēnes
10 – Biotopi
Viņiem šo informāciju jāpieliek arī atvērto datu portālā. Kas tie par atvērtiem datiem, ja tur ir maģiskie skaitļi pa vidu?!
Datos ir 3060 mikroliegumi. OSM ir 39 liegumi (oranžās pļekas ar nosaukumiem), kas atbilst datu ģeomterijai.
mr-compare.png
No OSM esošajiem kādi 2/3 ir atzīmēti kā mikroliegumi, kur papildus vērtības jāpieliek.
Bet OSM ir daži, kas ir no kaut kādām Natura piemēram https://www.openstreetmap.org/way/132054279 vai citiem avotiem piemēram https://www.openstreetmap.org/way/29091118. Pēc ģeomterijas sakrīt ar mikroliegumu - bet vai tas ir kaut kāds cits tajā pašā vietā vai arī tas pats miikroliegums - ¯\_(ツ)_/¯
OSM kopā ir 420 nature reservu un/vai protected area (oranžie). Tie ne 39 vai nu nepārklājas (uzreiz izdzēsu) vai ir lielāki citas nozīmes liegumi, kurus mikroliegumi ir iekšā - tos, es manuāli izdzēsu paskatoties, kā izskatās.
osm-ter-all.png
Dažiem liegumiem daudz blusu
oh-no.png
Bet principā tā arī ir reāli, ka daudzi liegumi ir gandrīz pilni ar mikroliegumiem:
overlappy.png
No OSM esošajiem es atradu tikai vienu, kur liela kļūda ģeometrijā - https://www.openstreetmap.org/way/894519646 grupa
osm-ml-mist.png
Ko mēs daram ar buferzonām (sarkanie) mikroliegumiem (zilie)? Tie ir aptuveni pusei. buferzonas.png
Es piedāvāju neko nedarīt.
Pamazām rakstu importa lapu https://wiki.openstreetmap.org/wiki/Import/Latvia_Microreserves . Tur nelikšu daudz sīkāk, bet paspamošu šeit.
Datos kļūdu daudz neatradu, gandrīz necik. Bet ir daži gadījumi, kur poligonam līnija palēkā iekšā-ārā. Automātiski salabot gluži nevaru, jo tur starpība lielāka nekā datu parastā precizitātē - ja labošu, tad arī sačakarēšu pareizās vietas. Piemēram, ir speciāli izgriezumi vietās.
bunch-of-bad-inner-lines.png
deliberate-cutout.png
Daudz kur ir ļoti daudz punkti sabāzti. Nezinu, no kuriem dati oriģināli - ar roku, no terplāniem, vai no kā. Bet te var taisnas līnijas automātski novienkāršot.
overprecise.png
less-precise.png
Daudzi mikroliegumi pieskarās viens otram. Daudz kur ir precīzi izgriezumi.
touching-various.png
finely-cut-out-detail.png
Daudzi poligoni taisa self-touching - faktiiski multipoligoni bet ar vienu kopīgu punktu vai caurumu, kas vienā vietā tikai punkts.
not-multipolygon-but-0-width.png
hole-with-point-connection.png
Ir pietiekami piemēru, kas pārklājas. Ir daži, kur grūti saprast vai kļūda via kā.
overlapping-for-various-purposes.png
is-this-supposed-to-overlap.png
Man liekas, par visiem šādiem gadījumiem var rakstīt datu autoriem, lai uzlabot datu kvalitāti pirms importa.
Ideāli, jā. Bet tikai tad mēs līdz kurš viņ zin kad gaidīsim to visu. Jo tie dati ir teorētiski oficiāli apstiprinātas koordinātes papīros. Ja viņi maina, tad jāmaina katram mikroliegumam papīri, cik es sapratu. Jo īpašnieki pat tām zemēs saņem atvieglojumus un tur visiem precīzi sarakstītas lietas. Ja nomainīsies teritorijas izmērs/laukums, tad pēkšņi arī visi nodokļi utt. Tas man liekas ātri neies nekādīgi. Un mēs jau varam protams pateikt - jums tur kļūdas, labojiet. Bet kamēr nepateiksim konkrēti kur un kāda, diez vai kāds skries skatīties uz katru. Viņi tač pat leģendu datiem nevarēja uzrakstīt mājas lapā. Man tad tik un tā katra kļūda jāatrod un jānodokumentē. Es godīgi sakot brīvprātīgi nepiesakos pie tā visa. Piemēram, tā lieko punktu noņemšana ir burtiski katram otrajam. Varbūt par tām iekšlīnijām uzrakstīšu kaut kad.
Mikroliegumi var pieskarties un sakrist ar citu liegumu robežām visvisādos variantos.
next-to-another-reserve.png
touching-anotehr-multiple-time.png
touch-other-and-own.png
touching-multiple-other-reserves.png
complex-overlaps.png
Ir vietas, kur nav skaidrs, vai tam jāpieskarās. Vai OSM ne tā, vai datos ne tā, vai liegumu dati nesakrīt savā starpā vai arī nav nemaz sakrītoši.
is-this-supposed-to-touch.png
HellMap said:
Ir pietiekami piemēru, kas pārklājas. Ir daži, kur grūti saprast vai kļūda via kā.
overlapping-for-various-purposes.png
is-this-supposed-to-overlap.png
Otrais izkatās pēc kļūdas.
Izskatīties tā izskatās, bet tādu piemēru ir daudz. Un skaidrs, ka zīmēts ir no kaut kādiem mērijumiem nesalīdzinot ar esošu vai nākotnes robežu citam liegumam.
so-much-almost-touching.png
Par citiem liegumiem runājot, atvērtu datu tiem nav, tāpēc nevaru neko salīdzināt kopā.
Šie piemēri pa nesakritību jau ir kādas konferences lightning talk, ja liek klāt citu info, pilns :D
Tu droši varēsi uzstāties :saluting_face: Bet man ir ko citu darīt ;)
Izskatās, ka mikroliegumi, kuriem vēlāk pievienoti gabali tiek ielikti kā atsevišķi elementi. Citiem vārdiem, duplicēti ID. Tādi ir 3. Viens no otra atšķiras tikai datumi.
same-id-1.png
same-id-3.png
same-id-2.png
Interesanti. Tad sanāk varianti vai nu merge, vai atsevišķi ar individuāliem start_date?
Es domāju, ka merge un izmantot agrāko start_date. Savādāk tā jau sanāk vēstures pierakstīšana nevis aktuālās kartes. Es nezinu, kur citur OSM kaut kas saglabā tādas izmaiņas, piemēram teritoriju robežām.
HellMap said:
Daudz kur ir ļoti daudz punkti sabāzti. Nezinu, no kuriem dati oriģināli - ar roku, no terplāniem, vai no kā. Bet te var taisnas līnijas automātski novienkāršot.
overprecise.png
less-precise.png
No manuālas ģeometriju labošanas atturētos jebkurā gadījumā, jo, ja kādreiz šo datu uzturēšanu būs vēlme automatizēt, šāds manuālās labošanas ieguldījums tāpat tiktu nonests. Tā kā lieto QGIS, var šo pamēģināt šo. Vai atrast analogus risinājumus.
Jā, es skatos, ko varētu automatizēt. Bet tādi kā Simplify tur nestrādā - tur precizitāte pārsniedz kļūdas. Tāds Simplify thresholds, kurš izlabos kļūdas pie reizes sabojā visu pārējo ģeometriju. Es neesmu vēl atradis, kā to izlabot.
HellMap said:
Es domāju, ka merge un izmantot agrāko start_date. Savādāk tā jau sanāk vēstures pierakstīšana nevis aktuālās kartes. Es nezinu, kur citur OSM kaut kas saglabā tādas izmaiņas, piemēram teritoriju robežām.
Ja apvienot, tad start_date vēlākais, jo apvienotā teritorija stājusies spēka vēlākajā datumā. Otrs variants ir likt dažādus start_date (karte sanāk aktuāla, vienkārši dota informācija par to, no kura datuma kurš gabals ir stājies spēkā).
HellMap said:
Jā, es skatos, ko varētu automatizēt. Bet tādi kā Simplify tur nestrādā - tur precizitāte pārsniedz kļūdas. Tāds Simplify thresholds, kurš izlabos kļūdas pie reizes sabojā visu pārējo ģeometriju. Es neesmu vēl atradis, kā to izlabot.
Domāju to lietotāja definēto QGIS funkciju, kas skatās pēc azimutiem (pēdējā atbilde, uz kuru arī saite). Teorētiski vajadzētu strādāt, bet nemēģināju.
Ar punktiem uz vienas līnijas nav lielu problēmu, Simplify to izdara. Validity arī izlabo ģeometrijas kļūdas. Te problēma ar praktiski kļūdainiem punktim, kas kaut kur ne tur. Piemēram
tiny-error.png
actual-error.png
Tieši šitādām kļūdām vajag kaut ko kā https://gis.stackexchange.com/questions/72244/deleting-points-which-are-close-to-each-other bet tas nav vispārīgs risinājums - te vēl klāt 10 soļi
Hmm, jā, šādu gadījumu dēļ jēdzīgākais liekas pacelt slieksni Simplify (pēc konkrētā gadījuma spriežot pietiktu ar 5 cm, liktu Visvalingam metodi). Jā, izmainīs ģeometriju visur, bet, kamēr slieksnis nav liels, nebūtiski, ja skatās OSM datu lietojumu. Vienīgais, ka vietās, kur robeža loģiski pārklājas ar citām ĪADT, kas nav mikroliegumi, veidosies atšķirības. Ja to grib izslēgt, tad ģeneralizēšanas brīdī jāliek klāt arī pārējās teritorijas no OSM. Starp citu, QGIS Topology Checker rīks var noderēt, ja jau netiek izmantots.
Topology Checker pēc Validate/fix bez kļūdām.
Ar OSM esošajiem elementiem atšķirības ir no pāris metriem līdz pārdesmit līdz "nevaru pateikt, vai te vispār jāsakrīt".
A kā Simplify uzlikt attālumu nevis leņķi? Tur var tikai angle ielikt. Es meklēju citus variantus, bet neko neatradu.
simplify-angle.png
Visvalingam strādā labāk un var tikt vaļā no tiem izgriezumiem pārāk stipri nesabojājot pašu kontūru, bet tik un tā ir vietas, kur sabojā pat, ja es manuāli sameklēju pašu mazāko vērtību, lai nolīdzina izgriezumu. Piemēram:
matching-admin.png
but-bad-line.png
no-longer-matching.png
Atšķirība 1.5 metri, kas principā štrunts mežā. Bet tas paliks labošanai. Ar tādu daudzumu labošanai, ātrāk ir izlabot tos izgriezumus nekā visas robežas. Bet robežas automātiski pievienot es arī nezinu vai sanāks, jo te ideāls gadījums, kad punkti paņemti no robežu datiem uz to brīdi.
HellMap said:
A kā Simplify uzlikt attālumu nevis leņķi? Tur var tikai angle ielikt. Es meklēju citus variantus, bet neko neatradu.
simplify-angle.png
Lietojot datiem to oriģinālajā koordinātu sistēmā LKS-92 (EPSG:3059), jo rīks ņem vērā koordinātu sistēmas mērvienību. Uz WGS84 importēšanai OSM pārprojicētu pašās beigās. OSM dati aprēķiniem attiecīgi jāpārprojicē uz LKS-92.
...nekad nebūtu iedomājies, ka tas ir atkarīgs no projekcijas. Protams, es neko par koordinātu sistēmām īsti nezinu. Uzprasīju ChatGPT un uzzināju, ka tie ir divi sastopamākie varianti - distance un angular units.
Paeksperimentēju oriģinālajā LKS-92, bet tur Simplify ir jānorāda vismaz 4 metri, ja es gribu tikt no šitiem vaļā.
threshold-awaaay.png
Īpaši stipri tas nesabojā kontūras.
a-bit-broken.png
Bet faktiski man liekas tas ne ar ko neatšķiras no tā paša, kad es uzliku 0.0006 leņķi WSG84.
Man bail, ka šitiem izgriezumiem vajadzēs to darīt savādāk kaut kā ar kaut kādiem vertex merge vispirms.
Kāds ID tam, kuram 4 m lietoji?
1616
v.clean ar v.in.ogr snap tolerance 0,5
P.S. Atkārtojamībai QGIS var Graphical Modeler lietot.
O. Es protams nebūtu uzminējis, ka to sauc par "v.clean".... Neviens pat internetā neatbildēja ar to.
Visus manus piemērus ar šauro izgriezumu tas nonesa. Tur ir viens ekstrēmāks piemērs (vismaz, cik es vizuāli atradu) - bet uz to es arī necerēju un to labojot jau reāli sāks ģeomteriju bojāt.
xtreme.png
Pretējam piemēram, citās vietās viss liegums in nepilni 5 metri platunmā tiny-belt.png
HellMap said:
Visus manus piemērus ar šauro izgriezumu tas nonesa. Tur ir viens ekstrēmāks piemērs (vismaz, cik es vizuāli atradu) - bet uz to es arī necerēju un to labojot jau reāli sāks ģeomteriju bojāt.
xtreme.png
Šitādi brīnumi reāli būtu labojami izejas datos, ja vien nav kāds importa gļuks pēkšņi.
Jā, 2,6 m automātiski šādi nav labojami. Kā jau @Rihards Olups teica, normāli būtu jālabo publicētajos datos. Izņēmuma gadījumā gan var jau izlabot arī individuāli, atrunājot, kurš liegums un kura virsotne labota (vizuāli pietiktu izdzēst to, kas kā pīķis iesniedzas iekšā).
Vai arī importēt tādu, kāds ir, un pielikt komentāru, ka kļūda oficiālajos datos :)
Rihards Olups said:
Vai arī importēt tādu, kāds ir, un pielikt komentāru, ka kļūda oficiālajos datos :)
Tāpat cilvēki vai nu mēģinās labot kartē, vai nu rakstīs notes. Labāk salabot.
Man liekas optimistiski domāt, ka nākotnes importi atkal VISUS importēs nevis tikai jaunos vai izmainītos. Ņemot vērā, ka tie ir ar metru nobīdēm no citiem liegumiem un zonām, tad tie ar laiku tik un tā tiks sabīdīti, sapoligonēti, utt. Nākotnes importi diez vai kādreiz vēl aiztiks iepriekš importētos, ja tur nav liela starpība. Citiem vārdiem - nākotnē vajadzētu aprēķināt laukumu un neaiztikt tos, kas nemainās. Un tādu ar lielām izmaiņām diez vai būs daudz un iemesls nesakritībai drošvien arī būs OSM pusē. Es nesaspringtu par šīm kļūdām daudz un to, cik atkārtojami tie labojumi.
Atrāvu vaļā svaigākos datus, kvalitāte ~ tāda pati.
Vai kādam sanāca par to ziņot?
Last updated: Jan 22 2025 at 07:42 UTC