Знакомство с 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

Представленный запрос формируется путём добавления параметров запроса в виде ?ключ1=значение1&ключ2=значение2&... к адресу WFS-сервера. Часть этих самых ключей и допустимых значений определены в стандарте WFS, а часть, так называемая vendor-specific, реализована в рамках того или иного WFS-сервера, но при этом отсутствует в стандарте. Поскольку официально на длину URL не накладывается никаких ограничений, то с помощью метода GET можно выполнять WFS-запросы любой длины. К преимуществам такого способа взаимодействия с WFS-сервером можно отнести такой момент: в этом случае пользователь может вставить строку запроса непосредственно в адресную строку браузера или поделиться ей с кем-нибудь, кому будут нужны те же самые данные (например, отфильтрованные по тому или иному признаку).

POST-запросы - это более мощный инструмент, позволяющий передавать параметры запроса в формате XML в теле самого запроса. Любой GET-запрос к WFS-серверу можно описать в формате POST (обратное утверждение не верно). Значение заголовка Content-Type при таком запросе должен быть согласно стандарту установлен в значение text/xml.

Отметим, что в теле POST запроса можно передавать не только XML документ, но и набор вида "ключ1=значение1&ключ2=значение2..." Пример такого запроса доступен здесь. Значение заголовка Content-Type при таком запросе должен быть согласно стандарту установлен в значение application/x-www-form-urlencoded.

Доступные методы

Стандарт 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 - список поддерживаемых фильтров, доступных при запросе данных.

DescribeFeatureType

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

Пример запроса DescribeFeatureType методом GET:

http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.1.0&request=DescribeFeatureType

Пример запроса DescribeFeatureType методом POST.

Данный запрос вернёт список слоёв, сгруппированных по значению атрибута namespace. Если мы хотим получить описание конкретного слоя, то запрос будет выглядеть следующим образом.

Пример запроса DescribeFeatureType с указанием конкретного слоя методом GET:

http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.1.0&request=DescribeFeatureType&typeName=topp:states

Пример запроса DescribeFeatureType с указанием конкретного слоя методом POST.

Легко запутаться при чтении XML-документа, но на самом деле здесь не так много информации. Из полученного ответа можно заключить, что слой topp:states содержит 23 атрибута, один из которых представляет описание геометрии, четыре текстовых и восемнадцать числовых атрибутов. Кроме того, в ответе представлены имена атрибутов.

GetFeature

Описаные выше два метода конечно полезны, однако наиболее важный метод ради которого и был разработан стандарт WFS - метод GetFeature, позволяющий запрашивать с сервера непосредственно сами данные. Данный метод необходимо использовать совместно с параметром typeName, определяющем имя слоя, объекты которого мы запрашиваем. Пример запроса GetFeature методом GET:

http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.1.0&request=GetFeature&typeName=topp:states

Пример запроса GetFeature методом POST.

Final Words

http://qblx.co/OZEtQv http://hurl.quickblox.com/hurls/f412acc984009a3364c2777970845bc2b8d3d005/b82c5fe63b4d77754cd2d9de488f7a9a44affdd6