WIP: Initial dataset transformation extension for virtual vector vars

[srstsavage]

Generates speed and direction variables from detected component vars.

Currently a proof of concept, the results are incomplete and surely incorrect in many (all?) cases.

Specifics on how to render the directional variable with arrows/barbs and how to structure requests for and layering of the speed/magnitude and directional layers are TBD.

[mpiannucci]

specifics on how to render the directional variable with arrows/barbs and how to structure requests for and layering of the speed/magnitude and directional layers are TBD.

Once these variables are added to the dataset, they should just work with the wms plugin as raster. From there we can add vector styles to the wms to get arrows or barbs or whatever else we would want

[srstsavage]

Yep, naive raster rendering of both the constructed speed and direction vars is currently working. I guess I'm wondering about the approach of having these two separate variables and how they should behave when rendered. Should a client explicitly request both of them in the WMS layers param if they want to see direction overlaid on magnitude/speed? Or should requesting a single constructed var (either speed or direction) always result in both being rendered in the same tiles? (probably not)

ncWMS presents a single vector variable to the user (e.g. "wind" instead of "wind speed" and "wind direction"), but that doesn't feel like the correct approach here.

[mpiannucci]

I like the grouped approach that ncwms uses so like u:v-group? We could then allow users to do that with pretty much whatever they want if they choose?

[jonmjoyce]

I have historically worked with winds as a single derived variable (wind) with a config defining that it's comprised of ugrd/vgrd (HRRR naming convention). The main problem eventually comes down to the data access layer which then either has to have a bunch of if(derived) statements or abstract that to a derived var reader. But for the front-end and API it should probably be 1 variable name. I like Matt's suggestion of having a derived variable naming convention.