Do you mean that you want the zoom control to be limited to a certain set of zoom 
levels?

If that is not what is meant, then I support the need for that.

Weird, i recall adding more info to this but somehow i guess my comment was lost :p

Anyway, what i meant is that it would be nice to have a way to tell the API to dissalow to ability for the user to 
go over and below certain zoom ranges, that way, avoiding the "no imagery" thing when zooming too much.
I know this can be done via JS events, but it just would be nice to have it right in the API as a parameter.
That is what i meant.

// Diego.

I agree, while it can be done using events it would be a very nice to have this
feature built in.  It would make it much easier for people to port over v2
applications to v3.

+1 for this feature. I had my map set up for this in v2 but can't figure it out in v3. 
Topherthegopher, can you point me to a page that shows how to do this with JS events in  
v3? Can't find anything on it...

It's as simple as listening for zoom_changed on the map object

// Limit the zoom to a minimum of 3
google.maps.event.addListener(map, 'zoom_changed', function()
{
    if (map.getZoom() < 3){
       alert("You cannot zoom out any further");
       map.setZoom(3);
    }
});

Thanks

It would be nice to have a min/max zoon.

Very often its eay to miss the "zoom out arrow", and click the bar to view the whole 
world. really annoying.

Besides the justification being to replicate v2 functionality, are there other
practicial reasons why max and min zoom levels would be beneficial?  From what I can
tell, the only visible difference would be to shorten or elongate the Zoom Control
bar based on min/max, but I'm not sure how important this is.

Because one can easily click just "above" the "zoom" down arrow, thereby making it max 
out level === the whole WORLD * 2.

Its a pain to have to zoom back in to a forgotten level.

There is definitely a justification for this feature because the application my team
is working on requires a maximum zoomed out level of 3. When the user tries to zoom
out beyond that, I reset the zoom level to 3 and create a warning to the user about
not trying to zoom out again. This works well to prevent the user from zooming out
when they are manually controlling it. However, it does not work well when the
application tries to zoom out too far. When many 'footprints' are displayed on the
map (as polygons), the application tries to zoom out and pan to fit them all onto the
viewing area (fit bounds). This causes the alert to pop up every single time someone
tries to view footprints that are too far apart to fit on the map. This is a definite
problem. If the map had a maximum level to which it could be zoomed out, the map
wouldn't try to zoom out any further and wouldn't cause an error to pop up every time
someone turned the footprints on or off, which is something that happens very
frequently in our application.

Without the min/max zoom levels our application cannot use the default navigation
control style.  We want to display both zoom and pan controls on the map, but without
the min/max zoom levels being reflected in the zoom control it adds extra checks when
the zoom level is changed and confusion to users.

An alternative to adding the min/max zoom levels could be a navigation control style
where the pan control is present as well as the + and - zoom buttons.

topher, use the zoom_changed listener above to limit zoom levels, then you can set
the navigation control to only be the pan control with a +/- sign.

Actually I do not see one built in.

https://code.google.com/apis/maps/documentation/v3/reference.html#NavigationControlStyle

SMALL is zoom only
ZOOM_PAN has a zoom slider, which does not properly reflect the zoom levels we want
to limit

We have custom controls taking care of this now, but it adds more listeners to an
application that has a bunch of listeners as it is.  Would just be nice for it to be
taken care of automatically.

The alternate example I am talking about is:
http://search.missouristate.edu/map/mobile/examples/ZoomPanControl.htm.  But again,
something specifically built into Google Maps would be ideal.

I shouldn't have to be listening to see if a user tries to zoom out so far, it should
be handled by the map controls itself.

(No comment was entered for this change.)

Hello,

I have one solution.
You can change the zoom limit of any map types.

-----------------------
google.maps.event.addListenerOnce(map, "bounds_changed", function() {
  var mapTypes = map.mapTypes;
  var roadmap = mapTypes.get(google.maps.MapTypeId.ROADMAP);
  roadmap.minZoom = 3;
  roadmap.maxZoom = 10;
});

(No comment was entered for this change.)

(No comment was entered for this change.)

Will the V2 functionality of getMaxZoomAtLatLng be replicated in V3? That is my biggest upgrade problem.

A feature that would allow it to make sure, theres is valid image data would be great.
Having both, the max and the min zoom levels for a given region seems in some situations very necessary.
I recognized, that at the moment, 404 errors are thrown when no images are available. It sould be nice to get these errors in order ro react to them.
Whichever way, having a google maps image with dozens of "no image available" "images" is surely worth being avoided. 

I need there to be a way to check if there are images available at a certain zoom level in order to upgrade from v2. 

What I need is what comments 19-21 reffer to, the getMaxZoomAtLatLng functionality.  Stranhe that it does not exist, or does it?

Yes, read the documentation here:
https://code.google.com/apis/maps/documentation/javascript/services.html#MaxZoom

(No comment was entered for this change.)

https://code.google.com/apis/maps/documentation/javascript/services.html#MaxZoom
Please note:
Right now You have to switch to the English version of this page if You don't find this section (for example it's not translated in German version) 

For some reason, setting a minZoom, and trying to zoom out while being there, will call .redraw() method of overlayviews but won't call zoom_change.

So we can't handle properly our overlayViews.