[Proj] Kruger 1912 inverse formulas are faster than I claimed.

paalkr pal.kristensen at statkart.no
Wed Apr 1 02:45:33 EST 2009


The work you have done regarding higher accuracy i very interesting. I work in the Norwegian Mapping and Cadastre Authority, and as you described we tend to use UTM zone 33 for all of Norway when building national wide databases. Because of this I would like to try out the enhancements you have worked on. Is there any pre-build binaries available of proj4 that contains the fix? Is the source code available so that I can compile it myself? Is it possible to incorporate this fix in the latest proj4 release, or does it depend on a specific revision number?

Pål Kristensen


I must apologize.  My timings for the Krüger 
formulas in the inverse direction were wrong.  

It's embarassing, but when I generated a lot of test 
points, I did not realize that they could get latitudes 
far outside the range of -90 to 90.  I am not sure why 
this affected my computations so much (since they are 
not iterative), but it seems to have made the computation 
about 10 times longer.

I have also managed to do a few real improvements.  
For example, it turned out that calling sinh(t) and cosh(t), 
on the same t, was inefficient on my computer.  It was much 
better to use the definition and write 

	double exp_t = exp(t);
	double exp_minust = 1.0 / exp_t;
	double sinh_t = 0.5 * (exp_t - exp_minust); 
	double cosh_t = 0.5 * (exp_t + exp_minust); 

After these and a few other minor improvements, my current timings are

                forward  inverse 
  Snyder/tmerc    220      675
  Krüger formulas 625      625

where the numbers give the milliseconds needed to process a million points.
So the Krüger inverse is not slower than tmerc. In the forward direction,
Krüger is around 3 times slower than tmerc.  

So, after I have seen these figures, I do not see much need for a 
compromise algorithm.

A clever algorithm could call the tmerc forward where this is accurate 
enough for the application, perhaps out to 6 or 9 longitude degrees 
from the central meridian.  Elsewhere, it would use the Krüger forward. 
In the inverse direction, the algorithm could just as well use 
Krüger formulas everywhere. 

About the area of usefulness for the Krüger formulas, I do not see 
any troubles around the north and south poles.  The worst error 
I found was that the inverse rounded a latitude, which should 
be 89.999999401 or 6.7 cm from the pole, was rounded to 90.0 exactly. 

The Krüger formulas do not work near the "west pole" and "east pole",
though (the points on the equator, 90 degrees from the central meridian.) 
I am not sure yet exactly how near you can go.  As a rough estimate,
I would say that the formulas work at least to 6000 km from the central 
meridian and its antipodal meridian (true distance, not projected 
distance), but I have not done enough tests yet. 

I am sorry that I asked a question based on faulty data. 
(I just hope that my figures are right this time!) 

Mikael Rittri
Carmenta AB
Box 11354
SE-404 28 Göteborg
Visitors: Sankt Eriksgatan 5
Tel: +46-31-775 57 37
Mob: +46-703-60 34 07 
mikael.rittri at carmenta.com
-----Original Message-----
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Mikael Rittri
Sent: den 22 maj 2008 11:04
To: proj at lists.maptools.org
Subject: [Proj] Transverse Mercator algorithm with good accuracy/speedtrade-off? 

[--- Text deleted ---] 

I have implemented the Swedish proposal[*], which was not too difficult, and I got it to agree with Oscar van Vlijmen's test point. But my implementation is about 4.5 times slower than tmerc in the forward direction, and about 15 times slower in the inverse direction. I doubt that I can improve the speed much. 

[--- Text deleted ---] 

Proj mailing list
Proj at lists.maptools.org

View this message in context: http://n2.nabble.com/Transverse-Mercator-algorithm-with-good-accuracy-speed-trade-off--tp2064100p2567670.html
Sent from the PROJ.4 mailing list archive at Nabble.com.

More information about the Proj mailing list