Fix handling wkt strings and add pyproj.CRS support

[ahuang11]

Closes #1137

The issue was that rioxarray gets loaded after running the second cell, which triggered the first if clause, but we didn't handle WKT strings properly; this PR fixes that.

    def _process_crs(self, data, crs):
        """Given crs as proj4 string, data.attr, or cartopy.crs return cartopy.crs
        """
        if hasattr(data, 'rio') and data.rio.crs is not None:
            # if data is a rioxarray
            _crs = data.rio.crs.to_wkt()
            print("RIO")
        else:
            # get the proj string: either the value of data.attrs[crs] or crs itself
            _crs = getattr(data, 'attrs', {}).get(crs or 'crs', crs)
            print("NOT RIO")

Supersedes contaminated #1138

Note the notebook cell execution number

[hoxbro]

Thank you for finding the cause of the confusing behavior. Your changes stops the error, but I still find the behavior not to be ideal, e.g.,

import cartopy.crs as ccrs
import rioxarray
import xarray as xr
from hvplot.util import process_crs

crs = ccrs.RotatedPole(pole_longitude=177.5, pole_latitude=37.5)
ds = xr.Dataset(attrs={"crs": crs})

a1 = process_crs(ds.rio.crs.to_proj4())
a2 = process_crs(ds.attrs["crs"])

type(a1), type(a2)

Outputs: (cartopy.crs.PlateCarree, cartopy.crs.RotatedPole)

After looking into it more, it seems these lines are the problem:

hvplot/hvplot/util.py

Lines 130 to 131 in c049c7b

	if proj_is_latlong(proj):
	return ccrs.PlateCarree()

Looking at this: ds.rio.crs.to_wkt() == crs.to_wkt() will return True, and if I comment out those lines I get type(a1), type(a2) to be (cartopy.crs.RotatedPole, cartopy.crs.RotatedPole)

[ahuang11]

Good catch! I believe if proj_is_latlong is making a wrong assumption that only PlateCarree is lat lon; rotated pole is also in latlong.

    A rotated latitude/longitude projected coordinate system
    with cylindrical topology and projected distance.

Also, I think to_wkt is preferred over to_proj4
https://proj.org/en/9.3/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems

[hoxbro]

It looks good to me.

One small thing is we have identical functions in GeoViews. Can you update them and test that we don't break anything in that CI, too, with these changes?

I think it is out-of-scope for this PR, but we are getting some warnings related to these tests. (Already there before this PR)

hvplot/tests/testgeo.py::TestProjections::test_plot_with_crs_as_nonexistent_attr_str
hvplot/tests/testutil.py::TestGeoUtil::test_proj_to_cartopy
hvplot/tests/testutil.py::test_check_crs
hvplot/tests/testutil.py::test_check_crs
hvplot/tests/testutil.py::test_process_crs[+init=epsg:26911]
hvplot/tests/testutil.py::test_process_crs_pyproj_proj
hvplot/tests/testutil.py::test_process_crs_platecarree[+init=epsg:4326]
hvplot/tests/testutil.py::test_process_crs_mercator[+init=epsg:3857]
  /Users/runner/miniconda3/envs/test-environment/lib/python3.11/site-packages/pyproj/crs/crs.py:141: FutureWarning: '+init=<authority>:<code>' syntax is deprecated. '<authority>:<code>' is the preferred initialization method. When making the change, be mindful of axis order changes: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6
    in_crs_string = _prepare_from_proj_string(in_crs_string)

[hoxbro]

Could be nice to still have this comment.