[Proj] Problems with /Op option used to compile proj in Microsoft Visual Studio
strebe at aol.com
strebe at aol.com
Thu Mar 15 12:56:48 PDT 2012
Well, then my question is, which are the cases where the two point equidistant projection could not behave well? Is it a problem of the two point equidistant definition or a problem of the way it is implemented in proj lib?
The problem is in implementation. These cases are properly dealt with by reformulating and series expansion. The question is whether it’s worth the bother.
Regards,
— daan Strebe
-----Original Message-----
From: Calogero Mauceri <mauceri at actgate.com>
To: proj <proj at lists.maptools.org>
Sent: Thu, Mar 15, 2012 8:14 am
Subject: Re: [Proj] Problems with /Op option used to compile proj in Microsoft Visual Studio
Glynn Clements wrote:
> Ultimately, I suspect that the calculation for the two-point
> equidistant projection just wasn't designed for the case where the two
> points are around one arc-second apart (approx. 15 metres; would be
> approx. 40 metres on Earth).
Glynn, so you are suggesting that more than in the float number
approximations, the problem is in why the number passed to the aacos is
so close to 1.
Well, then my question is, which are the cases where the two point
equidistant projection could not behave well? Is it a problem of the two
point equidistant definition or a problem of the way it is implemented
in proj lib?
I can provide a long set of cases where the conversion from tpeqd to
longlat fails, I just need a bit of time to run some data processing.
Thanks,
Calogero
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20120315/d8a9fa42/attachment.html>
More information about the Proj
mailing list