How to wait for metadata_changed event on large Kmllayer

[tallt]

Hi group - I have a large public KML file that the API v3 can't seem
to render using kmllayer on the first try. If I refresh my browser
window one or two times, then eventually I do get a metadata_changed
event and the layer finally displays.

When I watch the network panel via Firebug or Chrome, the first
kmllayer GET request is made, but seems to "hang up" after about 4
seconds, and no metadata_changed event is ever fired.

Refreshing the browser is a pain, so I've been trying to make multiple
kmllayer requests via code in an attempt to get the metadata_changed
event and to have the layer displayed.

This seems to work pretty reliably with Firefox, and sometimes with
IE, but almost never with Chrome.

Here's the simple app that I've written to test multiple kmllayer
requests:

http://timhaverland.s3.amazonaws.com/work/finss/kmllayersimpletest02.html

It makes a kmllayer request, then fires off a setTimeout function to
be run after 5 seconds. If the metadata_changed event is not received
by then, it makes another kmllayer request, waits again, and so on. I
stop this loop when 5 requests have been attempted.

Note that the KML url that I'm feeding to kmllayer has a timestamp
parameter on it so I can test without google caching my KML/rendered
tiles. This timestamp changes every 2 minutes. So you may have to wait
a couple of minutes to get the initial 4s timeout or "hangup" from
google.

One further note, when I feed my KML to maps.google.com, it always
seems to load the first time with no problems.

Thanks for any advice you may have,

Tim

[tallt]

Guess I should clarify what I'm asking:

1) Does anyone know why this does not work in Chrome (my biggest
concern)?
2) Anybody know a better way of waiting for a KML to be rendered ...
it's obvious after the initial call to kmllayer that Google is still
working on rendering my KML. Is there any way to keep my initial call
to kmllayer from timing out?

On Sep 9, 9:57 am, tallt <tim.haverl...@gmail.com> wrote:
> Hi group - I have a large public KML file that the API v3 can't seem
> to render using kmllayer on the first try. If I refresh my browser
> window one or two times, then eventually I do get a metadata_changed
> event and the layer finally displays.
>
> When I watch the network panel via Firebug or Chrome, the first
> kmllayer GET request is made, but seems to "hang up" after about 4
> seconds, and no metadata_changed event is ever fired.
>
> Refreshing the browser is a pain, so I've been trying to make multiple
> kmllayer requests via code in an attempt to get the metadata_changed
> event and to have the layer displayed.
>
> This seems to work pretty reliably with Firefox, and sometimes with
> IE, but almost never with Chrome.
>
> Here's the simple app that I've written to test multiple kmllayer
> requests:
>

> http://timhaverland.s3.amazonaws.com/work/finss/kmllayersimpletest02....

[tallt]

After some testing, it does appear that the webkit browsers (Chrome,
Safari) cache the response from calls to google.maps.KmlLayer (Firefox
appears not to), and will not go back to Google if you issue an
identical call to google.maps.KmlLayer. If you manually clear the
cache and make an identical KmlLayer request, Chrome/Safari will
actually send that request to Google.

This behavior is desirable if your KmlLayer request to Google was
successful (meaning you got the metadata_changed event and tiles were
returned to your browser). However, if Google was NOT able to process
your KmlLayer request within 4 seconds (not able to upload and render
your KML file due to size and complexity or your KML file and/or speed
of response of your server ... not due to the limits like overall size
of the KML file), then there's no way to issue that request again to
Google because the webkit browser will always go to the cache ... and
what's there is what appears to be nothing other than a dead-end call
to some callback function.

This dead-end cache response is unfortunate, because multiple
identical calls to KmlLayer WILL eventually return the
metadata_changed event and display the tiles. Google either continues
to work on your original request in the background, or repeated
requests to KmlLayer with the same URL will build parts of the map
tiles until they're all complete, at which point you get the
metadata_changed event.

Sure wish I could either:

1) Have Google send a status code other than "200 OK" when they can't
render your KML file within 4 seconds (like maybe code "202
Accepted"). Then perhaps when you issue the KmlLayer request again
using the same KML URL, then the browser will go back to Google rather
than the dead-end content in the cache.

2) Figure out how to have Chrome/Safari ignore the cache content. Thus
far I don't know of any way to do this.

Well, hope this "bump" inspires some thought out there. I realize that
my other option is to split my content up into pieces (not so easy
since in our production environment we're providing the KML data
dynamically). Perhaps I need to make a feature request to Google for
(1) above.

Tim

On Sep 9, 11:14 am, tallt <tim.haverl...@gmail.com> wrote:
> Guess I should clarify what I'm asking:
>
> 1) Does anyone know why this does not work in Chrome (my biggest
> concern)?
> 2) Anybody know a better way of waiting for a KML to be rendered ...
> it's obvious after the initial call to kmllayer that Google is still
> working on rendering my KML. Is there any way to keep my initial call
> to kmllayer from timing out?
>