The Android API allows for images to be superimposed onto a map. To do so, the developer specifies a set of lat/long coordinates for an "anchor point" within the image, the width (or height) of the image in meters, and "bearing" value by which the image will be rotated before it is superimposed. More info here:


Instead of an anchor point + width + bearing what I have instead is an image and two points of reference inside it, with coordinates for each. So, for example, I might have a 1000 x 1000 pixel image and know that pixel (100,100) corresponds to coordinates (X,Y) and that pixel (600,600) corresponds to (X',Y').

What I'm unclear on is how to correctly calculate the anchor point, bearing and "width" values to plug into the Android maps API such that (100,100) in my image appears at (X,Y) on the map and (600,600) in my image appears at (X',Y') on the map. Found this page:


with info on how to calculate the distance between two points and both starting and ending bearing. Using the distance formula I can calculate the actual physical distance between my two points of reference. Using basic geometry I can calculate the "pixel distance" between the two points in my image. Taken together, this should give me a conversion factor between pixels and meters, so I should be able to calculate the "width" of the image. Is that right?

But any "flat" image is going to be a projection of some sort, though, so I'm worried that this method of computing "width" won't be entirely accurate. If that inaccuracy is small then I can live with it. The actual physical size of the images I'm planning to overlay shouldn't be more than 20 miles x 20 miles max.

Then there's the issue of "bearing". I can compute the forward azimuth between (X,Y) and (X',Y') and I can compute the angle between (100,100) and (600,600) in my image. If I choose (X,Y) as my anchor and then subtract the latter angle from the former angle then that should give me the amount by which my image needs to be rotated before being its superimposed onto the map. Right?

Again, though, I'm worried about curvature issues. Is that a legitimate concern given I'm only talking about (approximately) 20 x 20 mile overlay images?

  • Yes, if there is a difference in projection between your images and the underlying google image then you will have curvature issues. You need to project your image into the same coordinate system and then it's straight maths to work out the hook point, width and height. A good image projection utility is GDALwarp gdal.org/gdalwarp.html – Michael Stimson Aug 31 '14 at 22:06
  • I see two challenges. 1. I don't know what projection Google Maps uses. 2. I don't know what projection the image will use since its created on the fly. My "use case" is a hiker who wants to see himself as a "dot" moving around on a trail map. He snaps a photo of a trail map and associates his current position with a point in the photo. He then begins his hike and, when he gets to the first intersection of trails, associates those coordinates with a second point in the photo. I had hoped this would be enough info for me to correctly superimpose the photo onto Google Maps. – jph Sep 1 '14 at 0:35
  • Considering you don't know where (exactly X,Y,Z) the camera will be, the orientation and pitch that's a big ask! You could apply a basic affine transformation to it and it should be good enough, the maths aren't too difficult - two points of correlation to place and subsequent points to determine accuracy. A phones' GPS unit is only good to a few metres but should be good enough for estimation overlay. – Michael Stimson Sep 1 '14 at 0:41
  • Gah. I'm such a newbie, you might as well be speaking Greek. At least I have some words to google. I was going to assume that the camera was positioned orthogonally to the surface of the map. That's not a crazy assumption; usually the trail maps are posted vertically on a kiosk type structure. The user would just stand in front of the map and move backward or forward until it fills the camera's preview screen, then snap the photo. I have to think Android's maps API applies some sort of transformation for you since it claims to map your flat image onto its existing map surface. – jph Sep 1 '14 at 0:56
  • 1
    It's a good idea, especially if you've not been there before. Some reference is better than no reference - so long as it's correct. I would try harder to get the already georeferenced trail map before I went rather than rely on it being posted near the entrance. – Michael Stimson Sep 1 '14 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.