You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It is common in some user environments or GUI applications to have users open a series of files and ask for the software to just "go". Right now this isn't possible because a single Scene object expects all of the files provided to it to be for one particular time/orbit.
Describe the solution you'd like
I suggest we add a classmethod to the MultiScene (which is not super well-tested/used) that would take a reader name and a series of files and automatically create the individual Scene's needed to load those files. This could add to the functionality provided in readers/__init__.py that uses the file patterns for readers to sort files in to groups based on start_time in the file. The classmethod would probably need to have keyword arguments for additionally grouping arguments including the resolution of the start_time.
I'm not sure how the MultiScene currently feels about SwathDefinitions and having sub-Scenes that are each different SwathDefinitions or different AreaDefinitions.
Describe any changes to existing user workflow
Initially, no. This would be a single new feature. In the future this may affect the individual Scene class or other utility functions we have like 'find_files_and_readers', but these conflicts aren't needed initially...I think.
Additional python or other dependencies
No additional dependencies.
Describe any changes required to the build process
No changes to the build process.
Describe alternatives you've considered
I originally thought this would just be a separate utility function and while the core functionality will probably be in a utility function, the main interface advertised to users should probably be in the MultiScene since that it typically how these types of things would want to be used. Plus you can always get an iterator of Scenes from the MultiScene.
Additional context
While typing this up I also thought about the possibility that this could be helped by the idea of making the Scene an XArray a xarray.Dataset where the dimensions would pretty much be (time, y, x). Just a thought.
Lastly, it would be a really cool example to give a big list of files (and a reader name) to the MultiScene classmethod, run a multiscene method to save the scenes as a set of animations, and then show the animation. This could all probably happen in a jupyter notebook (.gif).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
It is common in some user environments or GUI applications to have users open a series of files and ask for the software to just "go". Right now this isn't possible because a single Scene object expects all of the files provided to it to be for one particular time/orbit.
Describe the solution you'd like
I suggest we add a classmethod to the MultiScene (which is not super well-tested/used) that would take a reader name and a series of files and automatically create the individual Scene's needed to load those files. This could add to the functionality provided in
readers/__init__.py
that uses the file patterns for readers to sort files in to groups based on start_time in the file. The classmethod would probably need to have keyword arguments for additionally grouping arguments including the resolution of the start_time.I'm not sure how the MultiScene currently feels about SwathDefinitions and having sub-Scenes that are each different SwathDefinitions or different AreaDefinitions.
Describe any changes to existing user workflow
Initially, no. This would be a single new feature. In the future this may affect the individual Scene class or other utility functions we have like 'find_files_and_readers', but these conflicts aren't needed initially...I think.
Additional python or other dependencies
No additional dependencies.
Describe any changes required to the build process
No changes to the build process.
Describe alternatives you've considered
I originally thought this would just be a separate utility function and while the core functionality will probably be in a utility function, the main interface advertised to users should probably be in the MultiScene since that it typically how these types of things would want to be used. Plus you can always get an iterator of Scenes from the MultiScene.
Additional context
While typing this up I also thought about the possibility that this could be helped by the idea of making the Scene an XArray a
xarray.Dataset
where the dimensions would pretty much be(time, y, x)
. Just a thought.Lastly, it would be a really cool example to give a big list of files (and a reader name) to the MultiScene classmethod, run a multiscene method to save the scenes as a set of animations, and then show the animation. This could all probably happen in a jupyter notebook (.gif).
The text was updated successfully, but these errors were encountered: