Сервисы доставки данных OWS: различия между версиями

Материал из GIS-Lab
Перейти к навигации Перейти к поиску
Нет описания правки
Строка 168: Строка 168:
==Ссылки==
==Ссылки==


#Peter Baumann, "Flexible, Open, Free: The New OGC WCS 2.0 and its Reference Implementation", FOSS4G 2010.
#Peter Baumann, [http://2010.foss4g.org/presentations_show.php?id=3183 "Flexible, Open, Free: The New OGC WCS 2.0 and its Reference Implementation"], FOSS4G 2010.
#Andrea Aime, "Developers Corner: have your SLD transform raster data into vectors on the fly".
#Andrea Aime, [http://geo-solutions.blogspot.com/2011/01/developers-corner-have-your-sld.html "Developers Corner: have your SLD transform raster data into vectors on the fly"].

Версия от 19:48, 16 августа 2012

Эта страница опубликована в основном списке статей сайта
по адресу http://gis-lab.info/qa/ows.html


Объясняется почему и для чего существуют WMS, WFS, WCS и WPS. Как они взаимодействуют и где применяются. В статье не дается обзор существующих решений или сравнение программных продуктов.


Введение

Под акронимом OWS (OGC Web Services) скрываются различные сервисы - WMS, WFS, WCS и т.д. Попробуем разобраться для чего они существуют и какую цель преследовали разработчики этих стандартов.

Самое простое из распространенных объяснений выглядит так:

  • WMS - картинка (растр);
  • WFS - вектор;
  • WCS - грид (тоже растр, но другой).

Примем его за основу и задумаемся над таким вопросом. Если уже имеются векторные или растровые данные, то зачем их превращать в сервис? Данные хранятся в файлах и базах данных, которые для простоты будем называть "хранилищами". Сервисы занимаются транспортировкой данных из хранилищ к клиентам (чтение) и обратно (запись). Они также обслуживают различные запросы пользователей. Для географических сервисов это могут быть указания о перепроецировании данных, применении атрибутивных (country='RUSSIA') и пространственных (объекты в радиусе 100 м) фильтров, преобразовании форматов.

Если данные хранятся в файлах, то их можно просто загрузить целиком, нельзя взять только нужную часть. При этом программа-клиент должна будет самостоятельно разобраться в их внутреннем формате. Примеры распространенных векторных и растровых форматов, применяемых в ГИС: ESRI Shapefile, MapInfo, SXF, GeoJSON, KML, GeoTIFF, ECW и др. При разработке программы-клиента требуется, как минимум, реализация базовых операций ввода-вывода. Часть из этих задач решается использованием готовых библиотек, например, GDAL/OGR. Для хранения векторов и растров консорциумом OGC предложен формат GML (Geography Markup Language), но он удобен только в роли обменного формата, слабо применим в хранении (из-за избыточного объема) и обладает низкой скоростью чтения и записи.

Доступ к базам данных осуществляется с помощью запросов SQL. Но этот язык имеет несколько диалектов, полнота реализации стандарта разнится, да и сама процедура подключения к БД несколько отличается для разных продуктов. Форматы географического описания объектов (геометрия) в большинстве БД следуют рекомендациям OGC Simple Features и специфические форматы на сегодняшний день можно считать ушедшими в прошлое.

При разработке тонкого клиента или узко специализированного инструмента обработки данных желателен один универсальный интерфейс ко всем форматам и методам доступа. Использование сервисов OWS потребует организовать поддержку только одного формата (например, GML). Причем исходные данные могут храниться в самых различных видах и вся работа с ними перекладывается на плечи сервера. А значит, инструмент ГИС может получить то что ему требуется, не прилагая усилий. Например, многие существующие серверы позволяют предоставлять в сервисе WFS данные не только в формате GML, но во многих других векторных форматах - GeoJSON, ESRI Shapefile, DWG и т.п. Такой сервис можно встроить в уже существующую цепочку обработки данных, незначительно доработав программы, и получить доступ к широкому спектру хранилищ.

Стоит отметить, что спецификации OGC не описывают устройство программы-сервера. От нее требуется только предоставлять на выходе "правильный" сервис. А что происходит внутри, как реализованы процедуры ввода/вывода, перепроецирования, фильтрации и откуда сервер получает данные, может быть полностью скрыто от пользователя. Например, можно создать сервер WFS, который будет обращаться в интернет и собирать веб-страницы с прогнозами погоды, сопоставлять названия населенных пунктов с их координатами из БД, преобразовывать в пространственные объекты (точки с семантикой) и предоставлять (опубликовывать) в виде сервиса. Программа-клиент не знает источник данных, но может свободно с ними работать. Аналогично с применением фильтров. Очевидно, что для БД PostGIS и файла ESRI Shapefile на уровне технической реализации потребуются абсолютно разные подходы. Но это, опять же, забота сервера, а на уровне сервиса все фильтры описываются одинаково (спецификация "Filter Encoding").

Вывод - сервисы OWS не порождают новые данные, а занимаются только их доставкой (транспортировкой). Чуть позже, мы отойдем от такой трактовки, но в первом приближении к ним следует относиться именно так.

WFS (Web Feature Service)

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

Приведем пример из веб-программирования. Пусть данные лежат в БД PostGIS. Для доступа к ним воспользуемся запросами SQL. Простое приложение CGI на языке PHP:


<?php
// подключение
$conn = pg_connect("host=localhost dbname=geos user=vasya password=secret");
if (!$conn) {
  echo "An error occured.\n";
  exit;
}
 
// запрос
$result = pg_query($conn, 'SELECT * FROM mytable');
if (!$result) {
  echo "An error occured.\n";
  exit;
}
 
// сбор данных в массив (в примере - только первый столбец)
$arr = Array();
while($row = pg_fetch_row($result)) {
	array_push($arr, $row[0]);
}
pg_close($conn);
 
// кодирование в формат JSON
echo json_encode($arr);
?>
	

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

  • фильтры атрибутивные и пространственные;
  • запись новых и измененных данных обратно в БД;
  • запросы типа POST для работы с большими объемами данных.

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

  • унифицированные операции работы с данными, не зависящие от конкретной реализации (доработка или изменение другим программистом);
  • свободная миграция между хранилищами данных (задача смены БД);
  • единый язык описания фильтров (пусть и с потерей отдельных возможностей конкретного хранилища);
  • перепроецирование;
  • различные форматы на выходе (GML, GeoJSON, CSV).

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

Вывод - сервис WFS предназначен для доставки векторных данных с минимальной их обработкой (преобразование форматов) в прямом и обратном направлении (чтение-запись) с возможностью задания фильтров.

WCS (Web Coverage Service)

Сервис работает с данными, которые описываются терминами "грид" (grid) или "покрытие" (сoverage). Реальные примеры - космоснимки, данные с многоканальных сенсоров ДЗЗ, модели рельефа (DEM) и т.п. Все они имеют схожий формат хранения - прямоугольная область, разделенная по регулярной сетке, в каждой ячейке которой содержится несколько значений. Для многоканальных сенсоров в каждой ячейке число значений будет равно количеству каналов. Частными случаями многоканального грида являются RGB-композит (3 канала - red, green, blue) и модель рельефа (1 канал - высота). Строго говоря, WCS умеет работать и с нерегулярными криволинейными сетками, с TIN и произвольными сетями (рис. 1).

Рис. 1. Примеры нерегулярных гридов [1]

Нерегулярный грид
Нерегулярный грид

При работе с гридами требуются операции:

  • доступ к отдельным каналам;
  • выбор некоторой области растра;
  • выбор по дате из серии снимков (временны́е запросы).

Как и для сервиса WFS задачи WCS сводятся к унифицированному доступу к различным хранилищам (WKTRaster, RasterLite, rasdaman), базовым операциям чтения-записи и применению фильтров. Форматы - расширенный GML, GeoTIFF, JPEG2000 и др.

Вывод - сервис WCS предназначен для доставки растровых данных (грид).

WMS (Web Map Service)

Все сервисы OWS спроектированы по общему принципу и WMS очень похож на WFS и WCS. Но, если те были предназначены для доступа к существующим данным, то в WMS происходит создание новых. На основе данных из WFS и WCS (на практике чаще используют прямой доступ к хранилищам) сервис WMS создает карты с заданными стилями оформления. Можно взглянуть на его работу и с такой позиции - он занимается транспортировкой данных, представляя их в несколько иной форме. Зачастую, WMS используют для доступа к мозаиками космоснимков, хотя с формальной точки зрения это задача WCS.

Рис. 2. Место WMS среди сервисов WFS и WCS [1]

WMS vs. WFS & WCS

Наиболее распространенный пример работы WMS - создание топо-карт из растровых (космоснимки, сканированные планшеты) и векторных данных (дороги, гидрография, населенные пункты).

Характеристики WMS:

  • базовые понятия - "слой" и "стиль";
  • цель - получение карты; это не обязательно должен быть RGB-растр, широко используются форматы PDF, SVG, SWF;
  • задача сервиса - принять от клиента указания и вернуть их графическое представление;
  • главный элемент - это рендер.

Отдельно хотелось бы заострить внимание на рендере. Этот элемент занимается преобразованием исходных данных в формат изображения. Например, векторные линии с учетом заданных стилей преобразует в представление автодорог, а полигоны окрашивает в цвет лесов. История картографических серверов достаточно долгая и изначально они не имели узко определенных задач. В эпоху, предшествующую Web 2.0, на них, зачастую, возлагали ответственность за создание веб-порталов с оформлением, инструментами навигации и взаимодействия с пользователем. Следы тех времен можно увидеть в UMN MapServer (TEMPLATE, QUERYMAP, SCALEBAR). Но на сегодняшний день серверы WMS занимаются только узкой задачей - генерирование карт. Хотя в сам рендер может быть заложен формат на базе HTML, который генерирует веб-страницу. Редко используемая возможность, но примеры можно найти в GeoServer и SUAS MapServer.

В последнее время активно развиваются средства подготовки карт в формате PDF. Это находит применение в веб-приложениях и в генерировании карт большого формата при подготовке к печати.

Вывод - сервис WMS создает карты, получает указания от клиентов и доставляет готовый результат. Изменение (запись) в хранилища данных в этом сервисе не предусмотрена.

Кэширующие серверы

Не останавливаясь подробно, рассмотрим только взаимотношения с сервисами WMS (встречаются также кэширующие серверы WFS) и будем условно их называть "тайловые сервисы".

Как правило, работа программ-кэшей ограничена rgb-растрами. Появились они чисто из технической потребности оптимизации скорости сервисов WMS. Основное время работы сервера WMS тратится на рендеринг. Поэтому процедуру проводят однократно и создают наборы тайлов. И при обращении к сервису клиент может получить результат быстро. Это накладывает обязательства на программу-клиент (следование параметрам тайловой схемы) и применяется в основном в веб-приложениях. По такой схеме работает сервис WMS-C (разработан в OSGeo).

Наборы тайлов сами по себе являются информацией (данными). Для их хранения используют файлы (структуры из вложенных папок) или базы данных (MBTiles). Теоретически, они относятся к гридам - по 3 канала на каждый масштаб увеличения. Но так сложилось, что их причисляют скорее к сервисам WMS чем к WCS. Сервисы доступа к хранилищам тайлов - TMS (OSGeo) и WTMS (OGC).

На самом деле различия в тайловых сервисах весьма расплывчаты. Раз серверу WMS-C приходится хранить тайлы, то он же может предоставлять и сервис TMS, что очень распространено. Дополнительно, кэширующие серверы занимаются множеством прикладных задач: позволяют по имеющимся тайлам интерполировать новый с промежуточным масштабом (не совпадающим с тайловой схемой), производить перепроецирование, преобразование растровых форматов, объединять несколько слоев в один, наносить водяные знаки и т.д.

В целом, тайловые сервисы занимаются вспомогательными задачами и сопровождают сервисы WFS, WMS и WCS. Хотелось бы специально отметить, что сервис WMS занимается генерированием карт в общем виде и создание кэшей не входит в его задачи.

WPS (Web Processing Service)

Второй сервис, который создает данные. Но если WMS мог только незначительно влиять на объекты (функции трансформации в фильтрах стилей SLD), то WPS - это интерфейс к возможностям настольных ГИС, пакетам гео-моделирования, инструментам статистики и обработки. Результатом его работы могут быть как растровые, так и векторные данные.

Мир ГИС представлен богатым разнообразием инструментов: консольные пакеты типа GRASS; библиотеки для разработчиков на различных языках программирования (GeoTools, GEOS, Sextante); настольные приложения (FME, ArcGIS); модели и симуляторы окружающей среды (Drift-X).

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

Сервер WPS скрывает все взаимодействие с библиотеками и программами обработки. И для клиента все операции выглядят единообразно независимо от того, кто реально обрабатывает данные.

Например, стоит задача "выполнить теневую отмывку рельефа". Допустим, что грид рельефа доступен по WCS. Тогда задачу можно решить двумя способами. Первый - открыть настольную программу типа SAGA GIS, загрузить грид и применить метод из богатой библиотеки этой программы. В результате получим растровое изображение. Второй - работая в Quantum GIS обратиться на сервер WPS, выбрать функцию, выполняющую теневую отмывку, передать ей ссылку на WCS и получить отмывку.

Второй способ интересен разделением труда: одни программисты создают программы для пользователей, в которых удобно работать, визуально анализировать результаты обработки, создавать компоновки для печати; другие программисты заняты реализацией алгоритмов обработки данных, выбирая удобные им языки и технологии. При этом сервер WPS может физически работать на том же компьютере где и программа-клиент, а может быть вынесен на мощный сервер. Программа gvSIG GIS помимо собственных методов обработки позволяет обратиться к возможностям библиотеки SEXTANTE. В Quantum GIS построена интеграция с GRASS и Orfeo Toolbox. Сервер WPS позволил бы работать со всеми тремя библиотеками как в gvSIG так и в Quantum GIS.

Вывод - обрабатывает существующие и создает новые данные.

Заключение

Сервисы OWS являются интерфейсами между клиентами и хранилищами данных (WFS, WCS). Создают среду взаимодействия клиентов с инструментами обработки (WMS, WPS) и сервисов между собой. Позволяют строить цепочки преобразования данных в результат. Например, возьмем из БД грид рельефа, по WCS отправим в WPS для построения изолиний, затем полилинии нанесем на топокарту с нужной толщиной линии, бергштрихами и подписями, результат передадим клиенту (WMS).

Если развить архитектуру OWS до предела, то перед нами предстанет мир, где данные, процессы и пользователь тщательно разделены. Пользователь выбирает на сервере WPS нужный алгоритм обработки, направляет в него данные (WFS, WCS), а результат или выдается сразу или отправляется в хранилище. Стремительное развитие серверов WPS, а ведь еще на FOSS4G 2009 были представлены только первые разработки, и большой интерес к ним во всем мире позволяет прогнозировать активное их применение в ближайшем будущем. Будут это "настольные" серверы WPS, решения для локальных сетей или интернет-сервисы? - вероятно, это будет что то среднее и они не вытеснят полностью традиционные ГИС со встроенными методами обработки данных. Возможно, появятся преднастроенные "готовые" серверы WPS с узко специализированными наборами операций - решение повседневных задач гидролога, методы классификации растительности по данных ДЗЗ и т.п.

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

Сервисы OWS открывают не только данные, но и процессы. С их помощью вы можете поделиться алгоритмом классификации растительности по снимкам Aster или разложения по румбам экспозиций склонов. Данные используются в процессах, а процессы порождают данные. Граница между сервисами условна, особенно для WMS. Он лежит между WFS и WCS, и очень часто переступает границы их задач. А используя концепцию функций (functions) WMS способен потеснить WPS и выполнять обработку данных, например, строить горизонтали по гриду [2].

Ссылки

  1. Peter Baumann, "Flexible, Open, Free: The New OGC WCS 2.0 and its Reference Implementation", FOSS4G 2010.
  2. Andrea Aime, "Developers Corner: have your SLD transform raster data into vectors on the fly".