OpenLayers 支持 KML 中的详细级别答案

【问题标题】：OpenLayers support for Level of Details in KMLOpenLayers 支持 KML 中的详细级别
【发布时间】：2014-05-16 18:10:54
【问题描述】：

OpenLayers 是否支持基于 Level of Details 标签 (<Lod/>) 切换区域的可见性？据我研究和尝试，参考文献中提到的示例 KML 均不适用于 OpenLayers/Google 地图。您可能还对similar question regarding LoD in gmaps 感兴趣，这表明没有人关心关于细节支持的级别，因此有以下问题：

有没有人发现任何活生生的证据表明细节水平实际上一直有效？
如果没有，有没有人知道如何使用 KML 区域，如果它们仍然会一次全部加载到浏览器中？
如果仍然没有 - 您知道使用 KML 以智能且高效的方式加载大量功能 (>100000) 的问题的解决方法吗？或者，对于某些自定义实现，例如放大/缩小事件处理和手动切换功能的可见性，是否应该放弃“官方支持”的解决方案？

【问题讨论】：

我猜想您可视化如此大量特征的最佳解决方案是根据您的数据创建地图图块（如果需要，还可以使用 UTFGrids 进行交互）

标签： performance openlayers kml region level-of-detail

【解决方案1】：

Open Layers 不支持 KML 中的详细程度。正如您将注意到的，在某些功能之上，性能是可怕的——这不是 OpenLayers 的失败，而是现有的浏览器渲染和 DOM 遍历问题。 webGL 的出现无疑将大大改善这一点。

OpenLayers 有一种称为集群策略的东西来解决这个问题，根据您设置的各种参数，当您缩小时点会聚集在一起：请参阅http://openlayers.org/dev/examples/strategy-cluster.html 使渲染速度更快。

如果您可以更好地控制数据的来源，您可以在服务器端制作不同的图层并将它们作为单独的矢量图层加载到 OpenLayers 中，但使用不同的 maxResolution 级别来控制它们是否被绘制。

正如 sfletche 所建议的，您还可以将 kml 预渲染为不同缩放级别的图块或创建 wms，以便在服务器端完成工作，最终得到一个光栅。如果您确实需要在客户端查询这些功能，这种方法对您没有多大帮助。

在不了解您的设置和使用要求的情况下，很难提出可靠的建议。

【讨论】：

感谢您的澄清。关于设置和使用要求 - 用例是，项目是交互式的，并且在单击/悬停后它们的外观可能会改变。此外，地图的地图键应该是交互式的 - 图层的顺序可能会改变。
我需要看看使用 UTFGrid 进行客户端事件处理的服务器端层渲染，也许这是一个很好的方向。也许聚类也可以用来隐藏特定的特征（在我们的用例中对它们进行分组没有意义）。
最后，就浏览器性能而言——不仅渲染时间是瓶颈，图层数据下载时间也是如此。所以更好的渲染器策略只能部分解决这个问题——我猜 OpenLayers 仍然通过 NetworkLinks 将所有区域递归地加载到 DOM，而不管它们的细节级别或 LonLatAltBox ——这可能会扼杀用户体验，因为有多个这样的层有数千个特征。集群数据也是如此。 看来，没有最终好的解决方案这样的事情。
@zdanowiczkonrad 是的，这肯定是网络制图仍然存在的问题——与大量多边形/线特征交互。如果您不介意将数据加载到 Postgres/Postgis 之类的空间数据库中，您可以尝试的另一个选项是使用线泛化函数在某个缩放级别简化特征，然后在人们缩放时重新加载更高级别的细节在使用网络工作者或一些内置的 OL 功能时。看看 OpenLayers3 中的 webGL 如何改进矢量渲染将会很有趣。