РОССИЙСКИЙ НАУЧНЫЙ ЭЛЕКТРОННЫЙ ЖУРНАЛ Электронные библиотеки
2011 - Том 14 - Выпуск 4

Анализ геоинформационных данных в распределенных инфраструктурах

Шулькин Е.В., Краснопеев С.М.

 

Аннотация

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

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

Ключевые слова: анализ пространственных данных, открытый геопространственный консорциум, инфраструктура пространственных данных, Web Processing Service, WPS, клиент анализа данных.

Введение

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

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

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

Поэтому, в настоящее время крайне востребованным является:

  • Организация управления накапливаемыми информационными ресурсами
  • Разработка служб геопространственного анализа информации

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

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

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

Стандарты OGC

Ключевым условием достижения успеха на пути развертывания инфраструктур публикации и анализа данных является решение проблемы геопространственной интероперабельности. Выработкой подходов к решению данной проблемы занимается Открытый геопространственный консорциум (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

Стандарт обработки данных WPS

Согласно принятым OGC нормативам, стандартом обработки геопространственных данных является Web Processing Service (WPS) [6]. Стандарт WPS – это веб-сервис, предоставляющий услуги геопроцессинга растровых и векторных данных. Операции могут быть как простыми (например, геометрические операции над векторными данными), так и очень сложными, вплоть до расчета глобальных экологических моделей. В стандарте определен протокол передачи данных, формат команд для запуска процесса и получения результатов. Это публикация услуги в чистом виде.

Теоретически, протокол WPS не зависит от платформы и сделан по стандарту простого протокола доступа к объектам (SOAP, Simple Object Access Protocol). Однако на практике поддерживается лишь протокол HTTP.

Стандарт определяет три операции:

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

Веб-сервис принимает эти команды в формате XML или в виде URL-encoded запроса. Стандарт очень гибкий, это обеспечивается его свойствами:

  • Входные и выходные данные могут быть как ссылками на данные, так и быть встроенными в тело запроса или ответа.
  • Если ответ простой, например, изображение в формате GIF, веб-сервис может вернуть его напрямую, не оборачивая в XML.
  • Поддерживаются различные форматы входных и выходных данных. Например, числа и строки, ограничивающие прямоугольники (Bounding Box), векторные данные в формате GML и бинарные данные. Теоретически, список не ограничен, т.к. веб-сервис подразумевает возможность дополнить его собственным форматом данных.

Реализации WPS

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

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

В общем смысле, реализация стандарта WPS подразумевает реализацию двух компонентов развертывания:

  • Серверная часть веб-сервиса. Реализуется в виде серверного приложения. Большинство существующих на данный момент реализаций написано на Java, но есть сервера, которые написаны на C и на Python.
  • Клиентское приложение. Может быть как десктопным, так и браузерным.

Серверное приложение WPS

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

Рис. 2. Схема веб-сервиса

На данный момент существует несколько успешно развивающихся проектов, направленных на реализацию стандарта WPS:

  • deegree WPS [7]
    Проект сообщества, которое занимается исследованиями в области GIS-технологий с 2000 г. Основным результатом их деятельности является программный комплекс deegree, который состоит из нескольких компонент. Каждая компонента реализует одну спецификацию OGC – WMS, WFS, WCS и WPS. Основной идей компонента deegree WPS было максимально облегчить процесс публикации пользователем своего алгоритма. Для этого был сделан ряд упрощений – процессы пишутся строго на Java, по определенным стандартам, используя ряд написанных разработчиками deegree классов и модулей.
  • ZOO Project WPS [8]
    Проект молодого геоинформационного сообщества. При разработке они ставили две цели. Во-первых, дать пользователям веб-сервиса возможность публиковать процессы, написанные на разных языках; в список поддерживаемых языков входят Java, C/C++, Python и Perl. Во-вторых, изучить возможность связывания алгоритмов в цепочки анализа данных. Для этого разработчики предоставили серверное API на JavaScript.
  • GeoServer WPS [9]
    В данной реализации стандарта WPS не предусмотрена возможность публикации собственного процесса в виде исходного кода. Но проект GeoServer объединяет в себе реализацию нескольких стандартов OGC, включая WMS, WFS и WCS, и ориентирован на публикацию данных. Если запрос к GeoServer WPS в качестве входных данных использует ссылку на пространственные данные, которые опубликованы при помощи того же экземпляра GeoServer и расположены на одном сервере с процессом, то скорость выполнения процесса резко возрастает. Поддерживается кэш результатов, что также дает преимущество в скорости выполнения запросов.
  • pyWPS [10]
    Проект веб-сервиса на Python. Поддерживается публикация процессов, но они тоже должны быть написаны на Python.
  • 52° North WPS [11]
    В отличие от реализаций других компаний, несколько экземпляров веб-сервиса 52° North WPS развернуты самим сообществом разработчиков и успешно работают уже долгое время. Поддерживаются алгоритмы из следующих источников: GRASS GIS [12], Sextante [13], ArcGIS [14]. Связь с этими источниками достигается за счет серверных приложений, которые связывают веб-сервис с соответствующим сторонним хранилищем алгоритмов. Таким образом, 52° North 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

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

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

Рис. 6. Ресурсы клиента

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

Требования к клиенту определяются исходя из множества критериев. Неизменным остается базовый алгоритм работы, который определен самой логикой стандарта WPS.

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

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

Рис. 7. Выбираем набор функций клиента

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

Развитие клиента WPS

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

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

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

Умение решать простейшие задачи анализа ПД

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

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

Умение решать специфические задачи пользователя

Именно для таких случаев существует все многообразие опубликованных по открытым стандартам алгоритмов анализа данных; а также в некоторых реализациях WPS предусмотрена возможность публикации исходного кода.

На стороне клиента для решения таких задач требуются более развитые средства управления данными и слоями.

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

Кроссплатформенность

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

Для решения этой задачи можно предложить следующие шаги:

  • Браузерный клиент
    Наиболее простым способом решить проблему совместимости клиента на разных платформах является реализация клиента в виде браузерного приложения или сайта. Сложная проблема кроссплатформенности заменяется более тривиальной проблемой кроссбраузерности. Помимо этого, браузерная реализация решает проблему массового доступа.
  • Реализация клиента в виде подключаемого модуля
    Следующим шагом развития браузерного клиента становится идея использования возможностей уже созданных картографических сайтов и гео-порталов. Клиент анализа данных в этом случае следует реализовать в виде подключаемого программного модуля, в котором есть интерфейс для приема стандартизованных входных данных от сторонних приложений.
  • Реализация клиента в виде плагина к популярному браузерному картографическому приложению
    Предыдущий пункт, в силу огромного разнообразия картографических сайтов и настольных приложений, является излишне сложным и утопичным. Более реальным видится создание модуля на основе уже существующей среды для разработки картографических сервисов. Например, популярной картографической библиотеки OpenLayers, которая, на сегодняшний день, является стандартом де-факто для создания клиентской части инфраструктуры пространственных данных. Таким образом, мы теряем универсальность клиента, но получаем простоту в использовании и подключении.
  • Создание промежуточного веб-сервиса обработки запросов
    Логичным шагом видится создание отдельного веб-сервиса обработки запросов и ответов от сервиса анализа данных, моста между клиентом и WPS. Т.к. этапы получения метаданных и описания процессов, а также преобразования результата в удобный для обработки формат являются унифицированными для любых классов задач, наличие такого веб-сервиса позволит облегчить логику клиента и сконцентрироваться на решении задач назначения входных данных.

Универсальность и независимость от входных данных

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

Такую задачу предлагается решить следующим образом:

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

Рис. 8. Классы входных данных

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

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

Поддерживаются:

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

Необходимые системные требования:

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

    Адрес тестовой страницы – http://gis.dvo.ru:9080/web

    Технически, клиентский модуль представляет собой набор скриптов на JavaScript и PHP, а также таблиц стилей.

    Модуль загружается с сайта AJAX-запросом и выводится во всплывающем окне при помощи библиотеки highslide [17]. К сожалению, пока еще нет возможности изменить дизайн клиентского модуля, помимо модификации исходного кода.

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

    • Оверлейные операции.
    • Вычисление топологических характеристик.

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

    Шаг №1

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

    Рис. 9. Исходные векторные данные

    Шаг №2

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

    Рис. 10. Интерфейс выбора веб-сервиса и процесса

    Шаг №3

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

    Рис. 11. Интерфейс выбора входных значений

    Шаг №4

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

    Рис. 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: evgeny.shulkin@gmail.com

    Краснопеев Сергей Михайлович – зав. Лабораторией ГИС-технологий и моделирования геосистем ФГБУН Тихоокеанского Института географии Дальневосточного отделения РАН (ТИГ ДВО РАН). e-mail: sergeikr@tig.dvo.ru


    Последнее обновление страницы было произведено: 2012-03-26

    Все предложения и пожелания по содержанию и структуре портала направляйте по адресу rdlp@iis.ru