Web Map Server Implementation Specification

Материал из GIS-Lab
Версия от 06:09, 24 апреля 2013; Denis Rykov (обсуждение | вклад) (Новая страница: «== 6 Базовые элементы сервиса == === 6.1 Введение === В данном разделе рассматриваются аспекты…»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Перейти к навигации Перейти к поиску

6 Базовые элементы сервиса

6.1 Введение

В данном разделе рассматриваются аспекты работы Web Map Server, не зависящие от конкретных операций или являющиеся общими для различных операций.

6.2 Нумерация версий и их согласование

6.2.1 Нумерация версий

Web Map Service (WMS) определяет номер версии протокола. Данный номер применяется к XML-схеме и способу кодирования запросов, рассматриваемых в рамках данного Международного Стандарта. Номер версии состоит из трёх неотрицательных целых чисел, разделенных точкой, в формате "x.y.z". Числа "y" и "z" не должны превышать 99.

6.2.2 Изменение номера версии

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

6.2.3 Отображение в запросе и в метаданных сервиса

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

6.2.4 Согласование версий

WMS-клиент может согласовать с сервером номер взаимоприемлемой версии протокола. Согласование осуществляется посредством использования операции GetCapabilities (описываемой в 7.2) согласно следующим правилам.

Все метаданные сервиса должны включать номер версии протокола и должны соответствовать XML DTD или определению Схемы для данной версии. В ответ на запрос GetCapabilities (для которого параметр VERSION опционален) в котором не указан номер версии, сервер должен вернуть ответ, содержащий номер самой последней версии, которую он поддерживает. В ответ на запрос GetCapabilities, содержащий номер версии, сервер возвращает номер этой версии в случае если он ее поддерживает. Если же сервер не поддерживает указанную в запросе версию, то он передает клиенту информацию о поддерживаемой версии согласно следующим правилам:

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

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

ПРИМЕР 1 Сервер поддерживает версии 1, 2, 4, 5 и 8. Клиент поддерживает версии 1, 3, 4, 6 и 7. Клиент запрашивает версию 7. Сервер отвечает версией 5. Клиент запрашивает версию 4. Сервер отвечает версией 4, которую понимает клиент. На этом процесс согласования версий успешно завершается.

ПРИМЕР 2 Сервер поддерживает версии 4, 5 и 8. Клиент поддерживает версию 3. Клиент запрашивает версию 3. Сервер отвечает версией 4. Клиент не поддерживает ни данную версию, ни какую-либо другую боле высокую. На этом процесс согласования версий завершается и клиент разрывает связь с сервером.

Параметр VERSION является обязательным во всех запросах за исключением GetCapabilities.

6.3 Общие правила HTTP-запросов

6.3.1 Введение

Данный Международный Стандарт определяет реализацию WMS на распределённой вычислительной платформе (distributed computing platform, DCP), включающей в себя Интернет-хосты, поддерживающие протокол HTTP (Hypertext Transfer Protocol) (см. IETF RFC 2616). Таким образом онлайн ресурс, соответствующий каждой операции, поддерживаемой сервером, определяется посредством HTTP URL (Uniform Resource Locator). URL может отличаться для каждой операции, или быть одинаковым, по усмотрению поставщика услуг. Каждый URL должен соответствовать как минимум требованиям IETF RFC 2616 (раздел 3.2.2 "HTTP URL"), а в остальном определяться той или иной реализацией; в данном Международном Стандарте рассматривается только та часть URL, которая отвечает за запросы к ресурсам сервиса.

HTTP поддерживает два типа запросов: GET и POST. Оба этих метода могут быть использованы для доступа к сервису, при этом URL запрашиваемого ресурса в каждом случае будет различным. Поддержка сервером GET-запросов - обязательна, POST-запросов - опциональна.

6.3.2 Зарезервированные символы в HTTP GET URL

В рамках спецификации URL (IETF RFC 2396) определяется список зарезервированных символов, требующих экранирования во избежания конфликтов. Некоторые символы из данного списка явным образом зарезервированы в рамках рассматриваемого Международного Стандарта для использования в WMS-запросах. В случае если символы "?", "&", "=", "," или "+" выполняют одну из ролей, указанных в Таблице 1, то они отражаются в URL в неизменном виде. В случае же если эти символы появляются где-либо еще (например, среди значений параметров), то они должны быть закодированы согласно IETF RFC 2396.

Сервер должен быть готов декодировать любой символ, закодированный таким способом, а также преобразовывать символ "+" в пробел.

Символ Роль
? Разделитель, сигнализирующий о начале строки запроса.
& Разделитель между параметрами в строке запроса.
= Разделитель между именем и значением параметра запроса.
, Разделитель между значениями в списочных параметрах (таких как BBOX, LAYERS STYLES в запросах GetMap).
+ Сокращенное представление пробела.