pyart
pyart copied to clipboard
ARM-DOE
Object oriented, hierarchical Radar, Sweep, and Ray objects
Create a Sweep and Ray class that point to data in the Radar object in such as way that when the data is changed the data in other objects are also changed. Have iteration over the Radar object return Sweep objects, and iteration over the Sweep object return Rays. The overall goal of this would be that users (and developers if they choose) to not need to deal with worrying about the sweep_start_ray_index and sweep_end_ray_index attributes nor need to slice data.
Fleshing out this idea a bit more
Radar (Volume) class
- Iterator (or Sequence?) Abstract Base Class
- Uses current attributes and methods.
- Iteration generated Sweep objects which point to data.
- get_sweep method to produce a Sweep, keyword to copy data and "detach" from Radar.
Sweep class.
- Iterator (or Sequence?) Abstract Base Class
- Attached to underlying Radar object from which attributes are extracted.
- Can be 'detached' from Radar object where by a copy of the data is made. May make use of a DetachedRadar class which contains a single sweep for consistency.
- Sweep level parameters provided as properties which are either read only, or when set update the correct parameter in the attached Radar class.
- Sweep data (fields, elevation, etc) provided as dictionary-like attributes with the 'data' key a view onto the appropriate ndarray from the Radar object. These attributes can be created using the MutableMapping Abstract Base class so that changes, addition, and deletions to the keys or values are reflected in the Radar object.
Ray class.
- Sized Abstract Base Class (gates)
- Similar to the Sweep class, ray level parameters are properties, others dictionaries. Updated reflected in the creating classes.
- Attached by default to the underlying Sweep class, can be detached.
RadarField class.
- Holds data from a single radar field along with sweep locations to facilitate slicing and iteration.
- Iterator Abstract Base class.
- field dictionary can be easily extracted.
- Created from method off Radar class.
- Can be used to "build up" a new field within a algorithm.
This all sounds mostly fine to me. My main concern is that backwards compatibility with the Radar object is preserved (sounds like this will be the case, thankfully). I don't want to break software that depends on Py-ART to ingest radar data.
Timothy Lang Research AST, Atmospheric Measurements NASA Marshall Space Flight Center (ZP11) Huntsville, AL 35812 (256) 961-7861 [email protected]
From: "Jonathan J. Helmus" <[email protected]mailto:[email protected]> Reply-To: ARM-DOE/pyart <[email protected]mailto:[email protected]> Date: Tuesday, February 17, 2015 at 3:02 PM To: ARM-DOE/pyart <[email protected]mailto:[email protected]> Subject: Re: [pyart] Object oriented, hierarchical Radar, Sweep, and Ray objects (#242)
Fleshing out this idea a bit more
Radar (Volume) class
- Iterator (or Sequence?) Abstract Base Class
- Uses current attributes and methods.
- Iteration generated Sweep objects which point to data.
- get_sweep method to produce a Sweep, keyword to copy data and "detach" from Radar.
Sweep class.
- Iterator (or Sequence?) Abstract Base Class
- Attached to underlying Radar object from which attributes are extracted.
- Can be 'detached' from Radar object where by a copy of the data is made. May make use of a DetachedRadar class which contains a single sweep for consistency.
- Sweep level parameters provided as properties which are either read only, or when set update the correct parameter in the attached Radar class.
- Sweep data (fields, elevation, etc) provided as dictionary-like attributes with the 'data' key a view onto the appropriate ndarray from the Radar object. These attributes can be created using the MutableMapping Abstract Base class so that changes, addition, and deletions to the keys or values are reflected in the Radar object.
Ray class.
- Sized Abstract Base Class (gates)
- Similar to the Sweep class, ray level parameters are properties, others dictionaries. Updated reflected in the creating classes.
- Attached by default to the underlying Sweep class, can be detached.
RadarField class.
- Holds data from a single radar field along with sweep locations to facilitate slicing and iteration.
- Iterator Abstract Base class.
- field dictionary can be easily extracted.
- Created from method off Radar class.
- Can be used to "build up" a new field within a algorithm.
— Reply to this email directly or view it on GitHubhttps://github.com/ARM-DOE/pyart/issues/242#issuecomment-74752416.
@tjlang My plan with this is to keep all the existing attributes and methods of the current Radar object intact and in the same format. A few methods will be added to accommodate the new features (get_sweep, next, ...).
The one change that I can think of that could possibly break existing code is that the base class of the Radar object will change from the current object to one of the Abstract Base Classes (ABC) from the collections module. Radar objects would still be instances of pyart.core.Radar and object but also be instances of some of the ABCs. If you are subclassing the Radar object you would either need to implement the abstract methods (iter, getitem, ...) or the existing methods will be used.
OK, all I've done is copy from the Radar attributes or use them directly, so sounds like this shouldn't affect my stuff.
Timothy Lang Research AST, Atmospheric Measurements NASA Marshall Space Flight Center (ZP11) Huntsville, AL 35812 (256) 961-7861 [email protected]
From: "Jonathan J. Helmus" <[email protected]mailto:[email protected]> Reply-To: ARM-DOE/pyart <[email protected]mailto:[email protected]> Date: Wednesday, February 18, 2015 at 9:34 AM To: ARM-DOE/pyart <[email protected]mailto:[email protected]> Cc: Timothy Lang <[email protected]mailto:[email protected]> Subject: Re: [pyart] Object oriented, hierarchical Radar, Sweep, and Ray objects (#242)
@tjlanghttps://github.com/tjlang My plan with this is to keep all the existing attributes and methods of the current Radar object intact and in the same format. A few methods will be added to accommodate the new features (get_sweep, next, ...).
The one change that I can think of that could possibly break existing code is that the base class of the Radar object will change from the current object to one of the Abstract Base Classes (ABC) from the collections modulehttps://docs.python.org/2/library/collections.html#collections-abstract-base-classes. Radar objects would still be instances of pyart.core.Radar and object but also be instances of some of the ABCs. If you are subclassing the Radar object you would either need to implement the abstract methods (iter, getitem, ...) or the existing methods will be used.
— Reply to this email directly or view it on GitHubhttps://github.com/ARM-DOE/pyart/issues/242#issuecomment-74884162.
