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

[Thomas Knudsen]

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
Snyder "tmerc").

Regards
Thomas Knudsen, National Survey and Cadastre - Denmark (KMS)


2009/4/1 paalkr <pal.kristensen at statkart.no>

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20090401/8a3349c7/attachment.htm