Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hope xAxis of Stack Line support value #18437

Open
carlshe opened this issue Mar 28, 2023 · 22 comments
Open

Hope xAxis of Stack Line support value #18437

carlshe opened this issue Mar 28, 2023 · 22 comments
Labels
en This issue is in English new-feature pending We are not sure about whether this is a bug/new feature. topic: line

Comments

@carlshe
Copy link

carlshe commented Mar 28, 2023

What problem does this feature solve?

Currently, stack line only support category xAxis. Could xAxis support value so the x direction could be scaled by x value?

If so, Echarts could be used for simulating the geological profile, which is composed of connected rock/soil layer points.

What does the proposed API look like?

Just providing the value type for xAxis for stack line.

@echarts-bot echarts-bot bot added en This issue is in English pending We are not sure about whether this is a bug/new feature. labels Mar 28, 2023
@helgasoft
Copy link

yes, xAxis of Stack Line supports value, Demo Code

@xitice
Copy link

xitice commented Mar 29, 2023

@helgasoft In the demo you provided, only the default value of xAxis: category is used. Below is a screenshot of the complete options in the demo. In fact, when the value of xAxis.type is set to value, xAxis.data cannot be assigned, and all data will be in series, such as series[0].data = [[1, 2], [2, 3], [3, 4]].
image

@helgasoft
Copy link

@carlshe, thank you for pointing that out.
I forgot what the documentations says - when "axis.data is specified, the type is auto set as 'category'"

I still do not understand why type='value' is needed for your data.
Could you provide a data sample to see the problem with "x direction...scaled by x value" ?
Geological profiles are interesting, maybe we can come up with a solution.

@Ovilia
Copy link
Contributor

Ovilia commented Mar 31, 2023

Stack line with value axis may have some logic problems. For example, if the data of one series is [[1.1, 20], [2, 31], [3, 2]] and another series [[1, 12], [2, 31], [3, 2]], how do you expect them to stack? Should [1.1, 20] stack with [1, 12]? If not, the two bars should probably overlap. So I think you probably should use category x axis by logic.

@carlshe
Copy link
Author

carlshe commented Mar 31, 2023 via email

@carlshe
Copy link
Author

carlshe commented Mar 31, 2023

Stack line with value axis may have some logic problems. For example, if the data of one series is [[1.1, 20], [2, 31], [3, 2]] and another series [[1, 12], [2, 31], [3, 2]], how do you expect them to stack? Should [1.1, 20] stack with [1, 12]? If not, the two bars should probably overlap. So I think you probably should use category x axis by logic.

Thank you Ovilia,

I just hope while using stacked area map, the xAxis can reflect comparable continuous quantity. Currently the data of xAxis is treated as discrete identification.

demo

above link shows the data of xAxis of stack area map is treated as identification, not continuous value.

Could please also refer my reply to helgasoft?

@helgasoft
Copy link

@carlshe, I think themeRiver chart will work best for you
Demo Code
image

@carlshe
Copy link
Author

carlshe commented Mar 31, 2023

Thank you very much, helgasoft!

I tried your demo. It seems not suitable for me. Because the lines are not stable. The circumscribed polygon of the thematic river map is a symmetric graph. Any a item change will result in vertical adjust of bottom, top or middle lines to ensure it becomes symmetric again. In stack area map, item change only take effect on its neighbor. The bottom is stable.

modified demo

If stack area map really doesn't support continuous x value, is it possible to derive sub type from stack area map to improve its rendering?

@helgasoft
Copy link

if boreholes are of different depth, an additional 'unknown' layer can be added at the bottom
Demo Code - example: deepest borehole is at 16.
image

@carlshe
Copy link
Author

carlshe commented Mar 31, 2023

If stack area map really doesn't support continuous x value, is it possible to derive sub type from stack area map to improve its rendering?

Thank you very much, helgasoft!

The circumscribed polygon of the thematic river map is a symmetric graph. Any a item change, even small, will result in vertical adjust of bottom, top or middle lines to ensure it becomes symmetric again. In stack area map, item change only take effect on its neighbor. The bottom is always stable.

I tried your new demo, and found that at x-24, the bottom moves a little up, and the top moves a little down.

If stack area map really doesn't support continuous x value, is it possible to derive a sub type from stack area map to improve its rendering? by overriding/modifying part of its rendering process?

@helgasoft
Copy link

I tried your new demo, and found that at x-24, the bottom moves a little up, and the top moves a little down.

My mistake: last data line should be [24, 19, 'unknown'] instead of [24, 18, 'unknown']. If values sums of all three boreholes are the same (80), then the chart remains a rectangle.

is it possible to derive a sub type from stack area map to improve its rendering? by overriding/modifying part of its rendering process?

I cannot really answer that because I work at API level and do not do development (yet). But by what @Ovilia said earlier about the logic problem, it looks, hmm... impossible.
It would be helpful to investigate further if any JS charting software does exactly what you want and then post it here as a question with a code example.

@carlshe
Copy link
Author

carlshe commented Apr 1, 2023

Stack line with value axis may have some logic problems. For example, if the data of one series is [[1.1, 20], [2, 31], [3, 2]] and another series [[1, 12], [2, 31], [3, 2]], how do you expect them to stack? Should [1.1, 20] stack with [1, 12]? If not, the two bars should probably overlap. So I think you probably should use category x axis by logic.

@Ovilia

I understand your care.

I have a question? For 'category', if the data is ordered numbers, is it possible to expose an option to tell echart to treat these categories as x values, so the line points could be rendered at expected x-locations?

Or is it possible to derive a sub type from stack area map to improve its rendering? by overriding/modifying part of its rendering process, especally the function that get the rendering coords from [category,y-value]?

Thanks!

@carlshe
Copy link
Author

carlshe commented Apr 1, 2023

I found hichart can render stacked area map with x-value.

In fact, it still define xAxis as category, but it accept x-value as category and render line points at expected location.

MFQI5R84YOQ0)`)ANO}P91X

@helgasoft
Copy link

ECharts can do the same - Demo Code
image

@carlshe
Copy link
Author

carlshe commented Apr 2, 2023

Thank you, helgasoft!

I tested your demo code. I think it is essentially still original category type of xAxis. All the data defined for x_Axis is discrete identification. All the x-coord node must be prdefined in xAxis and evenly distributed over x-axis, and all feature points must locate at exactly one of the predefined x-coords. But for geological profile or any other similar polylines, the feature point could be at any a x-coord.

Modified demo of yours

Highchart has no much limit on x of Stack area map, except that all the layers should share the single data definition of x-categories. Values in x data set are not required evenly distributed over x-axis.

Hope ECharts could provide similar function as soon.

@Ovilia
Copy link
Contributor

Ovilia commented Apr 3, 2023

For 'category', if the data is ordered numbers, is it possible to expose an option to tell echart to treat these categories as x values, so the line points could be rendered at expected x-locations?

@carlshe I don't understand. If you have such requirement, why don't using category x axis?

@maciej-flexcompute
Copy link

I encountered the same problem as @carlshe and also looking forward for stack supporting xaxis type=value.

None of the proposed solutions are solving this problem. @Ovilia to you point on having data on different x locations, you could accept only values being provided on xaxis->data, then the points will be co-located. Alternatively you could check if points are co-located when provided in series and throw error if they are not. Ultimate solution would be to do interpolation, but supporting at least co-located would be great.

@helgasoft
Copy link

None of the proposed solutions are solving this problem.

Maybe because no sample data was ever given...? Sorry but "not uniformly" "co-located" "interpolation" sound confusing to me without real data. The Highchart example is also given without data.
Ok, lets try and guess what this mysterious "value data" could be. Here is an example.
Three lines start at 0 and all other X coordinates may or may not be the same, Demo Code.
How do we stack them without category "pillars"? Is it even possible ? Any reference paper(s) on the subject?
We need proof of concept.
image

disclaimer opinions expressed in this post are strictly personal, as ECharts user, not a developer

@helgasoft
Copy link

Guesswork continues... here is an Updated Demo with "sampling categorization", for lack of a better word.
Idea is to split xAxis into smaller units and generate more points on the original lines (sampling). Sampling step smp could be adjusted from rough (2+) to fine (<=1). Then we have enough categories (vertical reference points) to stack the lines on top of each other.
Use Switch button to toggle between lines and stacked lines.
@carlshe, @maciej-flexcompute, will this work for you?

image

@maciej-flexcompute
Copy link

maciej-flexcompute commented Apr 30, 2023

@helgasoft
Sorry, I didn't know that the problem was not sufficiently described. Sorry for the confusion. Sure, here are examples:

xaxis

x = [0.01, 0.50, 1.01, 1.50, 2.01, 2.51, 3.01, 3.50, 4.01, 4.50, 5.00, 5.51, 6.01, 6.50, 7.01, 7.51, 8.00, 8.50, 9.01, 9.50, 10.01, 10.51, 11.00, 11.51, 12.01, 12.51, 13.01, 13.50, 14.00, 14.20, 14.41, 14.60, 14.80, 15.01, 15.20, 15.41, 15.60, 15.80, 16.01, 16.21, 16.40, 16.60, 16.80, 17.00, 17.20, 17.41, 17.61, 17.81, 18.01, 18.20, 18.41, 18.60, 18.81, 19.00, 19.21, 19.40, 19.60, 19.81]

series 1 (y1)

y1 = [1.00, 1.03, 1.05, 1.08, 1.10, 1.13, 1.15, 1.17, 1.20, 1.22, 1.25, 1.27, 1.30, 1.32, 1.34, 1.37, 1.39, 1.41, 1.44, 1.46, 1.48, 1.50, 1.52, 1.54, 1.57, 1.59, 1.61, 1.62, 1.64, 1.65, 1.66, 1.67, 1.67, 1.68, 1.69, 1.70, 1.70, 1.71, 1.72, 1.72, 1.73, 1.74, 1.74, 1.75, 1.76, 1.76, 1.77, 1.78, 1.78, 1.79, 1.80, 1.80, 1.81, 1.81, 1.82, 1.82, 1.83, 1.84]

series 2 (y2)

y2 = [0.01, 0.71, 1.00, 0.70, -0.01, -0.72, -1.00, -0.71, 0.01, 0.71, 1.00, 0.70, -0.02, -0.71, -1.00, -0.70, 0.01, 0.71, 1.00, 0.70, -0.01, -0.71, -1.00, -0.70, 0.02, 0.72, 1.00, 0.71, -0.00, -0.31, -0.60, -0.81, -0.95, -1.00, -0.95, -0.80, -0.58, -0.31, 0.01, 0.32, 0.59, 0.81, 0.95, 1.00, 0.95, 0.80, 0.58, 0.30, -0.01, -0.31, -0.59, -0.81, -0.95, -1.00, -0.95, -0.81, -0.59, -0.30]

Plotted as category line:

Category

Category Line Demo

Plotted as category stack:

Category Stack

Category Stack Demo

Plotted as value line:

Value

Value Line Demo

Problem

I want this data to be presented as 'stack'.

You can clearly see that two line plots appear visually different. In the category plots, it seems that y1 is not a linear function as has a kink arround x=14. The y2 line has larger period in x in [14, 20] and shorter period in x in [0, 14].

In the value plot you can see that y1 is actually a linear function (the small off-linearity is due to roundoff error), and y2 is regular periodic function without any changes in periods.

This data plotted as 'category' creates confusion to the receiver, because datapoint lay in mathematically incorrect locations. User can incorrectly conclude that y1 is non-linear and y2 is not regularly periodic. In general any (x, y) data represented by real numbers should always be presented as 'values' and never as 'categories'. See plotting in Matlab, python, gnuplot, excel or any other plotting tools.

The solution you proposed in the last plot, in my example I would need to put sampling in 0.01 intervals, which is 2000 points instead of 58 (dataset size). But in general case (interval are real numbers) this is not possible to find such interval.

Finally, you can make a restriction that x values are common for both y1 and y2. I.e., there is not such x point of series 1 for which we don't have data from series 2 and vice versa.

@helgasoft
Copy link

Aah what a beauty, a model for problem/feature presentation, great job @maciej-flexcompute !
The new data helped me improve algorithm and code.

But in general case (interval are real numbers) this is not possible to find such interval.

Curious on the reason behind this statement. A constant step (interval) is crucial for the algorithm.
Please take a look at the couple lines where smp is generated. Could it not work with different data ?

Finally, you can make a restriction that x values are common for both y1 and y2

That may eventually help depending on what comes out of the previous question. But hope this limitation won't be necessary.

Latest Demo, essentially redrawing the lines with new X-values with a fixed step (smp).
Number of points for each series: original value = 58, new categorical = 100.

image

@maciej-flexcompute
Copy link

maciej-flexcompute commented May 1, 2023

@helgasoft

Your example looks exactly like what I am looking for.

But in general case (interval are real numbers) this is not possible to find such interval.

Here is the proof:

let's take a, b real numbers which represent intervals between points. We are looking for such interval c that a = p * c and b = q * c where p, q are whole numbers and they have no common factors. A common way of disproving a statement is by showing an example for which it does not work. I will show that such interval c does not exist if a=sqrt(2) and b=sqrt(3). We have respectively:
sqrt(2) = p * c and sqrt(3) = q * c. We have sqrt(2) * q = sqrt(3) * p. We can raise to power 2 both sides:
2 * q^2 = 3* p^2. We can see that the left-hand side is even, thus, p^2 must be even, thus p must be even, the right-hand side is divisible by 4, thus q^2 must be even, => q is even. We showed that both p and q are even which contradicts statement that p, q are whole numbers and they have no common factors. Thus c does not always exist.

Mathematically it is not possible, but numerically it is possible since we represent numbers in double precision, so at least 1e-16 can work. And practically speaking human cannot visually distinguish ~1e-5, so I guess your method will solve this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
en This issue is in English new-feature pending We are not sure about whether this is a bug/new feature. topic: line
Projects
None yet
Development

No branches or pull requests

5 participants