JavaScript：维护边界的最佳方法（谷歌地图）？

Question

我使用的是 Google 地图 v3 API。目前，我正在请求每次有人更改视口（通过缩放或移动地图）时获取新数据，并丢弃我拥有的旧数据。这很好用，但现在我想缓存数据，这样我就不需要每次视口更改时都获取数据。 Google Maps API 通过由纬度和经度组成的东北和西南坐标定义视口。它们存储在名为 LatLngBounds 的对象中。

我想出了两种方法：

1. 存储用户访问的每个新视口的边界，检查新视口是否位于旧视口中，并仅获取新视口不在旧视口中的部分的新数据。旧视口。本质上，
2. 将每个新视口划分为我们拥有的数据和需要获取的数据的矩形部分。存储每个矩形部分的边界。

如果有人能想到更好的方法来做到这一点，请随时提出新方法。

我的问题是，就更好的性能/内存使用和整体速度而言，哪一个会更好？它们都是相似的算法，所以这真的很重要吗？

此外，现在两种算法都依赖于根据旧视口划分新视口。划分新视口的算法是什么样的？ （假设我实现了第二个算法）

var prevBounds = [ /* Array of previously seen bounds */ ];
var newViewport = map.getBounds(); // New Viewport to divide up
var sw = newViewport.getSouthWest();
var swlat = sw.lat();
var swlng = sw.lng();
var ne = newViewport.getNorthEast();
var nelat = ne.lat();
var nelng = ne.lng();
// newViewport.intersects(bounds) 
// Returns true if this bounds shares any points with this bounds.

Answer 1

我可能会考虑或多或少地以 Google 提供地图图块的方式进行此操作 - 不是立即加载整个视口的数据，而是将整个地图划分为方形区域（尽管可能比 Google 的 256x256 图块更大的区域），确定哪些区域位于当前视口中，并加载这些区域的数据。当用户平移和缩放地图时，检查视口边界以查看新区域是否已进入框架，并根据需要加载它们。粗略的伪代码：（

var cache = {}

function onViewportChange() {
    // get new bounds
    var bounds = map.getBounds();
    // identify all the areas in the bounds
    var areas = getAreas(bounds);
    areas.forEach(function(area) {
        if (area.key in cache) {
            // do nothing, or load items from cache
        } else {
            // load new data, storing the key (and maybe the data) 
            // to the cache
        }
    })
}

function getAreas(bounds) {
    /* given a set of bounds, return an array of objects like:
    [
        {
           x: 1,
           y: 2,
           zoom: 4,
           key: "4-1,2",
           bounds: b // lat/lon bounds of this area
        },
        ...
    ]
    */
}

请参阅 Google 对地图坐标的解释以及此示例了解如何实施getAreas。）

这样做的吸引力在于，您要检索的区域要简单得多，并且可以很容易地检查您是否已经加载了给定区域的数据 - 每个区域都可以有一个简单的唯一密钥，可能是由 x/y/缩放坐标组成的字符串，并且在加载每个新区域时，您保存密钥（或者可能是密钥和数据 - 这取决于您是否从区域中删除旧数据）映射或只是将其留在那里）到某个缓存对象。然后，当视口移动到新区域时，您所要做的就是检查缓存中是否存在该键。

缺点是您可能经常在当前视口之外加载数据，并且您向服务器发送的请求可能比您建议的实现更多。如果您在不同的缩放级别提供不同的数据，则此方法可能效果最佳 - 否则您可能会在尝试选择在不同缩放下运行良好的单一大小的缓存区域时陷入困境。