Bug #2623

Time series chart precision doesnt update correctly

Added by Dan Keeley almost 5 years ago. Updated over 4 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:



This is a butchered example, but it shows the problem we have.

We are going from a data set with one entry, to one with 4. When the chart re-displays the axis displays the dates all wrong.

i.e. it hasnt changed scale from hours to days.

However; If you we're to change from a datasource with several days, to one with hours over a day, i've noticed it does correctly change
scale. So the issue here is specific to going from a datasource with one record for some reason. Very strage.

The attached dashboard will run self contained. Load it up, change the parameter from daily_one to daily_several, hit return and you'll see the issue. If the dash starts up with daily_several initially then all is fine. So it seems that somehow something is being shared in the chart between the first and second run which shouldn't be.

This is reproduced using yesterdays -dev build.

Capture.PNG - Pic showing issue (10.5 KB) Dan Keeley, 2013-09-27 04:16 PM

daily_one.ktr - datasource (8.38 KB) Dan Keeley, 2013-09-27 04:16 PM

daily_several.ktr - datasource2 (8.6 KB) Dan Keeley, 2013-09-27 04:16 PM

ticktest.cdfde - dashboard (39.8 KB) Dan Keeley, 2013-09-27 04:16 PM


#1 Updated by Pedro Vale almost 5 years ago

  • Assignee set to Duarte Cunha Leão

#2 Updated by Duarte Cunha Leão over 4 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Reproduced the issue.
The current time ticks calculation algorithm isn't very smart in that it doesn't choose the best of two choices based on the error to the desired number of ticks, as the numeric ticks algorithm does.

In the current case, if the span is at least 5 days it uses day precision, and otherwise it uses hour precision. Then when this results in too many ticks, it takes only one every N, until the desired tick count is reached.
Yet, the decision of choosing hour precision isn't back-tracked...

Making this right implies a big rewrite of the time-ticks code, and consequently, thorough testing.

Also available in: Atom PDF