TMC(Traffic Message Channel,交通信息频道)就是我们常说的实时交通路况，如果从狭义的来看，可能就是欧洲的RDS-TMC，一种基于FM广播的实时交通路况发送和接收系统，广义的理解已经完全超出了欧洲标准的限制，数据传输不仅仅可以使用FM发射，也可以使用GPRS或者DAB等方式进行传输，并且TMC已经不仅仅是交通路况信息，甚至可以传输天气信息，而最终的发展演变可能可以传送停车场车位、电影院入座、餐馆就餐等许多即时资讯，俨然是一个LBS的系统了。那么现阶段TMC的作用是什么呢？从提供的信息来看，就是告知驾驶员道路拥堵程度、突发交通事件、交通管制等交通信息，和交通广播台主持人不断播报即时路况信息类似，只不过电台是人工的语音的方式罢了。而TMC最最重要的功能是不仅仅告知用户交通信息，而是在GPS导航设备中提供导航建议，合理避开拥堵管制等交通路段，以让用户最快时间到达目的地。TMC大概就是这个样子吧，下面就细说一下个人对TMC的理解吧。
至今为止我依然不明白TMC是如何获得交通信息的，对于交警部门可能有交警值岗所以很容易得到交通信息，当然，我认为这么多的交通探头也是帮助交警获得交通信息的重要途径，而对于交通管制信息来说本身就是他们发起的自然是首先知道的，所以对于交警部门可能获得交通信息的方式非常多，但电子化的技术相对较少，可能更多需要人为判断(可能这也是最有效的办法)。而对于TMC的公司来说，当然不可能直接从交警部门获得信息(当然也有可能可以通过其他途径获得交通部门的交通信息)，那么有可能和交通部门一样，采用路况信息员的方式，定点定人完成实时路况信息的收集，交通广播台就是通过各个地方的司机朋友不断的向电台发送短信或拨打电话告知他们所遇到的路况，也算是比较有效的方式。而据说TMC公司最多的可能是采用浮动车的形式，方式也许是这样，比如与某出租车公司合作，在车上安装一个获得当前速度并不断将信息返回公司的装置，通过实时获得各个路段的车速(当然是多辆车权值后的车速)来判断道路的拥堵程度，对于交通路况来说车速就是最重要的道路拥堵与否的标准。当然在此情况下的弊端也是非常的明显，如果浮动车数量不够多，或者浮动车分布不均匀等都是影响数据质量的问题。我就在想，每个路段安装一定数量的雷达或者红外车速等，是否同样也可以达到路况监测的目的呢，不过这样的工作可能只能交通部门来做吧，一般人或公司可能做不了。
说完了数据的收集，下面就是处理，数据的处理也是一个非常关键的部分，数据的解算算法同样会影响最终数据，毕竟这么多笔数据并发反馈给服务端，如何计算如何权值都是一套科学的算法，不过个人不理解此部分，所以也说不出个所以然。另外，对于网路传输也是一个值得考虑的地方，最快的速度获得数据并以最快的速度发送到客户端，此点也很关键，如果网路慢、解算慢，最后发送的数据是半个多小时前的数据，那还算是实时路况吗，准确性也就更不用说了。一个公司对实时路况的响应时间间隔同样也是实力的体现。
信息采集并解算完成后则需要将此信息发布，发布的是电子信号，看不见听不到摸不着，非图形非语音信号对于用户来说是没有任何意义的，那么如何表现？其实方法很多，比如电台播音员的告知、拨打10086语音咨询、环路上的道路拥堵信息指示牌等等都是表现形式，只是比较简单的表现。而最多的应该是发布在WEB端或者手机端的实时路况信息，如何实现？
在此之前先说一下简单的TMC表现，一般以线性表示为主，红色表示拥堵，黄色表示缓慢，绿色表示畅通，一般是这三种情况，而对于交通事故等，除了影响到线的颜色意外，严重的需要在此位置用一交通事故的符号表示出来，其实也就是一个Point罢了。说完表现我们可以讲实现方法了：
1，最简单的办法：即时的绘制出线段的颜色和标示出交通事故点位。快速路上的道路信息拥堵指示牌就是一个最简单的绘制，已经固定的线型(LCD灯已经根据道路形态固定好形状了)，发出不同的颜色表示拥堵信息，仍然是红色黄色和绿色，最最简单的方式了。而如果基于WEB来做的话，甚至可以用SVG或者VML来绘制，而基于手机端的话，只需要带有图形引擎的绘制软件就可以了。实时路况的更新就是不断刷新图形的绘制。但这些都是比较初级的形态，但也是非常有效的形态。
2，基于WebMap的方法(个人思路)：在现有WebMap之上再绘制一层线或者点，只是WebMap自带的底图算是基础数据了。可以使用比如MapBar的引擎，或者Google Maps API，个人比较推荐Gmap API，因为如果你在浏览器上绘制非常多的Line和Point，除了内存消耗大以外，引擎也需要有这样的承受能力，比较Google的优化应该做的不错的，引擎承受能力也可以吧。而且最最重要的一点，Gmap API支持kml，你甚至只需要不断的更新你的kml数据就能表现出实时路况的效果，感觉非常的方便，但我也没有做过这样的测试，更不用说对于WebMap引擎的压力测试了。不过这种方法也是比较糟糕的，因为在大数据量的情况下，浏览器奔溃的几率较大(个人愚见)。
3，在WebMap之上叠加图片：WebMap作为底图基础数据，TMC数据作为一个图层叠加于WebMap之上，不使用画线画点的方式，而是采用叠加图片的方式，Gmap API不是已经支持overlay了吗，所以只需要生成实时路况图片叠加就可以了。至于如何生成图片，方法很简单了，就是WMS，用GeoServer或者ArcIMS等应该都可以。其实上面的第一种方法也可以直接用WMS来实现。我们仅仅需要更新后台数据库或者地图文件，WMS不断刷新输出新的路况图片，这样就可以实现动态路况了。方法也是比较简单，大多数公司的TMC的实现都采用此法吧。(如果判断错误欢迎指正。个人认为Google Map上叠加的wikipedia地图，用的也应该是overlay WMS图片的方式，而不是直接的marker)
以上是对于TMC展示的个人思路，我所能想到也大概就是这些了。那么如何作用于导航的呢，此点最为关键，我们还是说原理。其实刚刚上面有一点没有说到的是，什么地方用红色line表示，哪些用绿色的line，如何由堵车红色变成畅通的绿色等，这些如何做到的？所有的实时路况其实都和路有关，而即使每一条路都有长有短，也并不是一堵车就整条路堵车的，其实很简单，将所有的路都打断，段越多原则上表现的越细腻或者实际，一般来说在路和路的交叉口打断是比较合理的，如果还有必要则可以进一步的打断，而每一个段就是一条记录，速度信息最终会赋值到这些道路上，堵车与否的信息也就算是赋值到这些道路上了，绘图也就知道着色信息了。说的再白话简单一些，一个地区的所有路段(不是道路)都记录于数据库中，一个路段就是一条记录，而每个路段都是包含坐标信息的，这些坐标信息用于绘制Line形状，而对于每个路段的实时路况只有可能是三种情况中的一种，要么畅通要么拥堵要么缓慢，根据这三种情况对Line使用红黄绿分别着色，实时路况信息就一目了然的显示了。此点算是对上面三种表现方式的总结概括吧，但对于导航来说此点也是非常重要。
在导航电子地图中，所有的道路都是以路段的形式来表现的，每个路段就是一条记录，有形态、等级、速度、名称、单行信息等，当然更有唯一的ID标记，不然上面所说的着色也是无从谈起。理解了这些的话我们就可以将整个实现思路串起来了，也就可以理解明白TMC公司和数据公司以及导航软件公司是如何来合作的了。首先，TMC公司按照自己的方法对道路进行分段，以助于将路况信息发布到每一个路段，然后，和数据公司合作，数据公司将TMC公司提供的路况信号路段ID对应到导航电子地图中的道路路段ID，TMC公司甚至不需要考虑坐标信息，因为数据公司的电子地图中就包含了道路形态的坐标信息。而这两张ID对应表是至关重要的表，一旦对应错误则整个TMC系统表现混乱，而导航来说更是无法使用了，因为TMC发布的东路发生堵车结果地图对应到西路上堵车，那还能了得。这两张表格，术语上来讲，TMC公司提供的算是Location Table，而数据公司提供的算是Matching Table，也很容易理解，TMC公司发基于位置的路况信息表格，而数据公司就是做道路路段对应表格。对于导航公司来说，如何使用TMC信息呢，其实对于导航来说，航线规划需要考虑道路等级、道路速度、道路单行限制等信息，而TMC信息则成为影响航线规划的另一条参考信息，根据TMC提供的路况信息，将道路路段假想成等级降低、速度降低或者将道路设置成限制进入，可以说TMC信息是动态的改变道路的属性来影响整个的航线规划，当然，TMC信息的加入导致的情况是，航线规划也需要根据时间的推移不断的改变航线，让航线更加趋于合理，不可能是以前的从一个起点规划到终点中间一成不变的航线了。举例来说：某路段发生交通事故，整个路段很快由畅通变成缓慢，如果事故严重甚至会变成拥堵，而TMC即时捕捉到该信息，并解算成功，通过网络(FM/GPRS/DAB等都可以)广播发送，在GPS导航设备端已经有接收装置，接收到事故信息，原本规划通过该事故路段的航线则需要重新计算，绕过该事故路段继续行走于较畅通的路段，以免在事故路段进入堵车状态。由此可见，TMC的信息是非常有用的。
TMC技术展望。严格来说TMC技术应该算是LBS技术的一个分支，并且TMC技术是最有可能演变成LBS技术的，现阶段为什么那么多公司做TMC，并且投入大量资金，个人担心如同现在的导航电子地图行业，因为现阶段导航电子地图都很烧钱，能够赢利的为数不多，虽然十多家公司拥有导航电子地图甲级资质，但真正制作导航电子地图数据的没有几家，有些是因为自己的地图能够搭载自己的软件卖个价钱，有些就根本没有发布过导航电子地图。TMC难道也要如此发展？不得而知，看态势可能如此，业内做的最好的应该算是世纪高通公司了，加上被四维图新公司并购，前景也许不错，但暂时应该是没有赢利的，因为真正使用他们TMC上市的为数少之又少，所以我很不解。至于前景，如文章开头所言，重要之处首先打通这一通路，从数据采集技术到发布到客户的成熟应用，一路畅通的话对于后期来说是值得期待的，因为TMC本身就属于增值服务，而增值服务可以有很多内容，下次就不仅仅是TMC了，可能是天气预报、停车位信息等等等等。而对于下游行业来说，可以是导航市场，可以是10086这样的服务市场，WebMap也算是一个部分，甚至可以是ITS研究部门等。如同早年的物流，谁掌握了通路谁就控制了市场(想不起来具体句子了，但意思大概如此)。谁掌握了TMC通路技术，谁就掌握了上下游市场，不知道这样说是否片面，但至少对于上下游还是有影响的。让我们期待TMC更迅速的发展吧。
本来应该写成至少两篇文章的(一篇是基于WebMap的TMC展示，一篇是TMC如何作用于导航系统)，最后一气哈成了一篇，所以也就只能说是杂谈了，个人只是接触过一点TMC，而对TMC技术层面也不懂，杂谈的也只能算是个人对于TMC的理解吧，正确与否，还望拍砖。