《我是程序媛》之地图网格系统Grids，主要用来实现通勤找房的产品需求。

背景

• 给用户提供更好的找房产品，产品需求叫“通勤找房”：
  • 直线距离找房误差较大，效果差，app上原来有此方案但是已经下线；
  • 网站的写字楼找房只提供了固定的“x分钟路程”，没有结合交通方式；
  • 通过滑动条更改通勤时间，而不是固定时间；
  • 列表页的查询数据和地图找房数据差距较大；
  • 之后还有更复杂的场景化找房需求，例如：情侣找房需求等；
• 基于以上问题，有一些技术难点：
  • 实时计算x分钟之内到达某点的查询量大，计算多，性能较低；
  • 地球是椭圆的；
  • 结合调研了链家网、京东到家等实现方式；

目标

• 实现通勤找房的产品需求；
• 建设一个通用的栅格化路径搜索系统，满足全球化业务；
• 数据指标

  • Grids测距离的数据平均偏差±10%以内

    • 指标算法：出发地->目的地的百度测距：Grids的测距，抽查10%的数据；
    • 实现方式：可以通过缩小每个格子的精确度达到；

  • 业务数据平均偏差200米内

    • 楼盘上只有小区的坐标，没有楼栋坐标，较大的小区误差会大；
    • 调用地图拿到楼栋的坐标；
    • 产品驱动运营方去完善房源的楼栋精确坐标；

价值

• 实现通勤找房的用户需求，完成产品设定的目标和运营目标；
• 建设一个通用的栅格化路径搜索系统，全球化业务开展的开发周期降低80%（只需要跑业务数据，不需要开发）；
• 更多场景化的业务场景；比如：情侣找房、找附近的管家、找附近的师傅、就近派单等；
• 提供了社交场景的想象空间；
• bricks房源展示系统也借此开展；

核心方案

• 时间转换距离
  • 直接调用百度api拿到交通方式和距离的数据，不需要自己拿速度去算，给大众的感受较一致；
    （暂时不提供早晚高峰和实时的距离）
• 地图栅格化
  • 基于WEB墨卡托投影的原理，将地球平面化
    • 优点：最多可以精确到米；数据更直观友好；正方形；城市边界可以无限扩展，全球化的坐标；
    • 缺点：越接近两极放大越严重，所以我们只用它画格子，做简单的逻辑，不做实际距离测算；
      （市面上还有geohash，公式等）
  • 格子编号直接采用魔卡托坐标，格子编号为：魔卡托经度+魔卡托维度+格子米数

A格子编号	B格子编号	时间	时间
XY00500	AB00500	5min	500
AB00500	XY00500	10min	1000
XY00500	PQ00500	6min	567

• 格子和格子的距离索引（绿色部分）

  • 调用地图api计算距离
    计算的是每个格子的实际路径距离，而不是直线距离；
  • 提供三种精确度索引
    分别是 e1=200米，e2=500米，e3=1000米（先做500米的）；
  • 离线数据，定期更新
    每新开一个城市，需要提前建立索引；
    需要新城市的起始左下角L，K的坐标；

• 北京的数据大约需要跑7天，约千万级数据量；

• 房源和格子索引（红色部分）

  • 在基础研发部新的搜索平台上建立房源和格子的索引数据；

• 查询（紫色部分）

  • app获取到WGS84坐标，然后根据公示转换为web Mercator坐标
  • 所在格子的中心点精度坐标 = L+ int(（web Mercator经度坐标 - L坐标）/e2)*e2+e2/2，纬度同理，从而得到所在的格子编号（no）；
  • 查询网格间距离的索引得到所有的格子编号（格子s），查询条件：where B格子编号=no and 距离< 规定距离；
  • 查询房源网格索引，查询在这些格子（格子s）里的所有房源数据，给客户端返回；

• 数据流程图

围绕索引展开的数据流程图.png

• 应用架构图

• 存在的问题