Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Does cewolf support heat maps?
Currently it does not, chiefly because the underlying chart library (JFreeChart) does not support that. There are some hints on how one might go about implementing them (like http://stackoverflow.com/questions/10739422/heatmaps-with-jfreechart and http://www.jfree.org/jfreechart/api/javadoc/org/jfree/data/general/HeatMapUtilities.html), but I haven't had a use for them nor has anybody asked for them so far.
How would you envision heatmaps to work, i.e, what data to pass in, and in which formats, and how would the output reflect that data?
I actually wasn't asking for myself, so I'm not sure about the nature of data or of the visualization. The question was asked for a project that uses cewolf for charts, see http://sourceforge.net/p/art/discussion/352129/thread/d8ab9d0b/. I'll ask the poster there to pursue the matter here.
Thanks for your help. I am using a Mondrian Pivot table, and the way I envision it similar to the Excel Conditional Formatting. I want for example lower values to show green and higher values to show red, in between values to show yellow etc.
I am using the concept in that higher numbers lets say high 40 to 50 are bad values, and low numbers such as 0 to 10 are good values so display them as green. All in between orange and yellow. etc.
This is how I have the chart in excel pivot point using conditional formatting, so I am trying to recreate the same using the MDX and ART, I can do the pivot fine but I cant make it a heat-map.
Do you have a sample of how the chart would look? Is it just a table with cells of different colours? Like these?
Yes it would be exactly like the fusion charts heat maps. Can I create the same chart in ART ?
No. heat maps are not available in ART. They may be added in the future, If they become available in cewolf.
I had a look at how this might be done using what JFreeChart offers, and implementing something along the lines of the first link I posted, I got something basic up and running. It still needs some polishing, and doesn't go nearly as far as what FusionCharts offers, but it's a beginning. I should have a beta version available within the next week or so; I'll announce it here when it's available.
Much appreciated. I look forward to trying it out.
Thank you, I cant wait to try it out…
I've uploaded a new cewolf jar file to the "beta" directory, along with an example JSP file that demonstrates heat maps in action.
If no "color#..:" parameters are used in the postprocessor, then a uniform gray coloring is used; in that case the "subdivisions" parameter determines how man different shades of gray are used. The "value" of the color parameter consists of the lower bound from which on to use the given color, and the RGB value of the color itself, separated by a colon. For the lower bound it's also possible to use percentages if the exact values are not known, or not available in the JSP page. Such entries would look like "0%:#0000FF" and "50%:#FFFF00" for a two-colored scheme.
Note that cewolf now requires Java 5, but since even that has been obsolete for years, it shouldn't cause any problems.
Thanks for this. I'll use the beta in the ART project and report any issues I encounter.
A couple of thoughts:
1. Could the HeatMapEnhancer check that the renderer is a XYBlockRenderer, in addition to checking that the plot is an XYPlot. To avoid throwing an exception with the wrong chart type
2. If no color# parameter is used, a gray scale is used. Would it be possible to specify another colour to use instead of grey. e.g. shades of red.
I also notice that for the grey scale, bigger values have a lighter colour. I would expect higher values to have darker colours? i.e. the bigger the value, the more black.
A few more items.
1. When a parse/convert error occurs for subdivisions and stripwidth, can the values set be the same as the defaults? For uniformity?
2. For scaleTextPos, what is the difference between say topleft and topright? Both seem to produce the same effect, the scale text centered at the top. Perhaps the option could take just two values, top and bottom?
- Checking for the right renderer type: sure
- Other colors than greyscale if no colors are specified: yes, that's a useful feature
- Higher values = darker colors: I think that's a personal preference. To me it makes more sense the way it is now. But I have an idea for the previous point which *may* address this one as well.
- Subdivisions/stripwidth: yes, exceptions should cause the defaults to be used
- scaleTextPos: topleft means "top or left"; same for the others. JFreeChart might place it in either position depending on where it thinks is more room for it. That's just mirroring the underlying JFreeChart functionality.
I'll put up another beta that adresses these issues, but probably not before next weekend.
I've just uploaded a new beta version that addresses the issues I mentioned in my previous post. Color scales are now possible between two arbitrary colors (given as "lowerColor" and "upperColor"), which addresses the 2nd and 3rd issue. The JSP has been extended to demonstrate that feature. Let me know how you make out.
Everything works fine.
Just a note. Is there logging being done by the 2nd beta? Stuff like
value=-1.0, v=-1.0, vi=0.0
r=255, g=255, b=255
I don't think I noticed this with the first beta.
Excellent; then I'll make it an official release soon.
That's debug logging; it won't happen in the final release.
I look forward to it. Thanks for taking the time to implement this feature.
Version 1.2 has just been released.