I am trying to create a heatmap with a custom sort for x-axis values. In this example, the x-axis values are weather conditions and have similar names.
For instance, I want to show "Partly Cloudy," "Cloudy," and "Mostly Cloudy" next to each other, as well as "Light Snow," "Snow," and "Heavy Snow" (preferably in that specific order, although any solution that properly lumps them together would be sufficient).
To do this, I attempted to create a Split Chart with Sub Aggregation "Filters," where I could define values like "Cloudy," "Sunny," "Snow," etc. (think of these like the "root" word or condition). I then attempted to use a "Terms" Sub Aggregation for the X-Axis to show the values.
Unfortunately, it seems I am forced to show all terms for all filters, even when they don't apply. Regardless whether I choose "Rows" or "Columns" for the Split Chart configuration, there's a lot of dead space. ("Columns" seems to be a slightly better fit, as it doesn't force the y-axis to be repeated.)
Is it possible to ONLY show the x-axis labels for terms that are found within the filter subset? Is there another way for me to manually sort the Terms?
In the above picture, I am looking to only show the columns in green.
I also tried to use some sort of modified "Order By" criteria, but they seem to be too limiting for my needs. An alphabetical sort could potentially work if it allowed me to sort on the second word (as defined by a preceding space).
Hmm, this isn't going to work how you've currently got it set up.
The best way I can think of to accomplish this is using a scripted field. You could make it something like the following:
if (doc['current.conditions.keyword'].value.equals('Partly Cloudy')) return 0;
if (doc['current.conditions.keyword'].value.equals('Cloudy')) return 1;
if (doc['current.conditions.keyword'].value.equals('Mostly Cloudy')) return 2;
etc. etc. and then use the average of that field as your custom sort in the heat map. Then you'll need to get rid of your split by filters aggregation. Could you give that a try?
It looks like this worked, thanks! I had to create a quick data table view to see all the distinct values I've collected so far, and use that to manually return a distinct number for each distinct value.
For the final statement, I used a return command with a value one greater than all other returns - I assume this is a good "catch-all" for any otherwise unencountered value, and would properly sort them at the end, right? For example, imagine the fourth line in the script example you pasted was:
return 3;
Do you see any issues with using a catch-all like this?
The documentation for scripted fields indicates this is a potentially performance-impacting configuration, meaning I doubt this would be something one would want to use in production. Is there any way to reduce the impact or otherwise create a production-friendly solution?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
