OpenCDSS / cdss-lib-processor-ts-java

Colorado's Decision Support Systems (CDSS) time series processor library (Java)
GNU General Public License v3.0
0 stars 1 forks source link

SetTimeSeriesProperty - evaluate whether a time series can be a property #193

Open smalers opened 1 year ago

smalers commented 1 year ago

This is associated with the core processor design but does overlap other repositories such as cdss-lib-common-java.

There are cases where a time series is associated with related properties. Currently, typical time series only allow one data value per time series, which corresponds to the time series identifier. However, there are cases where additional time series might be associated with the primary time series, for example:

  1. Data collection system where a raw value is measured and is processed into scaled (engineering) value and possibly other derived values. Currently each time series is separate, which provides some benefits but also has some limitations.
  2. When creating a graph, need to process the time series into a derived form before visualizing, for example cumulative values needed for a double mass graph (new graph type that is being considered) or statistics needed for a box plot. Because the calculation may have some complexity, the time series product would need to have appropriate default values and allow configuration with product properties.

Associating the related time series with the primary time series could occur as follows:

  1. Treat as fully separate time series. This requires properties to make the association but the time series objects are kept separate. This can be cumbersome, especially if ambiguity may occur.
  2. Add a "related time series" list to the TS class. This would allow for the association but requires a slight change in the time series design.
  3. Use the existing time series property list to store a named reference to associated time series. The name (key) could have any appropriate value:
    1. How would it be handled in the Time Series Properties view?
    2. How would it be handled in output formats that contain the properties, such as DateValue?

Trying the last option requires the least effort at this point and can be tested. For example, change the SetTimeSeriesProperty command to allow selecting a time series to set as the property, and then see how the software handles in a test. Other questions are:

  1. Are the associated time series flagged in any way to know whether the time series is temporary, or transient, such as used by graphing but not a part of the larger workflow? Perhaps the temporary time series can have a property set like IsTemporary=True. Then output tools will know that it is a throw-away time series.
  2. Would transient time series automatically be removed as a property when the action is complete (e.g., when the graph is closed)? This adds some complexity.
  3. Would be nice to allow right-clicking on the property in the time series property view and being able to graph or view the table, at a minimum using the default properties.
smalers commented 1 year ago

After an initial evaluation, I decided to go with option 2 (associated time series separate from properties). Adding a time series as a property was going to result in too much potential problems because properties are expanded with ${Property} notation and a complex object like a TS instance could cause errors and require code in various places to check. I updated the SetTimeSeriesProperty command to allow setting a time series but have not done anything else in graphing code to test.