Transformation incorrect between rotated pole and lat-lon since Proj 9.8

[aulemahal]

Hi ! This is a issue that happens when I update to PROJ 9.8 in my conda environment. The transformation between a "rotated pole" (ob_tran) projection and the usual latitude/longitude gives different results. I think these new results are incorrect.

Example

echo "263  47.5 0" | cs2cs +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +to_meter=111319.490793274 +no_defs +type=crs +to +proj=ob_tran +o_proj=latlon +o_lon_p=0 +o_lat_p=42.5 +lon_0=263 +ellps=WGS84 +no_defs +type=crs
# Before, with PROJ 9.7.1
0dE	0dN 0.000
# After, with PROJ 9.8.0
0dE	0d13'24.328"N 0.000

Sorry, I am not used to cs2cs in the command line, but to higer-level python script. Usually cartopy which uses proj through pyproj. I copy-pasted the output of CRS.to_proj4() from pyproj to get the CRS definitions in the command line above.

Problem description

The destination CRS is a "rotated pole" projection, i.e. similar to normal lat/lon, but with the pole displaced. The point 263E 47.5N (in real lat/lon) is supposed to correspond to the point 0E 0N in the rotated projection. This can be computed by hand from the definitions.

But more than that, I detected the problem because all my transformations between these two CRS where giving different results. I am pretty confident that the output of PROJ 9.7.1 was correct, and the new one isn't.

Environment Information

• PROJ version (proj) : Rel. 9.8.0, March 2nd, 2026
• Operation System Information : Linux x86_64

Installation method

• conda from channel conda-forge : proj 9.8.0 he0df7b0_0

The example above tested in two different conda environment that only differ by the following:

1c1
< List of packages in environment: "newer-proj"
---
> List of packages in environment: "previous-proj"
193c193
<   libgdal-core                      3.12.2           h4f65170_3               conda-forge
---
>   libgdal-core                      3.12.2           he63569f_2               conda-forge
231c231
<   libspatialite                     5.1.0            gpl_hab3fe16_120         conda-forge
---
>   libspatialite                     5.1.0            gpl_h2abfd87_119         conda-forge
315c315
<   proj                              9.8.0            he0df7b0_0               conda-forge
---
>   proj                              9.7.1            he0df7b0_3               conda-forge
336c336
<   pyproj                            3.7.2            py314h7ce3bca_4          conda-forge
---
>   pyproj                            3.7.2            py314h68799e9_3          conda-forge

[rouault]

I am pretty confident that the output of PROJ 9.7.1 was correct, and the new one isn't.

In PROJ 9.8.0, the eqc projection has been updated to implement the ellipsoidal formulation (triggered here because of +ellps=WGS84) in addition to the spherical formulation
However +proj=ob_tran works with a spherical model, hence the discrepency you get in your results.

you can get the same results as previously by using +R=6378137 in the +proj=eqc part

From my perspective, not a bug, but works as intended

[aulemahal]

Ah! Thanks a lot.

This means that PROJ 9.7.1 was giving a spherical formulation before? I'll go to cartopy to see if they intended the PlateCarree projection to be ellipsoidal instead of spherical, as it was up to now.

[rouault]

This means that PROJ 9.7.1 was giving a spherical formulation before?

yes

[aulemahal]

Related to why I had an issue, but maybe not an actual issue :

The proj4 string I used to define my rotated pole projection is : proj=ob_tran +o_proj=latlon +o_lon_p=0 +o_lat_p=42.5 +lon_0=263 +ellps=WGS84 +no_defs +type=crs

Where +ellps=WGS84 is given, but the result still is spherical. I can't remove this argument from the string, otherwise PROJ fails. I can pass +ellps=sphere.

It seems to me then that the argument is needed, but has no effect, which adds to the confusion here, no ? Making the creation of a +proj=ob_tran fail when a non-spherical ellps is passed could make this behaviour clearer, is that someting implementable ?

[rouault]

It seems to me then that the argument is needed, but has no effect

yes

Making the creation of a +proj=ob_tran fail when a non-spherical ellps is passed could make this behaviour clearer

that would have backward incompatibility implications...

[aulemahal]

Indeed, I can't judge much of what is feasible, needed or not.

From my point of view (again not an expert) the fact that +ellps had no impact for +proj=eqc before but has one now is a "backward compatilibty implication". But as I said above, I think I'll raise all this downstream, in cartopy where most of the concerned proj4 parameters of my issue are defined.

Thanks!