Hi,
for whatever reason the Heat Map node, eventually others as well, sort the y-axis descending which is rather unusual. There is no option to adjust that not does changing the aggregation method or axis limits change anything.
Using a GroupBy for the calculation does not change the sort order
Best
Mike
Hi @mwiegand and thanks for your feedback,
In general, the display logic in the current Heatmap view is top to bottom (vertical) and left to right (horizontal) which makes sense to me in heatmaps with nominal values (that’s how I read/expect heatmaps). For numbers, I’m not sure (created a ticket: UIEXT-1813)
If the horizontal/vertical dimesion is string, it uses the current sorting in the input table. e.g., First row vertical (string) value is displayed at top of the vertical axis and the first row horizontal (string) value is displayed on left side of the horizontal axis.
If the horizontal/vertical dimension is numeric, it sorts the values in ascending order. e.g., smallest vertical (numeric) value is displayed at top of the vertical axis and the smallest horizontal (numeric) value is displayed on left side of the horizontal axis.
The “Manual” axis limit works on “numeric” values. e.g., if you have a numeric horizontal dimension, you can modify the axis limit.
If you want to change the order of the values in any of the axes:
Hi @armingrudd,
thanks for your quick response. Do I understand you correctly that the Heat Map interprets numbers as nominal values? If yes, why as this could cause misrepresentation of data other then intended by the user?
Though, I must admit that I see no logic, except the data representation would require it, to have any axis by default begin of descending order. Actually, since all coordination systems have zero as their point of origin, shouldn’t the ascending order considered to be default?
Converting data to string won’t cut it because it opens up another sorting issue that all strings starting with a 1 (1, 11, 111 and so on) would be come prior to the number 2. It would be required to add leading zeros which doesn’t make things better.
PS: I came across another sorting inconsistency. Binning numerical values (lead time) and charting that on the x-axis seems to result in random order (or I do not get how it’s ordered).
Intriguingly, using the sort node, the first bin actually came out - bcs. auf the “[” vs. “(” - last but all other values were sorted as expected. So does the heat map node actually sort anything or cause randomness and thus confusion?
Best
Mike
No, please read my first and second bullet points.
Wrong! In the Sorter node, with “alphanumeric string comparison” option checked (default), 1 is prior to 2, and 11 goes after 2.
It’s not a random order, as mentioned in my first bullet point, in case of “string” dimension, the order would be the order in the input table.
If you sort the numeric column before binning, the bins will appear in the expected order.
