Hi Brian, I note that your website is window.console.logging URLs that appear to be KMZ files, such as:
http://www.freeatvmaps.com/includes/output.php?a=37.34&b=-112.59&c=37.67&d=-112.03&e=11&f=44702 Running wget on this gives the following: HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Thu, 10 Feb 2011 01:40:31 GMT Server: Apache X-Powered-By: PHP/5.3.2-1ubuntu4.7 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Length: 508 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/vnd.google-earth.kmz This looks like it still has very strict no-cache headers (and Expires is well in the past). Regards, James On Thu, Feb 10, 2011 at 11:48 AM, Brian <[email protected]> wrote: > > 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. > -- 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.
