Changing database return for bar graph data

[spearec]

Is your feature request related to a problem? Please describe.

This encompasses general issues with the way bar graphs display meter data, especially when data are missing from time ranges. This will directly fix #475 and #570, and some ideas here apply to #479 as well.

Describe the solution you'd like

One solution is to change the database code to figure out the maximum number of bars that can fit within the requested range. These many bars are then requested from the database, and the graph is drawn as it currently is. This would prioritize recent data, so the last bar would be accurate, but some data at the beginning of the meter's range may be omitted. For example, if a meter has data for 365 days, but the graph scale is 4 weeks (28 days), the bar graph will currently display 14 bars. However, only 13 of these bars will have data across their full range. This new method would ignore a small piece of data at the beginning of the meter readings in order to eliminate the misleading final bar. Some edge cases to consider:

• The meter range is smaller than the requested bar range
• The graph's time range has +/- infinity as one or both of its values so all dates are desired
• Large swaths of data are missing from the meter data

Describe alternatives you've considered

While this is more of a possible future feature than an alternative, changing the normalization method for the bar graph as a whole is something that needs to be addressed. Right now, the database normalizes an average for each day and then aggregates the days into bars. Missing days are NOT normalized (#479). This leads to a somewhat inconsistent system, especially when compared to the line graph's method of normalization. Adding fully normalized bars, either just for the first/last bar or for all bars, is a possibility. This would require a rewrite of both the database and the display code for bar graphs, and is something that needs to be discussed further before it may be implemented.

Additional context

This summarizes a discussion I had with @huss about #475 and the way OED displays data for bar graphs in general.

[spearec]

PR #811 implemented a version of the original change which was planned. The new code makes the last bar issue less prevalent. However, since all meters/groups need to adhere to the same bar widths, inaccurate bars may still be presented when meters with differing date ranges are displayed. The only way to accurately fix this is to have a per-meter real start and end time, something which is currently not returned by the database. To make any more changes regarding how OED handles infrequent or missing data requires a longer conversation about whether or not data should be normalized, and if it is to be normalized, how should that be displayed. The final product may end up looking more like the alternative described above.