Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for adding an optional decimation extension (or parameter(s)) #115

Open
dginane opened this issue Jan 19, 2021 · 2 comments
Open

Comments

@dginane
Copy link

dginane commented Jan 19, 2021

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

@hylkevds
Copy link
Contributor

This is related to #71

@dginane
Copy link
Author

dginane commented Mar 2, 2021

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.

Please let me know if you have any comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants