什么是LBS数据库

架构的话有很多尝试，传统的Oracle和 Postgre用的比较广泛, 很多架构在此基础上同时应用 NoSQL。因为大多数LBS并不涉及更复杂的空间数据存储，例如多边形或者三维数据，因此，大多数generic的数据库架构都可以应用。

但是，从产品核心的设计以及发展来看，如果像FourSquare(4SQ)进行数据挖掘并提供收费的数据分析服务，那么基于空间的利用文件数据结构，以空间POI为基础的NoSQL，是比较好的选择。除了其他人介绍的很多LBS，比如街旁和4SQ，应用的Mongo DB， 还有Couch DB, 根据之前来讲课的澳洲政府的一个大型空间数据库项目(集成了多种现有的空间数据库)的构架师介绍，这个项目应用了Couch DB。虽然理论上Graphic的NoSQL对于存储空间数据也有很大优势，但是毕竟相对不成熟，所以实际应用中的NoSQL还是以doc结构的Mongo和Couch为主。

既然说到定位，就先做个小科普，目前，主流的手机定位方式大致分为三类：

1. GPS定位

2. 基站定位

3. 混合定位（也有叫wifi定位）

GPS定位，顾名思义通过手机中的GPS模块获取位置，优点是精度高，信息全，不仅能获取经纬度，还能包括海拔高度，方向角度等信息，在户外尤其是开阔地（平原）精度高，多用于骑行、运动等app（类骑记、乐动力等）和车载导航系统上；缺点也比较明显，强依赖GPS卫星信号，在室内和城市楼宇密集的地区单纯的GPS定位要么失败，要么漂移，大的漂移甚至会达到1km以上。

基站定位，优点，依靠运营商的电信基站（2g、3g、4g等）进行定位，由于不涉及到额外的硬件消耗因此功耗最低，并且通过算法和基站数据的丰富能够提供比较理想的定位精度；缺点是对运营商基站数据的分布密集程度依赖强，在基站密集的地区可以提供较理想的定位精度（500米左右），但如果基站分布分散的地区，精度会大幅度下降，而且目前专业的定位服务提供商（高德、百度）所使用的基站数据都是通过自己采集或购买的方式获取，覆盖密度和数据量都不如运营商（电信、联通、移动）自己的数据。目前运营商提供的定位服务多以该方式实现。

混合定位，目前移动端app采用最多的定位方式，通过整合基站和wifi的数据进行用户位置的确认，我们知道，每个wifi后面都可能对应一个到多个无线设备（路由器），每个设备都有一个唯一标识（MAC地址），定位服务提供商通过采集和采购的方式获取到定位地区的wifi覆盖数据，包括所有的wifi名称、硬件地址以及实际位置存储到自己的定位库中，作为基础数据，当设备发起定位请求时，提供设备所在的基站信息和周围的wifi信息，就可以获取精确的位置了。该方式结合了基站定位的低功耗特点，同时由于wifi数据的介入，大大弥补了单纯基站定位的精度不足的问题。缺点是，对服务提供商的wifi数据和基站数据库的丰富度有强需求，数据越丰富，精度越高。

介绍完了定位方式，我们再来看看手机app中的定位，上面说过，多数的LBS应用的定位方式都采用混合定位的方式，也就是说，获取wifi和基站的信息是获取高精度的必备条件。尽管混合定位能够覆盖大多数的使用场景，但是一些不确定因素会影响定位的精度。比如在室内会影响GPS的定位，而一些大型活动所需的临时性移动基站也会影响到基站定位的准确性，另外如果路由器的位置发生了变化，而wifi数据库中的位置没有及时更新，那么就很可能导致wifi定位错误。

如果希望尽可能的提高手机应用的定位精度，可以试试看打开手机自身的GPS定位，另外开启WiFi开关（无需连接到WiFi）也能够提升定位的准确度。

---