Автоматизація ДЗК / 5 Архітектура АС ДЗК

5. Архітектура ас дзк

5.1. Функціональна схема ас дзк.

АС ДЗК є базовим компонент для побудови системи багатоцільового кадастру. Автоматизована система Державного земельного кадастру (АС ДЗК) призначена для автоматизації процесів формування і ведення державного земельного кадастру шляхом здійснення автоматизованих операцій оперативного збору, накопичення, аналізу кадастрових даних про землю і об'єкти нерухомості в цілях оперативного управління територіями.

Основною задачею автоматизації є підвищення функціонування системи державного земельного кадастру, що містить певну кількість часткових задач, а саме:

• забезпечення надійного і повнішого обліку відомостей про об'єкти кадастрового обліку, у тому числі і про їх правове положення. 

• підвищення оперативності і якості процесу ведення Державного земельного кадастру. 

• формування достовірної звітності для вищих структур, для місцевої адміністрації і інших органів управління. 

• обґрунтованість ухвалення рішення посадовцями органів управління. 

• оперативне формування і надання довідкової інформації про об'єкти кадастрового обліку фізичним і юридичним особам. 

Розв’язування перелічених часткових задач вимагає автоматизації основних процедур ведення земельного кадастру, до яких відносяться наступні:

• ведення кадастрового зонування;

• ведення чергового кадастрового плану;

• введення, зберігання і редагування інформації про об'єкти обліку - адміністративному базовому рівні, кадастрових зонах, кадастрових кварталах, земельних ділянках, частинах земельних ділянок, будівлях і спорудах, територіальних зонах; про суб'єктів права – юридичних і фізичних особах, органах влади; про документи – підставах для кадастрового обліку; про правові відносини – правах на земельні ділянки, обтяженнях, обмеженнях і сервітутах.

Для забезпечення гнучкої настройці конфігурації на конкретні задачі, що вирішуються на підприємстві або його підрозділі, а також використанні централізованої бази даних з повними і синхронними інформаційними потоками на всіх робочих місцях АС ДЗК повинна мати модульну структуру, в якій кожна підсистема може функціонувати самостійно. Модульність структури передбачає наявність функціональних підсистем, кожна з яких здатна виконувати певну функцію в процесі ведення земельного кадастру. До основних підсистем відносяться наступні:

• підсистема реєстрації(ПК “Інтерфейс спеціаліста по кадастру (облік земельних ділянок)”);

• підсистема проектування (ПК “Підтримка чергового кадастрового плану”);

• інформаційно-аналітична підсистема (ПК “Інформаційно-аналітичне обслуговування користувачів”);

• підсистема діловодства і документообігу (ПК "Обмін інформацією" (шлюз));

• підсистема реєстрації прав (ПК “Реєстрації прав”);

• підсистема адміністратора (ПК “Адміністратор АС ДЗК базового рівня”).

В дужках наведені відповідні назви клієнтських програмних комплексів АС ДЗК базового рівня, склад яких передбачений програмою створення АС ДЗКУ.

Функціональне призначення підсистем полягає в наступному:

Підсистема реєстраціїє основною підсистемою і дозволяє виконувати реєстрацію інформації про суб'єктів, об'єкти, документи і права в базі даних. Інформація поступає в систему від проектувальників за допомогою обмінних файлів, які перед реєстрацією досконально перевіряються. Серед основних перевірок можна виділити:

• перевірки коректності просторової інформації

• перевірки коректності семантичної інформації.

Під час виконання просторових перевірок вивчається відповідність досліджуваного об'єкту просторової моделі об'єкту обліку ДЗК. В ході перевірок досліджується коректність, як самого об'єкту, так і коректність просторово-логічних відносин між всіма просторовими об'єктами ДЗК. Загальна кількість перевірок, виконуваних над просторовими даними, коливаються від п'ятнадцяти до вісімнадцять залежно від типу об'єкту.

Під час виконання перевірок семантичної інформації дані, що поступають, перевіряються на повноту і відповідність встановленому формату, крім того, коректність реєстрованої семантичної інформації забезпечується гнучкою системою класифікаторів, які постійно обновляються відповідно до змін в чинному законодавстві.

Підсистема проектуванняпризначена для виконання робіт із створення об'єктів обліку ДЗК і підготовки відповідної технічної документації. Підсистема проектування дозволяє швидко виконати проектування об'єкту, уникнути просторових помилок, виключити помилки семантики. На підставі запроектованої інформації підсистема створює обмінний файл, який повинен подаватися на реєстрацію разом з паперовою документацією.

Інформаційно-аналітична підсистемаслужить для аналізу інформації і підготовки на основі цієї інформації різного роду довідкової і звітної документації. Дана підсистема забезпечує фіскальну функцію кадастру і дозволяє визначати грошову оцінку земельної ділянки з урахуванням всіх просторово-логічних відносин між складовими грошової оцінки. Підсистема повинна виконувати просторові запити з наданням необхідної семантичної інформації, як у вигляді екранних форм, так і у вигляді звітів, містити розвинений аналітичний апарат, одержувати статистичну інформацію за станом ринку землі по самих різних критеріях, а також володіти функцією самонавчання, що дозволить накопичувати, систематизувати, а також повторно використовувати запити до системи.

Підсистема діловодства і документообігудозволяє відстежувати вхідний, вихідний і внутрішній потік кореспонденції, що проходить через установу. Підсистема контролює своєчасність розгляду документа, підготовки відповіді, постановку на контроль. Відповідає на питання – у кого в даний момент на розгляді знаходиться документ? Дозволяє одержувати статистичні звіти про діяльність канцелярії. Дана підсистема може інтегруватися з підсистемою управління виробництвом, що дозволить відстежити весь виробничий цикл – від подачі заявки, до підготовки встановлюючого право документа.

Підсистема реєстрації правузагальнює функціонування підсистем реєстрації і проектування, реєструє права на землю та нерухомість, підготовлює встановлюючи право документи.

Підсистема адміністраторадозволяє контролювати процес виробництва технічної документації на підприємстві. Дана підсистема відстежує весь виробничий цикл, дозволяє з'ясовувати в якому стані знаходиться документація по тому або іншому об'єкту, які узгодження отримані, які ще належить отримати. Виконує моніторинг і аналізує хід процесу візування проекту рішення. Дозволяє одержувати статистичні звіти про хід виробничого процесу. Забезпечує зв'язок виробничого, фінансового і бухгалтерського обліку на підприємстві.забезпечує збереження, синхронність і коректність інформації в базі даних. Дозволяє настроювати авторизацію доступу і протоколювання дій користувачів, забезпечення безпеки інформації. Забезпечує ведення довідників і класифікаторів.

Взаємодія підсистем АС ДЗК зображена на рис. 5.1.

Рис. 5.1. Взаємодія підсистем АС ДЗК

5.2. Архітектура ас дзк

Програмний комплекс АС ДЗК будується за клієнт-серверною архітектурою, відповідно до якого програмний комплекс поділяється на клієнтську частину і серверну частину (рис. 5.2). Серверна частина встановлюється на сервер, клієнтська частина встановлюється на відповідні робочі станції.

Рис. 5.2. Клиєнт-серверна архитектура АС ДЗК

Дана архітектура передбачає наявність і використання централізованої бази даних з повними і синхронними інформаційними потоками на всіх робочих місцях АС ДЗК. Інформаційне наповнення бази даних умовно можна поділити на три складові блоки:

• реєстри;

• бази;

• списки.

Застосування принципу «інформаційних моделей земельних ділянок» передбачає використання комплексних даних, тобто просторові та атрибутивні дані не відокремлюються.

Як варіант, блок реєстрів містить у своєму складі:

• реєстр замовлень;

• реєстр сертифікатів;

• реєстр земельних ділянок;

• реєстр нерухомості;

• технічна документація;

• реєстр вихідних (сформованих) документів (державні акти);

• реєстр договорів оренди

• реєстр книг реєстрації;

• реєстраційні картки.

Такий склад реєстрів та реалізовані в системі інформаційні зв’язки між ними (рис. 5.3) дозволяють забезпечити наскрізну комп’ютерну технологію введення та використання даних на усіх основних етапах реєстрації об’єктів нерухомості, прав та обмежень. Це означає, що дані з різноманітних джерел, які вводяться в систему на початкових етапах реєстрації об’єкта нерухомості, після контролю і доповнення можуть бути безпосередньо передані в базу кадастрових даних, що і визначається побудовою розподіленої архітектури інформаційних систем (рис. 5.4).

Базимістять просторову і атрибутивну інформацію про адміністративний поділ території, суб’єктів права, функціональне призначення земель, та містять документи, що підтверджують право.

Списки, що містять бібліотеку про: види власності, угідь, сервітутів, обмежень, проїздів, населених пунктів, співробітників, оцінки, користування, документів, позначень і др.

Дані накопичуються в базі даних починаючи з реєстрації вхідних документів (заяв громадян та юридичних осіб, технічних звітів з даними про земельні ділянки в форматах XML, додаткових документів, що посвідчують права, особу та інше). Система забезпечує збереження як формалізованих відомостей (таких що вводяться беспосередньо в поля діалогових форм), так і електронних копій вхідних документів в цифрових форматах попередньо ”просканованих” документів або в форматах стандартних текстових редакторів. Для вхідних документів (основних та додаткових) по певному об’єкту нерухомості може бути відкрита електронна реєстраційна справа, яка логічно об’єднує документи в єдиний комплект. Усі дані підлягають вхідному контролю, включаючи перевірку топологічної коректності меж суміжних земельних ділянок, відомості про суб’ктів прав та документи, що підтвержують їх права. Верифіковані дані ”по команді” реєстратора передаються (копіюються) в реєстр земельних ділянок та базу даних прав, які власне і складають кінцевий результат реєстрації.

Рис. 5.4. Розподілена архітектура ГІС

Система просторових запитів АРМ’ів усіх типів реалізується за уніфікованою схемою взаємодії компонентів (рис 5.5) на основі набору клієнтських компонентів для роботи з електронними документами (е –документів), що надходять від сервера, інструментальної ГІС (програмного ГІС - сервера) та компонентів підтримки інтерфейсу взаємодії з користувачем через інтерактивні е-документи та електронні карти.

Для кожного реєстру в системі підтримується відповідний набір електронних XML-документів, діалогові форми їх створення, перегляду і редагування, а також інтерактивні електронні карти для відображення меж об’єктів на топографічні основі.

Рис.5.5. Узагальнена схема взаємодії компонентів системи

Програмний ГІС-сервер реалізує логічно розподілену архітектуру доступу до геопросторових даних та уніфікує інтерфейс взаємодії з ними як для програмних компонентів, так і для користувача. В поточній версії ГІС-сервер системи реалізує інтерфейс взаємодії з інструментальною ГІС MapInfo.

ГІС-сервер забезпечує виконання таких основних функцій по візуалізації електронної карти та доступу до бази гепросторових даних:

• формування проекту робочого картографічного простору у складі декількох тематичних карт на єдиному наборі шарів цифрової топографічної основи;

• редагування візуальних властивостей шарів в конкретних електронних картах;

• масштабування і переміщення карти у вказаному напрямі у вікні екрану;

• синхронізацію переміщення електронних карт, розміщених в декількох окремих вікнах;

• відображення місць розташування земельних ділянок, вулиць і адрес;

• відображення чергового кадастрового плану;

• введення та редагування координат меж земельних ділянок та угідь на електронній карті;

• введення та редагування кординат осьових ліній вулиць та точок прив’язки адрес;

• редагування проектних меж кадастрових зон та кадастрових кварталів з використанням шару меж земельних ділянок;

• запит атрибутивних даних для об’єктів, що вибрані користувачем на електронній карті.

• Компоненти СПЗ АРМ для усіх реєстрів забезпечують:

• отримання переліку зареєстрованих об’єктів (повного або по фільтру значень атрибутів, заданих користувачем);

• перегляд інформації про зареєстровані об’єкти і документи;

• редагування атрибутів та координат зареєстрованих об’єктів;

• доповнення реєстрів новими об’єктами;

• вилучення із реєстрів окремих записів;

• нормативну грошову оцінку земельних ділянок.

Усі перелічені функції доступні як в режимі роботи з інтерактивними списками зареєстрованих об’єктів, так і шляхом вибору відповідних об’єктів на електронних картах.

В свою чергу, для будь-якого об’єкта, вибраного в списку зареєстрованих, система підримує формування, візуалізацію та редагування його геопросторових (координатних) даних безпосередньо на електронній карті або в табличних форматах.

5.3. Адміністрування доступом в мережі

Для захисту інформації від несанкціонованої зміни або видалення рекомендується для різних користувачів розмежувати права доступу до даних. Розділення прав доступу до бази даних по своїй суті аналогічно розмежуванню прав доступу в локальній мережі (Рис. 5.6).

Як правило, базами даних встановлюються за умовчанням права користувачів (наприклад в Microsoft SQL Server 2005 public, db_owner, db_datareader і т. д.), серед яких слід наголосити на 4 основні ролі:

Адміністратор– адміністратор має право модифікувати будь-яку інформацію в базі даних, у тому числі класифікатори. Має право додавати, видаляти і редагувати список користувачів, розподіляти їх по ролях.

Користувач– привілейований користувач має право модифікувати будь-яку інформацію в базі даних, у тому числі класифікатори. Забороняється змінювати список користувачів і призначати ним ролі.

Оператор– оператор має право з використанням клієнтського ПО звістці реєстри даних (додавати, знищувати, змінювати).

Гість– користувач може діставати доступ до інформації тільки на читання.

При подальшому створінні користувачів даної бази даних необхідно привласнювати їм, по можливості, тільки ці ролі. Створення користувачів цієї бази даних з іншими ролями, а також зміна прав встановлюваних ролей є украй не бажаним, оскільки може спричинити за собою не передбачені розробником ситуації і, як наслідок, порушення цілісності даних.

Рис. 5.6. Доступ до даних серверу в локальній мережі

5.4. Напрями модернізації ас дзк

При розробці системи повинні бути передбачений можливості її подальшої модернізації при мінімальних часових і фінансових витратах по наступних напрямах:

• зміна системної платформи (операційна система, СУБД, геоінформаційні системи);

• зміна (доповнення і розширення) форматів і протоколів обміну даними;

• розширення списку послуг, що представляються організаціям і громадянам у видаленому режимі;

• розширення списку функцій, що автоматизуються;

• адаптація до змін норм законодавства і, відповідно, що автоматизується бізнес-процесів;

• розширення складу інтерфейсів введення і надання інформації;

• застосування нових вузлів ЕСД Кадастр, нових учасників взаємодії і, відповідно, нових бізнес-процесів;

• упровадження нових інформаційних технологій;

• технічне дооснащение і переоснащення системи.

Модернізація системи повинна проводитися на основі:

• адаптації стандартів системи до нових законодавчих і нормативних документів федерального рівня;

• розробки нових стандартів електронних документів;

• розробки нових типових бізнес процесів;

• розробки нових процедур електронної взаємодії.