WMS OGC官方协议1.3终稿：Web Map Service详解

需积分: 31 54 浏览量更新于2024-08-02 收藏 868KB PDF 举报

WMS (Web Map Service) 是 Open Geospatial Consortium (OGC) 官方制定的一种标准，用于通过网络向用户提供地图数据的服务。OGC04-024 文档是 WMS 规范的第 1.3 版，发布于 2004 年 8 月 2 日，由 Jeff de La Beaujardière 编辑。该文档属于 OpenGIS 实施系列，是 OGC 的一项公开可用标准，版权归 OGC 所有。 WMS 标准的核心目标是定义一个接口，使得 Web 应用程序能够请求、检索和显示地理空间数据，如地图图像和地图服务信息。通过遵循 WMS 规范，地图提供者可以创建一个统一的接口，使用户能够无缝访问不同来源的地图服务，无需了解底层技术细节。WMS 使用 HTTP 协议进行通信，允许客户端应用程序发送请求以获取特定地图层、区域、分辨率和时间范围的数据。在 WMS 的架构中，关键概念包括 GetCapabilities 和 GetMap 两种操作。GetCapabilities 是用来获取地图服务的元数据，如可用地图层列表、坐标系统、数据格式等。而 GetMap 则是用户实际请求地图图像的操作，它需要提供地图的坐标范围、分辨率、投影方式以及所需的图像格式。此文档作为“Final”版本，意味着它已经完成了草案阶段，可供公众审查和批准，但正式成为国际标准之前仍可能有所变动。同时，由于它是草案标准，它可能会被考虑作为国家法规中的引用标准，尽管在工业、技术、商业和用户用途中是可接受的，但在法律法规的应用上还需谨慎。 ISO/DIS19128 可能是与 WMS 相关的另一个国际标准或指南，由 International Organization for Standardization (ISO) 制定，强调了地理信息系统的互操作性和标准化。这个文档的出现表明 WMS 在全球范围内正逐渐成为地图服务的标准框架，对于开发和集成地理信息系统至关重要。阅读和理解 WMS OGC04-024 文档对于开发基于 Web 的地图应用、GIS 开发者以及需要整合地理信息的任何领域都极为重要，它提供了实现高效、一致和可扩展的地图服务的蓝图。

ISO/DIS 19128

1) If a version unknown to the server and higher than the lowest supported version is requested, the

server shall send the highest version it supports that is less than the requested version.

2) If a version lower than any of those known to the server is requested, then the server shall send the

lowest version it supports.

If the client does not support the version sent by the server, it may either cease communicating with

the server or send a new request with a different version number that the client does support.

The process may be repeated until a mutually understood version is reached, or until the client determines

that it will not or cannot communicate with that particular server.

EXAMPLE 1 Server understands versions 1, 2, 4, 5 and 8. Client understands versions 1, 3, 4, 6, and 7. Client

requests version 7. Server responds with version 5. Client requests version 4. Server responds with version 4, which the

client understands, and the negotiation ends successfully.

EXAMPLE 2 Server understands versions 4, 5 and 8. Client understands version 3. Client requests version 3. Server

responds with version 4. Client does not understand that version or any higher version, so negotiation fails and client

ceases communication with that server.

The VERSION parameter is mandatory in requests other than GetCapabilities.

6.3 General HTTP request rules

6.3.1 Introduction

This International Standard defines the implementation of the Web Map Service on a distributed computing

platform (DCP) comprising Internet hosts that support the Hypertext Transfer Protocol (HTTP) (see IETF RFC

2616). Thus the Online Resource of each operation supported by a server is an HTTP Uniform Resource

Locator (URL). The URL may be different for each operation, or the same, at the discretion of the service

provider. Each URL shall conform to the description in IETF RFC 2616 (section 3.2.2 "HTTP URL") but is

otherwise implementation-dependent; only the query portion comprising the service request itself is defined by

this International Standard.

HTTP supports two request methods: GET and POST. One or both of these methods may be offered by a

server, and the use of the Online Resource URL differs in each case. Support for the GET method is

mandatory; support for the POST method is optional.

6.3.2 Reserved characters in HTTP GET URLs

The URL specification (IETF RFC 2396) reserves particular characters as significant and requires that these

be escaped when they might conflict with their defined usage. This International Standard explicitly reserves

several of those characters for use in the query portion of WMS requests. When the characters '&', '=', ',' and

'+' appear in one of the roles defined in Table 1, they shall appear literally in the URL. When those characters

appear elsewhere (for example, in the value of a parameter), they shall be encoded as defined in IETF RFC

2396.

The server shall be prepared to decode any character escaped in this manner, and to decode the '+' character

as a space.

ISO/DIS 19128

Table 1 — Reserved Characters in WMS Query String

Character Reserved Usage

? Separator indicating start of query string.

& Separator between parameters in query string.

= Separator between name and value of parameter.

, Separator between individual values in list-oriented parameters (such as BBOX, LAYERS

and STYLES in the GetMap request).

+ Shorthand representation for a space character.

6.3.3 HTTP GET

A Web Map Service shall support the "GET" method of the HTTP protocol (IETF RFC 2616).

An Online Resource URL intended for HTTP GET requests is in fact only a URL prefix to which additional

parameters are appended in order to construct a valid Operation request. A URL prefix is defined in

accordance with IETF RFC 2396 as a string including, in order, the scheme ("http" or "https"), Internet

Protocol hostname or numeric address, optional port number, path, mandatory question mark '?', and optional

string comprising one or more server-specific parameters ending in an ampersand '&'. The prefix defines the

network address to which request messages are to be sent for a particular operation on a particular server.

Each operation may have a different prefix. Each prefix is entirely at the discretion of the service provider.

This International Standard defines how to construct a query part that is appended to the URL prefix in order

to form a complete request message. Every WMS operation has several mandatory or optional request

parameters. Each parameter has a defined name. Each parameter may have one or more legal values,

which are either defined by this International Standard or are selected by the client based on service metadata.

To formulate the query part of the URL, a client shall append the mandatory request parameters, and any

desired optional parameters, as name/value pairs in the form "name=value&" (parameter name, equals sign,

parameter value, ampersand). The '&' is a separator between name/value pairs, and is therefore optional

after the last pair in the request string.

When the HTTP GET method is used, the client-constructed query part is appended to the URL prefix defined

by the server, and the resulting complete URL is invoked as defined by HTTP (IETF RFC 2616).

Table 2 summarizes the components of an operation request URL when HTTP GET is used.

Table 2 — Structure of WMS request using HTTP GET

URL Component Description

http://host[:port]/path[?{name[=value]&}] URL prefix of service operation. [ ] denotes 0 or 1 occurrence of an

optional part; {} denotes 0 or more occurrences.

name=value& One or more standard request parameter name/value pairs as defined

for each operation by this International Standard.

6.3.4 HTTP POST

A Web Map Service may support the "POST" method of the HTTP protocol (IETF RFC 2616).

An Online Resource URL intended for HTTP POST requests is a complete URL (not merely a prefix as in the

HTTP GET case) that is valid according to IETF RFC 2396 to which clients transmit request parameters in the

body of the POST message. A WMS shall not require additional parameters to be appended to the URL in

order to construct a valid target for the operation request. When POST is used, the request message is

formulated as an XML document.

ISO/DIS 19128

6.4 General HTTP response rules

Upon receiving a valid request, the service shall send a response corresponding exactly to the request as

detailed in Clause 7 of this International Standard, or send a service exception if unable to respond correctly.

Only in the case of Version Negotiation (6.2.3) may the server offer a differing result. Upon receiving an

invalid request, the service shall issue a service exception as described in 6.11.

A server may send an HTTP Redirect message (using HTTP response codes as defined in IETF RFC 2616)

to an absolute URL that is different from the valid request URL that was sent by the client. HTTP Redirect

causes the client to issue a new HTTP request for the new URL. Several redirects could in theory occur.

Practically speaking, the redirect sequence ends when the server responds with a WMS response. The final

response shall be a WMS response that corresponds exactly to the original request (or a service exception).

Response objects shall be accompanied by the appropriate Multipurpose Internet Mail Extensions (MIME)

type (

IETF RFC 2045) for that object. A list of MIME types in common use on the internet is maintained by the

Internet Assigned Numbers Authority (IANA) [2]. Allowable types for operation responses and service

exceptions are discussed below. The basic structure of a MIME type is a string of the form "type/subtype".

MIME allows additional parameters in a string of the form "type/subtype; param1=value1; param2=value2". A

server may include parameterized MIME types in its list of supported output formats. In addition to any

parameterized variants, the server should offer the basic unparameterized version of the format.

Response objects should be accompanied by other HTTP entity headers as appropriate and to the extent

possible. In particular, the Expires and Last-Modified headers provide important information for caching;

Content-Length may be used by clients to know when data transmission is complete and to efficiently allocate

space for results, and Content-Encoding or Content-Transfer-Encoding may be necessary for proper

interpretation of the results.

6.5 Numeric and Boolean values

Integer numbers shall be represented in a manner consistent with the specification for integers in XML

Schema Datatypes ([8], section 3.3.13). This International Standard shall explicitly indicate where an integer

value is mandatory.

Real numbers shall be represented in a manner consistent with the specification for double-precision numbers

in XML Schema Datatypes ([8], section 3.2.5). This representation allows for integer, decimal and exponential

notations. A real value is allowed in all numeric fields defined by this International Standard unless the value

is explicitly restricted to integer.

Positive, negative and zero values are allowed unless explicitly restricted.

Boolean values shall be represented in a manner consistent with the specification for boolean in XML Schema

Datatypes ([8], section 3.2.2). The values '0' and 'false' are equivalent. The values '1' and 'true' are

equivalent. Absence of an optional value is equivalent to logical false. This International Standard shall

explicitly indicate where a Boolean value is mandatory.

6.6 Output formats

The response to a Web Map Service request is always a computer file that is transferred over the internet

from the server to the client. The file may contain text, or the file may represent a map image. As stated in

6.4, the type of the returned file shall be indicated by a MIME type string.

Text output formats are usually formatted as Extensible Markup Language (XML; MIME type text/xml). Text

formats are used to convey service metadata, descriptions of error conditions, or responses to queries for

information about features shown on a map.

Allowed map formats are either "picture" formats or "graphic element" formats. Picture formats constitute a

rectangular pixel array of fixed size. Picture formats include file types such as Graphics Interchange Format

ISO/DIS 19128

(GIF; MIME type "image/gif"), Portable Network Graphics (PNG; MIME type "image/png"), Joint Photographics

Expert Group (JPEG; MIME type "image/jpeg"), all of which can be displayed by common Web browsers, and

file types such as Tagged Image File Format (TIFF: MIME type "image/tiff") that may require additional

software (beyond a basic Web browser) for display. Graphic element formats constitute a scale-independent

description of the graphic elements to be displayed (including points, lines, curves, text and images), such that

the size of the display may be modified while preserving the relative arrangement of the graphic elements.

Graphic element formats include Scalable Vector Graphics (SVG; MIME type "image/svg+xml") or Web

Computer Graphics Metafile (WebCGM; MIME type "image/cgm;Version=4;ProfileId=WebCGM") formats.

NOTE 1 SVG is expressed using XML, and could therefore be considered to be a text output format, but for the

purposes of this International Standard SVG is considered to be a map format.

NOTE 2 WebCGM is a profile of ISO/IEC 8632.

A server may offer multiple map formats. The formats it offers are enumerated in <Format> elements in its

service metadata. Use of a specific format is not required by this International Standard. However, for maps

that portray vector features the server should offer at least one format that supports transparency in order that

maps may be overlaid without obscuring other maps below (see the discussion about transparency in 7.3.3.9).

Also, for ease of use the server should offer at least one format that can be displayed by common Web

browsers without additional software. Based on these considerations, the server should offer at least the PNG

format.

6.7 Coordinate systems

6.7.1 Introduction

This International Standard uses two principal classes of Coordinate Systems: a Map CS applicable to the

map portrayal generated by the Web Map Service, and a Layer CRS for a Bounding Box applied to the source

data. During a portrayal operation, a WMS converts or transforms geographic information from a Layer CRS

into a Map CS. In addition, a Layer may have an associated vertical, temporal or other coordinate system.

6.7.2 Map CS

A Map CS is a coordinate reference system for a map produced by a Web Map Service. A WMS map is a

rectangular grid of pixels displayed on a computer screen (or a digital file that could be so displayed). The

Map CS has a horizontal axis denoted i, and a vertical axis denoted j. i and j shall have only nonnegative

integer values. The origin (i,j) = (0,0) is the pixel in the upper left corner of the map; i increases to the right and

j increases downward. The Map CS is defined using ISO 19111 terminology in B.2. The Map CS is identified

by the label "CRS:1".

The usual orientation of the Map CS shall be such that the i axis is parallel to the East-to-West axis of the

Layer CRS and increases Eastward, and the j axis is parallel to the North-to-South axis of the Layer CRS and

increases Southward. This orientation will not be possible in some cases, as (for example) in an orthographic

projection over the South pole. The convention to be followed is that, wherever possible, East shall be to the

right edge and North shall be toward the upper edge of the Map CS.

The WIDTH and HEIGHT parameters used in the GetMap request (7.3.3.8) and by inclusion in the

GetFeatureInfo request (7.4.3.3) correspond to i and j as follows:

• WIDTH denotes the size of the map image in pixels along the i axis (that is, WIDTH-1 is the maximum

value of i).

• HEIGHT denotes the size of the map image in pixels along the j axis (that is, HEIGHT-1 is the

maximum value of j).

The I and J parameters used in the GetFeatureInfo request (7.4.3.7) denote integer values along the i and j

axes, respectively, of the Map CS.

剩余84页未读，继续阅读

www_1666

粉丝: 0
资源: 9

WMS OGC官方协议1.3终稿：Web Map Service详解

OGC PUCK协议标准版本v1.4中文版

ＯＧＣ ＷＭＳ（Web Map Service）网络地图服务 （吐血整理）

ogc标准说明文档

ogc.rar_OGC 的 WFS 服务_WFS_ogc 规范_wcs_wms ogc

WMS_WFS_OGC标准系列文档

wms_explorer:OGC WMS资源管理器

OGC标准部分规范文档

ogc-i3s-community-standard:公共回购协议，用于开发OGC i3s社区标准的未来版本

WMS教程

OGC SLD标准

最新资源

ＯＧＣ　ＷＭＳ（Web Map Service）网络地图服务（吐血整理）