Знакомство с Web Feature Service

Эта страница является черновиком статьи.

Данная статья представляет собой введение в протокол OGC Web Feature Service. Рассматривается версия протокола 1.1.0.

Введение

Предположим, у нас имеется большой объём обновляемых данных, например, данные по тепловым аномалиям на территорию Российской Федерации, хранящиеся в пространственной базе данных PostGIS и какой-нибудь сторонний разработчик принимает решение использовать их в своем приложении. Прежде всего он вынужден будет реализовать все необходимые операции (извлечение, фильтрацию и т.п.), в терминах того хранилища к которому он подключен (в нашем случае в качестве таких терминов выступают операторы языка SQL). Если мы вдруг решим сменить способ хранения (например, перейдем на файловый вариант) или появится более качественный источник аналогичных данных, но в другом формате и разработчику нужно будет переключиться на него, то он будет вынужден полностью переписывать ту часть своего приложения, которая отвечает за извлечение данных из хранилища. Так вот основная задача WFS-сервисов - это предоставление разработчикам (или конечным потребителям данных) универсального интерфейса доступа к пространственным данным, элиминирующего необходимость прямого доступа к хранилищу и таким образом делающего его прозрачным для пользователя. В этом случае задача по реализации доступа к различным хранилищам данных ложится на плечи WFS-сервера, то есть WFS сервер выступает в качестве прослойки между хранилищем данных и пользователем данных (к пользователям данных могут относится и в том числе и программы). Стандарт предполагает, что на выходе WFS-сервис отдает данные в формате Geography Markup Language (GML), но это нисколько не запрещает на уровне 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, а часть, так называемая 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 - список поддерживаемых фильтров, доступных при запросе данных.