-
Notifications
You must be signed in to change notification settings - Fork 30
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
Comments
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 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 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 In looking through my datasets, though, this rule doesn't seem quite accurate enough. I have a dataset with 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., 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 |
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 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 In summary: |
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
).The text was updated successfully, but these errors were encountered: