nguy
Potential Features
Below is a list of potential features (some ongoing) that may be desirable in ARTview:
- [x] Remove regions by hand editing - Awaiting feedback to see if this works well
- [x] Manual dealiasing - related to the above along with point selection - in beta
- [x] Combining dealiasing routines, both internal and Py-ART ( #97 )
- [x] Provide an easy "Link" function (e.g. GateFilter) for Plugins that may be more straightforward than the current approach (but likely not as powerful)?
- [x] Addition and multiplication functions for rescaling (@pfhein suggestion)
- [x] Removing that high value ring at the end/edge of the sweep. @jjhelmus is this capability in Py-ART?
- [ ] Add the simple script generation to existing plugins
- [ ] Cache some number of radar instances when opening to help speed navigation. Possibly build list of opened radar instances for a session.
- [ ] Experimental Vispy plot occurence based on @deeplycloudy code
- [x] Look into Qt5/OpenGL solutions for faster(?) rendering. May require waiting on Matplotlib adoption.
- [ ] Always updating/improving documentation Add an ImageDisplay with some of the following:
- [ ] Add the ability to add underlying map instance
- [x] Enable adding text to image
:+1: on the list.
Concerning removing the last few high value gates at the edges of sweeps, typically this can be done by indexing the field in question and setting this to masked. For example:
radar = pyart.io.read('some_file.nc')
# insure that the reflectivity field is a masked array
radar.fields['reflectivity']['data'] = np.ma.array(radar.fields['reflectivity']['data'])
# mask out the last gates in each sweep
radar.fields['reflectivity']['data'][:, -10:] = np.ma.masked
This can be combined with the sweep method on the Radar class if masked of specific sweeps is needed. To do this to all fields you would need to add a for loop over the fields.
Is this a common enough occurrence that it would warrant a function in Py-ART? I truly don't know so any feedback would be welcome.
I would say it occurs often enough to warrant the addition. @tjlang @swnesbitt @kirknorth @deeplycloudy would you agree with this (see the above commentary)?
The high value gate ring at the edge of sweeps are not that common but they are common enough that a function in Py-ART would be appreciated.
Yes, SPol for sure
On Oct 23, 2015, at 15:54, Nick [email protected] wrote:
I would say it occurs often enough to warrant the addition. @tjlang https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tjlang&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=oh_IyBh3p6AhkrNBZyzmmDfeXg2WKrzfthPLOoHreWM&m=lxMn1SNOcAy2hpJfw7GCqqyj13vkuYF_3uR58U1Y1mM&s=-U1XG80aKlAUO3h84T5wvBbH7UzmP2Fholf_Vf3yDQk&e= @swnesbitt https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_swnesbitt&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=oh_IyBh3p6AhkrNBZyzmmDfeXg2WKrzfthPLOoHreWM&m=lxMn1SNOcAy2hpJfw7GCqqyj13vkuYF_3uR58U1Y1mM&s=i1zBP-ENWdY0f6nWaJHujfxih733jIjkIxNYIqsmDEY&e= @kirknorth https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_kirknorth&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=oh_IyBh3p6AhkrNBZyzmmDfeXg2WKrzfthPLOoHreWM&m=lxMn1SNOcAy2hpJfw7GCqqyj13vkuYF_3uR58U1Y1mM&s=EjMxtt-8KaBCt_K2NvKIBFt0RiNAU0SMuEDsBMDukQk&e= @deeplycloudy https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_deeplycloudy&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=oh_IyBh3p6AhkrNBZyzmmDfeXg2WKrzfthPLOoHreWM&m=lxMn1SNOcAy2hpJfw7GCqqyj13vkuYF_3uR58U1Y1mM&s=pgpMpAzreJsRsvndaKVpHnB1_vxInUE6vUUKrIu7sZs&e= would you agree with this (see the above commentary)?
— Reply to this email directly or view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nguy_artview_issues_107-23issuecomment-2D150690491&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=oh_IyBh3p6AhkrNBZyzmmDfeXg2WKrzfthPLOoHreWM&m=lxMn1SNOcAy2hpJfw7GCqqyj13vkuYF_3uR58U1Y1mM&s=-o8qcmOFRBorJ6CWzP86mkbFgNLIuApSASP0QmgC2tI&e=.
Steve Nesbitt, Associate Professor Department of Atmospheric Sciences, University of Illinois at Urbana-Champaign 105 S. Gregory St. x-apple-data-detectors://1, MC223, Urbana, IL 61801-3070 USA voice : +1.217.244.3740 tel:+1.217.244.3740 fax : +1.217.244.1752 tel:+1.217.244.1752 internet : [email protected] mailto:[email protected] ; https://www.atmos.illinois.edu/people/snesbitt https://www.atmos.illinois.edu/people/snesbitt ; http://publish.illinois.edu/snesbitt http://publish.illinois.edu/snesbitt
Sounds like a yes, I created a Py-ART issue to track this. Thanks for the input everyone.
The hand masking/dealiasing routines should be a big help for us at TTU, where second trip and complex velocity patterns are common in our Ka severe storm data. We also have a long-range artifact that will be useful to remove.
Re: graphics improvements, is this relevant? http://gr-framework.org/tutorials/matplotlib.html
Let me know if I can do anything to help adapt the vispy example to something more useful.
I'm happy to hear that hand masking would be useful for you. Could you better describe how you would like it to work? The programming part can be done, but I don't really know how the user iteration should work, may be you can help in that. Feel free to make a smaller or deeper/detailed plan of how it should look like, then I can think how to implement it.
I still didn't tested vispy (may be nguy did, I'm not sure). We are working with PyQt4 and pretend to stick with it, so an example should be ideally packed inside a Qwidget with some control parameters that can be modified. If it were a simple animation we could consider launching an independent window just to show it, but still implement the control tools in Qt. In any case, an example packed inside a class would be much useful than a script, in that way we can initialise it, call one or the other function and close it in the end.
Thanks for the notes @deeplycloudy , the gr framework looks promising. We'll look into that.
As for the vispy example, I have not implemented it yet, and have been thinking how best to do so to set it up for possible future use (as @gamaanderson mentioned). Hopefully coming in the near future.
Both hand masking and velocity unfolding are tedious and repetitive operations, so reducing the number of clicks is key for pleasant use. Right now you have to click a button to apply an action after each polygon, which adds some friction. Something like this is more appealing to me:
- Turn on lasso tool
- Brings up lasso config widget: Drop down menu to configure actions that will result from lasso operation: masking, manual velocity unfold, display data, etc.). Could also set other necessary parameters - this interface changes depending on the mode.
- Draw any number of polygons; each automatically has the operations in the widget applied.
- Added conveniences: Should be easy to cancel in the middle of a polygon (escape key?). An undo button in the widget could roll back last one or more lasso operations.
This works sort of like Photoshop: once you choose the paintbrush tool, you just keep using it until you decide to switch to something else.
As a further extension to the analysis too, my group also prototyped something in a notebook that had a lasso logging feature. This was with reproducibility in mind, so that the chain from raw data through final cleaned-up analysis was traceable and could be re-automated. We dumped JSON dictionaries of the coordinates and other relevant metadata (including the time of analysis) to a JSON file.
On Tue, Oct 27, 2015 at 2:32 PM, Nick [email protected] wrote:
Thanks for the notes @deeplycloudy https://github.com/deeplycloudy , the gr framework looks promising. We'll look into that.
As for the vispy example, I have not implemented it yet, and have been thinking how best to do so to set it up for possible future use (as @gamaanderson https://github.com/gamaanderson mentioned). Hopefully coming in the near future.
— Reply to this email directly or view it on GitHub https://github.com/nguy/artview/issues/107#issuecomment-151618705.
Thank you for the input @deeplycloudy. You described 1 widget (component) that control lasso and the operation. Do you think it would be bad if those were 2 widget, one that only control lasso and one only the operation? those would be initially 2 tabs in the menu, but in the future we could a better way to display them. The non-intuitive part is that even being two separated widget they are linked, so they respond to each other.
Now I will focus in getting the new modes functionality working, that is fundamental to get your first point, just one click to open the edition. After that I will implement undo to select region(lasso). Undoing is always a little trick.
I suppose it depends on how often the details of the lasso need to be configured - that could be a separate panel that pops up or expands from the bottom of the high-level lasso control. For instance, one might only rarely need to change the nyquist for manual unfolding; normally it comes from the radar metadata.
As with minimizing the number of clicks, I think it's also helpful to only present as much interface as necessary for ordinary use, with a single obvious place to click for further configuration. That gives the user confidence that she's addressed everything that is important without having to scan her eyes across an elaborate interface.
On Wed, Oct 28, 2015 at 4:46 AM, Anderson [email protected] wrote:
Thank you for the input @deeplycloudy https://github.com/deeplycloudy. You described 1 widget (component) that control lasso and the operation. Do you think it would be bad if those were 2 widget, one that only control lasso and one only the operation? those would be initially 2 tabs in the menu, but in the future we could a better way to display them. The non-intuitive part is that even being two separated widget they are linked, so they respond to each other.
Now I will focus in getting the new modes functionality working, that is fundamental to get your first point, just one click to open the edition. After that I will implement undo to select region(lasso). Undoing is always a little trick.
— Reply to this email directly or view it on GitHub https://github.com/nguy/artview/issues/107#issuecomment-151782533.
Anything new about the lasso tool or region selection? I would like to use it on selecting a bunch of point clusters but I couldn't find any code/examples from Vispy to start. Is there any resources for me to try even the 2D lasso first? Many thanks!
we are working on that, but a easy way to show what we already have is this videos: SelectRegion: https://www.youtube.com/watch?v=Hcz2YtpXBdM and also this ones may be interesting ExtractPoints: https://www.youtube.com/watch?v=iWBFSN6Thbw ManualUnfold: https://www.youtube.com/watch?v=B_BmYV7GdCA ManualFilter: https://www.youtube.com/watch?v=VXUZBiA3HfU
It looks great! Is this an open source tool that I would like to have a try. Do you use the 'point in polygon' solution to identify the selected region within or outside the lasso? Or you have better ideas in this tool?
yes, this is a open source project.
we define the lasso as a Matplotlib path object and then for every data point we test if it is inside with the path.contains_point method
except from the "high value ring" and "vispy" this list is expected to be implemented in version 1.3.
The first one is a pyart issue, if it is implemented there we will implement it here.
The second one I still don't know where it would be usefull / how to implement
Ah, yeah, still working on this. However, I think this is going to require the RadarCollection to become more formalized. I thought that this could be a good first test case for the RadarCollection.
I will add to the list, it shouldn't be difficult the implement, now that we have a reason. do we already have something in this sense? Do you need the RadarCollection to be a shared variable?
There is nothing thus far. My thinking lately was that this would best be implemented in Py-ART because it allows for some operability that is not present for processing as well. Then it could be inherited in ARTview as a probably a shared variable. How to relate to Vradar instance reliably I've yet to work out.
@nguy please review the items on the top of this discussion for what was already addressed and what should still be done.
A few items off the list, a couple outstanding. I'll add any of these that need to be complete to the other list you created. But I'm not sure if any of this is super important. The radarcollection was partially implemented and I need to get a hold on that code.