Version
5.4.3
Link to Minimal Reproduction
Steps to Reproduce
It is very painful and imo unacceptable that in the status quo, it is merely impossible (at least as far as I understand it) to set up a time axis with splits to personal taste. I understand that interval on time axes currently does not work as expected (yet), but the fact that using splitNumber instead almost NEVER matches the expectations is really bad. The documentation says that
Note that this number serves only as a recommendation, and the true segments may be adjusted based on readability.
but in the example attached, I do not see why splitNumber values like 4 or 6 should not work for readability reasons. I really think this needs to be adressed with priority - time axes are no exotic edge case, and uncontrollable axis intervals ARE a problem.
Current Behavior
No way to reliably control time axis intervals.
Expected Behavior
It must be possible to control time axis intervals somehow.
Environment
- OS: Windows 10
- Browser: Firefox
- Framework: -Any additional comments?
No response
5条答案
按热度按时间z9zf31ra1#
No way to reliably control time axis intervals.
It seems you want to set programmatically splitNumber and/or interval just once.
Lets assume this is done.
What would happen next, when users zoom in ? Would they be happy seeing a bunch of data over an empty axis line ? Or would a developer be happy handling zoom events and recalculating axis label positions and frequency ?
Hmm, I think the status quo is a good deal.
6l7fqoea2#
No way to reliably control time axis intervals.
It seems you want to set programmatically splitNumber and/or interval just once. Lets assume this is done. What would happen next, when users zoom in ? Would they be happy seeing a bunch of data over an empty axis line ? Or would a developer be happy handling zoom events and recalculating axis label positions and frequency ? Hmm, I think the status quo is a good deal.
I'm sorry, what? If I set splitNumber to e.g. 5, this obviously should be the guideline for number of splits on any given zoom state. As stated above - in the simple example there is just no reason why the desired splitNumber should not work. Or do you know any? This works nicely for value axes (even if zoomable), so why should I not want that to work on time axes as well?
plicqrtu3#
@ob-ARC Let's say if you can control the splits with splitNumber with time axis and it start value of the axis is
10:00:12and the end value is13:00:47. If you set thesplitNumberto be 4 and you expect it to split evenly, the labels will be10:00:12,11:00:23 667,12:00:35 333,13:00:47, which are not whole numbers. This is why you cannot usesplitNumberto force splitting. Although Apache ECharts is not perfect with time axis labels, this is what we could offer now. BTW, ECharts is an open source project and if you have a solid plan of how time axis should behave, you are welcomed to contribute.ux6nzvsh4#
@Ovilia I totally understand that a fixed number of splits does not work in any case. But I wonder why the desired number of splits also does not work even when the numbers would match (see example above). And of course I know that ECharts is open source - but unfortunately, I am already working full time as a developer and have wife and children at home, so coding in my free time currently is not an option.
yfwxisqw5#
@ob-ARC Let's say if you can control the splits with splitNumber with time axis and it start value of the axis is
10:00:12and the end value is13:00:47. If you set thesplitNumberto be 4 and you expect it to split evenly, the labels will be10:00:12,11:00:23 667,12:00:35 333,13:00:47, which are not whole numbers. This is why you cannot usesplitNumberto force splitting. Although Apache ECharts is not perfect with time axis labels, this is what we could offer now. BTW, ECharts is an open source project and if you have a solid plan of how time axis should behave, you are welcomed to contribute.In your example, I would expect that the algorithm somehow detects that start/stop of the axis is off the user-expected grid (in a range of 3 hours I would assume that only multiples of whole minutes actually matter to the user with regards to labelling).