[plot] Allow plot Value and Time bounds to be saved as a property of a Plot

[charlesh88]

Migrated from WARP repo:

From WARP Features discussion, 2/13/15. Allow the user to save the plot bounds of a plot view in a Panel as a property of that Panel. Note that at the time Panels were the only plot aggregator available; this functionality should now be applied to Stacked and Overlay Plot objects.

Migrated from: Originally created: Fri, 13 Feb 2015 14:16:04 -0800 Updated: Thu, 21 Jan 2016 15:10:41 -0800

Also requested by Rick Elphic:

Plotting quantities with time. I've been calling these strip charts, and have gotten used to being able to adjust both the time range and the value range manually in the Labview GCI's. We often need to do this, instead of autoscaling, because sometimes a rogue value will drive the scale limits to the level where we no longer can see the values we are actually interested in. That's when autoscale is too smart for its own good. Might consider implementing a zoom capability too, where you can mouse-select an area of time/value space to display. Of course, one also needs to be able to escape from this and just go back to a default autoscaled display, and start over.

Migrated comment, from @vwoeltje:

Noted by Robert during Sim #8; WARP-RP15's autofit plotting behavior is such that, if you start viewing two plots at different times, Y axis boundaries can end up being very different. (For instance, if you see large values in a plot that has been open for longer, it will retain its expanded axis boundaries, whereas a newly-opened plot of the same object will not have this.)

Believe this behavior is addressed by having plot bounds saved as a property of a panel (as described here), so noting here in lieu of filing a new issue. Want to consider this case behavior resolving this issue (ensure it is addressed, or file a follow up issue)

[charlesh88]

@larkin We need to discuss how the user would access saved timeframes - in the tree (not preferred) via context menu (maybe) and/or a control in the plot view itself.

[charlesh88]

Both cited use cases here refer to plot value bounds, so I'm not sure how time bounds got into the title. That said, "value" Y axis bounds functionality is in progress; X axis static time bounds are not and need the most definition. Static time bounds are equally applicable to plot and table objects.

Use Cases

1. The user wants to impose default Y axis bounds on a plot and turn off auto-scaling, so that whenever it loads it starts with those bounds. This is a single optional preference value saved with the plot object, and is only available if Auto-scale is disabled. This addresses Robert's use case above. This is currently in-progress in the new 2017 plots:
2. The user wants an object that displays a 7 day or 24 hour trend without being affected by the Time Conductor. So if the TC was in RT mode displaying data for the last 8 hours, you could have a plot in a Layout that is set to plot telemetry from the last seven days to now. Note that this is really a rolling fixed duration with offsets from "now". This use case satisfies requirements from the JASON 3 and M2020 missions for their dashboards.

Defining a Rolling Fixed Duration

For an initial version, same as shown for Y axis bounds: the object is either set to "Sync to Time Conductor", or has its own pre-defined Start and End offsets. To accomplish a seven day trend view, the user would set the Start to be 7 days ago, and the End to be now. Start and End offsets would be configurable with any valid durations (minutes, hours, days, etc.) and would need to potentially vary with time type (SCET, SOL, etc.). We'll need to determine if we need to support things like "Last Month", "Last Week", etc. where we'd need to evaluate day of week or what month we're in. Offsets in the future should be allowed to account for predictive data.

View Behavior When Loading an Object with Fixed Durations

The object displays data in the time frame set in its static time bounds. It visually indicates that it is not synced with the TC, and would articulate its currently applied time bounds clearly. Resetting the view after zooming and panning a plot resets to the defined static time bounds, not the current setting of the TC.

Multiple Rolling Fixed Durations and Time Bounds

There may be utility for saving and quickly applying multiple rolling fixed durations to objects, such as a plot object quickly switching from Last 24 hours to Last 7 days. This adds management, as the user would need to be able to name and remove these from objects. There's a further case for potentially allowing defined time bounds to be defined as objects in their own right, allowing them to be managed independently and applied to multiple objects - or the Time Conductor itself - easily.

@RCarvalhoNASA @costigan Could we get your thoughts here?

[Costigan]

General Comments

I think that we should allow the mission to add annotations to points in the dictionary, giving them an expected range.

The plot/stripchart view should have an option of using the expected range, if present. So the Y axis options would be:

1. Auto Scaling
2. Use the Expected Range in the Dictionary, if present
3. Use the range given here [min] [max]

Comments on Defining a Rolling Fixed Duration

To determine what X-axis interval should be shown, the user needs to define any two parameters: Start, Duration or Stop.

Start and stop are points in time and can be expressed like so:

1. A DateTime in some time system
2. A mission-relevant milestone

1 gives rise to different ways to express the time depending on how many time systems you have. #2 is like picking a single time from a dictionary of times, like Launch, Lunar-Orbit-Insertion or Landing.

The Duration can similarly vary based on time system and there can also be a set of mission-relevant intervals, e.g., day, week, month or orbit.

I think we have to support things like last-day, last-3-days, last-week, and these should be mission-customizable.

View Behavior When Loading an Object with Fixed Durations

I agree with everything in your paragraph about this.

Multiple Rolling Fixed Durations and Time Bounds

By saying "I think we have to support things like last-day, last-3-days, last-week ...", I'm saying that we need to do what you're talking about in this paragraph. However, I'm not sure that creation of those things is needed by all users. It could be a mission-specific customization that's done in json. The user sees the options in pulldowns, but can't create them (or has to change that json file to do so).

Here's one design for this. (This design has a few good features, but I don't really like it, and I don't think we should do this. But I'm including it as an example.) This is part of the ladee telemetry viewer. In that, the basic operation was a query to retrieve telemetry for plotting, printing or whatever. A query was (a) a datasource, (b) a set of telemetry points, (c) one or more time intervals and (d) an action to do with the resulting data. The time intervals were specified with this interface:

Here's what it looks like with Timespan of selected data source and DataTime range checked:

The user wants to specify a time interval. There are three parameters (From, Duration and To), and the user needs to specify two of them. Ideally, the interface should calculate and show the parameter not specified. If there are multiple time systems, the user should be able to choose one in which to express the two parameters provided. Ideally, the interface should calculate the equivalent value in the other time systems and show them (if there aren't too many). In this case, A-D aren't different time systems but just different ways of expressing the same time (UTC). This interface was useful as a translator between those representations, which feature was used sometimes. The arrow buttons are for copying the value of From to To and the other way. I occasionally used these. The Start button loads the From parameter with the start time of the datasource. The End button loads the To parameter with the end time of the datasource. I never once used these. The Locked checkboxes lock From or To so that their values can be changed when other parameters are changed. I don't think this is required, especially if an undo is present. Duration only had one way of expressing it. Last N days was very common, so there was a separate filter just for that. It could have been specified in this interface but checking Last N days exposed a numeric up/down that let the user set it more easily.

My main problem with this is that it's visually busy and I picked ugly colors. It would be better to hide the translations between different representations until they were asked for or to do that in another widget. I could imagine three text boxes with flexible parsing and valid/invalid feedback (e.g., change color when the parse was successful) would be nice.

[larkin]

@costigan currently plot does read an expected range from provided point metadata if it exists. Uses that for default. So if the dictionary adapter provides that info, it works.

Currently, we have a pseudo option "defaults," or the user can enable or disable auto scale. Once they have enabled / disabled, it's stuck that way (e.g. Won't go back to dictionary definition). I'm not sure if we should have "reset to defaults" or three explicit options. (Use point defaults, autoscale, or fixed). @charlesh88?

[Costigan]

Is there currently a tool for translating between time systems and representations within the same system?

I think three settings are needed. A possible fourth -- maximum of the fixed and autoscaled ranges -- would be useful in a few cases, but still seems like overkill.

If it pulls from the dictionary, how does it combine multiple ranges for multiple points? The convex hull?

[larkin]

Unsure on what the timesystem question means.

Currently, with multiple points, if the ranges are not exactly the same, it falls back to autoscaling.

In general, when a user wants to plot points with with disparate ranges, I think they are better served by multi y-axis; with each individual series having y-extents ("automatic", "autoscale", or "fixed") scaling to 100% height. Implementations I have seen of this hide the y-Axis entirely and use mouse-hover or other interactions to show actual values.