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
SensorThings services can be used by a client for visualizing a Timeseries of observations on a chart. The standard allows us to do that easily.
However, when the timeseries is describing a large time range with fine resolution between each observation (in our example, a station that has been measuring a set of properties every hour since 1970) and you want to a) display at a glance the global dynamic since 1970 and then b) allow the user to zoom in on a more precise time range, the current standard requires asking for the entire series of values then to delegate the decimation logic to the client side. This approach is not sustainable when data are very numerous.
Adding a decimation parameter on the server side could allow for adapting the amount of data received by the client to the resolution of the chart as the server implementation applies the decimation.
We prototyped a first implementation, which simply adds a decimation parameter to some SensorThings Endpoint where the client specifies the number of points expected for the requested time range :
$decimation=500
This is a very simple proposition that will have to be discussed and refined (for example by specifying the type of decimation applied…).
Please let me know if the proposition make sense to the group and if the group thinks it could be a valuable extension for the standard
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.
The approach described above is complementary to the aggregation approach described in the quoted #71 ticket. The on-the-fly approach can be compare to the WMS image size definition approach and the #71 Method to a pre-aggregated method that can be compared to WMTS Pyramids.
At this stage two questions are pending :
How the two approach should be described for the Sensors Things Standards
Name of the parameter should be modified. I can propose “CardinalityLimit”, which seems unambiguous considering the mathematical definition of the term “Cardinality” and "SubSamplingMethod" for describing the method applying for the subsampling process.
SensorThings services can be used by a client for visualizing a Timeseries of observations on a chart. The standard allows us to do that easily.
However, when the timeseries is describing a large time range with fine resolution between each observation (in our example, a station that has been measuring a set of properties every hour since 1970) and you want to a) display at a glance the global dynamic since 1970 and then b) allow the user to zoom in on a more precise time range, the current standard requires asking for the entire series of values then to delegate the decimation logic to the client side. This approach is not sustainable when data are very numerous.
Adding a decimation parameter on the server side could allow for adapting the amount of data received by the client to the resolution of the chart as the server implementation applies the decimation.
We prototyped a first implementation, which simply adds a decimation parameter to some SensorThings Endpoint where the client specifies the number of points expected for the requested time range :
$decimation=500
This is a very simple proposition that will have to be discussed and refined (for example by specifying the type of decimation applied…).
Please let me know if the proposition make sense to the group and if the group thinks it could be a valuable extension for the standard
The text was updated successfully, but these errors were encountered: