Don't make zero impact values transparent in rendered result image

[hav-gerdint]

Currently all values below 0.01 are made transparent in the resulting image (see symphony-ws/src/main/resources/styles/result-style.xml). When doing rarity-adjusted calculations based on local rarity domains it is plausible that many result pixels fall into this category (at least with the default "maximum value in area" result colormapping). The end result may be that the result image is almost totally transparent, and the user may have the perception that the calculation is broken.

To make the result more clear it would be desirable that instead of making zero (or low-impact) pixels transparent they the results colormap should be transparent only values outside of the calcuated area. Areas outside the area can be set to NODATA in the calculation loop (the pixels outside of the calculation area will have a zero mask value), and the rendering colormapping can be adjusted to make NODATA values transparent instead.

Currently we do not set any NODATA value in the result image. I guess the value could be Integer.MIN_VALUE and Double.MIN_VALUE (depending on the type of the result image), since impact is always greater than or equal to zero.

[hav-gerdint]

N.B: Imperative to set the NODATA value in the geotiff metadata (which should be derived from the GridCoverage's NODATA property, which thus needs to be set)

[hav-gerdint]

It is possible that the "Extrema" and "Histogram" JAI operations need to be converted to use JAI-Ext's "Stats" operator (which handles NODATA, which the classical JAI ones typically don't).

[hav-gerdint]

Very nice. Histogram feels more intuitive now!

[hav-gerdint]

One issue though. As indicated in the title of this issue the main objective from my PoV is as the issue title indicates that pixels with 0 impact shouldn't be transparent. It seems like they still are? (And the result-style.xml explicitly states it) My idea was to have the NODATA values be transparent in the result image, but zero pixels should NOT be transparent (instead some dark shade of blue). It would then be easier to see that impact is actually mostly zero in most pixels in rarity-adjusted calculations for instance. Not sure if the GridCoverageRendered supports it (though I guess it should). See the call at

MSP-Symphony/symphony-ws/src/main/java/se/havochvatten/symphony/web/WebUtil.java

Line 73 in 6062787

return renderer.renderImage(cov, symbolizer, new InterpolationNearest(), new Color(0, 0, 0, 0), 0,

Perhaps @hammarlinus can chime in on this.

[ann-hav]

... the issue title indicates that pixels with 0 impact shouldn't be transparent. It seems like they still are?

Values approaching 0 are rendered semi-transparent, but for minimal values the inversely proportional alpha indeed makes them practically invisible in the corresponding image.
You're right and I'll work on a revision targeting this, taking @hammarlinus' opinion into account.