Opened 10 years ago

Last modified 2 years ago

#8996 assigned defect

Odd behavior with custom axis labels for Chart2D line chart

Reported by: PetraRock Owned by: Eugene Lazutkin
Priority: high Milestone: 1.15
Component: Charting Version: 1.2.3
Keywords: charting axis labels Cc:
Blocked By: Blocking:

Description

The Chart2D samples and documentation imply that if you provide an array of values and labels for the axis, the labels will be aligned with major ticks. If the labels in the array are evenly spaced by their numeric equivalents, the chart at first appears to compute whether all the labels will fit, and then use only enough of them as will fit. It's pattern for this, though, seems inconsistent.

In the attached sample, a line chart is used to plot a time series of data over 24 hours with one data point on the hour each hour. The x axis values are date object millisecond values (e.g., (new Date()).getTime() ). Labels are provided for the x axis showing strings for each hour on the numeric value for the hour.

If majorTickStep is not specified (1 hour = 3600000ms), the axis computes the major tick positions and uses as many of the labels as possible, but there are two problems. The major tick marks are not on equal intervals (i.e., they start out every 3 hours, but sometimes have intervals of two hours) and they do not line up with the data points on the hour. If majorTickStep: 3600000 is specified, then the data points line up with the major ticks, but all the labels are used and overlap.

In a real-world application where the data for the chart may span different numbers of hours, there is not an obvious way to know how many labels will fit so that the label array could be properly constructed to match a proper majorTickStep value equal to "n hours". But when the chart is left to space the labels automatically so they will fit, the beahvior described above is problematic.

Attachments (3)

ChartAxisTest.html (2.8 KB) - added by PetraRock 10 years ago.
8996_10868.patch (11.0 KB) - added by jason_hays22 9 years ago.
I adjusted the eq function in common.js to allow for the proper comparison of dates (which are large integers) and to account for the double precision numbers that exist in JavaScript?. This fixes ticket #10868, which was a prerequisite to fix #8996. In linear.js, rather than using an arbitrary mathematical formula, I utilized the number of labels given as well as the magnitude to determine what majorTickStep best fit the chart. In charting.js, I added a new automated test module. In test_labels2d.html, I added two new tests to cover the changes to these tickets. CLA on file.
chartlinedate3bad.html (4.0 KB) - added by dotcom 9 years ago.

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by PetraRock

Attachment: ChartAxisTest.html added

comment:1 Changed 10 years ago by Eugene Lazutkin

Milestone: tbdfuture
Status: newassigned

Changed 9 years ago by jason_hays22

Attachment: 8996_10868.patch added

I adjusted the eq function in common.js to allow for the proper comparison of dates (which are large integers) and to account for the double precision numbers that exist in JavaScript?. This fixes ticket #10868, which was a prerequisite to fix #8996. In linear.js, rather than using an arbitrary mathematical formula, I utilized the number of labels given as well as the magnitude to determine what majorTickStep best fit the chart. In charting.js, I added a new automated test module. In test_labels2d.html, I added two new tests to cover the changes to these tickets. CLA on file.

comment:2 Changed 9 years ago by jason_hays22

PetraRock?, will you please test the patch to make sure it fixes the problem? It was patched against the latest trunk.

Changed 9 years ago by dotcom

Attachment: chartlinedate3bad.html added

comment:3 in reply to:  2 Changed 9 years ago by dotcom

Replying to jason_hays22:

PetraRock?, will you please test the patch to make sure it fixes the problem? It was patched against the latest trunk.

Hi Jason_hays222,

I’m having a similar problem when the date range is greater than 24 hours.

I manually applied your patch in 8996_10868.patch, I found it fixed the original problem in PetraRock?’s ChartAzisTest?.html, but the label on horizontal axis still does not show up correctly if date range is greater than 24 hours.

Attached chartlinedate3bad.html is my test program. I’m trying to draw a line chart in three days range with start date = 3/25/09, end date = 3/27/09, x majorTickStep is 1 day = 86400000 ms.

As you can see from chartlinedate3bad.html screen, labels do not line up with data point and the “date” values such as 3/25/09, 3/26/09. 3/27/09 do not shown up.

The first starting date is

1237953600000+ 86400000 = 1238040000000, it is not the 1238025600000 as displayed.

The displayed first step value 1238025600000 – 1237953600000 =7200000 , it is not the correct value 86400000, this caused the problem.

comment:4 Changed 8 years ago by JayZ(zhouxiang)

I think this is not a defect in dojox charting, the main cause of this issue seems is the beginning time you selected: var start = dojo.date.stamp.fromISOString("2009-03-25");(or var start = dojo.date.stamp.fromISOString("2009-03-25T00:00:00:000Z");) this "start" time is not a valid time for x axis, because: "console.log(start.getTime()/86400000) = 14327.666666666666" which means the start is not a "relative integer" accordion to the majorTickStep(86400000).

Solution 1: change the start value var start = dojo.date.stamp.fromISOString("2009-03-25T08:00:00");

Solution 2: use a relative time var start = dojo.date.stamp.fromISOString("2009-03-25") - dojo.date.stamp.fromISOString("1970-01-01") make the "start" and "end" parameter as relative time, then you can implement the "labelFunc" to customize your relative time labels(big integer) to normal date labels(3/25/09)

comment:5 Changed 6 years ago by cjolif

In 1.8 the new dropLabels mode on the axis (default to true) will make sure you can specify the major step (3600000 in your case) while still having superfluous labels dropped so that they don't overlap. That does not "fix" the other problem however. Which is probably more "just" #10868.

comment:6 Changed 3 years ago by dylan

Milestone: future1.12

comment:7 Changed 2 years ago by dylan

Milestone: 1.131.15

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.

Note: See TracTickets for help on using tickets.