WMS网络地图服务规范.docx

WMS网络地图服务规范.docx

《WMS网络地图服务规范.docx》由会员分享，可在线阅读，更多相关《WMS网络地图服务规范.docx（134页珍藏版）》请在冰豆网上搜索。

WMS网络地图服务规范

WMS网络地图服务规范

ICS07040

A75

GB

中华人民共和国国家标准

GB/T×××××—200×

地理信息－地图：

网络服务接口

Geographicinformation–WebMapServerInterface

（ISO19128：

2005，MOD）

××××-××-××发布××××-××-××实施

目　　次

前言

本标准修改采用（MOD）国际标准化组织地理信息标准化委员会（ISO/TC211）制定的ISO19128：

2005（E）《Geographicinformation－Webmapserverinterface》，并作了如下改动：

①本标准的编写方法执行国家标准GB/T1.1－2000《标准化工作导则第一部分：

标准的结构和编写规则》、GB/T20000.2－2001《标准化工作指南第2部分：

采用国际标准的规则》的要求。

②考虑到我国实际应用的需要，本标准在采用原国际标准时进行了以下编辑修改：

a）“本国际标准”一词改为“本标准”；

b）删除了原国际标准的封面、目次和前言；

c）用句号“。

”代替作为句号的“.”；

d）用小数点“.”代替作为小数点的“，”。

e）本标准的引言采用了原标准的引言，但作了少量的修改；

f）凡已被我国等同采用的国际标准，在本标准用国家标准的代号和名称取代相应的国际标准的代号和名称。

原国际标准编号和名称

替代的国家标准编号与名称

GB/T7408:

2004，数据元素和交换格式－信息交换－时间和日期的表达

GB/T7408-1994数据元和交换格式信息交换日期和时间表示法

GB/T19710:

2003，地理信息－元数据

GB/T19710地理信息元数据

③删除了原国际标准的前言。

④规范性引用文件的引导语和一览表引用文件的排序执行GB/T1.1-2000，其中ISO19117改为ISO19117：

2007。

⑤为便于使用，结合我国实际情况，在本标准的附录C中增加了4个与相应的国际标准条款等同地位的条款，作为对该国际标准条款的另一种选择。

它们是：

a）表B.5使用Beijing1954经度-纬度定义LayerCRS，因此原标准中表B.5改为B.7。

b）表B.6使用Xian1980经度-纬度定义LayerCRS。

c）表B.8使用国家黄海高程基准1956定义垂直CRS。

d）表B.9使用国家高程基准1980定义垂直CRS。

为此，原标准6.7.3.2第1自然段中“在附录B中，“CRS”命名空间的地理CRS被规定为WGS84、NAD27和NAD83基准。

”改为“在附录B中，“CRS”命名空间的地理CRS被规定为WGS84、NAD27和NAD83基准，以及CRS1954、CRS1980、CRS54和CRS85基准。

⑥为便于使用，在本标准的资料性附录G中增加了3个与相应国际标准条款G1、G2和G3等同地位的条款G4、G5和G6，作为应用该国际标准的另一组网络制图的示例。

⑦删除了原文7.2.4.6.14第2自然段，因为与第1自然段的第1句话完全重复。

本标准的附录A、附录B、附录C、附录D、附录E和附录F是规范性附录，附录G和附录H是资料性附录。

本标准由全国地理信息标准化委员会提出。

本标准由全国地理信息标准化委员会归口。

本标准起草单位：

武汉大学测绘遥感信息高程国家重点实验室，国土资源部信息中心，武汉大学资源与环境学院，武汉吉奥公司。

本标准主要起草人：

龚健雅、杜道生、高文秀、邓跃进、贾文珏、陈玉敏。

本标准所替代的国际标准ISO19128（E）于2005年12月1日首次发布。

引言

网络地图服务（WebMapService，WMS）从地理信息动态产生具有地理空间位置数据的地图。

本标准将由地理信息图示表达的“地图”定义为计算机屏幕上显示的数字图像文件。

地图本身并不是数据。

WMS产生的地图一般以图像格式提供，如PNG、GIF或JGPE；或按SVG（ScalableVectorGraphics）或WebCGM（WebComputerGraphicsMetafile）格式提供基于矢量的图形元素。

本标准定义了三个操作：

一个是返回服务级元数据；另一个是返回一幅地图，其地理空间参数和维参数有明确定义；可选的第三个操作返回显示在地图上的某些具体要素的信息。

通过使用标准的网络浏览器以统一资源定位符（UniformResourcesLocators，URL）的形式发出请求来调用网络地图服务的操作。

URLs的内容取决于被请求的那些操作。

特别是，当请求一幅地图时，URLs指出什么信息要显示在地图上、制图范围覆盖地球上的哪一部分、指定的空间参照系以及输出图像的宽度和高度。

当利用同样的地理信息参数和输出范围（BoundaryBox，BBOX）产生两幅或多幅地图时，其结果可以准确地被叠加以产生复合地图。

使用支持透明背景的图像格式（如GIF或PNG）可以使下层的地图可见。

此外，单个地图可以从不同的服务器请求得来。

因此，网络地图服务能够构建由分布式地图服务器组成的网络，客户可以从这些服务器定制符合自己要求的地图。

地图请求URLs的例子及其产生的地图的结果见附录G。

本标准适用于网络地图服务实例（WebMapServiceinstance），该实例具有发布和生成地图的功能，但不提供访问特定数据资源的功能。

基本的WMS将地理信息资源分为“图层”（Layers）并提供有限的预定义“样式”来显示这些图层。

本标准仅支持命名的图层和样式，不包括用户自定义要素数据符号化机制。

注：

OGC的SLD规范[6]规定了用户定义要素数据的符号化的机制，而不是命名的图层和样式。

简单说，具有SLD能力的WMS能访问来自网络要素服务（WFS）的要素数据[7]，并应用用户提供的清晰的样式化信息，以便产生一幅地图。

地理信息－地图：

网络服务器接口

1范围

本标准规定了一个服务行为，即从地理信息动态制作具有地理空间参照的地图。

它规定了从服务器获取地图所需要进行的各种操作，包括获取地图的描述信息、获取一幅地图以及查询地图上要素信息的操作等。

本标准适用于图片格式地图的图示化再现，但不适用于获取要素本身的数据或者覆盖的数据值。

2一致性

2.1一致性的类和需求

本标准定义了两种一致性的类：

一种是用于基本的WMS，另一种是用于可查询的WMS。

每一种类都具有两个子类：

一个用于客户，另一个用于服务器。

2.2基本的WMS

基本的WMS支持基本的服务元素（第6章），获取能力（Getcapability）操作（7.2），和获取地图（Getmap）操作（7.3）。

为了与本标准一致，基本的WMS将满足附录A中抽象测试套件A.1的要求。

2.3可查询的WMS

可查询的WMS应满足基本的WMS的全部要求，而且也应支持获取特征信息（GetFeatureinfo）操作（7.4）。

为了与本标准一致，可查询的WMS应满足附录A中抽象测试套件的全部要求。

3规范性引用文件

下列文件中的条款通过本标准的引用成为本标准的条款。

凡是注日期的引用文件，其随后所有的改动（不包括勘误的内容）或修订版均不适用于本标准。

然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。

凡是不注日期的引用文件，其最新的版本适用于本标准。

GB/T7408-1994数据元和交换格式信息交换日期和时间表示法

GB/T19710:

2005地理信息元数据

ISO19111:

2007地理信息基于坐标的空间参照（（ISO19111,Geographicinformation—Spatialreferencingbycoordinates）

EPSG（2003.2）,欧洲石油调查局大地测量参数Lott,R.,Ravanas,B.,Cain,J.,Simonson,G,andNicolai,R.,eds.,availableat

//www.epsg.org/>

IETFRFC2045（1996.10）,多用途英特网邮件扩展（MultipurposeInternetMailExtensions,MIME），第一部分：

英特网消息体格式，Freed,N.andBorenstein,N.,eds.,availableat

//www.ietf.org/rfc/rfc2045.txt>

IETFRFC2396（1998.8）,统一资源标识符（UniformResourceIdentifiers,URI）:

统用句法，Berners-Lee,T.,Fielding,N.,andMasinter,L.,eds.,availableat

//www.ietf.org/rfc/rfc2396.txt>

IETFRFC2616（1999．6）,超文本传输协议–HTTP/1.1,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,Leach,P.,andBerners-Lee,T.,eds.,availableat

//www.ietf.org/rfc/rfc2616.txt>

UCUM,度量单位的统一编码,Schadow,G.andMcDonald,C.J.（eds.）,version1.5

//aurora.regenstrief.org/UCUM/ucum.html>

XML1.0,可扩展标记语言（XML）1.0，WorldWideWebConsortiumRecommendation,Bray,T.,Paoli,J.,Sperberg-McQueen,C.M.,andMaler,E.,eds.,availableat

//www.w3.org/TR/>

XML模式第一部分：

结构，WorldWideWebConsortiumRecommendation,Thompson,H.S.,Beech,D.,Maloney,M.,andMendelsohn,N.,eds.,availableat

//www.w3.org/TR/>

4术语和定义

本标准使用了下列术语和定义。

4.1

客户client

能从服务器调用操作的软件组件

4.2

坐标参照系coordinatereferencesystem

通过基准与现实世界相关联的坐标系[ISO19111]

4.3

坐标系coordinatesystem

给点赋予坐标的数学规则集[ISO19111]

4.4

地理信息geographicinformation

与地球上的位置直接或间接相关现象的信息[ISO19101]

4.5

接口interface

描述实体行为的命名操作集[ISO19119]

4.6

图层layer

地理信息的基本单元，它可以作为一幅地图从服务器端请求得到

4.7

地图map

适合于在计算机屏幕上显示的数字图像文件的地理信息的图示表达

4.8

操作operation

转换和查询的规范，按照这个规范对象可以被调用执行[ISO19119]

4.9

图示表达portrayal

人类对信息的表示[ISO19117]

4.10

请求request

通过客户对操作的调用

4.11

响应response

由服务器端返回给客户的一个操作结果

4.12

服务器server

服务的特定实体（instance）

4.13

服务service

实体通过接口提供的功能性的可区分部分[ISO14252]

4.14

服务元数据servicemetadata

描述服务器上可用的操作和地理信息的元数据

5缩略语

CDATAXML字符数据（XMLCharacterData）

CRS坐标参照系（CoordinateReferenceSystem）

CS坐标系（CoordinateSystem）

DCP分布式计算平台（DistributedComputingPlatfom）

DTD文件类型定义（DocumentTypeDefinition）

EPSG欧洲石油调查局（EuropeanPetroleumSurveyGroup）

GIF图形交换格式（GraphicsInterchangeFormat）

GIS地理信息系统（GeographicInformationSystem）

HTTP超文本传输协议（HypertextTransferProtocol）

IANA国际因特网地址分配委员会（InternetAssignedNumbersAuthority）

IERS国际地球自转服务局（InternationalEarthRotationservice）

IETF因特网工程任务组（InternetEngineeringTaskForce）

ITRF国际陆地参考框架（InternatioanlTerrestrialReferenceFrame）

ITRSIERS陆地参照系（IERSTerrestrialReferenceSystem）

JPEG联合图像专家组（JointPhotographicExpertsGroup）

MIME多用途因特网邮件扩充协议（MultipurposeInternetMailExtensions）

NAD北美基准（NorthAmericanDatum）

OGC开放式地理空间联盟（OpenGeospatialConsortium）名称已改！

PNG可移植的网络图像文件（PortableNetworkGraphics）

RFC征求意见（RequestforComments）

SVG可缩放的矢量图形（ScalableVectorGraphics）

UCUM度量单位统一代码（UnifiedCodeforUnitsofMeasure）

URL统一资源定位符（UniformResourceLocator）

WebCGM网络计算机图形元文件（WebComputerGraphicsMetafile）

WCS网络覆盖服务（WebCoverageService）

WFS网络要素服务（WebFeatureService）

WGS世界大地坐标系（WorldGeodeticSystem）

WMS网络地图服务（WebMapService）

XML可扩展标记语言（ExtensibleMarkupLanguage）

6基本服务元素

6.1概述

本节规定了网络地图服务器行为的某些方面，这些方面独立于特定操作或者是一些操作通用的部分。

6.2版本的编号和协商

6.2.1版本号的形式和值

WMS定义一个协议版本号。

该版本号适用于XML模式和本标准规定的请求编码。

版本号包括三个正整数，它们用小数点分开，以“x.y.z”的形式出现，数字“y”和“z”不超过99。

本标准的各个实现均使用值“1.3.0”作为协议版本号。

6.2.2版本号的变化

协议版本号将随着本标准每个版本的变化而改变。

版本号应当单调增加，并由三个用小数点分隔的正整数组成，其中，第一个整数最为重要。

在号码序列上可以出现中断。

有些版本号表示草案的版本。

服务器及其客户不需要支持所有已定义的版本，但应该遵守以下的协商规则。

6.2.3在请求和服务元数据中的形式

版本号至少应出现在两个地方：

在服务元数据中和在客户向服务器请求的参数表中。

客户对一个特定服务进行请求时使用的版本号应当是该服务已说明支持的版本号（除了正在进行协商外，如6.2.4所述）。

服务器可以支持若干个版本，客户可以根据协商规则得到其具体的版本号。

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号版本。

客户不理解那个版本或是任何更高的版本，因此交流失败，客户停止与服务器的交流。

除了GetCapability外，其他请求中参数版本（VERSION）是必选的。

6.3基本的HTTP请求规则

6.3.1概述

本标准定义了WMS在分布式计算平台（DCP）上的实现，该分布式计算平台由支持超文本传输协议（HTTP）[IETFRFC2616]的位于因特网的主机组成。

因此，每个由服务器支持的操作的在线资源都是一个HTTP统一资源定位符（URL）。

对于每个操作来说，URL可以不同，也可以相同，这由服务提供者来决定。

除了在其它情况下依赖于具体的实现以外，每个URL应当符合IETFRFC2616中的描述（见3.2.2，“HTTPURL”），否则是独立实现；只有查询部分，包括服务请求本身是由本标准来规定的。

HTTP支持两种请求方法：

GET（获取）和POST（邮寄）。

服务器可以提供这些方法中的一个或两个，并且在每种方法中在线信息源定位符（OnlineResourceURL）的使用方法不同。

对GET方法的支持是必选的，对POST的支持是可选的。

6.3.2HTTPGETURL中的保留字符

URL规范[IETFRFC2396]保留了一些特定的字符并赋予它们特定的含义，并要求在可能与其定义的用途相冲突时避免使用它们。

本标准明确地保留了这些字符中的几个，用于WMS请求中的查询部分。

当字符“”、“&”、“=”、“,”和“+”担当表1中所定义的一个角色时，它们应当逐个地出现在URL中。

当这些字符出现在其它的地方时（例如，在参数值中），它们将按照IETFRFC2396所定义的那样进行编码。

服务器应准备以该方式对遗漏的字符进行解码，并将“+”字符作为空格进行解码。

表1WMS请求中查询语句的保留字符

字符

预定的用法

表明查询语句开始的分隔符

&

查询语句参数之间的分隔符

=

参数名称和参数值之间的分隔符

参数表中所列的多个参数值之间的分隔符（如在GetMap请求中的参数：

BBOX（边框），LAYERS（图层）和STYLES（样式））

+

空格字符的速记表示

6.3.3HTTPGET（HTTP的“GET”方法）

WMS应支持HTTP协议的“GET”方法[IETFRFC2616]。

为HTTPGET请求而扩展的在线资源URL事实上只是一个URL的前缀，为了构成一个有效的操作请求在前缀上需增加参数。

根据IETFRFC2396，一个URL前缀定义成一个字符串，依次包括模式（“http”或“https”）、因特网协议的主名或IP地址、可选的端口编号、路径、必选的问号“”和可选的字符串，该字符串由指定服务器的一个或多个参数组成并以“&”为结束符。

该前缀规定了请求参数发送的网络地址，以便在特定服务器上进行特定操作。

每个操作可能有不同的前缀，每个前缀完全由服务提供者来决定。

本标准规定如何构成被附加到URL前缀后面的查询部分，以便形成一个完整的请求消息。

每个WMS操作有若干个必选的或可选的请求参数。

每个参数有一个规定的名称。

每个参数可以有一个或多个有效值，这些参数由本标准规定，或由客户根据服务元数据选择的。

为了构成URL的查询部分，客户应当添加必选的请求参数以及任意设置的可选参数，作为名称和数值对（name/valuepairs），格式为“name=value&”（参数名称、等号、参数值和&）。

“&”是name/value对之间的分隔符，因此在请求字符串最后一个name/value对之后的“&”是可选的。

当使用HTTPGET方法时，客户构造的的查询部分被添加到有服务器定义的URL前缀后面，最后得到完整的URL，通过HTTP协议[IETFRFC2616]被调用。

表2总结了使用HTTPGET时操作请求URL的各组成部分。

表2使用HTTPGET的WMS请求结构

URL构件

描述

http:

//host[:

port]/path{name[=value]&}

服务操作的URL前缀。

[]表示可选部分出现0次或1次；

{}表示0个或更多的事件。

name=value&

一个或更多的标准请求参数的名/值对，就像本标准为每个操作定义的一样。

6.3.4HTTPPOST（HTTP的POST方法）

一个WMS可以支持HTTP协议的“POST”方法（IETFRFC2616）。

用于HTTPPOST请求的在线资源URL是一个完整的URL（不同于HTTPGET，那仅仅是一个前缀），根据IETFRFC2396，客户在POST消息主体中向它发送的请求参数是有效的。

为了给操作请求建立一个有效的目标，WMS不允许在该URL上添加额外的请求参数。

当使用POST方法时，请求消息被格式化为一个XML文档。

6.4基本的HTTP响应规则

在接收到有效请求时，服务器应当按照本标准第7条的规定返回一个严格满足请求的响应，或者在未能准确地做出响应时发布一个服务异常。

只有在进行版本协商情况下（见6.2.3），服务器才可以给出不同的结果。

当接收到一个无效请求时，服务将发送一个在6.11中描述的服务异常信息。

一个服务器可以发送一个HTTP重定向（重寄）

（Redirect）消息（使用IETFRFC2616定义的HTTP响应代码）到一个绝对的URL地址，该URL与从客户发送的有效请求的URL地址是不同的。

HTTP重定向导致客户发出一个定位到新的URL地址的新的HT