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 '11 at 1:06
  • 1
    Maybe this thread can help "Better Distance Measurements in Web Mercator Projection" gis.stackexchange.com/questions/14528/… – underdark Dec 16 '11 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 '11 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 '11 at 9:29

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 '12 at 10:38
  • In essence the ratio of failure on Merc versus Real-World shouldn't be this high. – George Feb 3 '12 at 10:47

Your Answer

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

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