传感器观测服务标准接口
版权声明：本文为博主翻译文章，转载请附上出处链接https://blog.csdn.net/qq_21225505/article/details/86550356
八、 需求类 ：核心
在这个模块中，SOS的核心操作getcapability、descripbesensor和GetObservation被指定。
GetCapabilities—提供对SOS服务器可用操作的元数据和详细信息的访问。
descripbesensor-提供有关传感器和传感器系统的详细信息，可用的SOS服务器。
GetObservation -提供从传感器和传感器系统中通过空间、时间和主题滤波选择的观察。
SOS操作遵循其他OGC Web服务的一般模式，并在适当的情况下继承或重用OWS公共标准[OGC 06-121r3]和SWE服务模型标准[OGC 09-001]定义的元素。
本标准中定义的所有请求和响应类型(除了基于[OGC 06-121r3]的GetCapabilities请求和响应之外)分别来自于OGC 09-001中定义的ExtensibleRequest或ExtensibleRepsonse类型。每个请求和响应类型都定义了一个可选的扩展属性，一个可以由扩展定义的请求参数的容器。
这个标准定义了以下的通用要求适用于以下的所有操作(除了在明确否定的地方)
-
GetCapabilities Operation
此操作允许客户端检索SOS服务器的服务元数据(也称为“功能”文档)
getcapability操作的概念模型如下面的UML图所示
a.请求
SOS GetCapabilities数据类型派生自OWS常用的GetCapabilities数据类型(在[06-121r3]表3中列出)，因此继承了该数据类型中包含的所有属性。
注意:请求属性——派生自OWS通用的getcapability类型——是由GetCapabilities操作的每个特定绑定显式或隐含表示的，因此不一定是该绑定定义的请求表示的一部分 。
注:可通过扩展添加额外部分;例如，这可以通过insertioncapability requirements类(第10.1条)来完成。
b.响应
对GetCapabilities操作请求的响应也称为capability文档。此文档向客户机提供关于特定服务实例的服务元数据，包括关于所服务的数据的元数据。此子句定义了SOS 2.0功能文档中所需的元素。
SOS“功能”数据类型派生自OWS公共OWSServiceMetadata数据类型(如[06-121r3]的第7.4.2条中定义的那样)，因此继承了该数据类型中包含的所有属性。
GetCapabilities响应文档的ServiceIdentification、ServiceProvider和OperationsMetadata部分在[OGC 06-121r3]中定义。
通常，此类一致性类将在SOS扩展中指定。
还应列出来自已实现规范(例如OGC筛选器编码规范或OMXML)的一致性类。
注意，概要文件属性中还列出了继承的一致性类。例如，即使InsertObservation一致性类依赖于insertioncapability类，但列出的都是这两个一致性类，而不仅仅是InsertObservation类。
在[OGC 06-121r3]中指定的OperationsMetadata部分列出了SOS服务器支持的请求类型。对于SOS的核心，这些是getcapability、descripbesensor和GetObservation;扩展可以向这个列表中添加更多的请求类型。
以下的小节定义了SOS功能文档的部分内容是由这个标准，FilterCapabilities和内容部分添加的
（1）FilterCapabilities Section
filterability部分从[OGC 09-026r1/ISO 19143]导入，用于说明SOS服务器支持哪些筛选操作符和操作数。操作符和操作数引用包含OGC筛选器表达式的服务操作的参数，如GetObservation操作。
示例1中的SOS支持几何操作符gml:Point的空间操作符BBOX，
它会像 http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1_response.xml 中的示例所示
示例2是一个SOS，它支持时间操作员的TEquals和临时操作的gml:TimeInstant和gml:时间周期将这些显示在 http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1_response.xml
（2）Contents Section
GetCapabilities响应的内容部分描述了SOS服务器提供的数据。为了将提供的观察结果分组，SOS定义了ObservationOfferings的概念。
Contents 类型列出了SOS服务器的所有ObservationOffering。一个ObservationOffering组是由一个过程(如传感器系统)产生的观察结果，ObservationOffering 列出了相关观察的基本元数据，包括观察到的属性。一个观测可以属于多个ObservationOffering。
综上所述:在procedures和 ObservationOfferings之间有1:n的关系;由这些procedures创建的观察与ObservationOfferings之间存在n:m关系。
注:观察通常与一个offering相关。然而，来自一个传感器的观察可能被分配到多个offering--- 1:n关系是允许的。这可以用于分组预先过滤的观察结果。允许根据一些主题标准对观察结果进行分组赋予了这种方法一种功能性，例如，将来自同一传感器系统的严重天气预报和全天气预报观测结果分组为两个offering。
SOS的Contents类型派生自[OGC 09001]中定义的SWES AbstractContents类型，并继承其属性。
这些继承属性是(详情见[OGC 09-001]第7.2.1条):
- procedureDescriptionFormat -一个特定过程的标识符/传感器描述格式。
- observableProperty —— 指向可以被某个过程观察到的属性，这个属性不必是已经存在的被观察过的属性。
- relatedFeature---过程直接或间接观察到/可观察到的特征;可以是服务提供者认为过程可以对其进行有价值的观察的任何特性。
- offering——包含关于服务承载的过程/传感器的元数据。
注:相关特性不一定是感兴趣的特性(并与观察结果相关)。服务提供者可以将相关特性的列表用于发现目的。例如，相关的特征可以是墨西哥湾，以防SOS提供由墨西哥湾地区的海洋漂流者携带的传感器测量的数据。特别是在移动传感器的这种情况下，将所有感兴趣的特性(=采样位置)作为相关特性列出是不合理的，因为Capabilities document会随着时间的推移变得太大 。
SOS observationprovider类型派生自OGC 09-001中定义的SWES抽象提供类型，并继承了它的所有属性。
这些继承属性是：(详情见[OGC 09-001]第7.2.2条):
- procedure- - 指向与此相关的过程或者传感器.
- 同时，procedureDescriptionFormat, observableProperty, and relatedFeature 也包含在上述描述中.
为了减少功能文档中的冗余信息，SOS支持[OGC 09-001]中定义的所谓的属性继承机制。
下表显示了在应用继承机制之后，可以继承observationprovider的哪些属性，以及期望继承的基数。
客户端需要根据表18中为ObservationOffering属性定义的继承类别，在确定它们的值(对于给定的产品)时，应用SWES属性继承机制。
因此，即使UML模型和模式编码定义，例如，作为可选的observationType和responseFormat属性，它们在每个ObservationOffering中都是强制性的。换句话说，在应用了属性继承机制之后，每个offering必须为这两个属性包含至少一个值。
由于O&M v2.0 XML编码(OMXML 2.0)是SOS 2.0中观测数据的唯一强制格式:
或许可以支持其他响应格式。但是，需要在本文的特定扩展中描述如何支持这些格式
（3） Exceptions
清单1:适用于GetCapabilities操作的异常代码
MissingParameterValue
InvalidParameterValue
VersionNegotiationFailed
InvalidUpdateSequence
OptionNotSupported
NoApplicableCode
InvalidRequest
RequestExtensionNotSupported
（4） Examples
示例3这个操作的XML实现的一个示例请求可以在这里找到:
http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1.xml
示例4此操作的XML实现的响应示例如下:
http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1_response.xml
2、DescribeSensor Operation
DescribeSensor操作允许检索与SOS关联的过程(或:传感器)的元数据描述。虽然GetCapabilities请求的响应列出了与SOS相关的过程，但随后可以使用DescribeSensor操作检索列出的过程的详细定义。此操作的定义见[OGC 09-001]第11条。
示例5可以在这里找到此操作的XML实现的示例请求
http://schemas.opengis.net/sos/2.0/examples/core/DescribeSensor1.xml
3、GetObservation Operation
GetObservation操作用于查询SOS，检索根据O&M规范结构化的观测数据。可以使用其他响应格式;然而，O&M是每个SOS服务器的默认和强制格式。GetObservation操作的几个参数允许对SOS服务器请求的观察结果进行广泛的过滤。
GetObservation操作的概念模型如下面的UML图所示。
（1）请求
GetObservation操作请求包含约束要从SOS检索的观察值的参数。这个子句描述了发出有效的GetObservation请求的要求。
GetObservation数据类型派生自OGC 09-001中定义的SWES ExtensibleRequest数据类型，并继承其属性
此结构的具体表示取决于所选协议绑定。
例如，根据需求30，如果省略时间过滤器，SOS服务器将向客户机返回所有时间的观察结果。
注:如果GetObservation请求的响应太大，无法合理地发送给客户机，SOS服务器的实现可能返回[OGC 09-001]第15条中指定的异常消息。
由需求29和需求30产生的示例6的抽象GetObservation请求如下所示:
该请求返回所有offerings、所有时间和所有空间范围的观测值，这些观测值是为“weather_station_in_my_backyard”感兴趣的特性而提供的，并携带由传感器“温度计”或“风速表”所测得的“温度”属性的结果。
注:SOS返回的观测值可以用不同的观测类型和结果类型进行编码。对于客户机，这样的响应很难解析。这里不讨论这个问题。将来可以通过一个扩展来解决这个问题，该扩展只允许请求特定的观察/结果类型。但是，这种机制会将观察/结果类型转换的负担放在SOS服务器上。
有必要在GetObservation请求模型和底层SOS数据模型之间建立一个链接
注意，在基于XML的SOS实现中，过滤器上下文可以通过XPath表达式定义——参见第13.1小节中的表48。
示例7 SOS接收到一个GetObservation请求，该请求通过指向Offering12849(属于observationoffer类型)对象，根据给定的offer过滤返回的观察结果。服务确定该特定对象是否包含在服务的功能内容部分中列出的产品集中。如果包含offering，那么服务将在GetObservationResponse中包含属于它的观察值。
示例8 SOS接收一个GetObservation请求，该请求通过指向FeatureA和FeatureB(都是GFI_Feature类型)，根据给定的感兴趣的特性过滤返回的观察结果。服务将只包含响应中那些将FeatureA或FeatureB作为其featureOfInterest属性值的观察结果。
（2）响应
这个小节描述了响应GetObservation请求时对SOS 2.0服务的要求
注意:在SOS 1.0版本中，GetObservation操作有时不仅用于检索与请求条件匹配的观察值(这也是SOS 2.0中操作的默认行为)，还用于对观察结果进行子集，只列出与请求中提供的observedProperty值匹配的(通常是SWE公共编码的)组件。由于SOS 2.0没有绑定到特定的结果格式，因此它不执行这种子集设置和重新构造。根据行为可以通过附加的一致性类来定义，作为对SOS 2.0核心的扩展。SWES ExtensibleRequest和ExtensibleResponse数据类型中提供的扩展点可以支持这种功能。
SOS GetObservationResponse数据类型源自OGC 09-001中定义的SWES ExtensibleResponse数据类型，并继承其属性
（3）Exceptions
注意:如果客户端接收到一个 ResponseExceedsSizeLimit异常作为对GetObservation请求的响应，它应该尝试将请求的观察集分割成更小的块，并通过使用参数的大量GetObservation请求来查询它们。例如，请求可以通过GetObservationRequest应用时间分区。temporalFilter属性。服务还可以支持其他操作来检索关于存储的观察数据的元数据，例如由给定过程生成的时间范围的观察数据。
清单2:适用于GetObservation操作的异常代码
- MissingParameterValue
- InvalidParameterValue
- OptionNotSupported
- Requirement
- NoApplicableCode
- InvalidRequest
- RequestExtensionNotSupported
- ResponseExceedsSizeLimit
（4）示例
- Example 9 An example request and response of the XML implementation of the GetObservation operation with a specified observedProperty and temporalFilter can be found here:
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps_response.xml
- Example 10 An example request and response of the XML implementation of the GetObservation operation with a specified observedProperty and procedure can be found here:
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure_response.xml
- Example 11 An example request and response of the XML implementation of the GetObservation operation with a specified observedProperty, procedure and featureOfInterest can be found here:
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter_response.xml
- Example 12 An example request and response of the XML implementation of the GetObservation operation with a specified observedProperty, procedure and spatialFilter can be found here:
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter_response.xml
4、编码
SOS在几个地方使用代码值，例如标识可以提供观察的格式，以及支持哪些概念类型来表示感兴趣的特性、观察和观察结果。
该标准重用SWE服务模型[OGC 09-001]定义的代码类型，但也使用以下定义的其他代码类型。
代码包的概念模型如下面的UML图所示
图中所示的ValueCode代码列表是空的，因为它定义了一组不受限制的可能的代码值。下面将解释包中包含的每个代码列表的详细信息以及一些示例代码值
（1）值代码
此代码列表是根据SWE服务模型[OGC 09-001]的公共代码包中定义的代码列表建模的。因此，分配给它的所有代码值都是uri。
有几种方法可以识别在概念模型中定义的类型：
- 模型本身可以为该类型分配唯一标识符。
例如:http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation
- 类型可以唯一标识通过模型的名称空间的组合,包的完整路径,其中包含的类型和类型的名字。
例如:http://www.isotc211.org/19103/2003/BasicTypes/Derived/UnitsOfMeasure/Measure,http://www.isotc211.org/19103/2003/BasicTypes/Primitive/Truth/Boolean
- 在概念模型和一些实现代码之间存在直接映射关系，比如，XML编码和映射类型可以在编码中被唯一标识。
在XML编码中，这可以是分配给类型的XML名称空间和元素名称(或者，如果不可用，则是复杂/简单类型名称)的组合。例如:http://www.opengis.net/swe/2.0/Quantity,http://www.opengis.net/gml/3.2/measure
下表列出了ValueCode列表的一些代码值及其定义和含义。对该规范的扩展可以定义其他代码
411
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
