Цифрова модель місцевості та її застосування в сучасних
геоінформаційних системах
С.Ю. Матвєєв, В.А. Курочкін,
І.С. Щвецию, С.І. Кемайкін
В
статті розглядається технологія зберігання і обробки цифрових карт в
сучасних геоінформаційних системах. Обговорюються проблеми, пов'язані з
використанням існуючих підходів при створенні складних інформаційних
систем, що оперують з картографічної інформацією.
Одночасно
пропонуються принципово новий підхід організації цифрової карти, заснований
на об'єднанні топологічної, об'єктної і атрибутивної інформації, а також
методика зберігання отриманої таким чином цифрової моделі місцевості в
реляційних базах даних.
Сьогодні
програмне забезпечення виходить на абсолютно новий етап свого розвитку. Якщо
раніше ми ставилися до програми або програмного комплексу як до засобу вирішення
якогось конкретного, часто обмеженого набору завдань, то зараз можна
розцінювати програмні засоби як частина більш складного
програмно-апаратного комплексу, що служить для рішення досить широкого
спектру галузевих завдань. Характерним прикладом цієї еволюції є офісні
додатки. Якщо раніше «електронний офіс» представляв собою лише набір
окремих засобів створення і якісного оформлення тексту, таблиць, ведення
примітивних баз даних, то тепер будь-який комплекс, призначений для серйозної
автоматизації діловодства, включає в себе набір інтегрованих один з
іншому продуктів, розвинені засоби обміну інформацією, управління розкладом
і багато іншого. Помітно, що практично в усі програмні комплекси
вливаються кошти для спільного ведення проектів і спільної роботи з
документами.
Одночасно
з цим процесом ми починаємо абсолютно по-новому дивитися на ряд, здавалося б,
звичних понять. Для прикладу візьмемо поняття документа. Сьогодні документ
може взагалі не існувати на папері, і тим не менше він буде підписаний,
отримає всі візи узгодження, надійде в усі необхідні підрозділи
організації. Реалізація нового підходу до документообігу неможлива без
Розширення поняття «документ» новими властивостями. Поза сумнівом, подібна
еволюція являє собою цілком природний і неминучий процес
розвитку комп'ютерної індустрії. Наслідком цього процесу є те, що
багато «класичні» поняття та об'єкти, будучи переведені в електронну форму,
поступово виявилися частково, а часто і радикально, трансформовані.
Звичайно,
подібні трансформації не могли не торкнутися геоінформатику, покликану
спростити управління складними територіальними інфраструктурами, хоча
спочатку ГІС (геоінформаційна система) народилися як засіб створення і
актуалізації карт. Природно, що електронні засоби, призначені для
видання карт, дуже швидко витіснили класичні пластики, олівці, пера.
Трохи пізніше ГІС стали розцінювати як засіб інтеграції атрибутивних і
просторових характеристик самих різнорідних об'єктів, тим самим побудувавши
«Місток» між ГІС і СУБД (система управління базами даних). Підтримка
проекцій, побудову тематичних карт і, нарешті, що з'явилися кошти
підтримки топології - все це наслідок процесу усвідомлення того, що ГІС
представляє собою серйозне і, мабуть, єдиний засіб управління все
ускладнюється системою життєзабезпечення людини.
Незважаючи
на еволюцію підходів та ідеології побудови ГІС, поняття електронної карти
чомусь виявилося слабо трансформовано. Карта як сукупність об'єктів
будь-яким чином згрупованих по шарах, разом з приєднаними базами
даних про атрибутику об'єктів залишається незмінною досить довго. У той же
час саме така структура цифрових карт породжує безліч проблем.
Сучасні ГІС: проблеми створення цифрових основ
Класичне
представлення карти у вигляді сукупності об'єктів неминуче призводить до порушення
топологічної цілісності моделі території, що відображається картографічними
матеріалами. Об'єкти так чи інакше мають спільні кордони, і природно, що при
зміні якого-небудь з дотичних об'єктів необхідно виробляти
модифікацію об'єктів-«сусідів», що в цілому ускладнює процедуру створення та
модифікації карти. У більшості випадків помилки редагування карт тягнуть за
собою складно усунути дефекти топологічної структури. Звичайно, що виникають
помилки в топології були б несуттєві у випадку, якщо б нас цікавила
тільки роздрукована на папері або пластиці картографічна основа, але
оскільки сучасні ГІС надають засоби вимірювань, розвинені засоби
топологічного і просторового аналізу, то будь-яка помилка такого роду
потягне за собою помилки функціонування безлічі підсистем ГІС. Змінити
ситуацію можна за допомогою «відщеплення» від об'єктної моделі карти інформації про
межах об'єктів в окремий шар - шар топології. При цьому кожен з
об'єктів зберігає посилання на свої кордони. Редагування карти в цьому випадку
зводиться до редагування шару топології. Шар топології часто називають
дуго-вузловий моделлю, а до кожного з об'єктів, по суті справи, прив'язані правила
«Збірки» об'єкта на цій дуго-вузлової моделі. Слід зауважити, що такий
підхід, на жаль, до цих пір залишається нереалізованим в більшості
геоінформаційних систем.
Інший
цікавий аспект створення сучасних цифрових карт пов'язаний зі зберіганням
атрибутивної інформації про об'єкти. Природно, що атрибутивна інформація в
силу сформованої системи управління територіальними інфраструктурами потрібно
більш часто, ніж просторова. Тут слід згадати різні форми,
звіти, зведені відомості, що будуються на основі атрибутивної інформації.
Фактично всі управлінські завдання так чи інакше спираються на СУБД. Саме з
цієї причини атрибутивна інформація зосереджена, як правило, в інтенсивно
використовуваної базі даних. А зв'язок з просторовою інформацією реалізована
за допомогою призначення індексу кожному з об'єктів карти.
Уявімо
ситуацію, коли кільком міським службам необхідно прив'язати до одного
об'єкту карти свої бази даних. Яка з служб повинна призначити індекс об'єкту?
У відповідності з якими правилами має бути призначений цей ідентифікатор, якщо
кожна зі служб має, як правило, власну систему класифікації та
кодування об'єктів? Крім того, в якому з тематичних шарів карти повинен
розташовуватися об'єкт? Адже практично кожна служба групує об'єкти
по-своєму, часто використовуючи не пошарове, а більш загальну, ієрархічну модель
угруповання.
Карта як модель територіальної інфраструктури
Поглянувши
декілька критично на загальноприйняті в області цифрової картографії моделі,
можна підвести такі підсумки. Будь-яка служба чи галузь працює в першу
чергу з сукупністю будь-яким чином класифікуються і
проіндексованих об'єктів (до яких додаються атрибутивні і
просторові характеристики). Просторове розташування об'єкта має
в ідеалі представлятися сукупністю його кордонів, взятих з дуго-вузлової моделі
місцевості. Це призводить до того, що для кожної конкретної області можливо і,
більш того, необхідно розщеплення цифрової карти на об'єктну і
просторову моделі місцевості. Об'єктна модель місцевості може бути
представлена у вигляді ієрархії, яка продукує способи кодування об'єктів.
Звичайно, можна було б говорити про більш загальній формі ієрархії - багатозв'язних
графі, але в силу, найімовірніше, обмеженості людського мислення таке
подання лише ускладнить маніпулювання інформацією та унеможливить
побудова настільки зручних у зверненні ієрархічних цифрових кодів об'єктів.
Крім того, що застосовуються на практиці галузеві класифікатори завжди
однозначні. Об'єктна модель місцевості повинна бути тісно пов'язана з
просторової моделлю, визначаючи цими зв'язками чітке розташування об'єктів
в просторі. Схематично таку Тополя-об'єктну цифрову карту можна
представити в наступному вигляді (рис. 1 .).
Рис.
1.
Однак
ми зовсім випустили з уваги атрибутивні характеристики об'єктів. Але ж
саме вони несуть галузеву специфіку. Нескладно уявити, що таблиця
звичайної реляційної бази даних може бути введена в цю схему абсолютно
безболісно і логічно (рис. 2).
Рис.
2.
За
суті справи, те, що зображено на рис. 2, відображає необхідну і достатню
інформаційну схему для успішного управління знаходиться в розпорядженні
будь-якої служби територіальної інфраструктурою. Природно, що така схема
є спрощеною, оскільки вона виходить шляхом абстрагування від тих
характеристик об'єктів, які з точки зору даного виду професійної
діяльності просто не розглядаються, тобто ця схема являє собою
модель, а точніше, цифрову модель місцевості, з точки зору певної
служби, галузі, підприємства.
Передумови зберігання цифрової моделі місцевості в реляційних базах
даних
Після
того як ми представили всі компоненти і структурні взаємодії всередині
цифрової моделі місцевості, виникає резонне питання про те, яким чином
здійснити технічну реалізацію такого підходу? Яким чином зберігати
об'єктні ієрархії, пов'язані з ними атрибутивні дані і просторову
модель території? Відповідь на це питання не цілком однозначний. У класичному
підході ГІС відповідає за збереження просторової та об'єктної моделі,
приєднані бази даних - за зберігання атрибутивної інформації.
Уявімо
на мить, що ми при вирішенні своїх завдань відмовилися від карти. Природно,
що цей крок обмежить спектр вирішуваних завдань, але в той же час більшість
завдань можна буде вирішити, спираючись тільки на об'єктну модель і атрибутивну
інформацію. Безліч підприємств і організацій у своїй щоденній роботі
просто не використовують карту та ГІС-підхід. Таким чином, якщо аналізувати, що
є основою для побудови трикутника об'єктна модель - атрибутивні
характеристики - просторова модель (рис. 3), слід визнати, що саме
об'єктна модель, явно чи неявно, є основою функціонування будь-якої
системи. Але такий вибір призводить до іншого важливого питання: чим відрізняється
просторова модель від атрибутивних характеристик об'єктів? Ми від початку
розділили ці моделі, більше того, ми розділили засоби зберігання і обробки
атрибутивної і просторової інформації. Всі атрибутивні характеристики
об'єктів лежать, як правило, в таблицях реляційних баз даних, у той час як
просторові характеристики - всередині геоінформаційної системи, яка
традиційно для їх зберігання використовує звичайні файли. Існуюче розщеплення
моделей не відрізняється особливою логікою, в набагато більшій мірі воно обумовлене
історичними причинами розвитку ГІС. Це приводить, у свою чергу, до того, що
при зверненні до атрибутивним даними зазвичай підтримується механізм блокувань і
транзакцій - тобто багато-доступ, в той час як для
просторових характеристик використовуються набагато менш потужні механізми
обробки даних.
Рис.
3.
Всі
це не може не призводити до серйозних проблем. По-перше, істотно
ускладнюється програмне забезпечення для спільної обробки та аналізу
просторових і атрибутивних характеристик об'єктів. По-друге, безліч
ГІС використовують зовсім різні формати зберігання просторових даних,
часто принципово несумісні одна з одною. По-третє, ускладнюється
проблема багатокористувацького доступу до просторової інформації, тобто
мережева розрахована на багато користувачів ГІС за невисоку ціну залишається міфом.
Для
вирішення проблеми достатньо поглянути на просторову модель місцевості
трохи з іншої точки зору. По суті справи, просторова модель містить
межі об'єктів. Кожен об'єкт має атрибутивні характеристики. Цілком
розумним здається інтерпретація набору кордонів як додаткових атрибутивних характеристик
об'єкта. У цьому випадку представлена вище схема (рис. 2, 3) може істотно
спроститися. Кожен об'єкт характеризується деяким набором атрибутивних
характеристик, у тому числі і своїми просторовими межами, які також
зберігаються в таблицях реляційної бази даних.
Подібне
об'єднання має ряд переваг, у тому числі може вирішити проблему
багатокористувацького доступу, причому як для просторових, так і для
атрибутивних даних; з'являється можливість створення єдиних засобів просторового
аналізу із залученням атрибутики об'єктів; нарешті, з'являється можливість
створення єдиної системи безпеки, регламентування прав доступу користувачів
до даних цифрової моделі місцевості. Також вирішується проблема поєднання форматів
(у випадку, якщо для подання цифрової моделі місцевості в реляційних базах
даних використовуються однакові правила). Більш того, можливий перехід до
об'ємної моделі, оскільки ніщо не забороняє топологічної (просторової)
моделі представляти тривимірні межі об'єктів. У той же час при створенні
цифрової карти з'являється можливість внесення в базу величезної кількості
характеристик, причому те, що виявиться несуттєвим для вирішення будь-яких
спеціальних завдань, може бути відкинуто тривіальним запитом.
Представлення даних про цифрової моделі місцевості в рамках реляційних
СУБД
Який
повинна бути структура бази даних для зберігання даних про цифрової моделі
місцевості? Природно, що реляційна база даних накладає суттєві
обмеження на подання даних. Двовимірні таблиці серйозно обмежують
засобу структуризації даних про цифрової моделі місцевості. Традиційно
інформація про об'єкти, представлена у вигляді таблиці, виглядає таким
чином: запис в цілому містить інформацію про об'єкт, а поля запису --
атрибутивні характеристики об'єкта. Приклад «класичного» підходу показаний в
наступної таблиці:
ID
Attr1
Attr2
Attr3
0101
12
11.12.1999
Comment
0104
15
25.11.1987
Comment
Однак
подібне подання не може бути використано для зберігання інформації про
цифрової моделі місцевості. Основна причина - «плаваючий» кількість атрибутів
об'єктів. У першу чергу це обумовлено інтерпретацією просторових
характеристик як атрибутивних. Цілком природно, що різні об'єкти можуть
мати різну кількість атрибутів. Більш того, при модифікації карти
кількість атрибутивних характеристик об'єкта може істотно змінюватися.
Існують підходи, коду зміні кількості атрибутів відповідає
динамічна зміна кількості стовпців в таблиці (прекрасним прикладом
реалізації такого підходу служить просторовий картридж ORACLE). Тим не
менше цей спосіб прийнятний аж ніяк не для всіх СУБД, більше того, він неминуче
породжує обмеження максимальної кількості характеристик об'єктів. Подолання
обмеження можливо шляхом розбиття даних на два і більше рядки, але при цьому
неминуче виникають складнощі з типізацією полів таблиць і обробкою даних.
Виходом
зі сформованої ситуації є підхід, коли кожної атрибутивної
характеристиці відповідає тільки один запис. У цьому випадку може
використовуватися таблиця наступної структури (надалі ми будемо використовувати
термін «обмінна таблиця», зміст якого стане очевидним дещо пізніше):
HOI
HDC
DATA
VAL
0104
050723
11.12.1999
27
0104
050721
08.11.1999
45.5
0104
096782
21.10.1999
Текст
0105
050723
15.10.1999
97
HOI
- Hierarchy Object Identification (ієрархічний ідентифікатор об'єкта)
HDC
??? Hierarchy Data Classification (ієрархічний класифікатор даних)
DATA
- Дата/час внесення характеристики
VAL
- Величина
Єдиною
технічної складністю реалізації такого подання даних є зберігання
значення ознаки, оскільки різні атрибути можуть бути представлені різними
типами даних. Можна запропонувати кілька можливих варіантів вирішення проблеми.
Наприклад, використовувати в якості типу даних поля [VAL] тип BINARY або створити
в таблиці поля, що відповідають усім можливим використовуваним типів даних
(фактично розщеплення поля [VAL] на [VAL_INTEGER], [VAL_DOUBLE],
[VAL_STRING], [VAL_DATA], [VAL_BINARY] і т.д.). Коректність інформації,
поміщається в базу даних, може в цьому випадку забезпечуватися програмним
забезпеченням.
Існує
можливість простого перетворення таблиці такої структури в «традиційний»
варіант. Для цього досить у назві та коментарі до полів «класичної»
таблиці вказувати ієрархічний класифікатор даних (HDC) (рис. 4).
Рис.
4.
Сама
можливість таких перетворень даних надзвичайно важлива, оскільки дозволяє
використовувати стандартні, традиційні методи побудови форм і звітів,
базуються саме на «класичному» поданні даних. У той же час
завдяки обмінним формату відкривається можливість уніфікованого
міжгалузевого обміну будь-якими даними.
Раніше
вже згадувалася проблема «сприйняття» різними службами і галузями одного і
того самого об'єкта. Кожна зі служб відбудовує свою модель об'єкта, що несе
тільки ті характеристики та атрибутивні дані, які необхідні для вирішення
спеціалізованих, галузевих завдань. Однак проблема полягає не в
різноманітності виникають моделей, а в тому, що ряд характеристик об'єкта
дублюється в різних галузевих базах. Більше того, різні галузі для
одних і тих же об'єктів застосовують різні способи класифікації та кодування
інформації. Таким чином, проблема зводиться до того, яким чином здійснити
обмін суміжними характеристиками об'єкта, якщо є дві різні бази
даних, між якими необхідно здійснити часткову реплікацію інформації
так, як показано на рис. 5.
Рис.
5.
Відповісти
на поставлене питання досить просто, якщо використовувати обмінні бази
даних. Експортуючи інформацію з перших таблиці в обмінну, можна простим
імпортом з обмінної таблиці заповнити другу базу необхідними даними.
Неодмінною умовою такого обміну інформацією є однакова
класифікація типів даних. Таким чином, ми приходимо до того, що для
успішного обміну міжгалузевої інформацією необхідна однакова класифікація
типів даних. Наявність єдиного класифікатора типів даних не є з
практичної точки зору серйозним обмеженням, особливо в силу того, що
такого роду класифікатор повинен мати ієрархічну структуру. Завжди
існує можливість окрім введення різних загальних типів даних, наприклад,
геометричних характеристик об'єктів, вводити в цей класифікатор
спеціалізовані галузеві гілки, не порушуючи при цьому цілісності системи.
Слід
помітити, що якщо міжгалузевої класифікатор типів даних є цілком
прийнятним рішенням, то з об'єктним класифікатором виникають серйозні
проблеми. Кожна галузь виробляє своє поділ об'єктів на групи і
підгрупи, а як наслідок - проводить свою «політику» індексації (кодування)
об'єктів. У результаті цього два різних коду можуть описувати один і той же
об'єкт (приклад показаний на рис. 5, коду з точки зору однієї галузі об'єкт
ідентифікується як 0104, а з точки зору іншої як 072211). Природно,
що для того щоб зробити обмін даними між цими таблицями, необхідно,
щоб система імпорту-експорту могла виконувати переіндексацію інформації, то
Тобто необхідно певним способом «зрівняти» різні варіанти індексації
одного й того самого об'єкта.
Для
вирішення проблеми достатньо завести таблицю врівноваження об'єктів, яка
містила б усього дві колонки, в перший з яких був би перший ідентифікатор
об'єкта, а по друге - другий ідентифікатор. Така таблиця дозволила б у
випадку операції імпорту з обмінної таблиці виробляти міжгалузевий обмін
інформації. Необхідною умовою індексації об'єктів в цьому випадку є
унікальність галузевих ідентифікаторів об'єктів. Цього нескладно добитися,
вводячи в першу розрядах ідентифікатора об'єкта код галузі.
Однак
побудова таблиці врівноваження об'єктів призводить до проблеми, пов'язаної з
необхідністю виконання умови транзитивності. Якщо [код А] = [код B], а
[код B] = [код C], звідси випливає, що [код А] = [код С]. Поза сумнівом, пошук
всіляких транзитивних пар кодів об'єктів викличе суттєві проблеми при
інтерпретації вмісту таблиць. Рішенням проблеми є введення в систему
деякого системного коду, за допомогою якого і відбувається зрівнювання
об'єктів. У цьому випадку в першій колонці таблиці зрівнювання міститься
галузевої код об'єкта, у другій - його системний ідентифікатор. При цьому у
всіх галузевих «іпостасей» об'єкта системний ідентифікатор загальний. Якщо ми
виробляємо зрівняння об'єктів двох галузей вперше, то при вставці їх
ідентифікаторів в таблицю зрівнювання генерується будь-яке довільне
унікальне число - системний ключ. Якщо код одного з об'єктів вже присутня
в базі даних, то для доданих об'єкту привласнюється вже існуючий
системний ідентифікатор. Це просте правило дозволяє повністю уникнути
можливих колізій, оскільки вибір системного ключа довільний і його можна
змінювати і регенерувати в будь-який момент. Нескладно також представити
об'єднання декількох таблиць зрівнювання в єдину таблицю.
Слід
відзначити, що якщо галузеві класифікатори типів даних велися ізольовано і
як наслідок одна й та ж характеристика має різні коди в різних областях,
можна ввести таблицю зрівнювання і для класифікаційних кодів типів даних.
Однак це рішення не є кращим, оскільки надалі буде показано,
як саме міжгалузева таблиця класифікаторів даних може бути використана
для вирішення проблеми паралелізму інформації.
Таким
чином, обмінна таблиця і таблиця врівноваження об'єктів, а в гіршому випадку і
таблиця зрівнювання типів даних, можуть бути основою обміну та інтеграції
інформації між будь-якими галузями, більше того, вони є унікальним способом
дозволу колізій, породжених недосконалістю способів ведення господарської
діяльності та існуючою системою міжгалузевого документообігу.
Представлення
просторової моделі в рамках реляційної СУБД
Остання
проблема, рішення якої приводить нас до можливості реалізації повноцінної
цифрової моделі місцевості, полягає в способі приведення топологічної
просторової моделі місцевості до запропонованої вище структурі баз даних.
Основою формування будь-якої карти є точки. Але що таке точки в контексті
проведеної вище формалізації? Точки створюють топографи, геодезисти, які
представляють галузь, по суті справи, що вводить в єдину цифрову модель місцевості
нові об'єкти. Ці об'єкти мають свої галузеві ідентифікатори і, природно,
властивості, які виражаються координатами X, Y, Z. Геометричні
характеристики крапки, звичайно ж, є типами даних, які, у свою
чергу, мають класифікаційний код. Таким чином, цифрова модель місцевості
фактично поглинає точки як зовсім звичайні об'єкти. Більш того, часто
немає необхідності вводити об'єкти-точки, а можна відразу призначити властивості X, Y
і Z для будь-якого об'єкта, наприклад, труби, мосту, стовпа і т.д. Механізми
синхронізації, які детально обговорювалися вище, дозволять уникнути
дублювання або недостовірності інформації всередині бази даних, яка містить
модель місцевості. Можна навіть передбачити механізм пріоритетів у випадку, якщо,
наприклад, координата X з'явилася в об'єкта двічі з боку різних служб. Якщо
різних служб призначити коди, які з'являються як в ідентифікаторі
об'єкту, так і в ідентифікаторі типу даних, то координати об'єкту розумно
ввести як тип даних, що належать, наприклад, геодезичну службу. Якщо
будь-яка інша організація продублює координату у своїй базі з помилкою,
то вибір правильних даних допустимо зробити автоматично, слідуючи правилу,
що найбільш достовірні дані поставляє та служба, код якої в
ідентифікаторі об'єкта і ідентифікаторі класу даних збігається. Це автоматично
дозволить уникнути виникає паралелізму в зборі інформації.
Однак
кінцева мета - введення в таблиці, що зберігають інформацію про цифрової моделі
місцевості, топологічної просторової структури. У цьому випадку точки
є лише засобом побудови межоб'ектних кордонів. Самі кордону, в свою
чергу, є атрибутами об'єктів. У цьому випадку кордон можна також
інтерпретувати як об'єкт, властивостями якого є ідентифікатори точок.
Рис.
6.
Подібна
структура бази дозволяє вводити будь-які види кордонів, у тому числі використовувати в
як кордонів тривимірні поверхні. При цьому програмне забезпечення, «не
сприймає »Z-координату, буде відбудовувати звичайну двовимірну карту, але в
Водночас допустимо будувати і тривимірні моделі. Крім того, для точки або
кордону можна ввести додаткову атрибутику, тим самим доповнюючи карту
елементами картини (наприклад, нечіткі кордону). Аналогічним чином можна
ввести в модель місцевості посилання об'єктів на їх просторові межі.
Єдиною збереженою проблемою є впорядкування посилань кордонів на
точки та об'єктів на межі. Адже обравши з бази всю інформацію про точки лінії,
ми тим не менш не вирішуємо проблему побудови самої лінії. Це є
наслідком невирішеною проблеми пріоритету атрибутів. У принципі, серед
атрибутів об'єкта, що відносяться до одного класу (в наведеному вище прикладі всі
атрибути лінії відносяться до класу точок), може виникнути необхідність у
розстановці пріоритетів для однакових атрибутів. Вихід із ситуації достатньо
простий - достатньо лише ввести необов'язкове для заповнення поле пріоритету
атрибуту об'єкта. Для рівноправних атрибутів (наприклад, діаметр і довжина труби)
поле не використовується, у той час як в інших випадках воно може заповнюватися, і
при запиті до бази цифрової моделі місцевості по ньому може проводитися
сортування.
В
результаті ми приходимо до найпростішої структурі бази даних, коли повна
інформація про цифрової моделі місцевості може зберігатися в таблиці, що складається
всього з п'яти обов'язкових полів, причому при додаванні таблиці зрівнювання
об'єктів цифрова модель може служити централізованим сховищем для обміну
міжгалузевими даними. Завдяки обов'язковому полю дата/час з'являється
можливість зберігання та накопичення архівної інформації і, що особливо важливо,
архівної картографічної інформації. У цьому випадку, використовуючи фільтр по даті,
ми можемо побачити, яким чином змінювалася місцевість, коли з'являлися нові
будинки, об'єкти інженерної інфраструктури, а при необхідності можна відстежити
навіть сезонні зміни меж об'єктів, наприклад річок і боліт.
Таким
чином, єдина цифрова модель місцевості є принципово новим підходом
до зберігання даних у геоінформаційних системах, що відкриває можливість
побудови розподілених багатокористувацьких сховищ та архівів даних, з
можливістю забезпечення цілісності, несуперечності і коректності як
топологічної структури моделі, так і атрибутивних даних об'єктів.
Список літератури
Для
підготовки даної роботи були використані матеріали з сайту http://elib.albertina.ru
