+proj=omerc lacks a spherical implementation (issue with lat_1=0 using the ellipsoidal formulation)

[mwtoews]

PROJ 9.5.1 has two Hotine oblique Mercator projections:

• ESRI:53025 Sphere_Hotine
• ESRI:54025 World_Hotine

While these projections can be converted to [deprecated] PROJ.4 strings, they error when round-tripped:

$ projinfo -o PROJ "$(projinfo -o PROJ ESRI:53025 | tail -n +2)"
input string: parsing of '+proj=omerc +lat_0=40 +lat_1=0 +lon_1=0 +lat_2=60 +lon_2=60 +k=1 +x_0=0 +y_0=0 +R=6371000 +units=m +no_defs +type=crs' failed: Error 1027 (Invalid value for an argument): omerc: Invalid value for lat_1: lat_1 should be different from 0
$ projinfo -o PROJ "$(projinfo -o PROJ ESRI:54025 | tail -n +2)"
input string: parsing of '+proj=omerc +lat_0=40 +lat_1=0 +lon_1=0 +lat_2=60 +lon_2=60 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +type=crs' failed: Error 1027 (Invalid value for an argument): omerc: Invalid value for lat_1: lat_1 should be different from 0

The main error (from omerc.cpp) is:

omerc: Invalid value for lat_1: lat_1 should be different from 0

The omerc docs don't specify this restriction for lat_1.

But also, this round-tripping exercise somehow "works" for WKT2:2019:

$ projinfo -o WKT2:2019 "$(projinfo -o WKT2:2019 ESRI:53025 | tail -n +2)" | grep -e "Lat\|Lon"
        PARAMETER["Latitude of projection centre",40,
        PARAMETER["Latitude of 1st point",0,
        PARAMETER["Longitude of 1st point",0,
        PARAMETER["Latitude of 2nd point",60,
        PARAMETER["Longitude of 2nd point",60,

See that Latitude of 1st point is zero? If lat_1 should be different form 0, then why doesn't this raise an exception?

[rouault]

I've investigated this a bit and the issue stems from the fact that we use the ellipsoidal formulation of oblique mercator even when on a sphere , like here. Most of the time this must be fine, but the ellipsoidal formulation doesn't work for phi1 = 0. This is mentionned in the middle of page 71 of https://pubs.usgs.gov/pp/1395/report.pdf "phi1 cannot be zero". I've experimented a bit with values close to 0, but this generates quite unstable values due to a division by almost 0. I believe the fix here would be to implement the spherical omerc