# Calculate zoom level given lat long area (slippy map)

I am wanting to calculate the zoom level for a given lat/long area. I am using the OSM/GE slippy map "standard" tile system.

The post below answers my question but requires the viewing screen resolution and then it projects the lat/long bounding box using the mercator projection.

How to calculate the optimal zoom-level to display two or more points on a map

And the answer in this post says "it would be cleaner to define in meters"

Counting slippy map tiles

I dont understand why I would need to use the viewing resolution or bother to project the coordinates. Since I already know with the OSM/GE slippy map "standard" a single tile at level 0 covers 360 degrees in width(longitude). Each subsequent zoom level halves the previous longitude width:

at zoom level 0, a tile is the full width of the earth 360 degrees zoom level 1 = 2 a tile is 180 degrees zoom level 2 = 4 a tile is 90 degrees zoom level 3 = 8 a tile is 45 degrees zoom level 4 = 16 a tile is 22.5 degrees zoom level n = 2**(zoom level) a tile is 360 / 2**(zoom level) width in longitude

So for me to calculate the zoom level that would fit in a lat/long bounding box, I would just take the deltas of the bounding box and solve for the zoom level.

My calculation for zoom level is simply (in c#):

  var deltaLat = boundingBox.MaxLat - boundingBox.MinLat;
var deltaLong = boundingBox.MaxLong - boundingBox.MinLong;

var zoomLevelWidth = (int)Math.Floor(Math.Log(360.0d / deltaLong) / Math.Log(2));
var zoomLevelHeight = (int)Math.Floor(Math.Log(170.0 / deltaLat) / Math.Log(2));


What am I missing? Why is this not the answer?

The core misconception is the nature of the Spherical (Pseudo) Mercator projection, and the application of the Slippy Map tile grid on it.

Generally speaking[¹], given the (pseudo code) transformation (Lon/Lat to Spherical Mercator)

ERAD = 6378137.0   // Auxiliary Sphere equal axis radius in meter
D2R  = PI / 180.0  // Degrees to Radians multiplying factor

x = ERAD * <lon> * D2R
y = ERAD * Log( Tan( (PI * 0.25) + (<lat> * D2R * 0.5) ) )


the projection distorts the transformed latitudinal geographic extent (+/- 85.06°) to an equal length with the longitudinal geographic extent (+/- 180°).

The important part is that the distortion (exaggeration in all directions) increases by a (Mercator projection inherent) factor of 1.0 / Cos( <lat> * D2R ), so non-linearly with increasing latitudes - which, consequently, contradicts the binary subdivision in latitudinal direction of the equally spaced[²] Lat/Lon coordinates.

The second misconception is the actual zoom level, and the implication of pixel space.

Your (mathematically correct) calculations attempt to find the optimally (rounded) extent of a single tile for the given bounds; knowing that one tile is usually defined as having 256 * 256 pixels, you're going to be very disappointed when the returned image is stretched to fit your screen pixel dimensions...

You'd want to increase the zoom level for the tiles to fetch so that their tile count * pixels size equals or extents your (smaller axis) screen resolution.

[¹] there is much more to it, and this is a generalization for exemplary purposes; the relation between geographical and projected units is more complex, and the spherical model derives here from the more correct spheroidal Mercator projection

[²] equally spaced as in unit space (in degrees) - not to be confused with actual ground surface lengths.