Никитина Ю.В. Никитин В.Н. Курс лекций Геоинформационные системы

Подождите немного. Документ загружается.

Группа специальных критериев включает в себя критерии, которые зависят от пред-

метной области и конкретной задачи. Примером могут служить цифровые карты, предназна-

ченные для анализа потокораспределения (на дорожных сетях, в трубопроводных сетях), или

цифровые карты, предназначенные для кадастра инженерных сетей. В последнем случае ин-

женерные сети (если, конечно, не показаны только каналы, как в случае теплопроводов)

должны быть разделены на сегменты, «разделителями» которых служат вентили, колодцы,

безвентильные врезки.

Корректность семантики. Этот критерий весьма значим, поскольку семантика явля-

ется важнейшей составляющей цифровой карты, и её проверка в большинстве случаев воз-

можна только путем визуального просмотра. Он включает выполнение двух основных требо-

ваний:

– корректность интерпретации условных знаков. Проверку корректности удобно про-

водить с использованием операции тематического выделения (создания тематической карты),

отобразив объекты условными знаками в максимальной степени приближенными к топогра-

фическим и отобразив характеристики объектов в виде подписей;

– корректность синтаксиса. Все объекты должны быть описаны посредством унифи-

цированной системы характеристик, которая, как правило, формулируется в виде классифи-

катора. Проверка синтаксиса включает: поиск синтаксических ошибок, «лишних» пробелов в

текстовых характеристиках, соответствие кодов характеристик или их расшифровок класси-

фикатору (если он имеется).

Корректность системы идентификации объектов. Большинство ГИС-программ ис-

пользуют для связи метрики и семантики назначаемые пользователем идентификаторы – це-

лые числа. Общее обязательное требование ко всем идентификаторам – уникальность.

В ряде случаев (например, при создании карт различных кадастров), к системе иден-

тификации могут быть предъявлены особые требования: упорядочивание по определенному

правилу, (например, «слева-направо», «сверху-вниз»), создание сквозной идентификации,

выделение диапазонов идентификаторов для каждого листа карты и каждого слоя, отсутствие

«пропусков» в идентификаторах. В случае сшитой карты большинство этих требований реа-

лизовать нетрудно, но если они предъявляются к карте, представленной физически не свя-

занным набором файлов, то требование об уникальности идентификаторов становится труд-

нореализуемым, особенно в случае, если имеется много объектов, продолжающихся с листа

на лист (так называемая сшивка по идентификаторам).

«Гладкость» и метрическая информативность. Рассмотрим только линейные объек-

ты.

Ломаная линия, представляющая собой контур линейного объекта, должна, во-первых,

быть как можно более «плавной», а во-вторых, точно передавать характерные изменения на-

правления объекта, например, прямые углы. Две наиболее распространенные ошибки цифро-

вания, порождаемые несоблюдением этих требований – это «скошенные углы» и «зубчатая

(зигзагообразная) линия» или, в частном случае, «выброс». Кроме того, линия контура ли-

нейного объекта не должна иметь систематических смещений относительно контура объекта

(рисунок 7.1).

Как известно, цифровые объекты представляют собой сегменты ломаных линий, ап-

проксимирующих изображения (границы) картографируемых объектов. При этом точность

аппроксимации может быть выбрана в широких пределах. Чрезмерное её уменьшение может

уменьшить метрическую точность всей карты в целом. Чрезмерное же её увеличение может

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

количества пикетов (или узлов) в ломаных линиях. При этом увеличивается время отрисовки

карты, время выполнения пространственных запросов и операций пространственного анали-

за.

Рисунок 7.1 – «Гладкость» и метрическая информативность объектов ЦТК

Оптимальным значением точности аппроксимации является такая, при которой сохра-

няется графическая точность цифровой карты.

Однородность выполнения правил формирования модели цифровой карты. Над одной

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

нология создания цифровых карт часто бывает недостаточно методически проработанной. По

этой причине цифровые карты могут обладать неоднородностью структуры. К наиболее рас-

пространенным ошибкам такого рода относятся:

– ошибки создания семантики (например, один оператор указывает «стр.», а другой

«строящийся») или объект вида «озеро с плотиной» в одном месте может быть указан как

просто «озеро», а в другом как «водохранилище»;

– ошибки топологии, когда, например, один оператор размещает «мост, не выражаю-

щийся в масштабе карты» на пересечение дороги и реки, а другой – только на дорогу, но

вблизи реки.

Количество подобных ошибок значительно уменьшается при соответствующей орга-

низации работ, при введении на производстве многоступенчатой (и независимой) системы

контроля качества.

Традиционная карта содержит большой объем информации, заданной в неявной фор-

ме, которую человек, читающий карту, легко понимает. Цифровая карта является моделью

местности, интерпретируемой программным обеспечением, и поэтому должна явным обра-

зом содержать описания этой информации. Данный тип информации может быть разделен на

3 группы: фундаментальная, производная и семантическая неявная информация.

К фундаментальной неявной информации отнесем топологические отношения и фор-

му объектов. Производная неявная информация включает отношения типа «вложение», «час-

тичное вложение», «пересечение» и т.д., которые легко могут быть получены путем выпол-

нения простых вычислительных процедур. Семантическая неявная информация – это отно-

шения между объектами, которые зависят от контекста, от картографической ситуации в дан-

ном месте карты.

Топологические отношения. Топологические или пространственно-логические связи

(ПЛС) объектов цифровой или электронной карты описывают пространственное расположе-

ние и логику взаимодействия между объектами, показанными на исходном картматеpиале.

ПЛС предназначены для повышения эффективности решения картографических задач

и задач цифрового моделирования земной поверхности.

Тополого-метрические отношения должны обеспечивать наличие общих точек пересе-

кающихся и стыкующихся объектов (линейных, площадных, точечных) или общего участка

метрики смежных объектов (линейных и площадных). Такие отношения не вредят при работе

с объектовыми форматами и в то же время принципиально необходимы для форматов, под-

держивающих только цепочно-узловую структуру описания, например ARC/INFO.

Создание корректной структуры ЦК зависит от возможностей программного обеспе-

чения и правильно поставленной технологии. Например, создание топологии в процессе

цифрования всегда предпочтительней, чем создание топологии автоматическим постпроцес-

сом, который почти всегда приводит к неконтролируемым изменениям точности (например,

объекты «притягиваются» друг к другу) и полноты (объекты «сливаются» или уничтожают-

ся).

Требования к передаче формы объектов. В природе существуют объекты, имеющие

«правильную» геометрическую форму: строения (многоугольники с прямыми углами), завод-

ские трубы (окружности) и т.д. При отображении на традиционной карте их форма искажает-

ся вследствие ограниченной графической точности.

При создании цифровой карты этот недостаток можно исправить в разумных преде-

лах: должны строго выполняться критерии, описанные в пункте «гладкость и метрическая

информативность». При выполнении корректировки формы объектов необходимо принимать

во внимание, что «неправильности» формы объекта могут отражать реально существующую

ситуацию.

Учет логики сочетания объектов. На карте существуют объекты, которые не могут

сочетаться друг с другом определенным образом (накладываться, пересекаться и т.д.). На-

пример, строение не может находиться в русле реки без острова или какого-либо другого

специального указания. Такие отношения будем называть недопустимыми. Примерами недо-

пустимых отношений также являются: пересечение «лес»–«озеро», пересечение «болото»–

«озеро», вложение «дом»–«озеро», пересечение «горизонталь»–«горизонталь» и т.п. Пере-

чень недопустимых отношений определяется логикой сочетания объектов карты, но лучше

всего, если он будет определен явно (например, как недопустимые отношения между некото-

рыми классами объектов) в техническом задании.

Логика сочетания объектов выражается, в ряде случаев, также и в регламентировании

их взаимного положения и даже их формы. Рассмотрим пример.

Горизонтали и русло реки, не выраженное в масштабе карты. Река течет по тальвегу

долины, т.е. там, где наиболее низко. В силу ограничений, накладываемых графической точ-

ностью, на цифровой карте реки могут слегка смещаться относительно тальвегов, что очень

хорошо видно в местах пересечения реки и горизонтали. Если на цифровой карте эта по-

грешность исправлена, значит перед вами карта высочайшего качества. Но необходимо пом-

нить, что исправляться должны горизонтали, а не русло реки.

Семантические отношения или связи. Появление этой группы отношений обязано

прежде всего объектам, которые принято называть «объектами, обозначаемыми подписью».

К таким объектам относятся: населенные пункты, стройплощадки, карьеры (на крупномас-

штабных картах), урочища и т.п. Они, как правило, показывают, что объекты, расположенные

на некотором, четко не определенном участке местности, имеют некоторую «общность». В

большинстве случаев для формирования этих отношений необходима дополнительная ин-

формация. Трудность при формировании подобного объекта состоит в том, чтобы определить

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

щих правил. Но в некоторых случаях, вероятно, можно ограничиться и просто размещением

подписи (например, для урочищ).

Контроль качества является важным этапом создания практически любой цифровой

карты. Выполнение части критериев может контролироваться только визуально (полнота, се-

мантическая корректность, частично точность), другая часть, в основном модельные крите-

рии, допускает определённую автоматизацию контролирующих процессов.

Контрольные вопросы

1. Корректность семантики.

2. «Гладкость» и метрическая информативность.

3. Требования к передаче формы объектов.

4. Учёт логики сочетания объектов.

Лекция 8

Интеграция пространственной и атрибутивной информации

Атрибутивные данные – это характеристики объектов, выражающиеся, как правило, в

алфавитно-цифровом виде. Например, адреса зданий, этажность, год постройки, количество

квартир или сведения об арендаторах земельных участков представляют собой информаци-

онные массивы, которые могут быть сведены в таблицы [102]. Там, где речь идет о таблицах,

применимо понятие реляционной базы данных (реляционная СУБД, РСУБД), как инструмен-

та манипулирования этими данными.

Преимущества реляционной модели данных слишком очевидны для того, чтобы про-

водить сравнительный анализ с другими моделями данных. К тому же на данный момент ин-

струментальное ПО, клиент-серверные решения, языки манипулирования данными, языки за-

просов и вся инфраструктура в целом для реляционных баз данных развита на порядок луч-

ше, чем для баз данных (БД), построенных по сетевой или иерархической модели.

Очевидна различная природа пространственных и атрибутивных данных. Соответст-

венно различны и методы манипулирования (хранения, ввода, редактирования, поиска и ана-

лиза) для этих двух составляющих цифровой карты. При попытках объединения данных в

единое целое часто это делается в ущерб одной из частей.

Одна из основных идей, воплощенная в традиционных ГИС – это сохранение связи

между пространственными и атрибутивными данными, при раздельном их хранении и, час-

тично, раздельной обработке.

На рисунке 8.1 приведен пример связи между пространственными и атрибутивными

данными. Записи в таблице, хранящей характеристики объектов, имеют в своем составе поле

идентификатора объекта. В свою очередь, объекты на карте также проидентифицированы.

Таким образом, осуществляется однозначная связь между пространственной сущностью объ-

екта на карте и информацией о нем из БД.

Одна из важнейших функций, осуществляемых этим механизмом, это выдача ответа

на запросы пользователя:

какая информация есть об объекте (объектах), который я вижу на карте? Напри-

мер, как называется этот населенный пункт, какова его площадь, состав населения и др.?;

где находятся объекты с определенными характеристиками? Например, показать все

аэродромы, имеющие бетонную ВПП длинной более 800 м.

Комбинируя такого рода запросы и пространственные запросы на принадлежность,

соседство, пересечение объектов, можно удовлетворить любые информационно-поисковые

нужды в любой сфере применения ГИС.

Можно выделить несколько уровней интеграции пространственных и атрибутивных

данных.

На самом низком из них пространственные и атрибутивные данные целиком отделены

друг от друга. Таким образом, пользователь вынужден иметь дело с двумя системами: гра-

фической и СУБД (рисунок 8.2). Как пример можно привести первые попытки добавления в

AutoCAD возможностей работы с базами dBASE, ранние версии WinGis, работающие с

СУБД Gupta. Такие решения внедрялись несколько лет тому назад и до сих пор используют-

ся. Очень много сил положено для состыковки двух программ и, соответственно, их данных.

ГИС

пространственная

база

данных

СУБД

атрибутивная

база

данных

ГИС

пространственная

база

данных

СУБД

атрибутивная

база

данных

Рисунок 8.2 – Схема взаимодействия подсистем при низком уровне интеграции про-

странственных и атрибутивных данных

По крайней мере, это неудобно, постоянно выходить из одной программы и входить в

другую (пусть это замаскировано интерфейсом и не заметно для внешнего пользователя). К

Объекты цифровой карты Семантические характеристики

Иденти-

фикатор

Характеристики

1 Река …

2 Луг …

3 Здание …

Рисунок 8.1 – Механизм связи пространственных и атрибутивных данных

тому же большая часть связи между пространственным объектом и его данными происходит

у пользователя в уме.

Более высокий уровень интеграции пространственной и атрибутивной информации

предусматривает наличие в составе ПО ГИС модулей управления внутренней базой данных.

Под внутренней БД понимается то, что данная ГИС умеет работать с реляционной БД без

привлечения каких либо дополнительных программных средств. Это типичное решение в

ГИС для персональных компьютеров (рисунок 8.3). Например, PC ARC/INFO, Maplnfo, MGE

Intergraph и GeoGraph имеют в своем составе небольшую реляционную СУБД.

ГИС

пространственная

база

данных

встроенная

СУБД

атрибутивная

база

данных

ГИС

пространственная

база

данных

встроенная

СУБД

атрибутивная

база

данных

ГИС

пространственная

база

данных

ODBC

атрибутивная

база

данных

ГИС

пространственная

база

данных

ODBC

атрибутивная

база

данных

а) б)

Рисунок 8.3 – Схема взаимодействия подсистем при наличии в составе ГИС модуля

для управления базами данных

а) ГИС содержит встроенную СУБД.

б) ГИС работает с БД через универсальные драйвера ODBC, IDAPI, BDE, ADO и т.д.

Конечно, о реляционности таких СУБД можно спорить. Понятие реляционной БД бы-

ло дано известным американцем Коддом. Первоначально в него входило 30 необходимых

критериев, которым должна удовлетворять СУБД, чтобы полностью поддерживать реляци-

онную модель данных. На сегодняшний день количество критериев возросло до 300. Навер-

ное, ни одна из существующих СУБД не удовлетворяет всем из них.

И конечно, СУБД-модуль в составе ГИС обычно обладает несколько меньшими воз-

можностями по сравнению с настоящей СУБД, но все же вполне подходит для решения мно-

гих задач, стоящих перед ГИС по отношению к базам атрибутивных данных:

– создание;

– ввод;

– редактирование (модификация);

– хранение;

– поиск (выполнение запросов);

– конвертация в другие СУБД;

– и, самое главное, это соотнесение, то есть привязка БД и распределенных (карто-

графических) данных.

В дополнение к этому некоторые ГИС поддерживают также и отношения один ко

многим, много к одному, и другие элементы реляционной алгебры. Здесь актуальным стано-

вится формат атрибутивных данных, которым оперирует ПО ГИС. Наиболее распростра-

ненными форматами БД на данный момент являются dBASE, Paradox, MS Access, форматы

данных электронных таблиц, ASCII-файлы.

Существует несколько вариантов реализации встроенной СУБД. В первом из них в ка-

честве оперативного формата выбирается один из популярных форматов данных или некий

«свой» формат (рисунок 8.3.а). Таким образом, все операции, проводимые ГИС с атрибутив-

ными данными, поддерживаются только для этого формата. Для использования данных,

представленных в других форматах, необходима их конвертация. Такими были предыдущие

версии всех распространенных на рынке ГИС. Этот путь прошли ArcView, Maplnfo, Inter-

graph, GeoGraph и другие ГИС. При этом достигается относительная простота использования

и, как правило, более высокая скорость работы с данными. Однако при использовании тех же

атрибутивных данных, что использует ваша ГИС, в других приложениях (например, при рас-

чете земельного налога), вам необходимо конвертировать данные и/или хранить их дважды.

Кроме того, разные форматы БД поддерживают разные типы данных. Ни один из них не яв-

ляется совершенным, поэтому все недостатки формата БД будут ощущаться на этой ГИС.

Во втором варианте реализации встроенной СУБД работа ведется с несколькими фор-

матами с использованием средств IDAPI, ODBC или аналогов (рисунок 8.3.б). Такие средства

позволяют ГИС несколько абстрагироваться от формата БД и, как следствие, работать с раз-

ными форматами почти одинаково хорошо. Подобные системы занимают сейчас лидирую-

щее положение на рынке. ArcView, Maplnfo, Intergraph MGE, GeoGraph обладают такими

возможностями.

Теперь при наличии атрибутивной информации нет необходимости ее конвертировать.

Нужно только осуществить пространственную привязку базы данных. Если почему-то вам

понадобились дополнительные возможности по манипулированию БД, вы можете воспользо-

ваться развитыми средствами «настоящей» СУБД. Недостатком же такого варианта является

работа с данными через драйверы форматов БД, разрабатываемые производителями СУБД и

сторонними фирмами. Не все из них представляют собой идеал, то есть иногда (не всегда)

снижается надежность и скорость обработки атрибутивных данных. Некоторую сложность

представляет настройка таких «многопрофильных» систем с помощью специальных конфи-

гурационных утилит.

И, наконец, наивысшая степень интеграции пространственных и атрибутивных дан-

ных предусматривает совместное их хранение и обработку.

Такие решения часто предлагаются отечественными разработчиками (рисунок 8.4.а)

(системы, ориентированные на использование «стандартных» форматов SXF, F1M – напри-

мер, ранние версии ГИС «Панорама»). К тому же федеральный стандарт формата данных

ГИС содержит в себе всю атрибутивную информацию, включая классификатор, и не подра-

зумевает существования других данных.

Плюсы такого подхода сомнительны, разве что иногда этот вариант лучше раздельно-

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

Как правило, структура атрибутивных данных не реляционная; как результат – сильно за-

труднены или вообще невозможны запросы к атрибутивной информации.

Если у пользователя есть необходимость использования атрибутивных данных в дру-

гих приложениях (например, при расчете маршрута следования автоколонны), необходимо

конвертировать данные и хранить их дважды. Это очень трудоемко, так как отсутствует ре-

ляционная модель данных и инструментарий для конвертирования.

Существует другой пример того же подхода, предусматривающий производство не-

которой надстройки над традиционной системой управления реляционными базами данных

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

стей современных СУБД по обработке данных (рисунок 8.4.б). Примером такого подхода

может служить технология Spatial Database Engine от компании ESRI, Inc. и MapInfo Spatial-

Ware, которые работают с большинством известных производителей СУБД, таких, как Oracle,

IBM, Informix и Microsoft. Однако такое решение требует серьезного участия производителя

СУБД и стоит недешево, иначе система превращается в БД с элементами графики, то есть от-

сутствует мощность пространственного аппарата настоящей ГИС.

ГИС

пространственная

атрибутивная

база

данных

ГИС

пространственная

атрибутивная

база

данных

ГИС

СУБД

пространственная

атрибутивная

база

данных

ГИС

СУБД

пространственная

атрибутивная

база

данных

а) б)

Рисунок 8.4 – Схема взаимодействия подсистем при наивысшем уровне интеграции

пространственных и атрибутивных данных

а) Хранение всей информации во внутренней базе данных.

б) Хранение всей информации во внешней СУБД.

Часто отечественные разработчики, автоматизирующие деятельность предприятия,

применяют в своем ПО такой подход. Бывает, что прикладные задачи, возложенные на ори-

ентированную на конкретное предприятие систему успешно реализованы, но достаточного

набора функций ГИС и продуманной структуры данных нет. Следовательно, применение та-

кой «ГИС» в другой области возможно только вместе с коренными изменениями ПО.

Контрольные вопросы

1. Атрибутивные данные.

2. Использование внешней СУБД.

3. Внутренняя СУБД: два варианта.

4. Совместное хранение данных: два варианта.

Лекция 9

Технологии совместного использования данных

Существует две технологии совместного использования данных: файл-сервер и кли-

ент-сервер.

Технология «файл-сервер» заключается в выделении специализированного компьюте-

ра (сервера) для хранения файлов с данными. Доступ к единому набору файлов осуществля-

ется с каждого компьютера в отдельности. Совместная обработка данных в такой системе ог-

раничена, так как не предусмотрено никаких средств для разрешения конфликтов при одно-

временном изменении данных разными пользователями.

Технология «клиент-сервер» также предполагает использование выделенного компь-

ютера для хранения данных, однако пользователю предоставляется доступ не к файлам, а к

некоторому сервису (набору процедур и функций), осуществляющему управление данными.

Это обеспечивает:

– высокую степень масштабируемости и независимости от аппаратных средств;

– очень высокую эффективность обработки данных;

– реальную возможность применения распределённых БД;

– работу со сверхбольшими базами данных (миллиарды записей/объектов).

Возможно два варианта реализации клиент-серверной ГИС:

1. Сервер пространственных баз данных является отдельным программным продук-

том. Этот вариант сложен в реализации и в мире ГИС еще не удалось его воплотить в полном

объеме. Только ARC/STORM (ESRI, Inc) может использоваться как реально действующее

решение. В качестве ПО клиентов возможно использование продукции этой же фирмы.

Однако с появлением технологии ArcSDE это направление осталось только в виде

продукта ArcSDE для покрытий, который обеспечивает возможность чтения покрытий, шейп-

файлов, слоёв ArcInfo LIBRARIAN и слоёв ArcStorm через любую сеть с протоколом TCP/IP

по интерфейсу ArcSDE и предназначен прежде всего для обеспечения плавного перехода к

ArcSDE для РСУБД.

2. Сервер пространственных баз данных является надстройкой или дополнением к су-

ществующему серверу реляционной БД. Реализация такого сервера пространственных БД

опирается на использование другого программного продукта (например, ORACLE) и автома-

тически добавляет его стоимость и правила лицензирования к стоимости сервера пространст-

венной БД как таковой. Кроме того, не всегда удобно использовать реляционную модель для

хранения некоторых типов пространственных данных. Это касается в основном топологиче-

ской модели пространственных данных.

С другой стороны, большую часть задач распределенной БД ГИС берет на себя про-

дукт, который уже длительное время использовался для целей обработки данных и прекрасно

зарекомендовал себя.

Компания ESRI, Inc выпустила программный продукт этого класса. Он называется

Spatial Database Engine или ArcSDE. Это служебное программное обеспечение для связи

ГИС-приложений с системами управления реляционными базами данных. Оно построено на

клиент-серверной технологии и предназначено для хранения, управления и быстрого получе-

ния пространственных данных из РСУБД, таких как Oracle, Microsoft SQL Server, IBM DB2 и

Informix [98].

Продукты корпорации MapInfo также используют подобный механизм доступа к дан-

ным. MapInfo Professional 6.5 может выступать в качестве клиента SpatialWare 4.5 с сервера-

ми баз данных IBM DB2 и Informix, Microsoft SQL Server 7 и Microsoft SQL Server 2000, Ora-

cle Spatial.

Методы хранения и извлечения пространственной информации ГИС MapInfo и ESRI в

различных промышленных СУБД значительно различаются, поскольку возможности послед-

них в плане работы с пространственными данными не одинаковы. Одна из наиболее полных

реализаций системы хранения пространственных данных осуществлена при использовании

объектно-реляционной СУБД компании Informix.

Сервер Informix Dymanic Server.2000 позволяет создавать и поддерживать принципи-

ально новые типы данных: если в классических СУБД можно работать с полями типа integer,

float, boolean и т. д., то в рамках IDS.2000 существует возможность создавать собственные

пользовательские типы данных, для которых разрабатываются соответствующие функции,

хранящиеся в виде разделяемых библиотек. Например, определив такой тип пространствен-

ных данных, как полигон, можно определить и функции, вычисляющие площадь этого поли-

гона. Для двух полигонов можно определить функции сравнения — пересекаются ли они и

если да, то какова их общая часть, и т. д.

Помимо этого, Informix Universal Server позволяет строить нетривиальные индексы,

обеспечивающие быстрое выполнение запросов к массивам данных новых типов. Каждый

разработчик, имеющий дело с нетривиальными типами данных, изобретает свой собственный

механизм поиска объектов с помощью индексов.

Базы очень большого объема в геоинформатике не редкость, и если запросы к ним на-

правлять напрямую, без индексирования, то среднее время их выполнения будет очень боль-

шим.

Методы пространственного индексирования пространственной информации, храня-

щейся в СУБД, как правило, сводятся к делению пространства, содержащего географические

объекты, на некоторые условные квадраты или прямоугольниКи (рисунок 9.1). Такая схема

позволяет при обработке запроса выполнять двухуровневый поиск: сначала из базы через ин-

декс с помощью приблизительного алгоритма выбираются потенциальные объекты, а потом к

предварительно отобранному множеству применяются более сложные алгоритмы, позво-

ляющие точно определить нужные объекты.

Grid File Quad-tree R-tree

Рисунок 9.1 – Методы индексирования пространственных данных

В СУБД Informix Universal Server реализован индекс R-Tree, разработанный для соз-

дания индексов одно-, двух- или трехмерных пространственных объектов и комбинирован-

ных данных, которые обрабатываются как многомерные (как, например, сведения о доме,

включающие число этажей, комнат, общую и жилую площадь и т. д.). С помощью этого ме-

тода можно индексировать и диапазонные данные (например, телевизионные программы, пе-

редаваемые в период с 9:00 до 10:30). Индекс R-Tree обеспечивает также двухуровневое вы-

полнение запроса, но при этом он не делит пространство на условные равные квадраты, а

вписывает каждый объект (или группу объектов) в свой собственный прямоугольник. Прямо-

угольник может включать как объекты, так и другие прямоугольники.

Модули СУБД Informix Universal Server, позволяющие подключить к серверу БД но-

вые типы данных вместе с функциями, с ними работающими, и соответствующими система-

ми индексации, называются DataBlade. Для сервера Informix 9.x существует три различных

DataBlade-модуля для хранения пространственных данных в Informix Universal Server:

– модуль системы работы с пространственными данными, реализованный компанией

ESRI;

– SpatialWare DataBlade компании Maplnfo;