[Proj] Switch utm from tmerc to etmerc

[Charles Karney]

Roger,

Reading your last messages, it seems to me that we are exactly aligned
in our understanding.

First of all (as I'm sure you realize), the results you get from proj.4
*are* reproducible providing you keep track of the version (software +
data files + compiler + build environment + ...).

For any reasonably complex package like proj.4 (and proj.4 is simpler
than most because it doesn't depend on other libraries), lots of things
change from one version to the next (bug fixes, improvements to
algorithms, new capabilities, etc.)  You want an easy way to toggle
these changes in version N to reproduce, selectively, the behavior in
version N-1.

While this is certainly doable, I don't think it's a sustainable
solution to deal with the scores of little fixes that get made to proj.4
during the course of a year.  (The code becomes a mess; testing is a
bigger mess; there will be all sorts of weird interactions between the
resulting environment variables.)

If there is a need to reproduce the old utm behavior in the next release
of proj.4, then I would recommend using tmerc (with the extra parameters
to specify central longitude, false easting, and scale) instead of utm.

And, of course, you always have the choice of sticking with the previous
version of proj.4

   --Charles

On 10/26/15 05:00, Roger Bivand wrote:
> On Mon, 26 Oct 2015, Charles Karney wrote:
>
>> I have a different understanding of the process from you.
>
> Yes, that's why I voiced it. The understanding of process in software
> development (not only open source) and in reproducible research does
> differ. I mentioned the same concern on:
>
> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html
>
> to which Howard replied:
>
> http://lists.osgeo.org/pipermail/metacrs/2015-August/000848.html
>
> Software development seems to focus on replacing "less correct"
> computations with "more correct; more attractive; more efficient", while
> reproducible research needs to document as far as possible which
> versions of software and metadata were used to generate a given result
> from given data (things like RNG seeds too). So when the EPSG file is
> updated, it would be great to be able to "know" about the version from
> the user interface.
>
> The same applies to +proj=utm, which is widely used, and where
> projection to utm from 4.9.3 will give (slightly) different numerical
> results (possibly trivial for practical purposes), but which may for
> example change variogram fitting output (again trivially, but tests for
> numerical equality within machine precision are often used to trap other
> software changes).
>
> If an environment variable was available to revert to legacy behaviour,
> it would be easy to see if downstream changes in performance are down to
> this (agreed, sensible) revision, or to something else.
>
> Sorry to be pedantic, but the difference in understanding is real.
>
> Roger