WMS网络地图服务规范.docx

1、WMS网络地图服务规范WMS网络地图服务规范ICS 07 040A 75GB中华人民共和国国家标准GB/T 200地理信息地图：网络服务接口Geographic information Web Map Server Interface（ISO 19128：2005，MOD）-发布 -实施目次前言本标准修改采用（MOD）国际标准化组织地理信息标准化委员会（ISO/TC 211）制定的ISO 19128：2005(E) Geographic informationWeb map server interface，并作了如下改动：本标准的编写方法执行国家标准GB/T 1.12000 标准化工作导则

2、第一部分：标准的结构和编写规则、GB/T 20000.2 2001 标准化工作指南 第2部分：采用国际标准的规则的要求。 考虑到我国实际应用的需要，本标准在采用原国际标准时进行了以下编辑修改：a) “本国际标准”一词改为“本标准”；b) 删除了原国际标准的封面、目次和前言；c) 用句号“。”代替作为句号的“.”；d）用小数点“.”代替作为小数点的“，”。e) 本标准的引言采用了原标准的引言，但作了少量的修改；f) 凡已被我国等同采用的国际标准，在本标准用国家标准的代号和名称取代相应的国际标准的代号和名称。原国际标准编号和名称替代的国家标准编号与名称GB/T 7408:2004， 数据元素和交换

3、格式信息交换时间和日期的表达GB/T 7408-1994 数据元和交换格式 信息交换 日期和时间表示法GB/T 19710:2003，地理信息元数据GB/T 19710 地理信息 元数据 删除了原国际标准的前言。 规范性引用文件的引导语和一览表引用文件的排序执行GB/T 1.1-2000，其中ISO 19117改为ISO 19117：2007。 为便于使用，结合我国实际情况，在本标准的附录C中增加了4个与相应的国际标准条款等同地位的条款，作为对该国际标准条款的另一种选择。它们是：a) 表 B.5 使用 Beijing 1954 经度-纬度定义Layer CRS，因此原标准中表B.5改为B.7。

4、 b) 表 B.6 使用 Xian 1980 经度-纬度定义Layer CRS。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等同地位的

5、条款G4、G5和G6，作为应用该国际标准的另一组网络制图的示例。 删除了原文7.2.4.6.14第2自然段，因为与第1自然段的第1句话完全重复。本标准的附录A、附录B、附录C、附录D、附录E和附录F是规范性附录，附录G和附录H是资料性附录。本标准由全国地理信息标准化委员会提出。本标准由全国地理信息标准化委员会归口。本标准起草单位：武汉大学测绘遥感信息高程国家重点实验室，国土资源部信息中心，武汉大学资源与环境学院，武汉吉奥公司。本标准主要起草人：龚健雅、杜道生、高文秀、邓跃进、贾文珏、陈玉敏。本标准所替代的国际标准ISO 19128（E）于2005年12月1日首次发布。引 言网络地图服务（Web

6、 Map Service，WMS）从地理信息动态产生具有地理空间位置数据的地图。本标准将由地理信息图示表达的“地图”定义为计算机屏幕上显示的数字图像文件。地图本身并不是数据。WMS产生的地图一般以图像格式提供，如PNG、GIF 或JGPE；或按SVG（Scalable Vector Graphics）或WebCGM（Web Computer Graphics Metafile）格式提供基于矢量的图形元素。本标准定义了三个操作：一个是返回服务级元数据；另一个是返回一幅地图，其地理空间参数和维参数有明确定义；可选的第三个操作返回显示在地图上的某些具体要素的信息。通过使用标准的网络浏览器以统一资源定

7、位符（Uniform Resources Locators，URL）的形式发出请求来调用网络地图服务的操作。URLs的内容取决于被请求的那些操作。特别是，当请求一幅地图时，URLs指出什么信息要显示在地图上、制图范围覆盖地球上的哪一部分、指定的空间参照系以及输出图像的宽度和高度。当利用同样的地理信息参数和输出范围（Boundary Box，BBOX）产生两幅或多幅地图时，其结果可以准确地被叠加以产生复合地图。使用支持透明背景的图像格式（如GIF或PNG）可以使下层的地图可见。此外，单个地图可以从不同的服务器请求得来。因此，网络地图服务能够构建由分布式地图服务器组成的网络，客户可以从这些服务器定

8、制符合自己要求的地图。地图请求URLs的例子及其产生的地图的结果见附录G。本标准适用于网络地图服务实例（Web Map Service instance），该实例具有发布和生成地图的功能，但不提供访问特定数据资源的功能。基本的WMS将地理信息资源分为“图层”（Layers）并提供有限的预定义“样式”来显示这些图层。本标准仅支持命名的图层和样式，不包括用户自定义要素数据符号化机制。注：OGC的SLD规范 6 规定了用户定义要素数据的符号化的机制，而不是命名的图层和样式。简单说，具有SLD能力的WMS能访问来自网络要素服务（WFS）的要素数据 7 ，并应用用户提供的清晰的样式化信息，以便产生一幅地

9、图。地理信息地图：网络服务器接口1 范围本标准规定了一个服务行为，即从地理信息动态制作具有地理空间参照的地图。它规定了从服务器获取地图所需要进行的各种操作，包括获取地图的描述信息、获取一幅地图以及查询地图上要素信息的操作等。本标准适用于图片格式地图的图示化再现，但不适用于获取要素本身的数据或者覆盖的数据值。2 一致性2.1 一致性的类和需求本标准定义了两种一致性的类：一种是用于基本的WMS，另一种是用于可查询的WMS。每一种类都具有两个子类：一个用于客户，另一个用于服务器。2.2 基本的WMS基本的WMS支持基本的服务元素（第6章），获取能力（Getcapability）操作（7.2），和获取

10、地图（Getmap）操作（7.3）。为了与本标准一致，基本的WMS将满足附录A中抽象测试套件A.1的要求。2.3 可查询的WMS可查询的WMS应满足基本的WMS的全部要求，而且也应支持获取特征信息（GetFeatureinfo）操作（7.4）。为了与本标准一致，可查询的WMS应满足附录A中抽象测试套件的全部要求。3 规范性引用文件下列文件中的条款通过本标准的引用成为本标准的条款。 凡是注日期的引用文件，其随后所有的改动（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新的版本适用于本标准。GB/T 74

11、08-1994 数据元和交换格式 信息交换 日期和时间表示法GB/T 19710:2005 地理信息 元数据ISO 19111:2007 地理信息 基于坐标的空间参照（ISO 19111, Geographic information Spatial referencing by coordinates）EPSG (2003.2), 欧洲石油调查局大地测量参数 Lott, R., Ravanas, B., Cain, J., Simonson, G, and Nicolai, R., eds., available at IETF RFC 2045 (1996.10), 多用途英特网邮件扩展（

12、Multipurpose Internet Mail Extensions, MIME），第一部分：英特网消息体格式， Freed, N. and Borenstein, N., eds., available at IETF RFC 2396 (1998.8), 统一资源标识符(Uniform Resource Identifiers, URI): 统用句法，Berners-Lee, T., Fielding, N., and Masinter, L., eds., available at IETF RFC 2616 (19996), 超文本传输协议 HTTP/1.1, Gettys, J

13、., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T., eds., available at UCUM, 度量单位的统一编码, Schadow, G. and McDonald, C.J. (eds.), version 1.5 XML 1.0, 可扩展标记语言（XML）1.0，World Wide Web Consortium Recommendation, Bray, T., Paoli, J., Sperberg-McQueen, C.M., and Maler, E., eds., availab

14、le at XML模式 第一部分：结构， World Wide Web Consortium Recommendation, Thompson, H.S., Beech, D., Maloney, M., and Mendelsohn, N., eds., available at 4 术语和定义本标准使用了下列术语和定义。4.1 客户 client能从服务器调用操作的软件组件4.2 坐标参照系 coordinate reference system通过基准与现实世界相关联的坐标系ISO 191114.3 坐标系 coordinate system给点赋予坐标的数学规则集ISO 19111 4

15、.4 地理信息 geographic information与地球上的位置直接或间接相关现象的信息ISO 191014.5 接口 interface描述实体行为的命名操作集ISO 191194.6 图层 layer地理信息的基本单元，它可以作为一幅地图从服务器端请求得到4.7 地图 map适合于在计算机屏幕上显示的数字图像文件的地理信息的图示表达4.8 操作 operation转换和查询的规范，按照这个规范对象可以被调用执行ISO 191194.9 图示表达 portrayal人类对信息的表示ISO 191174.10 请求 request通过客户对操作的调用4.11 响应 response由

16、服务器端返回给客户的一个操作结果4.12 服务器 server服务的特定实体（instance）4.13 服务 service 实体通过接口提供的功能性的可区分部分 ISO 142524.14 服务元数据 service metadata描述服务器上可用的操作和地理信息的元数据5 缩略语CDATA XML字符数据（XML Character Data）CRS 坐标参照系（Coordinate Reference System）CS 坐标系（Coordinate System）DCP 分布式计算平台（Distributed Computing Platfom）DTD 文件类型定义（Documen

17、t Type Definition）EPSG 欧洲石油调查局（European Petroleum Survey Group）GIF 图形交换格式（Graphics Interchange Format）GIS 地理信息系统（Geographic Information System）HTT P 超文本传输协议（Hypertext Transfer Protocol）IANA 国际因特网地址分配委员会（Internet Assigned Numbers Authority）IERS 国际地球自转服务局（International Earth Rotation service）IETF 因特网工

18、程任务组（Internet Engineering Task Force）ITRF 国际陆地参考框架（Internatioanl Terrestrial Reference Frame）ITRS IERS陆地参照系（IERS Terrestrial Reference System）JPEG 联合图像专家组（Joint Photographic Experts Group）MIME 多用途因特网邮件扩充协议（Multipurpose Internet Mail Extensions）NAD 北美基准（North American Datum）OGC 开放式地理空间联盟（Open Geospat

19、ial 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 网

20、络要素服务（Web Feature Service）WGS 世界大地坐标系（World Geodetic System）WMS 网络地图服务（Web Map Service）XML 可扩展标记语言（Extensible Markup Language）6 基本服务元素6.1 概述本节规定了网络地图服务器行为的某些方面，这些方面独立于特定操作或者是一些操作通用的部分。6.2 版本的编号和协商6.2.1 版本号的形式和值WMS定义一个协议版本号。该版本号适用于XML模式和本标准规定的请求编码。版本号包括三个正整数，它们用小数点分开，以“x.y.z”的形式出现，数字“y”和“z”不超过99。本标准的

21、各个实现均使用值“1.3.0”作为协议版本号。6.2.2 版本号的变化协议版本号将随着本标准每个版本的变化而改变。版本号应当单调增加，并由三个用小数点分隔的正整数组成，其中，第一个整数最为重要。在号码序列上可以出现中断。有些版本号表示草案的版本。服务器及其客户不需要支持所有已定义的版本，但应该遵守以下的协商规则。6.2.3 在请求和服务元数据中的形式版本号至少应出现在两个地方：在服务元数据中和在客户向服务器请求的参数表中。客户对一个特定服务进行请求时使用的版本号应当是该服务已说明支持的版本号（除了正在进行协商外，如6.2.4所述）。服务器可以支持若干个版本，客户可以根据协商规则得到其具体的版本

22、号。6.2.4 版本号协商一个WMS客户可以和服务器进行协商，以确定一个对双方都适合的版本号。版本号协商是依照以下规则由GetCapabilities操作（在7.2中描述）完成的。所有的服务元数据都应当包括一个协议版本号，并应遵守XML 的文件类型定义（DTD）或为该版本号定义的模式。在响应没有指定版本号的GetCapabilities请求（此时VERSION参数是可选的）时，服务器将以它支持的最高版本进行响应。在响应包含一个服务器实现的版本号的GetCapabilities请求时，服务器应当按照请求版本进行响应。如果服务器不支持请求的版本号，服务器应当以输出它支持的版本来响应，此版本按照如下

23、规则进行确定： 如果被请求的版本是服务器未知的版本且高于服务器所支持的最低版本，服务器将发送它所支持的低于被请求版本的最高版本。 如果客户请求的版本低于服务器已知的任何版本，那么服务器将发送它所支持的最低版本。 如果客户不支持服务器发送的版本，它可以停止与服务器交流，或是发送一个新的请求，新请求包含一个客户所支持的不同的版本号。重复这个过程，直至找到一个相互认可的版本，或者直至客户确定不再或者不能和服务器交流为止。例1：服务器理解1，2，4，5和8号版本，客户理解1，3，4，6和7号版本。客户请求7号版本。服务器发送5号版本。客户请求4号版本。服务器发送4号版本，这个版本客户能理解，这时交流成

24、功地结束。例2：服务器理解4，5和8号版本，客户理解3号版本。客户请求3号版本，服务器发送4号版本。客户不理解那个版本或是任何更高的版本，因此交流失败，客户停止与服务器的交流。除了GetCapability 外，其他请求中参数版本（VERSION）是必选的。6.3 基本的HTTP请求规则6.3.1 概述本标准定义了WMS在分布式计算平台（DCP）上的实现，该分布式计算平台由支持超文本传输协议（HTTP）IETF RFC 2616的位于因特网的主机组成。因此，每个由服务器支持的操作的在线资源都是一个HTTP统一资源定位符（URL）。对于每个操作来说，URL可以不同，也可以相同，这由服务提供者来决

25、定。除了在其它情况下依赖于具体的实现以外，每个URL应当符合IETF RFC 2616中的描述（见3.2.2，“HTTP URL”），否则是独立实现；只有查询部分，包括服务请求本身是由本标准来规定的。 HTTP支持两种请求方法：GET（获取）和POST（邮寄）。服务器可以提供这些方法中的一个或两个，并且在每种方法中在线信息源定位符（Online Resource URL）的使用方法不同。对GET方法的支持是必选的，对POST的支持是可选的。6.3.2 HTTP GET URL中的保留字符URL规范IETF RFC 2396保留了一些特定的字符并赋予它们特定的含义，并要求在可能与其定义的用途相冲

26、突时避免使用它们。本标准明确地保留了这些字符中的几个，用于WMS请求中的查询部分。当字符“”、“&”、“ =”、“,”和“+”担当表1中所定义的一个角色时，它们应当逐个地出现在URL中。当这些字符出现在其它的地方时（例如，在参数值中），它们将按照 IETF RFC 2396 所定义的那样进行编码。服务器应准备以该方式对遗漏的字符进行解码，并将“+”字符作为空格进行解码。表1 WMS请求中查询语句的保留字符字 符预 定 的 用 法表明查询语句开始的分隔符&查询语句参数之间的分隔符=参数名称和参数值之间的分隔符,参数表中所列的多个参数值之间的分隔符（如在GetMap请求中的参数：BBOX（边框），

27、LAYERS（图层） 和STYLES（样式）+空格字符的速记表示6.3.3 HTTP GET（HTTP的“GET”方法） WMS应支持HTTP协议的“GET”方法IETF RFC 2616。为 HTTP GET 请求而扩展的在线资源URL事实上只是一个 URL 的前缀，为了构成一个有效的操作请求在前缀上需增加参数。根据IETF RFC 2396，一个 URL 前缀定义成一个字符串，依次包括模式（“http”或“https”）、因特网协议的主名或IP地址、可选的端口编号、路径、必选的问号“”和可选的字符串，该字符串由指定服务器的一个或多个参数组成并以“&”为结束符。该前缀规定了请求参数发送的网络

28、地址，以便在特定服务器上进行特定操作。每个操作可能有不同的前缀，每个前缀完全由服务提供者来决定。本标准规定如何构成被附加到URL前缀后面的查询部分，以便形成一个完整的请求消息。每个WMS操作有若干个必选的或可选的请求参数。每个参数有一个规定的名称。每个参数可以有一个或多个有效值，这些参数由本标准规定，或由客户根据服务元数据选择的。为了构成URL的查询部分，客户应当添加必选的请求参数以及任意设置的可选参数，作为名称和数值对（name/value pairs），格式为“name=value&”（参数名称、等号、参数值和&）。“&”是name/value对之间的分隔符，因此在请求字符串最后一个nam

29、e/value对之后的“&”是可选的。当使用HTTP GET方法时，客户构造的的查询部分被添加到有服务器定义的URL前缀后面，最后得到完整的URL，通过HTTP协议IETF RFC 2616被调用。表2总结了使用HTTP GET时操作请求URL的各组成部分。表2 使用HTTP GET的WMS请求结构URL 构件描 述http:/host:port/pathname=value&服务操作的URL前缀。 表示可选部分出现0次或1次； 表示0个或更多的事件。name=value&一个或更多的标准请求参数的名/值对，就像本标准为每个操作定义的一样。6.3.4 HTTP POST（HTTP的POST方法

30、）一个WMS可以支持HTTP协议的“POST”方法（IETF RFC2616）。用于HTTP POST请求的在线资源URL是一个完整的URL（不同于HTTP GET，那仅仅是一个前缀），根据IETF RFC2396，客户在POST消息主体中向它发送的请求参数是有效的。为了给操作请求建立一个有效的目标，WMS不允许在该URL上添加额外的请求参数。当使用POST方法时，请求消息被格式化为一个XML文档。6.4 基本的HTTP响应规则在接收到有效请求时，服务器应当按照本标准第7条的规定返回一个严格满足请求的响应，或者在未能准确地做出响应时发布一个服务异常。只有在进行版本协商情况下（见6.2.3），服务器才可以给出不同的结果。当接收到一个无效请求时，服务将发送一个在6.11中描述的服务异常信息。一个服务器可以发送一个HTTP 重定向（重寄）（Redirect）消息（使用IETF RFC 2616定义的HTTP响应代码）到一个绝对的URL地址，该URL与从客户发送的有效请求的URL地址是不同的。HTTP 重定向导致客户发出一个定位到新的URL地址的新的HT