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 > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
