Increase flexibility of visual reports

[jhmigueles]

We discussed this some time ago. File summary reports look well when GGIR is run on defaults (ENMO, worn on wrist, standard bout lengths, ...). But they can be improved if other settings are used. For example:

• Adapt y axis limits to the metric used.
• Adapt labels to the settings (e.g., even if sensor.location == hip, the plot label would say "arm movement")
• Adapt plot to the algorithms used (e.g., the sleep plot will show the z-axis variability even if HorAngle with a different axis is used)
• It always show the MVPA metric with the longest bout, this could be adapted by showing the total MVPA and the composition of the selected bouts in stacked barplots (and it would be great if this is clarified in the plot).
• GGIR does not calculate sleep efficiency in certain settings (e.g., sleepwindowtype == "SPT", or HASPT.algo == "HDCZA"), yet the filse summary report would always show an estimate of the sleep efficiency, this can be confusing for the user.

For now I am just creating this issue not to forget it and to make a list of the things we would like to improve in g.plot5.

[jhmigueles]

Moving the g.plot5 function within g.part5 would facilitate this as it would allow to use the ts object and all the configurations. The only change this would imply is that the plots would be generated before the reports in the GGIR pipeline.

[vincentvanhees]

g.part5 is already a very long function (maybe even too long), so it may be better to create a new plotting function to eventually replace g.plot5 and call that new function from within g.part5. However, if we fully want to re-think the design of the visual report, including the layout then it may be worth considering moving all visualisation functions in GGIR to a separate R package. Advantages:

• Isolate all that work into a separate project, which in theory can be tested and used on its own even without GGIR.
• Reducing size and complexity of GGIR code base.
• Easier to start using more advanced R visualisation tools.

[jhmigueles]

The only "limitation" I see to that option is that we would need to either always export the timeseries from g.part5, or rerun g.part5 within the new package to get the timeseries classification. This would be in order to plot the behavior classification that is perfomed in part 5, which includes all the intensities and the sleep estimates. The current approach loads part 2 timeseries and part 3/4 sleep estimates and recalculate some of the variables (which sometimes end up in inconsistencies between reports and plots, and little flexibility for configurations other than the default).

Exporting always the part 5 timeseries could make the function slower, which is not good. So, the option I see is to state in the in the new package that part5 timeseries should be exported for the visualization to work.

[vincentvanhees]

I am not proposing exporting the time series. My proposal is that the new package, lets call it GGIRvisual for now, provides a function that takes as input all the information needed for creating the visualisation ranging form part 2 time series to part 5 classification. Next, g.part5 would call this external function and give it all the information it needs. The output of the external function would be the visualisation which GGIR can then send to a pdf for example.

Ideally GGIRvisual is not used by GGIR users directly, but as a dependency just like GGIRread is. But just like GGIRread we would design GGIRvisual in a way that it can be used without GGIR.

[jhmigueles]

I see, sounds good. I can start working on this. Should we then migrate all the visualizations made by GGIR? Or just the file summary reports for now?

[vincentvanhees]

I think it is good to plan this with all GGIR plotting functionality in mind even if we practically start with just one visualisation.

This would then be a good opportunity to:

• Rethink the design of all the visualisations to reduce redundancy and increase complementary value.
• Aim for consistent terminology and where possible re-use of code.
• Invest in user needs, e.g. option to change language of the legend.

[vincentvanhees]

Closing this issue, as we are not planning to work on this anytime soon.