WMS网络地图服务规范

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

1、ICS 07 040A 75GB中华人民共和国国家标准GB/T 200地理信息地图：网络服务接口Geographic information Web Map Server Interface（ISO 19128：2005，MOD）-发布 -实施中华人民共和国国家质量监督检验检疫总局中国国标准化管理委员会发布目次引 言v1 范围12 一致性12.1 一致性的类和需求12.2 基本的WMS12.3 可查询的WMS13 规范性引用文件14 术语和定义25 缩略语46 基本服务元素46.1 概述46.2 版本的编号和协商56.3 基本的HTTP请求规则66.4 基本的HTTP响应规则76.5 数值和布

2、尔值86.6 输出格式96.7 坐标系96.8 请求参数规则146.9 通用请求参数156.10 服务结果166.11 服务异常167 网络地图服务操作167.1 概述167.2 GetCapabilities（必选）167.3 GetMap（必选）307.4 GetFeatureInfo（可选）36附录 A（规范性附录）：一致性测试39附录B（规范性附录）：地图参照系（CRS）的定义41附录 C（规范性附录）：多维数据处理50附录 D（规范性附录）：GB/T 7408 的网络地图服务专用标准56附录 E（规范性附录）：XML模式58附录 F（规范性附录）：UML 模型75附录 G（资料性附录

3、）：网络制图示例79附录 H（资料性附录）：XML示例84参考书目92前言本标准修改采用（MOD）国际标准化组织地理信息标准化委员会（ISO/TC 211）制定的ISO 19128：2005(E) Geographic informationWeb map server interface，并作了如下改动：本标准的编写方法执行国家标准GB/T 1.12000 标准化工作导则 第一部分：标准的结构和编写规则、GB/T 20000.2 2001 标准化工作指南 第2部分：采用国际标准的规则的要求。 考虑到我国实际应用的需要，本标准在采用原国际标准时进行了以下编辑修改：a) “本国际标准”一词改为“

4、本标准”；b) 删除了原国际标准的封面、目次和前言；c) 用句号“。”代替作为句号的“.”；d）用小数点“.”代替作为小数点的“，”。e) 本标准的引言采用了原标准的引言，但作了少量的修改；f) 凡已被我国等同采用的国际标准，在本标准用国家标准的代号和名称取代相应的国际标准的代号和名称。原国际标准编号和名称替代的国家标准编号与名称GB/T 7408:2004， 数据元素和交换格式信息交换时间和日期的表达GB/T 7408-1994 数据元和交换格式 信息交换 日期和时间表示法GB/T 19710:2003，地理信息元数据GB/T 19710 地理信息 元数据 删除了原国际标准的前言。 规范性引

5、用文件的引导语和一览表引用文件的排序执行GB/T 1.1-2000，其中ISO 19117改为ISO 19117：2007。 为便于使用，结合我国实际情况，在本标准的附录C中增加了4个与相应的国际标准条款等同地位的条款，作为对该国际标准条款的另一种选择。它们是：a) 表 B.5 使用 Beijing 1954 经度-纬度定义Layer CRS，因此原标准中表B.5改为B.7。 b) 表 B.6 使用 Xian 1980 经度-纬度定义Layer CRS。c) 表 B.8 使用 国家黄海高程基准 1956 定义垂直 CRS。d) 表 B.9 使用 国家高程基准 1980 定义垂直 CRS。为此，

6、原标准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和附

7、录H是资料性附录。本标准由全国地理信息标准化委员会提出。本标准由全国地理信息标准化委员会归口。本标准起草单位：武汉大学测绘遥感信息高程国家重点实验室，国土资源部信息中心，武汉大学资源与环境学院，武汉吉奥公司。本标准主要起草人：龚健雅、杜道生、高文秀、邓跃进、贾文珏、陈玉敏。本标准所替代的国际标准ISO 19128（E）于2005年12月1日首次发布。引 言网络地图服务（Web Map Service，WMS）从地理信息动态产生具有地理空间位置数据的地图。本标准将由地理信息图示表达的“地图”定义为计算机屏幕上显示的数字图像文件。地图本身并不是数据。WMS产生的地图一般以图像格式提供，如PNG、G

8、IF 或JGPE；或按SVG（Scalable Vector Graphics）或WebCGM（Web Computer Graphics Metafile）格式提供基于矢量的图形元素。本标准定义了三个操作：一个是返回服务级元数据；另一个是返回一幅地图，其地理空间参数和维参数有明确定义；可选的第三个操作返回显示在地图上的某些具体要素的信息。通过使用标准的网络浏览器以统一资源定位符（Uniform Resources Locators，URL）的形式发出请求来调用网络地图服务的操作。URLs的内容取决于被请求的那些操作。特别是，当请求一幅地图时，URLs指出什么信息要显示在地图上、制图范围覆盖地

9、球上的哪一部分、指定的空间参照系以及输出图像的宽度和高度。当利用同样的地理信息参数和输出范围（Boundary Box，BBOX）产生两幅或多幅地图时，其结果可以准确地被叠加以产生复合地图。使用支持透明背景的图像格式（如GIF或PNG）可以使下层的地图可见。此外，单个地图可以从不同的服务器请求得来。因此，网络地图服务能够构建由分布式地图服务器组成的网络，客户可以从这些服务器定制符合自己要求的地图。地图请求URLs的例子及其产生的地图的结果见附录G。本标准适用于网络地图服务实例（Web Map Service instance），该实例具有发布和生成地图的功能，但不提供访问特定数据资源的功能。基

10、本的WMS将地理信息资源分为“图层”（Layers）并提供有限的预定义“样式”来显示这些图层。本标准仅支持命名的图层和样式，不包括用户自定义要素数据符号化机制。注：OGC的SLD规范 6 规定了用户定义要素数据的符号化的机制，而不是命名的图层和样式。简单说，具有SLD能力的WMS能访问来自网络要素服务（WFS）的要素数据 7 ，并应用用户提供的清晰的样式化信息，以便产生一幅地图。地理信息地图：网络服务器接口1 范围本标准规定了一个服务行为，即从地理信息动态制作具有地理空间参照的地图。它规定了从服务器获取地图所需要进行的各种操作，包括获取地图的描述信息、获取一幅地图以及查询地图上要素信息的操作等

11、。本标准适用于图片格式地图的图示化再现，但不适用于获取要素本身的数据或者覆盖的数据值。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的全部要求，而且也应支持获取特征信息（GetFeaturein

12、fo）操作（7.4）。为了与本标准一致，可查询的WMS应满足附录A中抽象测试套件的全部要求。3 规范性引用文件下列文件中的条款通过本标准的引用成为本标准的条款。 凡是注日期的引用文件，其随后所有的改动（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新的版本适用于本标准。GB/T 7408-1994 数据元和交换格式 信息交换 日期和时间表示法GB/T 19710:2005 地理信息 元数据ISO 19111:2007 地理信息 基于坐标的空间参照（ISO 19111, Geographic infor

13、mation 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), 多用途英特网邮件扩展（Multipurpose Internet Mail Extensions, MIME），第一部分：英特网消息体格式， Freed, N. and Borenstein, N., eds., available at IE

14、TF 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., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T., eds., available at UCUM, 度量单位的统一编码, Sc

15、hadow, 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., available at XML模式 第一部分：结构， World Wide Web Consortium Recommendation, Thompson, H.S., Beech, D., Maloney, M., and Mend

16、elsohn, N., eds., available at 4 术语和定义本标准使用了下列术语和定义。4.1客户 client能从服务器调用操作的软件组件4.2 坐标参照系 coordinate reference system通过基准与现实世界相关联的坐标系ISO 191114.3 坐标系 coordinate system给点赋予坐标的数学规则集ISO 19111 4.4 地理信息 geographic information与地球上的位置直接或间接相关现象的信息ISO 191014.5 接口 interface描述实体行为的命名操作集ISO 191194.6 图层 layer地理信息的

17、基本单元，它可以作为一幅地图从服务器端请求得到4.7 地图 map适合于在计算机屏幕上显示的数字图像文件的地理信息的图示表达4.8 操作 operation转换和查询的规范，按照这个规范对象可以被调用执行ISO 191194.9 图示表达 portrayal人类对信息的表示ISO 191174.10 请求 request通过客户对操作的调用4.11 响应 response由服务器端返回给客户的一个操作结果4.12 服务器 server服务的特定实体（instance）4.13 服务 service 实体通过接口提供的功能性的可区分部分 ISO 142524.14 服务元数据 service m

18、etadata描述服务器上可用的操作和地理信息的元数据5 缩略语CDATAXML字符数据（XML Character Data）CRS 坐标参照系（Coordinate Reference System）CS坐标系（Coordinate System）DCP 分布式计算平台（Distributed Computing Platfom）DTD文件类型定义（Document Type Definition）EPSG欧洲石油调查局（European Petroleum Survey Group）GIF图形交换格式（Graphics Interchange Format）GIS地理信息系统（Geogr

19、aphic Information System）HTTP超文本传输协议（Hypertext Transfer Protocol）IANA国际因特网地址分配委员会（Internet Assigned Numbers Authority）IERS国际地球自转服务局（International Earth Rotation service）IETF因特网工程任务组（Internet Engineering Task Force）ITRF国际陆地参考框架（Internatioanl Terrestrial Reference Frame）ITRSIERS陆地参照系（IERS Terrestrial

20、Reference System）JPEG联合图像专家组（Joint Photographic Experts Group）MIME多用途因特网邮件扩充协议（Multipurpose Internet Mail Extensions）NAD北美基准（North American Datum）OGC开放式地理空间联盟（Open Geospatial Consortium）名称已改！PNG可移植的网络图像文件（Portable Network Graphics）RFC 征求意见（Request for Comments）SVG可缩放的矢量图形（Scalable Vector Graphics）UC

21、UM度量单位统一代码（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）6 基本服务元素6.1 概

22、述本节规定了网络地图服务器行为的某些方面，这些方面独立于特定操作或者是一些操作通用的部分。6.2 版本的编号和协商6.2.1 版本号的形式和值WMS定义一个协议版本号。该版本号适用于XML模式和本标准规定的请求编码。版本号包括三个正整数，它们用小数点分开，以“x.y.z”的形式出现，数字“y”和“z”不超过99。本标准的各个实现均使用值“1.3.0”作为协议版本号。6.2.2 版本号的变化协议版本号将随着本标准每个版本的变化而改变。版本号应当单调增加，并由三个用小数点分隔的正整数组成，其中，第一个整数最为重要。在号码序列上可以出现中断。有些版本号表示草案的版本。服务器及其客户不需要支持所有已定

23、义的版本，但应该遵守以下的协商规则。6.2.3 在请求和服务元数据中的形式版本号至少应出现在两个地方：在服务元数据中和在客户向服务器请求的参数表中。客户对一个特定服务进行请求时使用的版本号应当是该服务已说明支持的版本号（除了正在进行协商外，如6.2.4所述）。服务器可以支持若干个版本，客户可以根据协商规则得到其具体的版本号。6.2.4 版本号协商一个WMS客户可以和服务器进行协商，以确定一个对双方都适合的版本号。版本号协商是依照以下规则由GetCapabilities操作（在7.2中描述）完成的。所有的服务元数据都应当包括一个协议版本号，并应遵守XML 的文件类型定义（DTD）或为该版本号定义

24、的模式。在响应没有指定版本号的GetCapabilities请求（此时VERSION参数是可选的）时，服务器将以它支持的最高版本进行响应。在响应包含一个服务器实现的版本号的GetCapabilities请求时，服务器应当按照请求版本进行响应。如果服务器不支持请求的版本号，服务器应当以输出它支持的版本来响应，此版本按照如下规则进行确定： 如果被请求的版本是服务器未知的版本且高于服务器所支持的最低版本，服务器将发送它所支持的低于被请求版本的最高版本。 如果客户请求的版本低于服务器已知的任何版本，那么服务器将发送它所支持的最低版本。 如果客户不支持服务器发送的版本，它可以停止与服务器交流，或是发送一

25、个新的请求，新请求包含一个客户所支持的不同的版本号。重复这个过程，直至找到一个相互认可的版本，或者直至客户确定不再或者不能和服务器交流为止。例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 基本的HTT

26、P请求规则6.3.1 概述本标准定义了WMS在分布式计算平台（DCP）上的实现，该分布式计算平台由支持超文本传输协议（HTTP）IETF RFC 2616的位于因特网的主机组成。因此，每个由服务器支持的操作的在线资源都是一个HTTP统一资源定位符（URL）。对于每个操作来说，URL可以不同，也可以相同，这由服务提供者来决定。除了在其它情况下依赖于具体的实现以外，每个URL应当符合IETF RFC 2616中的描述（见3.2.2，“HTTP URL”），否则是独立实现；只有查询部分，包括服务请求本身是由本标准来规定的。HTTP支持两种请求方法：GET（获取）和POST（邮寄）。服务器可以提供这些

27、方法中的一个或两个，并且在每种方法中在线信息源定位符（Online Resource URL）的使用方法不同。对GET方法的支持是必选的，对POST的支持是可选的。6.3.2 HTTP GET URL中的保留字符URL规范IETF RFC 2396保留了一些特定的字符并赋予它们特定的含义，并要求在可能与其定义的用途相冲突时避免使用它们。本标准明确地保留了这些字符中的几个，用于WMS请求中的查询部分。当字符“?”、“&”、“ =”、“,”和“+”担当表1中所定义的一个角色时，它们应当逐个地出现在URL中。当这些字符出现在其它的地方时（例如，在参数值中），它们将按照 IETF RFC 2396 所

28、定义的那样进行编码。服务器应准备以该方式对遗漏的字符进行解码，并将“+”字符作为空格进行解码。表1 WMS请求中查询语句的保留字符字 符预 定 的 用 法?表明查询语句开始的分隔符&查询语句参数之间的分隔符=参数名称和参数值之间的分隔符,参数表中所列的多个参数值之间的分隔符（如在GetMap请求中的参数：BBOX（边框），LAYERS（图层） 和STYLES（样式）+空格字符的速记表示6.3.3 HTTP GET（HTTP的“GET”方法）WMS应支持HTTP协议的“GET”方法IETF RFC 2616。为 HTTP GET 请求而扩展的在线资源URL事实上只是一个 URL 的前缀，为了构成

29、一个有效的操作请求在前缀上需增加参数。根据IETF RFC 2396，一个 URL 前缀定义成一个字符串，依次包括模式（“http”或“https”）、因特网协议的主名或IP地址、可选的端口编号、路径、必选的问号“?”和可选的字符串，该字符串由指定服务器的一个或多个参数组成并以“&”为结束符。该前缀规定了请求参数发送的网络地址，以便在特定服务器上进行特定操作。每个操作可能有不同的前缀，每个前缀完全由服务提供者来决定。本标准规定如何构成被附加到URL前缀后面的查询部分，以便形成一个完整的请求消息。每个WMS操作有若干个必选的或可选的请求参数。每个参数有一个规定的名称。每个参数可以有一个或多个有效

30、值，这些参数由本标准规定，或由客户根据服务元数据选择的。为了构成URL的查询部分，客户应当添加必选的请求参数以及任意设置的可选参数，作为名称和数值对（name/value pairs），格式为“name=value&”（参数名称、等号、参数值和&）。“&”是name/value对之间的分隔符，因此在请求字符串最后一个name/value对之后的“&”是可选的。当使用HTTP GET方法时，客户构造的的查询部分被添加到有服务器定义的URL前缀后面，最后得到完整的URL，通过HTTP协议IETF RFC 2616被调用。表2总结了使用HTTP GET时操作请求URL的各组成部分。表2 使用HTTP

31、 GET的WMS请求结构URL 构件描 述http:/host:port/path?name=value&服务操作的URL前缀。 表示可选部分出现0次或1次； 表示0个或更多的事件。name=value&一个或更多的标准请求参数的名/值对，就像本标准为每个操作定义的一样。6.3.4 HTTP POST（HTTP的POST方法）一个WMS可以支持HTTP协议的“POST”方法（IETF RFC2616）。用于HTTP POST请求的在线资源URL是一个完整的URL（不同于HTTP GET，那仅仅是一个前缀），根据IETF RFC2396，客户在POST消息主体中向它发送的请求参数是有效的。为了给

32、操作请求建立一个有效的目标，WMS不允许在该URL上添加额外的请求参数。当使用POST方法时，请求消息被格式化为一个XML文档。6.4 基本的HTTP响应规则在接收到有效请求时，服务器应当按照本标准第7条的规定返回一个严格满足请求的响应，或者在未能准确地做出响应时发布一个服务异常。只有在进行版本协商情况下（见6.2.3），服务器才可以给出不同的结果。当接收到一个无效请求时，服务将发送一个在6.11中描述的服务异常信息。一个服务器可以发送一个HTTP 重定向（重寄？）（Redirect）消息（使用IETF RFC 2616定义的HTTP响应代码）到一个绝对的URL地址，该URL与从客户发送的有效

33、请求的URL地址是不同的。HTTP 重定向导致客户发出一个定位到新的URL地址的新的HTTP 请求。从理论上讲，可能出现若干个重定向消息，但事实上，当服务器返回一个WMS响应时，重定向便会终止。最终的响应结果必将是一个与原请求严格对应的WMS响应（或者是一个服务异常）。响应对象应当伴随一个适当的多用途因特网邮件扩展协议（MIME）类型（IETF RFC 2045）。因特网上常用的MIME类型的目录由国际因特网地址分配委员会 (IANA) 负责维护2 。下面将讨论所允许的操作响应类型和服务异常类型。一个MIME类型的基本结构是一个“类型/子类型”形式的字符串。MIME允许在“类型/子类型；参数1

34、=值1；参数2=值2”这种形式的字符串中附加其他参数。一台服务器可以在它所支持的输出格式列表中包括参数化的MIME类型，除了这些参数化的变量外，一台服务器还应当提供这种输出格式非参数化的版本。响应对象还应当尽可能地伴随其他适当的HTTP实体头信息。特别是，过期的（Expire）和最近被修改的（Last-Modified）头信息为缓存（cashing）提供了重要的信息；客户可以通过内容长度（Content-Length）了解数据传输什么时候完成，并为结果有效地分配空间。为了正确地解释结果，内容编码（Content-Encoding）或内容传输编码（Content-Transfer-Encodin

35、g）可能是必要的。6.5 数值和布尔值整（型）数应当与XML模式数据类型（8，3.3.13）中整型数(integers)的说明方式相一致。本规范应明确地指明在什么地方整型值是必选的。实（型）数应当与XML模式数据类型（8，3.2.5）中双精度类型数(double-precision)的说明方式相一致，这种表达考虑到整数、小数和指数表达式。在本标准中规定的全部的值域都可以使用实型值，除非这个值被严格地限定为整型。除了明确地限制以外，允许使用正值、负值和零。布尔值应与XML模式数据类型（8，3.2.2）中布尔类型(Boolean)的说明方式相一致。值“0”等价于 “false（假）”；值“1”等价

36、于“true（真）”。可选值的缺省等价于逻辑假。本标准应明确地指明在什么地方布尔值是必选的。6.6 输出格式对一个WMS服务请求的响应通常是一个从服务器到客户通过因特传输的文件。这个文件可能是文本形式，也可能是一幅地图图像文件。正如6.4 说明的那样，返回的文件类型应当在MIME类型的字符串中指明。文本输出格式通常采用可扩展标记语言（XML；MIME 类型 text/xml）书写的文本格式。文本格式用于传递服务元数据、错误条件的描述或者对显示在地图上的要素信息查询的响应。所允许的地图格式可以是“图片（picture）”格式，也可以是“图形元素(graphic element)”格式。图片格式构

37、成了固定大小的矩形像元阵列。图片格式包括的文件类型有：图形交换格式（GIF；MIME 类型“image/gif”），可移植网络图像（PNG；MIME 类型“image/png”），联合图像专家组（JPEG；MIME 类型“image/jpeg”），所有这些文件格式都可以在通用的Web浏览器上显示，一些文件类型比如标签图像文件格式（TIFF；MIME类型“image/tiff”）可能要求其他的软件（除了基本的Web浏览器外）来帮助显示。图形元素格式是一种使图形元素（包括点、线、弧段、文本和影像）不依比例显示的一种文件格式。因此，在保留图形元素的相关排列的同时，显示的大小可能会改变。图形元素格式包

38、括可缩放矢量图形（SVG；MIME 类型“image/svg+xml”），或者网络计算机图形元文件（WebCGM；MIME 类型“image/cgm”；版本= 4 ；ProfileId= WebCGM）等格式 。注1 ：SVG使用XML表达，因而被认为是文本输出格式，但就本标准的目的而言， SGV被看作是一种地图格式。注：WebCGM是ISO/IEC 8632的专用标准。一台服务器可能提供多种地图格式。它所提供的格式在服务元数据的格式（Format）元素中被列举出来。本标准不要求使用特定的格式。但是，对于描述矢量要素的地图，服务器应当至少提供一种支持透明的图像文件格式，以便被叠置的地图不会遮挡

39、其下面的其他的地图（见7.3.3.9关于透明的讨论）。同时，为了便于使用，服务器应当至少提供一种不需要其他软件支持就能被通用的Web浏览器显示的文件格式。基于这些考虑，服务器至少要求能提供PNG格式。6.7 坐标系6.7.1 简介本标准使用两种主要类型的坐标系统：一种是Map CS，它应用于由WMS生成的地图的图示表达；一种是Layer CRS，它将边框（Bounding BOX）用于源数据。在进行地图图示表达的操作时，一个WMS将地理信息从Layer CRS转换到Map CS。此外，一个图层可能还有关联的垂直坐标系、时间坐标系或其它坐标系。6.7.2 Map CSMap CS 是为WMS制作

40、的地图所提供的坐标参照系。一幅WMS地图是一组显示在计算机屏幕上的矩形像元格网（或者是一个能以这样的形式被显示的数字化文件）。Map CS 有一个水平轴，记为；一个垂直轴，记为。和应当是正整数。原点（，）（0，0）是在地图的左上角；向右递增，向下递增。Map CS 用附录B.2中ISO 19111术语的定义，用“CRS:1”标记来识别。通常，Map CS 的坐标轴的朝向是这样定义的：即轴与Layer CRS自东向西的轴平行并且向东递增，轴与Layer CRS的自北向南的轴平行并且向南递增。在某些情况下，这种定向可能并不存在，比如南极上的正射投影。但是只要这种投影变换存在，那么变换所遵循的惯例便

41、是：无论在什么情况下，东指向地图坐标系的右边，北指向Map CS的上边。GetMap请求（见7.3.3.8）中使用的WIDTH（宽度）参数和HEIGHT (高度)参数以及包括在GetFeatureInfo请求中对应于和的参数如下： WIDTH 指的是沿轴的以像元为单位的地图图像的大小（也就是说，WIDTH-1是的最大值）； HEIGHT 指的是沿 j 轴的以像元为单位的地图图像的大小（也就是说，HEIGHT-1是的最大值）；在GetFeatureInfo请求（7.4.3.7）中使用的参数和j分别指的是沿着Map CS的i轴和j轴的整型值。6.7.3 图层坐标参照系（Layer CRS）6.7.

42、3.1 简介 一个Layer CRS是一种水平坐标参照系，它服务于作为地图来源的地理信息。正如下面将要讨论的一样，可能有多个Layer CRS。一个Layer CRS出现在下列与WMS 相关的实体中： 服务元数据中的（）元素（7.2.4.6.8）； GetMap请求中的CRS参数(7.3.3.5) ； GetFeatureInfo 请求中地图请求部分的CRS参数(7.4.3.3)。 一个WMS应当支持至少一种CRS。只有所有被选择的服务器都支持了一种通用的CRS，来自多台服务器的地图才可能被叠置。本标准不要求支持任何特定的Layer CRS。相反，该标准在该条和附录B中，只阐述了如何定义各种C

43、RS并讨论了几个可选的Layer CRS。 地图提供者可能支持对其地理位置或信息团体最有用和最适合的CRS。为了充分发挥服务器之间的互操作性，提供者还应通过地心坐标系，如 “CRS:84”（见6.7.3.2）、“EPSG:4326”（见6.7.3.3）或其他以ITRF为基础的各种系统来支持地理坐标。每个Layer CRS都有一个字符串作为标识符。Layer CRS标识符允许“label”和“URL”两种类型： Label: 这个标识符包括一个namespace（命名空间）前缀、一个冒号、一串数字或字符代码，并且在某些实例中还有一个逗号，其后跟随附加参数。正如下面的讨论，本标准定义了三种命名空间

44、：CRS，EPSG和AUTO2。 URL: 这个标识符是一个完全合法的URL，它指向一个大家都能访问的包含CRS定义的文件，且与ISO 19111一致。Layer CRS有两个轴，分别为x和y 。按CRS定义，x轴是第一个轴，y轴是第二个轴。x轴朝向是否自东向西，y轴朝向是否由南向北，这取决于特定的CRS。当将地理信息由Layer CRS映射到Map CS时，WMS的图示表达操作应当说明Layer CRS中坐标轴的排列次序、坐标系的原点以及坐标轴方向。坐标应当按CRS定义的顺序排列，并映射到Map CS对应的i轴和j轴。在进行投影变换操作时，需要交换坐标轴的次序。许多投影坐标参照系除了有向东和

45、向北两个坐标方向外，还有一个坐标轴及坐标顺序问题。例如，在芬兰使用的统一坐标系（EPSG:2393）中将向北列在向东之前。EPSG 地理坐标参照系遵循ISO 6709 ，它总是将纬度列在经度之前。大多数坐标参照系用两个坐标轴进行定向，一个指向东（E）的轴为正，另一个指向北（N）的轴为正。这些坐标系的坐标轴很容易被分别映射到边框的i轴和j轴。但是，有些CRS的坐标在其他方向上递增。例如，南非使用的Hartebeesthoek94 / Lo25系统（EPSG:2051）中的坐标向西和向南递增。对有效边框的测试应当能识别和解释CRS坐标轴的正方向。在地理CRS中，纬度应当在 -90，90 度之间取值

46、，经度应当在 -180，180 度之间取值或者是在CRS定义的其他单位的等效值中取值。7.3.5介绍的是关于从地理CRS到Map CS 转换的图层坐标参照系的投影变换。当CRS代码指定的2-维地理CRS的坐标轴使用其他单位而不是使用度为单位，或者使用度但不是十进制的度表示时，这种表示应当转换成十进制度的表示。注：将经度排在纬度之前的坐标轴排放次序的地理CRS不同于历史惯例。国际航空和航海部门的用户可能期望纬度在经度之前的排列顺序。这种不同的坐标排列出于安全的目的，特别是在处理紧急事件时作出响应。尽管本标准没有指定用户界面，但是WMS的用户界面开发者都应当注意纬度和经度的引用顺序，例如，用户的一

47、个边框输入或鼠标坐标的读取都应当将纬度显示在经度前。6.7.3.2 适用于CRS的CRS命名空间“CRS”的命名空间的前缀参考本标准附录B中定义的坐标参照系。这些定义采用了ISO 19111规定的格式。在附录B中，“CRS”命名空间的地理CRS被规定为WGS84、NAD27和NAD83基准，以及CRS1954、CRS1980、CRS54和CRS85基准。一个“CRS”的CRS标签由“CRS”前缀、冒号（：）和数字或字符串编码组成。例： “CRS:84”指的是WGS 84以十进制度表示的经度值和纬度值，并且经度范围在-180度和+180度之间，纬度范围在90度和90度之间。6.7.3.3 适用于

48、CRS的EPSG命名空间“EPSG”命名空间前缀参考了欧洲石油调查局（EPSG）大地测量数据集，EPSG为许多通用的坐标参照系定义了数字标识符（EPSG的“CRS代码”对应于EPSG数据集中的“COORD_REF_SYS_CODE”字段）。对大地测量、地图投影和坐标参照系数据的定义与每个CRS标识符相关。一个“EPSG”的CRS标签由“EPSG”前缀、冒号和一个数字代码组成。例：EPSG:4236指的是WGS 84地理纬度，然后是地理经度。也就是说，在CRS中，X轴代表纬度，Y轴代表经度。注：EPSG的带有“度供应商定义的表示法”的坐标轴的地理坐标参照系在本标准中采用十进制的度。6.7.3.4

49、 适用于CRS的AUTO2命名空间“AUTO2”命名空间用于“自动的”坐标参照系，即用于由用户选择投影中心的这类CRS，在附录B中定义了几个“AUTO2” CRS。一个完整的“AUTO2” CRS标签由“AUTO2”命名空间前缀、来自AUTO2命名空间的数字CRS标识符、规定边框单位和AUTO2 CRS 的单位之间转换的转换因子（factor）的一个数字，以及边框中心的以度为单位的经度和纬度值等组成：AUTO2:auto_crs_id, factor, lon0, lat0转换因子应当是非零的正值。如果factor =1，那么BBOX的单位与CRS定义中说明的单位相同；如果factor不是1，

50、那么factor就是BBOX单位和CRS单位的比值。在GetMap请求中规定，完整的 AUTO2 CRS包括经度、纬度和单位。在服务元数据中，因为客户在请求一个AUTO2 CRS时选择了经度、纬度和单位，因此他们可以省略。例1 ：一台服务器通过在服务元数据中包括“AUTO2:42003”的元素来指明它是支持自动正交CRS。客户可能发出一个GetMap请求得到该坐标参照系的一幅地图，此地图边框以m为单位，以西经100度，北纬45度为中心，使用的参数为“CRS=AUTO2:42003,1,-100,45”。例2 ： 与例1 相同的请求，但是允许边框有转换因子，并且边框以美国的英尺为单位，使用参数“

51、CRS=AUTO2:42003,0.3048006096012192,-100,45”。6.7.3.5 未定义CRS的地理信息服务器可能提供并没有准确定义空间参照的2-维地理信息。例如，一张手绘的历史地图可能代表一块地球区域但它并没有采用当代的空间参照系，而且航空像片可能没有引用精确的地理参照。这种类型的图片信息应该被看作图像，并且在为这样的对象描述Layer CRS时，就应当使用图像CS 的标签“CRS:1”。客户不能将一个“CRS=CRS:1”的图层和另一个图层叠置。6.7.4 边框边框的值通过在特定的Layer CRS中使用两对坐标来指定被映射的地球的特定部分。第一对坐标指定了Layer

52、 CRS中的最小坐标，第二对坐标指定了Layer CRS中的最大坐标。尽管对于大多数带有向东和向北递增的坐标轴的CRSs而言，最大和最小坐标应该是感兴趣区域的左下角坐标和右上角坐标，但是在某些实例中，最大和最小值往往是其它点的坐标值，比如说，当使用地理坐标来描述极点上方的区域时，或者当Layer CRS的坐标轴并不是向东和向西递增时就是如此。每个坐标对中的坐标的排列顺序应当遵循图层坐标参照系的定义；x 对应于Layer CRS的第一个轴，y 对应于图层参照坐标系的第二个轴。这个顺序可能与地图坐标系（Map CS）的顺序，并不一致。边框的坐标值应当采用Layer CRS中定义的单位。注：使用两个

53、角点规定地图区域在理论上不是唯一可能的方法。其他可能性包括规定一个中心点和一条直径，或一个中心点和一个缩放等级或比例尺。使用映射（基于位置的服务）的某些服务可以发现基于中心点的公式更适当。本标准不打算排除内部或客户机交互使用其他地图区域定义的其他服务类型。对多数坐标参照系来说，角点和中心点方法之间的转换是一个简单的数学操作。这样，例如当从实现本标准的WMS请求一幅地图时，用户输入的中心点和半径可变换为边框的两个点。边框的值出现在下面的与WMS相关的一些实体里： 服务元数据中的元素（7.2.4.6.8）； GetMap请求中的BBOX参数（7.3.3.6）； GetFeatureInfo 请求中

54、地图请求部分的BBOX参数（7.4.3.3）。边框的范围一定不能为零。例1： 在CRS:84 Layer CRS中表示全球的Layer的元数据元素将被写成：在这个CRS中，请求一幅全球地图的BBOX参数将被写成BBOX=-180, -90, 180, 90。例2：在EPSG:4326 Layer CRS中表示全球的Layer的元数据元素将被写成：在这个CRS中，请求一幅全球的地图的BBOX参数将被写成：BBOX=-90, -180, 90, 180.6.7.5 垂直CRS有些地理信息可能要利用多个高度（例如，空气中不同高度的臭氧浓度）。一个WMS需要在它的服务元数据中声明可利用的高度信息，并且

55、GetMap操作要包括一个用于请求特定高度信息的可选参数。单个高程或深度值是一个由一维垂直CRS来指定其单位及纵坐标递增方向的数字。正如在附录C中规定的那样，高程可能是单个值，也可能是多个值的列表，或者是一段间隔，它出现的形式取决于它所在的上下文。服务器最多可以为每一图层说明一个垂直CRS。在本标准中，将水平CRS和垂直CRS看成互相独立的元数据元素和请求参数。对一幅指定高程的地图的请求应当包括高程值，但不包括垂直CRS标识符（与水平CRS相比较，它随同水平边框一起包含在请求参数中）。在提供高程信息时，服务器应当在它的服务元数据中设定一个默认值，如果服务器已经设定了一个默认值并且在客户的请求中

56、边框没有包括该值，那么服务器应当以默认的值响应客户的请求。允许使用两种类型的的垂直CRS，即：“label”和“URL”标识符： Label：该标识符包括一个命名空间前缀、一个冒号、一个数字或字符代码。基于1988年的北美垂直基准，B.6定义了一个可选的垂直CRS，其标识符是“CRS:88”。如果命名空间的前缀是“EPSG”，那么，垂直CRS是欧洲石油调查局的数据集定义的那些CRS之一。 URL：这个标识符是统一资源定位符的全称，它指向一个大家都能访问的包含CRS定义的文件，且与ISO 19111一致。如果高度是一个3-维CRS的垂直部分，垂直CRS的标识符应当是3-维CRS的标识符。6.7.

57、6 时间坐标系有些地理信息可能使用多个时间（例如，每小时的气象图）。网络地图服务可以在它的服务元数据中陈述可利用的时间，并且GetMap操作包括一个请求特定时间的参数。附录D规定了时间串的格式。根据上下文，时间值可以作为单个值、一列值或一个时间间隔出现，就像附录C中描述的一样。当提供时间信息时，服务器应在服务元数据中设定一个默认值。如果服务器已经设定了一个默认值并且在客户的请求中没有该值，那么服务器应当以默认值响应客户的请求。6.7.7 其他坐标系有些地理信息可能适合其他维（如，不同波段的卫星影像）。除了4个时-空维之外的其他维都被称为“样本维”。一个 WMS 可以在它的服务元数据中陈述可利用

58、的样本维，并且 GetMap 操作要包括一个请求维数值的机制。每个样本维应当有一个名称及一个或多个有效值。附录 C.3.3 中规定了样本维的说明及用法。6.8 请求参数规则6.8.1 参数排序和大小写参数名不区分大小写，但是参数值要区分大小写。在本标准里，参数名都以大写字母出现仅是为了印刷清晰，并非必须。请求中的参数可以按任何顺序进行指定。当请求参数的赋值发生冲突时，服务器的响应可能没有被明确定义。本标准不要求服务器确定应当使用客户发送冲突值中的哪一个。WMS 应该考虑不属于本标准中的额外请求参数，但就根据本标准产生的结果而言，WMS 不要求这些参数。6.8.2 参数列表由列表组成的参数（例如

59、，在WMS GetMap中的BBOX，LAYERS和STYLES）应当用逗号（“，”）作为列表中各个项之间的分隔符，不能使用另外的空格符来分隔各个列表项。如果参数值中包含了空格或逗号，应当使用URL编码规则（见6.3.2 和 IETF RFC 2396）进行换码。在某些列表中，个别实体可以为空，并且使用空字符串（“”）来表示。因此，正像一个首逗号或一个尾逗号一样，两个连续的逗号表明一个空的项。一个空列表（“”）是表示一个不包括任何项目的列表还是表示一个只包括一个空项的列表，这取决于它的上下文。6.9 通用请求参数6.9.1 版本（VERSION）参数VERSION详细指定了协议的版本号。版本号

60、格式和版本协商问题见6.2。6.9.2 请求（REQUEST）参数REQUEST指明了调用的是哪个服务操作，其值应当是服务器提供的各种操作名称之一。6.9.3 格式（FORMAT）参数FORMAT规定了一个对操作响应的输出格式。一个 WMS可以只实现某种操作类型可识别格式的子集。服务器应当在服务元数据中说明它所支持的格式，并且应当接受对其已说明的每种格式的服务请求。一个服务器可以有选择性地提供此前其它服务实例没有提供过的新格式，但应该认识到这并不意味着要求客户接受或处理这种未知的格式。如果一个请求包含了指定的服务器所不提供的格式，此时有两种情况：若该服务器已经定义了默认格式，那么该服务器将以默

61、认格式响应；若该服务器没有定义默认格式，则该服务器将抛出一个服务异常（采用代码“InvalidFormat”）。客户可以只接受某种操作类型已知格式的一个子集，如果客户和服务器不支持任何相互认可的格式，客户出于谨慎的考虑可能停止和那个服务器的通讯，或是寻找一个中间服务完成格式转换，或是允许用户选择其它处理方法（例如，保存到本地存储器或是转到辅助应用）。 在服务元数据和操作请求中表达的所有格式都要使用MIME类型。每个操作都具有一个该操作所支持格式的明晰的列表。有些格式可能被多个操来实现，于是根据需要重复写在每个操作的列表里。6.9.4 异常（EXCEPTIONS） 参数EXCEPTIONS规定了报告错误的格式（见6.11）。6.9.5 扩展的功能和操作WMS 允许可选的扩展功能（capabilities）和操作。当需要额外的功能性（functionality）或专门化（specialization）时，在一个信息团体内可以定义各种扩展。一般的客户不需要也不希望使用这些扩展。当需要时，应使用附录E的服务元数据模式中提供的抽象实例元素_