«Ю.Б. Гриценко, Ю.П. Ехлаков, О.И. Жуковский ГЕОИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ МОНИТОРИНГА ИНЖЕНЕРНЫХ СЕТЕЙ Томск Издательство ТУСУРа 2010 2 УДК 625.78:91:004 ББК 38.788с51 Г858 Рецензенты: В.Ф. Тарасенко, д-р техн. наук, ...»

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

По сравнению с предыдущим методом данный вариант предъявляет более высокие требования к серверу, но обеспечивает более структурированный подход к отображению картографических данных [22].

Дальнейшее развитие геоинформационных систем в Интернете сопровождается созданием интерактивных сред взаимодействия клиентских приложений с геоинформационным сервером [23], суть которых состоит в предоставлении возможности пользователю самостоятельно выбирать на карте участки для отображения на своем компьютере. На сервере размещается набор серверных программ, обеспечивающих взаимодействие с клиентом, анализ действий клиента и создание растровой картинки на область, указанную пользователем. Модель взаимодействия клиента с сервером представляет собой следующее: пользователь видит генерализованный участок карты и, выбирая более мелкие участки, получает все более детальное отображение местности. Такое интерактивное взаимодействие требует более мощных серверов.

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

Для отображения данных, полученных от сервера, обычно используется клиентское программное обеспечение — программы просмотра (viewers), которые реализуются как ActiveX-компонент, Plug-in или Java-апплет и способны встраиваться в прикладные программы или веб-браузер.

Использование специальных компонентов переносит часть функций по обработке данных на сторону клиента, обеспечивая пользователя расширенными функциями (манипулирование тематическими слоями карты, пространственный анализ, получение информации об объекте и пр.).

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

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

Использование векторного подхода позволяет получить из программы просмотра идентификатор выбранного объекта и затем запросить атрибутивную информацию с сервера любым из возможных способов. В случае указания объекта на растровом изображении карты существует только лишь один подход — передача ГИС-серверу координат объекта, по которому запрашивается информация (в виде HTTP1-запроса). В этом случае сервер своими средствами выделяет нужный объект, учитывая доступность различных слоев карты и прочие ограничения, и возвращает ответ клиенту по протоколу HTTP. Формат взаимодействия клиента и сервера в сетевой ГИС определяется стандартами организации Open GIS Consortium, Inc (http://www.opengis.org/), которых придерживается большинство разработчиков, представляющих свои продукты на рынке сетевых ГИС-технологий. Ответ возвращается в формате GML2 и подлежит дополнительной обработке или требует задания схемы интерпретации ответа браузером.

HTTP — HyperText Transfer Protocol (протокол передачи гипертекста). Основой HTTP является технология «клиент-сервер», предполагающая существование потребителей (клиентов), инициирующих соединение и посылающих запрос, и поставщиков (серверов), ожидающих соединения для получения запроса, которые производят необходимые действия и возвращают обратно сообщение с результатом.

GML (Geography Markup Language) — язык географической разметки, разрабатываемый Open GIS Consortium.

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

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

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

Используемые ActiveX1-компоненты уже содержат в себе минимальную функциональность и при этом предоставляют набор интерфейсных функций (API2) для настройки и управления. Данные функции могут быть использованы в таких приложениях, как JavaScript3, JScript4, а также в ActiveX — cредство, при помощи которого Internet Explorer (IE) использует другие приложения внутри себя. Элементы управления ActiveX активизируются при щелчке по такому объекту на веб-странице.

API (Application programming interface) — набор готовых классов, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах.

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

JScript — скриптовый язык программирования компании Microsoft. JScript во многом аналогичен языку JavaScript компании Netscape, однако, помимо добавления клиентских скриптов на веб-страницы, JScript может использоваться и для других целей, например автоматизации администрирования систем Microsoft Windows, создания страниц ASP.

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

Наиболее популярным подходом является написание CGI-2, ISAPI/NSAPI-приложений3 или применение технологий PHP4, ASP5 и Perl6.

Perl6. Разработка первых возможна с использованием большинства современных высокоуровневых средств разработки (Borland Delphi, Microsoft Visual C++) и предоставляет широкие возможности в использовании. Последние обеспечивают простоту взаимодействия частей проекта и более быструю разработку приложений, но обладают меньшей гибкостью при реализации алгоритмов и поэтому не подходят для ряда задач.

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

VBScript — скриптовый язык программирования, интерпретируемый компонентом Windows Script Host. Он широко используется при создании скриптов в операционных системах семейства Microsoft Windows. VBScript был создан компанией Microsoft как замена устаревшему пакетному языку, интерпретируемому приложением command.com.

CGI (Common Gateway Interface) — стандарт интерфейса, используемый для связи внешней программы с веб-сервером. Программу, которая работает по такому интерфейсу совместно с веб-сервером, принято называть шлюзом, хотя многие предпочитают названия «скрипт» (сценарий) или «CGI-программа».

ISAPI — стандарт Internet Server API, изначально созданный как Microsoft Information Server API, но в дальнейшем предложенный в качестве открытого стандарта. NSAPI — стандарт Netscape Server API, используемый для взаимодействия с серверами компании Netscape.

PHP (Personal Home Page Tools) — скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостингпровайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.

ASP (Active Server Pages) — первая технология компании Microsoft, позволяющая динамически создавать веб-страницы на стороне сервера.

Perl — высокоуровневый интерпретируемый динамический язык программирования общего назначения.

Глава 3. Технологии функционирования инженерных ГИС 1) диалог с пользователем (Presentation Logic);

2) прикладные функции (Business Logic);

3) обработку данных внутри приложения (Database Logic);

4) управление информационными ресурсами (Database Management System);

5) служебные функции (связующее звено).

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

В зависимости от распределения функциональной нагрузки различают две модели передачи данных: тонкий клиент и толстый клиент (рис. 3.5).

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

Рис. 3.6. Схема распределения функций системы при передаче пространственных данных Глава 3. Технологии функционирования инженерных ГИС На представленном рисунке 3.6 показана часть процесса передачи данных (ответ сервера на запрос пространственных данных), на которой четко разделены функции клиента и сервера.

В системе с трехзвенной архитектурой можно выделить несколько основных частей, представленных на обобщенной схеме взаимодействия компонентов сетевой ГИС (рис. 3.7).

Рис. 3.7. Обобщенная схема взаимодействия компонентов сетевой ГИС Детальная схема взаимодействия компонентов сетевой ГИС показана на рис. 3.8.

Рис. 3.8. Схема взаимодействия компонентов сетевой ГИС Информационные технологии построения веб-ориентированной ГИС Клиентское приложение предназначено для просмотра карты и представлено веб-браузером (тонкий клиент), модулем отображения данных, встраиваемым в веб-браузер, или пользовательским приложением (толстый клиент). Не стоит оставлять в стороне и средства для редактирования, администрирования и сборки карты, которые также работают с сервером удаленно, а следовательно, относятся к клиентским приложениям. Любое клиентское приложение (кроме растрового варианта) получает от сервера данные по определенному указываемому в запросе шаблону [23]. Файлы шаблона хранятся на сервере и включают информацию о настройках слоев карты, необходимых для ее корректного отображения. Эта информация включает имена слоев, цвета и типы линий, путь к источнику данных и другую информацию о карте.

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

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

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

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

Глава 3. Технологии функционирования инженерных ГИС Рис. 3.9. Распределенное серверное решение: а — получение клиентом данных с разных серверов; б — распределение диспетчером запроса При передаче растровых данных атрибутивная информация по объектам карты остается недоступной для пользователя и ее необходимо либо загружать, используя дополнительные средства, либо запрашивать отдельно в процессе работы с картой. Для этого в состав веб-GIS-сервера включается дополнительный модуль по обработке картографических данных для растрового варианта карты «Служба растрового преобразования». Этот модуль, как правило, реализуется в виде приложения какого-либо сервера приложений JRun (Sun), Apache TomCat (свободно распространяемое ПО) и служит для формирования растрового варианта карты и возвращения атрибутивной информации. При поступлении запроса от диспетчера это приложение загружает с веб-сервера файл сборки (шаблон карты), а затем производит запрос данных по тому же механизму, что и клиентские приложения (т. е. посредством HTTP-запроса).

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

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

3.3. Технология хеширования данных На современном этапе развития геоинформационных систем широко распространяется подход к хранению пространственных данных совместно с атрибутивными в клиент-серверных СУБД. Лидером на рынке программного обеспечения, предназначенного для хранения пространственных данных, можно смело назвать СУБД Oracle с ее опцией Oracle Spatial3. На этапе подготовки электронных чертежей присутствует ODBC (Open Database Connectivity) — программный интерфейс (API) доступа к БД, разработанный фирмой Microsoft в сотрудничестве с Simba Technologies.

OLEDB (Object Linking and Embedding, Database) — набор интерфейсов, основанных на COM (Component Object Model — технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределенных компонентов, каждый из которых может использоваться во многих программах одновременно и позволять приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа).

Oracle Spatial — опция Oracle Database Enterprise Edition, включающая дополнительные возможности по обработке пространственных данных для поддержки ГИС-приложений, пространственных сервисов (location-based services), предназначенных для обработки и/или предоставления информации о местонахождении объектов.

Глава 3. Технологии функционирования инженерных ГИС постоянный характер обновления пространственных данных. При этом измененные пространственные данные записываются в БД Oracle Spatial.

Технология хранения пространственных данных не поддерживает механизм исключения дублирования геометрических объектов, что приводит к появлению в базе данных дублирующихся записей или объектов с одинаковой геометрией [24–27]. Несмотря на то что все пространственные объекты в базе данных имеют свой уникальный код, это не препятствует появлению в хранилище объектов с одинаковой геометрией, но разными идентификаторами. Это происходит в силу того что пространственные объекты часто копируются и вставляются, при этом встроенные механизмы геоинформационных систем, работающих с базой данных, не позволяют отследить объекты, имеющие одинаковую геометрию.

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

Обычно процесс обновления данных в пространственном хранилище производится следующим образом:

1) удаляются все объекты требуемого слоя из базы данных;

2) из файла чертежа объекты вновь загружаются, включая новые или измененные;

3) после считывания все графические объекты записываются в БД;

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

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

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

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

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

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

Множество всех графических объектов G может быть описано выражением ( G = {g1, g 2,..., g n } ). В пространственной схеме каждый графический объект состоит из множества точек P и может быть представлен выражением gi ~ Pi, Pi = {p1, p2, …, pm}.

Обозначим через F множество пространственных объектов, имеющих как минимум одно описание, а через N — множество графических объектов, не имеющих атрибутивных описаний. Таким образом, все множество пространственных объектов является объединением двух множеств (G = FUN).

Глава 3. Технологии функционирования инженерных ГИС Множество всех атрибутивных объектов А описывается выражением А = {а1, а2, …, аk}. Объект атрибутивной схемы можно определить выражением аi={B,h}, где B = {b1, b2, …, bl} — множество свойств объекта; h — уникальный хеш-идентификатор.

Хеш-идентификатор представляет собой 32-байтный шестнадцатеричный код, вычисляемый алгоритмом MD5 [29] (Ronald L. Rivest, Massachusetts Institute of Technology Laboratory for Computer Science and RSA Data Security, Inc. April 1992, Request for Comments 1321), которому в качестве параметров передаются координаты всех точек графического объекта.

Функция хеширования совершает обход всех точек множества Pi, из которых состоит объект, и по совокупному набору точек рассчитывает уникальный хеш-код h. При этом используется алгоритм MD5, входным параметром которого является множество координат объекта.

Функция хеширования, примененная к множеству точек объекта, осуществляет отображение множества координат точек объекта Pi в элемент h.

Хеширование обладает следующими свойствами:

1) функция осуществляет отображение множества точек объектов в уникальных хеш-кодах во множество из одного элемента f ( Ni ) = H i, где N — множество графических объектов, не имеющих атрибутивных описаний; H — множество уникальных хеш-идентификаторов;

2) не существует обратной функции, способной по уникальному хеш-коду получить исходные данные. В таком случае координатами объекта являются F-1(H) N или F-1(F(N)) N ;

3) трудоемкость процесса нахождения двух сообщений, которые дают два одинаковых h-значения.

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

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

Рис. 3.10. Технология хеширования пространственных данных Выполнение привязки пространственных данных к атрибутивным описаниям производится по требованию администратора и осуществляется вызовом специальной сервисной процедуры. Ниже приведен алгоритм работы процедуры привязки пространственных данных. Для каждого графического объекта gi необходимо выполнить следующие шаги:

1) определить, принадлежит ли графический объект множеству N.

Если да, то перейти к шагу 2, иначе — к шагу 7;

2) получить хеш-значение hi графического объекта и выполнить проверку наличия во множестве H такого же хеш-идентификатора. Если хешзначение hi было найдено во множестве H, перейти к шагу 3, иначе — к шагу 5;

3) из множества атрибутивных объектов A получить уникальный идентификатор ID объекта aid, найденный по его хеш-значению;

4) выполнить привязку графического объекта gi к соответствующему атрибутивному объекту aid, используя идентификатор ID, найденный на шаге 3. Перейти к шагу 7;

5) сгенерировать новое атрибутивное описание (объект aid );

6) выполнить привязку графического объекта к сгенерированному на шаге 5 новому атрибутивному описанию;

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

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

3.4. Технология разграничения прав доступа к векторным объектам В СУБД Oracle реализован объектный подход к хранению пространственных данных по принципу «один объект — одна запись». Помимо высокого быстродействия при работе с едиными хранилищами данных, построенными по объектному принципу, есть еще одно существенное преимущество: сложные аналитические запросы с пространственными составляющими могут выполняться не инструментальной ГИС, а средствами самой СУБД Oracle, что оптимально с точки зрения распределения ресурсов.

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

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

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

Механизм детального контроля доступа позволяет во время работы динамически присоединить предикат (предложения WHERE — где) как к одному, так и ко всем запросам к таблице или представлению.

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

Примером детального контроля доступа может служить политика безопасности, которая определяет, какие строки могут быть доступны различным группам пользователей. Политика безопасности формирует Раньше (когда-то единственно возможная, а теперь по многим причинам неэффективная) использовалась схема хранения ГИС-данных, при которой графика и семантика хранятся отдельно (в разных файлах). Это обстоятельство существенно снижает продуктивность ГИС-проектов, предназначенных для распределенного коллективного использования.

Глава 3. Технологии функционирования инженерных ГИС предикат, вид которого зависит от соединенного с базой пользователя и группы, к которой он принадлежит.

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

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

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

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

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

DML1-предложения, обращающиеся к таблице, получают предикат, возвращаемый связанной функцией my_security_function независимо от источника, вызвавшего DML-операцию (т. е. независимо от приложения, получающего доступ к данным).

Использование механизма детального контроля доступа к данным СУБД Oracle обусловлено следующими причинами:

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

DML (data-manipulation-language) — язык манипулирования данными. Примеры DML-предложений: SELECT, INSERT, UPDATE и DELETE.

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

3) возможностью запрета на соединение с базой данных от имени обобщенных пользователей. Благодаря детальному контролю доступа каждый пользователь должен соединяться с базой данных под своим именем. В этом случае обеспечивается полная подотчетность — можно отслеживать действия на уровне пользователя. В прошлом многие приложения при работе с различными представлениями данных для различных пользователей должны были применять обобщенных пользователей базы данных соответственно выбираемым данным;

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

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

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

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

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

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

АРХИТЕКТУРЫ ВЕБ-ОРИЕНТИРОВАННОЙ ГИС

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

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

В основе большинства современных ГИС лежит многоуровневая архитектура. В таких системах обычно выделяется три уровня: обработка данных, бизнес-логика и представление. В веб-ориентированных ГИС, как и в большинстве масштабных веб-приложений, можно условно выделить две части — клиентскую (Front-End) и серверную (Back-End), каждая из которых может иметь более сложную организацию и, оставаясь в рамках архитектуры, подразделяться на несколько уровней. Это, в свою очередь, требует решения задачи поиска наиболее эффективных подходов на каждом уровне проектируемой системы [31].

Разработка эффективной клиентской части (Front-End) — важный этап реализации средств веб-публикации геоинформационной системы, от результата которого зависит оценка качества и практичности приложения в целом. Сложность данного этапа обуславливается поиском наилучшего распределения бизнес-логики между клиентом и сервером и требованиями к функциональности: приложение должно предоставлять средства просмотра картографических данных, обеспечивать выполнение пространственных запросов и вывод атрибутивной информации.

Опыт показывает, что реализация Front-End в веб-ориентированных ГИС — нетривиальная задача, требующая тщательного анализа.

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

Применение архитектурных шаблонов, предназначенных для организации приложений, упрощает процесс разработки и сокращает время, затраченное на процесс создания веб-приложения. Одним из наиболее используемых является шаблон MVC (Model-View-Controller) (рис. 4.1).

Логика клиентской части Рис. 4.1. Архитектура Front-End на основе модели MVC Применение архитектуры MVC «в чистом виде» для разработки клиентской части (Front-End) имеет существенный недостаток: акцент в данной архитектуре делается на жесткое разделение ответственности и минимизацию кода, в результате чего затрудняется разработка многократно используемых однотипных компонентов, из которых состоит интерфейс геоинформационных систем (например, форм, таблиц, кнопок, картографического вьювера, элементов управления картой, поиском и пр.).

Применение технологий Веб 2.0 все более широким кругом пользователей обусловило неизбежное совершенствование подходов к созданию веб-приложений: применение асинхронной модели взаимодействия (AJAX) позволило повысить эффективность пользовательского интерфейса, а использование сервис-ориентированной архитектуры — оптимизировать передачу данных в процессе работы. В качестве средств интеграции различных веб-сервисов (Google Maps, Yahoo! Maps, Live Search Maps и др.) разрабатываются специализированные компоненты, к которым все чаще применяется термин «виджет» (widget — элемент интерфейса). Получить максимальную выгоду от использования этих подходов позволяет архитектура на основе компонентов.

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

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

1) переходная модель (на основе синхронного взаимодействия);

2) независимая модель (на основе асинхронного взаимодействия).

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

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

Создание эффективного пользовательского интерфейса Рис. 4.3. Асинхронное взаимодействие пользователя и ГИС Жизненный цикл независимого и переходного приложений Для классического приложения на основе переходной модели браузер представляет собой низкоуровневый терминал. Он не имеет информации об этапе выполнения работы пользователем, а на сервере содержатся минимальные сведения, которые сводятся к поддержке сеанса.

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

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

Анализ моделей взаимодействия пользователя и веб-приложения как подходов к построению пользовательского интерфейса позволяет сделать вывод о том, что создание клиентской части веб-ориентированной геоинформационной системы должно базироваться на использовании независимой модели взаимодействия. Возможными средствами реализации могут стать такие технологии, как AJAX1, Adobe Flash2, Java Web Start3,.NET No Touch Deployment4 и пр. Применение подхода AJAX позволяет создавать более эффективные решения, так как, в отличие от других средств, AJAX поддерживается большинством браузеров и не нуждается в заранее установленной исполняющей системе.

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

AJAX (Asynchronous Javascript and XML) — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате при обновлении данных веб-страница не перезагружается полностью и веб-приложения становятся более быстрыми и удобными.

Adobe Flash — мультимедийная платформа компании Adobe для создания веб-приложений. Широко используется для создания рекламных баннеров, анимации, игр, а также воспроизведения на веб-страницах видео- и аудиозаписей.

Java Web Start (часто JavaWS) — технология компании Sun Microsystems, позволяющая запускать приложения на Java из браузера. Основана на протоколе Java Network Launching Protocol (JNLP). В отличие от апплетов, приложения Web Start запускаются не в окне браузера и не имеют с ним прямой связи.

.NET No Touch Deployment («развертывание без контакта») — технология развертывания Windows-приложений. Пользователи могут «рассматривать» исполняемые файлы Windows, как если бы они были обычными веб-страницами, без всякой инсталляции.

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

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

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

Отличие архитектуры Model2 от MVC в том, что контроллер имеет единственную точку входа и единственное определение последовательности действий пользователя. Данное решение, именуемое «Контроллер запросов» (Front Controller), объединяет все действия пользователя по обработке запросов в одном месте, распределяя их выполнение посредством одного объекта-обработчика (рис. 4.4).

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

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

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

Рис. 4.5. Архитектура на основе компонентов Для отображения таких компонентов необходима автоматическая генерация потока HTML-данных и JavaScript-программ. В результате в среде браузера реализуются функции, типичные для настольных систем, и разработчик избавляется от необходимости программировать низкоуровневые операции (см. рис. 4.5).

Выбор архитектуры приложения на стороне сервера Преимуществом компонентного подхода является возможность реализации системы воспроизведения на базе обычного HTML-кода, в результате чего исчезает необходимость специального изучения разработчиками особенностей языка сценариев (например, JavaScript).

Применение компонентной архитектуры «в чистом виде» для создания серверной части ГИС имеет ряд недостатков:

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

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

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

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

Усовершенствованная архитектура на основе веб-служб с использованием развитого контроллера. С учетом достоинств и недостатков вышеописанных архитектур выделяются основные требования к серверной архитектуре веб-ориентированной ГИС: поддержка обработки событий; использование веб-служб; поддержка средств доставки клиентской части приложения. Удовлетворить данные требования позволяет усовершенствованная архитектура, разработанная на основе подхода MVC (рис. 4.6).

Рис. 4.6. Усовершенствованная архитектура на основе веб-служб Организация уровня управляющей логики предполагает реализацию контроллера запросов в виде цепочки фильтров. Фильтры — это программные компоненты, позволяющие разбить процесс обработки запроса на отдельные этапы и выделить различные вспомогательные действия. Логика каждого фильтра реализована таким образом, что переход к последующему фильтру зависит от успешного выполнения действий предыдущего.

В предлагаемой архитектуре [32] запрос обрабатывается фильтрами в следующей последовательности (рис. 4.7):

1) инициализация — создание или открытие сеанса работы пользователя и обновления статистической информации о пользователе;

2) диспетчеризация запроса — анализ и фильтрация некорректных URL-запросов, выбор контроллера, иерархии команд, веб-обработчика и выделение запросов к ГИС-службам;

3) ГИС-обработчик — подпрограмма, которая получает запросы картографического вьювера, перенаправляет их соответствующим ГИСслужбам и передает результат браузеру;

4) авторизация — проверка прав доступа на выполнение действий;

5) генерация HTTP-ответа — отправка данных и HTTP-заголовков;

6) обработка запроса — запуск команды, которую обрабатывает указанный контроллер и веб-обработчик;

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

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

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

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

Данные, возвращаемые сервером, можно разделить на три типа:

1) содержимое. В качестве данных передается генерируемый сервером HTML-поток, отображаемый в составе элемента IFrame или встраиваемый в структуру документа средствами DHTML. Подход эффективен при передаче статических данных, например справочной информации;

2) сценарии. В качестве данных передаются JavaScript-сценарии, которые позволяют динамически генерировать представление либо содержат в себе структуры данных модели предметной области. Недостатком данного подхода является тесная связь между уровнями приложения, так как для генерации кода на стороне сервера необходимо иметь информацию о программном интерфейсе клиента;

3) структурированные данные. Сервер передает только низкоуровневые данные (XML1/JSON2), которые обрабатываются уровнем клиента XML (eXtensible Markup Language) — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), обмена информацией между программами, а также создания на его основе более специализированных языков разметки.

JSON (JavaScript Object Notation) — формат обмена данными, используемый для представления данных в бизнес-логику, выполняющуюся в браузерах. Многие Ajax-разработчики предпочитают обрабатывать данные напрямую, используя JSON в JavaScript-коде на стороне браузера. По мере расширения применения JSON в программах, работающих на серверах промежуточного уровня, станет необходимым предоставлять данные корпоративных приложений в браузеры в формате JSON, а не в XML-формате. Это означает, что разработчики должны преобразовать существующие корпоративные данные на стороне сервера, закодированные в XMLформате, в JSON-формат перед передачей их в браузер.

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

При разработке веб-ориентированной инженерной ГИС, представленной в пятой главе данной работы, была использована архитектура (рис. 4.8), основанная на принципах MVC и ориентированная на использование структурированных данных, поставщиками которых являются веб- и ГИС-службы [32].

Рис. 4.8. Архитектура приложения на стороне клиента Картографический вьювер, интегрированный в клиентское приложение, реализован в виде компонента, управление которым осуществляется посредством API-интерфейса. Контроллер в приложении включает в себя обработчики событий, перехватывающие действия пользователя, генератора запросов, подготавливающего данные к отправке на сервер, и набора Callback-функций, которые выполняют обновление модели данных и представления при получении асинхронного ответа.

Данная архитектура обладает следующими преимуществами [32]:

1) применение архитектуры MVC обеспечивает разделение ответственности и уменьшение количества избыточного кода;

2) использование независимой модели взаимодействия позволяет повысить интерактивность приложения;

3) ориентированность на структурированные данные позволяет разделить код клиента и сервера, а также повлиять на уменьшение времени отклика;

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

Данная архитектура была положена в основу инструментальной веб-ориентированной ГИС WGS3, которой посвящена пятая глава.

Эффективность предложенных архитектур была подтверждена в ходе их использования для обеспечения средств веб-публикации геоинформационных систем промышленных предприятий ООО «Томскнефтехим» (г. Томск), ОАО «КМК» (г. Новокузнецк), ООО «Северский водоканал» (г. Северск), а также ГИС Томского университета систем управления и радиоэлектроники.

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

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

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

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

Наиболее часто к принципам SOA относят:

1) необязательность привязки архитектуры к какой-то определенной технологии;

2) независимость организации системы от используемых вычислительных платформ;

3) независимость организации системы от применяемых языков программирования;

4) использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним;

5) организация сервисов как слабосвязанных компонентов для построения систем.

Преимуществами SOA являются:

1) сокращение издержек при разработке приложений за счет упорядочивания процесса разработки;

2) расширение повторного использования кода;

3) независимость от используемых платформ, инструментов, языков разработки;

4) повышение масштабируемости создаваемых систем;

5) улучшение управляемости создаваемых систем.

В рамках сервис-ориентированной архитектуры основу корпоративной ГИС предлагается формировать из комплекса специализированных служб (картографических сервисов) [32]. В качестве таких служб могут выступать сервисы пространственного анализа; сервисы публикации SOA (Service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами.

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

На сегодняшний день принципы SOA наиболее эффективно (применительно к веб-ориентированным системам) реализуют архитектурные стили (подходы) WSA (Веб Services Architecture) и REST (Representational State Transfer), которые предлагается рассмотреть в контексте построения сервис-ориентированной архитектуры корпоративной ГИС.

WSA (Web Services Architecture) Веб-сервисы в данной архитектуре базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI1, WSDL2 и SOAP3. Эти протоколы реализуют основные требования SOA — сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), а также должен использоваться не зависящий от платформы интерфейс (XML). Протокол HTTP обеспечивает функциональную совместимость (рис. 4.9).

Рис. 4.9. Архитектура Web Services Architecture UDDI (Universal Description Discovery & Integration) — инструмент для расположения описаний веб-сервисов для последующего их поиска другими организациями и интеграции в свои системы.

WSDL (Web Services Description Language) — язык описания веб-сервисов, основанный на языке XML.

SOAP (Simple Object Access Protocol) — протокол, используемый для обмена произвольными сообщениями в формате XML.

WSA предоставляет возможность реализовать SOA, в которой службы взаимодействуют, обмениваясь XML-сообщениями. Технологии создания веб-служб в настоящее время достаточно продуманны, предлагаются как коммерческие, так и свободно распространяемые стеки веб-служб.

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

К достоинствам данной архитектуры можно отнести надежность (поддержку спецификации WS-Reliability1) и безопасность (поддержку спецификации WS-Security2). Однако при реализации приложения предполагается наличие инструментальных средств разработки (как правило, коммерческих), при отсутствии которых быстро создать простой и эффективный сервис — задача нетривиальная. Помимо этого, при реализации достаточно простых и часто используемых картографических функций (визуализации, запроса атрибутивной информации) сервис будет обладать значительным временем отклика и некоторой избыточностью пересылаемой информации, что при больших нагрузках может привести к перегруженности вычислительных ресурсов и сетевого трафика. Поэтому в качестве более простой реализации SOA часто рассматривают архитектурный подход REST.

REST (Representational State Transfer) В архитектуре REST (рис. 4.10) система представляется отдельными ресурсами со своим состоянием. Система не хранит состояние клиентского процесса для масштабируемости. Ресурсы представлены стандартными mime-типами для независимости от платформы и самоописываемости, имеют универсальный интерфейс, идентифицируются собственными URL и связываются только через явное указание ссылок и форм в их представлениях для обеспечения интеграции между сервисами.

WS-Reliability — спецификация для передачи сообщений открытых, надежных Web-сервисов, включающая гарантированную доставку, удаление дубликатов сообщений и их упорядочивание. Характеристики надежности основаны на расширениях протокола SOAP, а не привязаны к базовому транспортному протоколу.

Благодаря данной спецификации широкий спектр систем сможет взаимодействовать независимо от платформы и производителя.

WS-Security — спецификация, отвечающая за конфигурирование аутентификации благодаря использованию цифровых подписей. Построена как расширение протокола SOAP.

Рис. 4.10. Архитектура Representational State Transfer Для доступа к ресурсу используется небольшое количество методов HTTP (GET, PUT, DELETE, POST). Передача метаданных осуществляется посредством HTTP-заголовков (mime-типов). За кеширование, проксирование и авторизацию также отвечает протокол HTTP.

Кардинальное отличие REST от SOAP-сервисов заключается в том, что в REST акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов. Если SOAP-клиенты запрашивают выполнение действия на сервере, то REST-клиенты требуют сам ресурс. Например, вместо того чтобы запрашивать на сервере визуализацию фрагмента карты, запрашивается сам фрагмент карты как статическая картинка.

По такому же принципу может быть осуществлен доступ к службам WMS (Web Map Service) и WFS (Web Feature Service).

Учитывая специфику REST и SOAP-сервисов, представляется наиболее эффективным распределить картографические сервисы исходя из интенсивности их использования, сложности исполняемой логики и требований к надежности процесса выполнения. SOAP-сервисы обладают более высокой надежностью за счет спецификаций безопасного доступа к службам (WS-Security), адресации служб (WS-Addressing), управления состоянием (WS-Resource Framework), но сильнее загружают вычислительные ресурсы, поскольку требуют разбора XML-кода и упорядочивания объектов, а для оптимизации управления и ускорения этих операций необходимо специальное программно-аппаратное обеспечение. REST-сервисы менее надежны, но более производительны и позволяют снизить затраты на обеспечение сервис-ориентированного доступа к ресурсам.

Построение веб-ориентированной ГИС как Mashup-приложения Таким образом, к SOAP-сервисам можно отнести службы:

управление доступом;

пространственный анализ;

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

К REST-сервисам относятся следующие службы:

визуализация;

генерация KML1/GeoRSS2-представлений;

сервисы WMS;

сервисы WFS.

Анализ данных архитектурных подходов позволяет сделать вывод о том, что при оптимальном распределении функций между REST и SOAP-сервисами можно повысить эффективность применения SOA для реализации корпоративной ГИС. Это позволит снизить время выполнения критических для ГИС функций, уменьшить сетевой трафик, а также в некоторых случаях снизить время издержки на разработку картографических сервисов.

4.6. Построение веб-ориентированной ГИС как Mashup-приложения Спроектированную с учетом приведенных принципов инфраструктуру картографических сервисов предлагается положить в основу архитектуры корпоративной веб-mashup3-ГИС, которая в рамках данной архитектуры будет являться провайдером содержимого (источником данных).

KML (Keyhole Markup Language) — язык разметки на основе XML для представления трехмерных геопространственных данных в программе Google Earth, именовавшейся Keyhole до ее приобретения Google.

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

Mashup (или mash-up) — приложение, комбинирующее в себе контент с различных источников («гибрид» веб-приложений).

Mashup-приложение объединяет данные из нескольких источников в один интегрированный инструмент. Например, в качестве подложки могут быть использованы картографические данные виртуальных глобусов (Google Maps, Virtual Earth), в качестве тематических слоев — поток KML-данных, предоставленный специализированным картографическим сервисом, а для добавления к ним произвольных атрибутивных данных необходимо обратиться к сервисам управления информационными описаниями. В результате создается новый уникальный веб-сервис, изначально не предлагаемый ни одним из источников.

Архитектура mashup-приложений всегда включает три части:

1) провайдер содержимого — источник данных. Данные доступны через API и различные веб-протоколы, такие как RSS, REST и вебсервисы;

2) mashup-сайт — веб-приложение, предлагающее новый сервис, использующий не принадлежащие ему источники данных;

3) браузер клиента — пользовательский интерфейс mashup-приложения. В веб-приложениях содержимое может быть «смешано» клиентским браузером с использованием клиентского языка программирования, например JavaScript.

Основу mashup-приложения составляет комплекс компонентов — виджетов (Widgets), представляющих собой небольшие программные модули, имеющие графический интерфейс и прикладной интерфейс программирования (API), которые поддерживают систему событий. Основная задача виджета — интегрировать веб-сервис в приложение (выполнить смешивание). Интеграция картографических сервисов посредством виджетов представляет наиболее эффективный подход к реализации веб-ориентированной корпоративной ГИС в рамках SOA, поэтому архитектура mashup-приложений требует более детального рассмотрения.

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

На уровне взаимодействия сервисов различаются два типа архитектур mashup-приложений: на основе серверного смешения (ServerSide) и клиентского смешения (Client-Side). В соответствии с этим авторами предлагается два типа архитектур веб-mashup-ГИС.

Построение веб-ориентированной ГИС как Mashup-приложения Архитектура сервис-ориентированной веб-ГИС на основе серверного смешивания (mashup) События, генерируемые интерфейсом приложения в ответ на действия пользователя, обрабатываются логикой клиентского приложения (слой «контроллер» паттерна MVC), которая, в свою очередь, посылает HTTP-запросы веб-ГИС-серверу (рис. 4.11).

Рис. 4.11. Архитектура на основе серверного смешивания Веб-сервер (начальное звено веб-ГИС-сервера) инициирует работу интеграционной логики, которая посредством API серверных компонентов интегрирует как внутренние сервисы (ГИС), так и любые внешние веб-сервисы.

Архитектура сервис-ориентированной веб-ГИС на основе клиентского смешивания (mashup) В отличие от архитектуры на основе серверного смешивания, в данной архитектуре интеграционная логика размещается на клиенте. Виджеты, интегрированные в пользовательский интерфейс, генерируют события, которые могут быть обработаны как клиентской логикой, так и самими компонентами, и могут взаимодействовать между собой посредством API. Виджеты работают напрямую с ГИС-сервисами и со сторонними веб-сервисами посредством REST и SOAP-запросов (рис. 4.12).

Рис. 4.12. Архитектура на основе клиентского смешивания Представленные архитектуры позволяют перенести идеологию смешивания веб-сервисов на сектор веб-ориентированных геоинформационных систем, позволяя тем самым повысить эффективность применения SOA за счет реализации основных преимуществ mashup-приложений:

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

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

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

стимулирования внедрения новых технологий и идей при сохранении соответствующего уровня управляемости.

Сервис-ориентированная архитектура блока анализа… 4.7. Сервис-ориентированная архитектура блока анализа веб-ориентированной ГИС В рамках концепции SOA были рассмотрены функции пространственного анализа, расширяющие функциональные возможности геоинформационной системы и представленные в виде отдельных сервисов [32]. На рис. 4.13 представлена сервис-ориентированная архитектура блока анализа веб-ориентированной ГИС.

Рис. 4.13. Сервис-ориентированная архитектура блока В представленной архитектуре сервисы объединяются в группы по способу реализации и специфике анализа:

- сервисы подготовки данных для анализа;

- базовые сервисы анализа;

- специализированные сервисы анализа;

- сервисы представления результатов анализа.

Сервисы подготовки данных для анализа Для получения качественных результатов проводимого анализа необходимо правильно обработать и подготовить пространственные данные. Начальным этапом подготовки данных для использования их в вебориентированных геоинформационных системах является извлечение знаний о пространственном распределении огромного набора географических объектов. Сервис spatial data mining (пространственное извлечение знаний) решает данную задачу, используя инструментарий spatial data mining. Извлечение знаний — это процесс обнаружения в «сырых»

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

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

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

Наиболее часто решаемыми задачами в пространственном извлечении знаний являются задачи классификации, кластеризации и ассоциации.

Сервис-ориентированная архитектура блока анализа… Задача классификации — формализованная задача, в которой имеется множество объектов (ситуаций), разделённых некоторым образом на классы. Задано конечное множество объектов, для которых известно, к каким классам они относятся. Это множество называется выборкой.

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

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

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

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

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

Базовые сервисы анализа К общим сервисам анализа, используемым в ГИС, относятся:

- сервисы сетевого анализа;

- сервис тематического картографирования;

- сервис построения пространственных запросов.

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

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

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

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

При создании таких запросов могут учитываться не только операторы отношений (равно, больше, меньше и др.), логические операторы (и, или, не), арифметические операторы (сложение, вычитание и др.), но и пространственные операторы (соприкасаются, пересекаются, не пересекаются, содержат, быть внутри, покрывать, покрываться, равны). Пространственные операторы отображают межобъектные топологические отношения между объектами карты [29].

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

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

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

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

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

ВЕБ-ОРИЕНТИРОВАННАЯ

ГЕОИНФОРМАЦИОННАЯ СИСТЕМА WGS

5.1. Администрирование. Управление проектом Создание веб-ориентированной геоинформационной системы WGS (Web-Gis-Server) обусловлено необходимостью повышения эффективности применения геоинформационных технологий для управления инженерной инфраструктурой промышленных предприятий и муниципальных образований. Основными задачами, решаемыми геоинформационной системой WGS3, являются:

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

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

максимальная скорость поиска информации о сосредоточенных и распределенных объектах;

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

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

предоставление оперативного доступа к электронным данным планов по инженерным сетям в среде корпоративной сети предприятия;

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

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

снижение затрат за счет использования распределенной ГИС и применения архитектуры «тонкий клиент».

Веб-ориентированная геоинформационная система WGS3 представляет собой веб-приложение, работающее на базе сетевой ГИС Autodesk MapGuide.

Глава 5. Веб-ориентированная геоинформационная система WGS В состав системы WGS3 включены три модуля:

1) подсистема «Управление проектом»;

2) подсистема «Управление данными»;

3) пользовательские функции системы.

Подсистема «Управление проектом» предоставляет администратору системы следующие возможности:

управление пользователями (рис. 5.1) и ролями (рис. 5.2);

определение параметров доступа к объектам проекта: стандартным и системным функциям, панелям, слоям с данными и подложкам;

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

Рис. 5.1. Экранная форма «Создание нового пользователя»

Рис. 5.2. Экранная форма «Создание новой роли»

Назначение параметров доступа ролей к объектам проекта осуществляется в двух режимах:

1) режим назначения прав через объекты. Рекомендуется использовать в случае, если необходимо назначить нескольким ролям права на один объект (рис. 5.3);

2) режим назначения прав через роли. Рекомендуется использовать в случае, если необходимо назначить одной роли права на несколько объектов (рис. 5.4).

Рис. 5.3. Назначение прав через объекты Рис. 5.4. Назначение прав через роли Глава 5. Веб-ориентированная геоинформационная система WGS Назначение прав осуществляется присвоением привилегий доступа:

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

снять привилегию;

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

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

Рис. 5.5. Экранная форма «Выбор карты по умолчанию»

Рис. 5.6. Экранная форма «Выбор карты для окна общего вида»

5.2. Администрирование. Управление данными В геоинформационной системе WGS3 выделяется пять типов данных:

1) атрибутивные описания;

3) группы слоев;

4) характеристики;

5) группы характеристик.

Атрибутивное описание представляет собой описательную структуру объектов реального мира, состоящую из множества свойств (характеристик). Каждое описание может иметь простую либо сложную иерархическую структуру. При использовании иерархической структуры каждое дочернее (вложенное) описание вступает в связь типа «одинк-одному» или «один-ко-многим». Такая связь, в свою очередь, также может иметь свойства (характеристики). Карточка дочернего описания в иерархической структуре именуется как вложенная.

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

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

Отличие основного атрибутивного описания от дополнительного состоит в следующем:

карточка основного описания отображается первой при использовании функции «Карточка»;

при использовании функции «Поиск» в режиме поиска объектов на карте в списке результатов отображаются карточки основного атрибутивного описания;

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

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

Характеристика представляет собой описательную единицу объекта реального мира. Набор характеристик является атрибутивным описанием.

Глава 5. Веб-ориентированная геоинформационная система WGS Группы характеристик, как и группы слоев, выделяются в целях удобства управления. Например, характеристики «Номер дома» и «Улица» удобно объединить в группу адресных характеристик.

Главное окно подсистемы управления данными разделено на две области: слева представлено дерево объектов, сгруппированное по типам; справа — рабочая область подсистемы, в которой каждый редактируемый или создаваемый объект представляется в виде формы, открываемой в отдельной вкладке (рис. 5.7).

Подсистема «Управление данными» предоставляет администратору следующие возможности:

- управление слоями (рис. 5.8) и группами слоев (рис. 5.9);

- управление атрибутивными описаниями (рис. 5.10);

- управление группами характеристик (рис. 5.11) и самими характеристиками (рис. 5.12);

- связывание атрибутивных описаний со слоями;

- управление атрибутивными описаниями (рис. 5.13) или выполнение поиска по этим описаниям;

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

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

Для привязки атрибутивного описания в экранной форме привязки необходимо выбрать необходимое описание с учетом трех параметров (см. рис. 5.10):

1) «назначить данное описание основным». После привязки данное описание будет назначено основным. Если до момента назначения основным было другое описание, то оно автоматически будет назначено как дополнительное;

2) «привязать имеющиеся атрибутивные объекты к подходящим геометрическим». Если выбранное атрибутивное описание уже было ранее привязано к слою и в системе сохранились отвязанные карточки данного описания, то вместо создания пустых карточек для каждого объекта слоя будут восстановлены связи со старыми карточками.

Если в слое появились новые объекты, то для них будут созданы новые пустые карточки;

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

Рис. 5.7. Главное окно подсистемы управления данными Рис. 5.8. Форма создания слоя Рис. 5.9. Форма создания группы слоев Рис. 5.10. Экранная форма «Привязка атрибутивного описания»

Рис. 5.11. Экранная форма «Создание группы характеристик»

Рис. 5.12. Экранная форма «Создание характеристики»

Рис. 5.13. Экранная форма «Создание атрибутивного описания»

Глава 5. Веб-ориентированная геоинформационная система WGS Параметр «Удалить все атрибутивные объекты, не привязанные к геометрическим» зависит от параметра «Привязать имеющиеся атрибутивные объекты к подходящим геометрическим»:

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

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

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

При создании характеристики автоматически создаются следующие параметры:

наименование характеристики, используемое при отображении в карточке и форме поиска;

наименование в AutoCAD (синоним), которое будет использоваться в таблице объектных данных при работе с AutoCAD Map (Autodesk Map). При загрузке объектов из среды AutoCAD Map в базу данных значение из одноименного поля будет загружено в соответствующую характеристику карточки. Длина наименования не должна превышать 15 символов, допустимыми символами являются латинские и русские буквы, символ «_» и цифры;

группа характеристик, в которую помещается данная характеристика;

тип значения характеристики, выбираемый из списка:

• «Список значений»;

• «Число вещественное»;

В случае создания нового атрибутивного описания у данного описания автоматически создаются следующие параметры (см. рис. 5.13):

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