IssueTracker

Just found the same problem

Absolutely agree...I'm asking for the same implementation!

is there any news about custom map types ?

Hi Pamela,

May we bug the team with the following questions:

1. Is it planned at all?
2. If "yes", how deep in the queue is it?

It would be very nice if someone from the team could share their plans on this topic.
 Any feedback is greatly appreciated.

This is a necessity for one of my projects. I'm delaying v2 development in
anticipation of v3 support for this feature. Any definite yes or no on this?

We are also delaying migrating to v3 until this feature is implemented.

same here. correct me if I'm wrong but you (google team) were planning on
implementing support for custom maps from the beginning, as it's one of the main map
class functionalities of v2.x and you said, you are going to implement all of v2.x
functionalities. so it is just a question of time, isn't?

waiting here, too
guess those requests concern same topic
http://code.google.com/p/gmaps-api-issues/issues/detail?id=1831&q=label%3AApiType-Javascript3&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Stars%20ApiType%20Internal
and
http://code.google.com/p/gmaps-api-issues/issues/detail?id=1402&q=label%3AApiType-Javascript3&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Stars%20ApiType%20Internal
merging them together probably will rate it higher (34 stars)? ;)

same here:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=1871&q=label%3AApiType-Javascript3&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Stars%20ApiType%20Internal
-> 36 stars

I'm looking forward to this change as well, because we need this for our project and
I like the v3 API so far except that missing feature.

Waiting for some word on this too.  (Started redundant feature request 1930 when I
didn't find this thread sooner.)  GTileLayerOverlay is supported as a Mapserver
output method since 5.2 and it is very fast in API v2 with caching.  We really need
this in API v3 ASAP!!  

There must be a major issue with this or we would have heard something by now.  I
think maybe this is a fundamental bandwidth issue with mobile devices trying to load
all the tiles a desktop would at full size and trying to scale down in the client
device to small screens (s-l-o-w)?  Maybe there needs to be a resolution control
implemented at the server.

I have added some "Sparse Tile Layer Overlay" examples:

    http://www.polyarc.us/sparse
    http://www.polyarc.us/road
    http://www.polyarc.us/rail

The "height" & "width" & "bbox" values expected by mapserver are available to the
"setUrl" method.  The traditional "x" & "y" & "z" tile values are also available to
the "setUrl" method.

    xy.x = tile X offset
    xy.y = tile Y offset
    xy.X = tile width
    xy.Y = tile height
    xy.x0 = begin longitude
    xy.y0 = begin latitude
    xy.x1 = end longitude
    xy.y1 = end latitude

A single "Sparse Tile Layer Overlay" can handle multiple tile sets without redundant
OverlayViews, each requiring its own event listeners.

Apologies for the late update.  This is fixed in the release which went live last week.
http://code.google.com/p/gmaps-api-issues/wiki/JavascriptMapsAPIv3Changelog