关于百度地图的思考

[macoal]

2016年9月20日00:17:11

项目要定位服务，原本是调用系统自身gps设置，获取当前坐标信息并通过接口获取相关数据。但由于gps不能很好的响应，譬如有某种情况下gps内部有缓存暂时无法获取、没有gps卫星信号下无法定位等。故尝试通过百度地图定位服务解决问题。

项目原本服务是调用gps获取坐标，每5s或位置改变时会获取到坐标信息。由于是gps定位，故整个定位过程大多数并不涉及到流量的损耗。但比譬如：进入地铁后，没有gps信号，此时弊端就显现出来。留意百度等地图应用依旧可以使用，网络信号也很稳定，进而尝试通过百度地图定位sdk来解决这类问题。

1. 基站定位漂移量大：进电梯后还一度漂移到非洲，瞬间定不到位的情况；
2. 基站定位漂移量小：这种情况定位都有发生，gps可以根据返回值中的精准度和速度进行判断，尽可能少的发生漂移问题；基站返回值中没有这类参数，只发现 getRadius 方法好似定位精度，并发现 getLocationWhere 方法获得当前是在国内还是国外（ps：getCountry 并不好用，有时候会返回 null ）。
3. 流量问题：gps并不会使用流量，但倘若一直使用基站定位，流量的消耗是不得不考虑的。（ps：或者只有在刚载入时和gps无星时切换基站定位，有WiFi时则使用WiFi定位？）
4. 做了一个小实验，思路是：通过判断当前点和前一个点之间距离和前一个点与前前个点之间距离的比，倘若太大则说明漂移的厉害，倘若很小则说明漂移的不是很厉害。条件是每10s请求一次定位。（ps：做实验时忘记一个问题，那就是正常的定位是不是也算进漂移不是很厉害的情况？这样的话点和点之间只有大于100m的时候才会记录点。哈哈）
5. 实际的效果是：点和点之间距离会变长，短距离的线不会画出来，会被过滤掉；全程基站定位，地铁中也可以画出来点和点之间的线了，怀疑是否请求频率太低，定位并不是太准，而且在地铁里由于速度很快，点和点之间的漂移也随之变大；目前来说整体还符合预期。

   目前的结论和思考

   结果还算相对符合预期，呈现效果有了相对提升，也解决了问题。同时还有很大的优化空间，请求定位频率是否合适等等。

开个脑洞：有没有可能定位频率不写死，通过判断上一距离和当前距离的比来预估下一个距离和当前距离的最优时间差；或者频率写死了，动态的控制限制漂移量的大小，将精度提高。

2016年9月20日00:59:55