主题：【原创】大纵深的移动位置业务 -- 邓侃
家园 谢谢答复，有空深入交流下 手头上也算有点LBS的资源，不过现在实在是不敢进这个行业啊，觉得风险太高，收益很不明确。
不过看着又有点眼馋。唉
家园 请教 国内道路建设发展相对于国外来说，有的时候太快呢，数据更新是否能及时，不太清楚邮编是否有很规范的标准，以达到可以准确定位。
- 复 请教
家园 邮编是没指望的 数据更新是个大问题。某些GPS导航系统公司都用大学生拿GPS扫街标点的方式来更新数据了。
邮编很粗糙的，根本没指望。
- 复 邮编是没指望的
家园 那国内的GPS是通过什么定位的呢 我知道我所处的国家是通过多种方式，主要是邮编定位，输入邮编，门牌号，然后计算出行车时间，最短路线等等
家园 邮编可以作为缩小范围的工具，但是在中国还是没有什么用 原因很简单，绝大部分人不记得邮编，在查询的时候只会输入地名，不会输入邮编的。
既然不是一个索引量，那么基本上没有什么用处
家园 刚才想了一下，发现我的回复有误 高mm的问题是，曾经输入地址，某GPS设备说找不到。
这个把地址转化成GPS设备能求路的功能，叫做Address Capture（地址捕捉？）
高mm怀疑是因为道路经常建设，导致自己邮编记错之类的自己的错误。
实际上，一个好的产品，是要允许用户犯错的。也就是说，就算用户记错了邮编，记错了城市，甚至拼写都有了错误，一个好的Address Capture的引擎都要能够找到用户想去的地方。最少是要提供几个可能的选项给用户选择。
所以高mm碰到了一个不那么好的Address Capture的引擎，就开始想是不是自己记错了。其实用户永远不会错。如果用户错了，请参考前一条。这是一个合格的产品应该做到的一点。
这其实和道路是否更新关系不大。当然，道路如果真的经常更新，那么在Server端来做数据更新显然比在无数个终端上数据更新更容易。一次更新，所有的用户也能同时受益
家园 地址捕捉 Yueyu同学是这方面的权威。
欧美的地址很标准，两行，
123 Washington Ave East
Seattle, WA 12345
[door number] [street name] [road type] [direction]
[city], [state] [zip]
中国的地址可就没这么规范了，
北京市海淀区上地
小营西路12号上清园1-2-102
邮编 100085
“上地”是什么，区？
“上清园”是个居民区，居民区是个二维的区域，而不是一个线状的地理范畴？
“1-2-102”代表着1栋2单元102室，也可以写成1/2/102，或者其它林林总总的形式。
对于这样的地址怎么准确定位？几乎没办法。能做的是，把小区的大门，也就是“小营西路12号”的经纬度算出来。
但是如何把“小营西路12号”从整个字段中抽取出来？
印度的地址就更可爱了。
在中国，如果“小营西路2号”在“小营西路1号”西边，通常情况可以推测“小营西路3号”在更西边。
但是印度不一样，它的门牌号码是按房子的落成时间定的。所以1号的西边有可能是2号，但是再右边不一定是3号。3号有可能在1号左边。
家园 一样的 至于数据更新问题。总体上来讲，不像想像中变化如此剧烈。但是更新起来，在后台server更新，比在无数个设备上更新要容易的多。这也是为什么要强调要通过网络来跑LBS程序的原因之一