Very much work-in-progress POC of using spherely in geopandas as another geometry engine.

While there are many things to do or improve (implementing some basic things like astype and to_crs, but also just making the NotImplementedErrors more informative with a clear message, or changing them to a TypeError if we think it will never be implemented for spherical geometries; move common parts to a base class, etc), the current PR already does allow some basic things. Seehttps://gist.github.com/jorisvandenbossche/2e8ecee0d109b77e03c45fca7bac385a for an overview.

The approach currently taken here is: have a separate ExtensionArray class (currently calledGeographyArray), while keeping the singleGeometryDtype class but parametrizing it with anengine parameter (currently with values "planar" (default) and "spherical"; one question with this approach is if we want to describe the type of the engine (planar vs spherical) vs the package being used (shapely vs spherely). I like the type more, but at some point we might also have more than one engine for planar geometries).
This means you can do something like to convert an existing geometry column to use the spherical support:

geoseries.astype(geopandas.GeometryDtype(engine="spherical")# or the shorter string alias if we want to enable thisgeoseries.astype("geometry[spherical]")

Of course, we could also add a dedicated method for this conversion (as_spherical orto_spherical or something like that) if that might be easier to use vs the generic type casting.

While I took the approach of the parametrized dtype here (instead of different subclasses), I think I am now rather leaning towards going for subclasses .. (moving to that model is a relatively small code change)

xref#2769