KML layer sometimes displaying; sometimes not

[Edward Sargisson]

Hi,
I'm developing a database driven KML file which is loaded into the
KMLLayer.

Sometimes the layer displays and sometimes it doesn't.

Research showed that the content type might be important so that is
set to application/vnd.google-earth.kml+xml.

The KML file works in Google Earth and appears to be correct. It is
generated with the de.micromata.opengis.kml library.

I am using my development machine from home. I have configured my
router to allow traffic from the outside on the specific port my
server is on. The IP address is found using Dynamic DNS.

Any clues for determing the cause of this?

It sort of appears that Google is caching the KML and won't display
until it has actually cached the KML.

Many thanks in advance for any comments.

Cheers,
Edward

[Pil]

Without a link to your map - which should be open for the public
anyway - it remains guesswork.

Check pitfall #2 in this example of Mike Williams v2 tutorial.

http://econym.org.uk/gmap/kml.htm

or search the group's archive for bogus parameter or something
similar.

[Rossko]

> It sort of appears that Google is caching the KML

That's what KmlLayer does, there are ways around that if you search
this group.

> and won't display
> until it has actually cached the KML.

If you mean it takes some time for your KML to be read, because it is
slow to generate or the uplink is slow or whatever, yes Google's
KmlLayer appears to enforce agressive timeouts and will terminate the
process. Some have mentioned 4 seconds before.

[Mike Dolbow]

I use the 'metadata_changed' event on the KMLLayer inside a listener so I can tie the document load-up to the KML load. That way if the KML gets hung up, the document shows a throbber and I know I have to either wait or re-load.

[Edward Sargisson]

Hi all,
Thanks for the replies.

I am coming to the conclusion that the KmlLayer cannot be trusted to
reliably display - and that I can see no reliable workaround. Is
anybody confident that the KmlLayer is reliable?

At this point I am considering using individual encoded polylines. The
panning experience for the user is slower but at least the map should
display reliably.

Tiim Haverland at [1] and [2] claims that WebKit browsers cache the
results of the KmlLayer call - *even if the call failed*. This means
that retrying will not work in WebKit browsers. I have repeated his
results with Chrome and Safari. This was with a path which was
dynamic. It was set when a page loaded and retries would continue on
the same path. I had the file cached in memory and my logging showed
it was served within 3s.

An alternative approach would be to use the same filename and rely on
Google's servers caching the result. I don't like this because:
1. It becomes more difficult to protect my content. The dynamic
filename method added a level of difficulty to taking the content.
2. If the first request comes from a WebKit browser then that may fail
for that user - an no retrying will help.

Alternatively, I could cache yet more aggresively using a content
delivery network.

Thanks,
Edward

Links:
[1] http://code.google.com/p/gmaps-api-issues/issues/detail?id=3617
[2] http://groups.google.com/group/google-maps-js-api-v3/browse_thread/thread/ead45965777fc6a7/37a68c1ef29baa5c?lnk=raot

[Joseph Elfelt]

I put a timer in my app so it now displays an error message if it
appears that Google has timed out waiting for a KML file.
You can try your KML file with my beta code:

http://www.mappingsupport.com/p/beta/gmap4_817.php?q=http://url_to_your_online_kml_file