[Proj] Switch utm from tmerc to etmerc

[Roger Bivand]

On Mon, 26 Oct 2015, Even Rouault wrote:

> Le lundi 26 octobre 2015 00:09:10, Roger Bivand a écrit :
>> Charles Karney <charles.karney <at> sri.com> writes:
>>> This change has now been made to the master branch of the source.  The
>>> "utm projection" now follows the NGA recommendation and uses etmerc
>>> instead of tmerc (which is less accurate).  You can expect small
>>> (typically < 1mm, except at high latitudes) changes in the results for
>>> the utm projection.
>>
>> While correcting wrong parameterisations is good, here we are doing what
>> the mooted metacrs definitions were trying to avoid, that is altering
>> in-place code without user-facing versioning. Different versions (by
>> commit hashes now) of the underlying code will now give different answers,
>> so re-running an analysis with the same data and apparently the same code
>> in software linking to proj will give different answers, without the user
>> necessarily being able to re-instate the earlier relationship. It would be
>> great to bear in mind the fact that research does need to be reproducible
>> (data from times before this correction was known don't need to be obliged
>> to use it). I guess we have to assume that users really read commit logs
>> and NEWS files.
>
> Roger,
>
> I'm not in the business of reproducible research but I guess that if you want
> things to be perfectly reproducible you'd have to specify all the environment:
> exact software versions, probably with their compilation options and versions
> of their dependencies, OS version, and possibly hardware that was used.

Even,

Please see my reply to Charles. Usually the specification is the exact 
software versions of the workflow components; R provides sessionInfo() to 
record its immediate environment (including locale, which bites often). R 
runs a lot of tests like this across platforms, also on contributed 
packages, and for example 32 bit/64 bit/extended precision issues do get 
trapped across platforms and architectures. Given IEEE numerics, most of 
the other concerns are less important (unless they bite ...). The chain of 
dependencies external to R is less standardised, but attention to this is 
for example described in:

https://www.r-project.org/certification.html

for R "itself". Some of the dependencies have been changing recently to 
work around upstream issues, which is a never ending story; this includes 
a lot of work also in R istelf to handle clang. But reproducible research 
in some (an increasing number) contexts is not an option, it is a 
requirement (within reason). It's partly a mindset, but there are real 
differences in understanding of why applying apparently the same software 
to the same data may give different results.

Best wishes,

Roger

>
> Even
>
>>
>> Roger
>>
>>>    --Charles
>>>
>>> On 10/06/2015 11:19 AM, Charles Karney wrote:
>>>> Reposted from
>>>>
>>>>    https://github.com/OSGeo/proj.4/issues/316
>>
>> ...
>>
>>
>>
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: Roger.Bivand at nhh.no