LiveCode is the premier environment for creating multiplatform solutions for all major operating systems  Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!
Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

GSPearson
 Posts: 64
 Joined: Tue May 10, 2011 7:39 pm
Post
by GSPearson » Fri Feb 20, 2015 4:18 pm
I am trying to get the distance between 2 latitude/longitude points and if they are within so many miles of each other then put the marker on the map.
Here is the formula which I am trying to use
ACOS( SIN(lat1*PI()/180)*SIN(lat2*PI()/180) + COS(lat1*PI()/180)*COS(lat2*PI()/180)*COS(lon2*PI()/180lon1*PI()/180) ) * 6371000
Which produces an error of
button "Button": compilation error at line 14 (expression: unquoted literal), char 58
If I just use the first part of the formula up to the + sign I get the following error
button "Button": compilation error at line 14 (Function: separator is not a "'") near "into", char 50
Line 50 reads:
Code: Select all
put ACOS ( SIN ( tFCCLatitude * pi div 180) into tTempPart1
Any Ideas?

Klaus
 Posts: 11497
 Joined: Sat Apr 08, 2006 8:41 am
 Location: Germany

Contact:
Post
by Klaus » Fri Feb 20, 2015 4:22 pm
Quick guess: PI is a constant and not a FUNCTION like you used it in your script.
## ACOS( SIN(lat1*PI()/180)*SIN(lat2*PI()/1...
ACOS( SIN(lat1*PI/180)*SIN(lat2*PI/1...

GSPearson
 Posts: 64
 Joined: Tue May 10, 2011 7:39 pm
Post
by GSPearson » Fri Feb 20, 2015 5:54 pm
I got the formula to work, however my result is 0 which is not correct.
So I have broken down the formula into sections to see what might be going wrong.
Code: Select all
put SIN(tFCCLatitude * pi div 180) into tTempPart1
put SIN(tSourceLocLatitude * pi div 180) into tTempPart2
tFCCLatitude = 42.43952778
tSourceLocLatitude = 41.616444
When I view the variables from a break in the script editor both tTempPart1 and tTempPart2 have a result of 0.
When I compare the values of this to Excel or other programming languages I get a different result listed.
From Excel the values of
Part1 is 0.67481168
Part2 is 0.664140805
So i am not sure how to get livecode to view the numbers past the decimal

Klaus
 Posts: 11497
 Joined: Sat Apr 08, 2006 8:41 am
 Location: Germany

Contact:
Post
by Klaus » Fri Feb 20, 2015 6:10 pm
DIV does not what you might exspect it to do, please check the dictionary!
You had it correct in your first script:
...
put SIN(tFCCLatitude * pi/180) into tTempPart1
...

dunbarx
 VIP Livecode Opensource Backer
 Posts: 6468
 Joined: Wed May 06, 2009 2:28 pm
 Location: New York, NY
Post
by dunbarx » Fri Feb 20, 2015 6:40 pm
Also be aware that "div" and "mod" fall in the same PEMDOS hierarchy as ordinary multiplication or division.
Craig Newman

Dixie
 Livecode Opensource Backer
 Posts: 1336
 Joined: Sun Jul 12, 2009 10:53 am
 Location: Bordeaux, France
Post
by Dixie » Fri Feb 20, 2015 7:03 pm
Make a stack with two fields... err... and a button, then put the following into the button.
Enter the two lat/longs into the fields... and voila ...
Code: Select all
on mouseDown
/*lat/long from first set of coordinates */
put item 1 of fld 1 * pi/180 into lat1
put item 2 of fld 1 * pi/180 into lon1
/*lat/long from second set of coordinates */
put item 1 of fld 2 * pi/180 into lat2
put item 2 of fld 2 * pi/180 into lon2
set numberformat to 0.00
put (sin((lat2 lat1)/2))^2 + cos(lat1) * cos(lat2) * (sin((lon2  lon1)/2))^2 into a
put 2 * atan2( sqrt(a), sqrt(1a) ) into c
put 6373 * c into klicks
put 3961 * c into miles
put klicks && "Kilometres" && "/" && miles && "miles"
end mouseDown
Note : this is basically the 'haversine' formula... the distance in a straight line between two points taking the curvature of the earth into account, as opposed to using the 'google' maps directions service which would give you the distance between the two points if you were driving along the roads...

dunbarx
 VIP Livecode Opensource Backer
 Posts: 6468
 Joined: Wed May 06, 2009 2:28 pm
 Location: New York, NY
Post
by dunbarx » Fri Feb 20, 2015 9:01 pm
But there is a problem here.
Given a constant latitude, say 0° at the equator, the distance one travels over one degree is about 69 miles. So going from, say "0,100" to "0,101" is just that, 69 miles. You likely remain in the same time zone.
But if you are near the poles, say, "85,100", and you travel to "85,101" you only go a few miles. But you might go a handful of timezones.
It is just the way latitudes are plotted. Just off the top of my head, would the cosine of the latitude give the correct, er, correction factor?
Craig

Dixie
 Livecode Opensource Backer
 Posts: 1336
 Joined: Sun Jul 12, 2009 10:53 am
 Location: Bordeaux, France
Post
by Dixie » Fri Feb 20, 2015 10:05 pm
Yes.. you are quite correct, there is a problem...
the 'haversine formula' is not too clever over small distances, it would have been better to have used 'Vincenty's formula', ... I tried, but couldn't write it to work in liveCode, which is due to my failings not liveCodes...

dunbarx
 VIP Livecode Opensource Backer
 Posts: 6468
 Joined: Wed May 06, 2009 2:28 pm
 Location: New York, NY
Post
by dunbarx » Fri Feb 20, 2015 10:23 pm
Dixie.
The way our longitudes and latitudes are set up, as soon as you leave the equator you start to accumulate errors. I think that the "compression" of the value of the longitude might not be resolved by taking the cosine of the latitude at all, since it now occurs to me that the change in distance between two longitude values is linear from the equator to the poles, no? The curvature of the earth is not pertinent, seen along any two different longitude values. And of course, the way latitudes are set up, as equidistant "parallel" lines, makes differences in their values invariant regardless of where they are taken.
Craig

dunbarx
 VIP Livecode Opensource Backer
 Posts: 6468
 Joined: Wed May 06, 2009 2:28 pm
 Location: New York, NY
Post
by dunbarx » Fri Feb 20, 2015 11:00 pm
This seems to do it. Make three fields, name one "startpoint", one "endPoint" and one "distance". In a button script:
Code: Select all
on mouseUp
put toRadians(item 1 of fld "startPoint") into lat1
put toRadians(item 2 of fld "startPoint") into long1
put toRadians(item 1 of fld "endPoint") into lat2
put toRadians(item 2 of fld "endPoint") into long2
put abs(long1  long2) into d2
put 3959 * aCos(sin(lat1) * sin(lat2) + cos(lat1) * cos(lat2) * cos(d2)) into fld "distance"
end mouseUp
function toRadians var
return var/(180/pi)
end toRadians
Latitudes and longitudes are in standard format (ex.: 120,30), but in decimal form, not "deg/min/sec".
Craig

Simon Knight
 Posts: 539
 Joined: Wed Nov 04, 2009 11:41 am
 Location: Gunthorpe, North Lincs, UK
Post
by Simon Knight » Wed Jul 12, 2017 9:43 am
Hi, realise that this thread is a couple of years old but I am playing with GPS coordinates at present and found it while looking for methods of processing recorded positions to determine the speed of travel. On first reading the figure of 69 miles quoted above made my eyes pop in a WHAT NO sort of way. Why?
Our Earth is an oblate spheroid (a slightly squashed sphere or if your really care its slightly pear shaped) however for most purposes it is reasonable to make the assumption that the earth is a perfect sphere i.e. it has a constant radius. When working with coordinates and distances on the earth I recommend that you work in nautical miles (nm). This is because the definition of a nautical mile is that it is the distance subtended on the surface of the earth by one minute of arc at the centre. This means that a change of one degree of latitude is 60nm and because the Earth is a sphere a change of one degree of longitude on the equator is also 60nm. Fortunately 60nm is 69ish statute miles so my eyes can stop popping.
In order to calculate speed I need to calculate distance moved between reports. The simplest method is to use the coordinates to form a triangle and use Pythagoras theorem to calculate the distance. This method is accurate for short distances between points say no more than 200nm apart.
Comparing the two positions yields the angular changes in Latitude and Longitude.
From above the change in Latitude (in degrees) converts to distance (nm) through simple multiplication : ChLat*60 (i.e. convert to minutes). The change in Longitude is a little more complex as the distance varies from 60nm on the equator to zero at the poles. The distance in nm at any given Latitude between two Longitudes is known as departure and may be calculated using : departure(nm) = ChLong * 60 * Cosine(Mid Latitude) , where mid latitude = (Lat1 + Lat 2)/2.
Plug these two numbers into Pythagoras to calculate the distance between the points : Distance = SquareRoot ( departure squared + ChLat*60 squared )
For distances greater than 200nm then use the Haversine formula which calculates Great Circle distances rather than the departure which is a rhumb line.
best wishes
Skids
best wishes
Skids