[Proj] Switch utm from tmerc to etmerc

[Howard Butler]

> On Oct 26, 2015, at 4:00 AM, Roger Bivand <Roger.Bivand at nhh.no> 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

There are two separate concerns -- the parameter definitions and the maths that use them. Proj.4 is a mix of both, for better or worse, and at the moment if reproducibility is your primary concern, stick to known, point-in-time, named releases. You must deal with version difference issues downstream, or you must contribute upstream in a way that achieves your downstream goals. 

> 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.

I don't support adding this complexity. Downstream projects that require sensitivity testing like that need to build it themselves or contribute corresponding testing to the Proj.4 project. More knobs and switches just make things harder to maintain and cascades the possible permutations further down the line. The GDAL project, for example, has a number of tests that demonstrate sensitivity issues due to Proj.4 modifications. 

Proj.4 already has a tendency for internal complicatedness, and the people who remember most of it have moved on. There is no incoming audience of developers jumping in to pick up the slack. I think the reasons are because the problem space is indeed very complex (math, intricate metadata), and people write this style of software quite differently now (smaller audience who feels comfortable tinkering with it). Proj.4's ongoing goals 

For some perspective on this please go read ESR's blog posts about rewriting NTPSec [1]. The comparisons are not direct, but I think the sentiment is. Proj.4 exists in a similar space as OpenSSL and NTPSec and friends -- it is foundational infrastructure for a ton of projects, but it has solved the problem, and the interest has all moved on. Proj.4's ongoing challenge is bitrot and lack of a large enough pool of interested developers. Like a building standing alone in the elements, over time it trends toward being indistinguishable from the jungle in which it is surrounded unless people keep up with tasks like clearing the gutters and patching the roof.

In my role as maintainer, I'm here to attempt to stem the tide against this bitrot and try to ensure that Proj.4 continues to have releases. I'm not here to rewrite the software, institute rigorous regression tracking, or bureaucratify Proj.4's non-existant project process. If you wish to do those things, start filing tickets with code attached. 

Contributions that would significantly improve the health of the project include documentation organization and cleanup (we're now set up to do github pages at http://proj4.org which means documentation contribution can for the first time come through the same tool chain as tickets/code). We need more tests that identify and adapt to the precision and dictionary issues you've raised. Finally, we need modernization of the testing framework so it is more convenient to add regression-style tests in a platform-agnostic way. 

When Charles first proposed this modification, I asked that he give fair warning so the change would not silently happen. I know this kind of a modification could cause unexpected data differences, and I wanted to give people who might have opinions on it a chance to chime in. We heard nothing for three weeks, and that's enough permission asking as far as I'm concerned.

> I guess we have to assume that users really read commit logs and NEWS files.

Nowadays, people google things. Between the github ticket(s) and the mailing list posts, we've given them plenty of breadcrumbs to figure out what happened. Much more than a cryptic NEWS entry (which we'll have too).

Howard

[1] http://esr.ibiblio.org/?p=6881