OGC开放式地理信息系统联盟

《OGC开放式地理信息系统联盟》由会员分享，可在线阅读，更多相关《OGC开放式地理信息系统联盟（93页珍藏版）》请在装配图网上搜索。

1、开放式地理信息系统联盟（OGC）日期:2002-04-04本文档在 OpenGIS 计划中的编号: OGC 02-024版本号: 0.7分类: OpenGIS OGC 互操作计划报告 工程规范撰写人:John D. EvansOWS1网络覆盖服务（WCS） 版权申明 本OGC文档是一份草案，版权属于OGC，OpenGIS互操作计划的参与者可以不经OGC事先许可使用任何形式的草案复制品。但是，事先没有OGC的书面许可，不得因任何其它目的、以任何形式复制、存储或传播本文档或其摘要。警告 本文档并非OGC的标准或规范，它阐述了在OGC互操作计划的第一步中讨论的技术问题。阐述本文献的内容是为了促使整个

2、地理空间信息行业讨论这个主题；而不是将其作为任何一种可采用的规范。本文献不代表OGC或OGC技术委员会的正式立场。它可能在未经告示的情况下进行修改，并且不能作为的标准或规范进行引用。不过，文献中的讨论能很好地产生实施规范的定义。本文档的收件人需随同对本文档的评论一起，递交一份所知道的相关专利权的通知及证明文件。文档分类：OpenGIS互操作计划报告工程规范二级分类：适用采纳文档级别：定稿文档语言：英语目录 前言。 提交机构。 文档投稿者联系方式。 修订历史。 抽象规范的改进。序。导言。规定范围。致性。标准化参考资料。术语和定义。约定。符号（缩写的术语）。符号。基本服务要素。版本编号和协调。版本

3、号格式。版本的更改。在请求及服务性元数据上的显示方式。5版本号的协调。通用的请求规则。6关键值对编码。编码。通用的响应规则。服务异常。97GATCAPABILITIES操作（必需的）。91 GATCAPABILITIES请求。10711关键值对编码。10712编码。10 72 GATCAPABILITIES响应：CAPABILITIES XML文档。10721-CoverageLayerList顶级元素。11722-CoverageLayer特性（共用）。12723-域说明。16724-范围说明。2473异常情况。308-GETCOVERAGE操作（必选）。3181 ETCOVERAGE请求。

4、31811关键值对编码。31812编码。36 82-GETCOVERAGE响应。38821覆盖编码。39822-异常。39823GetCoverage的近似响应。399-DESCRIBECOVERAGELAYER操作（可选）。3991-DESCRIBECOVERAGELAYER请求。40911关键值对编码。40912编码。4092-DESCRIBECOVERAGELAYER响应。4110-参考书目。41附录A（标准）XML模式。42附录D（标准）一致性测试。89参考书目。90i. 前言ii提交机构本互操作计划报告工程规范由下列机构提交给OGC互操作计划。iii文档投稿者联系方式有关本文档的问题

5、请与编者或撰稿人联系。联系人公司（/组织）地址电话号码EMAILJohn D. EvansGST, Inc.6411 Ivy Ln. Ste 300Greenbelt, MD 20770USA(301) 474-9696evansStephane FellahPCI Geomatics490 St. Joseph Blvd., Suite 400Hull, Quebec J8Y 3Y7CANADA(819) 770-0022 Ext. 223fellahJeff LansingPolexis, Inc.jeffiv-修订历史日期版本作者修改的段落说明2001-11-170.5John Evan

6、s最初的DIPR版本2001-11-290.5Jeff Lansing添加了DescribeCoverageType的内容2001-11-290.5Stephane Fellah 修订格式和插值法定义; 许多独立存在的实体的注释2002-01-310.5.1John Evans修订& 校正; XML 模式2002-02-200.6Stephane Fellah覆盖层描述和XML请求的新模式2002-04-040.7John Evans确定并理顺了0.6版中的模式; 增加了复杂观测、文件和综合.V-OpenGIS抽象规范的改进OpenGIS抽象规范不需要改进以适应本文档的技术内容。序OGC01-

7、018r3 由以下部分构成：网络覆盖服务报告。.序言网络覆盖服务（WCS）支持网上地理空间数据的相互交换，此时地理空间数据作为包含地理位置值或特征的“覆盖”。不同于网络地图服务（OGC文档#01-021r2），它通过筛选和描绘空间数据返回静态的地图（服务器以图片形式表示）；网络覆盖服务在客户端的再现、多值覆盖、以及输入科学模型和不仅仅是阅读器的客户机需要提供对原始的（未处理的）地理空间信息的访问。网络覆盖服务由三种操作组成：GetCapabilities，GetCoverage和DescribeCoverageType。GetCapabilities操作返回一个描述服务和客户机能从中获取覆盖的

8、数据集合的XML文档。通常，客户机运行GetCapabilities操作并贮存结果，是为了在整个会话过程中，或是在多次会话过程中重复使用它。一般而言，网络覆盖服务中的GetCoverage操作是在GetCapabilities确定什么样的查询可以执行、什么样的数据能够获取之后执行的。它返回地理位置的值或特征，这些值或特征被捆扎在通用的覆盖格式中。除了几个扩展支持覆盖检索而不支持静态地图的检索以外，GetCoverage的句法和语义与WMS中GetMap的请求类似。OWS1 网络覆盖服务（WCS）1规定范围本规范文档阐述WCS如何实现在万维网上描述、请求和传输多尺度覆盖数据。网络覆盖服务的这一版

9、本着重于“简单的” 覆盖（定义为一些规则的、直角坐标网或棋盘形镶嵌的空间），它还预期了在OpenGIS抽象规范中定义的其它覆盖类型（专题6，“覆盖类型”，OGC文档#99-106）。2-一致性使用附录A（标准化的）中列出的相关测试可以检查OGC互操作程序报告的一致性和互操作测试。测试的框架、概念、方法及得出一致性结论的标准，在ISO19105地理信息一致性和测试中都做了详细说明。3-标准化参考资料文中引用的下列标准中，包含了构成本规范的条款。过时的参考资料在其后的修正、再版或任何出版物中都不再使用。鼓励就OGCnnn部分达成一致的各方对下列国际标准的最新版本中的内容在本规范中应用的可能性进行评

10、价。未过时的参考资料在最新的标准化文献中作为参考使用。OGC01021r2:2001，网络地图服务v. 1.1ISO19123,地理信息覆盖几何图形和功能抽象规范专题0：综述，OGC文档99-100r1成功的OGC接口规范准则，OGC文档00-014r14术语和定义上面的参考资料中的术语和定义在本文献中的含义与下列的术语相同。操作对象需要执行的转换或查询的规范。OGC AS 12接口由体现实体行为特性的操作组成的具有给定名称的集合。服务实体通过接口提供的明确的一部分功能。OGC AS 12服务实例服务器服务的实际实现。客户端可以从服务器上调用操作的软件组件。请求客户端对操作的调用。响应服务器返

11、回给客户端的操作结果。地图地理数据的图示表示。功能 XML 服务级元数据，用以描述服务实例中的操作和内容。5 约定511符号（缩写的术语）下列是本文献中使用的符号和缩写术语。API应用编程接口DCP分布式计算平台ISO国际标准化组织OGCOpen GIS 联盟UML统一建模语言XML可扩展标记语言1D一维2D二维3D三维512符号本文献中出现的图表使用统一建模语言（UML）静态结构图表。下面的图表描述了本文献中使用的UML符号。图 1 - UML 符号图中使用了UML类的下面三种模板a）对由具有这个接口的对象支持的一组操作的定义。一个接口类不包含任何属性。b）一组相异（独立存在并可能产生侧面影

12、响）值的描述符。数据类型类没有操作，其主要目的是保存信息。c） 是用串值表示潜在值列表的一个灵活的枚举。本文献使用了以下的标准数据类型：a）字符串字符序列b）整型整数c）双精度型双精度浮点数d）浮点型单精度浮点数6基本服务要素这一部分阐述网络覆盖服务器的行为概要（更一般的说法是OGC网络服务行为）它独立于具体的操作，或是与几个操作或接口共同行为。61版本编号和协调。611版本号格式已出版的规范的版本号包括三个型为“x.y.z”的正整数，彼此之间用小数点隔开，“y”和“z”位上的数字不超过99，各OWS规范独立编号。612版本的更改一个具体的规范版本号须随再版而改变。版本号必须单调增加，且仅由三

13、个彼此间用小数点分开的整数组成，其中第一个整数的意义最重大。这些数字序列间存在差距。有些数字可以表示实验性或临时版本，服务实例和客户端不需要支持所有确定的版本，但必须遵循下述的协调规则。613在请求和服务元数据上的显示方式至少要在两个地方使用版本号，一是在CapabilitiesXML描述一服务时，另一是在客户端请求该服务的参数列表中。在具体服务实例的客户端请求中使用的版本号必须与该实例申明支持的版本号相一致（如下所述的协调情况除外）。一个服务实例可支持几个版本，客户端可以根据协调规则确定这些版本号。614版本号协调OWS客户端可以与服务实例协调，确定一个彼此都适宜的规范版本。协调是由GetC

14、apabilities操作依据下述规则来完成的。所有CapabilitiesXML都必须包括一个协议版本号。为了响应包括一个版本号的GetCapabilities请求，OGC网络服务必须响应与规范的该版本相一致的输出，假如被请求的版本在服务器上不能执行，则必须协调出一个彼此适宜的版本。如果请求中没有指定版本号，服务器必须响应它所支持的最高版本并据此标注响应。版本号协调过程如下：1如果服务器执行请求的版本号，服务器必须发送该版本。2如果服务器不执行请求的版本，服务器必须发送低于请求版本的最高版本。 3如果客户端请求的版本比服务器执行的任何版本都要低，服务器必须发送它所执行的最低版本。4如果客户端

15、不理解服务器发送的新版本号，它可能会中断与服务器的通信，或者发送带有客户端理解的、比服务器发送的低的新版本号的新请求（如果服务器响应较低版本）。5如果服务器响应较高版本（因为请求的版本比服务器执行的任何版本都要低），但是客户端不理解建议的较高版本，客户端可发送比服务器发送的高的版本号的新请求。这一过程会重复进行，直到找到一个互相都能理解的版本，或是客户端确定不再与特定服务器通信。 例1：服务器支持版本1，2，4，5，8；客户端支持版本1，3，4，6，7；客户端请求版本7，服务器响应版本5；客户端请求版本4，服务器响应客户端支持的版本4，至此协调成功结束。例2：服务器支持版本4，5，8；客户端支

16、持版本3；客户端请求版本3，服务器响应版本4，客户端不支持版本4或其它更高的版本，因此协调失败，客户端终止与服务器的交流。62通用HTTP请求规则目前，OGC网络服务明确支持的、唯一的分布式计算平台(DCP)是万维网本身，更具体地说是执行超文本传输协议(HTTP)6的因特网主机。因此，由服务实例支持的各操作的在线资源是HTTP的统一资源定位器(URL).。对于各操作而言，URL可能不同，也可能相同，这取决于服务供应商的判断力。各URL的确定须遵循6中的描述，或者依据具体实现来确定，只有服务请求本身的参数是由OGC网络服务规范强制规定的。HTTP支持GET和POST两种请求模式。一个特定的OGC

17、网络服务类型可以只定义其中的一种或是两种模式都定义，并由具体的服务实例提供上述模式，不同的实例在线资源URL的用法不同。事实上，供HTTP的GET请求使用的在线资源URL只有一个URL前缀，为了构造有效的操作请求，还要在这个前缀后添加必要的参数。URL前缀定义为不透明的字符串，它包括协议，主机名，可选的端口数，路径，问号?，还可以增加一个或多个以&符号结尾的具体服务器参数。前缀唯一地标识具体的服务实例。对于HTTP 的GET，URL前缀必须以一个?(在没有附加的具体服务器参数的情况下)或&结尾。然而，在实践中,为了构造一个有效的请求URL，客户端在添加本规范中定义的操作参数之前，应该准备添加一

18、个?或&结尾。供HTTP的POST请求使用的在线资源URL是一个完整而有效的URL，客户端通过POST文档向它传输经过编码的请求。在构建请求操作的有效目标时，WCS服务器不必在URL上添加另外的参数。621关键值对编码使用关键值对编码时,客户程序将必需的请求参数编写为关键字=值形式的关键字/值对，并经由HTTP GET或HTTP POST传输到服务器。对于HTTP GET，客户端为选定操作的在线资源URL的前缀后添加用&，用来分隔关键字/值对；形成的URL必须符合HTTP通用网关接口（CGI）标准7，CGI要求查询参数序列前面必须有?，每两个查询参数间必须用&来分隔；正象所有CGI的应用一样，

19、查询URL的编码8必须能够保护特殊的字符。表1总结了HTTP GET操作请求URL的组成部分。表1 通用的OGC网络服务请求URL构件说明http:/host:port/path?name=value&服务操作的URL前缀， 表示出现次数为0或1；表示出现次数为0或更多；前缀完全由服务供应商来确定。Name=value&OGC网络服务定义的一个或多个标准化请求参数名称/值对，各个操作中必选的和可选的参数实际列表由相应的OWS规范确定。使用HTTP GET方法编码为关键值对的请求可以作为书签存储，也可以嵌入为超链接, 还可以经由XML文档中的Xlink被引用。6211参数顺序和大小写参数名不须区

20、分大小写，但参数值必须区分大小写。本文献中参数名特别用大写仅是为了印刷上的清晰，不是必需的。请求中的参数可以按任意次序指定。OGC网络服务必须做好遇到不属于这一规范的参数的准备，在由规范产生的结果方面,OGC网络服务须忽视这样的参数。6212参数列表由列表组成的参数须使用逗号(,)作为列表中各数据项之间的分隔符。例如，参数=数据项1, 数据项2, 数据项3。多重列表可通过将各列表封入圆括弧(,)中作为一个参数的值来确定。例如，参数=(数据项1a, 数据项1b, 数据项1c)( 数据项2a,数据项2b,数据项2c).622编码在实际实施的测试里，还没有完全解决关于是否使用SOAP19问题，因而，

21、在此暂时阐述两种可供选择的观点。为了向使用HTTP GET或(更常用的是)HTTP POST的服务器传输请求，客户端也可能将请求用XML编码。XML请求必须与相应的可选操作模式相一致，而且客户端序须将请求发送给在服务器CapabilitiesXML文件中针对该操作列出的URL。为了支持SOAP消息传送，客户机程序只需如下所示，将XML文档封入SOAP信封里： request document here 客户端需在XML请求前面加上下面定义的适当的HTTP请求头信息（与其它头信息一起在8中确定） 内容-类型: text/xml; charset=utf-8-或者?-内容-类型: applicat

22、ion /vnd.ogc.request+xml(这里的request是一个已定义的操作名) 内容-长度: nnnn(这里的nnnn是请求文档的字节数)SOAP消息传送需要下列头信息: 内容-类型：text/xml; charset=utf-8 内容-长度: nnnn这里的nnnn 是包括SOAP信封在内的文档字节数 SOAPAction: URL (可以为NULL)63通用HTTP响应规则当接收到一个有效请求时，服务必须根据适当规范中的细节返回严格对应于该请求的响应。只有在版本协调的情况下（上面所描述的），服务器才可能提供不一样的结果。当接收到一个无效请求时，服务程序必须发布一个6.4部分所

23、阐述的服务异常。注意:作为一个实际问题，在3W环境下，客户端应能够接收有效结果，或什么也不接收，或任何其它的结果。这是因为客户端本身可能产生一个不相容的请求，这个请求通过OGC网络服务程序以外的其它服务程序不经意地触发了的一个应答；也可能是因为服务程序本身是不相容的，等等。适当的多用途网际邮件扩充 (MIME)类型9必须伴随响应目标。SOAP请求返回一个由多个部分组成MIME文档，该文档是依据W3C中带有附件20条文的SOAP消息格式化的。第一部分是一个SOAP消息；第二部分包括实际的服务器应答(图象，覆盖，等等)。换句话说，该应答可能是一个包含来自服务器实际响应的URL的SOAP消息。其它的

24、HTTP实体的头信息应当尽可能附带适当的响应对象。特别地，有关终止和上次修改的头信息提供了关于存储的重要信息；客户端通过使用内容-长度了解数据传输完成时间并为结果有效地分配空间；为了适当地解释结果，内容编码或内容传送编码可能是必需的。64服务异常根据使用的分布式计算平台(DCP)的规则，在接收到无效请求时，服务器程序可发布在该DCP中为有效类型的异常。例如，在HTTP的DCP中，假如URL前缀是错误的，服务器程序将返回一个HTTP 404状态码。在接收到无效请求时，服务器程序必须发布一条服务异常XML消息，向客户应用程序和用户解释请求无效的原因。依据附录A.3中的服务异常DTD，服务异常XML

25、必须是有效的。在HTTP环境下，返回的XML的MIME类型必须为application/vnd.ogc.se_xml。包含的具体错误信息可以是纯文本块，也可以被包含在字符数据(CDATA)块段中，形成类似XML的包含角括弧()的文本。如同附录A.4服务异常XML中的例子所示。服务异常可包括附录A.3中指明的异常代码。除了那些已指定的含义外，服务器不能使用这些代码表示其它含义。客户端可以使用这些代码自动响应服务异常。 7GetCapabilities操作（必需的）网络覆盖服务器需说明其Capabilities。本节定义了一个XML文件结构，用于传送服务程序本身的一般信息，和可以从中请求覆盖的有效

26、数据集的具体信息。71GetCapabilities请求711关键值对编码一般格式的GetCapabilities请求在基本服务原理一节已定义，下表2是对其的总结。表 2 GetCapabilities请求URL的参数请求参数必需的/可选的说明REQUEST=GetCapabilitiesR该请求的名称VERSION=versionO该请求的版本SERVICE=WCSR服务程序类型 在生成该请求时，考虑到OGC网络服务器还可提供WCS以外的其它服务，必须特别说明客户程序查找的是关于WCS服务器的信息。因而，请求的SERVICE参数必须有表2.中所示的值WCS。712XML编码在OWS Serv

27、ice Metadata XML IPR 中介绍了GetCapabilities请求的XML编码的XML模式。例如，客户端可用XML编写一个GetCapabilities的请求如下：/OGC_Capabilities/OperationSignatures顶级XML元素GetCapabilities有两个属性：version 和service，它们分别表示协议的版本号和服务器地址。GetCapabilities元素有一个可选的子元素Section，它表示返回CapabilitiesXML文档的哪个部分：ServiceOffering，OperationSignatures，还是ContentM

28、etadata元素。如果没有提供这个子元素，那么服务器必须返回整个的CapabilitiesXML文档。72GetCapabilities应答：CapabilitiesXML文档对GetCapabilities请求的应答是与OWS Service Metadata XML IPR中给出的模式相一致的CapabilitiesXML文档，它由图3所示的四个主要部分组成。图2 - OGC_Capabilities 顶级元素OWS Service Metadata XML IPR中阐述了这四个部分的任务，以及前两个部分(ServiceMetadata和OperationSignatures)的结构。O

29、perationSignatures是WSDL服务的描述，它引入几个模式去定义请求（关键值对，XML，SOAP）和应答(XML文档，异常，或覆盖数据).的句法。下面的部分详细地阐述了这些模式。CapabilitiesXML文件的第三部分(ContentMetadata)是具体针对WCS的，它引入了接下来要阐述的CoverageLayerList模式。721CoverageLayerList顶级元素针对WCS的CapabilitiesXML文档中ContentMetadata部分的顶层是CoverageLayerList元素，它按任意次序排列覆盖层。图3显示了该CoverageLayerList

30、元素的结构。图2 CoverageLayerList(ContentMetadata下的顶层)有5种不同的覆盖层，但它们都具有下面所列的几个共有特性。722CoverageLayer特性（共有）在CapabilitiesXML应答中，网络覆盖服务器宣称它能从各数据集中挑选并返回某些覆盖(即时空位置的值或属性)。每一个可以提供覆盖的逻辑的集合称为一个覆盖层。可获取的各种覆盖层共享几个共同的元素，这些元素组成了AbstractCoverageLayerType(图4)。图3 抽象CoverageLayerType(AbstractCoverageLayerType本身扩展了一般的LayerType

31、，这意味着它可被网络地图服务（Web Map Service）和网络要素服务（Web Feature Service）共享。)下面部分阐述AbstractCoverageLayerType的各子元素这些子元素是各种覆盖层都具备的。7221LayerIDLayerID是一个不可或缺唯一的标识符(不能用于任何其它的覆盖层)。进行GetCoverage或DescribeCoverage操作时，客户端通过在LAYERS参数中(针对以关键值对表示的请求)，或在LayerID元素中(针对XML请求)使用LayerID值，从该覆盖层(或是覆盖层描述)中请求覆盖数据。7222TitleTitle元素不可缺少，

32、它包含一个为了在菜单中表示的人们可读取的字符串。7223Abstract和KeywordListAbstract和KeywordList元素是可选的，但推荐使用。Abstract是图层的一种叙述式描述， KeywordList包括类目检索中用于辅助搜索的关键字。7224MetadataURLMetadataURL元素是可选的，但推荐使用，它用于访问某一个特定层下数据的详细、标准的元数据。type属性指出了元数据所遵循的标准。目前定义了两种类型：TC211 = ISO TC211 19115；FGDC = FGDC Content Standard for Digital Geospatial

33、Metadata（数字地理空间元数据FGDC内容标准）。7225LatLonBoundingBox必选的LatLonBoundingBox元素具有按经纬度十进制度数显示封闭矩形边界的属性。地图服务器支持无论什么样SRS的覆盖请求和应答，都必须提供LatLonBoundingBox。但是，假如EPSG:4326 (WGS84 地理坐标)不是一个被支持的请求SRS，那LatLonBoundingBox可能是近似的，其主要目的是为基于地理坐标检索提供入口。7226空间参考系（SRS）：请求参考系，应答参考系和本身参考系对于各覆盖层，CapabilitiesXML的描述指定了：(i)数据本身的空间参考

34、系（SRS）；(ii)在接收到的GetCoverage请求中可以理解的各种SRS列表；(iii)在对GetCoverage请求进行响应时生成的覆盖中可以出现的各种SRS列表。72261SRS每个CoverageLayer必须具有一个或多个SRS元素，或是具有既是查询SRS（QuerySRS）又是应答SRS（ResponseSRS）的元素(该元素包括一个或多个SRS元素)。服务器可能分别详细列出查询与应答的SRS，也可能仅仅通告可以同时出现在接的收请求中和在传送覆盖应答中的各种SRS。SRS元素的内容可能是在网络地图服务实现规范中定义的EPSG或AUTO坐标系之一；也可能是未定义的(“OGC:n

35、one”)；或者是嵌入式的“扫描条带”参考系(“OGC:swath”)，客户端根据控制点或传感器元数据重建地面坐标。 72262QuerySRSQuerySRS元素定义了对该覆盖层发出GetCoverage请求时可以采用的SRS，而且，其中的一个坐标系必须是该覆盖层本身的SRS。 在请求中的特殊SRS代码如“OGC:none”或“OGC:swath”表示根据层的像素行/列坐标系(针对图象)或层的内部/局部坐标系(针对非栅格数据)来定义子集。72263ResponseSRSResponseSRS元素定义了覆盖在响应GetCoverage请求时可以采用的坐标系，且其中的一个坐标系应是该层的本地SR

36、S。当采用特殊SRS代码“OGC:none”或“OGC:swath”提供覆盖服务时，表示该层采用的是像素行/列坐标系(针对图象)或它的内部/局部坐标系(针对非栅格数据)。以SRS“OGC:swath”代码响应的覆盖可嵌入传感器模型或控制点信息，从而使胖客户端确定返回覆盖的地理坐标系。72264NativeSRS可选的NativeSRS元素确定覆盖层的本地SRS(随着BoundingBox中本地分辨率的确定，它使客户端能更便捷地访问原始的覆盖的值。)。7227BoundingBox各个层都有一个与其NativeSRS相对应地的BoundingBox元素，也可能对应于QuerySRS中列出的每一个

37、SRS，各层都有（或继承了）一个边界框元素。BoundingBox的属性指出了在指定的SRS单元中层的有效数据的界限。属性resx, resy, resz, rest指出了在BoundingBox 的SRS里数据的空间分辨率，这些属性被推荐用于与NativeSRS相应的BoundingBox.。对于SRS为“OGC:none”或“OGC:swath”的BoundingBox（它指出了像素或局部坐标系），这些属性通常是1Page: 15This is missing in the current schema. One possibility would be to bundle it with

38、 the SRSs.。7228SupportedFormatList 必选元素SupportedFormatList通告了可从覆盖层请求覆盖的输出格式(如GeoTIFF,HDF-EOS,NITF,DTED,等等.)。格式名称和MIME类型都标识这些格式。现已定义几种具体的OGC类型用于区分各种类型的XML文档，WMS 1.1.中列出了这些类型。7229SupportedInterpolationList可选元素SupportedInterpolationList确定当请求需要重采样、重复投影或进行其它综合时，服务器是否会并且如何在空间域上内插一CoverageLayer的值。可选、可复选的In

39、terpolationMethod子元素可能是以下8个不同值中的一个：“最近邻域”，“线性”，“双线性”, “双圆锥”，“无功面积（lost area）”，“重心（barycentric）”，“分段常数”和“无”.SupportedInterpolationList会在其默认属性中确定一个插值模式，假如客户端没有指定一个插值模式，就会采用这个模式。如果SupportedInterpolationList不存在默认属性，且没有InterpolationMethod子元素，客户端应该预计到会采用最近邻域的插值法。 如果列出的唯一插值模式为无，客户端只能在本地SRS中，按照本地分辨率，从该层中检索覆

40、盖。723域描述前述部分(6.2.2)描述了AbstractCoverageLayerType，它的元素是所有种类的覆盖层共有的。Capabilities XML文档中列出的各实际覆盖层都增加了两个至关重要的元素来扩充了这个类。这两个元素描述了从一个给定的覆盖层中可用的各个覆盖的域和范围。第一个元素描述了覆盖层中有值或有测量值的各个空间（也可能是时间）位置。这些位置用下面5种方法之一定义： 像素或点的规则格网； 不规则三角网（TIN）； 一系列点； 弧段集； 泰森多边形集合。有些元素是这些不同种类的覆盖所共有的，也有几个元素是每个种类的覆盖所独有的。7.2.3.1共有元素所有覆盖类型的域都有一

41、个空间范围，有些域还有时间范围和高程范围，如图5所示。.图5 域描述共用元素: SpatialExtent首先，必选元素SpatialExtent列出了各个空间维度的界限，在界限内时，可从覆盖层请求覆盖数据。SpatialExtent元素必须具有属性srsName，该属性指出表示SpatialExtent元素使用的空间参考系，这个参考系可能是一个2-D或3-D的坐标参考系。.必选元素XExtent和YExtent确定了一个在2-D坐标参考系中的2-D空间范围，可选元素Zextent用于3-D空间范围，在3-D坐标参考系内表示。下图（图6）描述的可选元素TemporalExtent列出了从覆盖层

42、请求覆盖的次数，它可由一个或多个的区段或时间点组成。TemporalExtent具有可选属性uom，它指出了用来表示时间间隔或实例的度量单位。图6 域描述的共用元素：时间和高程范围l 最后，可选元素ElevationExtent（上图Figure11所描述的）列出了可从覆盖层请求的覆盖的高程范围或点。ElevationExtent有一个可选属性uom，它指出表示高程的量测单位。ElevationExtent是用来向2-D空间范围补充高程范围信息的。除了空间、时间和高程域范围以外，各种不同的覆盖层还增加了更多具体的域描述符，下面几个部分对此作了详细说明。7232格网覆盖层首先，格网覆盖层定义它的

43、域是2，3，或4维空间内点或像元的规则网格。这种描述适合于数字航摄象片、卫片、格网地形模型、或其它的栅格数据。如图7所描述的，格网覆盖层的DomainSetDescription包含一个可复选的元素GridExtentDescription，该元素扩展了共有的DomainSetExtentDescriptionType。图7 格网覆盖层域描述GridExtentDescription模式在共用模式的基础上增加了3个元素。 必选元素GridAxisDescription，它确定格网的各坐标轴。 GridSpacing 对于已纠正的格网而言是必选的，但在其它的格网中未定义。它规定了沿格网各维度空间

44、的地面分辨率（像素尺寸或格网点间距），用（已纠正的）格网的坐标参考系的单位来表示。 必选元素Grid或必选元素RectifiedGrid，这两个元素都列出了沿各格网坐标轴的格网坐标的上下界限 (它们是用整数像元或格网坐标在格网内部坐标参考系中表示的，其下界限通常定为零)，Grid和RectifiedGrid都有两个必需的属性： dimension (值：2，3或4)表示一个2-,3-,或4-D格网。 type (值:点位或中心)指出值是与格网点位置（点位）相联系，还是与邻近点位（中心）间的区域相关。RectifiedGrid（纠正格网）描述如正射象片、Level 1G卫片这样的格网数据，这些格

45、网在各维度空间的格网坐标与地面坐标参考系的坐标之间存在仿射关系。如图8所示，RectifiedGrid增加了两个与GridRange并列的、必选的元素: Origin列出了格网原点（即，(0,0,0,0)格网点）在地面坐标系中的位置。 Offsets列出了地面坐标系中沿各坐标轴的格网间距。图8 纠正格网的描述RectifiedGrid也增加了第三个必选的属性srsName，它用来标识格网原点和偏移所采用的地面坐标系。在这里也考虑了第三类格网（还没有定案）：RectifiableGrid（可纠正格网）描述了这样的格网，其坐标轴与地面坐标系的坐标轴相关联，这种关联是通过数学转换实现的，而不是一种简

46、单的仿射关系。和RectifiedGrid中的Origin和Offsets相比较，RectifiableGrid描述是一个如图Figure9所示的MathTransform 元素。图9 可矫正格网描述MathTransform将列出基于传感器模型、几何参数和外方位元素的转换运算法则，MathTransform元素的句法还没有定义，它将引用Sensor Markup Language IPRPage: 21Ref.中的元素。7233点（MultiPoint）覆盖层第二类覆盖层定义其域为一系列的点，这些可能是气温读数、土壤抽样点或高程点的位置。除了共用的元素(SpatialExtent，Tempo

47、ralExtent和ElevationExtent)外，该类覆盖也列出了两个可选的元素，如图10所示。图 10 -点（MultiPoint）覆盖层的范围描述 Envelope 列出了组成有效数据点边界的一个或多个的多边形。它提供了关于域空间范围的更为精确（更紧凑）的描述。 PointCount 列出了覆盖层域中的点数。7234TIN覆盖层第三类覆盖层将其域定义为，由一系列点通过狄洛尼（Delaunay）三角形连网得到的一系列的三角形。(这类覆盖经常通过沿这些三角形进行线性内插模拟地形：地面被假定为取决于三个相邻测点连成的三角形的表面)，图11显示了这样的域结构。图 11 - TIN 覆盖层的范

48、围描述TIN覆盖层域的描述与点覆盖层域有很多相似之处，它也有Envelope 和PointCount。但TIN覆盖层增加了一个可选元素BreakLineCount，该元素列出了在TIN覆盖层中定义的断裂线的总数(断裂线是梯度突然发生明显变化的测点的集合)。7235曲线段覆盖层第四类覆盖层即曲线段覆盖层，其域定义为一系列的曲线（即弧段、样条或线划串），Page: 22Why do we list each curve not just an envelope or convex hull? Why do we care about the total number of curves in th

49、e layer?Page: 22This needs to be adjusted to the WSDL formulation.这种描述方式可能适合街道和道路底库。如图Figure12所示，该覆盖层用曲线代替了点覆盖层中点的描述。图 12 曲线段覆盖层域描述7236泰森多边形覆盖层这里所研究的最后一类覆盖层定义其域为由一系列已知的（“确定的”）点构成的多边形。各多边形不仅封闭了一个确定点，而且多边形内任何一点到该确定点的距离较其它任何点近。这种覆盖结构描述如图13所示。图 13 泰森多边形覆盖层域描述泰森多边形覆盖的域通常包括ClipArea元素，该元素列出了一个或多个组成有效数据外部边界

50、的多边形。它也包括列出覆盖中多边形总数的元素PolygonCount。我们也可能还需要讨论常规的多边形覆盖。724范围描述各覆盖类型在基本的AbstractCoverageLayerType上增加的第二个元素是RangeSetDescription。这个元素定义了域中各位置的属性（分类，量测或值）。一个位置可能附带几个互不相关的属性（例如当前土地利用，日平均气温，等等），每个属性在独立的范围集（Range Set）中描述。这些属性可能是一个纯量（数值或文本），如人口密度，或是一个复合（矢量或张量）值，如不同种族的收入，或不同波长辐射率等。7241通用范围集模型在这个WCS版本中，各种覆盖类型都

51、有相同的结构化范围集描述（GridCoverage除外，它增加了一些具体图形元素，如直方图值）。图14表示了这种模式。图 14 范围集描述单个RangeSetDescription可有一个或多个的RangeComponentDescription，用于描述与域中每个位置相联系的不同值。每个RangeComponentDescription都包含下列元素： 必选元素RangeID，唯一地标识覆盖层中的范围成分。 必选元素title，包含一个描述该范围成分的人们可读的字符串，用来在菜单中向用户显示该范围成分。 可选元素description，包含范围成分的自由文本描述。 可选元素Observable，规定了包含在范围成分中的各种观测（量和属性）的结构化描述。该描述包括一个name, 一个自由文本 description, 一个 docURL (观测类型注册条目的索引)，以及一个把表达值与现实世界的量和类相联系的referenceSystem 。 支持复合观测的可选元素RangeAxis。它描述并列出了范围成分所包含的