传感器观测服务接口标准之十

　　　　　　　传感器观测服务标准接口

版权声明：本文为博主翻译文章，转载请附上出处链接https://blog.csdn.net/qq_21225505/article/details/86597680

上一篇：传感器服务接口标准之九

十五、附件Ｂ：　 Identifier Handling (informative)

本附件描述了与SOS相关的各种资源的标识符的处理。 SWE服务中标识符的一般用法在SWE服务模型标准[OGC 09-001]的第16章中描述，该标准作为本规范的基础。

SWE服务模型定义每个对象类型（例如，过程类型，观察属性或观察）具有标识。 与GML不同，SWES对象不一定具有在XML实例文档中提供标识的XML属性（参见[OGC 09-001]中的第24.2.4.1节），因为SWES不能依赖于这些对象的单个数据编码。 相反，SWES定义服务的责任是为所有可引用的元素分配和维护标识符（使用xlink：来自其他元素的href）

此外 - 如[OGC 09-001]中的第16.3.1节所述 - 每个SWES对象都有一个标识符属性，该属性在UML模型中定义为ScopedName类型，并在XML Schema中编码为类型xs：anyURI。 因此，可以通过单个URI唯一地标识SWES对象。

但是，请注意，GML功能标识符不是这种情况，GML功能标识符（以XML格式）编码为带有codeSpace（类型为xs：anyURI）属性的gml：identifier元素和类型为xs：string的元素值。 这在[OGC 09-001]第16.3.1节中有更详细的解释。 由于映射SOS操作请求属性（从UML模型到XML架构标识/指向GML特征）的性质，客户端只能使用单个URI值来标识SOS操作请求中的GML特征。 因此，SOS的默认行为是忽略gml：identifier的codeSpace，并仅使用gml：identifier的元素值执行给定URI的相等性检查。 SOS应确保其管理的GML要素的gml：identifier元素值（例如观察及其感兴趣的特征）是唯一的 - 至少在服务范围内。
　　　B.1 Identifying a Procedure

O＆M模型中的观察过程是OM_Process类型。 在SOS的服务模型中，OM_Process类型在观察产品中用于列出与SOS托管的观察相关联的过程。
OM_Process的实际编码是未知的，可以是任何内容，从任何GML应用程序模式的SensorML到一些新的传感器描述格式。 因此，我们不能依赖于在其编码中找到过程的标识符。 即，SOS实现不可能对给定OM_Process编码内的标识符值进行通用搜索（除非SOS遵循可能编码的域特定限制）。 因此，在使用InsertSensor操作成功将过程/传感器插入SOS后，SOS返回一个新创建的指针用于此过程（参见[OGC 09-001]中的第13.2.3节）。

这个新创建的指针是SOS用于解决该过程的标识符（URI）。 因此，当为新的过程向SOS插入新的观察时，需要指定其标识符。 因此，过程标识符被指定为观察的过程元素的xlink：href属性的值。 因此，存储在OM_Observation / procedure / @ xlink：href中的值应与插入观察值的观察提供程序的标识符相同。 该标识符在SOS的Capabilities中的ObservationOffering / procedure元素中给出。

过程的标识符可以但不需要作为标识符包含在实际过程描述中。 标识符值可以包含在例如gml：identifier或其他字段中 - 这取决于给定过程描述的实际编码。 由于过程描述的各种可能的编码，编码中的标识符的包含可能是不可能的。

B.2 Identifying an Observation Offering 

如本文件的要求21所述，SOS应为其每个观察产品分配唯一的标识符值。 使用InsertSensor操作插入传感器/过程时，将创建新的产品。 在XML编码中，提供标识符（URI）包含在sos的swes：identifier属性中：ObservationOffering包含在Capabilities的contents部分中．

B.3 Identifying an Observed Property

GFI_PropertyType类型的（观察的）属性资源的标识符处理类似于OM_Process对象的标识符处理。 属性的编码是未知的，因此GFI_PropertyType的编码中的标识符可以是任何内容。 因此，不可能在给定的GFI_PropertyType实例中搜索标识符。
但是，不同之处在于SOS不需要管理实际资源。 GFI_PropertyType类型的每个属性的值始终是指向实际GFI_PropertyType资源的/指针的标识符。

GFI_PropertyType实例的标识符（URI）用作以下值：

• sos中的observedProperty元素：ObservationOffering
• OM_Observation中observedProperty元素的xlink：href属性

B.4 Identifying a Feature of Interest

对于感兴趣的特征，其他可识别类型存在很大差异。 由于感兴趣的特征总是GFI_Feature类型（XML编码为AbstractFeature的子类型），因此其编码支持gml：identifier属性。 因此，当SOS通过InsertObservation或InsertResultTemplate操作插入SOS时，可以找到感兴趣特征的标识符。
但请注意，感兴趣的功能不一定包含gml：identifier值。 观察发布者有责任提供这些标识符。 如果感兴趣的特征没有gml：标识符值并且客户端请求（例如GetObservation请求）包含感兴趣的特征标识符列表，则该感兴趣的特征将不匹配该请求（因为它不能与标识符匹配） 过滤器）因此不会包含在响应中。

在将观察结果插入SOS时，观察的感兴趣特征可以在观察实例内联编码或作为参考给出。
每当感兴趣的特征通过引用给出时，不建议SOS实现存储特征实例，而是应该存储属性OM_Observation / featureOfInterest / @ xlink：href中给出的引用。 然后，如果SOS需要由于操作请求而搜索特定的兴趣标识符，则该服务将需要解析该引用并检查所引用特征的gml：identifier值。 这是必要的，因为该特征在SOS之外被管理并且因此可以在SOS不知道的情况下被改变。

B.5 Identifying an Observation

在O＆M数据模型的XML实现中，观察的标识符存储在gml：identifier属性中（忽略codeSpace属性）。 每当标识符请求观察时（例如，通过GetObservationById操作），SOS实现必须在所有可用观察的gml：identifier字段中搜索以响应该请求。

 

十六、附录ｃ　Phenomena and Units of Measure (informative)

 

C.1 Identifying and referencing Phenomena and Units of Measure

互操作性的一个关键问题是定义一种标准方法来引用传感器测量的现象和这些现象的测量单位。这对于（i）在目录中发现SOS服务实例以及（ii）将请求参数化给提供所选观察属性的给定服务实例是重要的。由于SOS旨在用于大量应用领域中的各种应用，因此为现象和度量单位构建单一的综合性和权威性词典是不可行的。可观察现象包括所有应用程序域中所有要素类型的大多数属性（请参阅O＆M）。不同现象和计量单位的范围很大，先验未知，实际上既不可知也不可计算。现象和度量单位通常特定于给定的域，用于引用它们的机制必须支持分散的方法。
　　　　SOS和SWE的一个目标通常是指定一种标准机制，用于一致地识别现象和度量单位，这些现象和度量单位将扩展（向上或向下）以处理任何应用程序域中的任意数量的定义。识别现象和测量单位的机制必须足够灵活，以应对这种情况。
识别现象和测量单位的解决方案是使用外部参考。这些可以利用包括语义web表示在内的各种技术来解析以各种形式表达的资源。 GML字典提供了相对轻量级的格式，与SOS使用的数据和基于Web的寻址模式的GML表示兼容。服务和客户端使用URI来引用特定GML字典中的特定条目。
　　　　如果引用是由OGC字典或由另一个知名组织托管的字典定义的现象或度量单位，则URI可能是URN。使用OGC作为权限的URN值必须遵循OGC文档06023r1中指定的格式 - OGC名称空间中的定义标识符URN。

当引用是新的或非标准的定义时，可以使用URL，例如，在服务提供其自己的字典或使用未知的第三方字典的情况下。 如果特定定义是作为单个资源提供的字典中的子元素，则其URL必须包括片段标识符或XPointer以在字典中定位定义。

C.2 Describing and defining Phenomena and Units of Measure

像计量单位和现象这样的实体不是现实世界中的物理对象。它们是概念，只能通过约定或与其他无形概念的关系来定义。参考其他类型定义的现象或度量单位可以被认为是派生的或受约束的实体，并且可以从更基本的实体导出。现象和度量单位等概念在信息建模层次结构中占据不同的元级别，与“实例”级别数据（如观察和传感器实例）相比，它们的定义通常需要更严格的治理安排。因此，理想情况下，它们将在注册表环境中进行管理。 GML字典表示可以被认为是通常由服务提供的这种资源集合的“静态”视图，例如寄存器或目录。
　　　SWE计划依赖于现有的GML支持来识别或定义测量单位。这是基于基础，派生和“其他”（或“常规”）单位的通常层次结构，例如由Systeme International定义的单位。用于导出单元的机制是明确定义的，并且可以使用软件自动完成，只要通常理解基本单元即可。但是，理想情况下，使用UCUM符号。
　　　作为SWE计划的一部分，开发了用于描述通过组合和/或约束基础现象而导出的现象的GML一致模式。这种模式允许基本现象的定义与基本单位在GML中定义的方式非常相似。衍生现象可以发展为对现有现象的约束，现有现象的聚合，或者作为现有现象的组合。 SensorML 1.0.1包含用于描述此类现象的模式。

 

十七　附录Ｃ　 Relationship to Other OGC Web Service Standards (informative)

本附件描述了SOS与其他OGC服务规范的关系，这些规范也用于分发地理空间数据。 现在只描述与Web要素服务（WFS）的关系。

D.1与Web要素服务的关系

在SOS的开发中采用的方法，以及它所依赖的SWE规范，是以这样一种方式仔细建模传感器，传感器系统和观测，模型涵盖了所有类型的传感器并支持所有传感器的要求。传感器数据的用户。 SOS利用这两种数据类型（传感器，观测）的标准属性为观测数据提供专门的操作签名。
　　　这可能与Web要素服务（WFS）中采用的方法形成对比。 WFS基于地理特征的通用定义，该定义足够灵活，可以包含任何现实世界实体，并使用GML应用程序模式来定义特定服务实例公开的特征类型。因此，WFS“获取数据”请求是高度参数化的，因为它必须是完全通用的。通过这种方法，互操作性要求组织就特定于域的GML应用程序模式达成一致。在特定域中访问WFS以进行丰富处理的客户端必须具有该域中使用的应用程序模式的先验知识。
　　　SOS定义了所有传感器，传感器系统及其观测的通用模型。此模型是“水平”的，因为它适用于使用传感器收集数据的所有域。特定于域的细节被封装在第二层（感兴趣的特征，观察到的特性，传感器描述）中，允许通用客户端处理基本的“观察”。从这个意义上讲，SOS还提供了对观察数据和元数据的功能丰富的访问。

图17-1和图17-2包含两个如何耦合SOS和WFS的简单示例。 在第一个图中，SOS提供了针对某些感兴趣特征在O＆M观测中编码的动态属性值。 这些功能由外部WFS提供。 例如，SOS为某个湖泊提供表面温度。 然后，动态表面温度值由SOS提供，而感兴趣的特征（湖）由WFS实例提供。 如上所述，使用SOS的优点在于它以明确定义的O＆M格式提供表面温度值及其元数据，并且可以使用预定义的过滤器（例如时间，结果质量或生产过程）来代替 用于检索观察的WFS的通用GetFeature操作。

图17-2显示了耦合SOS和WFS实例的另一种可能性。在这种情况下，SOS在后端使用WFS来处理感兴趣的功能。 SOS提供了观察以及感兴趣的特征。在上面的示例中，客户可以从相同的SOS实例检索表面温度观测值以及感兴趣的特征湖。通过SOS接口检索感兴趣的特征的操作保持简单，因为只有一组有限的查询参数。
上面的两个例子指出，您不想使用SOS或WFS，而是如何组合或耦合这两种服务的问题。如上所述，SOS描述了具有来自O＆M规范的预定义观察特征类型的WFS简档以及用于检索这些观察的专用操作签名。 O＆M特征数据的专业化还使SOS能够在服务元数据文档中提供服务存储的观察的更详细摘要。这使注册管理机构能够收集信息，从而改进观察数据的发现。它还使客户能够生成并执行更明智的请求以检索观察数据。通常，SOS用于以时间序列的形式为某些感兴趣的特征提供动态属性值。这些感兴趣的功能可以由SOS实例本身（通过GetFeatureOfInterest操作）或外部WFS提供。