СодержаниеСодержание
Введение 3
1.1. Аннотация 3
1.2. Глоссарий 3
1.3. Описание предметной области 4
1.4. Неформальная постановка задачи 6
1.5. Обзор существующих методов решения 7
1.5.1. Oracle Spatial 8
1.5.2. PostGIS 9
1.5.3. DB2 Spatial Extender 9
1.5.4. ESRI ArcSDE 9
1.5.5. Другие системы 10
1.6. План работ 11
2. Требования к окружению 14
2.1. Требования к аппаратному обеспечению 14
2.2. Требования к программному обеспечению 14
2.3. Требования к пользователям 14
2.3.1. Разработчик 14
2.3.2. Администратор 14
3. Архитектура системы (общие требования) 15
4. Спецификация данных 16
4.1. Описание формата и структуры данных 16
4.1.1. Модель пространственных данных MySpatial 16
4.2. Описание сущности 19
4.3. Описание протокола 20
5. Функциональные требования 21
6. Требования к интерфейсу 22
6.1. Интерфейс SFS for OLE/COM 22
6.2. Интерфейсы редактирования 25
7. Прочие требования 30
7.1. Требования к надёжности 30
8. Проект 31
8.1. Средства реализации 31
8.2. Модули и алгоритмы 31
8.2.1. Файловая структура исходных текстов 31
8.2.2. Работа с СУБД 32
8.2.3. Алгоритмы 32
8.3. Структуры данных 37
9. Реализация и тестирование 39
Заключение 40
Список литературы 42
Приложение 1. Матрица DE-9IM 44
Приложение 2. Таблицы базы данных 45ВведениеВведение
1.1. Аннотация
В данной дипломной работе предлагается решение проблемы организации хранения пространственных объектов (точечных, линейных, полигональных) в обычных реляционных СУБД и выполнения операций пространственного анализа над ними.
Проведено исследование существующих программных средств, решающих данную задачу. Выявлены их сильные и слабые стороны. Сформулированы требования, предъявляемые реальными заказчиками к системам обработки пространственных данных.
На основании этих требований и существующих разработок предложена архитектура многопользовательской системы, основанная на использовании межплатформенного стандарта SFS [20], описывающего как структуры хранимых в БД объектов, так и методы доступа и работы с ними. Стандартизация форматов данных на уровне СУБД позволяет продуктам, разрабатываемым для различных платформ и поддерживающим эти форматы, работать с одной и той же пространственной БД. Использование же единых программных интерфейсов даёт возможность переложить бoльшую часть рутинной, но необходимой работы по анализу данных с клиентских приложений на ПО промежуточного уровня.
В рамках дипломной работы спроектирована и реализована система, поддерживающая оба аспекта стандарта SFS и отвечающая как за доступ к данным, так и за выполнение пространственного анализа.
Кроме методов редактирования данных в режиме реального времени реализован т. н. механизм откреплённого редактирования для работы с локальными копиями данных без непосредственного подключения к основной СУБД.
Система реализована с возможностью интеграции с конечными ГИС-приложениями в одном из трёх вариантов: в виде объектных модулей, динамически подключаемой библиотеки (DLL) или DCOM-сервера.
1.2. Глоссарий
ПД — пространственные данные
СК — система координат
BLOB — Binary Large Object — большой бинарный объект (тип данных СУБД, предназначенный для хранения объектов произвольного формата)
MSSQL — Microsoft SQL Server
OGC — Open GIS Consortium — Консорциум открытых ГИС [19]
SDE — Spatial Database Engine — система обработки пространственных данных от компании ESRI
SFS — OGC Simple Features Specification — спецификация простых пространственных объектов Консорциума открытых ГИС [21]
WKB — Well-known Binary representation — бинарный формат представления пространственных данных или координатных систем [21]
WKT — Well-known Text representation — текстовый формат представления пространственных данных или координатных систем [21]
1.3. Описание предметной области
Необходимость обработки пространственных данных (ПД), описывающих объекты реального мира в терминах векторных примитивов (точек, ломаных, кривых, полигонов), определённых своими координатами, привела в современном информационном пространстве к широкому использованию геоинформационных систем (ГИС). В связи с этим проблема обработки таких данных наряду с традиционными бизнес-данными встала особенно остро. По статистике около 80% систем принятия решения в различных областях науки и техники оперируют с ПД, а значит — требуют эффективных методов работы с ними.
Несмотря на кажущуюся общность, пространственные и бизнес-данные довольно сильно различаются как по способам хранения, так и по операциям, которые разрешено выполнять над ними [1, с. 7-8].
Во-первых, бизнес-данные обычно достаточно легко структурируются и помещаются в таблицы РСУБД в виде записей фиксированного формата, у которых большинство полей имеют скалярный тип и постоянную длину. В то же время один объект ПД представляет собой совокупность различных скалярных данных, описывающих координаты и размерности. Он может, кроме того, содержать внутри себя другие, подчинённые объекты, иметь весьма сложную иерархическую структуру и варьироваться по объёму в широких пределах, занимая несколько записей фиксированного размера либо поля, предназначенные для хранения больших бинарных объектов (BLOB). В связи с этим и общий объём ПД для конкретной задачи обычно намного больше, чем объём бизнес-данных.
Во-вторых, в реальных задачах рассматривают ограниченный набор бизнес-данных, связанных с интересующими оператора объектами, в то же время для выделения этого набора часто используют геометрические критерии (расстояния, площади, пересечения объектов и т.п.), основанные на анализе большого количества ПД. Более того, несмотря на (как правило) небольшой набор интересующих объектов, часто их рассматривают во взаимосвязях с большим количеством других объектов, не попавших в выборку. Например, при анализе характеристик засушливых районов для полноты картины необходимо отображать их вместе с окружающей территорией, площадь которой может быть во много раз больше их самих. Следовательно, необходимы быстрые механизмы поиска и извлечения ПД. Двоичные индексы, применяемые для поиска бизнес-данных, малопригодны для работы с ПД из-за их нескалярной природы, поэтому создаются более сложные индексы, основанные на Q- или R-деревьях [7]. Структура таких индексов достаточно сложнa, а для их обновления при изменении данных может потребоваться много вычислительных ресурсов. Для бизнес-данных это неприемлемо, но из-за того, что ПД гораздо чаще читаются, чем изменяются, эффективность индексов остаётся высокой.
Наконец, в-третьих, атрибутивные данные обычно независимы, поэтому при их изменении достаточно проверять только соответствие новых значений требуемому типу данных и не более того, в то время как для проверки корректности ПД требуется выполнение большого количества операций, в частности, по контролю топологической корректности данных — отсутствию пересечений и самопересечений полигонов, «дырок», окружённых полигонами, точечных или линейных объектов, пересекающих полигоны не в вершинах и т. п. Другими словами, любая операция изменения данных связана с проверкой многих условий, причём состав этих условий может изменяться в широких пределах в зависимости от рассматриваемой задачи.
Во многом из-за этих особенностей ПД различные ГИС до недавнего времени хранили их не в базах данных, а в файлах собственного формата, что значительно снижало диапазон применения таких продуктов. Лишь в последние годы стали создаваться системы, использующие в качестве хранилища ПД широко распространённые РСУБД и предоставляющие унифицированные интерфейсы работы с данными. Существенных успехов в этой области добилась компания ESRI, организовав не только совместное хранение пространственных и бизнес-данных в одной БД, но и обеспечив пользователей возможностью одновременно изменять одни и те же данные с помощью механизма долговременных транзакций, основанного на хранении различных версий данных для разных пользователей [23].
Из-за быстрого развития информационных технологий вообще и ГИС в частности создавалось довольно большое количество несовместимых между собой стандартов хранения и представления пространственных и бизнес-данных, что приводило к сложностям при преобразовании данных из одного формата в другой. Более того, даже при обеспечении единого стандарта на структуру данных уже нельзя гарантировать, что объекты будут всегда храниться только в одной центральной БД [2]. Например, в кадастровых задачах работа с ПД часто выполняется на местах, а затем результаты заносятся в общую корпоративную БД, при этом обычно используется механизм откреплённого редактирования, когда часть данных из общей БД переносится на внешний носитель, изменяется, а затем обратно подключается к исходной базе данных. Поскольку работа с центральной БД и откреплёнными данными производится независимо, при их слиянии возможно возникновение ошибок, связанных с нарушением целостности данных как на физическом (дублирование записей, нарушение связей), так и на логическом (нарушение топологических отношений) уровнях. Таким образом, в системе, предназначенной для работы с ПД, должны быть предусмотрены возможности преобразования данных между различными форматами, механизмы откреплённой и (или) распределённой работы и средства контроля корректности данных на всех этапах работы. Объединение данных из независимых источников является типичной задачей репликации, которая может быть весьма сложной [10, с. 3-6], но поскольку часто в комплексе систем поддержки ПД выделяют один центральный сервер, она значительно упрощается и мало отличается от задачи параллельного многопользовательского доступа.
1.4. Неформальная постановка задачи
Требуется разработать инструментальные средства, обеспечивающие программный интерфейс доступа и работы с ПД, хранящимся в СУБД.
Реализовать операции, проверяющие базовые геометрические отношения (пересечение, прикосновение и т. п.), средства контроля и механизмы коррекции данных. Программный интерфейс должен предоставлять методы для изменения хранящихся в БД пространственных объектов и топологических отношений (Рис.1).
Предусмотреть возможность преобразования данных между различными СУБД, как промышленными, так и настольными, а также импорт данных из внешних источников (ряда распространённых форматов файлов), также реализовать механизм экспорта данных во внешнюю БД для откреплённого редактирования.
За основу программного интерфейса принять открытый интерфейс SFS [21] для упрощения интеграции разрабатываемого продукта с существующими структурами данных и ГИС-приложениями.
Добавить при необходимости собственные интерфейсы для оперативного и откреплённого редактирования данных, поддержки хранимых в БД топологических отношений между пространственными объектами.
Расширить набор инструментальных средств Заказчика (группа ГИС-технологий Тихоокеанского института географии ДВО РАН), применяемых им для разработки более гибких продуктов, использующих единые стандартизованные интерфейсы.
Рис.1. Диаграмма вариантов использования верхнего уровня
1.5. Обзор существующих методов решения
Можно выделить два уровня работы с пространственными данными.
На первом уровне находится организация хранения данных, которая, в частности, включает в себя:
а) выбор способа хранения данных (в СУБД, в файлах специального формата, другим способом);
б) индексирование данных и другие действия по ускорению их поиска;
в) выполнение проверки совместной корректности объектов (например, топологический контроль на уровне слоёв данных);
г) восстановление данных после аварии или нештатного завершения работы.
Второй уровень отвечает за выполнение аналитических операций и проверку различных отношений между пространственными объектами безотносительно к способу их хранения.
Таким же образом всё программное обеспечение, предназначенное для работы с ПД, можно разделить на ПО первого, второго уровней и полного цикла.
Системы первого уровня редко встречаются в чистом виде. Обычно они поддерживают хотя бы некоторые действия пространственного анализа.
Разработки второго уровня часто базируются на некоторых стандартных интерфейсах и работают в качестве серверов пространственных запросов, принимая все требуемые для работы данные у клиента, а не из собственных БД. К таким системам относится Java Topology Suit [18], анонсированная 31 марта 2003 года, которая основана на стандарте SFS для интерфейсов OLE. Использование SFS — весьма прогрессивный шаг разработчиков данного продукта, однако этот стандарт имеет очень ограниченные возможности (см. пункт 6.1) и не предназначен для создания полноценных ГИС-приложений.
На сегодняшний день существует довольно большое количество систем полного цикла. Мы остановимся лишь на тех, которые обеспечивают работу с пространственными данными, хранящимися в РСУБД (Табл.1), поскольку тенденции развития ГИС всё больше доказывают эффективность интеграции пространственной и атрибутивной информации в единую корпоративную СУБД [6, с. 6]. Такие системы могут быть разделены на два основных класса: системы с поддержкой ПД на уровне ядра СУБД и ПО промежуточного уровня, работающее с СУБД, не поддерживающей специально ПД [4].
К первым можно отнести Oracle Spatial (компонент ядра Oracle), PostGIS (основана на СУБД PostgreSQL), DB2 Spatial Extender, являющейся расширением СУБД IBM DB2. Ко второй категории относится продукт ESRI ArcSDE, использующий для хранения данных различные промышленные СУБД (MSSQL, Oracle, Informix, IBM DB2) и предоставляющий специальный программный интерфейс для их обработки.
1.5.1. Oracle Spatial
Oracle Spatial поддерживает ПД на уровне ядра СУБД и хранит их в базе в объектно-реляционном (на один объект — одна запись с бинарными полями) или реляционном виде (несколько записей фиксированной длины на объект). Доступ к пространственным данным производится с помощью расширенного языка SQL, что позволяет сочетать в запросах пространственные критерии с атрибутивными. Основные пространственные отношения реализованы на базе матрицы DE 9IM (см. Приложение 1).
Однако данная система не может сочетаться с РСУБД других производителей, поскольку работает на уровне ядра СУБД Oracle. Кроме того, она не поддерживает откреплённое редактирование ПД в настольных СУБЛитератураСписок литературы
1. Королёв Ю. К. Статьи, лекции, доклады по проблемам геоинформатики.— М.: Изд-во «Дата+», 2000.— 128 с.
2. Краснопеев С. М. Концепция построения территориально распределённых ГИС (систем обработки пространственной информации). XXX ЮБИЛЕЙНАЯ МЕЖДУНАРОДНАЯ КОНФЕРЕНЦИЯ Информационные технологии в науке, образовании, телекоммуникации и бизнесе IT + SE'03. МАЙСКАЯ СЕССИЯ. Украина, Крым, Ялта-Гурзуф, 19 - 28 мая, 2003 г.
3. Краснопеев С. М. Разработка систем мониторинга состояния и эксплуатации лесных (древесных) ресурсов Приморского края. XXIX МЕЖДУНАРОДНАЯ КОНФЕРЕНЦИЯ Информационные технологии в науке, образовании, телекоммуникации и бизнесе IT + SE'2002. МАЙСКАЯ СЕССИЯ. Украина, Крым, Ялта-Гурзуф, 20 - 30 мая, 2002 г. С.225 226.
4. Леханов С. О. Пространственные расширения баз данных. Реферат. Владивосток: ДВГУ, кафедра информатики, 2001.
5. Новиков Б. А. Обработка и оптимизация запросов в базах данных. Специальный курс для студентов 5 курса (отделение информатики). Осенний семестр 2002 года. (03.06.2003).
6. Пензиенко А. В. Разработка средств предоставления аналитических ГИС-сервисов в сетях Интернет/Интранет: Серверная часть. Дипломная работа. Владивосток: ДВГУ, кафедра информатики, 2002.
7. Скворцов А. В. Глобальные алгоритмы построения R-деревьев. Работа по гранту РФФИ № 98-05-03194, 1999.
8. Смолин П. В. Хранение и эффективная обработка пространственных данных в реляционных СУБД. XXX ЮБИЛЕЙНАЯ МЕЖДУНАРОДНАЯ КОНФЕРЕНЦИЯ Информационные технологии в науке, образовании, телекоммуникации и бизнесе IT + SE'03. МАЙСКАЯ СЕССИЯ. Украина, Крым, Ялта-Гурзуф, 19 - 28 мая, 2003 г.
9. Турчанов С. В. MapControl — инструментальное средство разработки ГИС-приложений. XXIX МЕЖДУНАРОДНАЯ КОНФЕРЕНЦИЯ Информационные технологии в науке, образовании, телекоммуникации и бизнесе IT + SE'2002. МАЙСКАЯ СЕССИЯ. Украина, Крым, Ялта-Гурзуф, 20 - 30 мая, 2002 г. С.399-401.
10. Чистяков Т. С. Межплатформенная репликация данных и метаданных. Курсовая работа. Владивосток: ДВГУ, кафедра информатики, 2002.
11. Чистяков Т. С., Смолин П. В. Оформление исходных текстов Delphi и стиль программирования среди программистов различных подразделений МГУ им. адм. Г. И. Невельского. Версия 0.9d. Владивосток: МГУ им. адм. Г. И. Невельского, 2002.
12. Вычислительная геометрия // Algolist — алгоритмы, методы, исходники, Copyright 2000-2002 ©, Ilia Kantor. (03.06.2003).
13. ArcSDE 8.1 Developer Help. ESRI, 2001.
14. CGAL Basic Library Manuals. Release 2.4 (03.06.2003).
15. Clementini, Eliseo, Di Felice, P., van Oostrom, p., A Small Set of Formal Topological Relationships Suitable for End-User Interaction, in D. Abel and B. C. Ooi (Ed.), Advances in Spatial Databases — Third International Symposium. SSD ’93. LNCS 692. Pp. 277 295. Springer-Verlag. Singapore (1993).
16. DB2 Documentation. User’s Guide and Reference. Book version 7.1.02. (03.06.2003).
17. ESRI ArcNews. Vol. 24, No. 2. Summer, 2002.
18. JTS Technical Specifications. Version 1.3. Vivid Solutions. March 31, 2003.
19. OpenGIS Consortium. (03.06.2003).
20. OpenGIS Simple Features Specification for OLE/COM. Revision 1.1. OpenGIS Project Document 99-050. Release Date: May 18, 1999.
(03.06.2003).
21. OpenGIS Simple Features Specification for SQL. Revision 1.1 OpenGIS Project Document 99-049. Release Date: May 5, 1999.
(03.06.2003).
22. PostGIS / PostgreSQL. Geographic Objects for PostgreSQL, 2003. (03.06.2003).
23. Working with the Geodatabase: Powerful Multiuser Editing and Sophisticated Data Integrity. An ESRI White Paper. February 2002.
|
|
