Develop the summary tab

[neilnutt]

Develope the summary tab recording how the user got qmed and how the Fgc was developed. Provide a graph showing the adopted flood frequency curve.

[faph]

At the moment both the QmedAnalysis.qmed() and GrowthCurveAnalysis.growth_curve() methods focus on getting the correct results out, nothing else.

I'm thinking about adding an attribute *Analysis.results with a json-like data structure to store input data and intermediate and final results for QA and reporting purposes. One option would be to use Jinja (http://jinja2.readthedocs.org/) to render templates by passing the results data structures as a context. This would allow us to create different output templates very quickly including html, markdown, rst etc.

Any thoughts?

[neilnutt]

This kind of relates to the gui_data object question I was struggling with. Really in my head it was going to try to be two things a) a store for notes relating to the calc in free text b) a store for user decisions. I think looking at it might be useful to have 3 new entities

1. 'notes' a free text for each stage of the calc. I.e a note for cds description, another for qmed another for each fgc.
2. 'results' to store ahead of reformat using something like you suggest
3. 'qa' to store the actual signoff

These could be used via the api or gui.

[mikerspencer]

What about wrapping it up in markdown and incorporating notes, choices and results/graphs?

Sent from my phone, apologies if there are any typos. On 3 Oct 2014 23:24, "Neil Nutt" notifications@github.com wrote:

This kind of relates to the gui_data object question I was struggling with. Really in my head it was going to try to be two things a) a store for notes relating to the calc in free text b) a store for user decisions. I think looking at it might be useful to have 3 new entities

1. 'notes' a free text for each stage of the calc. I.e a note for cds description, another for qmed another for each fgc.
2. 'results' to store ahead of reformat using something like you suggest
3. 'qa' to store the actual signoff

These could be used via the api or gui.

— Reply to this email directly or view it on GitHub https://github.com/OpenHydrology/StatisticalFloodEstimationTool/issues/8#issuecomment-57871149 .

[faph]

@neilnutt: items 1 and 3 you can simply store in the ini file as per wiki https://github.com/OpenHydrology/StatisticalFloodEstimationTool/wiki/Open-Hydrology-project-file-structure because that's input data you need to store. The parsed object is your main "project" object wich you bind to the GUI.

If I make a results object as a plain dicts + lists object, then you can feed this into any report template. @mikerspencer: yes that would be possible using this approach.

@neilnutt: we might want to keep the report generator as standalone module, independent of the GUI modules. So you can re-use the report generators say for batch scripts etc.

[neilnutt]

Thanks to the Auto Hydrology report/library this is now substantially down the road to being closed. Just need to incorporate into the gui.