Calculating azimuth of a line or between two points. Help!

[empirepd]

Hello all,

I am having a lot of trouble trying to come up with some MB code to
calculate the azimuth of a line or the azimuth of the line that would
connect two points if that would work. I am in disbelief that MB
doesn't have a function that does this. Anybody got any code that does
this?

Thanks much,
Sam
arcane...@gmail.com

[Glen]

http://williams.best.vwh.net/avform.htm

[Rohit Mistry]

Hi,

 

i think there is no readymade functinon to calculate azimuth between two point.

it is only  Some function ( like,,sin,cos,tan, .) using this u have to calculate azimuth beetween 2 point.

Consider 4 quadrent 0-90-180-270..

 

Br//

Rohit 

 

[Glen]

What a pain in the butt that was
Note to Mapinfo developers GET BETTER math functions ACOS() has a bug!
and you have no ATAN2() function why?

'***************************************************************************************************************

Function Telcom_AZM(ByVal Start_PT_Lat As Float, ByVal Start_PT_Long
as Float, ByVal END_PT_Lat As Float, ByVal END_PT_Long As Float) As
Float


Dim rStart_PT_Lat As Float
Dim rEnd_PT_Lat As Float
Dim Bearing, dLon As Float
Dim X,Y As Float
Dim AZM as Float

rStart_PT_Lat = Start_PT_Lat * DEG_2_RAD
rEnd_PT_Lat = End_PT_Lat * DEG_2_RAD

dLon = (End_PT_Long - Start_PT_Long) * DEG_2_RAD

y = sin(dLon) * cos(rEnd_PT_lat)
x = cos(rStart_PT_Lat) * sin(rEnd_PT_lat) - sin(rStart_PT_lat) *
cos(rEnd_PT_lat) * cos(dLon)
Bearing = atan2(y, x)
Azm = round (Bearing * RAD_2_DEG, 0.1)

if AZM < 0 then
Telcom_Azm = 360 - ABS(AZM)
Else
Telcom_Azm = AZM
End If
End Function

'*************************************** ATAN2
***********************************************
Function aTan2(ByVal y As Float, ByVal x As Float) As Float

If x > 0 Then
aTan2 = Atn(y / x)
ElseIf x < 0 And y >= 0 Then
aTan2 = Atn(y / x) + PI
ElseIf x = 0 And y > 0 Then
aTan2 = PI / 2
ElseIf x < 0 And y < 0 Then
aTan2 = Atn(y / x) - PI
ElseIf x = 0 And y < 0 Then
aTan2 = -PI / 2
End If

End Function

[Bill Thoen]

What's the bug in acos()?

[Glen]

Bill

I sent you some example code did you get it?

G

[Spencer Simpson]

This subject's come up a few times in this group in the past.

The dirty little secret about ACOS is that it's inherently inaccurate. In
certain regions, the arc-cosine function is *extremely* sensitive to *tiny*
variations in the numbers, variations such as the ones inherent in
representing floating-point numbers inside computers.

AFAIK, MapInfo merely passes their ACOS function on to the acos() that comes
with the C compiler they build MapInfo with. It's unreasonable to expect
anything more accurate without going to (non-standard) higher precision
numbers, and that would make your programs run a LOT slower.

Since it's possible to algebraically derive a formula for the sine function
from the cosine function, you can use the ATAN2 function to get the azimuth.

That way, you're balancing out the inaccuracy in the sine function against
the inaccuracy in the cosine.

(ATAN2 calculates the direction of a 2-D vector given its two scalar
components, and the sine and cosine are the components of the great circle's
direction vector at the starting point).

Yes, the C compiler's builtin ATAN2 function really should be exposed in
MapInfo/MapBasic, since it's table-based and likely to be more accurate than
anything you can whip up in MapBasic. You can use your own C compiler to
make a DLL that exposes that compiler's ATAN2, and then reference the DLL in
your MapBasic program. However, you still get more accuracy by creating a
MapBasic ATAN2 from ATN than you'd get with just the cosine formula.

IF you use

LAT0 = start latitude
LON0 = start longitude
LAT1 = stop latitude
LON1 = stop longitude

DIST = angular distance
DLON = LON1-LON0

Sin AZIMUTH = sin (DLON) * cos LAT0 / sin DIST
Cos AZIMUTH = ( cos LAT1*sin LAT0 - sin LAT1*cos LAT0*cos DLON ) / sin DIST

which would mean

AZIMUTH = ATAN2 (
sin DLON*cos LAT0,
cos LAT1*sin LAT0 - sin LAT1*cos LAT0*cos DLON
)

Of course, this only works on the sphere: Things become a LOT more
complicated on an ellipsoid. Some of you may remember that I converted some
FORTRAN code for ellipsoidal navigation to C++ (downloaded from NIST IIRC).
There was a paper (written by the Air Force for targeting ICBMs) that
accompanied it. Unfortunately, the azimuth function was much simplified from
the formulae in the paper, and was correspondingly less accurate.

The old USGS bulletin 1532 by the late John P. Snyder explains the math a
lot better than his later publication Map Projections - a Working Manual"
(USGS Professional Paper 1395)

[Bill Thoen]

Yes, thanks, but from what I've heard of acos() in general sounds like
Spencer's comments are right. It's more the nature of the beast than a
bug in MapInfo's function.

[Glen]

Gents

Not to seem MEAN but my $50 dollar scientific calculator should not
work better that my $1000.00 + dollars software
I also feel if it works in Microsoft Excel it should work in MapInfo.
Same computer same floating point error.
So I feel it's a bug, but it is only my opinion


G

[Spencer Simpson]

The upshot is, your $50 scientific calculator only has to process as fast as
you can type, so the designers of your calculator could push the tradeoff
between accuracy and speed towards the side of accuracy.

If you want higher-precision (or even arbitrary-precision) floating-point
math, there is certainly software out there to do it. But then the
calculations will be done in software, and not the processor, so it's going
to be slow.

Spencer

-----Original Message-----
From: mapi...@googlegroups.com [mailto:mapi...@googlegroups.com] On
Behalf Of Glen
Sent: Monday, February 04, 2008 5:45 PM
To: MapInfo-L