Location type used in WeatherObserved data model cause error or StructuredValues

[ilarimikkonen]

We have been working on creating a data model.

QUESTION: Is the location structure specified in the https://github.com/FIWARE/data-models/tree/master/specs/Weather/WeatherObserved correct and if so, how should it be utilised? This question has arrived, since we have observed the following behaviour:

if this data is pushed:

curl --location --request POST 'https://context.domain.com/v2/entities' \
--header 'Authorization: Bearer c802f90d67f9e603bb507c8500f0dc70asdas' \
--header 'Content-Type: application/json' \
--header 'fiware-service: test \
--data-raw '{
    "id": "70B3D5A4D5110054",
    "type": "IotData",
    "dateObserved": {
        "type": "DateTime",
        "value": "2020-07-02T09:40:43+00:00"
    },
    "location": {
            "type": "geo:json",
            "value": {
                "type": "Point",
                "coordinates": [
                    2.73667,
                    39.5608
                ]
            }
        },
    "batteryLevel": {
        "value": 98
    },
    "humidity": {
        "value": 44
    },
    "temperature": {
        "value": 30.2
    }
}'

Everything is fine, but if this data (location block in JSON is changed, this is like in the WeatherObserved data model) is pushed:

curl --location --request POST 'https://context.domain.com/v2/entities' \
--header 'Authorization: Bearer c802f90d67f9e603bb507c8500f0dc70asdas' \
--header 'Content-Type: application/json' \
--header 'fiware-service: test' \
--data-raw '{
    "id": "70B3D5A4D5110054",
    "type": "IotData",
    "dateObserved": {
        "type": "DateTime",
        "value": "2020-07-02T09:40:43+00:00"
    },
    "location": {
        "type": "Point",
        "coordinates": [51.714306, 8.723663]
    },
    "batteryLevel": {
        "value": 98
    },
    "humidity": {
        "value": 44
    },
    "temperature": {
        "value": 30.2
    }
}'

error pops:

{
    "error": "BadRequest",
    "description": "unrecognized property for context attribute"
}

if data is pushed with options=keyValues:

curl --location --request POST 'https://context.domain.com/v2/entities?options=keyValues' \
--header 'Authorization: Bearer c802f90d67f9e603bb507c8500f0dc70asdas' \
--header 'Content-Type: application/json' \
--header 'fiware-service: test' \
--data-raw '{
    "id": "70B3D5A4D5110054",
    "type": "IotData",
    "dateObserved": {
        "type": "DateTime",
        "value": "2020-07-02T09:40:43+00:00"
    },
    "location": {
        "type": "Point",
        "coordinates": [51.714306, 8.723663]
    },
    "batteryLevel": {
        "value": 98
    },
    "humidity": {
        "value": 44
    },
    "temperature": {
        "value": 30.2
    }
}'

structuredValues are created:

[
    {
        "id": "70B3D5A4D5110054",
        "type": "IotData",
        "batteryLevel": {
            "type": "StructuredValue",
            "value": {
                "value": 98
            },
            "metadata": {}
        },
        "dateObserved": {
            "type": "StructuredValue",
            "value": {
                "type": "DateTime",
                "value": "2020-07-02T09:40:43+00:00"
            },
            "metadata": {}
        },
        "humidity": {
            "type": "StructuredValue",
            "value": {
                "value": 44
            },
            "metadata": {}
        },
        "location": {
            "type": "StructuredValue",
            "value": {
                "type": "Point",
                "coordinates": [
                    51.714306,
                    8.723663
                ]
            },
            "metadata": {}
        },
        "temperature": {
            "type": "StructuredValue",
            "value": {
                "value": 30.2
            },
            "metadata": {}
        }
    }
]

This will cause problems when pushed to QuantumLeap / Crate DB, reading from objects is not supported.

[fdelavega]

Hi @ilarimikkonen,

You are mixing the key values and normalized formats. In first example, you are creating properly the location using the normalized format, so you provide the type (geo:json) and the value:

{
        "type": "Point",
         "coordinates": [
                    2.73667,
                    39.5608
          ]
}

In the second example, all the attributes are normalized, except the location that is provided in keyvalues (the normalized way is the one used in the first example). The format is validated by the context broker, as the default format is normalized it asumes location to be normalized, but it lacks a value field, so it gives you an error.

in the third example, if you state that using key values, it assumes that what you are providing is just the value field of the attributes, so it gives them a default type, in this case StructuredValue.

A proper Keyvalues representation of the datamodel, would be:

{
    "id": "70B3D5A4D5110054",
    "type": "IotData",
    "dateObserved":"2020-07-02T09:40:43+00:00",
    "location": {
        "type": "Point",
        "coordinates": [51.714306, 8.723663]
    },
    "batteryLevel":98,
    "humidity": 44,
    "temperature": 30.2
}

As an important remark, if you create an entitity using Keyvalues option, the location would have StructuredValue type and geo queries will not work properly, so I do not recommend doing that.

[ilarimikkonen]

@fdelavega thank for a super quick reply! So the point is that: If there is a location in the json data always use normalised data model like this: https://github.com/FIWARE/data-models/blob/master/specs/Weather/WeatherObserved/example-normalized.json giving the type and value + stay away from keyValues?

[ilarimikkonen]

• does anyone know if there is some documentation on the options attribute? I could not find anything on that..

[fgalan]

does anyone know if there is some documentation on the options attribute? I could not find anything on that..

Yes.

The options query parameter part of the NGSIv2 specification. In addition, check the Orion NGSIv2 implementation notes, with some diferences implemented in Orion regarding the NGSIv2 specification.

[albertoabellagarcia]

This discussion has not to be held in the repo because is just frozen. Activity is now held in Smart data models and the frontend. Please use this link instead. https://github.com/smart-data-models/dataModel.Weather/tree/master/WeatherObserved