СТРУКТУРИРОВАНИЕ ГЕО-ДАННЫХ ПРИ ПОСТРОЕНИИ ИНФОРМАЦИОННЫХ СИСТЕМ

на основе реляционной модели

 

А. Левин                                                                                               Экоцентр МТЭА

Содержание

Предисловие

Пространственные структуры: точки с координатами

Пространственные структуры: точки с трассами

Пространственные структуры: слои и скважины

Пространственные структуры: реки и трассы

Географическая основа

Основные географические справочники-классификаторы

Основные географические числовые домены

Соотношение БД и ГИС на разных стадиях проекта

Преимущества подхода

Литература, источники информации

 

Предисловие

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

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

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

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

Построение информационных систем такого ранга обладает своими особенностями:

·         Большим разнообразием пространственных и географических данных. Представлена практически вся природная среда: поверхностные и грунтовые воды, инженерно-геологические данные, флора, фауна, инфраструктура региона и объекты строительства;

·         Сжатыми сроками запуска первой очереди системы, и вместе с тем долгой  жизнью системы в целом;

·         Ориентацией системы главным образом на выпуск ответственной проектной документации, в том числе картографического материала;

·         Участием многочисленных организаций - поставщиков данных.

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

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

Географическая основа информационной системы, включающая пространственные данные и географические объекты. На этот каркас нанизаны все остальные данные: химических анализов, физических измерений, биологических наблюдений, тематического картирования и т.п.

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

Структуры данных в противовес программным процедурам. Тщательность проектирования и отладки именно структур данных, с учетом опыта и багажа знаний по различным отраслям.  Процедурная составляющая системы и внутри БД, и снаружи от этого только выигрывает.

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

Пространственные структуры: точки с координатами

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

 

НОМЕР

X

Y

Z

3098

620581.61

5556290.82

127.37

3051

620680.84

5556274.58

142.85

3052

621185.84

5556124.58

110.22

3053

621345.42

5555100.21

118.12

3055

620725.84

5556384.58

182.85

3056

620725.84

5556384.58

174.50

3106

629554.44

5534273.92

116.81

3105

629554.01

5534274.48

117.08

3104

629554.32

5534275.24

117.93

3102

629198.02

5535707.21

126.15

3108

629782.97

5524204.29

114.22

 

Рис. 1. Таблица ТОЧЕК «POINTS»

 

 

КОД

Название

Тип

Население

Район

X

Y

0057

Пильтун

Поселок

230

Охинский

629061

5536057

0055

Пугачево

Село

107

Макаровский

629782

5524204

0174

Туманово

Станция

51

Макаровский

614697

5340141

 

Рис. 2. Таблица НАСЕЛЕННЫХ ПУНКТОВ «PPP»

 

Какие задачи позволяет решать такая простая структура? Для населенных пунктов можно отобрать все точки наблюдения на заданном расстоянии. Разумеется, это делается запросом SQL:

 

SELECT POINTS.НОМЕР, PPP.КОД

FROM POINTS, PPP

WHERE       Abs (POINTS.X - PPP.X) < dS

                                    AND

                             Abs (POINTS.Y - PPP.Y) < dS;

 

Здесь dS - размер заданной окрестности, половина условного окна, которое запрос «обшаривает» для каждого заданного пункта. Будут выбраны все точки в этой окрестности. В этом примере отбор точек в окрестности организован наиболее простым способом - квадратным «окном», однако вполне возможны и прямоугольное и круглое окно. Запрос от этого несколько усложнится лишь в части условия, и не сильно замедлится. Можно отбирать данные для всех населенных пунктов, для отдельных пунктов, формируя список по критериям, например, по типу или населению. Разумеется, по отобранным точкам можно агрегировать данные наблюдений и анализов. Результат будет аналогичен пространственному ГИС-запросу «выборка одного точечного слоя по другому».

Рис. 3. Выборка точек в окрестности населенных пунктов.

 

На практике удобно в одной таблице ТОЧЕК хранить все координаты вообще, всех точек всех объектов, включая линейные, площадные, точки проектируемых сооружений, важных объектов местности и ответственных объектов инфраструктуры, как в нашем случае - населенных пунктов.

 

НОМЕР

X

Y

Z

3098

620581.61

5556290.82

127.37

3051

620680.84

5556274.58

142.85

3052

621185.84

5556124.58

110.22

3053

621345.42

5555100.21

118.12

3055

620725.84

5556384.58

182.85

3056

620725.84

5556384.58

174.50

3106

629554.44

5534273.92

116.81

3105

629554.01

5534274.48

117.08

3104

629554.32

5534275.24

117.93

3102

629198.02

5535707.21

126.15

0057

629061

5536057

80.44

 3108

629782.97

5524204.29

114.22

0055

614697

5340141

115.2

Рис. 4. Единая таблица точек c населенными пунктами (отмечены желтым).

 

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

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

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

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

Пространственные структуры: точки с трассами

Если работы идут по трассам, например, трубопроводов, то, как правило, для каждой точки наблюдений известны километраж по ближайшей трассе и отстояние от нее. Эти данные не требуют дополнительных усилий для сбора, они есть. Если их грамотно структурировать, уложить в нужные колонки разумным образом, то в БД появляется возможность позиционировать все точки и данные относительно трасс. Что это за структура? Тоже довольно обычная. В таблице ТОЧЕК должны быть колонки «Ветвь трассы» (номер или название), «километровая отметка по трассе» (точная, не округленная), «Отстояние от трассы» (желательно по прямой). Таким простым способом задается, по сути, альтернативная координатная система.

 


НОМЕР

X

Y

Трасса

Км

Отстояние

3098

620581.61

5556290.82

Главная

179.5

-110

3051

620680.84

5556274.58

Главная

179.8

-100

3052

621185.84

5556124.58

Главная

180.5

0

3053

621345.42

5555100.21

Главная

180.5

0

3055

620725.84

5556384.58

Главная

181.4

25

3056

620725.84

5556384.58

Главная

181.6

50

3104

629554.44

5534273.92

Вторая

18

10

3105

629554.01

5534274.48

Вторая

22.5

35

3106

629554.32

5534275.24

Вторая

32.7

15

 

Рис. 5. Таблица точек с указанием положения по трассе.

 

Очевидно, что в такой структуре отбор точек наблюдения в некоей окрестности от любой ветви трассы будет тривиальным – он не потребует манипуляций с dX и dY, только отбора по критерию отстояния: нужные данные просто-напросто заложены заранее. Таким простым способом в БД реализуется то, что в ГИС называется пространственной выборкой слоя точек по слою линий.

 

Рис. 6. Выборка точек в окрестности трасс (PPT)

 

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

 «Трассовая» структура не позволяет однозначно искать расстояния между точками, как показано на рисунке знаком вопроса. На изломах трасс при таком анализе будут значительные ошибки. Говоря общо, структура позволяет решать пространственные задачи «линия-точки» (если точки размечены по этой линии). Для решений задач «точка-точка» следует обращаться к абсолютным координатам, как было показано выше.

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

Пространственные структуры: слои и скважины

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

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

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

Как правило, приповерхностное строение земли может быть представлено субгоризонтальными слоями, а выработки субвертикальны. Отсюда главным объектом трехмерной БД может являться слой, точнее, его подсечение по конкретной выработке. Это основная особенность предлагаемой структуры. На рисунке пример представлен для скважин, однако структура пригодна и для почвенных разрезов, и для любых других «субвертикальных» наборов данных.

 

 

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

 

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

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

Таблица слоев связана, разумеется, со скважинами: для любого конкретного слоя известно, по какой скважине он подсечен. Где же слои, как протяженные объемные тела? «Уминать» их в БД во всей сложности нецелесообразно, однако как понятия они должны быть обязательно. Каждое подсечение должно абсолютно адекватно увязываться с аналогичным в соседней скважине. Это обеспечивается через справочник горизонтов с индексами, чтобы данные для QIV всегда увязывались с QIV, а данные по почвенному горизонту A1 – всегда только с A1. Возможна детализация слоев и по литологии. Словом, конкретные слои могут быть выделены по разным критериям, важно одно – чтобы справочник горизонтов был целостным по всей территории проекта, и представлял собой естественную классификацию.

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

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

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

 

 

Рис. 8. Представление слоев в БД

 

Это разумно лишь для небольших компактных участков, типа месторождений, с густой сетью выработок и для оперативных задач – в этом случае в БД можно даже использовать невертикальные выработки и непараллельные сечения. Для региональных проектов, где выработки порой отстоят на километр друг от друга, интерполяции между ними и тем более экстраполяции весьма неоднозначны. На рисунке это иллюстрировано знаками вопроса.

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

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

Пространственные структуры: реки и трассы

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

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

 

 

Рис. 9. Точки и переходы

 

Такая структура дает возможность знать для каждого комплекта наблюдений, на каком отстоянии по течению от перехода они были получены. Прямо в БД запросами можно отобрать нужные данные (например, всё, что ниже по течению для данного участка трассы, на нужном удалении по течению и т.п.), оценивая, таким образом, степень зависимости показателей от объекта, степень влияния на объект. Это не адекватно удалению от трассы по прямой, разумеется, как можно видеть на схеме.

 

Рис. 10. Представление водотоков в БД

 

Такая структура, по сути, аппроксимирует реки направленными отрезками, чем напоминает систему поперечных профилей. Очевидно, что она пригодна лишь для решения задач по течению отдельных водотоков, на небольших удалениях от трассы, поскольку ничего «не знает» о слияниях и соподчинениях рек. Если появляются детальные данные о речной системе в полосе влияния объекта строительства, становится возможным составить схему речной сети, и отразить ее в БД таблицей ВОДОТОКОВ, связанной c ПЕРЕХОДАМИ один-ко-многим. По сути, это всего лишь сводный справочник всех рек территории, он может быть легко составлен агрегацией списка переходов или импортом гидрологического справочника.

Рис. 11. Переходы и справочник водотоков

 

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

 

Рис. 12. Переходы и водотоки с иерархией

 

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

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

Географическая основа

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

Какое именно представление могут получить географические объекты в БД? Максимально просто и вместе с тем достаточно для выполнения большинства задач. Если есть возможность, данный класс объекта сначала аппроксимируется точкой. Возьмем, например, те же населенные пункты: при работе в масштабе 1 : 200 000 точечного представления вполне достаточно. Таблица населенных пунктов снабжена всеми необходимыми атрибутами – название, тип населенного пункта, население и т.п. Она связана с таблицей ТОЧЕК связью один-к-одному.

 

Рис. 13. Точки и населенные пункты

 

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

Рис. 14. Точки, населенные пункты и районы

 

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

Рис. 15. Населенные пункты – полигоны

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

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

 

 

Рис. 16. Моделирование географических объектов в БД

 

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

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

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

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

 

Итак, напоследок перечислим компоненты географической основы в рамках реляционных БД:

 

v     Объекты исследования (их классы = таблицы);

v     Объекты строительства (их классы = таблицы);

v     Объекты окружающей местности;

v     Объекты инфраструктуры;

v     Связи объектов

 

Ø      Пространственные свойства всех этих объектов, включая трехмерные, с учетом дискретность координат и глубин;

Ø      ВременнЫе свойства, с учетом дискретности определения времени;

Ø      Географические свойства объектов и их классификации;

 

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

 

Основные географические справочники-классификаторы

 

q      Административные районы и области;

q      Румбы-экспозиции;

q      Типы водотоков;

q      Геологические подразделения;

q      Литологический состав;

q      Типы рельефа, в том числе склонов;

q      Типы экзогенных и эндогенных процессов;

q      Типы грунтов;

q      Типы вертикальных выработок;

q      Механический состав почв и грунтов;

q      Почвенные горизонты;

q      Типы и виды почв;

q      Растительные ассоциации;

q      Видов растений и животных, включая редкие и краснокнижные;

q      Типы землепользования;

q      Виды антропогенных нарушений;

q      Физические и химические параметры по средам опробования, включая нормативы;

q      Единицы измерения;

q      Методы определения, измерений и расчетов;

Основные географические числовые домены

o        Координаты в плане (по системам координат)

o        Размеры объектов в плане, согласно координатам;

o        Размеры элементов объектов

o        Размеры частиц

o        Глубины по скважинам, метры;

o        Глубины в почвенном слое, сантиметры;

o        Градусы азимута (с учетом склонения);

o        Уклоны;

o        Площади

o        Объемы

o        Время по годам, сезонам, дням;

o        Время суток;

o        Температура

o        Давление

o       

Соотношение БД и ГИС на разных стадиях проекта

Подход с центром тяжести в БД даёт возможность гибко проектировать структуры данных, развивая модели от этапа к этапу практически без потерь времени и качества. Для разработки и оперативного анализа применяются мощные штатные средства СУБД (язык SQL, реляционные операции). Система запросов проста в эксплуатации: для активизации процесса агрегирования данных надо лишь запустить вызывающий запрос, далее по цепочке идет сборка необходимых объектов. Подход разумен еще и тем, что многие составные части объектов описаны как самостоятельные единицы в документах, и первичными являются числовые пространственные параметры, а не картографическое представление. Это относится, например, к речным переходам, список которых появляется в проектной документации задолго до правильного представления о речной сети. Каждый переход снабжается паспортом, и привязка данных опробований и наблюдений к речному переходу не только желательна, но и обязательна.

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

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

Преимущества подхода

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

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

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

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

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

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

 

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

 

Материал впервые был изложен на конференции «ГИС в геологии» в 2002 году. C замечаниями и предложениями обращайтесь по адресу geologic@mail.ru, с любыми вопросами – на форум http://www.geofaq.ru/forum

 

Литература, источники информации

  1. Базы Данных: реляционные особенности и их практический смысл. А. Левин. www.geoFAQ.ru