Galimas techninis sprendimas integruotai CAD ir GIS sistemai

LGMS logotipas

Antrojo TAP GKTR 2.11.03:2013 svarstymo metu Nacionalinėje žemės tarnyboje mūsų sąjunga pasižadėjo pateikti pasiūlymus ir galimus techninius sprendimus kaip GKTR 2.11.03 atributikos pildymo alternatyvą. Žemiau pateikiame savo pastabas ir pasiūlymus, kurie buvo išsiųsti el. paštu Nacionalinei žemės tarnybai 2013-04-15.

Žinoma, labai laukiame kolegų pamąstymų ir pasiūlymų, kuriuos galite skelbti straipsnio komentaruose.

LGMS siūlomas techninis sprendimas integruotai CAD ir GIS sistemai

Atsižvelgdami į susitikimuose dalyvavusių suinteresuotų asmenų ir asociacijų pareikštas pastabas ir pasiūlymus “Lietuvos geodezininkų ir matininkų sąjunga teikia savo pastabas ir pasiūlymus prieš paskutinį planuojamą susitikimą rengiamo TAP GKTR 2.11.03:2013 klausimu.

Pagrindinė prieštara priimant naująjį GKTR 2.11.03:2013 reglamentą kyla dėl to, kad geodezininkai, pagrindiniai duomenų kūrėjai ir statistiškai CAD sistemų naudotojai, nesutinka savo ir savo užsakovų sąskaita pildyti įvairią atributinę informaciją, aprašančią įvairiausias realaus pasaulio objektų savybes. Tuo tarpu dalis erdvinių duomenų rinkinių  tvarkytojų, dažniausiai GIS sistemų naudotojų, erdvinių duomenų saugojime GIS formatu ir atributinių duomenų panaudojime mato apčiuopiamą naudą ir naudodamiesi geodezininkų sukurtais duomenimis planuoja  kurti pridėtinę vertę.

CAD ir GIS programinė įranga bei duomenų naudotojų poreikiai yra labai skirtingi – CAD PĮ pritaikyta greitam braižymui dvimatėje ir trimatėje erdvėje, tuo tarpu GIS PĮ pritaikyta įvairių analitinių uždavinių sprendimui, duomenų integravimui duomenų bazėse, jų pateikimui  įvairiuose interneto portaluose. Mums yra nesuprantamas šių dviejų skirtingų sistemų suliejimas į vieną. Geodezininkai, rengdami topografinius planus  yra tik pradinių, vektorinių duomenų gamintojai ir tvarkytojai. 

Suderinti šias dvi sistemas taip, kad duomenys cirkuliuotų tarp abiejų sistemų neiškraipomi, nesukeliant papildomų darbo sąnaudų nė vienai iš duomenų naudotojų pusių, yra gana sudėtinga.

Ne mažiau svarbu ir tai, kad atributinių duomenų pildymas bei konvertavimas tarp skirtingų duomenų formatų pareikalaus ženklių darbo sąnaudų (preliminariais skaičiavimais jos gali siekti 20%), o naujai siūlomame reglamente šios darbo sąnaudos užprogramuojamos geodezininkams, nors nei jie, nei tiesioginiai geodezinių darbų užsakovai nebus GIS duomenų naudotojai.

„Lietuvos geodezininkų ir matininkų sąjunga“ griežtai prieštarauja tokiam sprendimui – mes teigiame, kad GIS duomenis turi kurti tie, kurie iš jų kurs pridėtinę vertę, kitaip tariant – GIS duomenų pardavėjai turi būti ir jų kūrėjai.

Mes siūlome kompromisinį sprendimą, kuris gali tenkinti abi – tiek duomenų rengėjų geodezininkų, tiek duomenų tvarkytojų puses.

Pagrindiniai šio sprendimo akcentai yra šie:

  1. Vienu metu duomenų tvarkytojas palaiko dvi – CAD ir GIS duomenų bazes, užtikrindamas jų visiškai automatinį sinchronizavimą;
  2. Kiekvienas objektas turi unikalų identifikacinį numerį (ID), kuris leidžia objektą susieti dviejose skirtingose sistemose – CAD brėžinyje ir GIS duomenų bazėje;
  3. CAD brėžinyje nepildoma jokia objekto atributinė informacija, fiksuojama tik tiksli objekto padėtis dvimatėje ar  trimatėje (pageidautina) erdvėje;
  4. Visa objektų atributinė informacija kaupiama ir saugoma GIS duomenų bazėje, jos objektų geografinę padėtį automatiškai sinchronizuojant pagal objektų ID CAD duomenų bazėje;
  5. CAD brėžinio objektai, kurie tarnauja tik anotavimo tikslais, nėra sinchronizuojami su GIS duomenų baze, arba GIS duomenų bazėje sukuriamas ryšys tarp CAD brėžinio anotacijos objekto ir objekto, kurį šis anotuoja. Tai gali būti daroma tuo tikslu, jei planuojama automatizuotai ištaisyti CAD duomenų bazėje esančių anotacijų reikšmes pagal pakeistas objektų atributines reikšmes GIS duomenų bazėje.
  6. Braižydamas geodezininkas turi sekti tik vieną dalyką – kad patikslinus bet kokio jau esančio DWG duomenų bazėje objekto padėtį nebūtų prarandamas jo unikalus ID. Pvz. išbraižius objektą pagal naujas koordinates, jam turėtų būti perkopijuojamas seno, netikslaus objekto ID, o senasis objektas ištrinamas. Žinoma, gali būti tiesiog ištaisoma senojo objekto padėtis.
  7. Jei pateiktoje topografinėje medžiagoje geodezininko natūroje užfiksuoto objekto nėra, geodezininkas naujo ID objektui nesuteikia – tuo pasirūpina GIS duomenų bazės tvarkytojas.
  8. CAD duomenų bazės sluoksniai gali būti kuriami naujai siūlomo reglamento pagrindu, kuriame pateikiama loginė objektų grupavimo/kodavimo sistema.
  9. Geodezininkai neprivalo kurti GIS duomenų, jei to nereikia jo tiesioginiam užsakovui, tačiau esant poreikiui gali juos gauti iš duomenų tvarkytojo už atitinkamą mokestį, pageidaujamu formatu. Pavyzdžiui, geodezininkai gali užsisakyti jiem reikalingų komunikacijų, šulinių atributinius duomenis, kai tuo tarpu statinių, gatvių atributiniai duomenys jiems gali būti visiškai neaktualūs.

Programinės priemonės, kurių geodezininkui reikėtų unikalaus ID perkopijavimui, taip pat dubliuotų, neužpildytų ID tikrinimui ir pan., yra lengvai ir nebrangiai sukuriamos bet kuriai CAD programinei įrangai.

Unikalus objekto ID gali būti saugomas bet kurio objekto XDATA (Extended data – išplėstiniai duomenys), kurie yra palaikomi visuose DWG/DXF brėžinių formatuose.

Taip pat atkreipiame dėmesį, kad beveik visos savivaldybės turi CAD programinę įrangą ir specialistus, bent šiek tiek sugebančius dirbti su ja. Todėl sipnoms savivaldybėms nereikėtų didelių investicijų GIS programinės įrangos įsigijimui ir specialistų apmokymui tol, kol neatsiras tikras GIS duomenų poreikis.

Atkreipiame dėmesį į savivaldybių asociacijos rašte išdėstytą argumentą, jog Konstitucinio teismo 2004 m. gruodžio 13 d. nutarime pažymima, kad pagal Lietuvos Respublikos Konstituciją įstatymų leidėjas negali sukurti tokios teisinės situacijos, kai išleidžiamas įstatymas arba kitas teisės aktas, kuriam įgyvendinti reikia lėšų, bet tokių lėšų neskiriama arba jų skiriama nepakankamai.

„Lietuvos geodezininkų ir matininkų sąjunga“ mano, jog tol, kol nėra sukuriama konkrečios teritorijos GIS duomenų bazė ir neveikia teikiamų/gaunamų duomenų kokybės kontrolės sistema, bet kokių atributinių duomenų pildymas yra betikslis, dėl didelės jų praradimo tikimybės.

Siūlomas sprendimas numato, jog atributinių duomenų laukų kiekis, jų pildymo tvarka, paliekami GIS duomenų tvarkytojui ir gali būti apibrėžiamas kitais teisės aktais.

„Lietuvos geodezininkų ir matininkų sąjunga“ siūlo pašalinti atributinių duomenų aprašymą ir pildymą iš siūlomo TAP GKTR 2.11.03:2013, numatant unikalaus objekto ID naudojimą, nemokamų įrankių šio ID priskyrimui/kopijavimui ir pan. sukūrimą labiausiai paplitusiai CAD programinei įrangai Lietuvoje.

8 „Galimas techninis sprendimas integruotai CAD ir GIS sistemai“ komentarai

  1. Paulius Litvinas

    Keletas klausimų/komentarų:

    1. Minima CAD duomenų bazė. Svarbus klausimas kokie CAD objektai Jūsų nuomone tūrėtų būti naudojami objektam koduoti ir kokius jų parametrus kokiems objektams reikėtų saugoti, nes kaip suprantu pagrindinis uždavinys atkurti 100% grafinį vaizdą. Šioje vietoje tas turėtų būti tiksliai ir išsamiai apibrėžta (pvz. piketas. Jo atributai, atributo pozicijos ir pan.)

    Žinoma galima imti ir padaryti DWG brėžinyje naudojamos duomenų bazės(objektų saugojimui) kopiją ir kaupti visą informacija pilnai. Tačiau galimos problemos duomenų apjungime. Pvz. duomenų bazėje šlaitas saugomas 3D polilinija. Naujas pristatytas darbas su slaitu isreikstu 2D linija – kaip apjungti? Palikti neapjungtą?, arba atitinkamai reikia apjungti vieną „fitintą“ liniją su splainu ir pan. Didelis leidžiamų CAD objektų kiekis apsunkina administravimą (REGION,POLYGON, MPOLYGON, HATCH – tas pats objektas (jo atskiros dalys) gali būt išreikštas skirtingais CAD primityvais – vėlgi komplikuotas apjungimas).

    Turėtų būti kiek galima detaliau aprašyta kokiais CAD objektas kas koduojama.

    p.s. nesakau, kad tai turite padaryti Jūs – tiesiog į taip reikia atkreipti dėmesį ir tai apsvarstyti

    2. Išlaikyti ir sugaudyti unikalų objekto ID nėra taip paprasta. Netgi CAD komandos apdorodamos objektus dažnai ištrina originalų objektą ir į jo vietą sukuria naują – ObjectID – dings, Object Handler bus jau kitas.

    3. Turbūt labiausiai paplitusi CAD programa AutoCAD LT, kuriai negalimos jokios papildomos programinės priemonės.

    • 1. Unikalus ID turėtų būti suteikiamas tiems objektams, kurie turi sinchronizuotis su GIS duomenų baze. Pvz. krūmais apaugusio ploto ribai ID turi būti priskiriamas, o patiems krūmų sutartniams simboliams – ne. Dėl duomenų braižymo 2D ir 3D polilinijomis yra atskira kalba. Aš esu už visišką 3D modelį – tiek antžeminės, tiek požeminės situacijos, bet šiuo metu siūlomas GKTR reglamentas iš viso nenumato 3D  objektų, todėl tai ne šios diskusijos objektas.

      2. Prarandamas objekto ID yra mažiausias galimai prarandamos informacijos kiekis, lyginant su pilnai pildoma atributika. Kalbame būtent apie tai, kad apie objekto ID turi būti galvojama dirbant, sekama, kad jis nebūtų sugadintas. Lygiai taip pat ir šiuo metu turime galvoti apie tai, kad Object Data nebūtų gadinami, o vis dėlto tai vyksta nuolatos ir prarandami žymiai didesni informacijos kiekiai, nei objekto ID.

      3. Projektuotojai ir kt. užsakovai, dirbantys AutoCAD LT, nepanaudos nei SHP, nei XDATA, nei Object Data. Kalbame apie tai, kaip optimizuoti duomenų pildymą/apsikeitimą tarp geodezininkų ir savivaldybės.

  2. Negali būti jokių kalbų apie kažkokį unikalų ObjectID. Kaip susisies toponuotraukos brėžinys su duomenų kaupėjo CAD ar GIS duomenų baze yra tik išimtinai duomenų kaupėjo reikalas. O tam yra priemonių ir be kažkokio suteikiamo unikalaus ID. Jei LGMS siūlo vis dėl to naudoti atributą ObjectID, ir juo labiau, XDATA, tai geriau apskritai nieko nesiūlytų. Nei čia yra paprasta, nei panaudojama, nei nors kiek logiška naudoti XDATA. Tiesą sakant, tai visiškai bloga idėja ir mes kategoriškai jai prieštaraujame, jei jau naudotina nors kokia atributika, tai tada naudotina visa GIS atributika ir formatas SHP. O tai reiškia, kad visos LGMS pastangos – veltui.

    • Nebūtinai viskas veltui, c-gis.

      Pirma – yra dalinimasis idėjomis pagal savo kompetencijos lygį. Štai jau turime du komentarus, tai rodo, kad vyksta diskusija. Tuo tarpu iki šiol diskusijos nebuvo, visus įvarčius buvo stengiamasi mušti į vienus vartus.

      Antra – mes stengiamės ieškoti kompromiso, kadangi suprantame, jog yra ne tik geodezininkų poreikiai, bet ir valstybiniai. Valstybė nenori sumokėti už duomenis tiek, kiek turėtų, tačiau ir mes nenorime, kad mūsų darbų sąnaudos žymiai išaugtų.

      Trečia – kaip suprantu, esi patyręs duomenų tvarkymo srityje. Siūlyk konkretų sprendimą kaip tu jį matai, kaip techniškai išsprendžiamas duomenų sinchronizavimas, ypač, kai duomenys tikslinami, kinta jų geografinė padėtis. Kaip jie automatizuotai gali būti identifikuojami ir t.t., ir pan.

      Ketvirta – noriu sužinoti tavo nuomonę apie visiškai 3D duomenų kaupimo galimybę, atsižvelgiant į visus CAD sistemų niuansus, tokius, kaip negalėjimas vaizduoti sutartinių linijų tipų 3D polilinijoms ir pan.

      Tai galime padaryti bendraudami gyvai arba bendraudami čia, kad su mūsų idėjomis ir samprotavimais susipažintų kuo daugiau kolegų.

      • Vienas iš pasiūlymų apie 3D – polinijos gali būti ir 2D, bet ant kiekvienos viršūnės yra arba piketas su altitudės reikšme, arba altitudės tekstas. Gali būti įvairūs variantai, pvz., altitudės tekstas išjungtame sluoksnyje, tam tikro dydžio ar teksto stiliaus tekstas ir pan. Teksto įterpimo taškas sutampa su polilinijus viršūne. Arba – tiesiog 3D polilinija.

        Jei kalbėti apie atributiką – ją gali taip pat pakeisti arba tekstas, arba CAD blokai su atributais. Yra techninės priemonės tekstinę grafinę informaciją automatiškai įrašyti į reikiamo objekto GIS atributiką. Tai atrodo taip, sudaroma tokia užklausa (pvz): teksto, esančio tam tikrame sluoksnyje ir esančiame tam tikru atstumu nuo objekto reikšmė automatiškai įrašoma į objekto atributiką ir išeksportuojama. Dalyvauja tik CAD objektai, o GIS duomenų kaupėjas automatiškai gauna GIS duomenis. Užklausa yra nustatoma vieną kartą, o vėliau tik vykdomas eksportas – pažymima varnelė ant sluoksnio pavadinimo ir paspaudžiamas mygtukas.Vėl gi, techninės galimybės yra, bet tai duomenų kaupėjo rūpestis.

        Turėtų būti aprašyta, kaip yra kuriami CAD objektai. Pvz.: bloko objekto sluoksnis (viduje) turi būti toks, kokiame yra pats blokas. Plotiniai objektai neegzistuoja, nes tai yra GIS vizualizacija. Kokiuose sluoksniuose komunikacijos ir jų anotacijos, kokie blokų (cel’u) pavadinimai, tas turėtų būti aprašyta. Bet tai kompiuterinė braižyba, joks GIS’as, jokia atributika. Jei atsiranda nors koks negrafinis atributas, vadinasi grįžtam prie GIS. Jei reikalingas ObjectID, tai reikalingas ir GKODAS, ir BYLA ir kiti. Negali būti jokio ObjectID, tai – spąstai. O apie XDATA jau parašiau, siūlyčiau tiesiog pamiršti.

  3. Tvirtinu, kad,, projektuotojam t.y. architektam, tikrai nereikalinga nes SHP nei XDATA. Tikrai dauguma genplano brėžinius bei detaliuosius planus rengia AutoCAD programomis.

    • Projektuotojams SHP nepakenktų, bet toks turi būti užsakymas geodezininkui. Aišku, dažniausiai projektuotojai nežino, kas yra SHP.

    • Tomas Juozapavičius

      Na leiskite ir man prisidėti prie komentarų…
      Nesiciklinkit prie tų architektų ar projektuotojų. Toponuotrauka taip pat naudojama žemėtvarkos planavimo dokumentuose (kur z – nėra).
      Rengiant techninius projektus – kur tikrai reikalinga atributiką – prašau kaupkime mes juos, sudėliokime ir pan. Tai papildomas darbas reikalaujantis papildomo apmokėjimo.
      Tais atvejais kai smulkaus objektų detalumo nereikia – leiskit tiesiog parengti paparastą techinį planą, kurio tikslas atvaizduoti objektų vietas. Mano galva objektų detalumas, įskaitant ir atributinius duomenis, turi atsispindėti išpildomojoje nuotraukoje.
      Reziume – taisyklės neturi sukonkretinti teikiamų duomenų iki siūlomo lygio. Taisyklės turi aprašyti tik minimalius reikalavimus t.y. jokių *.shp, jokių atributų.

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *

Go back to top