variable groups not created

[docgregt]

I have two fields that are u/v of wind vectors. I am unable to name them in any way that ncwms will recognize and create a group so I can draw wind arrows and barbs. Can I configure the group manually in XML and what is the format? or what do i need to name the variables to get ncwms to do it automatically?

Greg

[guygriffiths]

You need to set the standard_name attribute of each field to something which defines them as vector components. Specifically, you should have a pair of one of:
eastward_<variable>, northward_<variable>
u-<variable>component, v-<variable>component
<variable>x-<string>velocity, <variable>y-<string>velocity

[docgregt]

Thanks. That worked well.
I receive wave height and direction as magnitude and direction (degrees). How can I form a group with that since it is not u,v or x,y kind of vector?

[guygriffiths]

That's not currently possible. What are the standard names? I can look into implementing this in the next release, it won't be particularly difficult. The main issue is the difference in conventions between directions (e.g. "east" can mean "travelling east" or "coming from the east" depending on context).

[docgregt]

Oh wow. What is the approach for rendering wave direction? So other systems just allow groups to be created and then the rendering is handled in the SLD. Then you dont have to worry about east, etc. as that can be handled in the SLD.

[guygriffiths]

As it stands, "direction" always has the sense of "direction quantity is moving towards". Users who want the meteorological sense have a different style available. Looking through the standard names table most directional fields specify to_direction or from_direction, so I would implement it by automatically grouping fields containing those strings.

We don't currently allow arbitrary grouping of layers, but I'm not sure what you mean when you say that rendering is handled in the SLD. Although we define everything in terms of (template) SLDs, we only really support custom layers which we then render ourselves.

[docgregt]

Ok. I am not as familiar with the SLD on your server, but on GeoServer I can use following to compute rotation:

                      <Rotation>
                          <ogc:Function name="Categorize">
                               <!-- Value to transform -->
                               <ogc:Function name="sqrt">
                                <ogc:Add>
                                    <ogc:Mul>
                                      <ogc:PropertyName>u</ogc:PropertyName>
                                      <ogc:PropertyName>u</ogc:PropertyName>
                                    </ogc:Mul>
                                    <ogc:Mul>
                                      <ogc:PropertyName>v</ogc:PropertyName>
                                      <ogc:PropertyName>v</ogc:PropertyName>
                                    </ogc:Mul>
                                </ogc:Add>
                              </ogc:Function>
                               <!-- Output values and thresholds -->
                               <ogc:Literal>0</ogc:Literal>
                               <ogc:Literal>1.543333332</ogc:Literal>
                                <ogc:Function name="toDegrees">
                            <ogc:Function name="atan2">
                            <ogc:PropertyName>u</ogc:PropertyName>
                            <ogc:PropertyName>v</ogc:PropertyName>
                         </ogc:Function>
                          </ogc:Function>
                        </ogc:Function>
                     </Rotation>

This is a costly calculation considering I can just precompute the angle once and store it as a layer instead of u,v. Using angle and magnitude then the rendering is quite fast.

[guygriffiths]

We haven't implemented the ogc functions of SLD, we just use it as a framework for our own visualisation types. It would be useful in cases like this, but it's not been necessary so far and it's a fair bit of work to implement. We do have a similar calculation in our vector calculations, but I think it is pretty fast compared to data I/O.