GGeoXml.getTileLayerOverlay() is deprecated as of version 2.141, due
to the fact that our rendering system has changed and it no longer
makes sense to return a TileLayerOverlay.

We do not expect this to significantly affect developer's code, since
this function was never guaranteed to return an object across all
browsers, and so developers would not have relied on it.

The API reference will be updated to reflect the deprecation soon:
http://code.google.com/apis/maps/documentation/reference.html#GGeoXml...

- pamela

On Jan 28, 2:01 am, pamela fox <pamela....@gmail.com> wrote:

Cacheable tiles are a big performance plus.  What determines whether
MAPSLT, previously MAPSDT, will be used ?  Can anything be added to
the KML file to force it to be used ?  Can an option be added to
GGeoXML to force it to be used ?

Also, the ability to specify colors on the fly rather than in the KML
file might be nice.

Thanks Pamela.

Issue 761

    http://code.google.com/p/gmaps-api-issues/issues/detail?id=761

addresses some of the same concerns.

The use of GPolyline / GPolygon makes sense for interactive poly
editing.  Without handles to the objects produced by GGeoXML, GPoly
offers no benefit with a lot of extra overhead.  Without cacheability,
identical GPolys have to be regenerated during every session by every
user.  Perhaps MAPSLT / MAPSDT ought to be the default.
maps.google.com always uses tiles to display KML files for improved
performance.

Hi bratliff-

We will still be using tiles behind the scene for many KML overlays,
but the implementation is different and it's no longer feasible to
easily give access to the GTileLayerOverlay associated with the tiles.

- pamela

On Jan 30, 2:45 am, bratliff <bratl...@umich.edu> wrote: