エンティティのジオローカリゼーション

プラットフォームはエンティティのジオローカライゼーションを可能にします。言い換えれば、エンティティは、次のタイプのうち、エンティティのロケーションとして解釈される値を持つ属性を持つことができます :

  • ポイント : たとえば、ある都市を移動する Car エンティティをモデル化する
  • ライン: 例えば、ストリート・エンティティをモデル化する
  • 任意の数の頂点を有するポリゴン : 例えば都市近所をモデル化する
  • 任意の GeoJSON

エンティティのロケーションは、Context Broker によって公開される Data API によって管理されます。NGSIv2仕様の "エンティティのジオスペース特性" のセクションを参照してください。次の例は、地球上のテネリフェ島の表面におおよそ対応する、特定のエンティティ(その id が 'Tenerife')の location 属性を設定する方法を示しています :

PATCH /v2/entities/Tenerife/attrs/location
Content-Type: application/json

{
  "value": [ "28.362, -16.883", "28.003, -16.693", "28.552, -16.136", "28.520, -16.418", "28.396, -16.641", "28.362, -16.883" ]
  "type": "geo:polygon"
}

プラットフォームに接続され、IoT Agents によって管理されるデバイスに対応するエンティティに関しては、モデル変換機能を使用し、geo:point' として、それらをジオロケーションすることができます。[通知シナリオ(how_notifications_work.md)に示されているのと同じシナリオを想定しましょう。センサ情報は、latitude, longitude` 形式で直接、または別々に、式を使用してジオポイントに情報を結合することでレポートできます。そのためには、この新しい情報を反映するために、車のプロビジョニングを変更する必要があります。センサ情報が以下を使用して送信される場合 :

POST /iot/services
Content-Type: application/json
Fiware-service: smartown
Fiware-servicepath: /roads

{
  "services": [
    {
      "protocol": [
              "IoTA-UL"
            ],
      "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
      "entity_type": "Car",
      "attributes": [
        {
          "object_id": "s",
          "name": "speed",
          "type": "Number"
        },
        {
          "object_id": "la",
          "name": "latitude",
          "type": "Integer"
        },
        {
          "object_id": "lo",
          "name": "longitude",
          "type": "Integer"
        },
        {
          "name": "location",
          "type": "geo:point",
          "expression": "${latitude}, ${longitude}"
        }
      ]
    }
  ]
}

この構成では、車からの情報を次の要求で報告することができます :

POST /iot/d?k=801230BJKL23Y9090DSFL123HJK09H324HV8732&i=BCZ6754
Content-Type: text/plain

s|55|la|40.392|lo|-3.759

これは、式によって定義されるように、location 属性の値に 40.392, -3.759 を設定し、Context Broker に更新要求を生成する。

エンティティの場所が正しく設定されると、さまざまなプラットフォームのポイントで利用される可能性があります。特に :

  • Data API では、地理的クエリ (サブスクリプションフィルタの一部として、GET /v2/entities のような同期または非同期の両方)を使用します。NGSIv2仕様の "地理的クエリ" を参照してください。たとえば、マドリッドの市内中心部から15km離れたすべての Car デバイスを取得するには、次のクエリを使用できます。

    GET /v2/entities?type=Car&georel=near;maxDistance:15000&geometry=point&coords=40.418889,-3.691944 
Fiware-service: smartown
Fiware-servicepath: /roads

  • CEP API では、CEPはエンティティ・ポイント・ロケーション(ライン、ポリゴンなどの他の形状はまだサポートされていません)を処理することができます。そのため、緯度と経度は EPL 条件で簡単に使用できます。詳細は、CEPのドキュメント を参照してください。たとえば、次のルールは、location' 属性を持つエンティティがクエンカから 5km 以内にある場合に電子メールを送信します。これは、クエンカのUTMC座標であり、(a, b)が 618618.8286057833 と 9764160.736945232、dは5,000mの距離である、円方程式(x - a)^2 + (y - b)^2 = d^2` を使用します。

    {
    "name": "rule_distance",
    "text": "select *, \"rule_distance\" as ruleName from pattern [every ev=iotEvent(Math.pow((cast(cast(location__x?,String),float) - 618618.8286057833), 2) + Math.pow((cast(cast(location__y?,String),float) - 9764160.736945232), 2) < Math.pow(5e3,2))]",
    "action": {
        "type": "email",
        "template": "${id} (${type}) is at ${location__lat}, ${location__lon} (${location__x}, ${location__y})",
        "parameters": {
            "to": "someone@tid.es",
            "from": "system@iot.tid.es",
            "subject": "${id} is coming"
        }
    }
}

  • 永続性のバックエンド :

    • CKAN(列モード) : 2つの列(1つは緯度用、もう1つは経度用)を使用するか、または両方を単一の列に結合するかのどちらかを使用して、ロケーションを提供する2つの方法があります。詳しくは、Cygnusのドキュメントを参照してください。これは Data API のマーク・エンティティのロケーションの標準的な方法ではないことに注意してください(前述の"エンティティの地理空間プロパティ"のセクションを参照してください)、おそらく Carto 実験的永続sink と同様の方法で動作するようになります。

    CKAN grid view

    CKAN map view