应用错误收集

显然，你不能真的显示“140万点”。这对计算机来说非常麻烦，对用户来说也是如此。

看着这个显示，我猜他们可能会将属性（在他们的SQL数据库中）分组为“社区”，为每个“社区”建立一个（lat，lng）并定义（也在他们的SQL数据库）那时的圆形标记。毫无疑问，他们还预先计算了在该标记下计算的属性数量。

他们接下来要做的就是在这些圆形标记之间建立一个层次结构。在较低（较远）的缩放级别，某些标记将不再出现，和它们将显示不同的（较大的......）计数，这可能只是“冒泡” “来自<em>（现在，不再显示......）标记”正好位于它们之下。

换句话说：每个Leaflet缩放级别都有自己独特的标记集，所有标记都是由主机预先计算的。当[Leaflet ...]地图放大或缩小时，标记图层的内容将被替换为适合该缩放级别的一组新标记。

计算所有这些数据，并将其存储在适当的SQL数据库结构中，将是在主机上定期运行的适度脚本或存储过程的工作。

在最高（最近......）放大级别，客户端可能会要求主机提供属于实际可见的（lat，lng）边界内的各个属性的列表在用户的显示器上......加上一些余量。如果用户将地图滚动到其他地方，那么（在短暂停顿后确保地图不再移动......）主机将被要求发送另一组属性点。

但关键的一点是“要求展示[宣传单张”的点总数永远不会“无法管理”。这是实际可以看到的一组圆圈，加上一些边距，每个圆圈代表最多当显示最终归结为“单个属性”时，点列表中唯一的那些是“附近的，加上一些边缘”。