В статье рассматривается проблема использования алгоритмов анализа пространственных данных в распределенных инфраструктурах, основанных на стандартах Открытого геопространственного консорциума. Вкратце затрагивается тема публикации алгоритмов анализа в виде исходного кода. Основное внимание уделено изложению нашего понимания о том, какой должна быть клиентская часть веб-сервисов обработки пространственных данных и как может быть организовано взаимодействие конечного пользователя с опубликованными средствами анализа данных.
Демонстрируются предварительные результаты разработки универсального клиентского модуля анализа данных.
Ключевые слова: анализ пространственных данных, открытый геопространственный консорциум, инфраструктура пространственных данных, Web Processing Service, WPS, клиент анализа данных.
В современном обществе осознается тот факт, что отсутствие широкого доступа к пространственным данным и инструментам их анализа является сдерживающим фактором экономического развития. Общество пришло к осознанию того, что без единого информационного пространства, реализованного в виде инфраструктур пространственных данных (ИПД), немыслимо прогрессивное развитие бизнеса.
ИПД обеспечит поддержку целого ряда прикладных задач (в том числе и федерального уровня), требующих связывания географической информации, поступающей из множества источников. Примерами таких задач могут быть: реагирование на ЧС, безопасность, муниципальное планирование, и т.п.
В последние несколько лет прогресс в технологиях сбора ПД происходил более быстрыми темпами, нежели в технологиях управления и анализа пространственных данных.
Поэтому, в настоящее время крайне востребованным является:
Это позволит обеспечить эффективный многопользовательский доступ к ПД и инструментам их анализа в пределах всей организации. И это абсолютно правильно, ведь совершенно недопустимо, чтобы при нынешних темпах накопления информации, востребованная информация лишь собиралась и лежала мертвым грузом. Круг лиц, который имеет к информации свободный и открытый доступ должен быть максимален, и соответствовать ее важности.
Кроме того, наличие информационных ресурсов, возможность доступа к ним и инструментам их анализа будет служить импульсом к развитию прикладных моделей в соответствующих областях знаний.
Цель данной работы – осветить возможности анализа пространственных данных в информационных инфраструктурах, технологической основой которых являются геопространственные веб-сервисы; дать обзор стандарта обработки данных и его отдельных реализаций. Наконец, показать важность разработки клиента для решения задач анализа данных и указать на ряд рекомендаций, которым должен следовать разработчик такого клиента.
Ключевым условием достижения успеха на пути развертывания инфраструктур публикации и анализа данных является решение проблемы геопространственной интероперабельности. Выработкой подходов к решению данной проблемы занимается Открытый геопространственный консорциум (OGC, Open Geospatial Consortium) [1].
Технологической основой интероперабельных инфраструктур являются стандартизованные веб-сервисы. В рамках развития идеи интероперабельности, OGC предложил ряд веб-стандартов, которые упрощают публикацию геопространственных данных в распределенной среде. Эталонная модель (Reference Model) [2], также разработанная OGC, объединяет эти стандарты. Наиболее важными и востребованными являются стандарты, которые описывают публикацию и протокол передачи пространственных данных через Интернет. В число этих стандартов входят Web Map Service (WMS) [3], Web Feature Service (WFS) [4] и Web Coverage Service (WCS) [5].
Рис. 1. Стандарты веб-сервисов OGC
Согласно принятым OGC нормативам, стандартом обработки геопространственных данных является Web Processing Service (WPS) [6]. Стандарт WPS – это веб-сервис, предоставляющий услуги геопроцессинга растровых и векторных данных. Операции могут быть как простыми (например, геометрические операции над векторными данными), так и очень сложными, вплоть до расчета глобальных экологических моделей. В стандарте определен протокол передачи данных, формат команд для запуска процесса и получения результатов. Это публикация услуги в чистом виде.
Теоретически, протокол WPS не зависит от платформы и сделан по стандарту простого протокола доступа к объектам (SOAP, Simple Object Access Protocol). Однако на практике поддерживается лишь протокол HTTP.
Стандарт определяет три операции:
Веб-сервис принимает эти команды в формате XML или в виде URL-encoded запроса. Стандарт очень гибкий, это обеспечивается его свойствами:
Например, открытым является вопрос о публикации процессов в серверной части веб-сервиса сторонним разработчиком. Большинство реализаций WPS поддерживают такую возможность, но предоставляют для этого разные средства (например, язык программирования, с помощью которого должен быть реализован публикуемый процесс).
В общем смысле, реализация стандарта WPS подразумевает реализацию двух компонентов развертывания:
Главной компонентой развертывания WPS является сервер, именно он хранит в себе список процессов, принимает запросы, извлекает из них данные, передает их в нужный процесс и формирует ответ с результатом. Когда говорят о реализации стандарта WPS, подразумевают именно серверную часть.
Рис. 2. Схема веб-сервиса
На данный момент существует несколько успешно развивающихся проектов, направленных на реализацию стандарта WPS:
| Реализация стандарта WPS | Лицензия | Язык реализации | Публикация процессов | Поддерживаемые языки | |
| deegree WPS | 0.4.0, 1.0.0 (deegree 3.0) | LGPL [15] | Java | Да, исходный код | Java |
| ZOO Project WPS | 1.0.0 | MIT/X-11 [16], open source | C (ядро), JavaScript (серверное API) | Да, исходный код | Java, C/C++, Python, Perl, JavaScript |
| GeoServer WPS | 1.0.0 | GPL | Java | JTS Topology Suite | Нет |
| pyWPS | 1.0.0 | GPL | Python | Да, исходный | Python |
| 52° North WPS | 1.0.0 | GPL | Java | Алгоритмы из GRASS GIS, Sextante и ArcGIS | Нет |
Таб. №1. Сравнительный анализ реализаций стандарта WPS
Алгоритм взаимодействия пользователя с веб-сервисом очень прост и, в целом, одинаков для каждой реализации:
Рис. 3. Алгоритм общения с веб-сервисом
А откуда берутся сами процессы? Ведь многие задачи из области анализа ПД невозможно решить без специфических алгоритмов. Реализации стандарта WPS по-разному решают эту задачу. В целом, есть два подхода:
Рис. 4. Публикация процессов
Например, 52° North позволяет использовать процессы из популярных пакетов обработки ПД GRASS GIS и Sextante, а GeoServer поддерживает JTS Topology Suite, что тоже дает возможность использовать сторонние процессы. Фактически, веб-сервис подключается к экземпляру хранилища процессов и обеспечивает к нему свободный доступ по спецификациям WPS. Сам процесс выполняется на стороне пакета.
С другой стороны, deegree и ZOO Project уделяют больше внимания публикации процесса в виде интерпретируемого исходного кода. Выполнение такого процесса берет на себя встроенный в веб-сервис интерпретатор языка. Поэтому для такой задачи берут, в основном, скриптовые языки или те, которые компилируются в промежуточный байт-код. Например, Java, JavaScript, Python и Perl.
Публикация исходного кода является очень ресурсоемкой задачей. Она требует усилий как со стороны разработчиков веб-сервиса, так со стороны тех, кто хочет опубликовать свой процесс. Веб-сервис должен иметь расширяемую архитектуру и предоставлять API для публикации. Ну а пользователь должен, как минимум иметь прямой доступ к веб-сервису, на котором он хочет опубликовать процесс. Вот так, например, выглядит схема публикации исходного кода процесса на Java в deegree 3.0. Класс на Java должен быть написан согласно требованиям разработчиков deegree и должен сопровождаться XML-файлом с описанием. В этом случае, процесс будет доступен в соответствие со спецификациями WPS.
Рис. 5. Публикация алгоритма в deegree 3.0
Одна только серверная часть WPS не может обеспечить всех требований, возникающих при комплексном анализе пространственных данных. Конечно, используя URL-encoded запросы, можно обратиться к веб-сервису напрямую, через адресную строку в браузере, и даже получить полезную информацию. Например, метаданные и список процессов, опубликованных на веб-сервисе. Но и тут нужно учитывать, что информация будет в формате, который малопонятен для неспециалиста.
Поэтому необходим второй компонент развертывания инфраструктуры анализа данных – клиентское приложение. Согласно принципу модульности, клиенту для работы необходим ряд взаимозаменяемых ресурсов:
Рис. 6. Ресурсы клиента
Организация хранения данных должна обеспечивать открытый доступ к ним. Данными могут быть ссылки на информацию, опубликованную по стандарту WFS, ссылки на шейпфайлы, векторные данные, которые определил сам пользователь, и т.п.
Требования к клиенту определяются исходя из множества критериев. Неизменным остается базовый алгоритм работы, который определен самой логикой стандарта WPS.
Как мы видим, слишком абстрактно сформулированы этапы выбора входных данных и вывода результатов. Это неудивительно, поскольку они жестко зависят от данных, которые нам нужно анализировать и процессов, которые мы для этого выбрали. Например, анализ топологии речной сети и снимка ДДЗ принципиально отличаются. Для их анализа необходимы разные процессы. И самое главное, у них разный формат входных и выходных данных. Например, речную сеть можно аппроксимировать векторным слоем с атрибутивной информацией. А в случае снимка ДДЗ речь идет о покрытии, матрице бинарных значений. Естественно, для этих двух случаев клиент должен по разному предлагать пользователю выбрать входные данные.
В этом случае, имеет смысл определить набор функций и внешний вид клиента, опираясь на исходные данные и поставленную задачу анализа.
Рис. 7. Выбираем набор функций клиента
Такой подход логичен, но не всегда оправдан. Развертывание инфраструктуры анализа данных – сложный и затратный процесс, в нем есть место экономии. Сходные по структуре задачи вполне можно объединить одним интерфейсом. Таким образом, мы вплотную подходим к идее создания универсального клиента анализа ПД. На этом пути есть множество преград. В следующем разделе мы опишем свойства, которым должен удовлетворять такой клиент и предложим пути их реализации.
Для профессиональных и ресурсоемких задач анализа пространственных данных существуют коммерческие программные комплексы. Например, серия продуктов от ESRI. Основной же задачей при создании инфраструктур публикации и анализа данных является предоставление свободного доступа к пространственным данным и инструментам их анализа, как можно большему числу пользователей.
Подобный подход оправдан при организации учебного процесса, а также систем оперативного принятий решений. В этом случае важна скорость доступа к разрозненным ресурсам инфраструктуры, а также удобство их использования.
С точки зрения, как пользователя, так и разработчика, универсальный клиент анализа данных должен обладать рядом свойств. Рассмотрим каждое из этих свойств подробно и предложим возможные пути их реализации:
Умение решать простейшие задачи анализа ПД
Примерами таких задач могут являться определение геометрических атрибутов объектов, построение новых объектов на основе существующих (буферная зона, выпуклый многоугольник) и т.п.
Обеспечить такую возможность тривиально. На стороне клиента, для использования подобных процедур требуются лишь базовые функции манипуляции с векторными данными.
Умение решать специфические задачи пользователя
Именно для таких случаев существует все многообразие опубликованных по открытым стандартам алгоритмов анализа данных; а также в некоторых реализациях WPS предусмотрена возможность публикации исходного кода.
На стороне клиента для решения таких задач требуются более развитые средства управления данными и слоями.
Клиент должен быть кроссплатформенным и спроектирован таким образом, чтобы его можно было использовать совместно с различными картографическими сайтами и приложениями.
Для решения этой задачи можно предложить следующие шаги:
Клиент должен учитывать различия в форматах и визуальном представлении различных классов входных данных (векторные пространственные данные, растровые данные в символьном или бинарном формате и текстовые данные), и предлагать интерфейс выбора, в зависимости от класса.
Такую задачу предлагается решить следующим образом:
Рис. 8. Классы входных данных
В соответствие с данными предложениями, в лаборатории ГИС-технологий и моделирования геосистем ТИГ ДВО РАН ведется работа по созданию универсального клиентского модуля анализа пространственных данных.
На данный момент, клиентский модуль кроссплатформенный, браузерный и поддерживает интеграцию с картографическими клиентами.
Поддерживаются:
Необходимые системные требования:
В качестве тестового клиента используется сайт геопортала, разработанный лабораторией ГИС-технологий. Картографическая основа геопортала написана при помощи OpenLayers. Клиент поддерживает создание и редактирование векторной графики. На текущий момент, это векторные графические примитивы, т.к. еще нет поддержки слоев WFS или шейпфайлов.
Адрес тестовой страницы – http://gis.dvo.ru:9080/web
Технически, клиентский модуль представляет собой набор скриптов на JavaScript и PHP, а также таблиц стилей.
Модуль загружается с сайта AJAX-запросом и выводится во всплывающем окне при помощи библиотеки highslide [17]. К сожалению, пока еще нет возможности изменить дизайн клиентского модуля, помимо модификации исходного кода.
Продемонстрируем работу модуля на примере следующих классов задач:
Рассмотрим простой пример задачи – построить зону отчуждения вокруг участка дороги. Подобные задачи часто возникают на практике, при проектировании урбанистических объектов.
В картографическом клиенте на базе OpenLayers загрузим дорожную карту. Используя инструмент рисования линий, в векторном слое очертим дорожное полотно. Задача сводится к построению буферной зоны вокруг выбранного участка дороги.
Рис. 9. Исходные векторные данные
Рис. 10. Интерфейс выбора веб-сервиса и процесса
После этого мы должны определить входные параметры для запуска процедуры. Интерфейс позволяет выбрать элемент векторного слоя и определить числовые параметры, в данном случае, ширину буферной зоны.
Рис. 11. Интерфейс выбора входных значений
На карте создается новый векторный слой и в него записывается результат операции, буферная зона.
Рис. 12. Результат выполнения операции
Можно привести другие примеры использования оверлейных и топологических операций:
Рис. 13. Построение выпуклой оболочки множества объектов
Рис. 14. Упрощение топологии кривой
В перечень доступных алгоритмов входят все процедуры, опубликованные по стандарту WPS. Тем не менее, поскольку клиент еще не может считаться достаточно универсальным, не гарантируется его работа на ряде специфических алгоритмов обработки векторных данных. Не поддерживается работа алгоритмов анализа покрытий и растровых данных.
Тестирование клиента проводилось на оверлейных и топологических операциях для векторных графических примитивов.
Несмотря на многочисленные усилия со стороны открытого геопространственного консорциума и независимых разработчиков ПО, задача анализа пространственных данных в распределенных инфраструктурах остается во многом нерешенной. Не существует рекомендаций по созданию клиентской части, отсутствует единый банк алгоритмов анализа, да и многие реализации стандарта WPS конкурируют друг с другом. Можно с уверенностью сказать, что эта область находится еще в процессе становления, в ней нет стандартов де факто.
Медленное развитие области объяснимо, т.к. действительно серьезные и насущные задачи накопления и анализа данных решаются настольными коммерческими приложениями. Но не стоит забывать, что использование инфраструктур дает свои преимущества, в том числе, массовость и открытость. Если необходимо, чтобы пространственные данные были доступны большому числу людей, без распределенных инфраструктур не обойтись.
Именно поэтому эту область нужно развивать как можно активнее. Наличие универсального клиента анализа данных, или, по крайней мере, рекомендаций по его созданию, будет небольшим, но полезным достижением.
Открытым остается вопрос о публикации алгоритмов анализа данных, в виде интерпретируемого исходного кода или байт-кода. А также вопрос о взаимодействии опубликованного алгоритма и клиента. Этой проблеме планируется посвятить следующую статью.
1. http://www.opengeospatial.org
2. OGC 08-062r4, OpenGIS® OGC Reference Model version 2.0. – URL: http://www.opengeospatial.org/standards/orm [15 февраля 2012]
3. OpenGIS Web Map Service (WMS) Implementation Specification, v1.3.0. Release date: March 15, 2006. – URL: http://www.opengeospatial.org/standards/wms [15 февраля 2012]
4. OpenGIS Web Feature Service (WFS) Implementation Specification, v1.1.0. Release date: May 3, 2005. – URL: http://www.opengeospatial.org/standards/wfs [15 февраля 2012]
5. OpenGIS Web Coverage Service (WCS) Implementation Specification, v1.1.1. Release date: July 08, 2007. – URL: http://www.opengeospatial.org/standards/wcs [15 февраля 2012]
6. OpenGIS Web Processing Service (WPS) Implementation Specification, v1.0.0. Release date: June 08, 2007. – URL: http://www.opengeospatial.org/standards/wps [15 февраля 2012]
7. http://www.deegree.org
8. http://www.zoo-project.org
9. http://geoserver.org
10. http://pywps.wald.intevation.org
11. http://52north.org
12. http://grass.fbk.eu
13. http://sextante.forge.osor.eu
14. http://www.esri.com
15. http://www.gnu.org/licenses/lgpl.html
16. http://www.gnu.org/licenses/license-list.html#X11License
17. http://highslide.com
Шулькин Евгений Владимирович – аспирант лаборатории ГИС-технологий и моделирования геосистем ФГБУН Тихоокеанского Института географии Дальневосточного отделения РАН (ТИГ ДВО РАН). e-mail:
Краснопеев Сергей Михайлович – зав. Лабораторией ГИС-технологий и моделирования геосистем ФГБУН Тихоокеанского Института географии Дальневосточного отделения РАН (ТИГ ДВО РАН). e-mail: