Changing Transverse Mercator Algorithm for +proj=tmerc

[micahcochran]

The issue to make tmerc an alias for etmerc @cffk 's implementation, and rename Snyder's algorithm from tmerc to stmerc. This discussion came up in #374.

Excerpts from the aforementioned issue:

---

busstoptaktik commented on Apr 26
Regarding Transverse Mercator: are you using the high precision etmerc implementation, or the slightly faster, but less precise, original tmerc version?

cffk commented on Apr 26
etmerc will be used in the next release (and this is the checked in version).

hobu commented on Apr 27

Strictly speaking, I believe the proper solution will be to rename what is now known as tmerc, to stmerc (indicating its John Snyder heritage), and renaming etmerc to tmerc

👍

rouault commented on Apr 27
For backward compatibility, I'd suggest not to remove etmerc, but make etmerc and tmerc aliases.

busstoptaktik commented on Apr 27
@rouault: yes - that is really a much better solution (and requires only a few additional lines of code).

[hobu]

I was not going to make this change by myself, and I was content to leave the status quo unless a pull request providing an implementation was provided and the consensus on @rouault's implementation was generally well received by the mailing list.

[kbevers]

After having started tackling this issue in #1234 I've been wondering if it would be better handle this in a slightly different way. I still want to switch the default tmerc to the etmerc algorithm. But instead of creating a stmerc that is a copy of the current tmerc I would add a flag to tmerc that toggles which algorithm is used. Perhaps +fast or +approx. This is similar to helmert where it is possible to toggle the exact version of the algorithm by adding +exact.

The main advantages to this approach is that no further (dummy) operations are added and possibly easier to document (we can stick to just one Transverse Mercator doc page).

@rouault will this make any difference in the ISO19111 code? Currently etmerc can be toggled on and off with USE_ETMERC=NO, at least my alternative approach suggested here is closer to that in the projstring but I can't tell if it could also simplify things in the C++ code.

[rouault]

will this make any difference in the ISO19111 code?

I don't think this would be a big difference.

[kbevers]

I don't think this would be a big difference.

Okay. I am also interested in your opinion on my proposal in general.

[rouault]

Okay. I am also interested in your opinion on my proposal in general.

I'm not sure to have understood if proj=etmerc would beome invalid ? This was added in 2011

[kbevers]

No, etmerc will still exist but will be synonym with tmerc as already agreed upon. The only difference really is not introducing a stmerc and instead handling that use case with +proj=tmerc +fast.

[rouault]

The only difference really is not introducing a stmerc and instead handling that use case with +proj=tmerc +fast.

Sounds good to me