-
Notifications
You must be signed in to change notification settings - Fork 411
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
Have smoothing functions return named DataArrays #3258
Comments
#2369 is another instance of this problem. I think it might be possible to have our xarray handling automatically add a name. The obvious part is including something like It's obvious in this case, where you could use the name of the 1 xarray input. But what would you do for e.g. |
For |
Actually, that's a really good point that 1 argument should be One limitation is that this doesn't help us solve #2369, but that doesn't eliminate this approach. One outstanding question: Do we have any functions that return multiple values that we need to consider how to handle? |
Looking back at the relevant code, this should definitely be possible, but I suspect it may not be the wisest approach as a uniform principle (e.g., not sure we really want
I unfortunately can't recall any examples off the top of my head, but the |
Curses, foiled again. Your suggestion sounds like a good way to progress. It will result in some unfortunate complexity. I suppose this isn't a uniquely MetPy problem. I assume that's because it's not as common for people to put these back into @sgdecker What's the original use case for wanting the data to be present within a |
The immediate use case here was to create a @jthielen 's example of |
What should we add?
Currently, functions like
smooth_gaussian
return DataArrays with no names. This causes problems if you want to combine DataArrays into a Dataset, as in the following example:My feature request is that functions like this (where the output is of the same nature as the input), when given DataArrays as input, return DataArrays with reasonable names, akin to what the working version of the code does, but internally, so that users need not use
.rename
themselves.Reference
No response
The text was updated successfully, but these errors were encountered: