Цифровая модель местности и ее использование в современных геоинформационных системах (стр. 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). Естественно, что для того чтобы произвести обмен данными между этими таблицами, необходимо, чтобы система импорта-экспорта могла выполнять переиндексацию информации, то есть необходимо определенным способом «уравнять» различные варианты индексации одного и того же объекта.