【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

入得谷来,祸福自求。
Post Reply
Elysees
Posts: 6756
Joined: 2003-12-05 13:10

【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Elysees » 2012-07-03 13:39

话说我还没进入导航(navigation,但无数人俗称gps)这个行业之前,就时不常听认识的朋友号称,“这其实好容易的,好容易的,都不知道为什么市面上的为什么做那么差。”
我当时虽然对行业内幕还不特别通,但之前稍有些关于gps和地图数据的训练,听到这些话就很想反驳。当然一般出于礼貌我的反应会是含笑点头,有时候称赞句“您懂得真多”,其实内心不住吐血。
去年还没开始新工作公司就安排我参加跟数据供应商的电话会议,当时有人就发过的墨西哥数据某城市名语言标号到底是Spanish还是Mexican Spanish喋喋不休的问了好久,我后来跟贵人抱怨道,这到底有毛关系啊,什么西班牙语不是西班牙语,讲那么半天,没完没了的。工作一阵子以后才知道,这确实有关系,关系虽不大,但也不小,对系统怎么运作也很有影响。
这都是后话。
我大概也能理解为什么不少人(尤其是Engineering background的人)觉得导航应该是件很容易的事,概念来说,所谓导航,就是指导人怎么从A点到B点,这完全就是个几何问题,何难之有?
我先把问题庖丁解牛一下,所谓从A点到B点,其实包含好几个方面:
首先第一点,A点和B点是怎么表示的,这个说起来就有若干种可能。有些时候,当用户输入的时候,所谓A点和B点,并不真的的是一个点。
大家可以想象一下自己找路的时候的输入,A点和B点,既可以是两条街的交叉点(Intersection search),或者某一个具体的地址(address search),或者某一个兴趣点或者Landmark(Point of Interest),甚至有时候只是很general的名字,隐含意是要到那个地方,而通常情况下这个地方往往不是一个点,或者是条线,或者是条街(例如Chinatown,例如Main Street),就普通用户而言,超过99.99%的人满足于以上几种输入,极少极少有人,会用经纬度代表自己的A点和B点。
如果把A点到B点的表示方法继续解剖,还会涉及全球各个地方地址表示的风俗,Admin Hierarchy的区别,等等等等,可长篇大论若干日。
而所谓从A点到B点,也并非几何直线距离,而是通过路网从A点出发抵达B点。因此A点和B点,无论是什么,必须依附于路网,没有路网可到的,也无法进行求路。
更进一步说,虽然只是简单的一个从A到B,其实很多人的期待值是“用最短的时间/最短的距离/最省钱的方式/最少转弯”从A到B。
我时不常在自己已经知道怎么走的时候,开着导航(有时候是我们公司的,有时候是别人的),看看导航给我怎么求路,一边听它指点一边想它这条路究竟是为什么怎么走。
我得说,就周边的路,或者旅行时候走过几次的路来说,人(至少我)算出来的路基本都比导航优化。有些是明显的数据缺点引起的:例如我在西雅图有次从某个商场出来,明明是可以左转的路口,Google的Navigator让我右转上下一个路口U-Turn;这里就是很明显的在路口加了一个错误的禁转指令;有些则是求路时候的算法跟生活脱节引起的(例如我在下午5-6点从Stanford shopping mall出来往南回Mountain View,所有的导航(几乎所有!大家可以拿自己的都试试)给的路都是,从University Ave上101,然后101往南,从Mountain View附近出来。这条路,只要是稍有当地生活经验的人都会知道基本不可行。比较好的选择之一有从El Camino Real上上Oregon Express,然后从紧靠101的W Bayshore Road 往南走。后一条路在通常情况下可以省20-30分钟时间。这个求路,并不是没有数据,而在于怎么把数据合理转换,计算权重。
所以虽然只是简单的A到B,其实也并不如大部分人想的那么“容易容易”。一转眼我换了这份工作已经快一年,这一年里跟进北美南美以及欧洲几边的数据发布,奇怪问题也碰上不少,来写写我这一年经历的行业虱子,这样下次大家在用导航而不顺遂的时候,可以多少有点儿理解,不至于愤而砸机(或者更加愤而砸机,囧)

(下接回帖)
Last edited by Elysees on 2012-10-02 13:49, edited 5 times in total.
我自横刀向天笑,笑完我就去睡觉。

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by tiffany » 2012-07-03 13:46

:mrgreen: 说起来就回忆起我们得gps (navigator) 指点我们往沟里开的历史。良人老痛骂他的garmin蠢笨反应慢,我心说谁让你没事儿老关键时刻指派它重新找路来着。
乡音无改鬓毛衰

silkworm
Posts: 4776
Joined: 2004-01-09 20:45

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by silkworm » 2012-07-03 13:50

提问:
那天在广播上听见一耳朵,德国高中生做了一个科技项目,把gps用户的信息,A to B以及路线,都回传给服务器,然后就能预报堵车情况,可以提前设计不太堵的路。
这个靠谱么?

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by Elysees » 2012-07-03 14:17

silkworm wrote:提问:
那天在广播上听见一耳朵,德国高中生做了一个科技项目,把gps用户的信息,A to B以及路线,都回传给服务器,然后就能预报堵车情况,可以提前设计不太堵的路。
这个靠谱么?
靠谱,但这个如果商业化涉及很多问题,例如legal上是不是允许把这些数据发给服务器,以及服务器接收了这个数据以后怎么进行分析运用到求路。
理论上说,只要数据量足够大,用户足够多(我每每跟贵人说道这种data mining的问题的时候就仿佛可以听到他内心狂笑哈哈哈哈),是可以通过实时数据计算当时的行车速度,甚至可以通过用户数据画出最新的地图,表示路口禁转,等等等等。
但第一用户数据很多时候不足够大到可以作为决定作用,第二有时候涉及到个人行为可用性很低。
再有就是这个问题的难点不仅仅在于知道哪一个路段堵车,这个信息其实大部分情况下通过历史数据都能得知,关键在于,知道这条路的当时时速以后,要怎么给这段路加权重。如果选择detour,另外一天路需要多加多少距离,路的级别多少,有多少路口,有没有堵车,都是要考虑的问题。大部分人希望detour是为了得到一条更优化的路省时间,并不是为了避免堵车而detour,如果另外的选择虽然不堵车但是需要走一条级别很低的local路,有很多路口,并且距离需要折得非常远,这样的情况下,就没有更优化路线存在,或者根据不同的人,优化的概念也不一样。
这就是人之所以比机器好的地方,人远比机器灵活,而且人在算路的时候其实考虑了很多因素,机器并不见得完全capture了这些。
贵人常说的是,算出来的formula不对,有时候是数据不够好,更多的时候是数据没有解析对,有很多变量根本没有被考虑到,这个说起来太数学袅,超出我的知识范围,呃,就点到为止哈。
tiffany wrote::mrgreen: 说起来就回忆起我们得gps (navigator) 指点我们往沟里开的历史。良人老痛骂他的garmin蠢笨反应慢,我心说谁让你没事儿老关键时刻指派它重新找路来着。
其实Garmin是做GPS的老牌,精度应该是没问题的,算法什么的倒可能比较欠缺,我周末去旧金山开着我的车载导航,我爹带着他的Garmin,我就觉得Garmin算出来的路有点匪夷所思。
我自横刀向天笑,笑完我就去睡觉。

april
Posts: 1349
Joined: 2010-03-21 21:12

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by april » 2012-07-03 14:32

He looked like a small panther, and he moved like a patch of night.

笑嘻嘻
Posts: 23302
Joined: 2003-11-22 18:00

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by 笑嘻嘻 » 2012-07-03 15:48

作为一名工程师,同时是一名使用工具的好手。我大言不惭地说,我从来不觉得一样工具简单,尤其是有很多人用的工具。称手的工具能给我带来巨大的快感。导航再怎么在人生地不熟的地方也比看地图方便,就是替代了一部分的人脑工作。尤其是再要更智能地选择路线。所谓从A到B其实就是高度总结了人脑看地图的过程。最早我们在美国开长途车用大地图本,要先简化A与B。在比例尺大的那页找大地址选高速公路,然后找到精细页面一步一步找local的路。然后开始抛弃地图本,(那时候costco还卖每年的地图本呢。何伟不是说过中国人不会看地图。这其实就是技能,导航仪让普通人不需要这个技能了。)用笔记本替代,那时无线上网还没广泛民用通常就是先在网上找好路线,然后把那几页大图小图考到机器里。
不过这说的都是民用导航仪,军工的学问可大了。
云浆未饮结成冰

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by Elysees » 2012-07-06 15:04

我7.4进三番看烟花,还亲身测试了一把这个,觉得也还是没有完全靠谱。10点左右渔人码头散场,Embarbacadero那条街上挤得水泄不通,google地图上也标志着大红色表明交通数据也是对的,可导航偏把我往那路上引,口口声声的就让我上Embarbacadero,我无法,只好自己对着地图找了条路走。不过我选的路也不太快,毕竟没有从指定路上走,也不知道是不是挤完Embarbacadero就柳暗花明逃出生天了。
我自横刀向天笑,笑完我就去睡觉。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(tbc)

Post by Elysees » 2012-09-26 16:28

借着Apple Map发布的东风,再来展开说说这个。
先声明,以下纯属猜测,从我做一行的经验来解析下错误可能的原因,并不一定是Apple Map真正的执行方式,望果粉们宽恕则个。

Apple map出来以后舆论轩然大波,甚至有人搞了个“The Amazing iOS6 Maps, Not”的Tumblr来搜集人们觉得大谬的Apple Map错误。
虽然看起来很多很多页貌似很欢乐,总结起来,其实大类的错误就几种
1,3D Map的错误
2,POI定位错误(这个包括所有POI例如车站,mall,学校等各种landmark,城市名--Named Place POI, etc)
3,Address Capture/Geocoding错误(输入一个地址,然后pin-point到具体的街上),这个错误不是特别多,我在tumblr上看到的就是把来克星敦街定位在布鲁克林(517 Lexington St, NY)
4,航片拼接不细致,这个不能算错误,只能说apple map内部的人对做遥感有点儿缺乏经验,犯的是遥感专业学生比较初级的毛病。

我在不知道哪个地方看到一句笑话,说Apple的Less is more的原则没法用在map上,hence the errors。
并不是没有道理,在我初步看来,从上面来说,apple map的几乎所有问题都出在把地图看得过于简单化。

1,
3D的错误属于挑出错容易改正不容易的问题,就我的观察推测,Apple的算法是用terrain数据来计算地面的高度变化,然后用建筑物的高度利用footprint进行三维化,最后在上面覆盖航片用航片信息完成texture的效果。这是比较方便和通用的做法,并不止apple一家用这个idea,区别在于数据的取得和具体的实现。
数据的取得来说,terrain数据比较简单,大部分国家都会有elevation数据,这个是最常用的做terrain效果的数据,大家肯定都见过各式各样做成阴影效果的hillshade。
人文建筑物应该有所区分,我接触的可用以建筑三维化的数据都分为几个信息,一般比较城市中心的地方大部分建筑物都有building footprint,然后每个footrpint有对应的高度,再细致些的还会有建筑物表面的texture信息(窗子格子,墙的颜色,etc)。这种数据出来的效果细,但比较动画(大家可以在百度地图上看看北京有些地区的三维效果,有点儿像跑游戏);apple(以及google,nokia)都加上最后一步,提取航片信息做texture,这样会有些逼真感。但有些人文建筑物例如桥,水坝,不能片面的从footprint做起,就需要很多细致的高度。Apple map的3D问题在标志性建筑物上出得不多,大部分都是在各种桥上,大约就是没有把人文建筑物分类对待的缘故。
还有三维化实现的简单化上,大家可以试试看看山区,其实山区没有建筑物的terrain覆盖航片总体来说是可行的,也不太出现可笑的效果。但到了terrain和建筑物叠加的时候,就会有奇怪效果出现,简单的说,人眼能辨识建筑物建在哪里,没有细致考虑过的程序就会混乱。例如一个建在山上的桥,桥上某一点的高度是x米,但是此地的海拔高度是y米,具体来说,这个桥的这个点应该拔高到x+y米,如果在海面上又要分开考虑。等等等等。实际的情况当然会比我举这个例子要更复杂。关于这个,有兴趣的可以看看Nokia Map的三维布鲁克林桥和Apple Map的布鲁克林桥,区别就很大。不过我个人怀疑Nokia Map的布鲁克林桥不是那么简单做出来,应该用的是Nokia自己的3D Landmark的数据,当然要比简单的计算高度做三维要细。

2,
POI定位错误大概就是那些找某某mall结果根本找错地方,或者找某某小学某某餐馆结果发现点落在马路正当中或者河道正中间。
老实说Apple Map的POI定位错误让我大跌眼镜。可能现在来说Apple Map的各种错误会让人有马后炮的感觉,大约果粉会攻击类似知易行难之类的。但POI定位这个实在是属于很基础的问题,稍微有些做导航地图经验的人都会意识到可能出现的问题进行QA矫正,以苹果从各导航公司挖走的大量人员来看(我们公司地图组去苹果的前后有十几人),也不应该有这个错误出现。
我之前猜测说苹果可能POI用了另一套数据,后来公司里跟人打听了一下,果然听说苹果的POI用的是CoreLogic的数据,这跟TomTom的街道数据就不是一套(我个人是有点儿不太理解为什么,TomTom本身也是有POI数据卖的)。
简单解释一下这两种数据:街道数据大家可能都比较熟悉,就是密密麻麻的路网,是线数据,线记录位置,attribute记录街道信息。街道配套的attribute很多,跟这个问题相关是街道名,相关路道的开始和结束的门牌号,城市名,和邮编。
POI数据是点数据,点记录位置(含坐标),attribute记录具体地址,如果该地址是个business,还有business的名字,别名,etc,etc。
精细的POI数据会一个一个点的采集,而不是用传统的geocoding(名词解释:Geocoding=根据提供的街道开始和结束的门牌号和街道长度,算出某一个地址在这个街道的位置,例如一条01-100的街,150根据这个算法会在这个街的中点上)的方法。精细POI的好处在于可以避免地址分布不均的地方,geocoding带来的偏差(例如可能150号在10号的旁边的一个很大的楼群中),这种精细POI尤其适用于北美以外大部分地址排列混乱无规律的地方。
问题在于POI和街道的来源不一致的时候,这两者需要首先进行数据匹配。
我们看到的地图其实都是相对的信息,大部分人在看地图的时候都是看某条街跟某条街/河/楼的相对关系,没有人真正研究过怎么把这条街还原到地球表面去。实际情况是,(尤其在电子地图界),数据的精确性本身也是相对的。根据数据采集商的不同,某条街某条河的具体的位置也会有差别,只要街和街的相对关系对了,一般来说就足够精确了。当数据来源不同的时候,同一条街本身有若干米的off是很正常的现象。具体形容一下,如果把source 1的路网overlay在source 2的路网上,可能所有的街都偏离若干距离。(声明:从法律角度上来说,直接对比数据是违反产权的,所有商业数据供应商之间,禁止进行直接比较。我刚入这个行的时候,因为遵循以前在政府干活儿的道道,差点儿被legal骂得臭头)
我们公司也有CoreLogic的数据,我曾经做过一次数据分析,拿CoreLogic的点来跟US Census的TIGER/Line(政府的公开数据可以随便分析对比)数据进行空间分析,在佛罗里达某些荒凉的地方,有超过30%的CoreLogic的点在150米范围之内根本没有对应的街(我的大致算法很简单,就是一个一个点的做150米buffer,所有跟这个圆intersect的街道片段都取attribute拿街名跟CoreLogic的点的街名对比,如果是个match,就算找到,没有match就算找不到),这个数字在有些人口密集的区会好些,例如Santa Clara County,这个百分比就降到了大约5%。150米,在繁密的城市,可能超出若干条街区。
而TomTom数据,在某些区域,是基于US Census TIGER/Line 2010的,可以想见跟CoreLogic的Conflict一定也是有,甚至不少的。
Apple Map的有些错误看起来就是没有进行数据来源匹配矫正的结果。我猜测他们就直接把CoreLogic的点数据拿来用,而不曾跟街道匹配过。用户输入地址或者POI名字的时候,第一顺序是在POI里面找,如果找到了,直接点在POI的经纬度上,而不考虑具体附近街区。如果在POI里面找不到,才会顺序到街道的geocoding。
假设在CoreLogic 采集POI数据的时候,他们给101 Main Street的一个地址定位是他们采集到的这个building的经纬度,然后TomTom在做街道数据的时候,可能这条Main Street在经纬度稍有不同因此101 Main St也会不同(具体为什么有不同,涉及关于数据采集记录后期校正等等等等的,也是另外的一大篇,就不细说了),人们看地图是不看经纬度的,也不能理解这两个数据来源的差别,看到的只是一个简单的,应该在Main Street上/附近的点,被点到了200米之外的街区,或者200米之外正好有条河,就到了河里。
这个问题本身并不难解决,如果事先考虑到,最好的办法是预先处理POI数据,把所有的POI的数据都先跟街道匹配一次,不匹配的统统删掉,重新用geocoding找一个点来代替这个点。或者如果不在意运行速度的话,找到POI点以后,取该街道的点进行矫正。
出问题的缘故,最大的可能是没有考虑到数据来源差异,这个,大约不做地图的人会有固定思维,认为地球上某一点地方是固定的,谁来取都一样,而没法理解在把这个点取出来还原到地图上的过程,各家有各家的差异。(我抱头说,这是Engineering完美世界的惯性思维吧)
我们公司在做类似过程的时候有个经典问题,就是废数据要不要。因为两者来源不同,可能采集时间有差别,造成POI里面有个100 A Street的点,但是A Street在街道里面还没有来得及收录进去。有些人的观点是就把这个点保留,就让它点在空白处;我的观点则是这个点直接在这个版本取出来,将来A Street被收录进街道以后再用。不然放一个点在某个在地图上看起来鸟不生蛋的地方,未免古怪。还有的问题有,如果某某邮局在100 K Street,然后POI提供一个100 K Street的点,但那个点在B Street上,附近也没有K Street。我一向的观点也是直接把这个点删掉,当然也有人建议保留。我要求删掉的缘故很简单,如果我的导航把我route到一个邮局,到了那儿我发现根本不是邮局,我还宁愿它一开始告诉我这个邮局找不到,那我起码可以找下一个邮局,哪怕远点儿。
当然,具体怎么处理都见仁见智,是比较个人的选择。只是说明这是个在导航界很常见的问题,我惊奇于Apple Map在发布前似乎完全没有针对这个数据conflict的应对,直接拿用户来当QA,跟他们以往风格很不符。

(tbc)
我自横刀向天笑,笑完我就去睡觉。

Jun
Posts: 27816
Joined: 2003-12-15 11:43

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Jun » 2012-09-26 17:30

没看得特别懂,不过小E说起engineers思维方式让我很有感应。我爹妈都是工程师,我跟他们就常常没法沟通关于医疗健康方面的话题,他们看见数据就觉得特别可信,百发百中,身体出了什么毛病就认为只要找出故障就可以修好如新,总是抓着医生不放,要求各种透视加化验,而且假设每一种 abnormality 必有相应的药物,吃了就好了,胆固醇指标低就一定不会得心血管病,啥啥指标低就一定没有癌症。我终于明白了为什么跟他们没法解释清楚,医学对人体的认识其实很模糊,很多疾病看不见摸不着也算不出,而且药物的效果也都是黑匣子,天晓得为什么有效,还有什么副作用,有时候解决方法比问题本身更糟糕。但是,工程师的脑子很难接受模糊的不精确的乃至混乱 chaotic 的现实。另外他们自信地假设人体跟机器一样,哪个零件出毛病了,拆开换掉,重新装好,就可以正常运转,这些零件都是独立的;但是人体(以及世界上的很多现象)是有机的,很多线索和因素互相关联,千丝万缕,无法单一拆解开来一条一条清清楚楚,彼此互不干扰。所以我给他们的一些解释和建议可信度不够,虽然他们照办之后显得我“很灵”,但是事先仍然疑虑重重,为什么我也说不清个所以然,就是让他们去吃这个那个药。
此喵已死,有事烧纸

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by tiffany » 2012-09-26 19:45

小e说的真有意思。继续继续。
乡音无改鬓毛衰

笑嘻嘻
Posts: 23302
Joined: 2003-11-22 18:00

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 笑嘻嘻 » 2012-09-26 20:13

我,我,我,我研究生的时候给城建系打工,就是把德州公路局的各种数据给联系起来,地图上的点和路面的照片同时播放,我就很傻很直接地从A点到B点算个匀速!

从前我跟小白对过笔记,工程师一进行受的训练就是万事万物都有原因,尤其是出错的时候,不知道原因只是没找到原因而已。所以见啥都应该问为什么,久而久之形成了OCD. 而科学家们就是实验出什么结果就是什么结果,不能老问为什么,老问就要么信教要么自挂东南枝了。

所以看来医药方面是属科学口,用工程师的方法慢慢啃。 :worthy:
云浆未饮结成冰

Knowing
Posts: 34487
Joined: 2003-11-22 20:37

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Knowing » 2012-09-27 5:05

Of cause everything has a reas
on! Otherwise how ....I don not know....how to face this world.
有事找我请发站内消息

Jun
Posts: 27816
Joined: 2003-12-15 11:43

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Jun » 2012-09-27 7:10

我也相信万事皆有原因,不过工程和医学的差别在于,人能制造出的东西,机制结构相对比较简单,而且是人造出来的,大家思路也一致,基本可以迅速摸透。而大自然花了几亿年制造出的东西,很复杂,不容易搞懂,工具和知识都远远不够,大多数时候只能靠直接观察现象然后倒推猜测。人对自然机器(生物包括人自己)的了解,可以类比石器时代人类对相对论的了解。但是大家总不能等着把内部机构和原因都彻底搞清楚了再来吃药治病,否则真的要自挂东南枝了,所以现在仍然基本依赖 empirical 数据来诊断和治病。

药物真的是黑匣子,更别提行为对生理的作用了;外科倒是更象工程一些,哪儿长瘤就割掉,关节之间的软骨磨坏了就换上金属的,血管堵了就从别处截一段血管接上。 :laughting015:
此喵已死,有事烧纸

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by tiffany » 2012-09-27 11:25

:mrgreen:
jun说得对。当初阿大曾经说过,工程师自己是上帝,创造世界的。造出来得东西相对比较简单。
生物,是真正上帝造的,古人云牵一发而动全身,所有的东西都是连着的。好比多少年以前就是比较简单粗暴的切脑子治疗癫痫那会儿,把一人得海马都切掉了,人是不癫痫了,人也记不住事儿了。。。。
乡音无改鬓毛衰

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-09-27 11:52

嘻嘻,这讨论有意思。
笑大这个说Engineering的思维让我想起Bones里面Bones说她自己,她说她相信万物万事皆有原因,科学没有办法解释的,只是因为还没找到原因。这个说法我也相信,但仅限在科学世界里,但设计到具体的人文以及自然界,就不是那么明确的。
我说的Engineering的完美思维,还要更具体一点。
就我跟贵人常年的接触来说(我觉得他还是个蛮典型的工程师思维,笑大小K来鉴定下?),我觉得他的世界都是可以用数学建模的(aka,用某一种算法来模拟现实世界)。我倒是觉得世界上并不是所有的事件都可以用算法来模拟的,尤其跟人挂钩的时候。我觉得人的很多行为(甚至还没涉及到生理部分)并不见得都有规律可循(白博和Jun对这个什么想法?)。贵人工作跟display ads相关,就是希望通过各种各样的算法建模来使display ads靠近用户的兴趣点因此提高internet viewer的点击率。他们搞过很多很复杂的model,在机器上运转的时候数据都很不错,貌似capture了规律,但真正放上来却经常有点击率不增反减的结果。当然,贵人这种思维,他的想法就是,结果不正确就是模型不正确,parameters没有找对,关系没有找对,没关系,改进模型。我就问他,你就没有想过,人们点击广告的行为也许并没有规律可循?也许你们根本就是大海捞针?就我自己来说,我今天心情好又有闲暇,就随便点几个看看;也许我这几天忙得不可开交心情不好,你的广告做成花儿我也不会点。他会说你这种行为就叫outlier,只要数据量足够大都可以filter掉,不算在模型里面。
既然是说地图,还是回到地图地理上。
城市地理也有这种类似数学建模的理论,关于一个城市会怎么建成发展起来。但人类历史发展有各种各样的outlier,而outlier在人文科学界往往是不可以被忽略的,即使只是0.1%的outlier。最简单的,(我万宗归一的回到地图上)关于一个国家的admin hierarchy,美国的大部分建制都是State->County->City,具体到统计还会有Blockgroup->Block。所有人(我可以说超过99.999%)在输入地址的时候是跳过county,直接输state,city,street(呃,顺序反过来)这在中西部大部分地方不会有问题,全美有非常少的几个例外(大概就是所谓的outlier),最著名的一个是New York,NY (btw,我们常说的New York, New York实际上应该是说这个城市的形制,其实意思是New York (the city), New York (the state),因为名字相同,所以出现咏叹的效果。然后我就看到有人以此为例咏叹式的说北京,北京;上海,上海。鉴于上海和北京也算省级形制,这么说也不算错,但说啥成都,成都就不对劲了,要说也应该说成都,四川啊)。New York City下面还有一个admin level,Borough(5个), 是不可以被忽略的。大部分人说纽约的地址的时候是有所指,虽然大部分人以为New York只有曼哈顿那一个岛,实际上New York City包含了5个Borough:曼哈顿,皇后区,布鲁克林,Bronx, Staten Island。这5个地方甚至不属于同一个county。这是个在美国非常特殊的形制,但绝对不能作为outlier在admin 模型里忽略掉。当然作为现在广为流行的one box search,app不能控制用户怎么输入,所以自由度非常大,这就要求app能handle各种情况包括可能的duplicate。tumblr上有个例子是笑话apple map把Lexington Ave放在了布鲁克林区,这本身在数据上是没有错的,因为布鲁克林确实有一个Lexington Ave。这个用户输入比较模糊,是517 Lexington Ave, ny。apple把ny解析成new york(the city)的通配倒是对了这个人的想法,但没有具体再往下走一步,517 Lexington Ave, New York, NY实际上有两个地址,一个在曼哈顿(10017),一个在布鲁克林(11221),当然比较纽约的人可能会说,布鲁克林那个应该写作517 Lexington Ave, Brooklyn, NY。但从Admin level上来说,布鲁克林这个candidate是正确的。同样的还有Main St,New York,NY,也应该有若干个结果。Apple Map简单化了我们这个复杂的世界,大概有个unique地址只有unique点的想法,在这种多个candidate出现的时候只出来一个,偏偏还是不太著名的一个,这就是我所谓的Engineer的完美世界的想法吧。
顺便说一句刚才那个输入其实还可以把NY解析成state,地址还要更加多。其实这符合笑大说的,一个app,在很多人用的时候,其实非常难做的原因。因为使用的人越多,你越不能预料可能的输入,就需要包含几乎各种人的行为。
我上面说的admin level在扩及世界范围的时候,还要更加复杂,admin level在西班牙有6个之多,因此如果只遵循city,country的输入,甚至即使违背欧洲人习惯再加一个province,依然会有非常非常多的duplicate cities出现。这种情况在美国东部也很常见,PA,VA,MA之类的老省份,几乎每个州都有若干重名的town,还有重名街道(可能每个城市都有什么Main Street, Bell Street之类的),这些都是QA时候应该考虑的因素,至少看看app要怎么handle这些状况。Apple map这次草草放地图出来,在我看来就是拿用户给他们做QA。
这个就算上面说的3吧。
Last edited by Elysees on 2012-10-02 13:19, edited 1 time in total.
我自横刀向天笑,笑完我就去睡觉。

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by tiffany » 2012-09-27 12:14

人类的行为,大的方面看还是有规律的。跟你自己每天出没几个地方似的。虽然在一个城里,有很多地方你也从来不会去的。我觉得总的来说数学的说还是一正态分布,不过这个正态分布的山峰比较宽,se会相当大。

小e你做用户的问题是要考虑所有人的可能需求,漏下一个人都是app的缺陷,那个思路跟你家贵人要考虑的往一群人里泼一瓢水怎么泼才能洒到最多的人是不一样的。
乡音无改鬓毛衰

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-09-27 12:24

啊, 白博说这个泼水的可真形象啊!!!可不就是嘛,他的想法里那些少数人干着就干着吧,我们这就万万不行了。
我对这个数学表达世界的理论有点儿觉得困扰(虽然也许在大部分时候是可行的)。最近还听说是match.com还是eharmony.com之类的地方不是也有模型算最佳配对。我有个同事说上去填了差不多10页的问卷,然后系统会根据算法来给他挑候选人......他自己说感觉还挺靠谱的涅。这个世界整个被Engineering们统治了嘛。
我自横刀向天笑,笑完我就去睡觉。

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by tiffany » 2012-09-27 12:38

也不算吧?还是有所谓mystery of the heart的。不然棒球就是一算法,哪里有那么激动人心。尤其是这种需要个人提供大量私人数据的算法,要是这人了解自己并且实诚,不需要计算机,换个活人也能给推荐个挺好的。。。跟以前深蓝跟高手下国际象棋似的,它的算法是每一可能性每一个可能性的算....
乡音无改鬓毛衰

笑嘻嘻
Posts: 23302
Joined: 2003-11-22 18:00

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 笑嘻嘻 » 2012-09-27 15:13

没,没,没。少数人不会被干死的,贵人模型不包括,自有其他模型包括。咱们在讨论云计算的时候不是从讲亚马逊开始的吗,亚马逊的长尾理论就是说书店里卖畅销书,绝大多数书后来就看得人很少了。但是这些不畅销的书数量多,加起来总和会超过畅销书的销量。后来Netflix 的最早商业模型也是根据这个。
云浆未饮结成冰

豪情
Posts: 21256
Joined: 2003-11-22 18:47

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 豪情 » 2012-09-27 15:23

光有这个长尾理论,没有网路的规模效应和warehousing的有效管理,也是不行的。亚马逊的warehousing的算法也下了很大功夫。
谁道闲情抛掷久?每到春来,惆怅还依旧。

笑嘻嘻
Posts: 23302
Joined: 2003-11-22 18:00

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 笑嘻嘻 » 2012-09-27 23:15

都是算法啊。 :mrgreen:
云浆未饮结成冰

camellia
Posts: 1146
Joined: 2003-12-04 19:17

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by camellia » 2012-09-29 16:33

哈,其实原因很简单,最近QA都outsource啦。这种User Acceptance Testing,应该是小E这种地图方面的专家来做,可是现在都是身在印度对美国地理没概念的人在做,工程师设计的时候有问题,QA也没发现就对了。私下觉得如果乔布斯还在,这事不会发生。
那个曼哈顿岛和布鲁克林街道重名的事害过我很多次,尤其是从NJ下面开上去的时候,输New York, NY 都给指布鲁克林去,还死活改不过来。可是我印象中,New York,NY就是特指NYC的啊,其他的几个城地址都是Brooklyn, NY或是Flushing, NY之类的。倒是这里Flushing, NY和Queens, NY对同一个地址可以同样成立这点挺特别的。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-01 12:09

茶花,我不知道这种outsource怎么做呢,其实QA这个过程在哪里做都无所谓,但QA case的设计和expect的结果应该是有local经验的人提供的呀,在印度做也得有个expected结果吧?
输New York, NY 都给指布鲁克林去,还死活改不过来。可是我印象中,New York,NY就是特指NYC的啊,其他的几个城地址都是Brooklyn, NY或是Flushing, NY之类的。倒是这里Flushing, NY和Queens, NY对同一个地址可以同样成立这点挺特别的。
New York, NY确实是NYC,但NYC不等于manhattan啊。NYC下面有5个Borough,就是我上面说的那5个,这5个是比NYC更低一级的admin level,理论上说输入New York,NY上面5个Borough都是正确的,如果按字母排序的话,这5个在array里面排序估计就是Brooklyn, Manhattan,Queens,Staten Island,The Bronx,如果没有考虑多个结果返回的话,第一个返回结果一般就是array里的第一个Brooklyn了。
Flushing是比Queens这个Borough里面更低一层的等级,属于neigborhood(有点儿类似于Hollywood之类的,但Hollywood一般不上地址),是Queens里的子集,在Flushing里有的地址当然会有一个对应的也在Queens里面,这本质上跟在Manhattan,NY/Brooklyn,NY/etc.有的地址在New York,NY里面也有对应的是一样的。
以纽约市的特殊性,传统的地图QA本来就有无数个针对他们的test case才是。
另外USPS的地址格式严格来说并不总是符合admin level的,例如Flushing,NY这样的地址,在别的地方会很少见。这个说开了去要涉及到什么是city,还有,在一般用户眼里,什么样的输入qualify as a city,这完全是两回事。
我自横刀向天笑,笑完我就去睡觉。

Knowing
Posts: 34487
Joined: 2003-11-22 20:37

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Knowing » 2012-10-01 13:02

好看,我还都看的懂。
哭诉说这就是为什么人少的地方GPS 经常不靠谱嘛?尤其是岛上。
说起数据建模,解决问题的方法,通常说的工程师脑袋是企图分析原因然后建模解决问题,解决不了就怀疑模型input 不够往上加。另一个现在时髦的是empirical 的建模。现在不少startup 都雇好些数学出身建模研究人的行为模式,但是侧重收集observation 不是纯数据。据说现在婚恋网站早就已经不止看用户填的理想配偶条件,还偷偷研究用户的行为模式,然后算该怎么搭对推荐。比如一男的填表要求对象受过大学教育,容貌中上,年龄相当的,但是老是看大胸金发派对女郎的profile, 老给她们发消息,网站就会推荐这类型的给他。netflix 推荐电影基本也是那个理,但是怎么从数据理归纳特征是人工智能的百万美元问题 :mrgreen: :mrgreen: 瞧,一切都还是有规律的。。。
有事找我请发站内消息

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by tiffany » 2012-10-01 13:05

我看到这个金发大胸party gril 忍不住狂笑
乡音无改鬓毛衰

豪情
Posts: 21256
Joined: 2003-11-22 18:47

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 豪情 » 2012-10-01 17:52

Elysees wrote:茶花,我不知道这种outsource怎么做呢,其实QA这个过程在哪里做都无所谓,但QA case的设计和expect的结果应该是有local经验的人提供的呀,在印度做也得有个expected结果吧?
输New York, NY 都给指布鲁克林去,还死活改不过来。可是我印象中,New York,NY就是特指NYC的啊,其他的几个城地址都是Brooklyn, NY或是Flushing, NY之类的。倒是这里Flushing, NY和Queens, NY对同一个地址可以同样成立这点挺特别的。
New York, NY确实是NYC,但NYC不等于manhattan啊。NYC下面有5个Borough,就是我上面说的那5个,这5个是比NYC更低一级的admin level,理论上说输入New York,NY上面5个Borough都是正确的,如果按字母排序的话,这5个在array里面排序估计就是Brooklyn, Manhattan,Queens,Staten Island,The Bronx,如果没有考虑多个结果返回的话,第一个返回结果一般就是array里的第一个Brooklyn了。
Flushing是比Queens这个Borough里面更低一层的等级,属于neigborhood(有点儿类似于Hollywood之类的,但Hollywood一般不上地址),是Queens里的子集,在Flushing里有的地址当然会有一个对应的也在Queens里面,这本质上跟在Manhattan,NY/Brooklyn,NY/etc.有的地址在New York,NY里面也有对应的是一样的。
以纽约市的特殊性,传统的地图QA本来就有无数个针对他们的test case才是。
另外USPS的地址格式严格来说并不总是符合admin level的,例如Flushing,NY这样的地址,在别的地方会很少见。这个说开了去要涉及到什么是city,还有,在一般用户眼里,什么样的输入qualify as a city,这完全是两回事。
我怎么觉得并不少见, SEATTLE 很多地区比如机场附近也是用sea-tac, WA但是他们是属于City of Seattle的. 我觉得是USPS系统不支持那么多层次.
谁道闲情抛掷久?每到春来,惆怅还依旧。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-01 18:31

SEATAC从数据上来说也是L4,也是个city(有自己的city hall),跟Seattle平级,(L1=Country,L2=State,L3=County,L4=City),不是Seattle的一部分。豪情说的city of seattle是指广义上的seattle大地区吧,类似bay area,washington dc metro area,并不是地址上的所谓的seattle the city。这种metropolitan area比较棘手,怎么收录各家有各家的做法,不过一般是不能算formal的city的。

New York比较特殊的在于它确实是一个大的city,面积虽然很大,形制上也只是L4,manhattan和Brooklyn比L4更低一级。
我自横刀向天笑,笑完我就去睡觉。

豪情
Posts: 21256
Joined: 2003-11-22 18:47

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 豪情 » 2012-10-01 19:07

如果地址写Seattle WA, Sea-Tac居民可以收到邮件.我说的City of Seattle就是行政上city. 不过可能sea-tac有自己的city.华州加州还有很多地方是unincorporated, 就是说, 不属于任何city, 不接受city服务不交税, 但是邮政系统还是给他们安排了一个city地址.
谁道闲情抛掷久?每到春来,惆怅还依旧。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-01 22:31

Seatac应该跟Kirkland,Bellevue什么的是一个意思吧,这个在wiki上查起来也是说是city level,http://en.wikipedia.org/wiki/SeaTac,_Washington,http://www.ci.seatac.wa.us。不过具体行政管辖如何我倒不是很清楚,我一直就好奇旧金山市长到底管不管整个bay area呢,这个大约要真正追究到具体行政地理。不过在DC一带的话,DC管DC,北维各市管各市,倒是没有一个metro area的总管的。
USPS能在Seattle,WA送到Seatac的地址,我猜测是通过zipcode校正过,不过我没有在usps工作过,只是猜测的。
美国中西部确实很多州有相当多的地方没有一个city,如果在地图上看,仅看L4的话,中西部很多地方是一块儿一块儿的,而不能拼出整个州的模样来,我一直挺奇怪那些地方怎么管辖;但东部大部分州就可以。另外就是虽然city在county下面,但很多city是跨county的,这个大概大家都知道了。
usps跟census大部分情况下match,但也有部分不match的city,这个估计是为了他们自己搞起来方便。我其实也一直挺想弄弄清他们那一套的。这个现象好像在英国更明显,他们的royal mail service和他们的census(类census机构)的London覆盖范围差别很大呢。
我自横刀向天笑,笑完我就去睡觉。

豪情
Posts: 21256
Joined: 2003-11-22 18:47

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 豪情 » 2012-10-01 22:48

我看房的时候问过不属任何city有什么问题, 据说是city的警察火警不管, 但是反正属于county, 有county的警察火警, 有county library. 学区完全是另一套系统. 也不受影响. SEATTLE郊区各CITY之间不属于任何CITY的地带多得很. 不过这些年那些city扩张得很厉害, 附近地区居民投票就可以加入. 对了上次cupertino水泥厂杀人案那个水泥厂其实也不属于city of cupertino. 一样是unincorporated. 但是地址也写的cupertino.
我的理解CITY 和学区一样只是历史形成的收税和服务系统. 不过美国大部分行政系统历史上也是这么形成的.
三番市长就管三番, 谢天谢地.
谁道闲情抛掷久?每到春来,惆怅还依旧。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-02 13:17

说道城市发展跟历史进程技术进步人类行为变化等等都紧密相关。我不是城市地理专业的,只知道一点点皮毛,也差不多全还给老师了。不过看美国中西部城市和东部城市的区别,就是两个不同时代的城市发展的过程。东部城市最早形成的时候还没有个人汽车的概念,城市的形成要紧实得多,各种资源也比较集中。美国中西部基本上是有个人汽车以后才开始发展的,整个分布就稀疏很多,资源有极大的浪费。我还没有搬到湾区之前从DC去Houston玩,两三天,那边城市设施之铺开程度比加州还过,我当时觉得资源真是被极大的浪费掉了,非常痛心ing。
1,我偏题偏到一个自己完全不熟悉的方向了,汗~
我自横刀向天笑,笑完我就去睡觉。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-02 13:48

继续来写这个apple map,上面的讨论都可以算做3,address的多用户输入的差别,geocoding的精确性什么的。
最后写一点点4,我不是遥感专业的,只在本科和硕士期间学了一点点遥感的皮毛,工作里用得很少,不过一般地图里也不是真的用遥感片做分析,主要就是拼接航片给用户看而已。
Apple Map被摘出来的错误里面,这一条我觉得严格意义上来说,不好算错误,只能说工作做得很不细致。对于大众而言,航片并没有非常实际的导航作用,只是更具象的让读者看到地图上这个区究竟是什么样子而已。从地图的角度上来说,我对航片效果并不是特别热衷,觉得信息量很低,除非看片的人非常熟悉这个区域,否则一般的读者能看出来的也仅有:(相当面积的)森林/植被,湖泊,居民区,(可能的)工业区,比较明显的城镇分布,比较大的道路,和足够醒目的landmark。
这个,大概众所周知的是,航片有各种来源,各种resolution,各种状态(黑白,彩色,像分析用的Landsat之类的,还有1-7个色谱区间),即使是同一个resource,航片拍摄时间不同,状态也很不一样。(题外话一句,我很久以前在微博还是哪里看人贴某处的遥感片比较,说是1990年和2000年的遥感片可以看出城市如何扩张blahblah,当然这个城市扩张很可能是真的,但航片分析不是这么简单的PHOTOSHOP两张照片一起看。最基本的一点,这两张片是不是一个季节拍的,植被本身有没有季节性变化,都没有提供;而不要提进一步的信息提取,只有博观众噱头而已)。
Apple Map航片拼接有几种让人诟病的地方:
一是有云而不曾处理掉。这个属于我说的很基本的遥感知识,一般遥感片拿到第一步要分析可用性,cloud的程度超过若干百分比(具体数字不记得了)航片一般会被丢弃重新找,某一个百分比之内可以进行处理,具体的操作我是不记得了,但稍微有点儿遥感知识的人应该至少注意到云层在航片上的百分比。
二跟一类似,是建筑物反光问题,这个也没什么说的,也是航片可用度的evaluation的过程。
三比较多见,是不同来源的航片拼接。这个比较多见在zoom-in的level,这个没啥好说的,raster数据用得太混乱,这个问题不难解决,尽量一个区域的航片的来源,resolution统一起来,拼接之后注意mosaic的过程(就是边跟边的拼接问题,一般航片都有1秒左右的重合区,这个区在拼接过程中每个点的值通过interpolation重新算,这样可以达到接近无缝拼接的效果),我觉得是最好fix的问题。
说它严格来说不算错误,是因为航片确实也覆盖过去了。但航片做图,要的就是读取航片信息的效果,如果航片拼接出来根本不是可读的模样,未免让人失望,还不如没有,尤其如果这个产品从一向鼓吹细节取胜的apple出来。
另外多说一句就是,(这个可能大家也都知道了),航片在zoom in过程中其实resources是换过很多次的,不过一般人不那么容易觉察出来。像Bing map用的世界地图的航片是NASA的Blue Marble Next Generation,这个分辨率并不高,大概是8km/pixel (5 mile/pixel,这个意思是每个pixel,如果想做一个正方形,相当于地面上8km的正方形), 图片也很小,整个世界也就是一个几M的JPG,同一个产品分辨率可以往上到500M/pixel,整个世界要分成8个tile,每个都有差不多20m。
如此类推如此类推,越往下zoom,对航片分辨率要求越高。一般来说,在同一个zoom level,所有航片分辨率都会尽量保持一致(即使来源有差),这样看起来至少不会出现一会儿blur一会儿sharp的效果。从做project的角度上说,这是个很容易把关的问题,一般的做法是,在每个zoom level,选好resolution的航片,拼接,然后切tile,在指定的zoom level只调指定的航片tile。
像apple map出来的问题,我不太客气的说,像本科生做的遥感作业,连什么resolution在什么zoom level都没搞清就瞎拼接了,最初设定的时候都没有给resource设定一个门槛,所以效果很差。
不过again,这个问题其实不难解决,只是需要重新来,重新买片(如果片还没买好,这以apple的财力,不是问题),机器重新转一通,服务器刷一下就好了。如果1-4有什么可以马上fix的问题,我觉得是这个。
嗯,暂时就算写完了吧,以后想起来再往里添。
我自横刀向天笑,笑完我就去睡觉。

笑嘻嘻
Posts: 23302
Joined: 2003-11-22 18:00

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by 笑嘻嘻 » 2012-10-09 0:04

Elysees wrote:说道城市发展跟历史进程技术进步人类行为变化等等都紧密相关。我不是城市地理专业的,只知道一点点皮毛,也差不多全还给老师了。不过看美国中西部城市和东部城市的区别,就是两个不同时代的城市发展的过程。东部城市最早形成的时候还没有个人汽车的概念,城市的形成要紧实得多,各种资源也比较集中。美国中西部基本上是有个人汽车以后才开始发展的,整个分布就稀疏很多,资源有极大的浪费。我还没有搬到湾区之前从DC去Houston玩,两三天,那边城市设施之铺开程度比加州还过,我当时觉得资源真是被极大的浪费掉了,非常痛心ing。
1,我偏题偏到一个自己完全不熟悉的方向了,汗~
美国中西部的城市建设理念跟两岸的确完全不一样。城市人口的集中对资源的节约是不是这些年提出的?我记得前些年听到广播里讲过。不过我觉得中西部的城市乡镇结构是美国独有的。一切都有序,包括高速公路上下口的走向,认路及其方便。简直象一种matrix 的文化。感觉是大工业文化的产物。
云浆未饮结成冰

camellia
Posts: 1146
Joined: 2003-12-04 19:17

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by camellia » 2012-10-10 20:17

Elysees wrote:茶花,我不知道这种outsource怎么做呢,其实QA这个过程在哪里做都无所谓,但QA case的设计和expect的结果应该是有local经验的人提供的呀,在印度做也得有个expected结果吧?
输New York, NY 都给指布鲁克林去,还死活改不过来。可是我印象中,New York,NY就是特指NYC的啊,其他的几个城地址都是Brooklyn, NY或是Flushing, NY之类的。倒是这里Flushing, NY和Queens, NY对同一个地址可以同样成立这点挺特别的。
天知道有local经验的人写不写test cases,这中间应该转了几手,然后lost in translation。UAT的人可能不是方面专家,现在这个都算是BA的活了,然后好多BA是印度来美国没怎么出门的。

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(抗09262012,简析苹果地图错误)

Post by Elysees » 2012-10-11 13:01

笑嘻嘻 wrote: 美国中西部的城市建设理念跟两岸的确完全不一样。城市人口的集中对资源的节约是不是这些年提出的?我记得前些年听到广播里讲过。不过我觉得中西部的城市乡镇结构是美国独有的。一切都有序,包括高速公路上下口的走向,认路及其方便。简直象一种matrix 的文化。感觉是大工业文化的产物。
这个也不完全是城市建设理念的问题,城市的发展说起来可以写好几本,我的知识也很有限。但大体来说城市的形成(而不是建成,大约只有DC这样的城市才叫建成)都是随可reach的资源来的,早期因为人没有自己的汽车,日常并不能自行跑很远,住处必须跟工作的地方接近,一个grocery store能serve的范围也很有限,所以residential area跟CBD混杂,城市形成很密实,类似于中国大部分城市,力争在有限面积内住下最多的人;而人工资源的分配也是随人的居住来规划(例如超市,ATM,银行等等这些生活设施的选址,在近年来其实都是经过GIS分析的,我时不常看到Wells Fargo,Starbucks之类的地方招GIS的人)。早期的城市形成受限于交通工具的限制,所以才有所谓CBD的形成,再后来有了铁轨,就有城镇顺着铁轨分布的现象(例如东南部Georgia一带,亚特兰大就是铁路以后兴起的,这个飘里面也说到过)。中西部发展要更晚,这个时候个人汽车已经进入家庭,人愿意并且能够为日常所用travel的范围要比从前大得多,所以城市设施都可以铺得很开,一个grocery store serve的area比之前要大很多很多。而且中西部基本上是先有公路才有城市,整个发展过程跟东部很不同。
我自横刀向天笑,笑完我就去睡觉。

Jun
Posts: 27816
Joined: 2003-12-15 11:43

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Jun » 2012-10-11 13:47

小E 一说让人茅塞顿开啊,原来交通方式才是最重大的因素。专业人士! :super:
此喵已死,有事烧纸

Knowing
Posts: 34487
Joined: 2003-11-22 20:37

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Knowing » 2012-10-11 21:04

好看!
小E 看见Google 的水下项目了么?great barrier reef 的照片搞的人真心痒。说起来我很奇怪他们怎么能同时拍下立体照片,zoom in 过程中的换片问题怎么解决?比如鱼是游的很快的,前一张照片里珊瑚礁边上一群鱼,zoom 过去时鱼可能已经游过去了,除非同时很多相机一起拍?还是有特殊相机处理照片所以zoom 过去鱼也不是清晰度很高,比近处的海龟差远了。也可能这就是为什么不能随意移动方向?
http://www.google.com/culturalinstitute/worldwonders/
有事找我请发站内消息

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Elysees » 2012-10-12 11:09

啊,Jun真是过奖了,这些都是课上听来的只鳞片爪了。
小k贴这个我以前没看过艾,有意思,但我的browser上好像看不了3D/我只看了看360view。我原先路上见过Google StreetView的车,是个车顶上装着照相机,车一边开一边不停急速旋转的,估计一秒钟内各个角度都拍了无数照片了吧。这个可能也是这种相机的,顶在潜水员(或者潜水车?)头上(?),哗啦啦转着拍的,不过水里阻力那么大,肯定转得没那么快吧?我也不知道。
Google有些项目真是挺有意思的。
我自横刀向天笑,笑完我就去睡觉。

Knowing
Posts: 34487
Joined: 2003-11-22 20:37

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Knowing » 2013-10-18 6:42

,最著名的一个是New York,NY (btw,我们常说的New York, New York实际上应该是说这个城市的形制,其实意思是New York (the city), New York (the state),因为名字相同,所以出现咏叹的效果。然后我就看到有人以此为例咏叹式的说北京,北京;上海,上海。鉴于上海和北京也算省级形制,这么说也不算错,但说啥成都,成都就不对劲了,要说也应该说成都,四川啊)。New York City下面还有一个admin level,Borough(5个), 是不可以被忽略的。大部分人说纽约的地址的时候是有所指,虽然大部分人以为New York只有曼哈顿那一个岛,实际上New York City包含了5个Borough:曼哈顿,皇后区,布鲁克林,Bronx, Staten Island。这5个地方甚至不属于同一个county。这是个在美国非常特殊的形制,但绝对不能作为outlier在admin 模型里忽略掉。当然作为现在广为流行的one box search,app不能控制用户怎么输入,所以自由度非常大,这就要求app能handle各种情况包括可能的duplicate。tumblr上有个例子是笑话apple map把Lexington Ave放在了布鲁克林区,这本身在数据上是没有错的,因为布鲁克林确实有一个Lexington Ave。这个用户输入比较模糊,是517 Lexington Ave, ny。apple把ny解析成new york(the city)的通配倒是对了这个人的想法,但没有具体再往下走一步,517 Lexington Ave, New York, NY实际上有两个地址,一个在曼哈顿(10017),一个在布鲁克林(11221),当然比较纽约的人可能会说,布鲁克林那个应该写作517 Lexington Ave, Brooklyn, NY。但从Admin level上来说,布鲁克林这个candidate是正确的。同样的还有Main St,New York,NY,也应该有若干个结果。Apple Map简单化了我们这个复杂的世界,大概有个unique地址只有unique点的想法,在这种多个candidate出现的时候只出来一个,偏偏还是不太著名的一个,这就是我所谓的Engineer的完美世界的想法吧。
顺便说一句刚才那个输入其实还可以把NY解析成state,地址还要更加多。其实这符合笑大说的,一个app,在很多人用的时候,其实非常难做的原因。因为使用的人越多,你越不能预料可能的输入,就需要包含几乎各种人的行为。
今天面试一个在google map 弄过这个搜索建议算法的瑞士孩子,谈了这个结果的筛选问题,挺有意思的,回头我有空了来讲啊..总之就是apple 不是做搜索起家的就是不行。。
有事找我请发站内消息

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by tiffany » 2013-10-18 8:17

我精神大震的说,快讲快讲!
乡音无改鬓毛衰

Elysees
Posts: 6756
Joined: 2003-12-05 13:10

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Elysees » 2013-10-22 8:51

Knowing wrote: 今天面试一个在google map 弄过这个搜索建议算法的瑞士孩子,谈了这个结果的筛选问题,挺有意思的,回头我有空了来讲啊..总之就是apple 不是做搜索起家的就是不行。。
等好几天了,急切求展开啊
我自横刀向天笑,笑完我就去睡觉。

Knowing
Posts: 34487
Joined: 2003-11-22 20:37

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by Knowing » 2013-10-22 16:10

 他做的就是当用户搜索怎么rank 返回结果,该match 什么,甚至打完整个字之前你们注意到了底下会有建议帮你auto complete 么?还有自动纠错的时候?这个算法是怎么弄的,回头我有空讲。。
有事找我请发站内消息

豪情
Posts: 21256
Joined: 2003-11-22 18:47

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by 豪情 » 2013-10-22 16:13

不要忘记。
谁道闲情抛掷久?每到春来,惆怅还依旧。

tiffany
Posts: 24705
Joined: 2003-11-22 20:59

Re: 【行业虱子】导航袍子上的密密麻麻虱子(暂时算写完吧)

Post by tiffany » 2013-10-22 16:55

我等到花儿也谢了,哀怨的说
乡音无改鬓毛衰

Post Reply