Heat Map sorts y-axis descenting

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:

1. convert the column to string (if itâ€™s numeric)
2. sort the values
2 Likes

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