Doubt about the Data-logger place in the entities model

[claudiadragoste]

Hello,

I'm tring to implement a Sensorthings Api server for a water networks; After reading and watching youtube videos, I still have a doubt: If I have a sensor for the flow of the water, another for the level of the water of a tank; and the sensor data is sent using a data-logger, my idea is - the sensors as Sensor; the data-loggger as the Thing; the pipe where i mesure the water flow and the tank where I mesure the level - as FeatureOfInterest. I'm not sure if I got the right meaning of the Thing and the FeatureOfIterest and I couldn't find among the public endpoints an example that illustrates where a data-logger is defined...

Is there anybody that had this user case? Thank you very much,

[hylkevds]

What you make your Thing, and whether your data-logger is in the model at all depends on how you want to use the data.
In the v1.1 data model your Thing is that which you want to attach a time series to. I don't know your exact use-case, but assuming that both the water level, and the flow pertain to the same tank (water level in the tank, flow into/out-of the tank) then it would make most sense to model your tank as the Thing
The data logger would not need to appear in the model at all, unless you are also measuring something that pertains to the data logger, like available disk space or battery level.

In version 2 we plan on improving this situation a lot, by making it possible to attach Datastreams (time series) to the Feature. In this case all your domain entities (the tank in your case) would be features, and the Thing would be the data logger.

[claudiadragoste]

thank you very much, Hylke, for your time!

[claudiadragoste]

Recently, I tested various public endpoints of different SensorThings API servers and the QGIS SensorThings API plugin (https://plugins.qgis.org/plugins/SensorThingsAPI/). Using this plugin, I could create layers using the Locations endpoint (e.g., https://airquality-frost.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/Locations). I don't understand why there is no interest in loading a layer from the FeatureOfInterest endpoint (e.g., https://airquality-frost.k8s.ilt-dmz.iosb.fraunhofer.de/v1.1/FeaturesOfInterest).

I'll explain why I'm asking this: if the sensors are connected to the data-loggers or PLC and one of them, for instance, monitors the water level in a tank, we thought the most natural approach would be for the 'Thing' to be the data-logger. This is because data-loggers can be moved from one place to another, making it logical to use 'HistoricalLocations.' On the other hand, the tank is always in the same place, and since I can save its position in 'FeatureOfInterest,' the tank fits perfectly there.

What I expect is to be able to click on the tank on the map and see all the datastreams and their time series. For this reason, it seems that the 'Thing' should be the tank and not the datalogger. Still, there is an interest in monitoring the dataloggers and knowing where they are installed.

[hylkevds]

You have described exactly what the problem is and why we are changing this in V2.0.
In v1.1 one can only attach a Datastream to a Thing, and not to a Feature. But in your use case (and in many other use cases) you would have liked to attach the Datastream to both the Tank and the data logger.

In version 2.0 this will be possible. The data model images for the V2 draft can be found in this issue:
#167 (comment)
As you can see, both the Thing and the Feature have a relation to the Datastream, so the new model will fit your use case much better. So in V2 you will be able to make the data logger the Thing, and your tanks the Features, and have the data logger move around. Using the OM extension with the Deployment entity type you'll even be able to describe which sensors are attached to the data logger at which time.

[claudiadragoste]

This is amazig!! I even wouldn't have dared to ask if it's possible to know which sensors are attached to the data logger at which time! Very interesting!