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 ------------------------------------------------------------------------- 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
