Caching Imagery Basemap Services
Scale Matching and Overzooming Done Right
TL;DR: Match your cache scale to your imagery resolution using a simple formula, set maxScale to 0 at every level, and stop building cache tiles your pixels can’t justify. There. Saved you four minutes
That said, if you’d like the full story—including the math, the gotchas, and the part where I explain why your imagery won’t zoom in even though it clearly should—please continue.
Imagery basemaps provide critical context for a ton of GIS workflows, but building one that performs well requires a little more effort than simply publishing a service. Two things will make or break your imagery service: caching at the right scale and configuring overzoom so your users don’t hit a dead end when they try to get a closer look.
Get the scale wrong and you’re either burning storage on tiles that add zero detail, or leaving usable resolution on the table. Get the scale right but skip the overzoom config, and you’ll still have users trying to zoom in even further (even though the map is turning into a blurry mess with every click).
The good news is that all this is fixable. Let’s start with scale.
Tip #1: Match Your Cache Scale to the Imagery Resolution
Caching an image service generates tiles at predefined scale levels. Those scales determine how far users can zoom and how detailed the imagery appears. So far, so good.
The trap is building the cache deeper than the imagery supports. And I get it — it’s tempting. “More detail” sounds like a good thing. But past a certain point, you’re not getting more detail. You’re just making bigger, blurrier tiles and burning through storage like it’s free. (Dear reader, it is not free.)
Here’s the relationship between imagery resolution and optimal map scale:
Map Scale = Raster Resolution (in meters) × 2000
I know. Formulas. But this one is straightforward once you understand how it applies to your imagery.
Let’s say you have 1-inch imagery from 2024. Using the formula above, we can calculate the optimal scale level to cache our imagery.
- Imagery resolution = 1 inch (each pixel represents 1 inch on the ground)
- 1 inch = 0.0254 meters
- 0.0254 x 2 x 1000 = 50.8
That’s your optimal scale. That’s where you should be caching.
Now here’s where tiling schemes come into play. In the Web Mercator tiling scheme, the largest predefined scale level is 70.53. That’s close enough to justify building the cache down to that level for 1-inch imagery.
However, if you’re using a State Plane tiling scheme, your scale stops might be different. Just make sure you’re matching the right scheme to the right numbers, or this whole exercise is academic.
The key takeaway: only build the cache down to the scale that matches the resolution of your imagery. Going deeper doesn’t magically create pixels that weren’t captured in the original imagery. It just creates larger tiles and longer processing times for absolutely no visual benefit.
Recommended Resolution-to-Scale Reference (Web Mercator)
Below is a handy reference table you can include in your caching workflow.
| Imagery Resolution | Resolution (meters) | Optimal Scale (Approximate) | Closest Web Mercator Scale |
| 12 in (1 ft) | 0.3048 | 609.6 | 564.25 |
| 6 in | 0.1524 | 304.8 | 282.12 |
| 3 in | 0.0762 | 152.4 | 141.06 |
| 1 in | 0.0254 | 50.8 | 70.53 |
These numbers will keep your cache aligned with the actual usable detail in the imagery.
If the imagery is 3 inches, stopping at 141.06 makes sense. If it’s 1 inch, going to 70.53 is justified. Going deeper than that? All it does is increase storage and processing load. Skip it.
Tip #2: Enable Overzooming in Field Maps and Other Clients
Now let’s talk about a separate but related frustration … er, concept.
You’ve built your cache correctly. You’ve matched scale to resolution. Everything looks great. And then a field user pinches to zoom just a little further and the map just … stops.
That’s a missing overzoom configuration. It’s one of the most common “why won’t this work” calls you’ll get.
Overzoom allows the client to stretch the highest resolution cached tile beyond its native scale. It does not increase detail — it just prevents dead ends. Basically, it’s the map saying “I don’t have more pixels, but I’ll let you keep zooming if you don’t mind things getting a little blurry.“
The catch is that overzoom can be blocked at three different levels, and if any one of them says no, the answer is no.
The Three Places Scale Restrictions Exist (a.k.a. The Three Places Things Go Wrong)
1 – Service Level (ArcGIS Server)
At the service’s REST endpoint, you’ll see:
“minScale”: 0,
“maxScale”: 0
2 – Web Map Level (Item JSON / Map Viewer)
{
“id”: “Imagery”,
“url”: “…/MapServer”,
“minScale”: 0,
“maxScale”: 0
}
Even if the service allows deeper zooming, the web map can still clamp it. This is one of the most common causes of “why won’t this zoom in?“
3 – App / Viewer Level (Field Maps, JS API)
The application itself may define zoom constraints. For example, in the JS API:
constraints: {
maxScale: 0
}
If the app defines a maxScale, it overrides everything upstream. You could have the service and the web map wide open, and the app can still slam the door shut.
Overzoom Configuration Checklist
When it’s 4:30 on a Friday and someone asks why the imagery won’t zoom, run through this:
- Service maxScale = 0 (Service level)
- Web map layer maxScale = 0 (Web Map Level)
- App constraints allow deeper zoom (App Level)
- Cache built to the appropriate finest level
If any one of those enforces a restriction, overzoom is dead.
Final Takeaways
Imagery basemap performance isn’t just about running the caching tools and calling it a day. It’s about making smart decisions before you start:
- Match your cache scale to imagery resolution (use the formula, save yourself grief).
- Skip the deep scale levels your pixels can’t justify. Your storage budget will thank you.
- Allow overzoom where field workflows demand it.
- Remove scale clamps at the service, web map, and app levels. Check all three because it’s always the one you assumed was okay.
Get it right, and your cached imagery becomes efficient, predictable, and flexible across every application. Get it wrong, and you’ll be troubleshooting zoom complaints until the end of time. Or until someone reads this blog post and fixes it in ten minutes.
Keegan Powers
Cultivate Geospatial Solutions, LLC
