Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial discussion on Pyresample 2.0 #181

Open
djhoese opened this issue Apr 2, 2019 · 0 comments
Open

Initial discussion on Pyresample 2.0 #181

djhoese opened this issue Apr 2, 2019 · 0 comments
Milestone

Comments

@djhoese
Copy link
Member

djhoese commented Apr 2, 2019

This issue is meant to present ideas and things to think about before the Spring 2019 PCW. This will start out as a sort of braindump, but I'll try to structure it a little. Things to consider, possible breaking changes, etc:

1. Main features to include

  1. Geometry Definitions (areas, swaths, etc)
  2. Resampling functions (nearest neighbor, bilinear, EWA, etc)

2. Interfaces to consider

  1. Limit core geometry definitions to AreaDefinition (or rename to GridDefinition?) and SwathDefinition. Area's are understood to be projected and uniformly spaced. Swaths are lon/lat are we assume they are not evenly spaced.
  2. Allow swaths to hold additional metadata like limb/edge resolution, nadir resolution, bbox (g-ring?), etc. Not sure it matters, but should there be an optional keyword argument for what "type" of lat/lon points these are (geodetic versus geocentric, etc)?
  3. Altitude/elevation coordinates? Unless we start supporting proper 3D interpolation (assuming that level N can be affected by values on levels N-1 and N+1) I don't think we need to handle this but I'm bringing it up anyway.
  4. Xarray accessor to allow for my_data_arr.pyresample.resample(area_def). See geoxarray project for possible overlap.
  5. Resampler objects to allow for resampler = NearestResampler(source_area, target_area); resampler(my_data).
  6. Provide a simplified resampling interface for one-shot resampling where you provide your data, source area, target_area, and kwargs. The function call would create the appropriate resampler object and handle all of the other stuff. This is the non-cache interface.
  7. Require pyproj 2.0+ and use pyproj CRS objects internally. Allow for WKT, PROJ strings, etc.

3. Questions

  1. Should SwathDefinitions allow for x/y coordinates that are non-uniform but are on a projected space?
  2. What does an AreaDefinition need to be properly/fully defined. Does it only accept a CRS object from pyproj? Does it accept PROJ.4 strings, WKT, and CRS objects? We considered dropping things like "proj_id" but in WKT something like this may be necessary or useful to fully describe the CRS.

Comment any additional ideas or concerns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant