GeoJson data in timescale-provider

[gg-dim]

In the Jena smartcity project we have several data sets with GeoJson data. From simple points geometry and polygons to FeatureCollections with Features and properties (e.g. speed, heading, ...).

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "properties": {
                "heading": 245.61,
                "className": "Car",
                "id": 218432,
                "time": 1723116362000,
                "class": "5",
                "speed": 42.566
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    11.5902657,
                    50.9259193
                ]
            }
        }
    ]
}

At the moment the timescale-provider only supports points. With a little effort it can handle other geometry objects. And with a little bit more effort you get the first geometry from the FeatureCollection, but you lose the property and additional features.

If your GeoData contains Z-coordinates, there is another problem. The PostGIS database has different column type for geometry data with and without Z-coordinates (GEOMETRY vs. GEOMETRYZ) but you can't insert data without Z-coordinates into a column with a Z-type and vice versa.

We should talk about these problems and how we deal with/resolve them.

[timothyjward]

We should add some filtering to the history storage. See https://github.com/eclipse/org.eclipse.sensinact.gateway/blob/2a3c185c1c6c7c4c32d5faf252ecc6971c808117/southbound/history/timescale-provider/src/main/java/org/eclipse/sensinact/gateway/southbound/history/timescale/TimescaleHistoricalStore.java#L226

This will allow us to target specific models/resources and not try to store things which we can't store. Also, in general it's not good to store data that doesn't change (i.e. most complex location data). Things that move (buses, trams) usually store simple data like a point.