KML hosted on Google Sites fails to display info balloons properly

[Joseph Elfelt]

Problem: KML info balloons fail to open or open and are empty
Seems to only affect KML files hosted on Google Sites.
I tested a KML file hosted on my server and it did not show this
problem.
BTW, Google recommends using Google Sites to host KML files.

Note: There is a time factor. Open an info balloon then leave the
map alone for 5 minutes. Now try to open a different balloon and you
should see the problem.

I made a small demo map as follows:

I copied Google's sample KML file and related html file.
I edited the KML file by adding 3 placemarks which each display the
default marker.
I included a short <description> for each marker.
I put that tweaked KML file on my Google Sites account:
https://sites.google.com/site/gmap4files/p/temp/cta.kml

I edited Google's html file to point to the KML file on Google Sites.

I'm on XP using FF9, IE8 and Chrome
Chrome seems to be OK,
The problem happens in FF9 and IE8.

Here is the demo map: http://www.mappingsupport.com/temp/kml_layer.html

I've been recommending for quite awhile that people use Google Sites
to host KML files and yesterday was the first complaint I received
form one of my users. Thus, I suspect something recently changed at
Google's end.

Can anyone else confirm or deny?

[geoco...@gmail.com]

I have been seeing issues with kml displayed by KmlLayer where is
stops responding over time. I have been seeing it with polygons
though on these maps:

http://www.geocodezip.com/v3_GoogleEx_layer-kml_us_states_simple.html
http://www.geocodezip.com/v3_GoogleEx_layer-kml_us_states_simpleA.html

I am seeing a lot of fetch errors and timeouts, and the click listener
seems to stop working over time. I'm not sure if it is related to
your issue or not. Have you tried using v3.6 to see if it is a
problem with the "nightly" version?

-- Larry

[geoco...@gmail.com]

On Feb 12, 9:05 am, "geocode...@gmail.com" <geocode...@gmail.com>
wrote:

behavior is definitely unreliable, just reloaded the map above,
clicked on texas, gave me "undefined" for the name and description
(reliably). Reloaded the map and texas worked as expected.

-- Larry

[Joseph Elfelt]

My production code (which can display KML files) is locked to 3.6
Someone using that code reported the problem to me.

[geoco...@gmail.com]

On Feb 12, 9:09 am, Joseph Elfelt <josephelf...@gmail.com> wrote:
> My production code (which can  display KML files) is locked to 3.6
> Someone using that code reported the problem to me.

Then it is conceivable that the problem is in the kml rendering code
(which seems to be somewhat common and not track API versions).

-- Larry

[geoco...@gmail.com]

On Feb 12, 9:09 am, "geocode...@gmail.com" <geocode...@gmail.com>

The map above seems to have a "hole" in the click area (a non-
clickable area near the bottom of Illinois on the IL/MO border)

-- Larry

[barryhunter]

I've seen this happen on Google Maps itself and in GGeoXml in v2. At
the time kmllayer from v3 seemed to be ok, but evidently it has also
broken now... :(

I'll make sure this thread is also brought to Googles attention.

[Chris Broadfoot]

Thanks all for the reports. Obviously this is quite hard to reproduce. Does this happen to any particular KML files, or on certain domains/hosts?

KML rendering is very susceptible to network problems, so its entirely possible these issues are a result of intermittent network problems rather than a change made to KML rendering.

Cheers
Chris

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[geoco...@gmail.com]

On Feb 12, 11:10 am, barryhunter <barrybhun...@gmail.com> wrote:
> I've seen this happen on Google Maps itself and in GGeoXml in v2. At
> the time kmllayer from v3 seemed to be ok, but evidently it has also
> broken now... :(

That seems to indicate it is in whatever the common code is that is
rendering the kml (since it happens on Google Maps, and on the Google
Maps API v2 and v3).

-- Larry

[Barry Hunter]

Here is one of the examples on Google Maps
https://groups.google.com/a/googleproductforums.com/forum/#!msg/maps/H3S1OG5FVew/XfnBJOHK_jsJ
- in that case its a self hosted file.

This:
https://groups.google.com/a/googleproductforums.com/forum/#!topic/earth/DV2Iu_fkfuo/discussion
is the V2 example - its actully using the KML gadget - but that is
using v2. Also using a sites hosted kml file.

At the time I replied to that file - I tried using a gadget ported to
use v3, and it didnt exhibit the same issue. It stuttered but didnt
break.

... from what I seen the 'iw' ajax endpoint starts returning invalid
data after a while. So it doesnt appear to be an issue between the
browser and Google Maps. Also by that time the KML has been fetched
from the server - it displays - and GMaps should have it cached - so
its shouldnt be an issue between the origin server and Gmaps. And it
happens consistantly for me - every time I view the affected urls. So
its not intermittant issue.

But that mention of cache - does hint at one possible cause. The cache
of the KML on Gmaps server has now expired, and so iw cant return any
data for it. I do note that Google Sites says the file shouldnt be
cached. No idea if that is new. (the self hosted one is a dynamic
script - and doesnt set caching headers)