[Proj] Switch utm from tmerc to etmerc
Roger Bivand
Roger.Bivand at nhh.no
Mon Oct 26 04:00:54 EST 2015
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
>
> I made the change to the source code repository in git. This is not
> typically what end users or downstream packagers use. They will pick up
> an official release. The change I just made will therefore be
> incorporated into release 4.9.3. At that time there will be an
> announcement with the changes (including this one) described. There's
> will only be one version 4.9.3 and specifying that you linked with this
> version will be sufficient to specify the code you used.
>
> This is how proj.4 and most other open source projects are usually
> updated.
>
> I hope this addresses your concerns.
>
> --Charles
>
> On 10/25/2015 07:09 PM, Roger Bivand wrote:
>> 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
>>
>>> --Charles
>>>
>>> On 10/06/2015 11:19 AM, Charles Karney wrote:
>>>> Reposted from
>>>>
>>>> https://github.com/OSGeo/proj.4/issues/316
>>>>
>
>
--
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
More information about the Proj
mailing list