+tmerc projections fail when the ellipsoid is spherical

[jaredkhan]

PROJ reverts to the evenden_snyder algorithm in this case, but Proj4js throws an error stating 'incorrect elliptical usage'.

See here for the relevant line in PROJ https://github.com/OSGeo/PROJ/blob/master/src/projections/tmerc.cpp#L597 See here for the relevant line in Proj4js https://github.com/proj4js/proj4js/blob/master/lib/projections/etmerc.js#L14

For example:

> require("proj4")("+proj=tmerc +a=6378137 +b=6378137 +lon_0=11.598056919260632 +x_0=1.0621731827420435e-09 +y_0=-5375403.8751633102 +k=1.0 +units=m +wktext +no_defs")
Uncaught:
Error: Incorrect elliptical usage. Try using the +approx option in the proj string, or PROJECTION["Fast_Transverse_Mercator"] in the WKT.
    at Projection.init$3 [as init] (/Users/jared/five/dev/scenario/frontend/node_modules/proj4/dist/proj4-src.js:3439:15)
    at new Projection (/Users/jared/five/dev/scenario/frontend/node_modules/proj4/dist/proj4-src.js:1649:12)
    at Projection (/Users/jared/five/dev/scenario/frontend/node_modules/proj4/dist/proj4-src.js:1595:16)
    at checkProj (/Users/jared/five/dev/scenario/frontend/node_modules/proj4/dist/proj4-src.js:2308:14)
    at proj4$1 (/Users/jared/five/dev/scenario/frontend/node_modules/proj4/dist/proj4-src.js:2312:18)

[ahocevar]

proj4.js supports this fallback too, but like the error message says, you have to add +approx to the proj string to make use of it. See #373.

[jaredkhan]

I'd like to understand:

• Why the etmerc algorithm isn't used for spheres. From reading the formula on the PROJ website (https://proj.org/operations/projections/tmerc.html#mathematical-definition) it seems it should work just fine for spheres since n would be zero.
• Why the two libraries differ in their opinion of whether to automatically fallback to tmerc for spheres and what the trade offs are. Is the algorithm imprecise for spheres?

Perhaps you could help point me in the right direction?

I also wonder whether the error message could be made more explicit or perhaps add some references. When I saw it, I ended up having to read quite a bit of the source to understand that it was the spherical nature of the projection that was causing this (I didn't know what this.es was so had to find that definition), and I'm still a bit unclear whether adding +approx is the right thing to do in my case.

[ahocevar]

Well, you're right that we could improve a bit here. The +approx param is used in PROJ too, see https://proj.org/operations/projections/tmerc.html#cmdoption-arg-approx. The implications are that it is less accurate.

You might be right that we're too strict wenn throwing that error. If you'd be willing to create a pull request that makes it more lenient (e.g. allow 0, and only fail when es < 0 or isNaN(es), along with a test case that verifies etmerc working correctly in that case, it would be appreciated.

[jaredkhan]

Would you happen to have references relating to the two algorithms that you could point me at? Would like to understand the different accuracies a bit better before making such a PR

[ahocevar]

@jaredkhan I don't have any references but the source code and the commit history.