etmerc original author Knud Poder turns 90.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

etmerc original author Knud Poder turns 90.

Thomas Knudsen

As described in a recent thread, for the next release, proj.4 will switch the default transverse mercator implementation from tmerc to etmerc.


This is probably a good occasion to reiterate the history of the code for the etmerc implementation - especially since the original author, Knud Poder, turned 90 on October 19th. Having his transverse mercator implementation becoming the proj.4 default is a strikingly proper way of celebrating Poder, among colleagues and collaborators rightfully considered “the Nestor of computational geodesy”.


Poder wrote the first version of what is now known as etmerc, around 1961. It was written in Algol-60 and ran on the GIER computer, built for the Danish Geodetic Institute (see [1] for details).


The code was based on theoretical foundations published a decade earlier, by König & Weise ([2], building on prior work by Krüger, 1912 [3]).


Poder’s work was characterized by great care with respect to numerical precision and accuracy (e.g. by using Clenshaw summation for recurrence series, and Horner’s scheme for polynomial evaluation).


Also, Poder was noted for his ingeniously implemented “dual autochecking method” (not used in the proj.4 version), where the same code was used for forward and inverse projections and was run both ways and compared, to protect against both coding- and hardware errors. The latter was very important at a time where the mean time between failure for computer systems was much shorter than today.


During the 1970s Poder’s student, Karsten Engsager (the “E” in etmerc, “Engsager Extended Transverse Mercator”) took over maintenance and eventually extended König and Weise’s numerical series by another term, bringing the accuracy up to today’s standard.


In 2008, through the efforts of a.o. Gerald Evenden, Frank Warmerdam and Karsten Engsager, etmerc was introduced in proj.4, while in 2013 Charles Karney provided 3 corrections - stressing the value and importance of open source code sharing.


Poder retired 20 years ago, but has been taking active interest in the maintenance and development of his code ever since. Switching proj.4 to use a transverse mercator implementation based on his work is probably the best conceivable way of celebrating the 90th birthday of a great Nestor of computational geodesy.


In celebration of Knud Poder!


/Thomas Knudsen, Danish Geodata Agency




[1] Thomas Knudsen, Simon L. Kokkendorff, Karsten E. Engsager (2012): A Vivid Relic Under Rapid Transformation, OSGeo Journal vol. 10, pp. 55-57, URL https://journal.osgeo.org/index.php/journal/article/download/200/167


[2] R. König and K. H. Weise (1951): Mathematische Grundlagen der Höheren Geodäsie und Kartographie, Erster Band. Springer, Berlin/Göttingen/Heidelberg, 1951. K


[3] L. Krüger (1912): Konforme Abbildung des Erdellipsoids in der Ebene. Neue Folge 52. Royal Prussian Geodetic Institute, Potsdam. URL http://bib.gfz-potsdam.de/pub/digi/krueger2.pdf



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: etmerc original author Knud Poder turns 90.

Davide Cesari
Sorry for erroneously reposting this message to the mailing list, I was
so caught in the interesting reading that I hit a wrong button in my
mailing program,
        Davide


On 28/10/2015 14:56, Thomas Knudsen wrote:
> As described in a recent thread, for the next release, proj.4 will
> switch the default transverse mercator implementation from tmerc to etmerc.
>
...


--
============================= Davide Cesari ============================
Dott**(0.5) Davide Cesari
ARPA-Emilia Romagna, Servizio IdroMeteoClima
NWP modelling - Modellistica numerica previsionale
Tel. +39 051525926
========================================================================
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

support-2
In reply to this post by Thomas Knudsen

Hello,

basically it is always ok to switch to any calculation that is more accurate or more formally correct ... but there should also be some kind of a method to stay downwards compatible. At least some methods or go arounds to stay compatible with old version should be given to users?!

What proj4 declarations should be used to keep the old calculation in effect?! etc..

Regards: Janne.

-----------------------------------------------

Thomas Knudsen kirjoitti 28.10.2015 15:56:

As described in a recent thread, for the next release, proj.4 will switch the default transverse mercator implementation from tmerc to etmerc......

 


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

Thomas Knudsen
If memory serves me right, you should use something like +proj=tmerc
+x_0=500000 +lon_0=...   +scale=0.9996 to invoke the Snyder algorithm
(fully analogous to what you had to do up until now to get utm using
+proj=etmerc)

/thomas

2015-11-02 11:42 GMT+01:00  <[hidden email]>:

> Hello,
>
> basically it is always ok to switch to any calculation that is more accurate
> or more formally correct ... but there should also be some kind of a method
> to stay downwards compatible. At least some methods or go arounds to stay
> compatible with old version should be given to users?!
>
> What proj4 declarations should be used to keep the old calculation in
> effect?! etc..
>
> Regards: Janne.
>
> -----------------------------------------------
>
> Thomas Knudsen kirjoitti 28.10.2015 15:56:
>
> As described in a recent thread, for the next release, proj.4 will switch
> the default transverse mercator implementation from tmerc to etmerc......
>
>
>
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

support-2
Hello,

why not just add a new projection called "utm2" or "newutm" or "xutm" ..
and use it like "proj=utm2" etc. I would like more if the new utm was
called different so that the old references would stay where they always
been.. just to stay consistent..

Regards Janne.

--------------------------------------------------------

Thomas Knudsen kirjoitti 02.11.2015 14:15:

> If memory serves me right, you should use something like +proj=tmerc
> +x_0=500000 +lon_0=...   +scale=0.9996 to invoke the Snyder algorithm
> (fully analogous to what you had to do up until now to get utm using
> +proj=etmerc)
>
> /thomas
>
> 2015-11-02 11:42 GMT+01:00  <[hidden email]>:
>> Hello,
>>
>> basically it is always ok to switch to any calculation that is more
>> accurate
>> or more formally correct ... but there should also be some kind of a
>> method
>> to stay downwards compatible. At least some methods or go arounds to
>> stay
>> compatible with old version should be given to users?!
>>
>> What proj4 declarations should be used to keep the old calculation in
>> effect?! etc..
>>
>> Regards: Janne.
>>
>> -----------------------------------------------
>>
>> Thomas Knudsen kirjoitti 28.10.2015 15:56:
>>
>> As described in a recent thread, for the next release, proj.4 will
>> switch
>> the default transverse mercator implementation from tmerc to
>> etmerc......
>>
>>
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

Charles Karney
Dear Janne,

I'm against given the new utm implementation a different name.  The
whole point is that a naive user can request "utm" and get the best
available implementation of the projection.

Conceivably, the old version could be made available as "oldutm" or
whatever.  But I would like to see some evidence this is really needed
given that with the standard UTM conventions for zones, we are only
talking about a ~ 0.1mm difference -- and this is also the round-trip
discrepancy in the old implementation.

   --Charles

On 11/08/2015 06:12 PM, [hidden email] wrote:

> Hello,
>
> why not just add a new projection called "utm2" or "newutm" or "xutm" ..
> and use it like "proj=utm2" etc. I would like more if the new utm was
> called different so that the old references would stay where they always
> been.. just to stay consistent..
>
> Regards Janne.
>
> --------------------------------------------------------
>
> Thomas Knudsen kirjoitti 02.11.2015 14:15:
>> If memory serves me right, you should use something like +proj=tmerc
>> +x_0=500000 +lon_0=...   +scale=0.9996 to invoke the Snyder algorithm
>> (fully analogous to what you had to do up until now to get utm using
>> +proj=etmerc)
>>
>> /thomas
>>

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

Even Rouault-2
Le lundi 09 novembre 2015 00:36:45, Charles Karney a écrit :

> Dear Janne,
>
> I'm against given the new utm implementation a different name.  The
> whole point is that a naive user can request "utm" and get the best
> available implementation of the projection.
>
> Conceivably, the old version could be made available as "oldutm" or
> whatever.  But I would like to see some evidence this is really needed
> given that with the standard UTM conventions for zones, we are only
> talking about a ~ 0.1mm difference -- and this is also the round-trip
> discrepancy in the old implementation.

For what is worth, I also don't see the point in making the old 'utm' available
under any other name for sub millimeter differences.

And there are other changes/fixes that are sometimes done in other projections
that affect computations by much larger extent, hopefully towards more correctness.
For example, the results of the aeqd projection can be very different w.r.t
older versions, when going far from the center point (and for the better since the results now round-trip)

proj 4.8.0 :

$ echo "0 -45" | cs2cs +proj=longlat +datum=WGS84 +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
-5504790.57 -3840359.33 0.00

$ echo "-5504790.57 -3840359.33" | cs2cs -I +proj=longlat +datum=WGS84 +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
44d36'50.801"E 0d16'23.383"S 0.000

--> completely off

proj 4.9.2

$ echo "0 -45" | cs2cs +proj=longlat +datum=WGS84 +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
-10900566.43 -7663668.99 0.00

$ echo "-10900566.43 -7663668.99" | cs2cs -I +proj=longlat +datum=WGS84 +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
0dW 45dS 0.000

--> perfect

If people are not happy with new proj versions, by all means, they can stay with older releases,
or fork the project to fit their purposes, or ask for a refund for their license fees.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

support-2
Hello,

since the difference will be in sub millimeter region .. I might also
not to be too much worried about the change .. especially if it is also
not much slower and clearly notified. But just to remain in some cases
it IS VERY important to get repeatable results (even if wrong) with the
library .. but this change could also be handled just mentioning that
the new utm formula will change the computation so and so much. And as
such the programmer (not the end user) should NOT apply the new library
without testing the results (so to say "keep the old version if you need
to be absolutely sure that the computations will be repeatable in the
future also..")

Janne.

--------------------------------------------------------------

Even Rouault kirjoitti 09.11.2015 04:36:

> Le lundi 09 novembre 2015 00:36:45, Charles Karney a écrit :
>> Dear Janne,
>>
>> I'm against given the new utm implementation a different name.  The
>> whole point is that a naive user can request "utm" and get the best
>> available implementation of the projection.
>>
>> Conceivably, the old version could be made available as "oldutm" or
>> whatever.  But I would like to see some evidence this is really needed
>> given that with the standard UTM conventions for zones, we are only
>> talking about a ~ 0.1mm difference -- and this is also the round-trip
>> discrepancy in the old implementation.
>
> For what is worth, I also don't see the point in making the old 'utm'
> available
> under any other name for sub millimeter differences.
>
> And there are other changes/fixes that are sometimes done in other
> projections
> that affect computations by much larger extent, hopefully towards more
> correctness.
> For example, the results of the aeqd projection can be very different
> w.r.t
> older versions, when going far from the center point (and for the
> better since the results now round-trip)
>
> proj 4.8.0 :
>
> $ echo "0 -45" | cs2cs +proj=longlat +datum=WGS84 +no_defs +to
> +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
> -5504790.57 -3840359.33 0.00
>
> $ echo "-5504790.57 -3840359.33" | cs2cs -I +proj=longlat +datum=WGS84
> +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
> 44d36'50.801"E 0d16'23.383"S 0.000
>
> --> completely off
>
> proj 4.9.2
>
> $ echo "0 -45" | cs2cs +proj=longlat +datum=WGS84 +no_defs +to
> +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84 +no_defs
> -10900566.43 -7663668.99 0.00
>
> $ echo "-10900566.43 -7663668.99" | cs2cs -I +proj=longlat
> +datum=WGS84 +no_defs +to +proj=aeqd +lat_0=45 +lon_0=90 +datum=WGS84
> +no_defs
> 0dW 45dS 0.000
>
> --> perfect
>
> If people are not happy with new proj versions, by all means, they can
> stay with older releases,
> or fork the project to fit their purposes, or ask for a refund for
> their license fees.
>
> Even

--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Potentially (theoretically) dangerous changes in Proj4 internal routines that affect the end results..

Paul Kelly
On 11/18/2015 10:27 PM, [hidden email] wrote:
 >
 > (so to say "keep the old version if you need
 > to be absolutely sure that the computations will be repeatable in the
 > future also..")

I seem to remember someone has already said this, but it shouldn't be
necessary to keep an old version of PROJ.4 since all you have to do to
keep the same formula is to reformulate the projection definition using
+proj=tmerc instead of +proj=utm. The old +proj=tmerc formula will still
be available in new versions of PROJ.4 in the future.

It would probably be a good idea for the release notes for the new
version to make this clear, to avoid undue alarm, and to explain that
projection definitions that use +proj=tmerc will give the same results
in both previous and future releases.

Paul
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj