Related: T403020: Support date/time data type

This feels like it's asking for an X/Y plot type instead of column series as a feature request?

No, this is an actual bug. The line chart is already an X/Y plot. There is no need to implement this as a new feature. In ECharts, the area chart is just the line chart with slightly different design, and in ECharts an area chart works just fine as an X/Y plot. It must be MediaWiki's input data processing not working correctly for area charts.

I guess to fix this in mediawiki/services/chart-renderer/src/lib/charts/lineChart.ts, one just needs to check the condition isValidNumberColumn( xAxisColumn ) in the function createAreaChart and use createBaseValueChartOption instead of createBaseCategoricalChartOption in that case, similarly to how it's already done in createLineChart. Perhaps with a bit of extra work, but not much.

ksarabia opened https://gitlab.wikimedia.org/repos/mediawiki/services/chart-renderer/-/merge_requests/99

Draft: Fix area charts with non-uniform numeric X axes

mlitn merged https://gitlab.wikimedia.org/repos/mediawiki/services/chart-renderer/-/merge_requests/99

Fix area charts with non-uniform numeric X axes

Above patch addresses area chart gaps.

Non-uniform dates are not fixed, but that's because there is (practically) no date support, for which there is another task already: T403020

Change #1235107 had a related patch set uploaded (by Bvibber; author: Bvibber):

[operations/deployment-charts@master] Update chart-renderer to 2026-01-29-153835-production

https://gerrit.wikimedia.org/r/1235107

Change #1235107 merged by jenkins-bot:

[operations/deployment-charts@master] Update chart-renderer to 2026-01-29-153835-production

https://gerrit.wikimedia.org/r/1235107

Confirmed with today's deploy that this example is fixed:
https://commons.wikimedia.org/wiki/Data:Test_area_chart_with_bug.chart

while the date example remains funky because we don't actually plot dates according to their .... date-ness yet. (See matthias' note above for the distinct bug to follow up with).

Thank you, this enabled us to use the area plots for population graphs.

However, it seems that this change had a strange effect on a graph with multiple numerical fields. Consider this graph:

• Source: https://commons.wikimedia.org/wiki/Data:Saint_Petersburg_subway_station_counts.tab
• Chart: https://commons.wikimedia.org/wiki/Data:Saint_Petersburg_subway_station_counts.Area.chart

Note that the years are consecutive, so no non-uniformity effects here.
After this change, it looked like this:

• Source: https://commons.wikimedia.org/wiki/Data:Bug_test.tab
• Chart: https://commons.wikimedia.org/wiki/Data:Bug_test.chart

(I fixed it by an edit to the source which replaced the type of the x-axis field (year) from number to string.)
If the type of the chart is changed from area to line, the problem gets resolved.
Admittedly, for this particular chart the ultimate solution will hopefully be to switch the type of the x-axis field to date, when it is implemented. But the current Bug_test.chart doesn't make sense at all anyway. Why are the graphs spaced with an interval ~2000?

In T411319#11568060, @colt_browning wrote:

However, it seems that this change had a strange effect on a graph with multiple numerical fields. Consider this graph:

• Source: https://commons.wikimedia.org/wiki/Data:Saint_Petersburg_subway_station_counts.tab
• Chart: https://commons.wikimedia.org/wiki/Data:Saint_Petersburg_subway_station_counts.Area.chart

Note that the years are consecutive, so no non-uniformity effects here.
After this change, it looked like this:

• Source: https://commons.wikimedia.org/wiki/Data:Bug_test.tab
• Chart: https://commons.wikimedia.org/wiki/Data:Bug_test.chart

(I fixed it by an edit to the source which replaced the type of the x-axis field (year) from number to string.)
If the type of the chart is changed from area to line, the problem gets resolved.
Admittedly, for this particular chart the ultimate solution will hopefully be to switch the type of the x-axis field to date, when it is implemented. But the current Bug_test.chart doesn't make sense at all anyway. Why are the graphs spaced with an interval ~2000?

Yeah, there's definitely still something funky here we should fix before waiting for the proper date stuff. It looks like there's two weird things going on:

1. The initial X axis value starts at 0 though we have no data until 1955, shoving the rest of the graph for each row into a bit at the end; this seems fine on the line graph, so may be an area-plot-specific issue in setup.
2. The X axis values for each row seem to get added to all the previous rows' X axis values or something, so they're all "stacking" off to the side which they shouldn't be. This is likely a side-effect very specific to the area plot type.

Some initial investigation:

https://commons.wikimedia.org/wiki/Data:Bug_test.chart stacks the data series on the x axis rather than the y axis now

• echarts picks the first (supported) axis to stack on
• data is given in [x, y] format
• Stacking is not supported for "category" types
  • x axis used to be "type": "category", (stacking unsupported) so it used to default to stacking on y axis
  • x axis is now (since the patch for this ticket) "type": "value",, which is supported, so that's where it'll now stack

Perhaps we should simply switch type back to category if we encounter more than 1 Y data series (i.e. data will be stacked).
The main downside here is that we're then introducing more inconsistent behavior in terms of how similarly-structured charts are being rendered: those with singular y series will support scaling, those with multiple won't...

Alternatively: this comment suggest swapping the order of the data ([y, x]) in order to get it to stack on the other axis.
That does *kind of* seem to work: the stacking does happen on the correct axis now, but it's not correct. Instead of stacking it based on the X value (year), it seems to do so based on the index of the data (i.e. combining the first available data of each series, combining the second, ...). See example here
It may be possible that there's a simple configuration setting that would need to be updated in order to fix this stacking, but I haven't found it.
An option could be to not filter out missing data, but explicitly pass in all null rows as well, so that they have the same indices. That seems to work; see example here.
Quick patch to demonstrate here

Thoughts?

An option could be to not filter out missing data, but explicitly pass in all null rows as well, so that they have the same indices. That seems to work; see example here.

This sounds like a good idea.

Change #1235853 had a related patch set uploaded (by Bvibber; author: Bvibber):

[operations/deployment-charts@master] Revert "Update chart-renderer service for Parsoid template fix"

https://gerrit.wikimedia.org/r/1235853

In team meeting today we agreed to revert the partial fix until a fix without the regression is in place and tested. Working on the revert now...

Change #1235853 merged by jenkins-bot:

[operations/deployment-charts@master] Revert "Update chart-renderer service for Parsoid template fix"

https://gerrit.wikimedia.org/r/1235853

Change #1235858 had a related patch set uploaded (by Bvibber; author: Bvibber):

[operations/deployment-charts@master] Reapply "Update chart-renderer service for Parsoid template fix"

https://gerrit.wikimedia.org/r/1235858

Change #1235860 had a related patch set uploaded (by Bvibber; author: Bvibber):

[operations/deployment-charts@master] Revert "Update chart-renderer to 2026-01-29-153835-production"

https://gerrit.wikimedia.org/r/1235860

Change #1235858 merged by jenkins-bot:

[operations/deployment-charts@master] Reapply "Update chart-renderer service for Parsoid template fix"

https://gerrit.wikimedia.org/r/1235858

Change #1235860 merged by jenkins-bot:

[operations/deployment-charts@master] Revert "Update chart-renderer to 2026-01-29-153835-production"

https://gerrit.wikimedia.org/r/1235860

Ok, I have reverted the production system to the version from last June that was previously running. We can fix things up on master in gitlab, then after more thorough testing we can push that back out to production.

Note that this means the single-series area charts with non-uniform data are borked again such as https://commons.wikimedia.org/wiki/Data:Test_area_chart_with_bug.chart

until a full fix is deployed.

(For charts in articles, charts will re-render along with the page they're on, as they're saved into the parser cache. Charts on Data: pages may re-render more aggressively.)

We are putting this back in our Backlog column until we get some tests in place.

Can I close the community wishlist wish that surfaced this?

I didn't know there was a community wish on this theme. Can you send it?