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.
