0

I read this question and implemented the accepted answer in Python (see below). It works in principle, but the results are consistently about 30% higher than expected (Czech Republic) - is that the expected accuracy of this algorithm?

To verify the algorithm, I used BoundingBox to get a bounding box with a known diagonal distance (building, two cities) and used the output coordinates as input for "my" algorithm.

Where is the problem?

  • my implementation?
  • the algorithm itself?
  • Python?
  • testing?

My implementation:

R= 6371 #km
dLat = math.radians(lat2-lat1)
dLon = math.radians(lon2-lon1)
lat1 = math.radians(lat1)
lat2 = math.radians(lat2)

a= math.sin(dLat/2)*math.sin(dLat/2) + math.sin(dLon/2) * math.sin(dLon/2) * math.cos(lat1) * math.cos(lat2)
c= 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
d = R * c;
return d
Community
  • 1
  • 1
Lukas
  • 2,232
  • 3
  • 21
  • 34
  • Why did you post a new question? http://stackoverflow.com/questions/17134437/how-to-calculate-distance-between-two-geographical-coordinates – Ashwini Chaudhary Jun 16 '13 at 14:55
  • @AshwiniChaudhary This should have been the only one. The first one got posted by some mistakenly pressed key when it was not yet written. – Lukas Jun 16 '13 at 14:59
  • You can always edit your question — or delete it as you have done. You can even delete a question while you're fixing a premature posting and then undelete it. (At least, I believe you can; you can do that for answers for sure.) – Jonathan Leffler Jun 16 '13 at 15:54

1 Answers1

3

No, the algorithm is not supposed to have an error of that magnitude. The link specifies that you can expect around a 0.3% error.

I can not reproduce your results with your code, so I believe the error is with your testing.

Here's some testing data from a site with the distance between and coordinates of Prague and Brno in decimal degrees format:

lat_prague, long_prague = 50.0833, 14.4667
lat_brno, long_brno = 49.2000, 16.6333
expected_km = 184.21

Here are the testing results:

>>> def calc(lat1,lon1, lat2,lon2):
# ... your code ...

>>> calc(lat_prague,long_prague,lat_brno,long_brno)
184.34019283649852
>>> calc(lat_prague,long_prague,lat_brno,long_brno) / expected_km
1.0007067631317437

A wild guess: for locations in the Czech Republic, the error you're getting seems in the right order of magnitude for with mixing up latitude and longitude:

>>> calc(long_prague,lat_prague,long_brno,lat_brno)
258.8286271447481
>>> calc(long_prague,lat_prague,long_brno,lat_brno) / expected_km
1.405073704710646

This is apparently a known confusion. A coordinate specified as only a pair of numbers is ambiguous (for instance: both BoundingBox and the reference for the distance above use (long, lat), and the algorithm uses the ordering lat, long). When you come across the ambiguous format with an unfamiliar data source without a formal specification, you'll just have to sanity-check. Sites like Wikipedia will tell you unambiguously that Prague lies at "50°05′N 14°25′E" -- that is, very roughly, around 50 degrees latitude (north-south) and 14 degrees longitude (east-west).

svk
  • 5,854
  • 17
  • 22