confusing behavior: one or more series or what?

[jjspoc]

Dear,

I´m struggling with confusing behaviour of the render. GF timeseries does it correctly from the beginning and I´m not sure whether this is one of the bug, feature, RTFM cycles. For the latter I came to the conclusion that I would ask for help. (win11 docker environemt, postgres/timescale for data and GF config, GF 10.0.0, tested with the great (!) echart plugin V 4.5 and 5.0, the code preamble as per Volkov documentation.

-1- the data are simulated temperatures, a string ID, time and float for the values
-2- the GF timeseries panel works as expected out-of-the-box
-3- echart panel renders the data as if it would be one series, though two IDs were selected, the lines are not drawn correctly
-4- when a transformation "prepare for time series" is added, the line drawing glitch is gone, still one series
-5- when two queries, one for each ID were done the echart plot is as expeted
-6- as it is not known whether two, or three IDs will be selected that´s not the way to go

What´s up here, anything I´m doing wrong?

That´s the query;

SELECT patientid, "time", "temp"
FROM public.body_temperature
WHERE patientid IN ('P00001','P00009')

or

(A) WHERE patientid IN ('P00001')
(B) WHERE patientid IN ('P00009')

That´s the data:

patientid time temperature
P00001	2023-04-07 12:20:44.000 +0200	37.1
P00001	2023-04-04 07:39:56.000 +0200	37.2
P00001	2023-04-02 07:39:53.000 +0200	36.8
P00009	2023-07-05 06:00:23.000 +0200	36.8
P00009	2023-07-02 04:05:45.000 +0200	37.2
P00009	2023-07-02 03:11:39.000 +0200	36.9

That´s the screenshot with the outcomes:

[mikhail-vl]

@jjspoc That's an interesting example. You are probably using the default function, which support multiple queries and each query has different names.

When you are using Transformations, each transformation parse/transform data frames differently.
In case of prepare time series, multi-frame time series, both transformed data frames has the same names and can't be distinguished by echarts.

Instead you should use labels id from the number field like:

const series = data.series.map((s, j) => {
  const sData = s.fields.find((f) => f.type === 'number').values.buffer || s.fields.find((f) => f.type === 'number').values;
  const sTime = s.fields.find((f) => f.type === 'time').values.buffer || s.fields.find((f) => f.type === 'time').values;
  const data = sData.map((d, i) => [sTime[i], d.toFixed(2)]);

  return {
    name: s.fields.find((f) => f.type === 'number').labels.id,
    type: 'line',
    showSymbol: false,
    areaStyle: {
      opacity: 0.1,
    },
    lineStyle: {
      width: 1,
    },
    data,
  };
});

Let me know if it's clear.

[jjspoc]

interesting, many thanks for the explanation and help. See the new panel, which indeed works as expected:

[mikhail-vl]

@jjspoc Thank you for confirming.

Let us know if there is anything else.

[jjspoc]

yes, @mikhail-vl, it took a while until this question came to my mind.

A general question regarding series.data: vs dataset: ; I understand that the eChart team recommends the use of dataset: over series.data See eCharts docs: Concept.
What is your take on this? Is there any particular reason for you to go the way you are going?

Their argument makes sense to me, though I'm unable to get even a simple chart up and running (due no javascript skills :-( at my end). In the above example I could at least see my data in the Chrome debugger. I'm already spending far too much time with this but I do see the potential for eCharts and your way of doing it.

What I also realised, is that the GF multiframe transformations (wide table , long table, multiframe) are at least accepted and in my naïve understanding should be processed and charted by eCharts accordingly (...if I would know more about JS)

const allOfIt = data;

console.log("All data: ", allOfIt);

return {
  tooltip: {},
  dataset: { allOfIt },
  series: {
    type: 'line',
  }
};

See snippet here:

series: Array(1) 0
  fields:  Array(3)
    0: {name: 'time', type: 'time', config: {…}, values: Array(178), state: {…}, …}
    1: {name: 'temp', type: 'number', config: {…}, values: Array(178), state: {…}, …}
    2: {name: 'patientid', type: 'string', config: {…}, values: Array(178), state: {…}, …}

[mikhail-vl]

@jjspoc Thank you for the questions, which makes me think more about Data sets.

We are looking to improve ECharts experience in Grafana to parse Query data into friendly structure and Data set works perfectly for it: #210.

I will plan it for the upcoming release.

[jjspoc]

This sounds very good - thanks for addressing the topic, Mikhael. I just want to share a few ideas & thoughts around this theme. Apologies upfront for the wordy message to GIT. Viz tools like Tableau and Spotfire allow the user to drag "dimensions" around and let you drop them on the respective axes. The right thing for non programmers. You may want to have a look at gapminder.org , in particular at this demo: https://www.gapminder.org/tools/ Hans Roslin developed the site quite a few years ago - pretty GF like I would say. He unfortunately passed away, I'm glad to see that the project is still around and apparently maintained. (The content is also great so are the talks from Hans Roslin on YT) [http://www.gapminder.org/tools/assets/images/social-share.png]<https://www.gapminder.org/tools/> Gapminder Tools<https://www.gapminder.org/tools/> Animated global statistics that everyone can understand www.gapminder.org What if a separate understand-data-structure plugin parses query results (aka RefId) and presents either code for a mapping (to be cut-n-pasted), or a view of how the data are being interpreted in order to guide the user to the required data structure - if wanted, one could add the buzz label "AI inside" to it. What annoys me in GF is that the user doesn't get a clue what structure data should be in (notable exception are the node Graph, where they list mandatory and optional fields. Or, why data is not parsed. That´s an issue upfront to map() or find() for eChart, however. Hope my comment makessense and I do hope this is a place to have that conversation. With best regards, Jörg

…

________________________________ From: Mikhail Volkov ***@***.***> Sent: Monday, August 21, 2023 10:05 PM To: VolkovLabs/volkovlabs-echarts-panel ***@***.***> Cc: jjspoc ***@***.***>; Mention ***@***.***> Subject: Re: [VolkovLabs/volkovlabs-echarts-panel] confusing behavior: one or more series or what? (Issue #201) @jjspoc<https://github.com/jjspoc> Thank you for the questions, which makes me think more about Data sets. We are looking to improve ECharts experience in Grafana to parse Query data into friendly structure and Data set works perfectly for it: #210<#210>. I will plan it for the upcoming release. — Reply to this email directly, view it on GitHub<#201 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYFEZWSGKEQKXF2E36QLQK3XWO5PTANCNFSM6AAAAAA2TZPFQE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mikhail-vl]

@jjspoc That does make sense and thank you for suggestions.

We are aiming to improve Apache ECharts user experience in the feature versions. Actually, we already started working on a visual editor to make it plug-and-play as possible and keep the customization capabilities.

You will this some of those improvements in the upcoming version. PR: #211