Question: How to properly encode a JEXL Geo:Point

[jason-fox]

I've been looking at the documentation, and there is no complete working example of a GeoJSON Point encoding for the JEXL parser:

I currently have the following:

{
    "devices": [
        {
            "device_id": "motion010",
            "entity_name": "urn:ngsi-ld:Motion:010",
            "entity_type": "Motion",
            "timezone": "Europe/Berlin",
            "expressionLanguage": "jexl",
            "attributes": [
                {
                    "name": "location",
                    "type": "geo:point",
                    "expression": "longitude + \",\" + latitude"
                },
                {
                    "name": "TimeInstant",
                    "type": "DateTime",
                    "expression": "level|toisodate"
                },
                {
                    "name": "level",
                    "type": "Number"
                },
                {
                    "name": "latitude",
                    "type": "Number"
                },
                {
                    "name": "longitude",
                    "type": "Number"
                }
            ]
        }
    ]
}

Which results in the following:

{
    "id": "urn:ngsi-ld:Motion:010",
    "type": "Motion",
    "TimeInstant": {
        "type": "DateTime",
        "value": "2021-11-18T14:20:14.901Z",
        "metadata": {}
    },
    "latitude": {
        "type": "Number",
        "value": 1,
        "metadata": {
            "TimeInstant": {
                "type": "DateTime",
                "value": "2021-11-18T14:20:14.901Z"
            }
        }
    },
    "level": {
        "type": "Number",
        "value": 1637245214901,
        "metadata": {
            "TimeInstant": {
                "type": "DateTime",
                "value": "2021-11-18T14:20:14.901Z"
            }
        }
    },
    "location": {
        "type": "geo:point",
        "value": "7,1",
        "metadata": {
            "TimeInstant": {
                "type": "DateTime",
                "value": "2021-11-18T14:20:14.901Z"
            }
        }
    },
    "longitude": {
        "type": "Number",
        "value": 7,
        "metadata": {
            "TimeInstant": {
                "type": "DateTime",
                "value": "2021-11-18T14:20:14.901Z"
            }
        }
    }
}

But instead of:

"type": "geo:point", "value": "7,1"

I would like to have

"type": "geo:point", "value": {"coordinates": [7,1], "type": "Point"}

and I can't see how to encode the quotation marks within the provisioning statement. The closest I can get in the JEXL Playground is single quote which won't work with a jsonparse function.

[jason-fox]

I've had a thought - maybe the mandatory GeoJSON conversions defined for NGSI-LD could be exposed within the JEXL parser, resulting in an expression like:

"expression": "longitude + \",\" + latitude | toGeoJSON"

That would make #1020 obsolete.

[mrutid]

Try this PLAYGROUND

expression: "{coordinates: [longitude,latitude], type: 'Point'}"
Every Object auto-map to JSON at return.

I Agree. Now finally JEXL is able to control explicitly every casting needed. But do we want to force to use JEXL to every user?

[mapedraza]

Having into account @mrutid answer, can we close this issue?

[jason-fox]

The question is answered, but personally I'd update the documentation with PR #1152 first before closing, but that is just purely a personal preference. Much better to have all this information in the public documentation than just an closed issue IMHO.

The real question (for me) is whether Telefónica agree JEXL parsing properly implemented is sufficient to close #1020 unmerged - my thought here is that #1020 becomes unnecessary (and should be withdrawn) if there is sufficient documentation to cover the workaround using JEXL there is no need for an additional flag just to be able to do the same thing using the legacy parser.

[fgalan]

The question is answered, but personally I'd update the documentation with PR #1152 first before closing, but that is just purely a personal preference. Much better to have all this information in the public documentation than just an closed issue IMHO.

We can keep this issue opened until PR #1152 gets merged.