The goal is working in EPSG 3785 and in particular Google Maps, one wishes to render (on a tile) a circle of a given radius in meters. The rendering is done in pixels.

I would guess that one could take a very simple linear approach to identify the meters per pixel for a given tile zoom:

metersPerPixel = MercWorldWidthMeters / (2 ^ zoom) / tileSize

Now, considering you wish to draw a radius of let's say 100 meters around a point in pixels, then you convert to pixels:

pixelRadius = metersRadius / metersPerPixel

This should in my mind produce a circle of metersRadius on the tile.

However, actually measuring the produced circle's radius with a circle produced in WGS 84 and Great Circle logic, it shows that it is actually about 40% smaller than expected... a big difference.

Does the logic above have a flaw?

Note that I am not interested in finding an alternative algorithm (going to Great Circle calculations and the like)... my question here is "why are the results (so much) different than expected".

All conversions this far have been working fine with the above logic but once I decided to calculate actual distance on EPSG 3785 I seem to be hitting a break wall.

To give an example with figures:

Radius: 0.08 miles ( = 128.74752 meters )
MercWorldWidthMeters: 20037508.342789 * 2
Zoom: 16
TileSize: 256

Above logic suggests a circle of ~107 pixels diameter.
Great Circle suggests a circle of ~175 pixels diameter.

  • Curvature of the earth? ;) rendering the radius of circular area on the surface of a sphere vs that of a radius of a 2-dimensional circle? Take the case where the circular area spans half of the earth (a hemisphere) the 2D radius would be r (the radius of the earth) whereas the one on a spherical surface would be pi*r. Just grasping at straws becuase time's almost up ;)
    – skeryl
    Dec 16, 2011 at 1:06
  • 1
    Maybe this thread can help "Better Distance Measurements in Web Mercator Projection" gis.stackexchange.com/questions/14528/…
    – underdark
    Dec 16, 2011 at 8:14
  • skeryl - I don't see how curvature can affect the radius at this scale. The error factor at this scale is very low to throw it so far off.
    – George
    Dec 22, 2011 at 9:25
  • underdark - +1 for a good reference. I think the answer from mkadunc attempts to answer it although I am still not convinced that is the reason.
    – George
    Dec 22, 2011 at 9:29

1 Answer 1


At any given zoom, pixels to real-world distance varies with Latitude. This is why you cannot use the following assumption:

 metersPerPixel = MercWorldWidthMeters / (2 ^ zoom) / tileSize

Note that if you are using Google Maps API, as suggested above, you can simply create a Circle with whatever radius (in meters) you want, and it will draw it appropriately. If you draw some circles near the equator and some near the poles, you will see the difference in pixel size quite easily.

For more robust algorithms and the concepts behind them you may be interested to read http://www.movable-type.co.uk/scripts/latlong.html. In addition you may be interested in the geometry library (http://code.google.com/apis/maps/documentation/javascript/geometry.html#Distance)

  • Thank you for that, however I must ask. If Merc projection uses meters for defining positions on the globe, why it not define distance? I am obviously missing something here. I understand quite well the effect of latitude growth/shrink and earth radius, but taking that away on a project based on meters, a distance in meters "should" be represented correctly and match the distance between two points (on the project - not necessarily in real-world)
    – George
    Feb 3, 2012 at 10:38
  • In essence the ratio of failure on Merc versus Real-World shouldn't be this high.
    – George
    Feb 3, 2012 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.