[Proj] Kruger 1912 inverse formulas are faster than I claimed.
Mikael Rittri
Mikael.Rittri at carmenta.com
Wed Apr 1 07:19:38 EST 2009
Hello Pål,
my own work is now implemented in Carmenta Engine, which is a
commercial GIS toolkit (http://www.carmenta.com/products/carmenta-engine).
As Thomas Knudsen said, Gerald Evenden has now implemented three
wide-accuracy Transverse Mercator algorithms in his libproj4.
These are
ftmerc (French algorithm),
ktmerc (Swedish algorithm, almost the same as a Finnish algorithm),
etmerc (Engsager's Danish algorithm).
I have read about them in the manual, but I haven't tried them.
The libproj4 can be found here: http://members.verizon.net/~vze2hc4d/proj4
TK> ...don't know whether it has been entered into Frank's yet).
I don't know, either.
For the ultimate overview of Transverse Mercator algorithms,
see Charles Karney's post from Sep 2008,
http://lists.maptools.org/pipermail/proj/2008-September/003746.html ,
as well as the documentation of his GeographicLib
(http://charles.karney.info/geographic). This library also
provides a wide-accuracy TM algorithm. Not to mention his global-
accuracy TM algorithm, which has errors less than 8 nanometers.
Now, that's what I call amazing accuracy.
However, any of the wide-accuracy TM algorithms should be more than
enough for Norway. My understanding is that these give millimeter
accuracy to at least 40 degrees of arc distance (not degrees
of longitude) away from the central meridian. (Well, depending
on the number of terms used in the series expansion, etc.)
Best regards,
--
Mikael Rittri
Carmenta AB
Box 11354
SE-404 28 Göteborg
Visitors: Sankt Eriksgatan 5
SWEDEN
Tel: +46-31-775 57 37
Mob: +46-703-60 34 07
mikael.rittri at carmenta.com
www.carmenta.com
-----Original Message-----
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of paalkr
Sent: den 1 april 2009 09:46
To: proj at lists.maptools.org
Subject: Re: [Proj] Kruger 1912 inverse formulas are faster than I claimed.
Hi!
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?
Regards,
Pål Kristensen
Hello,
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
SWEDEN
Tel: +46-31-775 57 37
Mob: +46-703-60 34 07
mikael.rittri at carmenta.com
www.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
http://lists.maptools.org/mailman/listinfo/proj
--
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.
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
More information about the Proj
mailing list