Google Maps Max Zoom Level

[Malcolm Lozada]

TheGoogle Maps API provides map tiles at various zoom levels for map type imagery. Most roadmap imagery is available from zoom levels 0 to 18, for example. Satellite imagery varies more widely as this imagery is not generated, but directly photographed.

Accessing the MaxZoomService is asynchronous, since the Google Maps API needs to make a call to an external server. For that reason, you need to pass a callback method to execute upon completion of the request. This callback method should process the result.

The following example shows a map of metropolitan Tokyo. Clicking anywhere on the map indicates the maximum zoom level at that location. (Zoom levels around Tokyo generally vary between zoom levels 18 and 21.)

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

A zoom level determines how much of the world is visible on a map. Mapbox provides maps in 23 zoom levels, with 0 being the lowest zoom level (fully zoomed out) and 22 being the highest (fully zoomed in). At low zoom levels, a small set of map tiles covers a large geographical area. At higher zoom levels, a larger number of tiles cover a smaller geographical area.

Map tiles are stored in a quadtree data structure. At zoom level 0, you can see a map of the whole Earth, and this image is contained in a single tile. At zoom level 1, the single tile you saw at zoom level 0 splits into exactly four tiles so the whole world fits in a 2x2 tile square. Each zoom level quadtree divides the tiles of the one before it, which creates a grid of 2zoomx2zoom. The highest zoom level, 22, is a 222x222 grid.

Libraries based on Mapbox GL display 512x512 pixel tiles by default, while many other mapping libraries use 256x256 pixel tiles. The only Mapbox product that work with 256x256 pixel tiles by default is the Mapbox Raster Tiles API. If you're working with Mapbox GL JS but would like to display 256x256 pixel tiles, you can also specify that individual Mapbox sources are 256x256 pixel tiles in your map's source definition or by ensuring the source's TileJSON is correct.

While a 512x512 tile and a 256x256 tile cover the same geographic area at any given zoom level, they will appear differently when displayed by Mapbox GL JS versus a traditional tiled map. In Mapbox GL JS, all tiles are offset by one zoom level. This means that when a Mapbox GL JS map is zoomed to zoom level 2, it will display the same geographic area as a traditional tiled map zoomed to zoom level 1. Because of this zoom offset, the appearance of a Mapbox GL JS map at zoom level 1 is the same as the appearance of a traditional tiled map at zoom level 2.

Determining the geographical distance covered by an individual pixel in a map depends on the latitude you are looking at. This table lists the approximate geographical distance in meters per pixel for each zoom level, at different latitudes. Many modern devices have displays with a pixel density that is much higher than the images they display, and they apply special transformations to make images look good. For this reason, it is important to note that the values below apply to the pixels in the map tile rather than the pixels on your screen.

These numbers are based on 512x512 pixel tiles, which are displayed in Mapbox GL-based map clients. The per-pixel value will be different for tiles served by the Mapbox Raster Tiles API, which are 256x256 pixels by default. To determine the per-pixel value for 256x256 tiles, take the zoom level you're interested in and look at the row above it.

Azure Maps use the Spherical Mercator projection coordinate system (EPSG:3857). A projection is the mathematical model used to transform the spherical globe into a flat map. The Spherical Mercator projection stretches the map at the poles to create a square map. This projection significantly distorts the scale and area of the map but has two important properties that outweigh this distortion:

To optimize the performance of map retrieval and display, the map is divided into square tiles. The Azure Maps SDK's use tiles that have a size of 512 x 512 pixels for road maps, and smaller 256 x 256 pixels for satellite imagery. Azure Maps provides raster and vector tiles for 23 zoom levels, numbered 0 through 22. At zoom level 0, the entire world fits on a single tile:

Having chosen the projection and scale to use at each zoom level, we can convert geographic coordinates into pixel coordinates. The full pixel width and height of a map image of the world for a particular zoom level is calculated as:

The latitude and longitude values are assumed to be on the WGS 84 datum. Even though Azure Maps uses a spherical projection, it's important to convert all geographic coordinates into a common datum. WGS 84 is the selected datum. The longitude value is assumed to range from -180 degrees to +180 degrees, and the latitude value must be clipped to range from -85.05112878 to 85.05112878. Adhering to these values avoids a singularity at the poles, and it ensures that the projected map is a squared shape.

When determining which zoom level to use, remember each location is in a fixed position on its tile. As a result, the number of tiles needed to display a given expanse of territory is dependent on the specific placement of zoom grid on the world map. For instance, if there are two points 900 meters apart, it may only take three tiles to display a route between them at zoom level 17. However, if the western point is on the right of its tile, and the eastern point on the left of its tile, it may take four tiles:

Some mapping platforms use a quadkey indexing naming convention that combines the tile ZY coordinates into a one-dimension string called quadtree keys or quadkeys for short. Each quadkey uniquely identifies a single tile at a particular level of detail, and it can be used as a key in common database B-tree indexes. The Azure Maps SDKs support the overlaying of tile layers that use quadkey naming convention in addition to other naming conventions as documented in the Add a tile layer document.

To convert tile coordinates into a quadkey, the bits of the Y and X coordinates are interleaved, and the result is interpreted as a base-4 number (with leading zeros maintained) and converted into a string. For instance, given tile XY coordinates of (3, 5) at level 3, the quadkey is determined as follows:

Qquadkeys have several interesting properties. First, the length of a quadkey (the number of digits) equals the zoom level of the corresponding tile. Second, the quadkey of any tile starts with the quadkey of its parent tile (the containing tile at the previous level). As shown in the following example, tile 2 is the parent of tiles 20 through 23:

Finally, quadkeys provide a one-dimensional index key that usually preserves the proximity of tiles in XY space. In other words, two tiles that have nearby XY coordinates usually have quadkeys that are relatively close together. This is important for optimizing database performance, because neighboring tiles are often requested in groups, and it's desirable to keep those tiles on the same disk blocks, in order to minimize the number of disk reads.

We upgraded to Portal 10.9.1 last week and I am having issues with the use of the new map viewer and having a limited zoom in capability. Most maps are unable to zoom past a certain level in the Viewer and in Dashboards.

This seems to be for existing maps that I have saved with old map viewer and new map viewer. I have been working on updating and saving these maps in new map viewer, but some were made in old map viewer. Also working through saving Dashboards into the new dashboards version that reads from new map viewer.

I have seen the new map viewer exhibit this behavior with WMTS layers. It seems to default to a max LOD of 18. We've gotten around this by either moving to vector tile basemaps when possible, or manually defining the max LOD in the WMTS layer's JSON.

We do use a blank custom basemap. I am looking into this. It is an old ArcMap raster layer that I believe was not tiled in to a close extent...where the basemap stops seems to maybe correlate to where the tiling stopped?

Once you get it uploaded, if you share it and create a web map with it also shared to the Featured Maps or whatever group you use as your basemap group in the Map settings in Portal Settings. Then it should show up in your basemap gallery to change your maps over to.

I would like to determine how to a convert specific map scale to the closest zoom scale used by the major web mapping players. For example, I want to open a web map to whatever predefined scale is closest to 1:100,000 or whatever cached scale is closest. How do I calculate the zoom level knowing that this is the established breakdown, and that the answer that I'm looking for is 10?:

Ah ha! I found the key to the answer by applying some google-foo, wine, and much confused panic recall of algebra i thought i would never use. I'll post the answer so I become rich and famous, as all GIS old guys should do.

At this discussion on Google Groups I discovered that basically when you do a fitBounds, the zoom happens asynchronously so you need to capture the zoom and bounds change event. The code in the final post worked for me with a small modification... as it stands it stops you zooming greater than 15 completely, so used the idea from the fourth post to have a flag set to only do it the first time.

In my case, I simply wanted to set the zoom level to one less than what google maps chose for me during fitBounds. The purpose was to use fitBounds, but also ensure no markers were under any map tools, etc.

When using 'bounds_changed' without the check in place, the map zoomed out once for every marker regardless of whether it needed it or not. Conversely, when I used 'zoom_changed', I would sometimes have markers under map tools because the zoom didn't actually change. Now it is always triggered, but the check ensures that it only zooms out once and only when needed.

3a8082e126