<div class="gmail_quote">Pål & Mikael,<br><br>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.<br>
<br>Engsager's implementation was considered amazingly accurate for an insane range of input values - and still very fast (although a bit slower than the Snyder "tmerc").<br><br>Regards<br>Thomas Knudsen, National Survey and Cadastre - Denmark (KMS)<br>
<br><br>2009/4/1 paalkr <span dir="ltr"><<a href="mailto:pal.kristensen@statkart.no">pal.kristensen@statkart.no</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi!<br>
<br>
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?<br>
<br>
Regards,<br>
Pål Kristensen<br>
<div><div></div><div class="h5"><br>
<br>
<br>
Hello,<br>
<br>
I must apologize. My timings for the Krüger<br>
formulas in the inverse direction were wrong.<br>
<br>
It's embarassing, but when I generated a lot of test<br>
points, I did not realize that they could get latitudes<br>
far outside the range of -90 to 90. I am not sure why<br>
this affected my computations so much (since they are<br>
not iterative), but it seems to have made the computation<br>
about 10 times longer.<br>
<br>
I have also managed to do a few real improvements.<br>
For example, it turned out that calling sinh(t) and cosh(t),<br>
on the same t, was inefficient on my computer. It was much<br>
better to use the definition and write<br>
<br>
double exp_t = exp(t);<br>
double exp_minust = 1.0 / exp_t;<br>
double sinh_t = 0.5 * (exp_t - exp_minust);<br>
double cosh_t = 0.5 * (exp_t + exp_minust);<br>
<br>
After these and a few other minor improvements, my current timings are<br>
<br>
forward inverse<br>
Snyder/tmerc 220 675<br>
Krüger formulas 625 625<br>
<br>
where the numbers give the milliseconds needed to process a million points.<br>
So the Krüger inverse is not slower than tmerc. In the forward direction,<br>
Krüger is around 3 times slower than tmerc.<br>
<br>
So, after I have seen these figures, I do not see much need for a<br>
compromise algorithm.<br>
</div></div></blockquote></div><br>