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.

Системы координат

Введение

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

Система координат карты

Данный тип систем координат применяется к карте, созданной WMS. Карта WMS представляет собой прямоугольную сетку пикселов, отображаемых на экране компьютера (или цифровой файл, который также может быть отображён). Система координат карты имеет горизонтальную ось, обозначаемую i и вертикальную ось, обозначаемую j. i и j должны принимать только неотрицательные целые значения. Началом системы координат (i,j) = (0,0) является пиксел, расположенный в левом верхнем углу карты; i возрастает слева направо, j - сверху вниз. Система координат карты определяется с использованием терминологии ISO 19111 в B.2 и обозначается меткой "CRS:1".

Обычная ориентация системы координат карты предполагает, что ось i должна быть параллельна направлению Восток-Запад в системе координат слоя и возрастать в восточном направлении, а ось j - параллельна направлению Север-Юг и возрастать в южном направлении. Такая ориентация в ряде случаев невозможна, например, при использовании ортогональной проекции на территории Южного полюса. Однако соглашение, которого всегда следует придерживаться, гласит, что в тех случаях, когда это возможно, Восток должен располагаться вдоль правого края, а Север вдоль верхнего края в системе координат карты.

Параметры WIDTH и HEIGHT, используемые в запросе GetMap (см. 7.3.3.8) и также включаемые в запрос GetFeatureInfo (7.4.3.3) соответствуют i и j согласно следующим правилам:

• WIDTH обозначает размер изображения карты в пикселах вдоль оси i (поэтому, WIDTH-1 - максимальное значение координаты i).
• HEIGHT обозначает размер изображения карты в пикселах вдоль оси j (поэтому, HEIGHT-1 - максимальное значение координаты j).

Параметры I и J, используемые в запросе GetFeatureInfo (см. 7.4.3.7) обозначают целые значения вдоль осей i и j системы координат карты.

Система координат слоя

Введение

Система координат слоя - это горизонтальная система координат исходных данных карты. Как будет показано дальше, системы координат слоя могут быть различными. Система координат слоя указывается в следующих местах:

• В элементе <BoundingBox> метаданных сервиса (7.2.4.6.8);
• В CRS параметре запроса GetMap (7.3.3.5);
• В CRS параметре запроса GetFeatureInfo (7.4.3.3).

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

Поставщики карт могут поддерживать системы координат, являющиеся наиболее удобными и соответствующие их географическому положению. Для максимизация совместимости данных между различными серверами поставщики также должны поддерживать географические системы координат, такие как "CRS:84" (см. 6.7.3.2), "EPSG:4326" (см. 6.7.3.3) или другие ITRF-системы.

Каждая система координат слоя имеет свой идентификатор, представляющий собой символьную строку. Допустимы два типа идентификаторов систем координат слоя - "метка" и "URL":

• Метка: идентификатор включает в себя префикс пространства имен, двоеточие и числовой или строковый код, а в некоторых случаях и дополнительные параметры, указанные через запятую. Данный Международный Стандарт определяет три пространства имен: CRS, EPSG и AUTO2.

• URL: идентификатор представляет собой полноценный URL, который ссылается на общедоступный файл, содержащий описание системы координат в формате, совместимом с ISO 19111.

Система координат слоя имеет две оси, которые обозначаются как x и y. Ось x является первой осью в определении системы координат, y - второй. В зависимости от системы координат ось x может быть ориентированной в направлении Запад-Восток, а ось y в направлении Юг-Север. В процессе формирования карты при перепроецировании исходных данных из системы координат слоя в систему координат карты должны учитываться начало системы координат слоя, порядок и направление координатных осей.

Координаты должны быть перечислены в порядке, определяемом описанием системы координат слоя, и отображены на соответствующие оси i и j системы координат карты путём изменения порядка осей по мере необходимости в ходе выполнения операции перепроецирования. Многие прямоугольные системы координат имеют координаты и порядок осей, направление которых отличается от направления на восток и на север, например, в системе координат Uniform Coordinate System, используемой в Финляндии (EPSG:2393), первая ось ориентирована на север, вторая на восток. Определения систем координат в EPSG соответствуют стандарту ISO 6709, в котором широта всегда указывается перед долготой.

В большинстве систем координат положительное направление одной оси ориентировано на восток, а другой на север. Эти карты удобно отображать на ограничивающий прямоугольник в осях i и j соответственно. Однако, в некоторых системах координат координаты увеличиваются в других направлениях. Например, система координат Hartebeesthoek94/Lo25, используемая в Южной Африке (EPSG:2051) имеет оси с направлениями роста координат на запад и на юг. Tests for valid bounding box areas shall recognise and account for the positive orientation of the CRS axes.

В географических системах координат значения широты должны находиться в диапазоне [-90, 90], а долготы в диапазоне [-180, 180] градусов или их эквиваленте в случае, если определение системы координат предполагает использование других единиц измерения. См. раздел 7.3.5, в котором рассматривается ситуация перепроецирования слоя, находящегося в географической системе координат в проекцию карты. Если код системы координат слоя определяет 2-х мерную систему географических координат с единицами измерения, отличными от градусов или в градусах, но не десятичных, то такие координаты должны быть приведены к десятичным градусам.

ЗАМЕЧАНИЕ Использование географических систем координат в которых вначале идёт долгота, а затем широта отличается от исторически сложившейся практики. Пользователи, связанные с международной авиацией или морским сектором ожидают обратного порядка координат и отображение карты с перевернутыми осями может иметь трагические последствия, особенно при возникновении какой-либо чрезвычайной ситуации. Хотя настоящий Международный Стандарт не определяет пользовательский интерфейс, но рекомендует разработчикам, связанным с его созданием, обратить внимание на то, что все ссылки на широту и долготу, например, в поле ввода ограничивающего прямоугольника или поле отображения координат курсора, должны отображать широту перед долготой.

Пространство имен CRS

Пространство имен с префиксом "CRS" относится к системам координат, представленным в Приложении B данного Международного Стандарта. Описания данных систем выполнены согласно стандарту ISO 19111. Географические системы координат в пространстве имен "CRS" в Приложении B определены для датумов WGS 84, NAD27 и NAD83.

Метка системы координат в пространстве имен CRS состоит из префикса "CRS", двоеточия и числового или символьного кода.

ПРИМЕР "CRS:84" - система координат на эллипсоиде WGS 84, единицы измерения данных - десятичные градусы долготы и широты, диапазон изменения долготы - от -180 градусов до +180 градусов, широты - от -90 градусов до +90 градусов.

Пространство имен EPSG

Пространство имен с префиксом "EPSG" относится к набору данных организации European Petroleum Survey Group (EPSG), в рамках которого определены числовые идентификаторы (EPSG-коды, поле "COORD_REF_SYS_CODE" в наборе данных EPSG) для большинства наиболее распространенных систем координат. Для каждого идентификатора определены геодезическая, картографическая проекции и используемая система координат.

Метка системы координат в пространстве имен EPSG состоит из префикса "EPSG", двоеточия и числового кода.

ПРИМЕР EPSG:4326 - система координат на эллипсоиде WGS 84, единицы измерения - градусы широты и долготы. То есть в данной системе координат ось x соответствует широте, y - долготе.

ЗАМЕЧАНИЕ Географические системы координат в пространстве имен EPSG, использующие "вендор-специфичное представление градусов", в рамках данного Международного Стандарта считаются как использующие десятичные градусы.

Пространство имен AUTO2

Пространство имен AUTO2 используется для "автоматических" систем координат; то есть для таких систем, описание которых включают выбранный пользователем центр проекции. Некоторые системы координат данного пространства имен представлены в Приложении B.

Метка системы координат в пространстве имен "AUTO2" состоит из префикса "AUTO2", числового идентификатора системы координат, коэффициента преобразования единиц измерения ограничивающего прямоугольника в единицы измерения системы координат AUTO2, значения центральной долготы и широты в градусах:

AUTO2:auto_crs_id,factor,lon0,lat0

Коэффициент преобразования должен быть положительным ненулевым числом. Если он равен единице, то единицы измерения BBOX будут совпадать с единицами измерения, используемыми в определении системы координат. Если коэффициент не равен 1, то в этом случае он равен отношению единиц измерения BBOX к единицам измерения системы координат. При запросе GetMap определение системы координат AUTO2 включает в себя долготу, широту и коэффициент преобразования. В метаданных сервиса долгота, широта и коэффициент преобразования опущены, поскольку они выбираются клиентом самостоятельно.

ПРИМЕР 1 Сервер сообщает о том, что он поддерживает автоматическую ортогональную проекцию, путем включения элемента "<CRS>AUTO2:42003</CRS>" в метаданные сервиса. Клиент может выполнить запрос GetMap для карты, указав эту систему координат, а также размер ограничивающего прямоугольника в метрах, отцентрированного по 100 градусам западной долготы и 45 градусам северной широты, используя следующее определение системы координат: "CRS=AUTO2:42003,1,-100,45".

ПРИМЕР 2 Аналогичный предыдущему примеру запрос, но с коэффициентом преобразования единиц измерения ограничивающего прямоугольника в футы США: "CRS=AUTO2:42003,0.3048006096012192,-100,45".

Географическая информация в неопределенной системе координат

На сервере можно опубликовать двумерные географические данные для которых отсутствует точная привязка. К таким данным относятся, например, нарисованная от руки историческая карта, содержащая изображение всей площади Земли, но не использующая при этом современные системы координат, или плохо привязанный аэрофотоснимок. Такие типы географической информации должны рассматриваться как изображения и для обозначения системы координат такого слоя должна использоваться метка системы координат карты "CRS:1". В этом случае клиенты не должны пытаться совмещать слои с системой координат CRS=CRS:1 с другими слоями.

Ограничивающие прямоугольники

Ограничивающий прямоугольник задается двумя парами координат в единицах измерения слоя и определяет тот участок Земли, который должен быть отрисован на карте. Первая пара определяет минимальные значения координат, вторая - максимальные. И хотя для большинства систем координат, у которых положительные направления осей совпадают с направлениями на восток и на север, эти координаты соответствуют левому нижнему и правому верхнему углу карты, но возможны варианты, когда они будут располагаться в других местах. Например, при использовании географических координат для описания полюсных территорий, или при использовании систем координат, в которых оси ориентированы в обратную сторону. Порядок координат в каждой паре должен соответствовать порядку координат в используемой системе координат слоя; x соответствует первой оси в определении системы координат, y - второй. Этот порядок может не совпадать с порядком осей i и j системы координат карты. Координаты ограничивающего прямоугольника должны быть выражены в тех же единицах измерения, что используются в системе координат запрашиваемого слоя.

ЗАМЕЧАНИЕ Теоретически, использование двух угловых точек для определения области карты - не единственный способ. В качестве альтернативы можно, например, задать центральную точку и радиус охвата или центральную точку и масштабный уровень. Для некоторых картографических сервисов (например, сервисов, основанных на местоположении) подход с использованием центральной точки может оказаться более подходящим. Данный Международный Стандарт не запрещает использовать другие алгоритмы вычисления запрашиваемой области на стороне клиента. Однако для большинства систем координат операция преобразования запрашиваемой области, заданной с помощью центральной точки, в область, определяемую координатами углов, с математической точки зрения - тривиальна. Так, например, пользователь может ввести координаты центральной точки и интересующий его радиус охвата, после чего эта информация легко конвертируется клиентским приложением в ограничивающий прямоугольник, заданный двумя точками, и уже в таком виде ограничивающий прямоугольник передаётся WMS-серверу как реализовано в рамках настоящего Международного Стандарта.

Значения ограничивающего прямоугольника отображаются в следующих местах:

• В элементе <BoundingBox> метаданных сервиса (7.2.4.6.8);
• В параметре BBOX запроса GetMap (7.3.3.6);
• В параметре BBOX подзапроса карты запроса GetFeatureInfo (7.4.3.3).

Ограничивающий прямоугольник не должен иметь нулевую площадь.

ПРИМЕР 1 Элемент метаданных <BoundingBox> для слоя, содержащего данные на всю территорию Земли в системе координат CRS:84, должен записываться так: <BoundingBox CRS="CRS:84" minx="-180" miny="-90" maxx="180" maxy="90">. Параметр BBOX запроса всей территории Земли в данной системе координат записывается так: BBOX=-180,-90,180,90.

ПРИМЕР 2 Элемент метаданных <BoundingBox> для слоя, содержащего данные на всю территорию Земли в системе координат EPSG:4326, должен записываться так: <BoundingBox CRS="EPSG:4326" minx="-90" miny="-180" maxx="90" maxy="180">. Параметр BBOX запроса всей территории Земли в данной системе координат записывается так: BBOX=-90,-180,90,180.

Вертикальная система координат

Иногда географическая информация может быть доступна в разрезе различных высот (например, уровень концентрации озона в атмосфере на разных высотах). WMS может сообщать клиенту о доступных уровнях в метаданных сервиса и при выполнении запроса GetMap клиент будет указывать опциональный параметр значения интересующей его высоты. Высота или глубина - это величина, единицы измерения и направление увеличения которой определяются одномерной вертикальной системой координат. В зависимости от контекста высота может задаваться одним числом, списком или интервалом, как показано в Приложении С.

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

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

Допустимо использование двух типов идентификаторов вертикальных систем координат - "метка" и "URL":

• Метка: идентификатор включает в себя префикс пространства имен, двоеточие и числовой или строковый код. В B.6 определена вертикальная система координат "CRS:88", основанная не североамериканском вертикальном датуме (North American Vertical Datum) 1988 года. Если в качестве пространства имен выступает "EPSG", то определение системы координат в этом случае берется из набора данных European Petroleum Survey Group.

• URL: идентификатор представляет собой полноценный URL, который ссылается на общедоступный файл, содержащий описание системы координат в формате, совместимом с ISO 19111.

Если высота является вертикальной компонентой трехмерной системы координат, то идентификатор вертикальной системы координат должен также обозначать трехмерную систему координат.

Временная система координат

Некоторая географическая информация может быть доступна на определенные моменты времени (например, ежечасная карта погоды). WMS может сообщать клиенту о доступных временных отсчетах в метаданных сервиса и при выполнении запроса GetMap клиент будет указывать интересующую его временную метку. Формат строки времени определен в Приложении D. В зависимости от контекста, временная метка может задаваться одним числом, списком или интервалом, как показано в Приложении С. При предоставлении информации о доступных временных отсчетах, сервер должен указать в метаданных сервиса значение, используемое по умолчанию и именно данные, соответствующие этой временной метке, должны быть переданы клиенту в том случае, если он явным образом не указал интересующее его время.

Прочие системы координат

Для некоторой географической информации могут быть доступны дополнительные измерения (например, спутниковые снимки в различных диапазонах длин волн). Измерения, отличные от четырех стандартных измерений пространства-времени называются "выборочными измерениями". WMS может сообщать клиенту о доступных выборочных измерениях в метаданных сервиса, а запрос GetMap в свою очередь включает механизм запроса значений этих измерений. Каждое выборочное измерение имеет имя и одно или несколько допустимых значений. Определение и использование выборочных измерений представлено в C.3.3.

Правила использования параметров запроса

Порядок и регистр параметров

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

Порядок следования параметров в строке запроса произвольный.

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

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

Списки параметров

Параметры, значения которых представлены в виде списков (например, BBOX, LAYERS и STYLES в запросе GetMap) должны использовать запятую (",") в качестве разделителя между элементами списка. Дополнительный символ пробела не должен использоваться для их разделения. Если список значений содержит пробел или запятую, то они должны быть экранированы согласно правилам кодирования URL (см. 6.3.2 и IETF RFC 2396).

Иногда элементы списка могут содержать пустые значения, которые должны быть представлены в виде пустой строки (""). То есть две подряд идущих запятые указывают на пустое значение между ними, аналогичную роль выполняют запятая вначале или в конце строки. Пустой список ("") должен быть интерпретирован либо как список, не содержащий ни одного элемента, либо как список, содержащий один пустой элемент, в зависимости от контекста.

Общие параметры запроса

VERSION

Параметр VERSION определяет номер версии протокола. Формат номера версии и порядок согласования версий описаны в 6.2.

REQUEST

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

FORMAT

Параметр FORMAT определяет выходной формат ответа сервера.

WMS может возвращать ответ в различных форматах в зависимости от типа запроса. Сервер обязан сообщать о поддерживаемых форматах посредством метаданных и в обязательном порядке корректно обрабатывать запросы для заявленных форматов. Сервер может опционально предлагать новый формат, прежде не используемый в подобных сервисах, но при этом следует учитывать, что клиент не обязан принимать или обрабатывать данные в неизвестном формате. Если запрос содержит формат, не поддерживаемый сервером, то он должен вернуть ответ в формате, используемом по умолчанию для данного типа запроса, если такой был установлен. В противном случае - вернуть исключение (с кодом "InvalidFormat").

Клиент может поддерживать не все форматы, предлагаемые сервером для конкретного типа запроса. Если клиент не поддерживает ни одного из предложенных форматов, то он может на свое усмотрение либо разорвать связь с сервером, либо попытаться найти промежуточный сервис, который бы осуществил преобразование форматов, либо предложить пользователю выбрать другой метод обработки (например, сохранить данные в локальное хранилище или передать во вспомогательное приложение).

При выполнении запросов и внутри метаданных описание форматов выражается посредством MIME-типов. Каждому типу запросов соответствует определенный список поддерживаемых форматов. При этом некоторые форматы могут одновременно присутствовать в списках форматов различных типов запросов, что свидетельствует о том, что каждый из этих запросов поддерживает указанный формат.

Исключения

Параметр EXCEPTIONS определяет формат в котором будет возвращаться информация об ошибках (см. 6.11).

Расширенные возможности и операции

Функционал Web Map Service может быть расширен путем добавления поддержки новых операций и модификации возможностей имеющихся. Такие расширения могут найти применение в рамках определенных сообществ в случае если это потребуется. Стандартный клиент не обязан поддерживать такие расширения. Описание расширенных возможностей выполняется путем добавления экземпляров абстрактных элементов <_ExtendedCapabilities> или <_ExtendedOperations> в метаданные сервиса согласно схеме, приведенной в Приложении E. Расширение возможностей стандартных операций заключается в предоставлении дополнительных метаданных о сервисе, а также может включать или не включать описание новых опциональных параметров, используемых при выполнении тех или иных запросов. Расширение списка операций позволяет обеспечить поддержку новых типов запросов.

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

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

Результат работы сервиса

При поступлении корректного запроса сервис должен возвращать ответ в формате, указанном в параметре FORMAT. В HTTP окружении MIME-тип, указанный в заголовке Content-Type, должен соответствовать формату запрашиваемых данных.

Исключения сервиса

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

Ошибки, возникающие в программных модулях, которые не имеют отношения к WMS, могут приводить к сообщениям об исключениях, не рассматриваемых в рамках данного Международного Стандарта. Например, при возникновении ошибки в окружении локальной вычислительной среды в которой развернут WMS (например, в случае нехватки памяти или дискового пространства), сервер может оказаться не в состоянии обработать WMS-запрос и может вернуть сообщение об ошибке. Или, например, при получении запроса, который считается некорректным согласно правилам используемой распределенной вычислительной платформы (DCP) сервер может сгенерировать исключение сервиса типа соответствующего используемой DCP (например, некорректный префикс URL или 404 код HTTP-ответа (IETF RFC 2616)).