Refactoring the Scene with accessors

[mraspaud]

Feature Request

Is your feature request related to a problem? Please describe. The Scene object has at the moment too many responsibilities and is very bloated. At the same time, we are considering using a xarray Datatree object as a replacement for the Scene in the future, but we probably will not be able to subclass it to add custom methods.

Describe the solution you'd like To address these problems, one solution would be to add accessors (like xarray.DataArray accessors) to the Scene. This will make it easier to switch to datatree in the future, but also, if we create multiple accessors, allow to separate concerns.

Describe any changes to existing user workflow This will change the way we use the Scene methods for sure. So definitely backwards incompatibility is to be expected when we deprecate the regular methods.

Additional context Hopefully this is the beginning of a discussion on the topic of making the Scene easier to maintain.

[djhoese]

I have to admit I've never liked the accessor pattern that xarray uses. For simple use cases it makes things magically "simpler" like geoxarray's .geo.crs for accessing standard CRS information. But for most other use cases that actually act on and produce a new xarray object it has always felt like this type of workflow should be using separate functions or classes and not necessarily be tied to xarray objects at all.

I agree that the Scene is too bloated and we would need to be careful about doing the same in an accessor interface. While we could make multiple accessors this is not the standard approach from what I can tell from other libraries. Typically it is a single accessor for a library. Additionally the more accessors we create the more likely we are to conflict with other libraries who have made their own accessors.