From @ghiggi:

Current area_extent_<> and <>_bbox follow the (xmin, ymin, xmax, ymax) convention. More precisely the area_extent is defined as (lower_left_x, lower_left_y, upper_right_x, upper_right_y).

• This is also the convention adopted by rasterio/rioxarray/shapely object bounds method.
  --> Maybe we could add a bounds property?
• When retrieving the area_extent_ll (in lat/lon) the lower-left and upper-right corners do not necessarily currently define the outermost lat/lon coordinates of the area. Maybe this method should be changed! And maybe we could also add a bounds_ll method.
• Additionally, the area_extent convention differs from the i.e. matplotlib cartopy and matplotlib extent which is defined as (xmin, xmax, ymin, ymax)
  --> Maybe we could add a <mpl/cartopy>_area_extent_<''/ll> property?

From @ghiggi:

For GEO AreaDef, all the above _ll methods currently return np.nan/np.inf values. Maybe ad-hoc processing using get_geostationary_bounding_box_in_lonlats could be implemented for area_extent_ll, but the corners would remain undefined ! Maybe would be worth raising an error to avoid downstream bugs !

Deprecate/remove nprocs and likely dtype. Both of these should be specified per-call to functions that return new arrays and should default to whatever the internal data structures work. Likely defaulting to 64-bit floats.

An additional note to area_extent in lon/lat @djhoese:

For SwathDefinition or AreaDefinition crossing the antimeridian (like for GOES-17 Full Disc), the definition of area_extent_ll in lon_lat is ambiguous.
Currently, SwathDefinition does not have an extent/area_extent attribute.
Currently, for AreaDefinition the area_extent_ll xmin and xmax are defined by projecting to lat/lon the area_extent[0], area_extent[2]. For antimeridian crossing AreaDefinition, it means that the area_extent_ll has xmin>xmax

In the future.spherical, I started implementing an SExtent object which can be defined by a list of area_extent. The SExtent object enables then to check for i.e. intersection with other SExtent objects.
In the case of antimeridian crossing Swath/Area, we can provide two extents: one going to xmax=180 and another one starting from xmin=-180. As an example for GOES-17 FD, the SExtent would be defined by list_extent = [[150, 180, -70, 70], [-180,-150, -70, 70]]

Maybe an option could be to return the SExtent object from area_extent_ll.

What about no BaseDefinition class? Besides isinstance checks which should probably use duck typing instead, do we need it? I think we could just design things by "composition". That is, build up the functionality in separate and specific helper classes.