I tried adding the following (to the actual KMZ files being requested,
not the sample):
header("Pragma: public");
header("Cache-Control: maxage=21600, public");
header('Expires: ' . gmdate('D, d M Y H:i:s', time() + 21600) . '
GMT');
It did cause the tiles to cache more. Unfortunately tiles that were
empty were now always empty. At least without the caching you could
reload and retry.
It seems like the Google servers are sending back partially rendered
or empty tiles, perhaps because a timeout is being reached. Firefox
is the worst for empty tiles, and Safari seems the best (tiles will
load after 3 or 4 seconds, by which time FF has given up and stays
empty).
Thanks for your help. I hope a solution is found, because my whole
site depends on it.
I'm going to look into Fusion Tables for the things that change
infrequently. Maybe then I could use geoxml3 for the rest.
Thanks,
Brian
On Feb 9, 4:45 pm, James McGill <[email protected]> wrote:
> Hi Brian,
>
> I don't see any explicit cache headers on sample.kmz. Try allowing public
> caching with an explicit cache time of 6 hours. I suspect that this will
> help with missing tiles.
>
> You could also try using Fusion Tables and uploading your data via the API.
>
> Regards,
> James
>
> On Thu, Feb 10, 2011 at 10:05 AM, Brian <[email protected]> wrote:
> > The KmlLayer link is different based on the markers they have checked,
> > the zoom level, and the bounds of the viewport.
>
> > The site has over 8,000 miles of ATV trails (for the state of Utah,
> > more to come), so having static KML files is out of the question.
>
> > Nothing is there to prevent caching of the same querystring, and if
> > you're looking at the same area, same zoom, and same options the
> > querystring will be the same (the lat/long of the bound are rounded to
> > two decimal places to increase the likelihood of being cached).
>
> > I have 4 levels of simplification stored in the database for each
> > polyline, and serve up the right one based on zoom level (so when
> > you're zoomed out you get a very simplified line, and when you zoom
> > way in you get all the detail).
>
> > I tested out geoxml3 and it works great on my Mac, but on my PC it
> > chokes on the bigger files. And zipping them to KMZ makes a huge
> > difference (a 120K KMZ file is 800K as a KML file, but I think its
> > probably gzip'd before being sent).
>
> > So unless I find a way to optimize geoxml3 I may be stuck with having
> > everything rendered on Google's servers. I wish I knew why some of
> > the tiles aren't loading or are partially loading.
>
> > Thanks!
> > Brian
>
> > On Feb 9, 2:32 pm, Chad Killingsworth
> > <[email protected]> wrote:
> > > It looks like your KmlLayer links contain a querystring parameter that
> > > changes on every request (presumably to prevent caching). Do your trails
> > > actually change that much that you would need that? I can understand for
> > > testing, but once it was stable keeping a static link to the Kmz would
> > have
> > > massively helped your response times as Google's server would not have to
> > > re-render your data on every request.
>
> > > Chad Killingsworth
>
> > --
> > 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
> > [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/google-maps-js-api-v3?hl=en.
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
