WMS网络地图服务规范.doc

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

2、的 HTTP 请求规则 .66.4 基本的 HTTP 响应规则 .76.5 数值和布尔值 .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（规范性附录）：G

3、B/T 7408 的网络地图服务专用标准 .56附录 E（规范性附录）：XML 模式 .58附录 F（规范性附录）：UML 模型 .75附录 G（资料性附录）：网络制图示例 .79附录 H（资料性附录）：XML 示例 .84参考书目 92iii前言本标准修改采用（MOD）国际标准化组织地理信息标准化委员会（ISO/TC 211）制定的 ISO 19128：2005(E) Geographic informationWeb map server interface，并作了如下改动：本标准的编写方法执行国家标准 GB/T 1.12000 标准化工作导则 第一部分：标准的结构和编写规则、GB/T 2

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

5、 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。 b)

6、表 B.6 使用 Xian 1980 经度-纬度定义 Layer CRS。c) 表 B.8 使用 国家黄海高程基准 1956 定义垂直 CRS。d) 表 B.9 使用 国家高程基准 1980 定义垂直 CRS。iv为此，原标准 6.7.3.2 第 1 自然段中“在附录 B 中， “CRS”命名空间的地理 CRS 被规定为 WGS84、NAD27 和 NAD83 基准。 ”改为“在附录 B 中， “CRS”命名空间的地理 CRS 被规定为 WGS84、NAD27 和 NAD83 基准，以及 CRS1954、CRS1980、CRS54 和 CRS85 基准。 为便于使用，在本标准的资料性附录 G

7、中增加了 3 个与相应国际标准条款 G1、G2和 G3 等同地位的条款 G4、G5 和 G6，作为应用该国际标准的另一组网络制图的示例。 删除了原文 7.2.4.6.14 第 2 自然段，因为与第 1 自然段的第 1 句话完全重复。本标准的附录 A、附录 B、附录 C、附录 D、附录 E 和附录 F 是规范性附录，附录 G和附录 H 是资料性附录。本标准由全国地理信息标准化委员会提出。本标准由全国地理信息标准化委员会归口。本标准起草单位：武汉大学测绘遥感信息高程国家重点实验室，国土资源部信息中心，武汉大学资源与环境学院，武汉吉奥公司。本标准主要起草人：龚健雅、杜道生、高文秀、邓跃进、贾文珏、陈

8、玉敏。本标准所替代的国际标准 ISO 19128（E ）于 2005 年 12 月 1 日首次发布。v引 言网络地图服务（Web Map Service，WMS）从地理信息动态产生具有地理空间位置数据的地图。本标准将由地理信息图示表达的“地图”定义为计算机屏幕上显示的数字图像文件。地图本身并不是数据。WMS产生的地图一般以图像格式提供，如PNG、GIF 或JGPE；或按SVG（Scalable Vector Graphics）或WebCGM（Web Computer Graphics Metafile）格式提供基于矢量的图形元素。本标准定义了三个操作：一个是返回服务级元数据；另一个是返回一幅地

9、图，其地理空间参数和维参数有明确定义；可选的第三个操作返回显示在地图上的某些具体要素的信息。通过使用标准的网络浏览器以统一资源定位符（Uniform Resources Locators，URL）的形式发出请求来调用网络地图服务的操作。URLs的内容取决于被请求的那些操作。特别是，当请求一幅地图时，URLs指出什么信息要显示在地图上、制图范围覆盖地球上的哪一部分、指定的空间参照系以及输出图像的宽度和高度。当利用同样的地理信息参数和输出范围（Boundary Box，BBOX ）产生两幅或多幅地图时，其结果可以准确地被叠加以产生复合地图。使用支持透明背景的图像格式（如GIF或PNG ）可以使下层

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

11、图层和样式。简单说，具有SLD能力的WMS能访问来自网络要素服务（WFS）的要素数据 7 ，并应用用户提供的清晰的样式化信息，以便产生一幅地图。1地理信息地图：网络服务器接口1 范围本标准规定了一个服务行为，即从地理信息动态制作具有地理空间参照的地图。它规定了从服务器获取地图所需要进行的各种操作，包括获取地图的描述信息、获取一幅地图以及查询地图上要素信息的操作等。本标准适用于图片格式地图的图示化再现，但不适用于获取要素本身的数据或者覆盖的数据值。2 一致性2.1 一致性的类和需求本标准定义了两种一致性的类：一种是用于基本的 WMS，另一种是用于可查询的WMS。每一种类都具有两个子类：一个用于客

12、户，另一个用于服务器。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 规范性引用文件下列文件中的条款通过本标准的引用成为本标准的条款。 凡是注日期的引用文件，其

13、随后所有的改动（不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新的版本适用于本标准。GB/T 7408-1994 数据元和交换格式 信息交换 日期和时间表示法GB/T 19710:2005 地理信息 元数据2ISO 19111:2007 地理信息 基于坐标的空间参照（ISO 19111, Geographic information Spatial referencing by coordinates）EPSG (2003.2), 欧洲石油调查局大地测量参数 Lott, R., Ravanas, B.

14、, 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 IETF RFC 2396 (1998.8), 统一资源标识符(Uniform Resource Identifiers, URI): 统用句法，Berners-Lee, T., Fi

15、elding, 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, 度量单位的统一编码, Schadow, G. and McDonald, C.J. (eds.), version 1.5 XML 1.0, 可扩展标记语言（XML ）1.0，World Wide Web

16、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 Mendelsohn, N., eds., available at 4 术语和定义本标准使用了下列术语和定义。4.1客户 client能从服务器调用操作的软件组件4.2 坐标参照系 c

17、oordinate reference system通过基准与现实世界相关联的坐标系ISO 191114.3 坐标系 coordinate system给点赋予坐标的数学规则集ISO 19111 4.4 地理信息 geographic information与地球上的位置直接或间接相关现象的信息ISO 1910134.5 接口 interface描述实体行为的命名操作集ISO 191194.6 图层 layer地理信息的基本单元，它可以作为一幅地图从服务器端请求得到4.7 地图 map适合于在计算机屏幕上显示的数字图像文件的地理信息的图示表达4.8 操作 operation转换和查询的规范，按

18、照这个规范对象可以被调用执行ISO 191194.9 图示表达 portrayal人类对信息的表示ISO 191174.10 请求 request通过客户对操作的调用4.11 响应 response由服务器端返回给客户的一个操作结果4.12 服务器 server服务的特定实体（instance）4.13 服务 service 实体通过接口提供的功能性的可区分部分 ISO 142524.14 服务元数据 service metadata描述服务器上可用的操作和地理信息的元数据45 缩略语CDATA XML字符数据（ XML Character Data）CRS 坐标参照系（Coordinate

19、Reference System）CS 坐标系（Coordinate System）DCP 分布式计算平台（Distributed Computing Platfom）DTD 文件类型定义（Document Type Definition）EPSG 欧洲石油调查局（European Petroleum Survey Group）GIF 图形交换格式（Graphics Interchange Format）GIS 地理信息系统（Geographic Information System）HTTP 超文本传输协议（Hypertext Transfer Protocol）IANA 国际因特网地址分配

20、委员会（Internet Assigned Numbers Authority）IERS 国际地球自转服务局（International Earth Rotation service）IETF 因特网工程任务组（Internet Engineering Task Force）ITRF 国际陆地参考框架（Internatioanl Terrestrial Reference Frame）ITRS IERS陆地参照系（ IERS Terrestrial Reference System）JPEG 联合图像专家组（Joint Photographic Experts Group）MIME 多用途因特

21、网邮件扩充协议（Multipurpose Internet Mail Extensions）NAD 北美基准（North American Datum）OGC 开放式地理空间联盟（Open Geospatial Consortium）名称已改！PNG 可移植的网络图像文件（Portable Network Graphics）RFC 征求意见（Request for Comments）SVG 可缩放的矢量图形（Scalable Vector Graphics）UCUM 度量单位统一代码（Unified Code for Units of Measure）URL 统一资源定位符（Uniform R

22、esource 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 概述本节规定了网络地图服务器行为的某些方面，这些方面独立于特定操作或者是一些操5作通用的部分。6.2 版本的编号和协商6

23、.2.1 版本号的形式和值WMS定义一个协议版本号。该版本号适用于XML模式和本标准规定的请求编码。版本号包括三个正整数，它们用小数点分开，以“x.y.z”的形式出现，数字 “y”和“z”不超过99。本标准的各个实现均使用值“1.3.0”作为协议版本号。6.2.2 版本号的变化协议版本号将随着本标准每个版本的变化而改变。版本号应当单调增加，并由三个用小数点分隔的正整数组成，其中，第一个整数最为重要。在号码序列上可以出现中断。有些版本号表示草案的版本。服务器及其客户不需要支持所有已定义的版本，但应该遵守以下的协商规则。6.2.3 在请求和服务元数据中的形式版本号至少应出现在两个地方：在服务元数据

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

25、以它支持的最高版本进行响应。在响应包含一个服务器实现的版本号的GetCapabilities请求时，服务器应当按照请求版本进行响应。如果服务器不支持请求的版本号，服务器应当以输出它支持的版本来响应，此版本按照如下规则进行确定： 如果被请求的版本是服务器未知的版本且高于服务器所支持的最低版本，服务器将发送它所支持的低于被请求版本的最高版本。 如果客户请求的版本低于服务器已知的任何版本，那么服务器将发送它所支持的最低版本。 如果客户不支持服务器发送的版本，它可以停止与服务器交流，或是发送一个新的请求，新请求包含一个客户所支持的不同的版本号。6重复这个过程，直至找到一个相互认可的版本，或者直至客户确

26、定不再或者不能和服务器交流为止。例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）上的实现，该分布式计算平台由支持超文

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

28、不同。对GET方法的支持是必选的，对POST的支持是可选的。6.3.2 HTTP GET URL中的保留字符URL规范IETF RFC 2396保留了一些特定的字符并赋予它们特定的含义，并要求在可能与其定义的用途相冲突时避免使用它们。本标准明确地保留了这些字符中的几个，用于WMS请求中的查询部分。当字符“?”、“&” 、“ =”、“,”和“+”担当表1中所定义的一个角色时，它们应当逐个地出现在URL中。当这些字符出现在其它的地方时（例如，在参数值中），它们将按照 IETF RFC 2396 所定义的那样进行编码。服务器应准备以该方式对遗漏的字符进行解码，并将“+ ”字符作为空格进行解码。表1

29、WMS请求中查询语句的保留字符字 符 预 定 的 用 法? 表明查询语句开始的分隔符& 查询语句参数之间的分隔符= 参数名称和参数值之间的分隔符, 参数表中所列的多个参数值之间的分隔符（如在GetMap请求中的参数：BBOX（边框） ，LAYERS（图层） 和STYLES（样式） ）+ 空格字符的速记表示76.3.3 HTTP GET（HTTP的“GET”方法）WMS应支持HTTP协议的“GET” 方法IETF RFC 2616。为 HTTP GET 请求而扩展的在线资源URL事实上只是一个 URL 的前缀，为了构成一个有效的操作请求在前缀上需增加参数。根据IETF RFC 2396，一个 U

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

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

32、t/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 消息主体中向它发送的请求参数是有效的。为了给操作请求建立一个有效的目标，WMS不允许在该URL

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

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

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

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

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

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

39、相关排列的同时，显示的大小可能会改变。图形元素格式包括可缩放矢量图形（SVG；MIME 类型“image/svg+xml”） ，或者网络计算机图形元文件（WebCGM； MIME 类型“image/cgm”；版本= 4 ；ProfileId= WebCGM）等格式 。注 1 ： SVG 使用 XML 表达，因而被认为是文本输出格式，但就本标准的目的而言， SGV 被看作是一种地图格式。注：WebCGM 是 ISO/IEC 8632 的专用标准。一台服务器可能提供多种地图格式。它所提供的格式在服务元数据的格式（Format）元素中被列举出来。本标准不要求使用特定的格式。但是，对于描述矢量要素的地

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

41、系、时间坐标系或其它坐标系。106.7.2 Map CSMap CS 是为WMS制作的地图所提供的坐标参照系。一幅WMS地图是一组显示在计算机屏幕上的矩形像元格网（或者是一个能以这样的形式被显示的数字化文件）。Map CS 有一个水平轴，记为 ；一个垂直轴，记为 。 和 应当是正整数。原点（ ， ）（0，0）是在地图的左上角； 向右递增， 向下递增。Map CS 用附录B.2中ISO 19111术语的定义，用“CRS:1”标记来识别。通常，Map CS 的坐标轴的朝向是这样定义的：即 轴与Layer CRS自东向西的轴平行并且向东递增， 轴与Layer CRS的自北向南的轴平行并且向南递增。在

42、某些情况下，这种定向可能并不存在，比如南极上的正射投影。但是只要这种投影变换存在，那么变换所遵循的惯例便是：无论在什么情况下，东指向地图坐标系的右边，北指向Map CS的上边。GetMap请求（见7.3.3.8）中使用的WIDTH（宽度）参数和HEIGHT (高度)参数以及包括在GetFeatureInfo请求中对应于 和 的参数如下： WIDTH 指的是沿 轴的以像元为单位的地图图像的大小（也就是说，WIDTH-1是 的最大值）； HEIGHT 指的是沿 j 轴的以像元为单位的地图图像的大小（也就是说，HEIGHT-1是 的最大值）；在 GetFeatureInfo 请求（7.4.3.7）中

43、使用的参数 和 j 分别指的是沿着 Map CS 的 i 轴和 j 轴的整型值。6.7.3 图层坐标参照系（Layer CRS ）6.7.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。只有所有被选择

44、的服务器都支持了一种通用的CRS，来自多台服务器的地图才可能被叠置。本标准不要求支持任何特定的 Layer CRS。相反，该标准在该条和附录 B 中，只阐述了如何定义各种 CRS 并讨论了几个可选的 Layer CRS。 地图提供者可能支持对其地理位置或信息团体最有用和最适合的 CRS。为了充分发挥服务器之间的互操作性，提供者还应通过地心坐标系，如 “CRS:84”（见 6.7.3.2） 、“EPSG:4326”（见 6.7.3.3）或其他以 ITRF 为基础的各种系统来支持地理坐标。11每个 Layer CRS 都有一个字符串作为标识符。 Layer CRS 标识符允许“label” 和“U

45、RL” 两种类型： Label: 这个标识符包括一个 namespace（命名空间）前缀、一个冒号、一串数字或字符代码，并且在某些实例中还有一个逗号，其后跟随附加参数。正如下面的讨论，本标准定义了三种命名空间：CRS ，EPSG 和 AUTO2。 URL: 这个标识符是一个完全合法的 URL，它指向一个大家都能访问的包含 CRS定义的文件，且与 ISO 19111 一致。Layer CRS 有两个轴，分别为 x 和 y 。按 CRS 定义，x 轴是第一个轴，y 轴是第二个轴。x 轴朝向是否自东向西，y 轴朝向是否由南向北，这取决于特定的 CRS。当将地理信息由 Layer CRS 映射到 Ma

46、p CS 时，WMS 的图示表达操作应当说明 Layer CRS 中坐标轴的排列次序、坐标系的原点以及坐标轴方向。坐标应当按 CRS 定义的顺序排列，并映射到 Map CS 对应的 i 轴和 j 轴。在进行投影变换操作时，需要交换坐标轴的次序。许多投影坐标参照系除了有向东和向北两个坐标方向外，还有一个坐标轴及坐标顺序问题。例如，在芬兰使用的统一坐标系（EPSG:2393）中将向北列在向东之前。EPSG 地理坐标参照系遵循 ISO 6709 ，它总是将纬度列在经度之前。大多数坐标参照系用两个坐标轴进行定向，一个指向东（E）的轴为正，另一个指向北（N）的轴为正。这些坐标系的坐标轴很容易被分别映射到

47、边框的 i 轴和 j 轴。但是，有些 CRS 的坐标在其他方向上递增。例如，南非使用的 Hartebeesthoek94 / Lo25 系统（EPSG:2051）中的坐标向西和向南递增。对有效边框的测试应当能识别和解释 CRS 坐标轴的正方向。在地理 CRS 中，纬度应当在 -90，90 度之间取值，经度应当在 -180，180 度之间取值或者是在 CRS 定义的其他单位的等效值中取值。 7.3.5 介绍的是关于从地理 CRS 到Map CS 转换的图层坐标参照系的投影变换。当 CRS 代码指定的 2-维地理 CRS 的坐标轴使用其他单位而不是使用度为单位，或者使用度但不是十进制的度表示时，这

48、种表示应当转换成十进制度的表示。注：将经度排在纬度之前的坐标轴排放次序的地理 CRS 不同于历史惯例。国际航空和航海部门的用户可能期望纬度在经度之前的排列顺序。这种不同的坐标排列出于安全的目的，特别是在处理紧急事件时作出响应。尽管本标准没有指定用户界面，但是 WMS 的用户界面开发者都应当注意纬度和经度的引用顺序，例如，用户的一个边框输入或鼠标坐标的读取都应当将纬度显示在经度前。6.7.3.2 适用于 CRS 的 CRS 命名空间“CRS”的命名空间的前缀参考本标准附录 B 中定义的坐标参照系。这些定义采用了 ISO 19111 规定的格式。在附录 B 中， “CRS”命名空间的地理 CRS

49、被规定为 WGS84、NAD2712和 NAD83 基准，以及 CRS1954、CRS1980、CRS54 和 CRS85 基准。一个“CRS”的 CRS 标签由“CRS”前缀、冒号（：）和数字或字符串编码组成。例： “CRS:84”指的是 WGS 84 以十进制度表示的经度值和纬度值，并且经度范围在-180 度和+180 度之间，纬度范围在90 度和90 度之间。6.7.3.3 适用于 CRS 的 EPSG 命名空间“EPSG”命名空间前缀参考了欧洲石油调查局（EPSG ）大地测量数据集，EPSG 为许多通用的坐标参照系定义了数字标识符（EPSG的“CRS代码 ”对应于EPSG 数据集中的“COORD_REF_SYS_CODE”字段） 。对大地测量、地图投影和坐标参照系数据的定义与每个CRS标识符相关。一个“EPSG”的CRS标签由“EPSG”前缀、冒号和一个数字代码组成。例：EPSG:4236指的是 WGS 84地理纬度