Heatmap changed with latest version
This discussion was imported from CodePlex
AvanDiepen wrote at 2013-12-12 08:31:
The latest download (OxyPlot-2013.2.140.1) shows me another heatmap then the versions before.! Is there a change, it looks so different...
AvanDiepen wrote at 2013-12-12 13:53:
Please note: If I do a CTRL-ALT-C on the graph screen, the data is identical but the graph differs.
objo wrote at 2013-12-12 17:34:
Are any of your axes reversed? The new code takes axis reversal into account, but I think there may be a bug if X0>X1 or Y0>Y1.
I did not see any differences in the examples included in the example library.
I did not see any differences in the examples included in the example library.
AvanDiepen wrote at 2013-12-12 18:57:
Thanks for your quick respons.
The Y-Axis is reversed because these are the rotors of a cold mill. The bottom is rotor 21 and at the top of the Y-axis is rotor 5. The view is from the operator room of the cold-mill. Till version 139 it worked well. If you need some pictures I can send it to you.
Thanks in advance.
The Y-Axis is reversed because these are the rotors of a cold mill. The bottom is rotor 21 and at the top of the Y-axis is rotor 5. The view is from the operator room of the cold-mill. Till version 139 it worked well. If you need some pictures I can send it to you.
Thanks in advance.
objo wrote at 2013-12-12 20:15:
I have corrected the bug for X0>X1 and Y0>Y1.
I guess you can swap Y0 and Y1 in your HeatMapSeries to correct the problem.
Let me know if there are better ways to define this to make it less confusing!
I guess you can swap Y0 and Y1 in your HeatMapSeries to correct the problem.
Y0
should define the y-coordinate of the Data[*,0]
elements. If this is on the top or the bottom depends on the vertical axis.
Let me know if there are better ways to define this to make it less confusing!
AvanDiepen wrote at 2013-12-13 07:08:
Thank you objo, now it's working the same as before. (with the latest v 2013.2.141.1)
AvanDiepen wrote at 2013-12-13 07:28:
Sorry there's still a problem if the lowest number of the Y-axis is at the bottom (say Cartesisch) and the highest above, the graph is not the same as before.
Reason to do this: Sometimes they want to swap the rotors of the roll(steel); if the roll is handled in another mill.
I only use:
Reason to do this: Sometimes they want to swap the rotors of the roll(steel); if the roll is handled in another mill.
I only use:
if (cbSwapRotors)
{
linearAxisRotors.EndPosition = 1;
linearAxisRotors.StartPosition = 0;
}
else
{
linearAxisRotors.EndPosition = 0;
linearAxisRotors.StartPosition = 1;
}
and of course the data is refilled from the database in a two dimensional array. That's all I do.objo wrote at 2013-12-16 20:30:
Can you create a small example that fails? I think all the current examples in the example library are working (correct me if I am wrong)
AvanDiepen wrote at 2013-12-17 12:45:
When I was creating a test model for you I saw that using start- and endposition was enough for the right result (in the latest version), but in version 139 and before I had to load the peak data the other way around. (much more code) With the latest version
the following routine is doing the whole fill:
for (int iRow = 0; iRow <= iMaxArrayIndex; iRow++)
{
this.listScheefstand.Add(new DataPoint((int)(dataTableVormData.Rows[iRow]["length"]),
Math.Abs((int)(dataTableVormData.Rows[iRow]["flatn_error_steer"]) - MiddelsteBedekteRotor)));
meters[iRow] = (int)dataTableVormData.Rows[iRow]["length"];
for (int iMeting = iLeftsensorPLUSsideOffset; iMeting <= iRightsensorMINsideOffset; iMeting++) // sensors
{
if ((string)(dataTableVormData.Rows[iRow]["SS" + iMeting.ToString().PadLeft(2, '0')]) != "U")
{
// Covered
peaksData[iRow, iRightsensorMINsideOffset - (iMeting - 1)] =
(int)dataTableVormData.Rows[iRow]["SD" + iMeting.ToString().PadLeft(2, '0')];
}
}
}
Thanks for your help objo.Customer support service by UserEcho