Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location. However, if nothing is drawn for a location X,Y where U,V are masked, this would seemingly lead to a problem where the locations and the things to be drawn get out of phase. Am I missing something here? Eric, did I miss some magic somewhere in quiver that handles this?
Ryan
···
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Ryan May wrote:
Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location. However, if nothing is drawn for a location X,Y where U,V are masked, this would seemingly lead to a problem where the locations and the things to be drawn get out of phase. Am I missing something here? Eric, did I miss some magic somewhere in quiver that handles this?
Ryan
Ryan,
There is no magic; we are not compressing or otherwise extracting the valid values, but are leaving the masking of U and V in place through the creation of the arrow vertices. It is the PolyCollection.draw() method that is then handling the masking.
Now, having said that, and having traced through the code, I am not at all sure that everything in collections is still working correctly as described; I will have to look a bit more.
Note that the path module itself can handle masking now, so masked arrays sometimes get passed all the way through to it.
Quiver and windbarb could use the axes.delete_masked_points function right at the start, and this might be a good change to make, except that it is inconsistent with using the present set_UVC method to update arrows at constant locations.
Eric
Eric Firing wrote:
Ryan May wrote:
Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location. However, if nothing is drawn for a location X,Y where U,V are masked, this would seemingly lead to a problem where the locations and the things to be drawn get out of phase. Am I missing something here? Eric, did I miss some magic somewhere in quiver that handles this?
>>
There is no magic; we are not compressing or otherwise extracting the valid values, but are leaving the masking of U and V in place through the creation of the arrow vertices. It is the PolyCollection.draw() method that is then handling the masking.
Now, having said that, and having traced through the code, I am not at all sure that everything in collections is still working correctly as described; I will have to look a bit more.
Note that the path module itself can handle masking now, so masked arrays sometimes get passed all the way through to it.
So you mean the list/array of vertices can contain masked values?
Quiver and windbarb could use the axes.delete_masked_points function right at the start, and this might be a good change to make, except that it is inconsistent with using the present set_UVC method to update arrows at constant locations.
delete_masked_points() looks to me like a sane way to go. I'll update my masked handling to use this.
Ryan
···
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Ryan May wrote:
Eric Firing wrote:
Ryan May wrote:
Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location. However, if nothing is drawn for a location X,Y where U,V are masked, this would seemingly lead to a problem where the locations and the things to be drawn get out of phase. Am I missing something here? Eric, did I miss some magic somewhere in quiver that handles this?
>>
There is no magic; we are not compressing or otherwise extracting the valid values, but are leaving the masking of U and V in place through the creation of the arrow vertices. It is the PolyCollection.draw() method that is then handling the masking.
Now, having said that, and having traced through the code, I am not at all sure that everything in collections is still working correctly as described; I will have to look a bit more.
Note that the path module itself can handle masking now, so masked arrays sometimes get passed all the way through to it.
So you mean the list/array of vertices can contain masked values?
Yes. But again, trying to trace data values through various paths in the code, it can be hard to keep track of what assumptions are being made at each stage. I think the present intention is that masked values are passed through, but I also think I saw a recent code addition (maybe...) that does not do this. I need to check.
Quiver and windbarb could use the axes.delete_masked_points function right at the start, and this might be a good change to make, except that it is inconsistent with using the present set_UVC method to update arrows at constant locations.
delete_masked_points() looks to me like a sane way to go. I'll update my masked handling to use this.
It can be OK if your windbarb is intended as a one-shot instance--that is, the user makes another one if the data change--which is probably OK.
delete_masked_points looks to me like it has its own problems in the whole mpl-with-units context, including a recent change that I suspect breaks the handling of datetime inputs, but I don't think that any changes or cleanups will affect your use of it.
Eric
···
Ryan
Eric Firing wrote:
Quiver and windbarb could use the axes.delete_masked_points function right at the start, and this might be a good change to make, except that it is inconsistent with using the present set_UVC method to update arrows at constant locations.
delete_masked_points() looks to me like a sane way to go. I'll update my masked handling to use this.
It can be OK if your windbarb is intended as a one-shot instance--that is, the user makes another one if the data change--which is probably OK.
delete_masked_points looks to me like it has its own problems in the whole mpl-with-units context, including a recent change that I suspect breaks the handling of datetime inputs, but I don't think that any changes or cleanups will affect your use of it.
What I've tried to do is keep copies of the original data passed in, and when updating UV or offsets, use delete_masked_points to keep them lined up as appropriate. Does this sound reasonable? It doesn't look too bad, and still keeps an interface that allows updating.
Ryan
···
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Eric Firing wrote:
Ryan May wrote:
Eric Firing wrote:
Ryan May wrote:
Hi,
In looking over trying to support masked arrays in wind barbs, I noticed
a problem. I had originally copied the model of quiver, wherein masked
arrays are supported for U,V, and color, but not for X,Y. This stems
from the seemingly nonsensical nature of masking a location.
However, if nothing is drawn for a location X,Y where U,V are masked,
this would seemingly lead to a problem where the locations and the
things to be drawn get out of phase. Am I missing something here?
Eric, did I miss some magic somewhere in quiver that handles this?
>>
There is no magic; we are not compressing or otherwise extracting the
valid values, but are leaving the masking of U and V in place through
the creation of the arrow vertices. It is the PolyCollection.draw()
method that is then handling the masking.
Now, having said that, and having traced through the code, I am not
at all sure that everything in collections is still working correctly
as described; I will have to look a bit more.
Note that the path module itself can handle masking now, so masked
arrays sometimes get passed all the way through to it.
So you mean the list/array of vertices can contain masked values?
Yes. But again, trying to trace data values through various paths in
the code, it can be hard to keep track of what assumptions are being
made at each stage. I think the present intention is that masked values
are passed through, but I also think I saw a recent code addition
(maybe...) that does not do this. I need to check.
Quiver and windbarb could use the axes.delete_masked_points function
right at the start, and this might be a good change to make, except
that it is inconsistent with using the present set_UVC method to
update arrows at constant locations.
delete_masked_points() looks to me like a sane way to go. I'll update
my masked handling to use this.
It can be OK if your windbarb is intended as a one-shot instance--that
is, the user makes another one if the data change--which is probably OK.
delete_masked_points looks to me like it has its own problems in the
whole mpl-with-units context, including a recent change that I suspect
breaks the handling of datetime inputs, but I don't think that any
changes or cleanups will affect your use of it.
I suspect that your concern may be referring to my recent change. I
started some unit tests for delete_masked_points() (in
unit/axes_unit.py) when I made the modifications, so if you have use
cases, put 'em in there...
-Andrew