Статья: Цифровая модель местности и ее использование в современных геоинформационных системах

С.Ю. Матвеев, В.А. Курочкин, И.С. Щвецов, С.И. Кемайкин

В статье рассматривается технология хранения и обработки цифровых карт в современных геоинформационных системах. Обсуждаются проблемы, связанные с использованием существующих подходов при создании сложных информационных систем, оперирующих с картографической информацией.

Одновременно предлагаются принципиально новый подход организации цифровой карты, основанный на объединении топологической, объектной и атрибутивной информации, а также методика хранения полученной таким образом цифровой модели местности в реляционных базах данных.

Сегодня программное обеспечение выходит на совершенно новый этап своего развития. Если раньше мы относились к программе или программному комплексу как к средству решения какого-то конкретного, зачастую ограниченного набора задач, то сейчас можно расценивать программные средства как часть более сложного программно-аппаратного комплекса, служащего для решения достаточно широкого спектра отраслевых задач. Характерным примером этой эволюции являются офисные приложения. Если раньше «электронный офис» представлял собой лишь набор отдельных средств создания и качественного оформления текста, таблиц, ведения примитивных баз данных, то теперь любой комплекс, предназначенный для серьезной автоматизации делопроизводства, включает в себя набор интегрированных друг с другом продуктов, развитые средства обмена информацией, управления расписанием и многое другое. Заметно, что практически во все программные комплексы вливаются средства для совместного ведения проектов и совместной работы с документами.

Одновременно с этим процессом мы начинаем совершенно по-новому смотреть на ряд, казалось бы, привычных понятий. Для примера возьмем понятие документа. Сегодня документ может вообще не существовать на бумаге, и тем не менее он будет подписан, получит все визы согласования, поступит во все необходимые подразделения организации. Реализация нового подхода к документообороту невозможна без дополнения понятия «документ» новыми свойствами. Вне сомнения, подобная эволюция представляет собой совершенно естественный и неизбежный процесс развития компьютерной индустрии. Следствием этого процесса является то, что многие «классические» понятия и объекты, будучи переведены в электронную форму, постепенно оказались частично, а зачастую и радикально, трансформированы.

Конечно, подобные трансформации не могли не затронуть геоинформатику, призванную упростить управление сложными территориальными инфраструктурами, хотя изначально ГИС (геоинформационная система) родились как средство создания и актуализации карт. Естественно, что электронные средства, предназначенные для издания карт, очень быстро вытеснили классические пластики, карандаши, перья. Несколько позже ГИС стали расценивать как средство интеграции атрибутивных и пространственных характеристик самых разнородных объектов, тем самым построив «мостик» между ГИС и СУБД (система управления базами данных). Поддержка проекций, построение тематических карт и, наконец, появившиеся средства поддержки топологии – все это следствие процесса осознания того, что ГИС представляет собой серьезное и, пожалуй, единственное средство управления все усложняющейся системой жизнеобеспечения человека.

Несмотря на эволюцию подходов и идеологии построения ГИС, понятие электронной карты почему-то оказалось слабо трансформировано. Карта как совокупность объектов каким-либо образом сгруппированных по слоям, вместе с присоединенными базами данных об атрибутике объектов остается неизменной достаточно долго. В то же время именно такая структура цифровых карт порождает множество проблем.

Классическое представление карты в виде совокупности объектов неизбежно влечет к нарушению топологической целостности модели территории, отражаемой картографическими материалами. Объекты так или иначе имеют общие границы, и естественно, что при изменении какого-либо из соприкасающихся объектов необходимо производить модификацию объектов-«соседей», что в целом усложняет процедуру создания и модификации карты. В большинстве случаев ошибки редактирования карт влекут за собой сложно устранимые дефекты топологической структуры. Конечно, возникающие ошибки в топологии были бы несущественны в случае, если бы нас интересовала только распечатанная на бумаге или пластике картографическая основа, но поскольку современные ГИС предоставляют средства измерений, развитые средства топологического и пространственного анализа, то любая ошибка такого рода повлечет за собой ошибки функционирования множества подсистем ГИС. Изменить ситуацию можно посредством «отщепления» от объектной модели карты информации о границах объектов в отдельный слой – слой топологии. При этом каждый из объектов сохраняет ссылки на свои границы. Редактирование карты в этом случае сводится к редактированию слоя топологии. Слой топологии часто называют дуго-узловой моделью, а к каждому из объектов, по сути дела, привязаны правила «сборки» объекта на этой дуго-узловой модели. Следует заметить, что такой подход, к сожалению, до сих пор остается нереализованным в большинстве геоинформационных систем.

Другой интересный аспект создания современных цифровых карт связан с хранением атрибутивной информации об объектах. Естественно, что атрибутивная информация в силу сложившейся системы управления территориальными инфраструктурами требуется более часто, чем пространственная. Здесь следует упомянуть различные формы, отчеты, сводные ведомости, строящиеся на основе атрибутивной информации. Фактически все управленческие задачи так или иначе опираются на СУБД. Именно по этой причине атрибутивная информация сосредоточена, как правило, в интенсивно используемой базе данных. А связь с пространственной информацией реализована посредством назначения индекса каждому из объектов карты.

Представим ситуацию, когда нескольким городским службам необходимо привязать к одному объекту карты свои базы данных. Какая из служб должна назначить индекс объекту? В соответствии с какими правилами должен быть назначен этот идентификатор, если каждая из служб имеет, как правило, собственную систему классификации и кодирования объектов? Кроме того, в каком из тематических слоев карты должен располагаться объект? Ведь практически каждая служба группирует объекты по-своему, зачастую используя не послойную, а более общую, иерархическую модель группировки.

Взглянув несколько критически на общепринятые в области цифровой картографии модели, можно подвести следующие итоги. Любая служба или отрасль работает в первую очередь с совокупностью каким-либо образом классифицируемых и проиндексированных объектов (к которым добавляются атрибутивные и пространственные характеристики). Пространственное расположение объекта должно в идеале представляться совокупностью его границ, взятых из дуго-узловой модели местности. Это приводит к тому, что для каждой конкретной области возможно и, более того, необходимо расщепление цифровой карты на объектную и пространственную модели местности. Объектная модель местности может быть представлена в виде иерархии, которая продуцирует способы кодирования объектов. Конечно, можно было бы говорить о более общей форме иерархии – многосвязном графе, но в силу, вероятнее всего, ограниченности человеческого мышления такое представление лишь усложнит манипулирование информацией и сделает невозможным построение столь удобных в обращении иерархических цифровых кодов объектов. Кроме того, применяемые на практике отраслевые классификаторы всегда однозначны. Объектная модель местности должна быть тесно связана с пространственной моделью, определяя этими связями четкое расположение объектов в пространстве. Схематически такую тополого-объектную цифровую карту можно представить в следующем виде (рис. 1.).

Рис. 1.

Однако мы совершенно упустили из виду атрибутивные характеристики объектов. А ведь именно они несут отраслевую специфику. Несложно представить, что таблица обычной реляционной базы данных может быть введена в эту схему совершенно безболезненно и логично (рис. 2).

Рис. 2.

По сути дела, то, что изображено на рис. 2, отражает необходимую и достаточную информационную схему для успешного управления находящейся в распоряжении какой-либо службы территориальной инфраструктурой. Естественно, что такая схема является упрощенной, поскольку она получается путем абстрагирования от тех характеристик объектов, которые с точки зрения данного вида профессиональной деятельности просто не рассматриваются, то есть эта схема представляет собой модель, а точнее, цифровую модель местности, с точки зрения определенной службы, отрасли, предприятия.

После того как мы представили все компоненты и структурные взаимодействия внутри цифровой модели местности, возникает резонный вопрос о том, каким образом осуществить техническую реализацию такого подхода? Каким образом хранить объектные иерархии, связанные с ними атрибутивные данные и пространственную модель территории? Ответ на этот вопрос не вполне однозначен. В классическом подходе ГИС отвечает за хранение пространственной и объектной модели, присоединенные базы данных – за хранение атрибутивной информации.

Представим на мгновение, что мы при решении своих задач отказались от карты. Естественно, что этот шаг ограничит спектр решаемых задач, но в то же время большинство задач можно будет решить, опираясь только на объектную модель и атрибутивную информацию. Множество предприятий и организаций в своей ежедневной работе просто не используют карту и ГИС-подход. Таким образом, если анализировать, что является основой для построения треугольника объектная модель – атрибутивные характеристики – пространственная модель (рис. 3), следует признать, что именно объектная модель, явно или неявно, является основой функционирования любой системы. Но такой выбор приводит к другому важному вопросу: чем отличается пространственная модель от атрибутивных характеристик объектов? Мы изначально разделили эти модели, более того, мы разделили средства хранения и обработки атрибутивной и пространственной информации. Все атрибутивные характеристики объектов лежат, как правило, в таблицах реляционных баз данных, в то время как пространственные характеристики – внутри геоинформационной системы, которая традиционно для их хранения использует обычные файлы. Существующее расщепление моделей не отличается особой логикой, в гораздо большей степени оно обусловлено историческими причинами развития ГИС. Это приводит, в свою очередь, к тому, что при обращении к атрибутивным данным обычно поддерживается механизм блокировок и транзакций – то есть многопользовательский доступ, в то время как для пространственных характеристик используются гораздо менее мощные механизмы обработки данных.

Рис. 3.

Все это не может не приводить к серьезным проблемам. Во-первых, существенно усложняется программное обеспечение для совместной обработки и анализа пространственных и атрибутивных характеристик объектов. Во-вторых, множество ГИС используют совершенно разные форматы хранения пространственных данных, зачастую принципиально несовместимые друг с другом. В-третьих, осложняется проблема многопользовательского доступа к пространственной информации, то есть сетевая многопользовательская ГИС за невысокую цену остается мифом.

Для решения проблемы достаточно взглянуть на пространственную модель местности немного с иной точки зрения. По сути дела, пространственная модель содержит границы объектов. Каждый объект имеет атрибутивные характеристики. Вполне разумным кажется интерпретация набора границ как дополнительных атрибутивных характеристик объекта. В этом случае представленная выше схема (рис. 2, 3) может существенно упроститься. Каждый объект характеризуется некоторым набором атрибутивных характеристик, в том числе и своими пространственными границами, которые также хранятся в таблицах реляционной базы данных.

Подобное объединение имеет ряд преимуществ, в том числе может решить проблему многопользовательского доступа, причем как для пространственных, так и для атрибутивных данных; появляется возможность создания единых средств пространственного анализа с привлечением атрибутики объектов; наконец, появляется возможность создания единой системы безопасности, регламентация прав доступа пользователей к данным цифровой модели местности. Также решается проблема совмещения форматов (в случае, если для представления цифровой модели местности в реляционных базах данных используются одинаковые правила). Более того, возможен переход к объемной модели, поскольку ничто не запрещает топологической (пространственной) модели представлять трехмерные границы объектов. В то же время при создании цифровой карты появляется возможность внесения в базу огромного количества характеристик, причем то, что окажется несущественным для решения каких-либо специальных задач, может быть отброшено тривиальным запросом.

Какой должна быть структура базы данных для хранения данных о цифровой модели местности? Естественно, что реляционная база данных накладывает существенные ограничения на представление данных. Двумерные таблицы серьезно ограничивают средства структуризации данных о цифровой модели местности. Традиционно информация об объектах, представленная в виде таблицы, выглядит следующим образом: запись в целом содержит информацию об объекте, а поля записи – атрибутивные характеристики объекта. Пример «классического» подхода показан в следующей таблице:

Однако подобное представление не может быть использовано для хранения информации о цифровой модели местности. Основная причина – «плавающее» количество атрибутов объектов. В первую очередь это обусловлено интерпретацией пространственных характеристик как атрибутивных. Вполне естественно, что различные объекты могут иметь различное количество атрибутов. Более того, при модификации карты количество атрибутивных характеристик объекта может существенно изменяться. Существуют подходы, кода изменению количества атрибутов соответствует динамическое изменение количества столбцов в таблице (прекрасным примером реализации такого подхода служит пространственный картридж ORACLE). Тем не менее этот способ приемлем отнюдь не для всех СУБД, более того, он неизбежно порождает ограничение максимального количества характеристик объектов. Преодоление ограничения возможно путем разбиения данных на две и более строки, но при этом неизбежно возникают сложности с типизацией полей таблиц и обработкой данных.

Выходом из сложившейся ситуации является подход, когда каждой атрибутивной характеристике соответствует только одна запись. В этом случае может использоваться таблица следующей структуры (в дальнейшем мы будем использовать термин «обменная таблица», смысл которого станет очевидным несколько позже):

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.

Сама возможность таких преобразований данных чрезвычайно важна, поскольку позволяет использовать стандартные, традиционные методы построения форм и отчетов, базирующихся именно на «классическом» представлении данных. В то же время благодаря обменному формату открывается возможность унифицированного межотраслевого обмена любыми дан...

ВНИМАНИЕ! Текст просматриваемого вами реферата (доклада, курсовой) урезан на треть (33%)! Чтобы просматривать этот и другие рефераты полностью, авторизуйтесь  на сайте: Ваш id: Пароль: РЕГИСТРАЦИЯ НА САЙТЕ