MS RFC 13:MapServer中的传感器观测服务支持

日期

2006／02／21

作者

叶旺沃森阿塞法

联系方式

位于dmsolutions.ca的Yassefa

状态

通过

概述

这是第一次尝试在MapServer中支持部分OGC传感器Web启用（SWE）。围绕SWE制定的不同规范如下：

  • 传感器观测服务（SOS）：提供用于管理已部署传感器和检索传感器数据的API。

  • 观测和测量：观测和测量的信息模型和编码。

  • 传感器警报服务：一种客户机可以注册和接收传感器警报消息的服务。该服务支持预定义警报和自定义警报，并涵盖警报发布、订阅和通知的过程。

  • 传感器模型语言：用于发现、查询和控制网络驻留传感器的信息模型和XML编码。

  • 传感器规划服务：一种服务，通过该服务，客户可以确定一个或多个移动传感器/平台所需收集请求集的收集可行性，或者客户可以直接向这些传感器/平台提交收集请求。

  • 传感器标记语言（TML）：传感器（接收器和发射器）的一般特性

  • Web通知服务：为长时间异步进程执行和管理客户端和Web服务之间的消息对话。

这里的目的是支持SoS强制操作。请参考OGC网站（https://www.opengeospatial.org/domain/swe/）了解有关SWE计划的更多详细信息。

用户界面

从用户的角度来看，SoS接口将提供三个核心操作（getCapabilities、getObservation和describeSensor）。有关可用内容的完整描述，请参见 Annexe A : Sensor Observation System (SOS) support in MapServer .

MapServer中的更改

  • 所有开发都将本地化为mapogcsos.c文件。

  • 将在mapows.c/h文件中添加一些内容，以集成请求的分派。

  • 在mapgml.c（函数msgmlwritewfsquery）中，提取将功能（gml:featuremember）写入单独函数的循环，以便getObservation也可以使用它来输出结果。

  • 当使用标记use-sos构建mapserver时，SoS功能将可用。

MapScript含义

对于mapscript模块来说不是特殊含义

其他库

生成getCapabilities文档时，将尝试使用libxml2（http://xmlsoft.org/）库。决定进行将基于易用性和输出速度。

测试

建议将带有map/data/预期结果的自动测试添加到msautotest项目中，以测试getcapabilities和getobservation请求。

投票历史

  • +1：阿塞法、温格默丹、纳西奥纳尔

  • +0 : Morissette

  • -0 : Gillies

注解

MAPServer开发列表中提供了讨论和关注（2006年2月RFC 13:SoS支持）

附录A:MAPServer中的传感器观测系统（SOS）支持

这是首次尝试定义MAPServer将支持哪些功能，以便能够部署传感器观测系统（SOS）

使用的规范和有用链接：

SoS提供多个操作，分为核心强制操作（getCapabilities、describeSensor和getObservation）和可选的事务和增强操作。MAPServer中的第一个SoS实现将只处理核心操作

** 1。获取能力请求**

getCapabilities请求将使用以下参数：

  • 请求：固定在getcapabilities

  • 服务：固定在SOS

** 2。getCapabilities返回文档**

附在文档末尾的getCapabilities文档示例。以下元素是能力文档中包含的SoS项，具有等效的MapServer实现

  • 服务标识（所有元素都从Web级别的元数据中提取）

    • 标题：从Web级别的OWS/SOS标题的元数据中提取。与WMS/WFS相同的概念

    • 摘要：元数据OWS/SOS摘要

    • 服务类型：固定到SoS

    • 服务类型版本：固定为0.3

    • 费用：元数据OWS/SOS费

    • 访问约束：元数据：OWS/SOS_约束

  • 服务提供者（所有元素都是从Web级别的元数据中提取的，使用等效的名称作为sos元素）

    • ProviderName：

    • ProviderSite

    • IndividualName

    • PositionName

    • 声音

    • 传真

    • DeliveryPoint

    • 西蒂

    • AdministrativeArea

    • PostalCode

    • 国家

    • ElectronicmailAddress

    • EndAddress

    • OnlineResource

    • HoursOfService

    • ContactInstructions

  • 操作元数据：这部分功能定义了将支持的操作，即getCapibilities和getObservation。有关详细信息，请参阅https://svn.opengeospatial.org:8443/ogc-projects/ows-3/schema4demo/ows/1.0.30/owsoperationsmetadata.xsd

    • 操作：获取能力

      • 操作名称：固定在getcapabilities

      • HTTP:已提取连接点URL。仅支持get-request方法

      • 参数：包括名称和版本。我们可以使用这些参数来传播服务SOS的名称和版本。如果需要，可以添加其他参数。

    • 操作：获取观察

      • 操作名称：Fixed GetObservation

      • DCP（HTTP）：从元数据中提取

      • 参数：我们可以使用它来传播执行getObservation请求时所需的参数（providing、eventtime）

    • 操作：描述传感器

  • 过滤能力

    将支持的筛选功能与MapServer中当前支持的功能相同（请参见 WFS筛选器编码 更多信息：空间能力、逻辑运算符、比较运算符

    在OGC过滤器时间功能的规范中有一个提到，但是我找不到它的确切定义。无论如何，

  • SoS内容（观察产品）

    正如SoS规范（第6.2节）中所解释的，“…观察产品也类似于Web地图服务中的一个层，因为每个产品都是一组不重叠的相关观察产品。每个观测提供都受到许多参数的限制，包括传感器系统，报告观测、时间、现象、地理区域…“

    在MapServer中，将使用Mapserer的Group参数用一组层表示产品。与组关联的元数据（产品将从组的第一层获取）

    将在组级别设置以下属性。

    • 标准属性

      • ID：唯一的产品标识符。强制性的

      • 名称：与产品一起使用的名称。可选的

      • 说明：产品说明。可选的

    • 限定于：用于定义产品的地理边界。它应该从元数据中提取。强制性的

    • EventTime：用于定义产品的有效时间范围。它应该从元数据中提取。强制性的

    • 过程：一系列URL引用了一个或多个系统，这些系统在产品中提供观察结果。它应该从元数据中提取。强制性的

  • 观察属性：可在本产品中要求的观察/现象。

    规范中确定了两个专业：

    • 约束：通过添加单个约束来修改基础现象（例如，地表水温度添加深度介于0-0.3之间的约束）

    • 复合物是一种复合物（一组可能或不可能相互关联的成分现象）或将一个或多个约束列表应用于基本现象的现象集。

    对于MapServer，没有明确的切割指示哪种表示更自然，但是如果我们考虑组/层/属性组合，我们可以看到一组层可以表示产品，一个层将是观察到的属性（或现象），属性将是定义该现象的复合现象。

    能力文档将包括compositephenomenontype元素，该元素具有标识现象的强制ID元素和可选元素，如名称和组件。

  • 感兴趣的特征

    规范中给出的定义是：这是一个单一特征或一组特征，代表传感器系统在其上进行观测的对象。对于现场传感器，这可能是一个与传感器相连的站点，或者是其周围的大气。对于远程传感器，这可能是作为传感器的区域或体积。它由GML特征类型表示，并应包括边界框范围。

    在这里，这相当于前面定义的“bounded by”元素。

    注意，在MAPServer的实现中，假设用于表示单个传感器的地理信息表示感兴趣的传感器特征。这是一个能够进行空间查询的需求。

  • 结果格式

    将返回到GetObservation请求的结果的mime类型。固定为text/xml；subtype=“om1.0.30”

** 3。获取观察请求**

使用get方法将支持用于检索观测数据的get observation请求。第一个实现中将不支持Post方法。

以下是将支持的参数及其定义：

  • 产品：等同于功能中标识的产品ID（强制）

  • EvetntTime：单个时间或时间段。这将用作时间过滤器，以使用标识的时间属性进行查询。（可选）

  • ObservedProperty：标识MapServer中的层（强制）

  • Interest特性：使用bbox的附加地理过滤器。（可选）

  • 结果：将使用OGC过滤器支持的功能进行过滤。

** 4。获取观察响应**

观察响应应包含以下信息：

  • 描述产品的信息

  • 有效时间（实例或周期）

  • 现象描述（如发售名称）

  • 发行感兴趣的地点和特征

  • 与产品相关的结果

在MapServer实现的情况下，建议返回一个反映查询结果的观察集合。以下是返回的不同元素：

  • 名称：产品唯一标识符

  • 说明：产品说明

  • 时间：有效时间实例或周期

  • 利益特征：本次发行涉及的地域范围

  • 成员：对返回的所有观察结果重复此操作。以下是每个成员的参数

    • 观察性质：观察到的现象

    • 位置：地理坐标

    • 程序

    • 结果：观察结果。在第一个实现中，建议返回gml:feature成员。这使得可以以易于操作的格式返回一个/多个属性值。将等效于WFS中返回的gml:feature成员。

5.描述传感器

描述传感器请求使用两个参数，即传感器ID（强制）和可选输出格式。

在此阶段，描述传感器将使用在层上设置的URL类型的元数据，并中继请求。在这个实现中，不会在MapServer中生成任何sensorML输出。

** 6。例子**