Hi Brian, Some further thoughts:
- In Chrome tiles are always showing up for me (although sometimes things that should be in bounds don't appear until I pan further, suggesting your bounding box may be slightly off). - You shouldn't need a separate KML file per zoom level and x / y. I suggest producing a single KMZ file for your entire map. If this is too large split it into two or four based files on Lat/Lng bounds and load all four once (when the map is loaded) rather than reloading on pan. The Maps API will simplify features as required. I'll give this a try in Firefox later tonight. Regards, James, Maps API Team 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.
