Web Map Server Implementation Specification

Перевод OpenGIS Web Map Service (WMS) Implementation Specification v.1.3.0

Назначение документа

Данный Международный Стандарт определяет поведение сервиса, динамически создающего пространственно привязанные карты на основе географической информации. Помимо этого в рамках данного Стандарта определена операция, позволяющая получить описание карт, доступных на сервере, а также операция запроса атрибутивной информации для объектов, расположенных на карте. Этот Международный Стандарт рассматривает получение уже отрисованных карт в графическом формате и не применим к задаче получения исходных векторных или растровых данных.

Сокращения

CDATA	XML Character Data
CRS	Coordinate Reference System
CS	Coordinate System
DCP	Distributed Computing Platform
DTD	Document Type Definition
EPSG	European Petroleum Survey Group
GIF	Graphics Interchange Format
GIS	Geographic Information System
HTTP	Hypertext Transfer Protocol
IANA	Internet Assigned Numbers Authority
IERS	International Earth Rotation Service
IETF	Internet Engineering Task Force
ITRF	International Terrestrial Reference Frame
ITRS	IERS Terrestrial Reference System
JPEG	Joint Photographic Experts Group
MIME	Multipurpose Internet Mail Extensions
NAD	North American Datum
OGC	Open GIS Consortium
PNG	Portable Network Graphics
RFC	Request for Comments
SVG	Scalable Vector Graphics
UCUM	Unified Code for Units of Measure
URL	Uniform Resource Locator
WebCGM	Web Computer Graphics Metafile
WCS	Web Coverage Service
WFS	Web Feature Service
WGS	World Geodetic System
WMS	Web Map Service
XML	Extensible Markup Language

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

Введение

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

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

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

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

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

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

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

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

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

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.

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

Введение

Данный Международный Стандарт определяет реализацию 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-запросов - опциональна.

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

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

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

Таблица 1 - Зарезервированные символы в строке WMS-запроса

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

HTTP GET

WMS предполагает обязательную поддержку GET-запросов (IETF RFC 2616).

URL ресурса, к которому происходит обращение посредством GET-запроса, фактически представляет собой некоторую, специальным образом сконструированную строку (префикс), дополняемую служебными параметрами, отвечающими за запрос. Структура префикса определяется в соответствии с IETF RFC 2396 как строка, состоящая из названия схемы ("http" или "https"), имени или цифрового представления хоста, номера порта (опционально), пути, обязательного символа вопроса "?" и опциональной строки, содержащей один или более сервер-специфичных параметров, заканчивающихся символом амперсанда "&". Префикс определяет сетевой адрес, по которому будет отправлен запрос на конкретный сервер. Для различных операций может быть использован различный префикс. Выбор префикса определяется поставщиком услуг.

В рамках данного Международного Стандарта рассматривается способ построения второй части URL (query part), следующей за префиксом, необходимой для формирования полноценного запроса. Каждый тип WMS-запроса имеет собственный набор обязательных и опциональных параметров. Каждый параметр имеет собственное имя и может принимать одно или несколько допустимых значений, которые определяются либо в рамках данного Международного Стандарта, либо устанавливаются клиентом на основе метаданных сервиса. В процессе формирования второй части URL запроса клиентское приложение дополняет префикс обязательными и опциональными параметрами в формате "имя=значение&" (имя параметра, знак равенства, значение параметра, амперсанд). Символ "&" служит разделителем между парами имя/значение и поэтому является опциональным после последней пары в строке URL.

При использовании HTTP-метода GET, префикс URL, опрделяемый сервером, дополняется строкой запроса и результирующий URL используется как описано в спецификации HTTP (IETF RFC 2616).

В Таблице 2 представлена структура WMS-запроса при использовании HTTP-метода GET.

Таблица 2 - Структура WMS-запроса при использовании HTTP-метода GET

Компонент URL	Роль
http://host[:port]/path[?{name[=value]&}]	Префикс URL. [ ] обозначает 0 или 1 повторение опциональной части; {} обозначает 0 или более повторений.
name=value&	Один или несколько стандартных параметров, определенных для каждого типа WMS-запроса в рамках данного Международного Стандарта.

HTTP POST

WMS опционально может поддерживать "POST"-запросы (IETF RFC 2616).

URL ресурса при осуществлении POST-запроса - это полноценный URL (а не только префикс, как в случае с GET-запросом), что является допустимым в соответствии с IETF RFC 2396. В данном случае клиент передаёт параметры запроса в теле POST-сообщения. WMS не требует указания дополнительных параметров в URL для формирования валидного запроса. Тело POST-сообщения представляет собой XML-документ.

Общие правила формирования HTTP-ответов

При поступлении на сервер валидного запроса, сервер должен вернуть ответ, сформированный по правилам, описанным в Разделе 7 данного Международного Стандарта или вернуть исключение, сообщающее о невозможности сформировать корректный ответ. Только в случае процедуры согласования версий (см. 6.2.4) сервер может предлагать различный результат. При поступлении невалидного запроса сервер выдаёт исключение, как описано в 6.11.

Сервер может отправить HTTP-сообщение о перенаправлении (используя HTTP-коды как описано в IETF RFC 2616) запроса на другой URL, отличный от того, который был запрошен клиентом. Перенаправление предполагает, что клиент должен выполнить новый HTTP-запрос по новому URL. Теоретически, перенаправление может осуществляться несколько раз. Практически, последовательность перенаправлений заканчивается в момент, когда сервер возвращает WMS-ответ. Этот ответ должен соответствовать оригинальному запросу, посланному клиентом (или представлять собой исключение).

Ответ должен сопровождаться соответствующим HTTP-заголовком, содержащим MIME (Multipurpose Internet Mail Extensions) тип ответа (IETF RFC 2045). Список MIME-типов, используемых в Интернет, поддерживается организацией Internet Assigned Numbers Authority (IANA) [2]. Допустимые типы ответов и исключений рассмотрены ниже. Базовая структура MIME-типа представляет собой строку вида "тип/подтип". MIME допускает использование дополнительных параметров: "тип/подтип; параметр1=значение1; параметр2=значение2". Сервер может включать параметрезированные MIME-типы в собственный список поддерживаемых выходных форматов. В дополнение к любому параметризированному варианту сервер должен предлагать базовую непараметризированную версию.

Ответ должен сопровождаться другими HTTP-заголовками по мере необходимости и по мере возможности. В частности, заголовки Expires и Last-Modified содержат важную информацию для кэширования; Content-Length может использоваться клиентом для определения момента завершения передачи данных и эффективного распределения места под них; Content-Encoding и Content-Transfer-Encoding - для правильной интерпретации ответа.

Числовые и Логические значения

Целые числа должны быть представлены согласно спецификации целых типов данных, описанной в документе XML Schema Datatypes ([8], раздел 3.3.13). Данный Международный Стандарт обязан явным образом указывать где целое значение является обязательным.

Действительные числа должны быть представлены согласно спецификации чисел двойной точности, описанной в документе XML Schema Datatypes ([8], раздел 3.2.5). Это представление допустимо для целых, десятичных и экспоненциальных нотаций. Действительные значения допустимы во всех местах, определённых данным Международным Стандартом, за исключением тех, для которых явно указано использование целых чисел.

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

Логические значения должны быть представлены согласно спецификации логических значений, описанной в XML Schema Datatypes ([8], раздел 3.2.2). Значения "0" и "false" - эквивалентны. Значения "1" и "true" - эквивалентны. Данный Международный Стандарт явным образом указывает где логический тип является обязательным.

Выходные форматы

Любой ответ WMS-сервиса - это файл, который передается через Интернет от сервера к клиенту. Данный файл может содержать текст или фрагмент карты. Как указано в 6.4, тип возвращаемого файла должен быть задан при помощи указания MIME-типа.

Текстовые данные, обычно, представлены в формате Extensible Markup Language (XML; MIME-тип text/xml) и используются для передачи метаданных сервиса, атрибутивной информации об объектах карты или для описания ошибок.

Допустимыми форматами представления карты являются форматы "изображений" и "графических элементов". К первой группе относятся такие типы файлов как Graphics Interchange Format (GIF; MIME-тип "image/gif"), Portable Network Graphics (PNG; MIME-тип "image/png"), Joint Photographics Expert Group (JPEG; MIME-тип "image/jpeg"), каждый из которых может быть отображён с помощью любого современного Web-браузера, а также типы файлов, для отображения которых требуется дополнительное программное обеспечение (возможностей Web-браузера недостаточно), например, Tagged Image File Format (TIFF: MIME-тип "image/tiff"). Ко второй группе относятся форматы масштабно-независимого описания графических элементов (включая точки, линии, кривые, текст и изображения), позволяющие сохранять их взаимное расположение при изменении размера самого изображения. Сюда относятся форматы Scalable Vector Graphics (SVG; MIME-тип "image/svg+xml") и Web Computer Graphics Metafile (WebCGM; MIME-тип "image/cgm;Version=4;ProfileId=WebCGM").

ЗАМЕЧАНИЕ 1 SVG является подмножеством XML и поэтому может быть отнесен к текстовому выходному формату, но для целей данного Международного Стандарта SVG относится к формату карты.

ЗАМЕЧАНИЕ 2 WebCGM является профилем ISO/IEC 8632.

Сервер может поддерживать различные выходные форматы. Поддерживаемые сервером форматы представлены внутри элементов <Format> метаданных сервиса. Использование конкретного выходного формата не оговаривается настоящим Международным Стандартом, тем не менее, для карт, построенных на базе векторных данных, сервер должен поддерживать как минимум один формат с поддержкой прозрачности для того, чтобы можно было наложить несколько карт друг на друга без их полного перекрытия (см. обсуждение прозрачности в 7.3.3.9). Кроме того, для удобства использования, сервер должен предложить по крайней мере один формат, который может быть отображен при помощи обычного Web-браузера без необходимости привлечения дополнительного программного обеспечения. Исходя из этих соображения, сервер должен поддерживать по крайней мере формат PNG.