OWS1网络覆盖服务.doc

《OWS1网络覆盖服务.doc》由会员分享，可在线阅读，更多相关《OWS1网络覆盖服务.doc（96页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、OGC 02-024OWS1网络覆盖服务（WCS） 版权申明 本OGC文档是一份草案，版权属于OGC，OpenGIS互操作计划的参与者可以不经OGC事先许可使用任何形式的草案复制品。但是，事先没有OGC的书面许可，不得因任何其它目的、以任何形式复制、存储或传播本文档或其摘要。警告 本文档并非OGC的标准或规范，它阐述了在OGC互操作计划的第一步中讨论的技术问题。阐述本文献的内容是为了促使整个地理空间信息行业讨论这个主题；而不是将其作为任何一种可采用的规范。本文献不代表OGC或OGC技术委员会的正式立场。它可能在未经告示的情况下进行修改，并且不能作为的标准或规范进行引用。不过，文献中的讨论能很好

2、地产生实施规范的定义。本文档的收件人需随同对本文档的评论一起，递交一份所知道的相关专利权的通知及证明文件。文档分类：OpenGIS互操作计划报告工程规范二级分类：适用采纳文档级别：定稿文档语言：英语目录 前言。 提交机构。 文档投稿者联系方式。 修订历史。 抽象规范的改进。序。导言。规定范围。致性。标准化参考资料。术语和定义。约定。符号（缩写的术语）。符号。基本服务要素。版本编号和协调。版本号格式。版本的更改。在请求及服务性元数据上的显示方式。5版本号的协调。通用的请求规则。6关键值对编码。编码。通用的响应规则。服务异常。97GATCAPABILITIES操作（必需的）。91 GATCAPAB

3、ILITIES请求。10711关键值对编码。10712编码。10 72 GATCAPABILITIES响应：CAPABILITIES XML文档。10721-CoverageLayerList顶级元素。11722-CoverageLayer特性（共用）。12723-域说明。16724-范围说明。2473异常情况。308-GETCOVERAGE操作（必选）。3181 ETCOVERAGE请求。31811关键值对编码。31812编码。36 82-GETCOVERAGE响应。38821覆盖编码。39822-异常。39823GetCoverage的近似响应。399-DESCRIBECOVERAGELA

4、YER操作（可选）。3991-DESCRIBECOVERAGELAYER请求。40911关键值对编码。40912编码。4092-DESCRIBECOVERAGELAYER响应。4110-参考书目。41附录A（标准）XML模式。42附录D（标准）一致性测试。89参考书目。90i. 前言ii提交机构本互操作计划报告工程规范由下列机构提交给OGC互操作计划。iii文档投稿者联系方式有关本文档的问题请与编者或撰稿人联系。联系人公司（/组织）地址电话号码EMAILJohn D. EvansGST, Inc.6411 Ivy Ln. Ste 300Greenbelt, MD 20770USA(301) 4

5、74-Stephane FellahPCI Geomatics490 St. Joseph Blvd., Suite 400Hull, Quebec J8Y 3Y7CANADA(819) 770-0022 Ext. Jeff LansingPolexis, Iiv-修订历史日期版本作者修改的段落说明2001-11-170.5John Evans最初的DIPR版本2001-11-290.5Jeff Lansing添加了DescribeCoverageType的内容2001-11-290.5Stephane Fellah 修订格式和插值法定义; 许多独立存在的实体的注释2002-01-310.5.

6、1John Evans修订& 校正; XML 模式2002-02-200.6Stephane Fellah覆盖层描述和XML请求的新模式2002-04-040.7John Evans确定并理顺了0.6版中的模式; 增加了复杂观测、文件和综合.V-OpenGIS抽象规范的改进OpenGIS抽象规范不需要改进以适应本文档的技术内容。序OGC01-018r3 由以下部分构成：网络覆盖服务报告。.序言网络覆盖服务（WCS）支持网上地理空间数据的相互交换，此时地理空间数据作为包含地理位置值或特征的“覆盖”。不同于网络地图服务（OGC文档#01-021r2），它通过筛选和描绘空间数据返回静态的地图（服务器

7、以图片形式表示）；网络覆盖服务在客户端的再现、多值覆盖、以及输入科学模型和不仅仅是阅读器的客户机需要提供对原始的（未处理的）地理空间信息的访问。网络覆盖服务由三种操作组成：GetCapabilities，GetCoverage和DescribeCoverageType。GetCapabilities操作返回一个描述服务和客户机能从中获取覆盖的数据集合的XML文档。通常，客户机运行GetCapabilities操作并贮存结果，是为了在整个会话过程中，或是在多次会话过程中重复使用它。一般而言，网络覆盖服务中的GetCoverage操作是在GetCapabilities确定什么样的查询可以执行、什么

8、样的数据能够获取之后执行的。它返回地理位置的值或特征，这些值或特征被捆扎在通用的覆盖格式中。除了几个扩展支持覆盖检索而不支持静态地图的检索以外，GetCoverage的句法和语义与WMS中GetMap的请求类似。89 OGC 2002 版权所有 OWS1 网络覆盖服务（WCS）1规定范围本规范文档阐述WCS如何实现在万维网上描述、请求和传输多尺度覆盖数据。网络覆盖服务的这一版本着重于“简单的” 覆盖（定义为一些规则的、直角坐标网或棋盘形镶嵌的空间），它还预期了在OpenGIS抽象规范中定义的其它覆盖类型（专题6，“覆盖类型”，OGC文档#99-106）。2-一致性使用附录A（标准化的）中列出的

9、相关测试可以检查OGC互操作程序报告的一致性和互操作测试。测试的框架、概念、方法及得出一致性结论的标准，在ISO19105地理信息一致性和测试中都做了详细说明。3-标准化参考资料文中引用的下列标准中，包含了构成本规范的条款。过时的参考资料在其后的修正、再版或任何出版物中都不再使用。鼓励就OGCnnn部分达成一致的各方对下列国际标准的最新版本中的内容在本规范中应用的可能性进行评价。未过时的参考资料在最新的标准化文献中作为参考使用。OGC01021r2:2001，网络地图服务v. 1.1ISO19123,地理信息覆盖几何图形和功能抽象规范专题0：综述，OGC文档99-100r1成功的OGC接口规范

10、准则，OGC文档00-014r14术语和定义上面的参考资料中的术语和定义在本文献中的含义与下列的术语相同。操作对象需要执行的转换或查询的规范。OGC AS 12接口由体现实体行为特性的操作组成的具有给定名称的集合。服务实体通过接口提供的明确的一部分功能。OGC AS 12服务实例服务器服务的实际实现。客户端可以从服务器上调用操作的软件组件。请求客户端对操作的调用。响应服务器返回给客户端的操作结果。地图地理数据的图示表示。功能 XML 服务级元数据，用以描述服务实例中的操作和内容。5 约定511符号（缩写的术语）下列是本文献中使用的符号和缩写术语。API应用编程接口DCP分布式计算平台ISO国际

11、标准化组织OGCOpen GIS 联盟UML统一建模语言XML可扩展标记语言1D一维2D二维3D三维512符号本文献中出现的图表使用统一建模语言（UML）静态结构图表。下面的图表描述了本文献中使用的UML符号。图 1 - UML 符号图中使用了UML类的下面三种模板a）对由具有这个接口的对象支持的一组操作的定义。一个接口类不包含任何属性。b）一组相异（独立存在并可能产生侧面影响）值的描述符。数据类型类没有操作，其主要目的是保存信息。c） 是用串值表示潜在值列表的一个灵活的枚举。本文献使用了以下的标准数据类型：a）字符串字符序列b）整型整数c）双精度型双精度浮点数d）浮点型单精度浮点数6基本服务

12、要素这一部分阐述网络覆盖服务器的行为概要（更一般的说法是OGC网络服务行为）它独立于具体的操作，或是与几个操作或接口共同行为。61版本编号和协调。611版本号格式已出版的规范的版本号包括三个型为“x.y.z”的正整数，彼此之间用小数点隔开，“y”和“z”位上的数字不超过99，各OWS规范独立编号。612版本的更改一个具体的规范版本号须随再版而改变。版本号必须单调增加，且仅由三个彼此间用小数点分开的整数组成，其中第一个整数的意义最重大。这些数字序列间存在差距。有些数字可以表示实验性或临时版本，服务实例和客户端不需要支持所有确定的版本，但必须遵循下述的协调规则。613在请求和服务元数据上的显示方式

13、至少要在两个地方使用版本号，一是在CapabilitiesXML描述一服务时，另一是在客户端请求该服务的参数列表中。在具体服务实例的客户端请求中使用的版本号必须与该实例申明支持的版本号相一致（如下所述的协调情况除外）。一个服务实例可支持几个版本，客户端可以根据协调规则确定这些版本号。614版本号协调OWS客户端可以与服务实例协调，确定一个彼此都适宜的规范版本。协调是由GetCapabilities操作依据下述规则来完成的。所有CapabilitiesXML都必须包括一个协议版本号。为了响应包括一个版本号的GetCapabilities请求，OGC网络服务必须响应与规范的该版本相一致的输出，假如

14、被请求的版本在服务器上不能执行，则必须协调出一个彼此适宜的版本。如果请求中没有指定版本号，服务器必须响应它所支持的最高版本并据此标注响应。版本号协调过程如下：1如果服务器执行请求的版本号，服务器必须发送该版本。2如果服务器不执行请求的版本，服务器必须发送低于请求版本的最高版本。 3如果客户端请求的版本比服务器执行的任何版本都要低，服务器必须发送它所执行的最低版本。4如果客户端不理解服务器发送的新版本号，它可能会中断与服务器的通信，或者发送带有客户端理解的、比服务器发送的低的新版本号的新请求（如果服务器响应较低版本）。5如果服务器响应较高版本（因为请求的版本比服务器执行的任何版本都要低），但是客

15、户端不理解建议的较高版本，客户端可发送比服务器发送的高的版本号的新请求。这一过程会重复进行，直到找到一个互相都能理解的版本，或是客户端确定不再与特定服务器通信。 例1：服务器支持版本1，2，4，5，8；客户端支持版本1，3，4，6，7；客户端请求版本7，服务器响应版本5；客户端请求版本4，服务器响应客户端支持的版本4，至此协调成功结束。例2：服务器支持版本4，5，8；客户端支持版本3；客户端请求版本3，服务器响应版本4，客户端不支持版本4或其它更高的版本，因此协调失败，客户端终止与服务器的交流。62通用HTTP请求规则目前，OGC网络服务明确支持的、唯一的分布式计算平台(DCP)是万维网本身，

16、更具体地说是执行超文本传输协议(HTTP)6的因特网主机。因此，由服务实例支持的各操作的在线资源是HTTP的统一资源定位器(URL).。对于各操作而言，URL可能不同，也可能相同，这取决于服务供应商的判断力。各URL的确定须遵循6中的描述，或者依据具体实现来确定，只有服务请求本身的参数是由OGC网络服务规范强制规定的。HTTP支持GET和POST两种请求模式。一个特定的OGC网络服务类型可以只定义其中的一种或是两种模式都定义，并由具体的服务实例提供上述模式，不同的实例在线资源URL的用法不同。事实上，供HTTP的GET请求使用的在线资源URL只有一个URL前缀，为了构造有效的操作请求，还要在这

17、个前缀后添加必要的参数。URL前缀定义为不透明的字符串，它包括协议，主机名，可选的端口数，路径，问号?，还可以增加一个或多个以&符号结尾的具体服务器参数。前缀唯一地标识具体的服务实例。对于HTTP 的GET，URL前缀必须以一个?(在没有附加的具体服务器参数的情况下)或&结尾。然而，在实践中,为了构造一个有效的请求URL，客户端在添加本规范中定义的操作参数之前，应该准备添加一个?或&结尾。供HTTP的POST请求使用的在线资源URL是一个完整而有效的URL，客户端通过POST文档向它传输经过编码的请求。在构建请求操作的有效目标时，WCS服务器不必在URL上添加另外的参数。621关键值对编码使用

18、关键值对编码时,客户程序将必需的请求参数编写为关键字=值形式的关键字/值对，并经由HTTP GET或HTTP POST传输到服务器。对于HTTP GET，客户端为选定操作的在线资源URL的前缀后添加用&，用来分隔关键字/值对；形成的URL必须符合HTTP通用网关接口（CGI）标准7，CGI要求查询参数序列前面必须有?，每两个查询参数间必须用&来分隔；正象所有CGI的应用一样，查询URL的编码8必须能够保护特殊的字符。表1总结了HTTP GET操作请求URL的组成部分。表1 通用的OGC网络服务请求URL构件说明http:/host:port/path?name=value&服务操作的URL前缀

19、， 表示出现次数为0或1；表示出现次数为0或更多；前缀完全由服务供应商来确定。Name=value&OGC网络服务定义的一个或多个标准化请求参数名称/值对，各个操作中必选的和可选的参数实际列表由相应的OWS规范确定。使用HTTP GET方法编码为关键值对的请求可以作为书签存储，也可以嵌入为超链接, 还可以经由XML文档中的Xlink被引用。6211参数顺序和大小写参数名不须区分大小写，但参数值必须区分大小写。本文献中参数名特别用大写仅是为了印刷上的清晰，不是必需的。请求中的参数可以按任意次序指定。OGC网络服务必须做好遇到不属于这一规范的参数的准备，在由规范产生的结果方面,OGC网络服务须忽视

20、这样的参数。6212参数列表由列表组成的参数须使用逗号(,)作为列表中各数据项之间的分隔符。例如，参数=数据项1, 数据项2, 数据项3。多重列表可通过将各列表封入圆括弧(,)中作为一个参数的值来确定。例如，参数=(数据项1a, 数据项1b, 数据项1c)( 数据项2a,数据项2b,数据项2c).622编码在实际实施的测试里，还没有完全解决关于是否使用SOAP19问题，因而，在此暂时阐述两种可供选择的观点。为了向使用HTTP GET或(更常用的是)HTTP POST的服务器传输请求，客户端也可能将请求用XML编码。XML请求必须与相应的可选操作模式相一致，而且客户端序须将请求发送给在服务器Ca

21、pabilitiesXML文件中针对该操作列出的URL。为了支持SOAP消息传送，客户机程序只需如下所示，将XML文档封入SOAP信封里： request document here 客户端需在XML请求前面加上下面定义的适当的HTTP请求头信息（与其它头信息一起在8中确定） 内容-类型: text/xml; charset=utf-8-或者?-内容-类型: application /vnd.ogc.request+xml(这里的request是一个已定义的操作名) 内容-长度: nnnn(这里的nnnn是请求文档的字节数)SOAP消息传送需要下列头信息: 内容-类型：text/xml; ch

22、arset=utf-8 内容-长度: nnnn这里的nnnn 是包括SOAP信封在内的文档字节数 SOAPAction: URL (可以为NULL)63通用HTTP响应规则当接收到一个有效请求时，服务必须根据适当规范中的细节返回严格对应于该请求的响应。只有在版本协调的情况下（上面所描述的），服务器才可能提供不一样的结果。当接收到一个无效请求时，服务程序必须发布一个6.4部分所阐述的服务异常。注意:作为一个实际问题，在3W环境下，客户端应能够接收有效结果，或什么也不接收，或任何其它的结果。这是因为客户端本身可能产生一个不相容的请求，这个请求通过OGC网络服务程序以外的其它服务程序不经意地触发了的

23、一个应答；也可能是因为服务程序本身是不相容的，等等。适当的多用途网际邮件扩充 (MIME)类型9必须伴随响应目标。SOAP请求返回一个由多个部分组成MIME文档，该文档是依据W3C中带有附件20条文的SOAP消息格式化的。第一部分是一个SOAP消息；第二部分包括实际的服务器应答(图象，覆盖，等等)。换句话说，该应答可能是一个包含来自服务器实际响应的URL的SOAP消息。其它的HTTP实体的头信息应当尽可能附带适当的响应对象。特别地，有关终止和上次修改的头信息提供了关于存储的重要信息；客户端通过使用内容-长度了解数据传输完成时间并为结果有效地分配空间；为了适当地解释结果，内容编码或内容传送编码可

24、能是必需的。64服务异常根据使用的分布式计算平台(DCP)的规则，在接收到无效请求时，服务器程序可发布在该DCP中为有效类型的异常。例如，在HTTP的DCP中，假如URL前缀是错误的，服务器程序将返回一个HTTP 404状态码。在接收到无效请求时，服务器程序必须发布一条服务异常XML消息，向客户应用程序和用户解释请求无效的原因。依据附录A.3中的服务异常DTD，服务异常XML必须是有效的。在HTTP环境下，返回的XML的MIME类型必须为application/vnd.ogc.se_xml。包含的具体错误信息可以是纯文本块，也可以被包含在字符数据(CDATA)块段中，形成类似XML的包含角括弧

25、()的文本。如同附录A.4服务异常XML中的例子所示。服务异常可包括附录A.3中指明的异常代码。除了那些已指定的含义外，服务器不能使用这些代码表示其它含义。客户端可以使用这些代码自动响应服务异常。 7GetCapabilities操作（必需的）网络覆盖服务器需说明其Capabilities。本节定义了一个XML文件结构，用于传送服务程序本身的一般信息，和可以从中请求覆盖的有效数据集的具体信息。71GetCapabilities请求711关键值对编码一般格式的GetCapabilities请求在基本服务原理一节已定义，下表2是对其的总结。表 2 GetCapabilities请求URL的参数请求

26、参数必需的/可选的说明REQUEST=GetCapabilitiesR该请求的名称VERSION=versionO该请求的版本SERVICE=WCSR服务程序类型 在生成该请求时，考虑到OGC网络服务器还可提供WCS以外的其它服务，必须特别说明客户程序查找的是关于WCS服务器的信息。因而，请求的SERVICE参数必须有表2.中所示的值WCS。712XML编码在OWS Service Metadata XML IPR 中介绍了GetCapabilities请求的XML编码的XML模式。例如，客户端可用XML编写一个GetCapabilities的请求如下：/OGC_Capabilities/Op

27、erationSignatures顶级XML元素GetCapabilities有两个属性：version 和service，它们分别表示协议的版本号和服务器地址。GetCapabilities元素有一个可选的子元素Section，它表示返回CapabilitiesXML文档的哪个部分：ServiceOffering，OperationSignatures，还是ContentMetadata元素。如果没有提供这个子元素，那么服务器必须返回整个的CapabilitiesXML文档。72GetCapabilities应答：CapabilitiesXML文档对GetCapabilities请求的应答是

28、与OWS Service Metadata XML IPR中给出的模式相一致的CapabilitiesXML文档，它由图3所示的四个主要部分组成。该部分提供了服务公用的元数据，该元数据包含了最少量的可以阅读的信息该部分用WDSL描述了服务所支持的操作该元素是一个可包含任何具体服务元数据的容器。例如：一个wfsFeatureList、一个wmsLayerList或者ISO19115都可以插入该部分 该元素是一个可包含任何具体服务元数据的容器。例如：一个wfsFeatureList、一个wmsLayerList或者ISO19115都可以插入该部分 该部分可以包含任何一个用来描述额外功能的方案。最浅

29、显的例子是过滤功能方案。 根元素图2 - OGC_Capabilities 顶级元素OWS Service Metadata XML IPR中阐述了这四个部分的任务，以及前两个部分(ServiceMetadata和OperationSignatures)的结构。OperationSignatures是WSDL服务的描述，它引入几个模式去定义请求（关键值对，XML，SOAP）和应答(XML文档，异常，或覆盖数据).的句法。下面的部分详细地阐述了这些模式。CapabilitiesXML文件的第三部分(ContentMetadata)是具体针对WCS的，它引入了接下来要阐述的CoverageLaye

30、rList模式。721CoverageLayerList顶级元素针对WCS的CapabilitiesXML文档中ContentMetadata部分的顶层是CoverageLayerList元素，它按任意次序排列覆盖层。图3显示了该CoverageLayerList元素的结构。图2 CoverageLayerList(ContentMetadata下的顶层)有5种不同的覆盖层，但它们都具有下面所列的几个共有特性。722CoverageLayer特性（共有）在CapabilitiesXML应答中，网络覆盖服务器宣称它能从各数据集中挑选并返回某些覆盖(即时空位置的值或属性)。每一个可以提供覆盖的逻辑

31、的集合称为一个覆盖层。可获取的各种覆盖层共享几个共同的元素，这些元素组成了AbstractCoverageLayerType(图4)。图3 抽象CoverageLayerType(AbstractCoverageLayerType本身扩展了一般的LayerType，这意味着它可被网络地图服务（Web Map Service）和网络要素服务（Web Feature Service）共享。)下面部分阐述AbstractCoverageLayerType的各子元素这些子元素是各种覆盖层都具备的。7221LayerIDLayerID是一个不可或缺唯一的标识符(不能用于任何其它的覆盖层)。进行GetCo

32、verage或DescribeCoverage操作时，客户端通过在LAYERS参数中(针对以关键值对表示的请求)，或在LayerID元素中(针对XML请求)使用LayerID值，从该覆盖层(或是覆盖层描述)中请求覆盖数据。7222TitleTitle元素不可缺少，它包含一个为了在菜单中表示的人们可读取的字符串。7223Abstract和KeywordListAbstract和KeywordList元素是可选的，但推荐使用。Abstract是图层的一种叙述式描述， KeywordList包括类目检索中用于辅助搜索的关键字。7224MetadataURLMetadataURL元素是可选的，但推荐使

33、用，它用于访问某一个特定层下数据的详细、标准的元数据。type属性指出了元数据所遵循的标准。目前定义了两种类型：TC211 = ISO TC211 19115；FGDC = FGDC Content Standard for Digital Geospatial Metadata（数字地理空间元数据FGDC内容标准）。7225LatLonBoundingBox必选的LatLonBoundingBox元素具有按经纬度十进制度数显示封闭矩形边界的属性。地图服务器支持无论什么样SRS的覆盖请求和应答，都必须提供LatLonBoundingBox。但是，假如EPSG:4326 (WGS84 地理坐标)

34、不是一个被支持的请求SRS，那LatLonBoundingBox可能是近似的，其主要目的是为基于地理坐标检索提供入口。7226空间参考系（SRS）：请求参考系，应答参考系和本身参考系对于各覆盖层，CapabilitiesXML的描述指定了：(i)数据本身的空间参考系（SRS）；(ii)在接收到的GetCoverage请求中可以理解的各种SRS列表；(iii)在对GetCoverage请求进行响应时生成的覆盖中可以出现的各种SRS列表。72261SRS每个CoverageLayer必须具有一个或多个SRS元素，或是具有既是查询SRS（QuerySRS）又是应答SRS（ResponseSRS）的元

35、素(该元素包括一个或多个SRS元素)。服务器可能分别详细列出查询与应答的SRS，也可能仅仅通告可以同时出现在接的收请求中和在传送覆盖应答中的各种SRS。SRS元素的内容可能是在网络地图服务实现规范中定义的EPSG或AUTO坐标系之一；也可能是未定义的(“OGC:none”)；或者是嵌入式的“扫描条带”参考系(“OGC:swath”)，客户端根据控制点或传感器元数据重建地面坐标。 72262QuerySRSQuerySRS元素定义了对该覆盖层发出GetCoverage请求时可以采用的SRS，而且，其中的一个坐标系必须是该覆盖层本身的SRS。 在请求中的特殊SRS代码如“OGC:none”或“OGC:swath”表示根据层的像素行/列坐标系(针对图象)或层的内部/局部坐标系(针对非栅格数据)来定义子集。72263ResponseSRSResponseSRS元素定义了覆盖在响应GetCoverage请求时可以采用的坐标系，且其中的一个坐标系应是该层的本地SRS。当采用特殊SRS代码“OGC:none”或“OGC:swath”提供覆盖服务时，表示该层采用的是像素行/列坐标系(针对图象)或它的内部/局部坐标系(针对非栅格数据)。以SRS“OGC:swath”代码响应的覆盖可嵌入传感器模型或控制点信息，从