Google地图KML加载 - 414请求URI太大 [英] Google Maps KML Loading - 414 Request URI too large

问题描述

我目前正在建立一个Google Maps项目，该项目将根据用户输入动态加载和卸载各种KMZ文件。它可以很好地适用于大约8层的加载/卸载，但是随后Google Maps发生414错误。我将问题追溯到API生成的存储字符串中，以引用每个KML层。

I am currently building a Google Maps project that will dynamically load and unload various KMZ files based on user input. It works fine for roughly 8 layer loads/unloads, but then Google Maps breaks down with the 414 error. I've traced the problem down to the stored string the API is generating to refer to each KML layer.

以下是单击图层时运行的代码：

Here's the code that runs when a layer is clicked:

function showLayer(layername) {
  if (layers[layername].kml === undefined) {
    layers[layername].kml = loadKML(layers[layername].file, layers[layername].options);
  }
  layers[layername].kml.setMap(map);
  redrawRoutes(layers[layername].kml);
}

和loadKML函数：

And the loadKML function:

function loadKML(file, options) {
  var path = kmlDir + file;
  options = options || { preserveViewport: true };
  layer = new google.maps.KmlLayer(path, options);
  return layer;
}

基本上我的目标是只加载一次KML文件，将它存储在对象，并在随后的加载/卸载中引用它。这里的问题是，在JavaScript对象内 new google.maps.KmlLayer 生成一个很长的字符串

Basically my goal is to only load each KML file once, store it in an object, and just reference that on subsequent loads/unloads. The problem here is that inside the Javascript Object that new google.maps.KmlLayer generates, a big long string

"kml:cj5TNh3iqySpI_DAGiDgbSJESQ-dakZTiMY09US6imjvFNPMTIIYNAg|ks:;dc:cg;ts:44610546|kv:3|api:3"

并每次将其附加到请求URI。这会相当快速地加起来，并且在7-8附加之后，URI太长，任何后续的请求都会被忽略。

and appends this to the request URI each time. This adds up rather quickly, and after 7-8 appends the URI is too long and any subsequent requests are ignored.

有没有办法使用这个长请求字符串，我可以强制它使用自定义字符串，或每次只清除URI？我只会处理大约6个文件，我真的希望能够处理尽可能多的图层加载/卸载。

Is there a way around using this long request string, can I force it to use a custom string, or just clear the URI each time? I will only be dealing with ~6 total files, and I'd really like to be able to handle as many layer loads/unloads as possible.

推荐答案

您正试图优化Google已有的功能。 Google缓存的KML文件及其关联的图块，因此销毁和重新创建图层的惩罚很小。只要KML图层的网址保持不变，就应该销毁并重新创建该图层。

You are trying to optimize what Google already has. Google cache's KML files and their associated tiles so there is very little penalty for destroying and recreating layers. As long as the url to the KML layer stays constant, you should just destroy then recreate the layer.

无论地图上当前有多少个KML文件，Google都会呈现他们作为一个单一的瓷砖覆盖。每次您通过setMap添加/删除KML图层时，您的用户都必须下载新的图像。

Regardless of the number of KML files currently on the map, Google renders them as a single tile overlay. Your users have to download new tile images everytime you add/remove KML layers via setMap.

您的KML文件每隔几小时才会被访问一次。据推测，Google试图将为该请求发布的缓存标头授予KML文件。但是，并没有明确定义Google在缓存标头丢失时缓存KML的时间。

Your KML file will only be accessed once every few hours. Supposedly, Google attempts to honor the cache headers issued for the request to the KML file. However, it's not specifically defined how long Google will cache your KML when strong cache headers are missing.

谷歌还规定了最小缓存时间，以便即使您要通过您的KML文件在1分钟后应该过期的强大缓存标头，Google仍会缓存该文件的预设时间（以及未公开）。标准解决方法是为KML url添加额外的查询字符串参数，以便生成一个先前未被缓存的新/唯一地址。

Google also imposes minimum caching times so that even if you were to specify via strong cache headers that your KML file should expire after 1 minute, Google would still cache the file for it's preset (and undisclosed) time. The standard workaround is to add extra querystring parameters to the KML url in order to generate a new/unique address that hasn't been previously cached.

这篇关于Google地图KML加载 - 414请求URI太大的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！