# Heat Map sorts y-axis descenting **URL:** \ **Category:** Feedback & Ideas\ **Tags:** bug\ **Created:** [April 2, 2024, 8:27am UTC](https://forum.knime.com/t/heat-map-sorts-y-axis-descenting/78270 "2024-04-02T08:27:38Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mwiegand](https://forum-cdn.knime.com/user_avatar/forum.knime.com/mwiegand/32/66896_2.png) [@mwiegand](https://forum.knime.com/u/mwiegand)\ **Post date:** [April 2, 2024, 8:27am UTC](https://forum.knime.com/t/heat-map-sorts-y-axis-descenting/78270/1 "2024-04-02T08:27:38Z")
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. ![image](https://forum-cdn.knime.com/uploads/default/original/3X/f/1/f15c2732b7d17e1eb771037af295ae6a08848354.png) Using a GroupBy for the calculation does not change the sort order ![image](https://forum-cdn.knime.com/uploads/default/original/3X/7/a/7ad870f360ea6da3dc2d41976285f0cf5d5222c0.png) Best Mike ---
**Author:** ![armingrudd](https://forum-cdn.knime.com/user_avatar/forum.knime.com/armingrudd/32/84633_2.png) [@armingrudd](https://forum.knime.com/u/armingrudd)\ **Post date:** [April 2, 2024, 10:57am UTC](https://forum.knime.com/t/heat-map-sorts-y-axis-descenting/78270/2 "2024-04-02T10:57:56Z")
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 ---
**Author:** ![mwiegand](https://forum-cdn.knime.com/user_avatar/forum.knime.com/mwiegand/32/66896_2.png) [@mwiegand](https://forum.knime.com/u/mwiegand)\ **Post date:** [April 2, 2024, 11:33am UTC](https://forum.knime.com/t/heat-map-sorts-y-axis-descenting/78270/3 "2024-04-02T11:33:05Z")
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). ![image](https://forum-cdn.knime.com/uploads/default/original/3X/b/7/b70aa4f36099b9c0a0f80cdc45b39cd700f7588d.png) 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? ![image](https://forum-cdn.knime.com/uploads/default/original/3X/f/3/f3c45480624d311ad4efdbe24aabc828d5bb46af.png) Best Mike ---
**Author:** ![armingrudd](https://forum-cdn.knime.com/user_avatar/forum.knime.com/armingrudd/32/84633_2.png) [@armingrudd](https://forum.knime.com/u/armingrudd)\ **Post date:** [April 2, 2024, 12:11pm UTC](https://forum.knime.com/t/heat-map-sorts-y-axis-descenting/78270/4 "2024-04-02T12:11:31Z")
> [@mwiegand](#): > > Do I understand you correctly that the Heat Map interprets numbers as nominal values? No, please read my first and second bullet points. > [@mwiegand](#): > > 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. Wrong! In the Sorter node, with “alphanumeric string comparison” option checked (default), 1 is prior to 2, and 11 goes after 2. > [@mwiegand](#): > > I came across another sorting inconsistency. Binning numerical values (lead time) and charting that on the x-axis seems to result in random order 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. > [@mwiegand](#): > > Intriguingly, using the sort node, the first bin actually came out - bcs. auf the “[” vs. “(” - last but all other values were sorted as expected. If you sort the numeric column before binning, the bins will appear in the expected order.