Feature Request - Precipitation Type

[Craytor]

This package has been amazing to work with! I'm wondering about the possibility of adding precipitation data to model data. Models have reflectivity, and they also have information about precip type. I'm wondering about the possibility of supporting precip type down the road. I know this is a rather complex task, but would we be able to achieve this using a "filter" in WebGL to apply a separate color palette based on the precipitation type? Finally, for the required data, in terms of the current project, this would require three or four items in addition to reflectivity - CSNOW, CICEP, CFRZR, and possibly CRAIN. Perhaps CRAIN may not be needed as if your precip type is not snow, mix, or freezing rain, it's going to be rain?

Thoughts on this? In terms of structure - perhaps this should be an additional layer type such as a "Shaded Layer" and perhaps the inputs could be data, and then the layer types. I think that this should also be applicable to both ContourFilled and Raster.

I'm willing to help out any way possible, but my knowledge of WebGL is lacking.

[tsupinie]

Yeah, I think this could be an interesting addition. I'm trying to mull over in my head exactly how I would want it to look and how I would want the code to be structured. But it's doable, and making it part of the library would be more efficient than just having the user add four layers if they wanted a ptype display.

[Craytor]

I was curious if you've given this any more thought on a "best approach."

[tsupinie]

The short answer is "yes, but ..."

Basically, my plan was to allow the user to pass a mask to the ContourFill and Raster classes that would select from a bunch of different colormaps that the user could pass in as well. The problem with that is, due to the way I'm implementing colormaps right now, each colormap takes two textures.

The maximum number of textures (per draw call) that's guaranteed to be supported on all hardware is 8, so a colormap taking two textures is a bit wasteful in that context. If a user wanted to do something like PivotalWeather's precip type/precip rate plot (attached), they'd need one texture for the precip rate, one for the precip type mask, and eight for the colormaps. That's 10 textures, so above that limit.

So I went down a rabbit hole of trying to get each colormap down to one texture, which for WebGL reasons is gonna be trickier than I thought it was gonna be when I started. (Plus, I realized I might have a fencepost bug in colormaps for Raster plots, which I'll need to fix somehow.) I haven't worked on this in a bit, so I might pick it up again soon.

gets up, walks around, makes lunch

Though now that I think on it for a few minutes ...

I could still have that API and basically draw each color separately. So in the precip type/precip rate example, you'd have one draw call for the rain ptype, one for the snow ptype, etc., and it would be transparent to the user. That would get around that WebGL limitation, and I wouldn't be stuck on the colormap optimization.

Well, thanks for the unintentional rubber-ducking!