CC BY
105
Вычислительные технологии
Том 19, № 3, 2014
Геоинформационное обеспечение
>к
для решения гидрологических задач*
А. Т. Зиновьев, О. В. Ловцкля, Н.А. Бллдлков, А. В. Дьяченко Институт водных и экологических проблем СО РАН, Барнаул, Россия e-mail: zinoviev@iwep.ru, lov_olga@inbox.ru, nikita-baldakov@yandex.ru
Зиновьев А.Т., Ловцкая О.В., Балдаков Н.А., Дьяченко А.В. Геоинформационное обеспечение для решения гидрологических задач // Вычислительные технологии. 2014. Т. 19, № 3. С. 14-26.
Описаны геоинфомационные компоненты информационно-моделирующих систем, предназначенных для решения гидрологических задач. Проанализированы масштабы и форматы необходимой картографической информации. Рассмотрена структура проблемно-ориентированной базы данных, используемой для хранения и обработки информации в составе информационно-моделирующих комплексов. Предложена организация базы данных в виде схемы "звезда" на базе СУБД PostgreSQL. Для создания Web-ГИС разработано расширение GeoServer, реализующее функции поиска и фильтрации по пространственным отношениям и выполняющее взаимодействие клиент/сервер по протоколу WPS.
Ключевые слова: база данных, Web-ГИС, PostgreSQL, WPS.
Zinoviev A.T., Lovtskaya O.V., Baldakov N.A., Dyachenko A.V. Geoinfor-mation support for hydrologic problems // Computational Technologies. 2014. Vol. 19, No. 3. P. 14-26.
Purpose. Numerical solution of hydrological problems often requires large volumes of spatial-temporal hydrometeorological and GIS data describing the characteristics of catchments, channels and floodplains. IWEP deals with the development of problem-oriented information modeling systems, which combine computation modules, databases and GIS. The paper presents the results of the development of geoinformation components of the information-modeling hydrological systems.
Methodology. We defined the scale and formats of spatial data required for modeling of hydrological processes and phenomena. The structure of the problem-oriented database for data storage and processing in the information-modeling systems was defined as well. For visualization of spatial information we use the cross-platform web mapping server Geoserver.
Findings. The problem-oriented database is a "star" scheme based on DBMS PostgreSQL. The main elements of the scheme are a value table and numerous dictionary tables. Auxiliary dictionary tables allow us to store raw and processed data, the data
* Работа выполнена в рамках проектов СО РАН IV.38.2.5 "Разработка информационно-аналитического обеспечения для исследования водно-экологических процессов в водоёмах, водотоках и водосборах Сибири" и VII.76.1.1 "Исследование процессов формирования стока и разработка информационно-моделирующих систем оперативного прогнозирования опасных гидрологических ситуаций для крупных речных систем Сибири" при финансовой поддержке Междисциплинарного интеграционного проекта СО РАН № 42 "Природные и техногенные риски критически важных гидротехнических объектов, водохранилищ и водных систем Сибири".
of regular monitoring and single observations, the data collected for different periods of averaging, the data on different related natural environments (water, soil, atmosphere) in the database. For visual representation of map layers, we have designed a generator of SLD-files (SldGenerator) that enables the stylization and publication of spatial data based on an intuitive interface. Moreover, we designed and implemented GeoServer based plug-ins that provide tools for the data search and filtering with the help of WPS protocol.
Originality/value. The tools for integrated processing of heterogeneous cartographic data have been developed. These tools were used for both calculation and full-scale study data that are essential for solution of various hydrological problems.
Keywords: problem-oriented information modeling systems, database, Web-GIS, PostgreSQL, WPS.
Введение
При решении практически важных гидрологических задач требуется привлечение достаточно сложных математических моделей. Поэтому разработанные на основе плановых гидродинамических моделей компьютерные модели расчёта течений в водотоках сложной конфигурации используют большие объёмы разнородной пространственно-распределённой эмпирической информации. Так, для решения указанных задач необходима изменяющаяся в пространстве и времени гидрологическая и метеорологическая информация. К ней необходимо добавить данные геоинформационной системы (ГИС), описывающие пространственные характеристики водосбора, сведения о подстилающей поверхности, цифровую модель рельефа русла и речной долины. Всё это определяет актуальность разработки и создания информационно-моделирующих систем, объединяющих вычислительные модули, базы данных и ГИС. Необходимое взаимодействие информационно-моделирующих систем с ГИС обеспечивается общей базой данных, которая также содержит информацию для создания геометрических форм при визуализации в ГИС-системах [1].
Базы данных для решения конкретных задач имеют определённую специфику, обусловленную самим предметом исследования. Главной особенностью используемой в этих задачах информации является наличие в ней временной составляющей, что оказывает существенное влияние на структуру данных в моделирующих комплексах. Значительный объём в составе этих данных занимают временные ряды измеряемых и расчётных величин (таких как расходы, уровни, метеопараметры и т.п.), относимые к определённым пространственным точкам (створам, метеостанциям и т.п.). Использование ГИС и систем моделирования позволяет эффективно решать различные гидрологические задачи, обеспечивая модели достаточно полной и корректной информацией. В российских и зарубежных разработках [2-6] известны успешные примеры такого симбиоза. Совместное использование ГИС и баз данных является практически стандартом в системах поддержки принятия решений по управлению водными ресурсами [7]. Существенный недостаток перечисленных систем — использование коммерческих ГИС-продуктов, обладающих функциональной избыточностью и имеющих высокую цену, не только при подготовке данных, но и на этапе визуализации результатов расчётов. Кроме того, ни одна из известных нам систем, кроме гидрологической информационной системы CUAHSI [6], не уделяет достаточного внимания организации данных наблюдений и результатов расчётов. Отсутствие же унификации представления информации затрудняет
возможность расширения информационно-моделирующих комплексов и использования общих данных для решения разных задач.
Базы гидрологических и геоданных в общем случае должны включать:
— все виды данных гидрометеорологических наблюдений,
— все необходимые виды данных специальных наблюдений за параметрами природной среды (характеристики почвы, показатели качества воды, данные о подземном и поверхностном стоке и т. д.);
— все виды геоданных по водосборным бассейнам.
Для создания баз данных в целях решения поставленных задач необходимо:
— определить состав, структуру и содержание базы данных с учетом информационных потребностей для решения задач гидрологического прогнозирования;
— разработать инструменты для выборки и обобщения необходимой информации;
— создать инструменты получения информации по запросам пользователей.
Исходя из вышесказанного, в рамках разработки и функционирования системы прогнозирования половодий и паводков в бассейне Верхней Оби было предусмотрено решение следующих задач [8]:
1) создание интегрированной базы данных, объединяющей разнородную картографическую информацию, данные наблюдений за природными процессами, расчётные данные и данные моделирования;
2) развитие геоинформационной системы, обеспечивающей универсальный подход к отображению пространственно-распределённой информации.
1. Создание интегрированной базы данных для решения гидрологических задач
При построении информационно-моделирующих систем вопросы выбора масштаба используемой информации играют важную роль [7]. Большинство гидрологических процессов варьируют в пространстве и времени. Информация, обладающая масштабами крупнее требуемых, становится "зашумленной" в то время как имеющая масштабы мельче требуемых — не представительна или нецелесообразна. В табл. 1 приведены масштабы картографических данных в зависимости от решаемых задач [9]. В соответствии с таблицей для быстрого поиска объектов используются цифровые карты мелкого (1: 500000, 1: 1000000) или среднего (1: 200000, 1: 100000) масштаба. Наличие такого покрытия позволяет провести практически все подготовительные работы, предшествующие, например, прогнозу территории затопления.
Структура предлагаемой в настоящей работе картографической базы данных выглядит следующим образом:
1) мелкомасштабная топографическая основа (вектор), включающая гипсометрию и гидрографию (1: 500000, 1: 200000);
2) набор геопривязанных растровых покрытий масштаба 1: 100000, 1: 50000, 1: 25000 и крупнее на исследуемую территорию, покрывающий её, по возможности, полностью;
3) векторные слои гидрографии, гипсометрии масштаба 1: 25000 и крупнее на отдельные участки исследуемой территории.
Сложность и разнородность решаемых задач обусловливают нетривиальные подходы к проектированию структуры базы некартографических данных. В единой систе-
Таблица 1. Масштабы топографических данных, используемых при решении гидрологических задач
Масштаб Решаемая задача
1: 500000, 1: 1000000 Создание обзорных карт, поиск объектов на карте
1:200000 Расчёт бассейно-административной структуры территории, расчёт водохозяйственной структуры территории и водохозяйственных балансов, выбор бассейнов — аналогов для решения задач русловой трансформации, создание обзорных карт, поиск объектов на карте
1: 50000, 1:100000 Первичная оценка затопления территории крупными паводками, составление реестра главных водных объектов, расчёт водосборного деления и параметров водосборов для средних рек, оценка антропогенных изменений гидрографической сети, ОРБ-привязка результатов полевых исследований
1:25000 Оценка затопления территории паводками и при разрушении гидротехнических сооружений, составление реестра водных объектов, расчёт водосборного деления и параметров водосборов для малых рек, оценка антропогенного изменения территории, калибровка ДДЗ, ОРБ-привязка результатов полевых исследований, оценка русловых деформаций и антропогенных изменений гидрографической сети
1:5000, 1:10000 Высокоточная оценка затопления территории паводками и при разрушении ГТС, оценка русловых деформаций
ме желательно хранить результаты моделирования и натурных наблюдений, данные, снимаемые с приборов в режиме реального времени и разных периодов осреднения, относящиеся к разным природным средам. Универсальная схема такой базы с единой расширяемой системой справочников позволяет собрать и объединить наиболее важные данные по предметной области исследования и использовать их для последующих анализа, расчётов, отображения результатов.
При разработке модели данных в качестве прототипа авторами использовался единый международный формат данных CUAHSI [6]. Стандартизованная схема хранения данных облегчает анализ информации из различных источников как для одного, так и для различных гидрологических объектов исследования. В полном объёме система управления данными CUAHSI HIS ODM использована при построении информационной системы Приморского УГМС [10].
Данные наблюдений, необходимые для гидрологических расчётов, имеют следующие основные характеристики (рис. 1):
— место проведения наблюдения (пространство);
— дата и время проведения наблюдения (время);
— тип и значение наблюдаемой переменной (идентификатор и значение).
Помимо этих характеристик, существует много других отличительных признаков,
сопровождающих данные наблюдений. Многие из дополнительных атрибутов уточняют основные характеристики. Например, место наблюдения, кроме указания географических широты и долготы, может определяться в местной системе координат, а также сопровождаться текстовым обозначением. Другие атрибуты могут обеспечить необходимые условия для правильной интерпретации данных, сохраняя информацию об условиях их отбора, методиках обработки, а также о владельцах и источниках данных. В табл. 2 представлены общие атрибуты, связанные с точечными наблюдениями.
Рис. 1. Схема описания данных наблюдений
Т а блица 2. Атрибуты, характеризующие наблюдение
Атрибут Определение
Название параметра Название оцениваемого параметра
Значение Значение наблюдаемого параметра
Точность Количественная оценка точности измерений
Дата и время Дата и время наблюдения
Местоположение Расположение точки (объекта), в которой проводилось измерение
Единица измерения Единица измерения (например, м или м3/с) и её тип (например, длина, объём, время)
Интервал Временной интервал, за который выполнялось (усреднялось) наблюдение
Смещение Расстояние от опорной точки до места, в котором было проведено наблюдение (например, 5 м ниже поверхности воды)
Тип смещения/ Опорная точка Точка отсчёта, от которой вычисляется смещение в месте измерения (например, средний многолетний уровень воды)
Тип данных Вид измеряемой величины (например, непрерывное, минимальное, максимальное или кумулятивное измерение)
Чувствительность Индикатор чувствительности отбора данных (например, ниже предела чувствительности, или < 0.01)
Среда Среда, в которой отбиралась проба (вода, воздух, почва и т.д.)
Категория значения Характеристика представленного значения (непосредственные измерения, вычисленное значение, результат моделирования)
Метод анализа Используемый метод анализа
Источник данных Организация, проводившая измерение
Организация Организация, предоставляющая данные
Комментарии Комментарии, касающиеся качества данных и влияющие на их использование или интерпретацию
Концептуальная модель создаваемой базы данных, представленная на рис. 2, позволяет оценить состав и количество таблиц БД, а также их взаимосвязи. В терминах проектирования реляционных баз данных такой подход к структурированию данных называется схема "звезда" (star schema). Модель данных состоит из двух типов таблиц:
одной таблицы фактов (fact table) — центр "звезды" — и нескольких таблиц измерений (dimension table) по числу измерений в модели данных — лучи "звезды" [11]. Основными элементами такой схемы являются таблица фактов и множество таблиц измерений. Таблица фактов, как правило, содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Таблицы измерений содержат не изменяемые либо редко изменяемые данные. Таблицы измерений также содержат, как минимум, одно описательное поле (обычно наименование параметра) и, как правило, целочисленное ключевое поле для однозначной идентификации рассматриваемого параметра. Если измерение, соответствующее таблице, содержит иерархию, то такая таблица также может содержать поля, указывающие на "родителя" данного параметра в этой иерархии. Каждая таблица измерений должна находиться в отношении "один ко многим" с таблицей фактов.
В терминах разрабатываемой базы данных в качестве таблицы фактов выступает таблица Значения данных. Остальные таблицы играют роль таблиц измерений или справочников (см. рис. 2).
Наличие вспомогательных справочников позволяет хранить в БД данные разного качества ("сырые", прошедшие контроль качества, обработанные и т.д.), регулярные данные мониторинга, данные разовых наблюдений и разных периодов наблюдения (от мгновенных до среднемноголетних), а также данные, относящиеся к любым компонентам природной среды. Реляционная БД со строками (записями), характеризующими наблюдение в точке, обеспечивает максимальную гибкость при анализе данных за счёт возможности их выбора и группировки по многоаспектным критериям.
Рисунок 3 иллюстрирует возможности использования разработанной модели данных для создания БД по Новосибирскому водохранилищу.
Рис. 2. Концептуальная модель базы данных
Модель данных наблюдений не зависит от географического представления точек наблюдений. Их географическое расположение хранится в полях Latitude, Longitude и Elevation таблицы Расположение точек (см. рис. 3). Координаты задаются в географической или проекционной системе координат либо другим способом, специально определённым для решаемой задачи. Каждая точка наблюдения имеет уникальный
Ш Редактирование данных - PostereSOL 9.3 i(ocalhost:5432) - OD YSI ■ИГ-УЫГх В Редактиро вание данных - PostgreSQL 9.3 flocalhost:5432 -OD YSI Novosi 040613 - units ВШВ
Файл Правка Вид Инп Таблица Расположение точек J II Файл Правка Вид Инструменты ? Таблица Единицы измерения J
\\ m ; m * \ © i llBl4»« ® Щ ■ Y|Ç|i[j
siteid ГРК] serial sitecode text sitename text latitude double precis longitude double precis latlongdatum 1 unitsid [PK] serial unitstype text unitsname text unitsabbreviatio text ■
i p OTTO 54.833961 83.048332 3 ■ 1 безразмерная процент %
2 www 54.833961 83.048332 3 1 2 У- TH—I
3 www 54.833961 83.048332 3 3 3 биология клеток на мм клет/ m
4 www 54.833961 83.048332 3 4 4 биология колонии на г К0Л01 'г
5 www 54.833961 83.048332 3 5 5 биология трихом на л трихс 1/Л
6 www 54.833961 83.048332 3 Б 6 биология цист на л цист/ i
1 www 54.833961 83.048332 3 7 7 биология экземпляров на л экз/j
8 www 54.833961 83.048332 3 8 8 биология экземпляров на м2 ЭКЗ/I
9 www 54.833961 83.048332 3 9 9 биология экземпляров на мЗ ЭКЗ/Р
10 0 = 54.833961 83.048332 3 Ê 10 10 время год год ] í
В Ре да (тирование даннь ■HSHBBHI flaf?athast:543?) - ПП YS Movasih 040 Ï|l68 строк, J— Таблица Тип смещения
Файл авка Вид Инструм« Таблица Значения данных Г Файл П 1 1 г
1 1 \Я\п ' чи 4á) IS : ......'
valueid PK] serial datavalue double precis valueaccurac double precis localdatetime timestamp w utcoffset double precis i eid eger h ariableid nteger offset value o Tsettypeíd double precif in eger Л ■ffsettypeid PK] serial offsetunitsid offsetdescription text
i .95 2013-06-07 i I ) 0.487 ■ 114 Ниже поверхности воды
2 ISO 2013-06-07 i 0.487 ! 2 2 114 Выше поверхности земли
3 195 2013-06-07 0.487 «
4 i__ тз^шьо? 2 0.487
5 5 1 .127 2013-06-07 4 0.487
6 6 0. .09 2013-06-07 3 0.487
7 7 8.27 2013-06-07 i 0.487 1 а
8 8 -94.9 2013-06-07 f 0.487
9 9 82 2013-06-07 0.487 i
10 10 » 4 2013-06-07 7 a il V 0.487 V/ я
Ш Редактирование данных - PostgreSQL 9.3 (localhost:5432) - 0D_YSI _Novosib_040 S13 - variable Наш
I Файл Правка Вид Инструменты ? i Таблица Параметры 1
|;и|«л m m : 1 Не ограничен! v
variableid [PK] serial variablename text speciation text variableunitsi integer samplemedium text valuetype text isregular integer timesupport double precis timeunitsid integer text Y ■ ?ех1
l Ti Температура Непримениг D 140 Поверхностные воды Полевые данные 0 0 100 Едини1 яое Гидре
2 2 Удельная электропроводность Нецрииенин( э 165 Поверхностные воды Полевые данные 0 0 100 Едини1 яое Гидре
3 3 Удельная электропроводность приведенная к 25 С Неприменим« э 165 Поверхностные воды Вторичные данные 0 0 100 Едини1 we Гидре -
4 4 Удельное сопротивление Неприменим« э 164 Поверхностные воды Вторичные данные 0 0 100 Едини* юе Гидре
5 5 Total Dissolved Solids Неприменим« э 42 Поверхностные воды Вторичные данные 0 0 100 Единю ю е Гидре
6 6 Соленость Неприменим« й-А э 167 Поверхностные воды Вторичные данные 0 0 100 Едини* юе Гидре
7 8 7 8 ри pH в мВ Непримениг^ Неприменим« Э 71 Поверхностные воды Полевые данные 0 0 100 Единич ное Гидре
9 9 Окислительно-восстановительный потенциал Неприменим« э 71 Поверхностные воды Полевые данные 0 0 100 Единичное Гидре
10 10 Нутность Неприменим« э 166 Поверхностные вода Полевые данные 0 0 100 Единичное Гидре V >
ll^TpOK^^^
Рис. 3. Фрагмент базы данных измерений параметров качества воды на Новосибирском водохранилище, полученных многопараметрическим зондом У81 6600У2-4 4-7 июня 2013 г.
Рис. 4. Схема связи БД наблюдений и геопространственных данных
идентификатор, который может быть логически связан с одним или многими объектами в модели данных ГИС. В качестве примера такой взаимосвязи на рис. 4 показано отношение "один к одному" между точками наблюдений из модели данных наблюдений и точками метеопостов на векторном слое. Подобное отношение между точками наблюдений и объектами ГИС имеет общий характер и не даёт никакой информации о структуре и значении данных, хранящихся в ГИС. Такая архитектура позволяет модели данных наблюдений взаимодействовать с любой географической моделью данных, содержащей сведения о расположении точек наблюдений.
2. Развитие геоинформационной системы для решения гидрологических задач
В последние годы наблюдается тенденция использования свободно распространяемых базовых программных продуктов с открытым кодом, существенно снижающих стоимость разработки собственных программных средств и позволяющих отказаться от функционально избыточных коммерческих систем [12].
В качестве физической модели данных для информационно-моделирующих систем, разрабатываемых в ИВЭП СО РАН, используется объектно-реляционная СУБД Post-greSQL [13] — свободно распространяемая СУБД с открытым кодом, поддерживающая большую часть стандарта SQL и предлагающая множество дополнительных сервисов. Так, приложение PostGIS [14] добавляет PostgreSQL поддержку пространственных объектов. Фактически PostGIS представляет собой пространственное расширение PostgreSQL-сервера, что позволяет использовать его как пространственную базу данных для ГИС. Среди некоммерческих продуктов, предоставляющих возможность хранения пространственной информации, связка PostgreSQL/PostGIS обладает наиболее широкой функциональностью.
Для визуализации предобработанной пространственной информации авторами предложена структура проблемно-ориентированной ГИС для системы оперативных прогнозов половодий и паводков в бассейне Верхней Оби с использованием кроссплатфор-менного картографического сервера Geoserver с открытым кодом [15]. Типичное ГИС-приложение включает в себя три функциональных составляющих: презентационный сервис (клиентский интерфейс), сервис прикладной логики (серверное приложение) и сервис данных [16]. Презентационный сервис отвечает за взаимодействие приложения с пользователем, сервис прикладной логики выполняет основные функции приложения, сервис данных, реализованный через систему управления базами данных, обеспечивает взаимодействие приложения с данными. Архитектура распределённого ГИС-приложения выглядит следующим образом: клиент — Web-сервер — сервер приложений ГИС — сервер пространственных данных. Сервер приложений ГИС реализует базовый набор функций геоинформационной системы, которые объединяются в программные компоненты, предоставляющие для применения свои методы и свойства. Этот подход позволяет использовать на клиентских компьютерах достаточно простые приложения, в том числе и стандартные Интернет-браузеры, сосредоточив основную массу вычислений на сервере. В силу того что вычисления выполняются на сервере, значительно уменьшается объём передаваемых данных, поскольку пользователь получает только конечный результат обработки запроса, а не все данные, необходимые для его исполнения.
Архитектура ГИС на основе кроссплатформенного картографического сервера Geoserver представлена на рис. 5.
При работе с пространственными данными Geoserver оперирует четырьмя основными абстракциями: Источник данных, Слой, Стиль слоя и Рабочее пространство. Управление стилем векторного слоя осуществляется путем передачи серверу файла в формате SLD (Style Layer Descriptor). В Geoserver логической единицей, соответствующей отдельному ГИС-проекту, является Рабочее пространство (workspace). Оно содержит источники данных, наборы слоев и стилей — XML-файлов, описывающих визуальное представление и символику слоя.
Абстракция Слой объединяет непосредственно географические данные, один или более присоединённых к слою стилей и, опционально, ссылку на метаданные. Стиль слоя в Geoserver создаётся на XML-подобном языке разметки Style Layer Descriptor (SLD) и определяет цвета геометрических объектов, тип и толщину линий, символику для точечных слоёв, текстовые подписи. В стандарт SLD включена возможность представлять тот или иной объект в зависимости от приданной ему атрибутивной информации и текущего для пользователя масштаба карты, что позволяет выполнять генерализацию и решать другие геоинформационные задачи. Однако непосредственно описание стиля слоя на языке SLD является весьма нетривиальной задачей, что затрудняет возможность формирования и настройки ГИС-проектов клиентами — экспертами конкретной предметной области. Для визуального определения стиля слоя авторами разработан генератор SLD-файлов (SldGenerator), предоставляющий пользователю возможность стилизации и публикации пространственных данных с использованием простого и интуитивно понятного интерфейса.
SldGenerator создан на базе фреймворка Eclipse RCP [17], обеспечивающего возможность быстрой разработки приложений с графическим интерфейсом. В качестве инструмента обработки и визуализации пространственных данных использована библиотека
Рис. 5. Архитектура ГИС на основе кроссплатформенного картографического сервера Geoserver
GeoTools, включающая набор средств для манипулирования картографическими данными и их отображением [18]. На рис. 6 представлена архитектура разработанного приложения, на рис. 7 — схема задания стиля в спецификации SLD.
Формирование стиля согласно схеме на рис. 7 выполняется в следующей последовательности:
— задается тип (content) слоя — векторные объекты или растр;
— в зависимости от типа примитива и значений некоторого атрибута пространственных данных выполняется разбиение объектов на группу категорий;
— к объектам каждой категории применяется ограничивающее правило (например, максимальный или минимальный масштаб видимости);
— для полученной выборки определяется стиль отображения. Стилем можно задать толщину линии, её цвет, прозрачность, цвет заливки (при использовании полигонов), прозрачность заливки, для точечных примитивов можно также указать символ. Для всех типов пространственных объектов можно указать атрибут, который будет отображаться в виде надписи.
Рис. 6. Архитектура приложения SldGenerator SLD
Рис. 7. Схема задания стиля в спецификации SLD
Наличие функций фильтрации и поиска объектов по пространственным отношениям между ними фактически является стандартом для настольных как проприетарных, так и открытых ГИС [19]. Однако в Web-ГИС, реализованной на базе Geoserver, стандартная возможность поиска и фильтрации по пространственным отношениям ограничивается объектами одного слоя и отсутствует возможность сохранения результатов поиска во временных слоях для их последующего использования.
Включение в WEB-ГИС возможностей анализа пространственных данных требует выбора протокола взаимодействия между клиентом и сервером. В ходе пользовательской сессии клиенту должна быть представлена функция сохранения промежуточных результатов. Широко используемые протоколы WMS (Web Map Service для передачи данных в растровом виде) и WFS (Web Feature Service для передачи данных в векторном виде в формате GML) ограничены в форматах ввода-вывода, являются протоколами stateless (без сохранения состояния) и не предусматривают возможность сохранения информации о сессии пользователя; каждая передача данных рассматривается как новая. Однако спецификации OGC (Open Spatial Consortium) содержат протокол WPS (Web Processing Service), лишённый ограничений, присущих протоколам WMS и WFS [20]. Протокол WPS (Web Processing Service) определяет механизм, посредством которого клиент посылает на сервер запрос на обработку пространственных данных (например, сложение двух растров или нахождение выпуклой оболочки набора точек) и получает от сервера результат обработки. Для конкретного экземпляра WPS разрабатывается собственный расширяемый набор задач обработки данных, называемый WPS Processes.
С использованием механизмов WPS-протокола возможности GeoServer по поиску и фильтрации были расширены до сравнимых с возможностями настольных ГИС. Для построения информационно-моделирующей системы оперативных прогнозов половодий и паводков в бассейне Верхней Оби WPS-протокол дополнен следующими функциями:
— поддержка растрового типа данных в WPS-запросах;
— возможность обращения к результату WPS-запроса через WMS- и WFS-протоколы;
— хранение объектов каталога GeoServer с временем жизни, ограниченным длительностью пользовательской сессии.
Выводы
— Разработана структура проблемно-ориентированной ГИС для системы прогнозирования половодий и паводков в бассейне Верхней Оби.
— Определена структура базы данных, содержащей оперативные и архивные данные, характеризующие гидрологическую обстановку; разработана система справочников, позволяющая хранить в БД данные разного качества ("сырые", прошедшие контроль качества, обработанные и т.д.), регулярные данные мониторинга, данные разовых наблюдений и разных периодов наблюдения (от мгновенных до среднемноголетних), а также относящиеся к любым характеристикам изучаемых процессов.
— Созданы инструменты для интегрированной обработки разнородных картографических данных, данных наблюдений, расчётов и моделирования, которые предоставляют возможность решения практически важных гидрологических задач, в том числе по оценке последствий опасных гидрологических явлений.
Список литературы
[1] Зиновьев А.Т., Кошелев К.Б., Марусин К.В., Шиьких А.А. Информационно-моделирующая система на основе компьютерной модели руслового потока: Структура, определяющие уравнения, результаты расчётов // Геоинформационные технологии и математические модели для мониторинга и управления экологическими и социально-экономическими системами / Под ред. И.Н. Ротановой. Барнаул: Пять плюс, 2011. С. 55-62.
[2] Ackerman C.T., Evans T.A., Brunner G.W. HEC-GeoRAS: Linking GIS to hydraulic analysis using ARC/INFO and HEC-RAS // Hydrologic and Hydraulic Modeling Support with Geographical Information Systems / Eds. D. Maidment and D. Djokic. New York: ESRI Press, 2000. P. 155-176.
[3] MIKE 21C-2D River Hydraulics and Morphology. [http://www.dhisoftware.com/Products/ WaterResources/MIKE21C.aspx].
[4] Delft3D-FLOW Simulation of Multi-Dimensional Hydrodynamic Flows and Transport Phenomena, Including Sediments. User Manual. 2011 (Version 3.15). 672 p.
[5] Мотовилов Ю.Г. Состояние и перспективы гидрологического моделирования речных бассейнов России на основе комплекса ECOMAG // Фундаментальные проблемы воды и водных ресурсов: Материалы 3-й Всеросс. конф. с междунар. участием. Барнаул: АРТ, 2010. С. 530-532.
[6] CUAHSI Hydrologic Information System: Overview of Version 1.1. / Ed. D.R. Maidment. Consortium of Univ. for the Advancement of Hydrologic Science, Inc, 2008. 96 p. Available at: http://his.cuahsi.org/documents/HISOverview.pdf
[7] Бик И., Лаукс П. Планирование и управление водохозяйственными системами. Введение в методы, модели и приложения: Пер. с англ. М.: Юстицинформ, 2009. 659 с.
[8] Васильев О.Ф., Зиновьев А.Т., Кошелев К.Б. и др. Разработка информационно-моделирующих систем для оперативного прогнозирования опасных гидрологических ситуаций для крупных речных систем Сибири (на примере Верхней Оби) // Водная стихия: Опасности, возможности прогнозирования, управления и предотвращения угроз. Материалы Всеросс. науч. конф. Новочеркасск: ЛИК, 2013. С. 41-47.
[9] ЛовцкАя О.В., Яковченко С.Г., Жерелина И.В. и др. Геоинформационное обеспечение водохозяйственных и гидрологических расчётов // Сибирский экологический журнал. 2005. Т. 6. C. 1013-1023.
[10] Бугаец А.Н., Гарцман Б.И., Краснопеев С.А., Бугаец Н.Д. Опыт обработки информации модернизированной гидрологической сети с использованием системы управления данными CUAHSI HIS ODM // Метеорология и гидрология. 2013. № 5. С. 91-101.
[11] Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели анализа данных: OLAP и Data Mining. СПб.: БХВ-Петербург, 2004. 336 с.
[12] Neteler M., Mitasova H. Open Source GIS: A Grass GIS Approach. New York: Springer, 2008. 420 с.
[13] Вислоьоков В. Краткий обзор возможностей PostgreSQL [http://postgresql.ru.net/].
[14] What is PostGIS [http://postgis.refractions.net/].
[15] What is GeoServer [http://geoserver.org/display/GEOS/What+is+GeoServer].
[16] Чандра А.М., Гош С.К. Дистанционное зондирование и географические информационные системы. М.: Техносфера, 2008. 312 с.
[17] Vogel Lars Eclipse 4 RCP — Tutorial. Building Eclipse RCP applications based on Eclipse 4. Available at: http://www.vogella.com/tutorials/EclipseRCP/article.html
[18] Architecture — GeoTools 8.0-RC1 User Guide [http://docs.geotools.org/latest/userguide/welcome/architecture.html].
[19] Clementini E., Sharma J., and Egenhofer M. Modeling topological spatial relations: Strategies for query processing // Comput. and Graphics. 1994. Vol. 18(6). P. 815-822.
[20] Christopher M., Daniel P.A. Evaluation of the OGC Web processing service for use in a client-side GIS // The J. of the Open Source Geospatial Foundation. Vol. 1. May 2007 [http://osgeo.org/journal].
Поступила в 'редакцию 21 марта 2014 г.
