Change curve's color based on its position relative to a second curve

[d_stranz]

Thanks for the continued discussion, I appreciate it.

So do I. I don't like religious wars over approaches to coding or coding style, but discussions of the pros and cons of different ways to accomplish the same task are always useful.

I guess my method of thinking is shaped by being a library builder for much of my coding career. My company has millions of lines of code in libraries that we use for all of our applications, and which we have licensed to other companies in a similar business for their use. Very early on, I helped lead efforts to develop protocols for data interchange in my industry and wrote code for it (in 1992) that is still in use today. Reusability and generality is in my genetics at this point.

So, my approach when writing anything new that I view as a tool and not an application-specific piece of code is to consider the design and implementation so that it makes that tool as reusable as possible in as many different types of application as possible. Widgets for data plotting are a good example. I have developed a number of these over the years, first in MFC and then as I moved into Qt first in Qwt, then in the Qt Graphics / View framework (using some parts of Qwt in the QGraphicsScene), and now using QCustomPlot.

My goal with this latest implementation is to have a single base widget that I can use wherever I need a plot - curve, stick, scatter, bar, whatever - where each type of plot can be fed from the same data source (a QAbstractItemModel), and where the model itself does not need to keep a duplicate copy of the data. Some of my curve plots can have millions of points.

In my field, stick plots are very common. This is a plot where each data point is represented by a vertical stick starting at y = 0 and extending to the y value for that point. Each stick can have a different color, can be decorated with a symbol (like a circle, star, triangle, etc.) and have a multi-line label at the top end. So my goal is to design a curve class that can do all of those things, but where all of them (except the stick itself) are optional. I suppose I could even add a visibility flag for the sticks.

(To answer your question about the color table: if the user doesn't specify one or specifies an index outside the table range, the curve defaults to using a pre-defined single color, blue or black probably, for all points, and provides a method where you can set the default color if the pre-defined default isn't your thing).

QCustomPlot is very well-designed so that it lives up to its name - you can design something that puts nearly any type of x-y data into a plot by deriving from a low-level "plottable" class with a very basic interface that the QCustomPlot calls to actually display the plottable. Compare this to QtCharts, where the plots and their interfaces are chiseled into granite and can't be changed at all.

It is then up to the business logic to feed the plot the data and configuration details it needs to determine what to plot. So how would I handle your requirements?

1. The two curves are now no longer required to have the same x sampling. In fact, there's no requirement that any point in the reference data shares the same x value as a point in the signal data (although it's pretty likely that they will both contain a data point at x=0, but beyond that all bets are off)
2. I can't add or remove samples from either curve on the business logic side, at least not without keeping a pristine copy of the original data.

In the business logic, I would use the reference and signal data to construct the data for the curve that will be plotted using your rules for how color is determined. If I need to add extra points to the curve to accommodate color changes, fine, only the plot will know. The original data is unchanged, it is only the data that will be plotted that shows the result of the calculation.

This is what I have referred to in other posts as distinguishing between the map and the terrain. The terrain is a constant - it's the Earth and it is what it is. How you draw the map of that terrain of course depends on the terrain, but you can draw the map at any scale, add false color, contour lines, names for roads and buildings, none of which you see when you look at the dirt in front of you.

So in your case, instead of the curve class doing the calculation of color, I would write a separate, business-specific class that takes the signal and reference data structures and produces a plot-compatible data array with the color or color index of each point specified that will be fed to the generic curve class that knows what to do with such data.

Adding the ability to specify a color on a point-by-point basis adds to the reusability of the curve class. Sure, a two-pen solution might meet the current need, but maybe the next project will require a curve that can be color-coded to indicate a change in one variable as another changes - think of a plot of the elevation changes along a stream bed that codes changes in water velocity with the color of each point or section of the curve. Two pens aren't enough, and maybe a mapping function is needed that converts a y value into a color from a QGradient will work better.

Yes, all of this is more work, and will likely require tweaking, but with enough thought put into the design and implementation of the component side, I can pull that component out of the box, plop it into a window, and just use it. My application is responsible for feeding it data as required and I can use the same component across many applications.