Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing Transverse Mercator Algorithm for +proj=tmerc #404

Closed
micahcochran opened this issue Aug 22, 2016 · 7 comments
Closed

Changing Transverse Mercator Algorithm for +proj=tmerc #404

micahcochran opened this issue Aug 22, 2016 · 7 comments
Milestone

Comments

@micahcochran
Copy link
Contributor

@micahcochran micahcochran commented Aug 22, 2016

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
Copy link
Contributor

@hobu hobu commented Aug 22, 2016

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 kbevers added this to Decisions in 2017 release Jul 5, 2017
@kbevers kbevers added this to the 6.0.0 milestone Mar 5, 2018
@kbevers
Copy link
Member

@kbevers kbevers commented Feb 4, 2019

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
Copy link
Member

@rouault rouault commented Feb 4, 2019

will this make any difference in the ISO19111 code?

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

@kbevers
Copy link
Member

@kbevers kbevers commented Feb 4, 2019

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

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

@rouault
Copy link
Member

@rouault rouault commented Feb 4, 2019

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
Copy link
Member

@kbevers kbevers commented Feb 4, 2019

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
Copy link
Member

@rouault rouault commented Feb 4, 2019

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

Sounds good to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
2017 release
Decisions
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants