Знакомство с Web Feature Service
Данная статья представляет собой введение в протокол OGC Web Feature Service. Рассматривается версия протокола 1.1.0.
Введение
Предположим, у нас имеется большой объём обновляемых данных, например, данные по тепловым аномалиям на территорию Российской Федерации, хранящиеся в пространственной базе данных PostGIS и какой-нибудь сторонний разработчик принимает решение использовать их в своем приложении. Прежде всего он вынужден будет реализовать все необходимые операции (извлечение, фильтрацию и т.п.), в терминах того хранилища к которому он подключен (в нашем случае в качестве таких терминов выступают операторы языка SQL). Если мы вдруг решим сменить способ хранения (например, перейдем на файловый вариант) или появится более качественный источник аналогичных данных, но в другом формате и разработчику нужно будет переключиться на него, то он будет вынужден полностью переписывать ту часть своего приложения, которая отвечает за извлечение данных из хранилища. Так вот основная задача WFS-сервисов - это предоставление разработчикам (или конечным потребителям данных) универсального интерфейса доступа к пространственным данным, элиминирующего необходимость прямого доступа к хранилищу и таким образом делающего его прозрачным для пользователя. В этом случае задача по реализации доступа к различным хранилищам данных ложится на плечи WFS-сервера, то есть WFS сервер выступает в качестве прослойки между хранилищем данных и пользователем данных (к пользователям данных могут относится и в том числе и программы). Стандарт предполагает, что на выходе WFS-сервис отдает данные в формате Geography Markup Language (GML)[1], но это нисколько не запрещает на уровне WFS-сервера реализовать поддержку любого другого выходного формата.
Важно отличать Web Feature Service (WFS) от Web Map Service (WMS). В то время как WMS предназначен для передачи уже отрендеренных данных, WFS отдаёт данные в оригинальном виде. Можно провести аналогию: скомпилированная программа (WMS) и исходный код (WFS).
На сегодняшний день существует 2 версии WFS - 1.1.0 и 2.0. Обе версии считаются действующими, но несколько отличаются друг от друга. В рамках данной статьи будет рассмотрена работа с WFS 1.1.0.
GET и POST запросы
Здесь и далее мы не будем приводить ответы WFS-сервера, а будем использовать для этого онлайн-сервис hurl, позволяющий наглядно представить запрос и ответ WFS-сервера.
Существует два способа получения данных с WFS-сервера: HTTP GET и HTTP POST. При GET-запросе данные запроса передаются помощью строки URL:
http://wfsserver?key1=value1&ke2=value2
Представленный запрос формируется путём добавления параметров запроса в виде ?ключ=значение&ключ=значение&... к адресу WFS-сервера. Часть этих самых ключей и допустимых значений определены в стандарте WFS[2], а часть, так называемая vendor-specific, реализована в рамках того или иного WFS-сервера, но при этом отсутствует в стандарте. Поскольку официально на длину URL не накладывается никаких ограничений, то с помощью метода GET можно выполнять WFS-запросы любой длины. К преимуществам такого способа взаимодействия с WFS-сервером можно отнести такой момент: в этом случае пользователь может вставить строку запроса непосредственно в адресную строку браузера или поделиться ей с кем-нибудь, кому будут нужны те же самые данные (например, отфильтрованные по тому или иному признаку).
POST-запросы - это более мощный инструмент, позволяющий передавать параметры запроса в формате XML в теле самого запроса. Любой GET-запрос к WFS-серверу можно описать в формате POST (обратное утверждение не верно).
Доступные методы
Стандарт WFS описывает 6 методов, каждый из которых отвечает за выполнение той или иной операции:
- GetCapabilities
- DescribeFeatureType
- GetFeature
- GetGMLObject
- Transaction
- LockFeature
Поскольку мы рассматриваем базовые возможности WFS, то остановимся на рассмотрении только первых трёх методов: GetCapabilities, DescribeFeatureType, GetFeature и GetGMLObject - довольно сложная штука и вряд ли вы с ней столкнётесь, а последние два метода Transaction и LockFeature предназначены для выполнения операций по редактированию объектов.
GetCapabilities
Для клиентов, в первый раз подключающихся к WFS-серверу, необходимо знать возможности этого сервера (доступные слои, поддерживаемые функции фильтрации и т.п.). Запрос GetCapabilities позволяет осуществить запрос такой информации.
Пример запроса GetCapabilities c помощью метода GET:
http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.1.0&request=GetCapabilities
Пример запроса GetCapabilities c помощью метода POST.
В данных примерах WFS-серверу было передано 3 параметра: "service=wfs", "version=1.1.0", and "request=GetCapabilities". Это три обязательных параметра, которые должны присутствовать в любом WFS-запросе (service, version, request). Иногда WFS-сервер ослабляет это требование, но официально - это три обязательных параметра, поэтому следует всегда включать их в свои запросы. Параметр service сообщает WFS-серверу, что выполняется WFS-запрос, version - передаёт информацию о версии сервиса, request - запрашиваемый метод.
Документ, полученный в ответ на запрос GetCapabilities, представляет собой длинный и сложный XML-документ, но он очень важный. Стоит отметить, что GetCapabilities ответ версии 1.0.0 (устаревший вариант) значительно отличается от ответа GetCapabilities версии 1.1.0. Рассмотрим 5 основных разделов этого документа:
- ServiceIdentification - базовая информацию о WFS-сервисе, в частности, поддерживаемые версии;
- ServiceProvider - контактная информация о компании, стоящей за данным WFS-сервисом: телефон, сайт, email;
- OperationsMetadata - описаны поддерживаемые WFS-сервером методы и их параметры, в частности, форматы выходных данных;
- FeatureTypeList - список слоёв, включая используемую проекцию, а также параметры ограничивающего прямоугольника;
- Filter_Capabilities - список поддерживаемых фильтров, доступных при запросе данных.