在Solr中基于空间地址查询主要围绕2个概念实现: 算法
Cartesian Tiers 笛卡尔层 编码
Cartesian Tiers是经过将一个平面地图的根据设定的层次数,将每层的分解成若干个网格,以下图所示: 索引
每层以2的评方递增,因此第一层为4个网格,第二层为16 个,因此整个地图的经纬度将在每层的网格中体现: 图片
笛卡尔层在Lucene中对空间地理位置查询最大的用处在查找周边地址的时候有效的减小查询量,即将查询量能够控制在分层后最小的网格中的若干docId。那么如何构建这样的索引结构呢,其实很简单,只须要对应笛卡尔层的层数来构建域便可。也便是tiers0->field_0,tiers1->field_1,tiers2-field_2,……,tiers19->field_19。(通常20层便可)。每一个对应笛卡尔层次的域将根据当前这条记录的经纬度经过笛卡尔算法计算出归属于当前层的网格,而后将gridId(网格惟一标示)以term的方式存入索引。这样每条记录关于笛卡尔0-19的域将都会有一个gridId对应起来。可是查询的时候通常是须要查周边的地址,那么可能周边的范围超过一个网格的范围,那么实际操做过程是根据经纬度和一个距离肯定出须要涉及查询的从19-0(从高往低查,留给读者思考)若干层对应的若干网格的数据(关于代码实如今后面的文章内容阐述)。那么一个经纬度周边地址的查询只须要以下图圆圈内的数据: 字符串
因此经过这样的数据过滤,将极大的减小计算量。 get
GeoHash算法 hash
在Lucene索引中将经纬度的二维坐标经过geohash,变成一个一维的字符串base32的坐标,例如,经纬度对应一个base32的坐标为DRT2Y,那这个base32的字符串什么意思呢?其实编码中每一个字符都是表明一个区域,而且前面的字符是后面字符的父区域,即R是D区域内的子区域,T又为D区域的子区域,你们能够从以下图片得到base32的层级关系(如下图片均来自互联网): file
进入D区域,则看到又分为若干区域,而R为其子区域: 互联网
继续进入R区域,能够继续看到有子区域T区域: grid
而2Y也是基于以上的关系类推,因此一个base32的编码是标示一个区域,而编码过程当中会根据经纬度的精度来肯定这个区域大小。从上面的解释你们确定会想到编码的前缀是表示更大的区域。例如wx4g0ec1,它的前缀wx4g0e表示包含编码wx4g0ec1在内的更大区域。因此根据这个特色,利用模糊查询是能够达到一种附近地点的查询。
Geohash算法实现其实很是简单,网上有不少例子,在这里借用下这些例子再加上比较详细的说明。基本算法流程是基于多轮的收敛,以达到知足精度要求为止。具体流程以(39.92324 纬度, 116.3906 经度)为例,首先将纬度的范围(-90, 90)平分红两个区间(-90, 0)、(0, 90),若是目标纬度位在(-90,0),则编码为0,在(0,90)则编码为1。因为上面的例子中维度39.92324是属于(0, 90),因此第一轮得到的编码位取1。接下来再将(0, 90)分红 (0, 45), (45, 90)两个区间,而39.92324位于(0, 45),因此编码为0。以此类推,直到精度符合要求为止,以下图所示:
因此经过16轮的计算后获得经度39.92324的编码为:1011 1000 1100 0111 1001
经度也用一样的算法,对(-180, 180)多轮的依次细分计算:
获得经度116.3906的编码为1101 0010 1100 0100 0100
经纬度的编码都计算完毕后,接下来就须要合并经纬度的编码,规则是以经度开始,依次每次取一位合并成5位的新编码,如上图红色字标示顺序所示:
完成合并编码后就须要将该编码和base32编码表对应起来,作法是每5位为一个十进制数,以11100为例,它的十进制数是28,因此对应的base32编码表示W,以下图所示:
其余的五位编码依次从表中找到对应位置后,(39.92324 纬度, 116.3906 经度)的base32编码为:wx4g0ec1
解码算法与编码算法相反,先进行base32解码,而后分离出经纬度,最后根据二进制编码对经纬度范围进行细分便可,这里再也不赘述。不过因为geohash表示的是区间,编码越长越精确,但不可能解码出彻底一致的地址