TMS是tile map service的缩写，是一种瓦片地图服务，也称之为WMTS（web map tile service），具体的标准可以见OGC网站。TMS的算法很简单，就是把投影后的世界地图按照层级进行四叉树(待验证)切割，切割后的瓦片数量随层级呈金字塔型，数量和层级关系如下表所示：

对这些瓦片进行编号，由于瓦片编号的规律性（平面直角坐标系），加上投影也是一种算法（球形展开成平面），所以，编号和坐标之间就建立了一种索引关系，通过编号可以得到经纬度区间，通过经纬度可以找到瓦片的编号，具体的计算公式如下：

n = 2 ^ zoom
xtile = ((lon_deg + 180) / 360) * n
ytile = (1 - (log(tan(lat_rad) + sec(lat_rad)) / π)) / 2 * n

由公式可以看出，只要确定经纬度和层级，就可以得到瓦片的编号索引，相反，若知道编号就可以去推算未知的经纬度了，其计算公式如下：

n = 2 ^ zoom
lon_deg = xtile / n * 360.0 - 180.0
lat_rad = arctan(sinh(π * (1 - 2 * ytile / n)))
lat_deg = lat_rad * 180.0 / π

所以：一、显示地图的时候就可以根据中心坐标和层级以及bound范围，就可以确定需要加载那些地图瓦片；二、mark一个point的时候，根据point的经纬度以及tile的经纬度范围，就可以确定point在某一tile的像素坐标位置，而tile同bound之间又有像素关系，所以point就可以mark到map的bound上了；三、同二相反，鼠标在bound上单机，也就可以得到具体的经纬度信息了。这应该是webmap引擎实现丰富多样地图效果的基础吧，包括线、面、地图叠加等更多功能。

我从网上找了一段开源的代码，重新组了一下，可以通过在线的方式获得编号同经纬度之间的正反算了，体验网址：http://rovertang.com/labs/tileindex/，你输入经纬度并选择层级后就可以得到Google tile和TMS的瓦片索引编号了，效果如下图：

需要说明的是，Google tile同TMS有差别，原因是：Google tile的直角坐标系原点在左上角（即北极点同中央子午线的交点），而TMS的原点在左下角（南极点同中央子午线的交点）。所以：编号索引中的x轴不变，y轴略有变化，结果为该列所有tile减去y再减去1，公式就不再罗列了，可以直接查看我提供的网址分析源代码吧。我们以上海世博演艺中心(现为梅赛德斯奔驰演艺中心)的坐标来演示一下Google tile和TMS的索引差异吧，经过计算，在14层级下，Google tile的x和y分别为13721和6696，而TMS的x和y为13721和9687，两者的tile网址可访问这两个连接：http://mt0.google.com/vt/lyrs=m@174000000&hl=zh-CN&src=app&x=13721&s=&y=6696&z=14&s=Galileo和http://rovertang.com/labs/GMAPIv3_Offline/expotile/14/13721/9687.png，后者是我通过maptiler工具切割的世博地图tile(在上次的Google Maps API v3离线开发包一文中我有提供下载，现增加演示网址：http://rovertang.com/labs/GMAPIv3_Offline/)，两者对比如下：

BTW：如果你需要更多的将TMS算法公式变为可执行代码，那么请参考OSM的wiki：Slippy map tilenames，文中提供了python、perl、PHP、.net等语言的code，有兴趣的可以参考一下。

最后：本文虽然参考了较多的瓦片文章，但对瓦片地图的理解可能仍然有片面之处，欢迎交流和指正。

这次愚人节的时候，Google推出了水下搜索，当然，这只是一个愚人的小把戏，不过效果非常不错，进入页面后，第一眼是一个水面的效果，水下的鲨鱼在游来游去，然后Google logo和搜索框从水面上往下掉进水里，输入内容后点击搜索，会将搜索出来的图片从天而降掉进水里，点击水面还能引起波澜，如果点击手气不错，会掉金币、宝甁、宝箱等，效果很愚人吧。现在仍然可以体验，体验网址：http://www.google.com.hk/intl/zh-CN/landing/shuixia/，效果截图如下：

需要特别说一下的是，这个效果是用HTML5做的，需要使用支持HTML5的chrome或firefox等浏览器才能看到这一效果，使用IE6只能看到一提示画面，让你安装chrome浏览器。虽然这只是Google愚人节的一个玩笑，但也让我们看到了HTML5的强大，没有Flash依然可以做出Flash的效果。不过效果虽炫，但资源耗不起那，打开这一页面后，CPU一下子就上去了，主要应该是这个搜索框和logo的不断刷新(看source code会发现这些元素会不断变化位置)所致吧，真有点伤不起。

最后，我把这一效果的代码扒了下来（除搜索按钮无效果外其他都是一样的），本地演示：http://rovertang.com/labs/shuixia/ (速度有点小慢，如果加载不成功，则请Ctrl+F5强制刷新)，代码和资源下载：http://sharesh.googlecode.com/files/googleshuixia.zip。有兴趣的朋友可以自行研究一下这一效果的实现，也许会对你如何使用HTML5做游戏有所新的发现和帮助吧。

如果你是做Android软件的，那么就涉及到发布到市场的问题，Google自身提供了一个市场，叫Google Android Market，和Apple的appstore类似，只是这个市场更加的开放，现在，这个Google Android Market已经更名为Google Play了。我尝试着去了解了一下将软件发布到Google Android Market的过程，和大家一起来说说这该死的Google Android Market。

如何发布你的软件到Google Android Market？

首先，你要有一个Google的账号和VISA或万事达(以及另外两家)的信用卡，当然，这是废话。

然后，你要有一个checkout(现已并入Google Wallet，美国区已经执行，其他地区暂未执行)帐号，注册的过程中没有china可选，但可以先选择Hongkong来代替。

有了checkout，就去Google Android Market申请软件发布，申请地址：http://play.google.com/apps/publish。和Apple的appstore类似，需要通过checkout向Google支付google25美金，就是软件开发许可，这样你才可以获得签名的私钥文件，有了签名你才可以发布到Google Android Market，debug的签名应该是不可以的(这有点和当年的symbian的签名证书类似，只是似乎没有那么严格)。

原则上，完成了这几项就可以在Google Android Market上发布你的软件了，而且免费收费都可以。但问题是：你的信用卡实际上是大陆的，账单地址又是虚假的Hongkong地址，可能加上Google出于纳税的考虑，所以如果Google checkout没有美国纳税身份证明(现在已经开通了20多个国家和地区吧，其他国家和地区也应该需要类似的纳税证明的，可能如果你本身是国外银行卡也许就简单多了)，Google只能每个月最多给你500美金，多余的部分暂扣。checkout的账户限制和早期paypal有点类似，给账户充值美金还要用国外银行卡，所以淘宝上就有做美金兑换业务，不过据我上次使用paypal的经历，paypal现在应该都可以支持国内的银行卡了，包括双币借记卡都可以，也许银联的卡都可以。

那好吧，我想就去办张香港的银行卡吧。打电话给招商银行，问了下在上海也能办香港的一卡通，但有三个条件，一是账户上需要有五万人民币，二是要有港澳通行证，并且半年以上，当然，身份证我就不说了，三是居住证明，水电煤账单、信用卡账单等都可以，当然有房产证最好。三样齐全后你就可以去办了，不过只有两个网点可办，一个在陆家嘴，一个在淮海路。不过，我是办不了这个卡了，以后再考虑吧。

不过，事情还没完，考虑到财务问题，又去咨询了下财务，结果事情更复杂了。首先，严格来说，公司的所有业务均为对公业务，所以应该要用公司的银行账号，个人账号原则上是不可以作为公司业务账号进行经营的。其次，公司的经营许可范围是什么？在网上卖软件是否意味着有电子商务行为，是否超范围经营？再次，涉及美元则要用公司的美金账户，然后是否涉及进出口？和财务这么一聊，我是更觉得复杂了。

回到正题，从上述的问题来看，向Google Android Market提交收费程序基本不是一个好的路子，而且看了一下国内大部分的公司向Google Android Market提交的应用也基本都是免费的，这样是不是就意味着做android应用就收不到钱了？其实倒是未必，换个思路就会豁然开朗：软件免费，许可收费。你发布的软件，是免费的，可以放到Google Android Market，以及国内很多流行的市场，向机锋市场、安智市场、AppChina应用汇等，无非就是就是放到市场里去吗，但在软件里安装了你的程序，接下来的事情可就是你自己干的了，包括是否允许运行、功能限制、付费激活、账户控制等，所以最终能不能收到钱，还是取决于你，而非应用市场。

通过向Google Android Market发布软件这个原则上应该很简单的事情，没有想到让Google帮助我们赚钱是那么的艰辛，相比apple的appstore，google的market要想在国内立足，还有很长很长的路要走，更不要说整个市场生态环境的培育了。

网上有个朋友向我推荐申请美国一公司的银行卡(可以用大陆身份办理，也可以给寄送实体卡，虚拟卡也可以办)，不过这应该也会涉及到费用的问题，所以如果有国外朋友帮忙代收应该算是最好的路子了。不知道大家对程序放到Google Android Market进行收费，还有什么好的路子？

什么是User Agent？懂一点网页制作的人应该都明白。简单的说，User Agent就是用来识别浏览器名称、版本、引擎以及操作系统等信息的内容。于是乎，User Agent的判断就成为识别浏览器的关键，不仅仅如此，移动互联网开发势头迅猛，那么通过User Agent判断桌面端设备或移动设备就变的很为重要。当然，通过User Agent也可以用来改善一定的兼容性，比如判断得到用户用IE6浏览器那么就是用不同的代码。这些，我想许多的WEB开发中已经成为考虑的第一个问题。

那么，有没有一种好的判断User Agent的代码呢？网上应该有很多，比较简单的直接判断下iOS和Android，然后进入不一样的页面。比如百度地图就是如此，桌面设备访问http://map.baidu.com/地址，而移动设备就访问http://map.baidu.com/mobile/地址，你用桌面设备访问移动网址则还会自动跳回到桌面地址。这就是通过判断User Agent做到的效果。

我没有去细究百度地图是如何判断桌面设备和移动设备的，但我想要找到一个比较全面的User Agent判断代码。不知道大家是否知道有一个叫html5test的网站，其中要作用就是判断你的浏览器对HTML5的支持程度，但同时，他还提供了浏览器和设备信息。我在桌面端通过Firefox、Chrome、IE、Safari等测试都很正确，在移动设备端，Apple iPod下测试了Safari、Opera mini和UC，除了UC无法识别外其他都OK，另外在Nokia E63下也做了测试，默认浏览器OK，UC无法识别。

既然HTML5TEST已经做的如此全面，连浏览器、引擎、设备类型和设备名称等都一应俱全，那就说明在User Agent上的判断应该是做的非常不错的，至少，是我现今看到的最好的了。然后又看到HTML5TEST本身是开源的，那就下载下来分析一下吧。看过后，没有想到，HTML5TEST竟然封装的那么好，一个JS包含了基本上全部的User Agent判断，这个js文件，可以直接浏览这里。

我把这个JS单独拿出来，再加上几句html，做了个浏览器测试的页面，大家可以通过访问这个页面来查看自己的浏览器信息、设备信息等，效果请见下图。地址：http://rovertang.com/labs/useragent/

我想，通过这一个js，得到了浏览器信息、设备类型和设备名称，接下来怎么做就看你自己的了，不过也有一个小小的担心：一个大于50K的js文件，对页面的加载似乎是有点压力的。

顺便说一下，发现IE对HTML5的DOCTYPE标签支持不是很好，有测试不通过的现象。万恶的IE确实挺让人恼火的。

最后推荐一个FireFox的组件吧，我想许多人都用过，就是User Agent Switcher，作用呢就是在FF下伪装成其他浏览器，比如iPhone的浏览器，这样就可以直接在FF下浏览移动网页进行代码分析了。

HTML5现在已经成为移动开发的另一个焦点，关于native app和web app以及杂交app的讨论也已经不少。原来光芒四射的Flash，Adobe公司宣布放弃移动版的开发，而转向更大力度的支持HTML5。虽然说HTML5里的Canvas可以在今后替代Flash，但个人觉得似乎也不乐观，我们来说几件事情吧。

近十年前就看到flashk(一个组织后来就消亡了)做过一个基于flash的管网系统，那时候就觉得用flash做一个地图引擎，那应该是多牛。

后来觉得SVG不错，我都有点同GML有点相提并论了，但SVG至今依然不是HTML5的一部分，而且这么多年也没有一个牛的应用是用SVG做的，虽然SVG看起来挺强大的，支持热点、支持内嵌js等，并且很多浏览器对SVG的支持也不错。(最早有见过用SVG来做地图的，那应该在我06年时写博客有提到过，但那时候瓦片地图都应该是在大家努力研究的状态吧)

昨天晚上开始研究百度的地铁地图，是用flash做的，矢量化的，做的还是挺漂亮的，我一直很喜欢，但移动设备基本上不能用(对flash不支持或者支持不佳)。研究这个东西呢有两个意图，一是把它离线，让其他网站也能用，另一就是想直接看看他们的数据，毕竟自己做数据还是比较累人的。现在的结果是，本地显示基本OK，部分功能不可用(比如路径演算就一定是需要服务端支持的，发现地铁的路径演算竟然是百度地图的一个部分，演算完毕后地铁程序解析获取到的JSON数据，可能地铁换乘也算是百度步行导航演算的一个部分吧，我卡壳的是地铁的JS不能获取JSON以及解析，不知道是否和跨域有一定的关系否)。地铁数据部分，也已经看到数据，是一个二维平面下的一系列坐标点集合，准备导出来看看能否直接成图。

今天花了一点时间，把HTML5中的Canvas章节，简单的浏览了一遍。虽然有不少的函数，但似乎同绘图工具有所类似了，让我想到了mapinfo，什么画线、画面、画圆、画弧线、填充颜色、设置包边的粗细和颜色等等等。我在想：若使用HTML5绘图，那不仅仅是要将地图绘制一遍(获得坐标控制点)，更需要将地图通过JS语言来去实现一遍。OMG，想起来就觉得有点头大，难道flash当年也如此麻烦？即便flash如此麻烦，那也至少是有可视化编辑环境的，那HTML5的绘图是否会有可视化的编辑环境呢？(也许只是我还没有发现吧)。另外补充一句：flash的问题确实比较多，比如非常占用CPU、比较耗电，那么HTML5的Canvas就不会有这问题吗？

后来搜索“HTML5 Canvas map”的时候，看到两个地图，一个世界地图，另一个是美国地图，都是用HTML5绘制的，突然觉得HTML5绘制地图看起来希望很大嘛，于是研究了一下这个开源的美国HTML5地图，但简单看了下，就觉得怕了，因为：美国地图绘制的固然漂亮，但绘制的那一系列平面坐标点是如何而来的呢？当然，不排除是有工具的，但我觉得，若要做到这样，那是多么的艰辛那(看他的Map.js文件，总共近1300行，地图数据就占据了一半)。有兴趣的朋友就去看看吧：http://dougx.net/map/usmap.html

不过，既然HTML5大势如此，那HTML5的将来一定是璀璨的，只是，可以得到一个结论是：在没有一个好用的工具之前，用HTML5来绘制地图，是一件非常非常麻烦的事情，更不用说将HTML5的绘图做成引擎，实现放大缩小平移以及热点响应事件等操作了。看到一个HTML5做的巨牛网站，甚是欣慰，动画效果同flash有的一拼，观摩地址：http://www.ro.me/。(虽然是效果巨牛的HTML5动画网站，但工程其实挺大的，查看源文件，发现一个页面加载了90多个功能js，绘图js也是让人眼花的坐标系列，看下这个文件会不会吓到你，呵呵)

总结几句废话：

1、做件事情很不容易

2、工具(或者说是框架或引擎之类的东西，比如openlayers引擎、jQuery框架等)很有用

3、可用性和易用性很关键

最后问大家一句：你会用HTML5去绘制地图否？

常常看JS文件的时候，经常会遇到一些unicode编码后的中文，很难猜透是啥中文，所以会比较痛苦。虽然在线解码以及解码小工具都有，但都不是很好用，特别是那个unicode解码器2.0版，我竟然打不开。一气之下，Google了一下解码的方法，竟然只要一句C#语句(原文)就可以搞定，如下：

private String DecodeUnicode(String dataStr)
{
    Regex reg = new Regex(@"(?i)\\[uU]([0-9a-f]{4})");
    return reg.Replace(dataStr, delegate(Match m) { return ((char)Convert.ToInt32(m.Groups[1].Value, 16)).ToString(); });
}

虽然我不会C#，但看在已经安装了VS2008的份上，就跑了一下代码，测试通过。为了免去以后的痛苦，所以就把它编译成一个exe吧，顺便也就分享给大家吧。

功能很简单，输入unicode编码后的内容，然后点击decode，自动还原成可读的unicode码。截图如下：

下载地址：http://sharesh.googlecode.com/files/deunicode.zip

在开始这个题目之前，先给大家再次扫扫盲，扫的不是坐标系统的盲，而是我们国家所使用的坐标系统。大家都知道，美国GPS使用的是WGS84的坐标系统，以经纬度的形式来表示地球平面上的某一个位置，这应该是国际共识。但在我国，出于国家安全考虑，国内所有导航电子地图必须使用国家测绘局制定的加密坐标系统，即将一个真实的经纬度坐标加密成一个不正确的经纬度坐标，我们在业内将前者称之为地球坐标，后者称之为火星坐标，具体的说明可以参看百度百科中关于火星坐标系统的解释(文中的两段还是对我原文的摘录)。

所以，本文所要讨论的坐标系统，是关于地球坐标和火星坐标的事情。以前使用Google Maps API开发习惯了，就觉得国外用地球坐标国内用火星坐标是共识，但由于Google服务常常被block的因素，加上还没取得所谓的审图号，所以改用国内地图API，结果问题来了，并不是所有的地图API都采用火星坐标的。我用了一个下午的时间写了个API示例，将地球坐标和火星坐标标注到地图上去对比，具体大家可以访问以下网页自行查看差别：

http://rovertang.com/labs/map-compare/

结论是：

注1：百度地图使用百度坐标，支持从地球坐标和火星坐标导入成百度坐标，但无法导出。并且批量坐标转换一次只能转换20个(待验证)。

注2：搜狗地图支持直接显示地球坐标，支持地球坐标、火星坐标、百度坐标导入成搜狗坐标，同样，搜狗坐标也无法导出。

个人认为：采用自家坐标体系，而不采用国内通用的火星坐标体系，实在是自寻短处。当然，百度是因为做的足够大、足够好，所以很霸道，也为以后一统天下而不让别人瓜分之而做准备吧。搜狗虽然用自家坐标体系，但能将地球坐标直接导入，此举也属唯一。而图吧地图不知道学什么加密方式，以前用地球坐标用的好好的，现在用图吧自己的坐标，难道是因为给百度做过所以也来了这么一招？或者沿用百度？不得而知。

本文的目的在于：做地图开发的时候，不希望被一家地图API迁就，所以采用火星坐标是正确的选择，希望本文能够对选择使用谁家API的开发者提供一点帮助吧。就我个人而言，我绝不会使用非火星坐标系统的地图API，虽然百度地图API很好很强大确实很吸引我。

在做这几个样例的过程中，也同大家分享几点个人感受：

1、MapBar和MapABC是需要绑定网站域名的。Google Maps API v3开始就不使用了key了，所以也希望更多的地图API不要限制于地图API key(手机开发或地图接口应用倒是可以用key来关联一下)。

2、兼容性仍然是个大问题。MapBar API在IE6下正常，Chrome和FireFox下有问题。MapABC我也调试了很久，最后在Chrome下还是有点问题。当然，还有更糟糕的地图API(易图通的myemap在Chrome下不显示地图，瑞图的365地图网在Chrome下错位)，我就没有去尝试了。

3、发现51ditu的地图级别，是越详细数字越小，和其他地图API相反，同时，初始化地图的时候若输入一个超过层级的数字，则地图不显示，放大缩小不可操作，不知道这算不算是一个bug。

4、在移动设备上的兼容性未做测试，若把这一参数加上，也许又可以刷掉几个地图API。

虽然做了这些比较，但个人还未能完全拿定主意用哪个API来开发，不知道大家倾向于哪一家地图API呢？

在09年的时候，我就写过一篇Google Maps API离线开发包(没有网络也可以开发Gmap了)，后来liongis大虾又重新整理了一份新的包，甚至出了v3版的离线包。今天在liongis大虾的基础上，我重新整理释放一份离线开发包给大家，和liongis的离线包相比，仅将版本由3.4.x升级到3.8.2，这应该是现阶段最新的包，最简单的一个区别：放大地图的时候，比原版平滑顺畅的多，这当然最需要感谢的，是Google的改进，增加了一层静态地图覆盖，放大的时候又异步平滑加载，所以效果非常好。

废话不多说，除了上述说到的改进，我顺便附送一份世博地图的tile，实现的效果大致如下：

这一效果算是叠加自定义瓦片地图的形式实现的自己地图离线显示。

需要特别说明的是：

1、本离线开发包内仅实现了功能离线，即js源码和部分控件图片的离线，地图仍然使用Google Tile。

2、从思路上讲，将Google Tile下载到本地，或者自行切割tile，都是一种将地图离线的方法，原则上都可以实现。关于tile的命名和获取方法，待下回分解。

3、在Google服务经常被block的今天，离线包和离线地图，还是非常有必要的。:)

祝大家用好这份离线包，如有兴趣可以一起讨论交流。

下载地址：http://sharesh.googlecode.com/files/GoogleMapsAPIv3_OfflinePack.zip

使用方法：解压缩到一个web服务器目录下，通过浏览器地址直接访问map-simple.html和maptype-tms.html即可，前者是简单示例，后者是瓦片地图示例。IE6、FireFox、Chrome下测试通过。

本文完成于两个月前，由于种种原因现在才同大家分享，以下是原文：

一年一度的由世纪高通公司组织的RTIC论坛于11月23日在昆明世纪金源大酒店举行。RTIC论坛精神在于组织讨论和分享RTIC技术在国内以及国际上的应用，以拓展大家对RTIC的认识，切磋在使用过程中的问题和心得体会。论坛邀请到了车厂、互联网、导航软件等厂商，当然还有政府部门，其中车厂居多，主要包括了上海汽车、大众、丰田、本田、日产等，当然也包括了较多汽车零部件厂商，以日系为主，比如电装、先锋、阿尔派、三洋等，还有像歌乐、哈曼、伟世通、博世等。除了车厂以及汽车零件厂商外，也有导航软件厂商和互联网企业，比如美行科技、新科、搜狗地图、腾瑞万里(导航犬)、泰为、百度、Google、中国电信等企业。当然，还有部分企业和研究机构，如北京交通信息中心等。

论坛主要由几个简单演讲组成，一起来分享一下这几个演讲吧。

一、北京市智能交通系统发展

这个演讲由北京交通信息中心提供，算是政府部门对于数据的披露。

1、北京的智能交通系统整体建设已经基本完毕，公交卡系统已经覆盖全市范围，此部分也可以在以后为交通流量分析提供依据。

2、对东直门等大型交通枢纽已经使用视频等方式进行交通流量采样。

3、北京共21000多个公交车，已经形成了汇报从车队到分公司再到总公司的流程。现在，北京共13000量公交车已经安装了GPS，涉及到九个分公司，537条线路，3条BRT线路。

4、在电子收费方面，已经形成了公交、轨交、出租车一体的一卡通系统，现有4000万交通卡用户，其中活跃用户在1278万，日军使用在1400万次，其中轨交有221万次。

5、在高速公路方面，共有365条ETC车道，实现了100%的高速覆盖。共有超过40万辆车使用ETC系统。(注：个人搜索了一下北京的汽车量，09年大概在400万左右)

6、在出租车方面，共有6.67万辆车全部装上了GPS(北京的出租车总数就是6.67万)，共有5个GPS监控中心，2家出租车公司实现了电话调度，日均叫车(电招)量在1.2万次左右。

7、在省际客运方面，共11个客运站，70多个代售点，1000多辆车安装了GPS。

8、在货运方面，共有7175辆车撞有GPS，共两个监控平台。

9、在停车方面，已经建立了电子地图系统，部分区域建立了停车诱导系统，涉及7000多个停车位(注：7000多这个数字待确认。这里应该是少些了一个0，应该在7万，这个数据是根据最后一个演讲推断而出)。

10、 在公路管理方面，已经设立了监测设备，平均1.2公里就有一个监控设备。

11、 已经建立了运输枢纽信息服务平台，共安装了280多个视频采集点和30多个客流采集点。

12、 在信息资源整合方面，正在加强调度中心的建设。

13、 北京市智能交通发展成果：建立了掌上交通信息指南，其中通过12580系统使用该功能的就超过了呼叫量的60%(待验证)。在车载导航仪方面也有超过3万的用户。

14、 在公众服务模式上，提供了网站服务和服务商合作两种模式。

15、 最后就是加强TOCC的建设，以提供更准确的分析报告，和提供更好的运维管理。

二、2011年RTIC服务发展回顾与2012年服务计划

这部分的演讲是由世纪高通公司的技术部门提供的。

1、在发展过程中遇到的问题：一是希望国家加大对产业的推动，二是交通拥堵限行等不利于实时交通的发展。

2、现在RTIC开通的城市，sohu使用了16个城市、baidu使用了19个城市、诺基亚使用了13个城市、Google使用了22个城市。(注：实际上应该总共开通了22个城市，或者可能已经包含了测试中的城市，Google只是作为了先行者)

3、从实时交通使用调查结果来看，用户的感觉准确率情况是：长春75%；杭州85%；无锡83%。

4、现开通的四个交通事件有：交通管制、道路施工、交通事故、道路障碍(待验证)。关于交通事件的搜集方法，主要与第三方合作方式下的用户交互模式为主。

5、今年建设推出了简洁交通信息画面、交通流量(待验证)、交通事件、动态停车位(实验室阶段)等。

6、在技术方面，尝试用信号灯控制模式进行分析。现在，上海的浮动车采集分析可以达到20秒一次。上海交通路况信息数据源主要来自：3家出租车公司、货运物流公司和交通局。

7、在管理方面，加强了人、流程、技术、管理四个方面的建设。

8、2012年的目标共三个部分，首先是对现有服务的稳步提升，提高已发布城市的质量，增加发布的内容，其次是保持产品的扩张能力，以点带面式发展，最后是加强创新服务试点。

三、东南亚RTIC交通信息服务的发展

本演讲是由泰国的丰通株式会社提供的，其实是属于丰田的合资公司，演讲的是一个泰国人，用日语演讲的。

1、现状：到2015年，实现东南亚人口一体化，四个国家将形成统一的经济圈(应该是类似欧洲国家的欧盟)。

2、一些数据：

汽车总量：日本7560万辆；中国5190万辆。(注：这个数据好像有点老，日本的数据差不多，但中国的汽车量说是今年超过日本。)

导航总量：日本4500万个每年；中国2830万个每年。

手机数量：日本118百万台；中国648百万台。

人口数量：日本127百万；中国1333百万。

互联网数量：日本34百万；中国298百万。(这个互联网忘了是指什么了，可能是互联网接入)

3、到2014年，汽车总量将达到100万(注：数据似乎有点少)，手机普及率将达到75%。

4、为了在泰国建立RTIC系统，丰通公司将安装1万个GPS到出租车上，以解决浮动车少的问题，同时捕捉数据的频率将达到3秒(注：很高哦)一次。

5、Gbook将会引入Android系统(应该是Gbook同手机的结合)。

6、关于TTET公司的介绍：是一家车载嵌入式软件开发企业，共230人。

7、其他关于在泰国发展RTIC的信息，可以为他们国家提供的内容有：地图数据和Maching Table；作为硬件制造商介入(用于FM-RTIC的中国设备在东南亚市场上一样适用)；成为RTIC的服务伙伴。

四、车的信息与技术发展

这部分的演讲是由Denso IT laboratory提供的，电装是非常有名的日本汽车零部件厂商，提供的前装车载导航软件还是很厉害的，演讲中展示的一些技术，也是我所比较惊叹的，在本文最后我们会加几张图片予以说明。

1、现阶段汽车信息的方向：高度化的信息、提高环保、与智能手机的结合、智能生活。

2、日本的汽车量为7400万，每年的交通事故是390万件(待验证)，公路每年增加5000公里。

3、电装研究的技术方向：

(1) 提供实时交通流量的测定

(2) 动态拥堵的预测

(3) 提供避免拥堵的最佳路线。(自动学习以在没有目的地的情况下提供路径引导)

(4) 节能环保辅助系统。(比如提前预测踩刹车。根据测试，在15公里路径的燃油率提升上来看，普通的系统提升为9.8%，而此系统的提升为17.1%)

4、开发了与智能手机结合的系统：NaviCon。(可以在App Store上找到)

5、开发了高速图像匹配技术：CARD。(待验证)

五、基于浮动车的数据挖掘与应用

此部分的演讲是由北京航空航天大学提供的，主要是研究后的数据，基本都以图表的形式来表现，所以内容不多，记录了三个部分：

1、本数据的分析是基于12000量浮动车数据的分析

2、每天都OD总量和趋势都比较稳定(大概就是交通流量等吧)

3、七到八成的打车人员打车里程在10公里以内。

当然，图表包含了非常多的内容，比如每天都流量、每个礼拜的、高峰期的比较、甚至节假日的流量等，分析比较详尽，由于最终得到比较稳定这一结论，所以这一概况也没啥好说的。

六、交通信息服务扩展

此演讲是由实际高通公司提供的，主要的内容是对自有产品的一个分析。

1、现状：

(1) 共有29个签约客户(注：待验证，此处应该是指正式商用的厂商吧，这个量也不小了)

(2) OEM汽车用户为16万以上

(3) 终端用户在150万以上(注：个人认为这个这个终端用户很宽泛，除了类似我们公司带TMC功能的PND用户外，我也是他们的终端用户，因为我会在诺基亚S60的手机上使用Google地图查看当前城市的路况信息，甚至浏览网站的用户也算)

(4) 呼叫中心的使用在250万以上(根据第一个演讲中讲到有超过60%的12580呼入与交通信息有关，以此类推这个数据还算有理有据)

2、提供的服务：

(1) 一键式交通信息播报服务(注：此是FM收音机的一个模块，仅需要一个小小的硬件就可以完成，按一下这个硬件按钮，将会自动播报当前车辆位置附近的路况，再播报全市概要路况。此功能还算是很有用的，后来有客户上台作为嘉宾讲到的时候也有说他们在开发类似的功能。)

(2) 交通信息标准服务(注：标准的交通信息服务内容，RTIC标准或TMC标准的数据内容)

(3) 交通信息增值服务

(4) 交通信息高端服务

(注：服务的标准、增值、高端等，应该是内容的区分，比如标准的RTIC内容，比如城市路况概览图，比如动态停车场服务)

3、根据统计，广播用户有6.5亿，有一半以上的司机听广播，并且以听当地交通广播为主。

4、现阶段实时交通路况所遇到的问题：

(1) 没有赶上路况播报点。(注：即通过FM广播的方式播报路况，容易有漏听的可能)

(2) 拥有全市路况而无周边路况。(注：这也是通过收听当地交通台所遇到的一个常见问题，所以开发了一键FM播报路况的模块)

(3) 导航仪+TMC后，成本和风险问题将加大。

七、洞悉市场，把握机遇——实时路况消费者研究

此演讲是由Frost&Sullivan提供，是一家市场咨询公司，为世纪高通包括车厂等提供市场研究报告，当然，不仅仅包括汽车领域。

1、中国的第一辆汽车：1901年袁世凯赠送给慈禧的六十大寿贺礼，一辆第二代奔驰小轿车。

2、两个问题：一是在政策上需要更多政府的支持，另一是望车厂的推广力度要进一步加大。

3、通过北京、上海、广州、深圳、沈阳、武汉六个城市的调研，获得的信息如下：

(1) 认知度：62比38，即三分之一的人听说过。(注：个人认为认知度还是非常不高那)

(2) 重要性：三分之一的人认为重要

(3) 满意度：82比18(注：个人认为八成的满意度不容易那，应该没有那么高)

(4) 希望汽车提供的服务排名：防盗、追踪、救援、路况、导航、电话

(5) 是否愿意为实时路况付费？63比37，六成的人愿意付费，付费的区间在5～20元每月。

(6) 用户认为实时路况中的两个重要内容：停车场和道路事件

(停车位主要由三个部分组成，大楼配套的、公共停车场、路边停车，上海的停车位在5万多，北京在6万多)

(7) 北京在堵车的情况下：汽车速度为15公里每小时，而开车也只有22公里每小时。(由此可见，在北京开车要是遇上堵车还不如骑车)

4、总结：

(1) 实时交通路况的市场会进一步提速。

(2) 车载信息的使用以简便易用为主，导航需求较大。

(3) 虽然用户愿意为实时路况服务付费，但最好由厂商来承担这部分费用。

其他一些信息

演讲部分基本由以上几个部分组成，最后附上一些图片说明。

RTIC论坛现场

世纪高通提供的两个服务产品：一个是广播的一键播报路况，另一个是当前城市路况信息概览图。

世纪高通提供的在iPhone上的路况概览软件，除了城市简图和路段简图外，还提供了详细的堵车信息列表，还是比较实用的。

另外世纪高通公司还提供了一个网站的DEMO，用于查看他们的路况信息，以及一些新成果的演示，比如动态停车场信息。

在演示台上，还有泰为公司提供了基于iPhone的导航软件演示，带有实时路况功能。

而Denso IT lab弄了个独立的展台，展示他们对最新技术的研究，还是挺佩服电装公司使用新技术对实时交通路况的研究。

上图是通过摄像头取得视频数据，然后通过图像处理技术，识别出视频中的车辆，抓取出车辆轮廓，再根据摄像头的范围尺寸，差分计算出车辆的速度，以此来获得当前道路的路况信息。我想，若采用这一技术那是否可以适当的取代一些浮动车的技术呢。

根据刚才说到的视频分析，应用到实际场景中如上图所示，架设好摄像头，然后划分出车道，抓取每个车道上的汽车，并根据视频尺寸差分计算出行车平均速度，上图中左侧为视频右侧为实时分析出来的速度数据。真是有点叹为观止了。

最后提供一个关于避免拥堵的最佳路线的PPT吧。这里是讲针对用户的驾车习惯学习，一个月以后，用户在非导航的状态下，都可以语音告知用户左转右转等机动信息。我们在市面上能够看到的是，根据导航习惯，得到导航趋势，比如上下班的时候直接友情提示用户是否开始回家路线的导航，而电装已经做到了在没有导航路线的情况下，直接通过语音告知用户行车信息，这才是分析数据的极致那。

总结：通过此次RTIC论坛，比较深入的了解了世纪高通的产品信息，并了解到了一些使用他们产品的厂商，而能看到电装这样的技术前沿展示更是大开眼界，另外虽然没有同车厂用户沟通交流上但能认识一些同行朋友也是一个视野的开阔，总的来说，这是一次收获颇丰的会议。

虽然这个摩托罗拉XT615的手机不是我的，但是经由我手购买并全权包办的。既然是新机，就拿出来晒晒，说说我的想法，所以本文就是简单的开箱照。

XT615手机的包装非常的简单，没有任何华丽的感觉，想到当年购买N72的时候，里面的包装还用了塑料成型的东西，一看就觉得很贵，但摩托的包装真有点对不起我这在一号店花2388的价格。

不过现在手机的包装也都以简约的为主了，上次拿到手上的一个LG手机也是如此，可能是出于环保的考虑吧。但XT615的包装，还挺有大厂风范的，不像山寨的做工。包装以红白两色为主，简洁明了，看起来很清爽，正面是logo、型号、机器外观，加上他们需要推广的所谓的智件园，没有一点多余，言简意赅。

侧面是标贴纸，型号、IMEI等信息，因为每一个手机都有不同的条码，这是不可能印刷在包装盒上的，所以基本上都是用贴纸的形式。

背面是产品的亮点以及必要的产品信息，仍然是非常的简单。

另外的三个侧面就不看了，一边是品牌logo，主要用于产品放在橱柜的时候让消费者一眼能看到这个品牌，另外两侧是产品图片和必要的文字说明信息。

XT615采用了上下分离式的盒子设计，掀开盖子就可以看到包装盒内的东西了。

首先呈现在面前的是手机，一般情况下都是如此的。盒子实际上分成了左右两个部分，但都是放置配件的部分。

拿出手机的时候，吓了我一大跳，心想，MD，怎么连后背盖都没有，不会丢了啥东西吧。不过，实际上后背盖就在配件里面，没有盖上可能也是情有可原，但却是会让人有心一惊的感觉。

包装盒再打开就可以看到所有的配件了。

配件实际上不少，拍了个全家福。数数的话，有：数据线兼电源线、充电器(需要配合USB线使用)、耳机、电池、后背盖、保修卡、用户手册、温馨提示和一张小卡片。

本以为小卡片是啥会员卡什么的，但实际上是为什么没有说明书的说明。

另外，还有一张温馨提示的纸条，竟然提示我：不支持热插拔存储卡！

虽然没有详细说明书和不支持热插拔这两点实际上是应该给产品减分的，但能够坦然的告知用户，这一点做的还是不错的，特别是热插拔的事情来看，一来是减少可能产生的纠纷，二来也是减少没必要的客服成本，只是这样的产品设计似乎不太科学了一些。

手机用的是BP6X的电池，电池没什么好说的，多国通用所以印刷了好几个国家的语言文字，不过有一点值得注意，这个圆形的白色标贴，非常值得一提，因为一旦拆开，白色标贴就不可能在粘合上去，所以不懂的人只需要注意到这一点也算能对这机器是否被用过而做到心中有数了。

最后说说这个薄薄的铁盖，后盖，做工薄看来是有代价的，不用不锈钢是做不出如此薄的效果吧，真担心这个铁会不会影响手机信号那。

另外还在淘宝上买了一个磨砂护盾，也就是手机套，硬壳，非塑胶软套，个人觉得硬的磨砂手感更好一些。

买一个护盾还送一个贴膜和擦布啥的，总共花费28块钱，还算非常划算的。

另外还买了品胜的充电器和替代电池。

另外还有一个moto的蓝牙耳机，199，还行。

好了，开机，传统的小机器人logo不见了，换成了moto的logo。

开机后就可以看到主界面了。再说android的系统就没有必要了，moto定制了一下系统，差别不大，方便性稍好。

moto XT615的开箱照就到此吧，最后说说这个机器。机器还算满意，首先是外观，超薄设计和皮革漆后盖，手感相当的好，其次是硬件给力，800W像素的摄像头是个亮点，但CPU和内存个人不是特别满意，最后是性价比，其实也一般，ME525的配置同这个类似，价格差距还真不是一个档次，但ME525的外观确实不太给力。以上，算是个人感受，就算是给需要购买的朋友一个参考吧，不过我老婆挺喜欢这个手机，没有办法，吸引眼球是第一要素那。