You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We used SensorThings for sharing observations measured by a buoy that dives and measures some physical parameters of water when diving. The raw data that provides the buoys has several observations for a single timestamp but at different depths.
For now, we model it by a kind of hack when using the SensorThings model :
We declare the depth as an observed property, and use the MultiDatastream extension to retrieve the other observed properties along with the depth values.
When retrieving observations, we group the results with the same resultTime for each series, and use the depth values for X axis.The solution is not fully satisfying because depth results have a resulTime property that is not correct.
It is possible that the standard already provides a better way to implement such a case, and we’ve simply missed it. However, we think it could be useful to provide clear guidance on how to model this kind of timeseries in a way that improves the interoperability for the client discovering such a service.
So we would be glad to discuss this point, if the DWG thinks it could be useful.
The text was updated successfully, but these errors were encountered:
I add a little complementary information to my previous post as discussed during the last TC.
We chose to use the MultiDataStream extension to receive together the temperature (the physical phenomenon) and the associated depth. It seems not be possible using only the DataStream class.
We could have used a 3 dimensional locations (a X,Y,Z point) but :
It multiplies exponentially the locations
This involves asking for a location for each measurement and these two elements have only an indirect link considering the sensor things model. This complicates the data post-processing of the data for the display we want to do (temperature as a function of the depth, see above)
We used SensorThings for sharing observations measured by a buoy that dives and measures some physical parameters of water when diving. The raw data that provides the buoys has several observations for a single timestamp but at different depths.
For now, we model it by a kind of hack when using the SensorThings model :
We declare the depth as an observed property, and use the MultiDatastream extension to retrieve the other observed properties along with the depth values.
When retrieving observations, we group the results with the same resultTime for each series, and use the depth values for X axis.The solution is not fully satisfying because depth results have a resulTime property that is not correct.
It is possible that the standard already provides a better way to implement such a case, and we’ve simply missed it. However, we think it could be useful to provide clear guidance on how to model this kind of timeseries in a way that improves the interoperability for the client discovering such a service.
So we would be glad to discuss this point, if the DWG thinks it could be useful.
The text was updated successfully, but these errors were encountered: