Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vector layer name changes in TDS5/ncWMS2 #165

Open
pacioos opened this issue Mar 4, 2024 · 3 comments
Open

vector layer name changes in TDS5/ncWMS2 #165

pacioos opened this issue Mar 4, 2024 · 3 comments

Comments

@pacioos
Copy link

pacioos commented Mar 4, 2024

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 and northward_sea_water_velocity. This would then be accessed via the WMS LAYERS parameter by specifying the combined standard_name of sea_water_velocity. In TDS5/ncWMS2, however, the layer must now be specified in LAYERS by the generic u:v-group layer name, instead. All client code and TDS configurations that were used to enact sea_water_velocity will now need to be updated to specify u: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) the standard_name (e.g., sea_water_velocity)? 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).

@guygriffiths
Copy link
Contributor

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.

@pacioos
Copy link
Author

pacioos commented Mar 5, 2024

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

@guygriffiths
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants