百度地图和 Google 地图的实时路况功能是如何实现的？

guimingliang

记得之前看过一篇“谷歌实时路况”的文章，提到主要的技术是通过手机基站获取手机数据来进行分析的，通过分析在单位空间和时间内主干道路的手机用户量，移动速度获取基础信息，然后关键在于建立模型，分别出道路车辆中人员的信息，过滤掉行人的信息，从而才能做到真正的实时路况！！  
出租车GPS等方式的数据采集不充分，有偶然性！！！

ryanliu74

在现在百度提供全国范围的高速公路实时路况来看，以前的猜测可能不太准确。

xifangqi

我知道高德。据说高德有个子公司，在北京，专门提供数据

0315176

五年前的文字，纯粘贴，不再看了。原文链接：我来说说TMC(信息采集、系统展示、导航作用等杂谈)

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使用红黄绿分别着色，实时路况信息就一目了然的显示了。此点算是对上面三种表现
显示全部

jtrly760321

现在看来殷浩同学的说法是比较准。
不管是采用摄像头，还是地感线圈，还是还是出租车的GPS信号，用来监测交通流量，我认为都是存在局限的。
现在大部分提供交通流量的地图，几乎所有的道路都已经能够全面提供交通流量，比如百度地图。包括高速公路，也包括城区的偏僻小路。
那就说明通过出租车车载GPS不现实的，因为高速公路和城区的偏僻小路几乎没有出租车经过。地感线圈也是不现实的，同样道理，高速公路和城区偏僻道路地感线圈数量也不会分布的这么合理，因此也是不现实的。
唯一只有一种办法，就是通过移动公司的网络检测手机用户的移动速度，进而推算出当地道路的交通情况。