[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