Open pacioos opened 5 months ago
Having a generic u:v-group also makes it impossible to have more than one vector variable in a dataset (e.g., sea_water_velocity and wind).
Ah, yes, I see the issue. It's not a generic name, but rather the non-matching part of the variable names. So if you have u_wind
and v_wind
, you get u:v-group
. So the only way to have multiple vector variables is to use different naming conventions (e.g. u_wind
/eastward_sea_water_velocity
/x_slope
.
We won't revert to using standard name, since that doesn't allow for multiple different representations of the same quantity (e.g. 2 types of sea_water_velocity
- for example average and peak within a time period), but I agree that there does need to be a check for name collisions.
I currently have very little time to work on this. I've put a fix in the code to ensure that the new IDs will be unique for variables. I don't anticipate having the time to do a release in the near future, but if you are able to test this from the code and give me feedback, it'll make it in the next time I do perform a release.
Thanks, Guy. I did not realize the vector variables were named off of the "non-matching part of the variable names". I figured it would always be u:v-group
, so that is helpful to know!
In looking through my datasets, though, this rule doesn't seem quite accurate enough. I have a dataset with ugrd10m
and vgrd10m
variables that get grouped as ugrd10m:vgrd10m-group
. The "non-matching part" would have made it u:v-group
. Similarly, Uwind
and Vwind
in this dataset become Uwind:Vwind-group
rather than U:V-group
.
So, is the rule actually that it combines non-matching parts of the variable names up to the next underscore character, if any? Or does it actually always combine the full variable names? e.g., eastward_sea_water_velocity
and westward_sea_water_velocity
variable names would be combined into the rather lengthy eastward_sea_water_velocity:westward_sea_water_velocity-group
vector variable?
Thanks for putting in a fix to ensure unique IDs. Unfortunately, being reliant on using this via TDS, I'm not versed at how to test this from the code directly. In any case, knowing more about the new rules in ncWMS2 for naming vector quantities has been instructive in itself. Any further details or clarifications based on the above will help me transition my display tools to TDS5/ncWMS2 in the near future.
I would also like to know if there is a pattern that can be used to pre-determine the new "unique ID" part, as well. If it is unpredictable, then client viewers will need to traverse the GetCapabilities
for determining the group variable name. And will this ID be tacked on only when there are naming collisions? Or is the new unique ID an enforced mandatory part of the vector variable names that we should always account for (when this fix is released in the future)?
Many thanks!,
John Maurer, PacIOOS
Sorry, you're quite correct, I was getting confused with the bit of the code which detects vector fields (for various reasons I don't have a dev environment set up at the moment, so I had to eyeball it). I was also assuming that you had had a name collision error with u:v-group
, but on re-reading, you didn't actually say that.
So yes, the rule is actually very simple, it is just the combination of x + y variable names, separated by a colon. So a vector field created from two variables named "varX" and "VAR_Y" would provide varX:VAR_Y-group
, as well as varX:VAR_Y-mag
and varX:VAR_Y-dir
. I've reverted the change I made, so this rule will continue to apply.
In summary:
For a vector field made from variables named x
and y
, set WMS_LAYERS to x:y-group
The layer name required for vector layers in the WMS LAYERS parameter has changed in TDS5/ncWMS2. In TDS4/ncWMS, a vector layer was dynamically-generated by ncWMS from the component
standard_name
attributes: e.g.,eastward_sea_water_velocity
andnorthward_sea_water_velocity
. This would then be accessed via the WMS LAYERS parameter by specifying the combinedstandard_name
ofsea_water_velocity
. In TDS5/ncWMS2, however, the layer must now be specified in LAYERS by the genericu:v-group
layer name, instead. All client code and TDS configurations that were used to enactsea_water_velocity
will now need to be updated to specifyu:v-group
as the layer name in any WMS request (e.g., GetMap, GetMetadata) instead. Could it possibly be restored to using (or also honor) thestandard_name
(e.g.,sea_water_velocity
)? Having a genericu:v-group
also makes it impossible to have more than one vector variable in a dataset (e.g.,sea_water_velocity
andwind
).