How to find distance and bearing between point A and point B?

May 9, 2013

Hello,

As a relatively new geocacher, I'm about to hide my first own cache. I want it to be interesting and ambitious enough, therefore I made it a mystery cache with a few stages.

Between one specific stage (let's call it A) and the next one (B ), I'd like to tell cachers to go to a position in X meters and Y ° (distance and bearing). In order to find the correct values, they'll have to answer a location-specific question in front of stage A. Thereby I'll make sure that they really go there and don't do the whole solving online at home.

Here's my question: Without using a protractor/L-shaped ruler, how can I measure the correct distance AND bearing between stage A and stage B? I have installed a few geocaching/map apps on my Android, and it seems that LocusPro is the most advanced one.

When setting the starting point on the map at stage A and asking LocusPro to navigate me using the compass, it will give me a distance and a bearing, but the bearing depends of my own orientation in front of stage A. I'd need an absolute value in degrees though, as I don't know in what direction I should point my smartphone when in front of stage A in order to let LocusPro find the correct value in degrees.

Shortly put, what's the best way to find distance and bearing between two points using a smartphone? Or should I better return to pencil, ruler and map?

Thanks a lot for any suggestions!

Alex

Edited May 9, 2013 by alexhager

7.8k · May 9, 2013

There are many websites that will do this. This one is one of the popular ones.

There's also FizzyCalc, which is a Windows program that does lots of conversions and measurements.

May 9, 2013

There are many websites that will do this. This one is one of the popular ones.

There's also FizzyCalc, which is a Windows program that does lots of conversions and measurements.

Thank you very much!

I'd have expected the so highly acclaimed LocusPro to offer such a calculation too, but in the end, I'm happy with any solution as long as it gets me the right values

Again, thanks!

Edited May 9, 2013 by alexhager

May 9, 2013

FizzyCalc!

"Distance" tab. Place the first location in "Point 1" and the goal location in "Point 2". You will be given the Distance and the Forward Azimuth (Bearing).

May 10, 2013

Thanks to both of you! Thanks to both solutions (website and software) I have found a "compromise" in distance and bearing that should get cachers close enough to my final. After all, the distance from the last waypoint should not be big enough to let minor errors result in important deviations.

Thanks!

May 10, 2013

I'd have expected the so highly acclaimed LocusPro to offer such a calculation too, but in the end, I'm happy with any solution as long as it gets me the right values

You expected right because LocusPro can give you distance and bearing; "Main menu/More/Add new route & measure" the route editor menus will appear

-Click on your starting POI and add it to the route (far left icon)

-Go to the next point and add it once you do this it will automagicaly show you the distance and bearing from point to point

I agree it's not the most intuitive way to measure but it works. The Locus developer Menion is very nice and you can make the suggestion to and a bearing/distance tool to the Geocaching Tools menu at Get Satisfaction

May 10, 2013

Thanks for your explanations, it's good to know that it works, even though it seems to be less intuitive indeed. I've already followed your suggestion to bring up the idea of a proper bearing/distance tool at Get Satisfaction. We'll see what they/Menion think.

Thanks, I appreciate your help!

Edited May 10, 2013 by alexhager

5.3k · May 11, 2013

Thanks to both of you! Thanks to both solutions (website and software) I have found a "compromise" in distance and bearing that should get cachers close enough to my final. After all, the distance from the last waypoint should not be big enough to let minor errors result in important deviations.

They give different answers?

They should not.

Fizzycalc gives the correct distance and bearing for the WGS-84 ellipsoid, which is what GPS units use. If the website does not give the same answer it is not using the WGS-84 ellipsoid.

Also, be sure you understand the difference between forward and reverse azimuth. Over a short distance, they are 180 degrees apart but over a longer distance they are not.

5.3k · May 11, 2013

oops. Inadvertent dupe.

I went to the Javascript page; there are a bunch of potential pitfalls there. Default coord format is DD MM SS.S, which is not what this site uses. Also, default distance is in nautical miles (nm) which are a lot longer than regular miles!

Edited May 11, 2013 by fizzymagic

May 11, 2013

Thank you, fizzymagic. I remember having used km as distance unit on the site. I am not familiar with the details of GPS mapping and the different systems or ellipsoids and their differences, I never disliked maths or physics, but never dug deeper into it than necessary either

I'm thankful that there are tools that do the thinking for me when it comes to calculations and your software seems to be very accurate indeed. I just checked the values I found using the projection tool in Locus and changed the values slightly so that the waymark Locus shows me is as close as possible to the actual final.

I'll see how easily cachers will find my final using the bearing and distance data from the last waypoint.

Thanks for having taken the time to answer, fizzymagic!

Edited May 11, 2013 by alexhager

2.7k · May 11, 2013

oops. Inadvertent dupe.

I went to the Javascript page; there are a bunch of potential pitfalls there. Default coord format is DD MM SS.S, which is not what this site uses. Also, default distance is in nautical miles (nm) which are a lot longer than regular miles!

Hi Fizzy

This is borderline to this topic, but since you are reading it... I have a question, but first some background. I think it was a horrible idea that GPS manufacturers decided to use HDD MM.mmm as the default coordinate format. It should have been HDD.ddddd

Since FizzyCalc is a Geocaching tool I understand why it does calculations in the HDD MM.mmm format. But if I want to string several projections together, accuracy is lost due to rounding (they are not actually errors). I see 3 possible solutions to address my concern.

1. The ability to set FizzyCalc to return more digits as HDD MM.mmmmmmmmm (without confusing newbie FC users?). Possible?

2 The ability to set FizzyCalc to also calculate in the HDD.ddddddddd format (again without confusing newbie FC users). Possible? This is the absolute best solution for me if this could be done, and you would be willing.

3 Someone direct me to a good downloadable calculator that works as well as FizzyCalc, but does all calculations in HDD.dddddddd format. I have been looking, but have not found what I want.

5.3k · May 12, 2013

Since FizzyCalc is a Geocaching tool I understand why it does calculations in the HDD MM.mmm format. But if I want to string several projections together, accuracy is lost due to rounding (they are not actually errors). I see 3 possible solutions to address my concern.

That's an interesting point you make; I just made the default output the same as geocaching.com's to make it easy for people to use. I don't think it would be difficult to make an option to have the output DD.dddddddd, DDD.dddddddd

Everything inside fizzycalc uses full floating-point double precision, which is usually good to 15 digits or so.

I'd probably go with 8 digits because, well, why not? It gives a precision of .02 mm, which is probably good enough for most any purpose in geocaching!

I'll see what I can do.

May 12, 2013

oops. Inadvertent dupe.

I went to the Javascript page; there are a bunch of potential pitfalls there. Default coord format is DD MM SS.S, which is not what this site uses. Also, default distance is in nautical miles (nm) which are a lot longer than regular miles!

Hi Fizzy

This is borderline to this topic, but since you are reading it... I have a question, but first some background. I think it was a horrible idea that GPS manufacturers decided to use HDD MM.mmm as the default coordinate format. It should have been HDD.ddddd

Since FizzyCalc is a Geocaching tool I understand why it does calculations in the HDD MM.mmm format. But if I want to string several projections together, accuracy is lost due to rounding (they are not actually errors). I see 3 possible solutions to address my concern.

1. The ability to set FizzyCalc to return more digits as HDD MM.mmmmmmmmm (without confusing newbie FC users?). Possible?

2 The ability to set FizzyCalc to also calculate in the HDD.ddddddddd format (again without confusing newbie FC users). Possible? This is the absolute best solution for me if this could be done, and you would be willing.

3 Someone direct me to a good downloadable calculator that works as well as FizzyCalc, but does all calculations in HDD.dddddddd format. I have been looking, but have not found what I want.

I think the GeoCache Calculator might have the features you're looking for - I was using it in the field the other day to get the distance between two caches and then to triangulate where a third cache was based on a schematic posted on the puzzle cache. I know the option to switch between coordinate formats is there and it definitely provides decimal places beyond three.

May 12, 2013

oops. Inadvertent dupe.

I went to the Javascript page; there are a bunch of potential pitfalls there. Default coord format is DD MM SS.S, which is not what this site uses. Also, default distance is in nautical miles (nm) which are a lot longer than regular miles!

Hi Fizzy

This is borderline to this topic, but since you are reading it... I have a question, but first some background. I think it was a horrible idea that GPS manufacturers decided to use HDD MM.mmm as the default coordinate format. It should have been HDD.ddddd

Since FizzyCalc is a Geocaching tool I understand why it does calculations in the HDD MM.mmm format. But if I want to string several projections together, accuracy is lost due to rounding (they are not actually errors). I see 3 possible solutions to address my concern.

1. The ability to set FizzyCalc to return more digits as HDD MM.mmmmmmmmm (without confusing newbie FC users?). Possible?

2 The ability to set FizzyCalc to also calculate in the HDD.ddddddddd format (again without confusing newbie FC users). Possible? This is the absolute best solution for me if this could be done, and you would be willing.

3 Someone direct me to a good downloadable calculator that works as well as FizzyCalc, but does all calculations in HDD.dddddddd format. I have been looking, but have not found what I want.

I think the GeoCache Calculator might have the features you're looking for - I was using it in the field the other day to get the distance between two caches and then to triangulate where a third cache was based on a schematic posted on the puzzle cache. I know the option to switch between coordinate formats is there and it definitely provides decimal places beyond three.

5.3k · May 12, 2013

2 The ability to set FizzyCalc to also calculate in the HDD.ddddddddd format (again without confusing newbie FC users). Possible? This is the absolute best solution for me if this could be done, and you would be willing.

Your wish is granted.

2.7k · May 12, 2013

2 The ability to set FizzyCalc to also calculate in the HDD.ddddddddd format (again without confusing newbie FC users). Possible? This is the absolute best solution for me if this could be done, and you would be willing.

Your wish is granted.

I nominate Fizzy for King of wish granters.

2.7k · May 13, 2013

Since FizzyCalc is a Geocaching tool I understand why it does calculations in the HDD MM.mmm format. But if I want to string several projections together, accuracy is lost due to rounding (they are not actually errors). I see 3 possible solutions to address my concern.

That's an interesting point you make; I just made the default output the same as geocaching.com's to make it easy for people to use. I don't think it would be difficult to make an option to have the output DD.dddddddd, DDD.dddddddd

Everything inside fizzycalc uses full floating-point double precision, which is usually good to 15 digits or so.

I'd probably go with 8 digits because, well, why not? It gives a precision of .02 mm, which is probably good enough for most any purpose in geocaching!

I'll see what I can do.

Well, one minute you are being nominated King, and the next your subjects are already nipping at your heels. I had occasionally noticed an odd behavior in FizzyCalc and just accepted that there was a reason for it. But now you say Everything inside fizzycalc uses full floating-point double precision, and now I wonder. Especially since the new functionality works perfectly where the old still falls a tiny bit short.

My example: PROJECTIONS

Point: N30 W70

Distance: 1 Foot

Bearing: 0, 90, 180, 270

DD.dddddddd Results:

30.00000275,-70.00000000

30.00000000,-69.99999684

29.99999725,-70.00000000

30.00000000,-70.00000316

DD MM.mmm Results:

N 30 00.000, W 70 00.000

N 29 60.000, W 69 60.000

N 29 60.000, W 70 00.000

DD MM SS.ss Results:

N 30 00 00.01, W 70 00 00.00

N 29 60 60.00, W 69 59 59.99

N 29 59 59.99, W 70 00 00.00

N 29 60 60.00, W 70 00 00.01

Something in the case of the RED results is not being converted perfectly. This is not new behavior, but the new DD.dddddddd output is perfect. The DD MM.mmm has been like this all along, and now the DD MM SS.ss has much the same problem. Is it, that's just the way it is, or oops I can fix that.

5.3k · May 13, 2013

DD MM.mmm Results:
N 30 00.000, W 70 00.000

N 29 60.000, W 69 60.000

N 29 60.000, W 70 00.000

N 29 60.000, W 70 00.000

DD MM SS.ss Results:

N 30 00 00.01, W 70 00 00.00

N 29 60 60.00, W 69 59 59.99

N 29 59 59.99, W 70 00 00.00

N 29 60 60.00, W 70 00 00.01

Something in the case of the RED results is not being converted perfectly.

Actually, the problem is that it is not being ROUNDED perfectly. I've known about this problem for some time. It only rears its head in edge cases, as you show.

There is a much worse algorithmic problem in there, still, when you try to do antipodal distances. But again, that is an edge case that very rarely appears.

I may try to fix it, though, now that you mention it.

5.3k · May 13, 2013

Well, one minute you are being nominated King, and the next your subjects are already nipping at your heels. I had occasionally noticed an odd behavior in FizzyCalc and just accepted that there was a reason for it. But now you say Everything inside fizzycalc uses full floating-point double precision, and now I wonder. Especially since the new functionality works perfectly where the old still falls a tiny bit short.

Once again, your wish becomes my command.

8.9k · May 15, 2013

Distance between ...

42.20872123451, -89.232123456 and

42.20872123450, -89.232123456

is 0.000001 m

Sounds right to me...

2.7k · May 15, 2013

Distance between ...

42.20872123451, -89.232123456 and

42.20872123450, -89.232123456

is 0.000001 m

Sounds right to me...

Seriously? You are providing a Distance example in the Format that I did note worked perfectly as a Projection example. I'll even give you the Meters instead of Feet, but thank goodness Fizzy actually read what I wrote. But would you like another mystery to explore? I would prefer if Fizzy could explain it to me though. He has done a fantastic job every time I point out a minor shortcoming. Just like he has already done twice just in this thread and once years ago.

On the COORD CONVERSION tab enter the Coordinate String: N40 W70 and click Go.

Notice the returned UTM: 19T E 414640 N 4428236

Now copy that same 19T E 414640 N 4428236 back to the Coordinate String box. Click go again.

Notice the returned UTM: 19S E 414640 N 4428236

Interesting. See the issue? (in RED again)

5.3k · May 15, 2013

On the COORD CONVERSION tab enter the Coordinate String: N40 W70 and click Go.

Notice the returned UTM: 19T E 414640 N 4428236

Now copy that same 19T E 414640 N 4428236 back to the Coordinate String box. Click go again.

Notice the returned UTM: 19S E 414640 N 4428236

Interesting. See the issue? (in RED again)

It's actually not an issue. Both coordinates are correct. The letter designation just is used as a shortcut to allow you to estimate the validity of distances; inside a zone is fine, between zones may raise a red flag. The letters are not used in determining the coordinates in the Northern Hemisphere.

The S zone is south of N 40 00.000 and the T zone is north of that line. But since you are pretty close to the E-W center of the zone, it doesn't make an appreciable difference.

A more interesting case would be at the eastern or Western edge of a UTM zone.

try these coordinates:

19S E 110119 N 4437762

Notice that the UTM shown in the conversion screen is:

18T E 622351 N 4428747

Both coordinates point to the same spot, although the top one is not normalized. But they are both "correct" in the sense that they point to a well-defined spot. Do you know why?

This kind of thing is the reason that I am not particularly a fan of using UTM coordinates for geocaching.

Edited May 15, 2013 by fizzymagic

1.8k · May 15, 2013

Some GPS units will project the distance for you. The easiest way is simply to mark the waypoint when you are setting up or verifying the locations and letting the GPS do the work for you.

How to find distance and bearing between point A and point B?

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation