地图点聚合优化方案

一、为什么需要点聚合

在地图上查询结果通常以标记点的形式展现,但是如果标记点较多,不仅会大大增加客户端的渲染时间,让客户端变得很卡,而且会让人产生密集恐惧症(图1)。为了解决这一问题,我们需要一种手段能在用户有限的可视区域范围内,利用最小的区域展示出最全面的信息,而又不产生重叠覆盖。

图1

二、已尝试的方案---kmeans

直觉上用聚类算法能较好达成我们目标,因此采用简单的kmeans聚类。根据客户端的请求,我们知道了客户端显示的范围,并到索引引擎里取出在此范围内的数据,并对这些数据进行kmeans聚类,最后将结果返回给客户端。

但是上线之后发现kmeans效果并不如意,主要有以下两个缺点。

a)性能问题

kmeans是计算密集型算法,需要迭代多次才能完成,而且每次迭代过程中都涉及到复杂的距离计算,比较消耗cpu。

我们在上线后遇到load较高的问题。

b)效果问题

kmeans未能彻底解决重叠覆盖问题!可以看到有些聚合后的图标会叠合在一起。

三、优化方案

再次回顾我们的目的:我们需要一种手段能在用户有限的可视区域范围内,利用最小的区域展示出最全面的信息,而又不产生重叠覆盖。

3.1. 直接网格法

解决地理空间相关问题时,对空间划分网格这种方法往往屡试不爽。

      原理:将地图范围划分成指定尺寸的正方形(每个缩放级别不同尺寸),然后将落在对应格子中的点聚合到该正方形中(正方形的中心),最终一个正方形内只显示一个中心点,并且点上显示该聚合点所包含的原始点的数量。

如何将点落到正方形内呢?我们将空间人为指定100*100大小,通过这个公式进行映射。

        优点:运算速度较快,每个原始点只需计算一次,没有复杂的距离计算。

        缺点:有时明明很相近的点,却仅仅因为网络的分界线而被逼分开在不同的聚合点中,此外,聚合点的位置采用的是该网格的中心,而非该网格的质心,这样聚合出来的点可能不能较精确反映原始点的信息。

3.2. 网格距离法

       原理:沿用方案一思想,1)将各个点落到相应正方形内;2)求解各个网格的质心;3)合并质心:判断各个质心是否在某一范围内,如果在某一范围内则进行合并。

如何判断各个质心点是否需要合并呢?以A点为例,画一个矩形或者圆范围,落在此范围内的合并,B、C均落在范围内,因此A、B、C三点合并。

         优点:运算速度同样较快,相对于方案一,多了求解质心以及质心合并两个步骤,但这两个步骤都较为简单,能很快完成。

3.3. 直接距离法

         原理:初始时没有任何已知聚合点,然后对每个点进行迭代,计算一个点的外包正方形,若此点的外包正方形与现有的聚合点的外包正方形不相交,则新建聚合点(这里不是计算点与点间的距离,而是计算一个点的外包正方形,正方形的变长由用户指定或程序设置一个默认值),若相交,则把该点聚合到该聚合点中,若点与多个已知的聚合点的外包正方形相交,则计算该点到到聚合点的距离,聚合到距离最近的聚合点中,如此循环,直到所有点都遍历完毕。每个缩放级别都重新遍历所有原始点要素。

         优点:运算速度相对较快,每个原始点只需计算一次,可能会有点与点距离计算,聚合点较精确的反映了所包含的原始点要素的位置信息。

         缺点:速度不如完全基于网格的速度快等,此法还有个缺点,就是各个点迭代顺序不同导致最终结果不同。因此涉及到制定迭代顺序的问题。

3.4. K-D树方法

这种方法需要结合PCA(主成分分析)和K-D树,在效果上比较好,但是性能较差,实现也较为复杂。(http://applidium.com/en/news/too_many_pins_on_your_map/)

参考文献

https://developers.google.com/maps/articles/toomanymarkers

http://applidium.com/en/news/too_many_pins_on_your_map/

基于百度地图的标记点聚合算法研究

在线地图的点聚合算法及现状

时间: 2024-10-12 09:20:18

地图点聚合优化方案的相关文章

Elasticsearch聚合优化 | 聚合速度提升5倍

https://blog.csdn.net/laoyang360/article/details/79253294 1.聚合为什么慢?大多数时候对单个字段的聚合查询还是非常快的, 但是当需要同时聚合多个字段时,就可能会产生大量的分组,最终结果就是占用 es 大量内存,从而导致 OOM 的情况发生. 实践应用发现,以下情况都会比较慢: 1)待聚合文档数比较多(千万.亿.十亿甚至更多): 2)聚合条件比较复杂(多重条件聚合): 3)全量聚合(翻页的场景用). 2.聚合优化方案探讨优化方案一:默认深度

分享详细网站SEO优化方案

下面分享详细网站SEO优化方案: 一.网站上线前准备阶段 1.域名选择 2.服务器及空间选择 3.网站类型选择:内容资讯型.商铺型.论坛型.文档分享下载型. 4.竞争对手调研分析 5.网站针对用户分析 6.程序选择 二.网站上线后SEO运营阶段 站内结构优化 合理规划站点结构(1.扁平化结构 2.辅助导航.面包屑导航.次导航) 内容页结构设置(最新文章.推荐文章.热门文章.增加相关性.方便自助根据链接抓取更多内容) 较快的加载速度 简洁的页面结构 1.站内SEO优化 ①关键词分析选择 ②网站框架

网站完整详细的SEO优化方案

一个完整的SEO优化方案主要由四个小组组成: 一.前端/页编人员 二.内容编辑人员 三.推广人员 四.数据分析人员 接下来,我们就对这四个小组分配工作. 首先,前端/页编人员主要负责站内优化,主要从四个方面入手: 第一个,站内结构优化 合理规划站点结构(1.扁平化结构 2.辅助导航.面包屑导航.次导航) 内容页结构设置(最新文章.推荐文章.热门文章.增加相关性.方便自助根据链接抓取更多内容) 较快的加载速度 简洁的页面结构 第二个,代码优化 Robot.txt 次导航 404页面设置.301重定

SEO网站优化方案

学习许多前辈的经验,看到一些比较有价值的seo优化方案,特记录一下,对照自己的操作之路,新人也可借鉴一二,下面是从卢松松博客看到的文章.高手直接跳过,请勿喷水. 一个完整的SEO优化方案主要由四个小组组成: 一.前端/页编人员 二.内容编辑人员 三.推广人员 四.数据分析人员 接下来,我们就对这四个小组分配工作. 首先,前端/页编人员主要负责站内优化,主要从四个方面入手: 第一个,站内结构优化 合理规划站点结构(1.扁平化结构 2.辅助导航.面包屑导航.次导航) 内容页结构设置(最新文章.推荐文

一个完整的SEO优化方案

一个完整的SEO优化方案主要由四个小组组成: 一.前端/页编人员 二.内容编辑人员 三.推广人员 四.数据分析人员 接下来,我们就对这四个小组分配工作. 首先,前端/页编人员主要负责站内优化,主要从四个方面入手: 第一个,站内结构优化 合理规划站点结构(1.扁平化结构 2.辅助导航.面包屑导航.次导航) 内容页结构设置(最新文章.推荐文章.热门文章.增加相关性.方便自助根据链接抓取更多内容) 较快的加载速度 简洁的页面结构 第二个,代码优化 Robot.txt 次导航 404页面设置.301重定

然后我就去网上搜索“如何写网站SEO优化方案

这段时间属于网站的策划阶段,网站的定位.网站的布局以及关键词的选定 首先,需要确定自己建设一个什么样的网站.,我们当然是企业网站,然后,确定网站的关键词,确定关键词可以参考自己的竞争对手,也可以通过关键词挖掘工具选择合适的关键词,选出的关键词一定符合用户的搜索习惯,并且有一定的搜索量.最好是能够有明确转化意向的关键词. 关键词确定后,需要设计网站的整体布局,比如说首页应该放置哪些板块,你的客户最关心的是哪些内容?最想了解的是哪些信息?,这时就需要对你的客户进行分析了,比如我们做的是工业品,客户比

前端性能优化方案索引

作者:HaoyCn 网址:http://segmentfault.com/a/1190000003821219 陆续整理和不断更新网络上给出的前端性能的优化方案. 这里只是做一个总概括式的索引,每一个方案都十分值得推敲和细说. 1 请求和响应 缓存控制 请求头里,可以发送 If-Modified-Since 以及 If-None-Match 等信息,来询问服务端请求内容是否有更新,如果没有更新,可返回304,告诉浏览器使用缓存,避免重新下载资源.Pragma 和 Cache-Control 等也

web前端优化方案(Yahoo)

目录(分7类,共35条): [内容]尽量减少HTTP请求数    [服务器]使用CDN(Content Delivery Network)    [服务器]添上Expires或者Cache-Control HTTP头    [服务器]Gzip组件    [css]把样式表放在顶部    [js]把脚本放在底部    [css]避免使用CSS表达式    [js, css]把JavaScript和CSS放到外面    [内容]减少DNS查找    [js, css]压缩JavaScript和CSS

H5性能优化方案

H5性能优化意义 对于一个H5的产品,功能无疑很重要,但是性能同样是用户体验中不可或缺的一环.原本H5的渲染性能就不及native的app,如果不把性能优化做起来,将极大地影响用户使用产品的积极性. 用户感受 当用户能够在1-2秒内打开H5页面,看到信息的展示,或者能够开始进行下一步的操作,用户会感觉速度还好,可以接受:而页面如果在2-5秒后才进入可用的状态,用户的耐心会逐渐丧失:而如果一个界面超过5秒甚至更久才能显示出来,这对用户来说基本是无法忍受的,也许有一部分用户会退出重新进入,但更多的用