Fixing with Proj 9.8

[dopplershift]

As noted in #2634, Proj 9.8 added support for properly handling ellipsoids to the equidistant cylindrical projection (OSGeo/PROJ#4656). This breaks assumptions we make in PlateCarree, where we try to essentially make it treat lat/lon as unchanged Cartesian coordinates; this is accomplished by undoing the scaling by the Earth's radius (and converting radians back to degrees).

This PR attempts to update PlateCarree to correctly function with Proj 9.8 by avoiding scaling hacks altogether and just use the latlong projection to accomplish what we intend with PlateCarree. In order to handle the offsets that were previously supported, we use the pm (Prime Meridian) PROJ parameter. (Using lon_0 in this case created problems with finding transformations in some cases because this ends up encoded as a remark.) pm causes some challenges in that it ends up attached to the datum, which violates some assumptions we were previously making.

This breaks some tests, but nothing that seems to be critical. One oddity is that some clipping around the edges of plots seem to be working less well for reasons I haven't identified.

[greglucas]

I think this makes sense for Natural Earth at a minimum
https://www.naturalearthdata.com/features/

Projection: Natural Earth’s WGS84 projection is specified in shapefile’s PRJ file. It can also be described as a PROJ4 code [EPSG:4326](http://spatialreference.org/ref/epsg/wgs-84/) string “+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs”.

The thing that I've always wondered though is if we shouldn't just make a class LatLong() instead (or in addition to as an alternative spelling)?

Regarding your question about clipping being worse, do you know if this takes the geodesic interpolator path because pyproj thinks even the native "projection" definition is geodetic?

[dopplershift]

I agree we should also have a LatLong class to do this. If we do so, I would consider not having that class support lon_0, because that offset has created a lot of headaches trying to move from our old implementation to just using latlon. (See the dropping pm hackery I had to do here.) I would want to see what other ways we can use to implement the shifting people use lon_0 for with PlateCarree. In that event I would (probably with a quiet warning) deprecate PlateCarree and add a separate EquidistantCylindrical class. IMO, we've just been conflating too many things in PlateCarree for that to be salvageable API-wise.

No, it doesn't trigger Cartopy's geodesic interpolation (SphericalInterpolator), because while PROJ returns True for is_geographic, being a subclass of Projection means is_geodetic() for PlateCarree will always return False.

Test failure notes:

• I need to dig into the tests failures more, especially for pcolormesh. Since we allow a sizable tolerance, I'm not sure what changes represent only a change against the (long-term) baseline versus what this PR changes against main.
• A lot of the changes to the gridlining/labelling look like improvements.
• test_gridliner_title_adjust shows some shifts of gridlines relative to the coastlines for the Mercator panel. I want to understand what's causing that better.
• Not sure why test_cursor_values is getting different values

[QuLogic]

• A lot of the changes to the gridlining/labelling look like improvements.

• test_gridliner_title_adjust shows some shifts of gridlines relative to the coastlines for the Mercator panel. I want to understand what's causing that better.

See also my comments on #2685; grid labelling seems a bit fragile in some ways, but that's a bigger problem to fix.

[QuLogic]

Not sure why test_cursor_values is getting different values

This test is a bit weird; it uses default PlateCarree and tries to format [-181.5, 50]. That x coordinate is outside of the normal boundaries of longitudes. So for latlong over eqc, it seems to wrap that to the more "correct" longitude of +178.5 when we transform it from geodetic.

[QuLogic]

I need to dig into the tests failures more, especially for pcolormesh. Since we allow a sizable tolerance, I'm not sure what changes represent only a change against the (long-term) baseline versus what this PR changes against main.

A lot of these seem to have been increased to allow newer and newer PROJ. Since we have moved to pyproj and dropped support for several older versions, it may be time to refresh these and reset the tolerances.

[QuLogic]

I need to dig into the tests failures more, especially for pcolormesh. Since we allow a sizable tolerance, I'm not sure what changes represent only a change against the (long-term) baseline versus what this PR changes against main.

A lot of these seem to have been increased to allow newer and newer PROJ. Since we have moved to pyproj and dropped support for several older versions, it may be time to refresh these and reset the tolerances.

The easiest way to see what has happened with the pcolormesh tests is from test_grid_labels_inline[RotatedPole]:

which has a diff of:

Namely, the gridline along the 180° line is halved (which is more in line with the 0° line.) I guess there is either some trimming or similar wrap-around effect as with test_cursor_values.

The same thing happens with the pcolormesh tests:

The lines on the left/top of the Axes are known changes from before and the reason for the existing higher tolerances (and I think they are possibly wrong as they are on the outside of the Axes boundary line, but that's something to figure out elsewhere.) The line on the right side is at 0° but the underlying map has central_longitude=180 so it's the same antimeridian. I do think that the result is better now as the squares appear to be of closer width (12px vs 13px for before).

[QuLogic]

A lot of the changes to the gridlining/labelling look like improvements.

So in the case of test_grid_labels_inline[Mercator], test_grid_labels_inline[Miller], test_grid_labels_inline[AzimuthalEquidistant], and test_grid_labels_inline[AlbersEqualArea], as well as the Mercator subplots of test_grid_labels, test_grid_labels_tight, and test_gridliner_title_adjust, we've gained a 180° label. Looking at the gridliner code, it appears that all longitude lines after CRS transform are slightly different and the 180° line now intersects the map boundary, so we get a new potential label site, which seems to fit without overlap, and gets added to the plot. My personal opinion is also that these are improvements.

test_gridliner_title_adjust shows some shifts of gridlines relative to the coastlines for the Mercator panel. I want to understand what's causing that better.

This may be because tight layout changed the positioning slightly due to the top-right map gaining its 180° labels. The Mercator subplot in the new image is 1 pixel taller than before. I feel like if you try to overlay the other maps, you see a similar issue because they're all a pixel or two different in shape.