[Proj] Kruger 1912 inverse formulas are faster than I claimed.
knudsen.thomas at gmail.com
Wed Apr 1 03:02:36 EST 2009
Pål & Mikael,
Are you aware of Karsten Engsager's wide-range, high precision
implementation ("etmerc" in Gerald's libproj - don't know whether it has
been entered into Frank's yet). Gerald did some timing testing, which was
posted to the list about a year ago.
Engsager's implementation was considered amazingly accurate for an insane
range of input values - and still very fast (although a bit slower than the
Thomas Knudsen, National Survey and Cadastre - Denmark (KMS)
2009/4/1 paalkr <pal.kristensen at statkart.no>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj