-
Notifications
You must be signed in to change notification settings - Fork 91
Re-introduce GeoJSON conversion under a flag #1020
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 8 commits
6a8fa69
a8456b2
3892f4f
3d6ec0b
f4795e8
d8506fd
5d82f8e
41333d5
9417381
9d01da9
2370063
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -46,10 +46,10 @@ curl http://${KEYSTONE_HOST}/v3/OS-TRUST/trusts \ | |
| Apart from the generation of the trust, the use of secured Context Brokers should be transparent to the user of the IoT | ||
| Agent. | ||
|
|
||
| ### GeoJSON support (this only applies for NGSI-LD, not for NGSIv1 and NGSIv2) | ||
| ### GeoJSON support | ||
|
|
||
| The defined `type` of any GeoJSON attribute can be any set to any of the standard NGSI-v2 GeoJSON types - (e.g. | ||
| `geo:json`, `geo:point`). NGSI-LD formats such as `GeoProperty`, `Point` and `LineString` are also accepted `type` | ||
| The defined `type` of any GeoJSON attribute can be any set to any of the standard **NGSI-v2** GeoJSON types - (e.g. | ||
| `geo:json`, `geo:point`). **NGSI-LD** formats such as `GeoProperty`, `Point` and `LineString` are also accepted `type` | ||
| values. If the latitude and longitude are received as separate measures, the | ||
| [expression language](expressionLanguage.md) can be used to concatenate them. | ||
|
|
||
|
|
@@ -69,15 +69,16 @@ values. If the latitude and longitude are received as separate measures, the | |
| } | ||
| ``` | ||
|
|
||
| For `attributes` and `static_attributes` which need to be formatted as GeoJSON values, three separate input formats are | ||
| accepted. Provided the `type` is provisioned correctly, the `value` may be defined using any of the following formats: | ||
| For `attributes` and `static_attributes` which need to be formatted as GeoJSON values, three separate input | ||
| formats are accepted. Provided the `type` is provisioned correctly, the `value` may be defined using any of | ||
| the following formats: | ||
|
|
||
| - a comma delimited string | ||
| - a comma delimited string | ||
|
|
||
| ```json | ||
| { | ||
| "name": "location", | ||
| "value": "23, 12.5" | ||
| "name": "location", | ||
| "value": "23, 12.5" | ||
| } | ||
| ``` | ||
|
|
||
|
|
@@ -102,6 +103,27 @@ accepted. Provided the `type` is provisioned correctly, the `value` may be defin | |
| } | ||
| ``` | ||
|
|
||
| Because GeoJSON types (e.g. `Point`, `LineString` etc.) are native types in **NGSI-LD**, automatic GeoJSON conversion is switched on for NGSI-LD by default. | ||
|
|
||
| With **NGSI-v2**, for backwards compatibility reasons, automatic GeoJSON conversion for types other than `geo:json` is turned off by default. | ||
| Add the `autocastGeoJSON` configuration to the attribute to enable GeoJSON conversion. Each GeoJSON attribute can be provisioned as shown: | ||
|
|
||
| ```json | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This example in documentation is for a configuration group. However, the templates modified in this PR are only about devices: The behavior should be as follow:
|
||
| { | ||
| "entity_type": "GPS", | ||
| "resource": "/iot/d", | ||
| "protocol": "PDI-IoTA-JSON", | ||
| ..etc | ||
| "attributes": [ | ||
| { | ||
| "name": "observationSpace", | ||
| "type": "Polygon", | ||
| "autocastGeoJSON" : "true" | ||
| } | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the following syntax would be better: So the way in which the autocast is done depends on the Maybe it would even better to have a The |
||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| ### Metadata support | ||
|
|
||
| Both `attributes` and `static_attributes` may be supplied with metadata when provisioning an IoT Agent, so that the | ||
|
|
@@ -149,7 +171,7 @@ following: | |
| - Temporal Properties (e.g. `Datetime`, `Date` , `Time`) | ||
| - GeoJSON types (e.g `Point`, `LineString`, `Polygon`, `MultiPoint`, `MultiLineString`, `MultiPolygon`) | ||
|
|
||
| Most NGSI-LD attributes are sent to the Context Broker as _properties_. If a GeoJSON type or native JSON type is | ||
| Most **NGSI-LD** attributes are sent to the Context Broker as _properties_. If a GeoJSON type or native JSON type is | ||
| defined, the data will be converted to the appropriate type. Temporal properties should always be expressed in UTC, | ||
| using ISO 8601. This ISO 8601 conversion is applied automatically for the `observedAt` _property-of-a-property_ metadata | ||
| where present. | ||
|
|
@@ -183,12 +205,11 @@ Other unrecognised `type` attributes will be passed as NGSI-LD data using the fo | |
| } | ||
| ``` | ||
|
|
||
|
|
||
| ### NGSI-LD Linked Data support | ||
|
|
||
| `static_attributes` may be supplied with an additional `link` data element when provisioning an IoT Agent to ensure that | ||
| active attributes from the provisioned IoT Device may be maintained in parallel with a linked data entity . Take for | ||
| example a temperature gauge placed within a building. The **Device** data model literally represents the IoT device | ||
| itself, but the `temperature` attribute also needs to be shared with the **Building** entity | ||
| `static_attributes` may be supplied with an additional `link` data element when provisioning an IoT Agent to ensure that active attributes from the provisioned IoT Device may be maintained in parallel with a linked data entity . Take for example a temperature gauge placed within a building. | ||
| The **Device** data model literally represents the IoT device itself, but the `temperature` attribute also needs to be shared with the **Building** entity | ||
|
|
||
| A `link` between them can be provisioned as shown: | ||
|
|
||
|
|
@@ -222,8 +243,7 @@ e.g.: | |
| } | ||
| ``` | ||
|
|
||
| Whenever a `temperature` measure is received **Device** is updated, and entity `urn:ngsi-ld:Building:001` is also | ||
| updated as shown: | ||
| Whenever a `temperature` measure is received **Device** is updated, and entity `urn:ngsi-ld:Building:001` is also updated as shown: | ||
|
|
||
| ```json | ||
| "temperature": { | ||
|
|
@@ -292,7 +312,7 @@ The library provides some plugins out of the box, in the `dataPlugins` collectio | |
| use the `addQueryMiddleware` and `addUpdateMiddleware` functions with the selected plugin, as in the example: | ||
|
|
||
| ```javascript | ||
| var iotaLib = require('iotagent-node-lib'); | ||
| var iotaLib = require("iotagent-node-lib"); | ||
|
|
||
| iotaLib.addUpdateMiddleware(iotaLib.dataPlugins.compressTimestamp.update); | ||
| iotaLib.addQueryMiddleware(iotaLib.dataPlugins.compressTimestamp.query); | ||
|
|
@@ -302,7 +322,7 @@ iotaLib.addQueryMiddleware(iotaLib.dataPlugins.compressTimestamp.query); | |
|
|
||
| This plugins change all the timestamp attributes found in the entity, and all the timestamp metadata found in any | ||
| attribute, from the basic complete calendar timestamp of the ISO8601 (e.g.: 20071103T131805) to the extended complete | ||
| calendar timestamp (e.g.: +002007-11-03T13:18). The middleware expects to receive the basic format in updates and return | ||
| calendar timestamp (e.g.: `+002007-11-03T13:18`). The middleware expects to receive the basic format in updates and return | ||
| it in queries (and viceversa, receive the extended one in queries and return it in updates). | ||
|
|
||
| ##### Attribute Alias plugin (attributeAlias) | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| { | ||
| "location": { | ||
| "value": "23,12.5", | ||
| "type": "Point" | ||
| } | ||
| } | ||
|
|

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this PR provides "the definitive fix" mentioned in #1012 (comment)
Thus, an entry in CHANGES_NEXT_RELEASE relating issue #1012 should be included.