道路交通信息记录服务器和GPS用户终端

暂无

道路交通信息记录服务器和GPS用户终端\n技术领域\n[0001] 本发明涉及道路交通信息采集系统，更具体地，涉及一种道路交通信息记录服务器和一种GPS用户终端，其中基于用户偏好和/或历史记录信息，实现有效道路交通信息的记录。本发明介绍了一种利用浮动用户数据和浮动用户偏好信息生成道路交通信息的方法和系统。特别是介绍了一种利用浮动用户数据和浮动用户偏好信息生成道路拥堵信息的方法和系统。本发明中，浮动用户是在道路上移动并能过终端设备向中心上传数据的人或车，浮动用户数据是由在道路上移动的浮动用户提供的数据，它至少包含三种信息，用户编号、时间信息、位置信息。浮动用户偏好信息是浮动用户驾驶车辆时的常用路线、驾驶偏好等，例如，定义上下班路线为常用路线。\n背景技术\n[0002] 已有很多公知的专利讨论了利用浮动车进行交通拥堵信息采集的方法和系统。例如，日本专利文献JP-A-7-29098公开了一种利用浮动车的位置和速度信息、计算道路的拥堵状态的系统。在这类系统中车辆向中心发送自己的位置和速度信息，系统将根据车辆的位置信息计算出车辆所处的道路，如果车辆的位置信息有误差，车辆将可能被匹配到错误的道路上，导致系统计算出来的交通拥堵信息被反应到错误的道路上，其结果就是系统输出的道路拥堵信息的精度下降。现有浮动车系统中多以出租车作为浮动车，而中国出租车上的GPS设备多属于低端设备，精度不是很高，通过实际测试得到的精度大概在30米到50米左右，而且垂直方向的高程信息精度也很差，现实中无法区分高架桥、立交桥中不同高度的道路。如果车辆的位置信息是由低精度的GPS装置获得的，车辆的位置信息往往误差就比较大；另外，在大城市中由于高楼、高架桥、复杂立交桥等对GPS信号的遮挡，车辆行驶在这些建筑的周围时也经常会出现GPS信号漂移，导致车辆被系统匹配到错误的道路上。目前在中国以上问题很常见。\n[0003] 为了解决这个问题，本发明引入用户偏好信息对车辆的位置信息进行验证，利用车辆的位置、速度信息，计算道路的拥堵状态。每个人都有自己的偏好，例如，对于相同的目的地，有些司机喜欢走路宽的环路，有些司机喜欢走车少的小路。再比如，对于上班族，平时上下班的路线可能是相对固定的，周末去电影院的路线可能是相对固定的，这些都取决于用户的偏好。如果这些用户的偏好作为用户信息被收集并保存在系统中，那么当系统利用车辆上传的数据进行计算时，即使车辆位置信息有些误差，系统也能够对车辆的位置做出正确的判断，因为系统已经获得了先验知识，知道车辆要通过的路线或者司机通常会选择的路线。\n[0004] 美国专利7,424,363(Method and system for adaptive navigationusing a driver’s route knowledge)中提到了根据司机对路径的熟悉程度提供相应路径导航，当司机对某些路段比较熟悉时，就省略这段路的路径导航，只在司机不太熟悉的路段向司机提供路径导航，这需要导航仪保存司机对路径的经验知识。美国专利7,257,484(Method forsearching car navigation path by using log file)中提到了利用导航仪保存的路径记录提供导航，导航仪在为用户计算路径前，首先从历史记录中查找，看是否有目的地相同的路线记录可以直接选用，。这两个专利中提到了如何用司机经验信息和导航仪的历史记录信息去提供导航功能，但这些信息都只保存在单个导航仪上，没有上传到中心，由中心进行分类分析，更没有提出将这些信息用于交通信息采集的方法和系统。本发明所提出系统将用户偏好和车辆行驶数据都保存在中心系统中，用于计算道路拥堵状况和向用户提供个性化的交通信息。\n发明内容\n[0005] 本发明提供了一种道路交通信息记录服务器和一种GPS用户终端。在本发明中，基于用户信息的交通信息采集系统通过收集用户的常用路线，驾驶偏好等信息建立各个用户的档案，向用户提供个性化的交通信息服务，并采集用户车辆行驶过程中的位置和速度信息生成道路的拥堵信息，在此过程中，用户信息被用于提高数据采集的精度，使得生成的道路拥堵信息比现在的浮动车系统更加准确。\n[0006] 根据本发明的第一方案，提出了一种道路交通信息记录服务器，包括：收发装置，用于接收GPS用户终端实时上报的所述GPS用户终端的GPS信息；存储装置，用于存储地图信息、所述GPS用户终端的预测路线、和所述GPS用户终端的有效GPS信息；以及筛选装置，用于根据所述地图信息，则将与所述GPS用户终端的预测路线相符的所述GPS用户终端的GPS信息作为所述GPS用户终端的有效GPS信息记录在所述存储装置中。\n[0007] 优选地，所述GPS用户终端的预测路线是由所述GPS用户终端所属的用户通过所述GPS用户终端预先设置、并上报给所述道路交通信息记录服务器的，以及所述收发装置还用于接收由所述GPS用户终端上报的所述GPS用户终端的预测路线。\n[0008] 优选地，所述收发装置还用于接收由所述GPS用户终端预先上报的起点和终点，所述道路交通信息记录服务器还包括：预测路线生成装置，用于根据所述起点和所述终点，预先生成所述GPS用户终端的预测路线，以及所述收发装置还用于将所述预测路线生成装置生成的所述GPS用户终端的预测路线发送至所述GPS用户终端。\n[0009] 优选地，所述道路交通信息记录服务器还包括：预测路线生成装置，用于根据所述GPS用户终端的历史有效GPS信息，通过聚类操作生成所述GPS用户终端的预测路线。\n[0010] 优选地，所述道路交通信息记录服务器还包括：预测路线生成装置，用于根据所述GPS用户终端的历史有效GPS信息和所述GPS用户终端所上报的GPS信息，生成所述GPS用户终端的预测路线。\n[0011] 优选地，所述道路交通信息记录服务器还包括：预测路线生成装置，用于根据所述GPS用户终端所属的用户的用户路线偏好信息和所述GPS用户终端的所上报的GPS信息，生成所述GPS用户终端的预测路线。进一步优选地，所述收发装置还用于接收由所述GPS用户终端预先上报的所述用户路线偏好信息。或者，所述用户路线偏好信息是由所述预测路线生成装置根据所述GPS用户终端的历史有效GPS信息通过聚类操作获得的。\n[0012] 优选地，所述道路交通信息记录服务器还包括：推算装置，用于根据当前位于每条道路上的所有GPS用户终端的有效GPS信息，推算出每条道路上的道路交通信息。\n[0013] 优选地，所述预测路线生成装置还根据每条道路上的道路交通信息，更新所述GPS用户终端的预测路线。\n[0014] 优选地，所述GPS用户终端的GPS信息至少包括：所述GPS用户终端的当前位置，以及所述GPS用户终端的有效GPS信息至少包括：所述GPS用户终端的预测路线上与所述GPS用户终端的当前位置相对应的位置。更优选地，所述GPS用户终端的GPS信息还包括：\n与所述GPS用户终端的当前位置相对应的上报时间，以及所述GPS用户终端的有效GPS信息还包括：与所述GPS用户终端的当前位置相对应的上报时间。\n[0015] 优选地，如果所述GPS用户终端的当前位置与所述GPS用户终端的预测路线之间的最短距离小于等于预设阈值，则所述筛选装置确定所述GPS用户终端的当前位置与所述GPS用户终端的预测路线相符。\n[0016] 优选地，如果所述GPS用户终端的当前位置与所述GPS用户终端的预测路线之间的最短距离小于等于所述GPS用户终端的当前位置与所述地图信息中所有其他路线之间的最短距离，则所述筛选装置确定所述GPS用户终端的当前位置与所述GPS用户终端的预测路线相符。\n[0017] 优选地，所述筛选装置包括：匹配单元，用于根据所述地图信息，将所述GPS用户终端的当前位置匹配到所述地图信息中的路线上，得到一个或多个匹配路线结果；以及选择单元，用于根据所述GPS用户终端的预测路线，从所述一个或多个匹配路线结果中选择位于所述GPS用户终端的预测路线上的一个匹配路线结果，作为所述GPS用户终端的有效GPS信息。\n[0018] 更优选地，所述存储装置还用于存储所述GPS用户终端所属的用户的用户路线偏好信息，以及如果所述一个或多个匹配路线结果中的任何一个都未位于所述GPS用户终端的预测路线上，则所述选择单元根据所述用户路线偏好信息，从所述一个或多个匹配路线结果中选择符合所述用户路线偏好信息的一个匹配路线结果，作为所述GPS用户终端的有效GPS信息。进一步优选地，所述GPS用户终端的预测路线是由所述GPS用户终端所属的用户通过所述GPS用户终端预先设置、并上报给所述道路交通信息记录服务器的，以及所述收发装置还用于接收由所述GPS用户终端上报的所述用户路线偏好信息。或者，所述用户路线偏好信息是根据所述GPS用户终端的历史有效GPS信息通过聚类操作获得的。\n[0019] 更优选地，如果所述GPS用户终端的当前位置与所述地图信息中的一条路线之间的最短距离小于等于预设阈值，则所述匹配单元将所述路线作为所述一个或多个匹配路线结果之一。\n[0020] 根据本发明的第二方案，提出了一种GPS用户终端，包括：GPS单元，用于实时采集所述GPS用户终端的GPS信息；存储装置，用于存储地图信息和所述GPS用户终端的预测路线；筛选装置，用于根据所述地图信息，确定所述GPS单元所采集的GPS信息是否与所述GPS用户终端的预测路线相符；以及收发装置，用于将与所述GPS用户终端的预测路线相符的所述GPS用户终端的GPS信息作为所述GPS用户终端的有效GPS信息发送至道路交通信息记录服务器。\n[0021] 优选地，所述GPS用户终端的预测路线是由所述GPS用户终端所属的用户预先设置的。\n[0022] 优选地，所述收发装置还用于向所述道路交通信息记录服务器上报由所述GPS用户终端所属的用户预先设置的起点和终点，所述道路交通信息记录服务器根据所述起点和所述终点，预先生成并向所述GPS用户终端发送所述GPS用户终端的预测路线，以及所述收发装置还用于接收由所述道路交通信息记录服务器发送的所述GPS用户终端的预测路线。\n[0023] 优选地，所述GPS用户终端还包括：预测路线生成装置，用于根据所述GPS用户终端的历史有效GPS信息，通过聚类操作生成所述GPS用户终端的预测路线。\n[0024] 优选地，所述GPS用户终端还包括：预测路线生成装置，用于根据所述GPS用户终端的历史有效GPS信息和所述GPS用户终端所上报的GPS信息，生成所述GPS用户终端的预测路线。\n[0025] 更优选地，所述存储装置还用于存储所述GPS用户终端的历史有效GPS信息。\n[0026] 更优选地，所述收发装置还用于接收由所述道路交通信息记录服务器发送的所述GPS用户终端的历史有效GPS信息。\n[0027] 优选地，所述GPS用户终端还包括：预测路线生成装置，用于根据所述GPS用户终端所属的用户的用户路线偏好信息和所述GPS用户终端的所上报的GPS信息，生成所述GPS用户终端的预测路线。\n[0028] 更优选地，所述用户路线偏好信息是由所述GPS用户终端所属的用户预先设置的。\n[0029] 更优选地，所述收发装置还用于接收由所述道路交通信息记录服务器发送的所述用户路线偏好信息。\n[0030] 更优选地，所述用户路线偏好信息是由所述预测路线生成装置根据所述GPS用户终端的历史有效GPS信息通过聚类操作获得的。\n[0031] 进一步优选地，所述存储装置还用于存储所述GPS用户终端的历史有效GPS信息。\n[0032] 进一步优选地，所述收发装置还用于接收由所述道路交通信息记录服务器发送的所述GPS用户终端的历史有效GPS信息。\n[0033] 优选地，所述收发装置还用于接收由所述道路交通信息记录服务器发送的每条道路上的道路交通信息。\n[0034] 更优选地，所述预测路线生成装置还根据每条道路上的道路交通信息，更新所述GPS用户终端的预测路线。\n[0035] 优选地，所述GPS用户终端的GPS信息至少包括：所述GPS用户终端的当前位置，以及所述GPS用户终端的有效GPS信息至少包括：所述GPS用户终端的预测路线上与所述GPS用户终端的当前位置相对应的位置。更优选地，所述用户终端的GPS信息还包括：与所述GPS用户终端的当前位置相对应的采集时间，以及所述GPS用户终端的有效GPS信息还包括：与所述GPS用户终端的当前位置相对应的采集时间。\n[0036] 优选地，如果所述GPS用户终端的当前位置与所述GPS用户终端的预测路线之间的最短距离小于等于预设阈值，则所述筛选装置确定所述GPS用户终端的当前位置与所述GPS用户终端的预测路线相符。\n[0037] 优选地，如果所述GPS用户终端的当前位置与所述GPS用户终端的预测路线之间的最短距离小于等于所述GPS用户终端的当前位置与所述地图信息中所有其他路线之间的最短距离，则所述筛选装置确定所述GPS用户终端的当前位置与所述GPS用户终端的预测路线相符。\n[0038] 优选地，所述筛选装置包括：匹配单元，用于根据所述地图信息，将所述GPS用户终端的当前位置匹配到所述地图信息中的路线上，得到一个或多个匹配路线结果；以及选择单元，用于根据所述GPS用户终端的预测路线，从所述一个或多个匹配路线结果中选择位于所述GPS用户终端的预测路线上的一个匹配路线结果，作为所述GPS用户终端的有效GPS信息。\n[0039] 更优选地，所述存储装置还用于存储所述GPS用户终端所属的用户的用户路线偏好信息，以及如果所述一个或多个匹配路线结果中的任何一个都未位于所述GPS用户终端的预测路线上，则所述选择单元根据所述用户路线偏好信息，从所述一个或多个匹配路线结果中选择符合所述用户路线偏好信息的一个匹配路线结果，作为所述GPS用户终端的有效GPS信息。进一步优选地，所述用户路线偏好信息是由所述GPS用户终端所属的用户预先设置的。或者，所述收发装置还用于接收由所述道路交通信息记录服务器发送的所述用户路线偏好信息。或者，所述用户路线偏好信息是根据所述GPS用户终端的历史有效GPS信息通过聚类操作获得的。\n[0040] 更优选地，如果所述GPS用户终端的当前位置与所述地图信息中的一条路线之间的最短距离小于等于预设阈值，则所述匹配单元将所述路线作为所述一个或多个匹配路线结果之一。\n[0041] 根据本发明，所述GPS用户终端是车载GPS用户终端或手持式GPS用户终端。更优选地，所述车载GPS用户终端是公交车车载GPS用户终端。\n[0042] 根据本发明的第三方案，还提出了一种公交车车载GPS用户终端，包括：GPS单元，用于实时采集所述GPS用户终端的当前位置；存储装置，用于存储地图信息和所述公交车的规定路线；筛选装置，用于根据所述地图信息，确定所述GPS单元所采集的GPS信息是否与所述公交车的规定路线相符；以及收发装置，用于将所述公交车的规定路线上与所述GPS用户终端的当前位置相对应的位置和上报时间作为所述GPS用户终端的有效位置点信息发送至道路交通信息记录服务器。\n[0043] 优选地，所述公交车的规定路线包括多条规定路线，以及所述公交车车载GPS用户终端还包括：规定路线选择单元，用于根据用户的操作，从所述多条规定路线中选择一条作为所述公交车的当前规定路线。其中，所述筛选装置仅确定所述GPS单元所采集的GPS信息是否与所述公交车的当前规定路线相符。\n[0044] 本发明中定义由用户提供的车辆行驶数据为浮动用户数据(FUD，Floating User Data)，同时定义提供FUD的用户为浮动用户(FloatingUser)，或简称为用户。本发明目的在于利用用户偏好信息和浮动用户数据共同生成道路拥堵信息，并向用户提供个性化的信息服务。系统获得用户偏好信息(如常用路线，驾驶偏好等)，即系统先保存了关于用户的先验知识；然后采集用户在实际行驶过程中的位置、速度信息，综合用户的驾驶偏好、车辆位置、速度信息进行计算，生成道路的拥堵信息。\n[0045] 浮动用户的出行方式可以是多种多样的，步行、自驾、公交、地铁，但一般情况下只有用户自己驾驶或是乘坐公共道路交通工具时才比较关心道路的拥堵情况。用户的出行偏好是由系统分析用户的历史出行记录而生成，如通过分析用户车辆的轨迹，发现用户对路径选择的偏好，例如用户从地点A到地点B时常用的路线，偏好于走主路而不是辅路。浮动用户的出行偏好也可以是由用户主动提供的信息，如上下班常用路线，去电影院常走的路线等，从A点到B点经常乘坐的公交车路线等。\n[0046] 浮动用户的信息建立后保存在位于中心系统的用户信息数据库中。当用户驾车或乘车出行时，如果用户向中心系统发出请求，要求获得到达某一目的地的交通信息，那么中心就将当前的交通信息发送到用户所拥有的终端设备上。并开始采集用户车辆行驶过程中的位置和速度信息，结合用户偏好(如常用路线，对主路和辅路的选择偏好等)对采集来的用户车辆数据进行处理，得到用户所经过的路线的道路拥堵状况。整个路网的道路拥堵状况通过对所有浮动用户车辆数据进行处理而得到。即使用户(如公交车、出租车等浮动用户)不向中心系统请求交通信息，只要浮动用户向中心系统发送浮动用户数据，中心系统就可以根据浮动用户数据和浮动用户偏好计算道路拥堵状况。\n[0047] 本系统中的浮动用户既可以是私车驾驶者、公车驾驶者，也可以是出租车司机和公交车司机等公共交通工具的驾驶者，甚至可以是普通的乘客或步行者。系统从浮动用户的众多历史轨迹中分析出来用户的出行或驾驶偏好。如出租车司机往来于机场和火车站之间常用的路线。如果浮动用户是公交车司机，那么其驾驶的公交车的行驶路线也是相对固定的，可以将其作为用户驾驶偏好来保存，如果浮动用户是公交车本身，那么其行驶路线也是相对固定的，可以将其作为用户驾驶偏好来保存。系统建立浮动用户的出行或驾驶偏好档案后，在对浮动用户数据进行处理时就要参考浮动用户的出行或驾驶偏好。\n[0048] 不同于传统的浮动车系统只提供无差别的道路拥堵信息，本系统可以很方便的根据用户的请求，直接向用户提供基于用户请求的交通信息，并且将用户对交通信息的请求作为触发条件，触发用户端设备上传车辆的行驶信息。在对用户上传的车辆的行驶信息进行处理时，因为中心系统已知用户偏好信息，所以处理结果也比较传统的浮动车系统更加准确。\n附图说明\n[0049] 通过下面结合附图说明本发明的优选实施例，将使本发明的上述及其它目的、特征和优点更加清楚，其中：\n[0050] 图1.1是本发明的一个实施例的系统结构图(中心系统——服务器)；\n[0051] 图1.2是本发明的另一实施例的系统结构图(终端系统——GPS用户终端)；\n[0052] 图2.1是示出了用户信息数据库100中所包含的数据结构的示意图，其中(a)是用户驾驶偏好信息的示意图，(b)是用户常用路线信息的示意图，以及(c)是用户常用路线中所包含路链信息的示意图；\n[0053] 图2.2是GPS点进行路链匹配的示意图；\n[0054] 图2.3A～2.3D示出了车辆位于交叉路口时进行路链匹配的示意图；\n[0055] 图2.4示出了车辆位于区分主辅路的道路上时进行路链匹配的示意图；\n[0056] 图3是用户信息采集装置结构图；\n[0057] 图4是浮动用户数据分析装置分析用户常用路线和驾驶偏好等信息的流程图；\n[0058] 图5是示出了浮动用户上传的浮动用户数据和浮动用户轨迹的示意图，其中(a)是浮动用户上传的浮动用户数据示例，以及(b)是浮动用户轨迹的示例；\n[0059] 图6示例了浮动用户的三条轨迹经过聚类后形成的常用路线；\n[0060] 图7示例了如何从用户轨迹中提取用户习惯信息；\n[0061] 图8是另一客户端系统示意图；\n[0062] 图9是浮动用户数据采集装置结构图；\n[0063] 图10是浮动用户为自驾车用户时路链信息生成装置生成路链信息的流程图；\n[0064] 图11是分别示出了用户按照和未按照常用路线行驶时上传GPS数据的示意图，其中(a)是用户常用路线示意图，(b)是用户按常用路线行驶时上传GPS数据示意图，以及(c)是用户未按常用路线行驶时上传GPS数据示意图；\n[0065] 图12是路链信息的一个示例；\n[0066] 图13是为了管理公交用户(包括公交车辆、公交车辆驾驶员、公交车乘客)而提供的数据结构的示意图，其中(a)是公交用户编号与公交路线编号对应图，以及(b)是公交路线编号与路链编号对应图；\n[0067] 图14是公交车辆数据示例；\n[0068] 图15是包含公交车路线设定模块406的另一客户端示意图；\n[0069] 图16是浮动用户为公交车(司机)或乘客时路链信息生成装置生成路链信息的流程图；\n[0070] 图17是浮动公交用户与中心系统之间进行数据交互的流程图；\n[0071] 图18是浮动用户是出租车用户时路链信息生成装置生成路链信息的流程图；\n[0072] 图19是偶尔改变路线的浮动用户的路线示意图，其中(a)是浮动用户常用路线示意图，以及(b)是浮动用户临时改变路线示意图；\n[0073] 图20是浮动用户和中心系统之间互惠合作示意图。\n具体实施方式\n[0074] 为了清楚详细的阐述本发明的实现过程，下面给出了一些本发明的具体实施例。\n需要说明的是，本发明并不局限于这些应用，而是可适用于更多其它相关的浮动用户道路交通系统。\n[0075] 下面参照附图对本发明的优选实施例进行详细说明，在描述过程中省略了对于本发明来说是不必要的细节和功能，以防止对本发明的理解造成混淆。\n[0076] 图1.1是本发明的一个实施例的系统结构图(中心系统——服务器)，包含一个用户信息数据库100，用于保存用户的偏好信息，例如：用户的常用固定路线、常用目的地以及其它一些驾驶偏好；一个用户信息采集装置200，通过分析用户历史驾驶信息(例如GPS轨迹)生成用户的驾驶偏好，或者接收用户手动输入的信息，该信息采集装置生成的数据将保存在前述用户信息数据库100中；一个位于中心的浮动用户数据采集装置300和一个浮动用户数据库130，用于采集和保存车辆的位置、速度、方向等信息；终端用户系统400将车辆的实时位置、速度、方向等信息上传到位于中心的浮动用户数据采集装置300；一个路链信息生成装置500和路链信息数据库150，路链信息生成装置500以用户信息数据库\n100、浮动用户数据库130、地图数据库120为输入，输出保存在路链信息数据库150中，其主要保存路链的交通信息。一个用户请求响应装置600用于处理用户的请求，并返回结果给用户，同时用户的请求将触发中心系统开始采集用户的车辆行驶信息，即浮动用户数据。\n[0077] 图1.2是本发明的另一实施例的系统结构图(终端系统——GPS用户终端)。本发明所述终端系统既可以是车载的导航设备，也可以是便携式的导航设备或有导航功能的手机等其它设备，如图1.2所示。图1.2中420是历史数据存储部件，用于存储用户历史上走过的路线信息和常用路线信息(在一些实施例中，也称为“预测路线信息”)，用户的常用路线既可以是用户通过人机交互接口设定的，也可以是由信息处理部件440通过分析历史数据得到的。GPS模块433用于采集车辆当前位置、速度等信息。信息处理部件440包含路径计算功能，以及将GPS点与地图路链进行匹配的功能。\n[0078] 当用户通过人机交互接口435设定的目的地后，信息处理部件首先进行路径计算，路径计算时可以只根据终端系统上的地图数据计算出一条最优路径，也可以根据来自中心系统的实时交通信息计算出一条最优路径(预测路线)。信息处理部件440计算出最优路径后，将其输出到显示部件437上。用户车辆沿着这条路线行驶时，GPS模块能够采集车辆的位置信息，信息处理部件440将GPS位置信息匹配到地图的路链上，并将车辆的GPS位置输出到显示部件437上。数据接收发送部件450将车辆的实时GPS信息以及所匹配上的路链的信息上传到中心系统。中心系统接收到用户车辆的GPS信息和路链信息后，就能将其用于实时交通信息计算。信息处理部件在将GPS点匹配到路链上后，首先判断匹配上的路链是否属于计算出来的路线(预测路线)，如果不属于，那么说明GPS点发生了漂移或者用户车辆没按照计算路线行驶，此GPS数据和路链数据将被抛弃，不上传到中心系统。这样就保证了中心系统所获得的GPS信息和路链信息是准确的，减少了由GPS漂移带来的误差。\n[0079] 用户偏好信息指用户的常用路线、驾驶偏好，如上下班常用路线，去电影院常走的路线等等。图2.1是用户偏好信息的一个例子。在图2.1中，(a)是用户驾驶偏好信息的示例图，其中的“平均速度”代表用户在顺畅的道路上通常的行驶速度；“主/辅路选择”表示用户在驾驶时更喜欢走主路还是更喜欢走辅路；“优先项”是指用户在选择路线时的偏好，时间优先表示用户总是选最快路径，距离优先表示用户总是选最短路径，费用优先表示用户总是选择费用最少的路径，费用包括燃油费用，道路通行费用等。熟悉区域表示用户经常驾车出现或通过的地区。在图2.1中，(b)是用户常用路线信息的示例图，其中显示了几条用户常用路线的信息，如上下班的路线和去电影院的路线。在图2.1中，(c)是用户常用路线中所包含路链信息的示例图，其中显示了一条路线所包含的路链信息，在地图中一条路线是由多条路链所构成。用户车辆位置信息上传到中心后，被匹配到地图路链上。在这一匹配过程中，通常情况下，如果GPS数据的精度比较低，GPS信号发生了漂移，或者GPS数据有缺失，那么用户车辆就可能匹配到错误的路链上，最终影响系统生成道路拥堵程度的计算精度。但是在本发明所述系统中，因为用户偏好被记录保存在中心系统，系统已经知道用户车辆会通过哪些路链，所以即使GPS数据的精度比较低、GPS信号发生了漂移、或者GPS数据有缺失，用户车辆仍然能够匹配在正确的路链上。\n[0080] 图2.2示例了GPS点匹配到路链的过程，一般来说，GPS点到路链的匹配是采用最短距离法，即将GPS点匹配到离该点最近的路链上。在图2.2中，(a)示意了一条常用路线L和两个路链1、2，其中路链1是常用路线L中的一条路链，路链1是一条主路，路链2是一条辅路，两者距离较近，用户车辆实际处于路链1上。假设用户车辆经过路链1时上传了一个GPS点A，如图2.2中的(b)所示，因为GPS点发生漂移，使得该点到路链2的距离更近。\n进行匹配计算时，首先计算A点到路链1和路链2的垂直距离，得到距离分别为X1和X2，同时A1和A2分别为A点到路链1和路链2的垂直投影点；然后比较X1和X2的大小，在本例中A点更接近路链2，所以X2小于X1，通常情况下，依据最短距离原则A点将被匹配点路链2，A2为A点在路链2上的垂直投影点，所以A2就是匹配后用户在路链2上的位置。但是实际上，用户是处于路链1上，匹配结果与实际情况不符。采用本发明所述方法时，因为用户的常用路线已经被保存在中心系统中，系统保存了用户将通过路链1这一先验知识，那么即使X2小于X1，本发明所述匹配方法也会认定A点匹配到路链1上，A1将是匹配后用户在路链1上的位置，这与实际情况相符。\n[0081] 当然用户也可能偶尔不按照常用路线行驶，如图2.2中的(c)所示，用户可能实际上就是行驶在路链2上，那么按照最短距离将A点匹配到路链2得到的是正确的结果。但是因为路链1位于常用路线中，路链2不是常用路线的组成部分，所以用户实际行驶在路链\n1上的统计概率大于行驶在路链2上的统计概率，即将A点匹配到路链1上的正确率总是大于将A点匹配到路链2上的正确率。\n[0082] 在本发明中，对匹配点的处理可以按照两种方法处理。第一种方法是，如果GPS点附近有常用路线，既使GPS点到该常用路线上的路链的垂直距离不是最短的，如图2.2中的(b)所示的情况，那么GPS点也被匹配到常用路线上。这种方法能够处理GPS发生较大漂移的情况，虽然整体的匹配正确率比较传统的最短距离法高，但是不能完全避免误判。第二种方法是，如果GPS点的附近有常用路线，且GPS点到该常用路线上的路链的垂直距离是最短的，才将GPS点匹配到常用路线上，否则将该GPS点抛弃，不再用于计算道路交通信息。这种方法可以减少误判，但是可能会抛弃一会原本可用的GPS数据，减少系统可用的数据量。\n另外，对于GPS点发生缺失的情况，就只能采用第一种方法进行判断，即认定用户就是按照常用路线行驶的，如图2.2中的(d)所示，路链1和路链2附近没有GPS点，那么中心系统根据常用路线信息，认定用户行驶在路链1上。\n[0083] 当车辆位于交叉口的拐角处时，同时既定路线也正好是一条转弯路线，那么前述两种匹配方法都有可能出现错误。图2.3A～2.3D示出了车辆位于交叉路口时进行路链匹配的示意图。为了清楚起见，这里示出了实际道路的场景，但是应当注意的是，在整个浮动车系统中，路链均为以起点和终点标识的线段，并不具有宽度。\n[0084] 对于图2.3A和2.3C所示情形，GPS点与终端既定线路的垂直距离最短，匹配结果与实际情况相符；但对于图2.3B和2.3D所示情形，上传的GPS点与终端既定线路中纵向的路链的垂直距离最短，判定匹配到纵向的路链上，但车辆的真实位置在横向的路链上，匹配出错。但是这种情况对交通信息计算的准确性影响很小，因为系统在计算道路交通信息时是根据同一路线上前后多个点进行计算的，对于图2.3B和2.3D所示情形，虽然发生匹配错误，但是出现错误的两条路链是前后相连的两条路链，而且都是处于同一既定路线上，所以这一错误对交通信息的计算影响很小。\n[0085] 当车辆位于区分主辅路的道路上时，那么前述两种匹配方法也有可能出现错误。\n图2.4示出了车辆位于区分主辅路的道路上时进行路链匹配的示意图。\n[0086] 情景(A)：终端在既定路线上行驶，GPS信息也位于既定路线上，采用两种方法都能进行正确的匹配。情景(B)和(C)：终端在既定路线上行驶，GPS信息不在既定路线上，采用前述第一种匹配方法时，能进行正确的匹配，采用前述第二种方法时，两个GPS信息将被抛弃，也不会引入错误。对于情景(E)，终端没在既定路线上行驶，GPS信息也不在既定路线上，采用前述第一种匹配方法时，会进行错误的匹配，采用前述第二种方法时，该GPS信息将被抛弃，不会引入错误。对于情景(D)，终端没在既定路线上行驶，但GPS信息漂移到既定路线上，前述两种方法都无法正确匹配。这种情况属于很少数的情况，对于道路交通信息的精度影响很小。这种情况下必须根据该点前后GPS点的情况进行判断，前提是该点前后GPS位置的匹配是正确的，否则也无法得到正确的匹配结果。已经有公知技术利用GPS点的前后点关系纠正GPS点的漂移，这不属于本发明的内容，在此不进行赘述。\n[0087] 用户偏好信息可以通过分析浮动用户数据(历史有效GPS信息)来得到，浮动用户数据可以通过用户的手机等便携式设备上传，也可以通过用户车辆的车载导航仪上传。\n用户偏好信息也可以由浮动用户通过人机界面主动输入，例如通过中心提供的用户网站，或是通过车载导航仪连接到中心系统。图3显示了一个用户偏好信息采集子系统，该子系统中浮动用户数据分析装置220或人机界面装置210采集到用户偏好信息，保存在位于中心的用户信息数据库100中。浮动用户数据分析装置220和浮动用户数据库202可以位于中心，也可以位于用户端的设备中。人机界面分布于中心端和用户端。用户设备通过网络与中心连接，传递浮动用户数据和用户输入的用户偏好信息。用户信息数据库100中包含有图2.1中所列的所有信息，如果用户为私家车驾驶者，除了系统可以自动分析用户的偏好信息，用户也可以过人机界面输入用户偏好信息，如平均速度、熟悉区域，常用路线等。并且中心系统可以通过不断的分析浮动用户数据对用户偏好信息进行自动更新。用户也可以通过人机界面不断的更新自己的出行、驾驶偏好。如果浮动用户为公交车，公交车的运行路线是相对固定的，除了系统可以自动分析出公交车的运营路线等偏好信息，也可以将公交车的运营路线和时刻表作为用户偏好信息手动输入到用户信息数据库中。\n[0088] 图4示例了浮动用户数据分析装置220如何从保存在浮动用户数据库中的历史数据中分析得到浮动用户的常用路线和驾驶偏好等用户信息。图5中的(a)为浮动用户上传的浮动用户数据的示例，这些数据保存在浮动用户数据库中。它包含用户编号、路线编号、路链编号、经纬度、速度、方向、时间等。其中用户编号、经纬度、时间是必需的，其它数据内容可以为空，这取决于系统的需求和客户端所能上传的数据的内容。用户编号用于确定浮动用户的身份；经纬度和时间用于确定浮动用户在某一时间所处的位置。路线编号用于确定浮动用户所行驶的路线，路链编号用于确定浮动用户当前所处的路链。如果浮动用户客户端的设备比较先进，例如是车载导航仪，车辆位置可能在导航仪上就直接匹配到路链上了，那么浮动用户数据就可以包含浮动用户所处的路链信息。浮动用户数据的内容并不局限于图5中的(a)所示的内容和格式，中心系统可以根据客户端的输入增加或减少保存在浮动用户数据库的数据项。\n[0089] 图4中步骤S221将每个浮动用户的上传的浮动用户数据进行分类，得到多条轨迹，每条轨迹由一连串的位置信息组成(如GPS点)。图5中的(b)为浮动用户轨迹的示例。每条轨迹中包含了用户编号，轨迹编号和轨迹中的每个GPS点的经纬度和时间信息。\n对于出租车来说每条轨迹都有可能是一次载客行驶的轨迹，如从机场到市中心某酒店，或从某酒店到机场。对于私家车来说，一条轨迹则可能是一次上、下班轨迹。如果轨迹中的GPS点的密度比较高，能保证轨迹中的每条路链上都有GPS点，那么轨迹中所包含的路链就能确定下来。如果轨迹中的GPS点的密度比较低，或者出现了缺失，则不能保证轨迹中的每条路链上都有GPS点，那么轨迹中所包含的路链就不能唯一确定，而这是一个普遍现象。为了解决这个问题，步骤S222根据轨迹的起点的经纬度对S221中得到的轨迹进行聚类，得到一系列起点相近的轨迹。步骤S223根据轨迹的终点的经纬度对S222中得到的轨迹进行聚类，得到一系列起点终点都相近的轨迹。步骤S224根据轨迹的时间跨度和轨迹长度对S223中得到的轨迹进行聚类，得到一系列起终点、时间跨度、长度相近的轨迹。步骤S225根据轨迹中的起点时间和终点时间对S224中得到的轨迹进行聚类，最终得到一系列起终点、时间跨度、距离长度，出发时间、到达时间相近的轨迹。步骤S226将S225得到的轨迹合并为同一条轨迹。合并后的轨迹要求保证轨迹中的每条路链上都有足够的GPS点，那么轨迹中所包含的路链就能确定下来，否则就是一条无效的路线。一旦浮动用户往来于某两点之间的路线被确定下来，并且该路线被利用的频率达到一定的程度，中心系统就能将该路线作为浮动用户的一个常用路线保存在用户信息数据库中。步骤227分析浮动用户的常用路线，提取用户的驾驶偏好，作为用户偏好保存在用户信息数据库中。浮动用户数据分析装置\n220生成了新的浮动用户偏好信息后，可以立即自动保存在用户信息数据库100中，也可以经通信装置将新的偏好信息反馈给浮动用户，让浮动用户判断系统生成的偏好信息是否正确，如果用户认为不正确，那么就不保存新的用户偏好，否则将新的用户偏好保存在用户信息数据库100中。在步骤S228，转向下一用户，执行类似的操作，以提取出下一用户的用户偏好信息。\n[0090] 图6示例了浮动用户1234的三条轨迹经过聚类后形成的常用路线。在图6中，(a)、(b)和(c)中的三条轨迹中的GPS点都比较稀疏，这三条轨迹分别是浮动用户1234在三次经过起点和终点过程中所采集到的。可以看出每条轨迹中所包含的GPS点比较稀疏，不能确保所经过的每条路链上都有GPS点，中心系统就无法根据一条轨迹在地图中唯一确定车辆从起点到终点所经过的路线。传统的方法是用路径推测的方法来推算出几条从起点到终点的路线，然后根据最短距离或最短时间原则从中挑选出一条最有可能的路线作为从起点到终点的路线。这种路径推测的方法的准确度并不是很高，特别是当GPS点精度和密度本身就不太高时。为了解决这个问题，本发明用轨迹聚类的方法来提高GPS点的密度，经聚类后形成的轨迹中的GPS点比较密，如图6中的(d)所示，每条路链上都至少有一个GPS点，从而可以唯一的确定一条路线作为用户的常用路线。之所以称之为常用路线，是因为只有在用户经常通行的路线上，系统才有可能在起点到终点之间采集到相互重复的轨迹，才有可能对轨迹进行聚类。图6中只用了三条轨迹举例，实际上常用路线可以由更多的用户轨迹聚类形成，参与聚类的轨迹越多，常用路线中的GPS点就越密，路线就越精确。图2.1中的(b)、(c)是聚类后生成的用户常用路线的示例。图2.1中的(c)显示了每条路线所包含的路链情况。\n[0091] GPS点的密度提高后，某些情况下GPS点的误差还是会影响系统对用户路线的确定，如对于两条平行相邻的道路(主辅路)，地图上是用两条平行的路链来表示的，GPS数据误差有可能导致车辆被匹配到错误的路链上。传统方法是根据车辆运动的方向和地图的拓扑关系来修正GPS点精度不高引起的地图匹配错误。但是对于两条相邻的主辅路，因为其路链的方向和拓扑关系都是一样的，所以很难用传统方法进行区分。图7中的(a)显示了两条平行相邻的路链A和B，分别是主路A和辅路B。假设浮动用户的实际常用路线是辅路B，浮动用户每次通过路链B时只上传一个GPS点，因为GPS误差，系统很难从GPS数据判断出浮动用户实际行驶在主路上还是辅路上。但是经过前述聚类计算后，这段道路上的GPS点密度大大提高，可以获得大量的GPS点，如图7中的(b)所示。通过大量的测量试验与观察分析发现，随着时间的不同、卫星分布状态的改变以及天气的变化，GPS数据都有不同曲线方向的飘移，但是其分布状态接近于正态分布。即浮动用户行驶在某条路链上时，其上传的GPS数据应该是较平均的散布在路链两侧的。计算路链A的起点到路链A两侧GPS点的连线与路链A的夹角，夹角大小从负180度到正180度，求所有夹角的和，记为SumA，如图7中的(c)所示。同样计算路链B的起点到所有路链B两侧GPS点的连线与路链B的夹角，夹角大小从负180度到正180度，求所有夹角的和，记为SumB，如图7中的(d)所示。因为GPS的误差是接近正态分布的，如果浮动用户实际行驶在路链B上，那么SumB的绝对值应该趋近于零，并且小于SumA的绝对值。如果浮动用户实际行驶在路链A上，那么SumA的绝对值应该趋近于零，并且小于SumB的绝对值。所以通过比较SumA和SumB的绝对值可以判断浮动用户的常用路线是经过主路A还是经过辅路B。一旦在常用路线中确定了浮动用户常走辅路B，那么当浮动用户再次经过这段路时，即使只上传了一个GPS点数据或者没有上传任何GPS点数据，系统也能通过常用路线中保存的信息判断用户走的是辅路B，这比传统的路径推测的方法要准确的多。\n[0092] 一般来说，每个浮动用户的常用路线不只一个，装置220得到了一个或多个浮动用户的常用路线后，进一步分析浮动用户的常用路线，提取用户的驾驶偏好。因为用户常用路线中都包含了车辆行驶过程中的GPS位置信息，而且GPS点密度较高，所以结合地图信息可以比较容易提取用户的驾驶偏好，如用户的熟悉区域、用户对主/辅路的偏好等等。用户偏好数据的示例如图2.1中的(a)、(b)、(c)所示。\n[0093] 通过浮动用户数据分析装置不但可以分析浮动用户的常用路线，还可以分析浮动用户的其它驾驶偏好，如对主辅路的选择，经常活动的区域等。浮动用户数据分析装置不仅可以用于生成浮动用户的偏好，还可以用于中心系统定期自动更新浮动用户的偏好，这样当浮动用户的偏好发生改变时，可以不通过人机界面去修改用户信息，而是由中心系统从历史浮动用户数据中计算出新的用户偏好，自动跟踪用户偏好的变化。\n[0094] 中心系统要生成实时的道路拥堵信息，就必须能够实时采集到浮动用户在道路上的行驶数据，如位置、速度等，称之为浮动用户数据。浮动用户数据的上传可以通过安装在车辆上的定位和通信设备来完成，也可以通过司机或乘客的手机等便携式设备来完成。浮动用户通过各种客户端，经由各种无线网络将浮动用户数据上传到中心系统。图8显示了另一种客户端的结构。GPS模块403用于采集浮动用户的位置、速度等信息，通讯模块419用于将数据实时上传到中心系统。GPS模块和通讯模块既可以独立安装在用户车辆上，也可以是作为用户手机、PDA或导航仪等便携式设备或车载设备的嵌入式模块。通讯模块419可以将浮动用户数据上传到位于中心的浮动用户数据采集装置300，也可以将用户的请求上传到位于中心的用户请求响应装置600。客户端装置可以是多种形式的，可以是手机、PDA、便携/车载导航仪等，只要嵌入了定位模块(如GPS接收仪)和通讯模块(如SMS/GPRS/CDMA/)的电子设备都可以成为客户端。用户还可以通过这些客户端的人机界面输入用户偏好信息，并上传到中心。\n[0095] 浮动用户上传的实时数据，被中心的浮动用户数据采集装置300所接收，图9显示了装置300的一种结构。它包含通信模块319，用于接收浮动用户通过各种通信方式上传的浮动用户数据。用户上传的数据可能是多种格式的。数据转换模块309负责将接收到的数据转换为能够被路链信息生成装置500所识别的统一格式，并将转换后数据保存在浮动用户数据库130中。浮动用户数据库130中所保存的当前实时浮动用户数据被路链信息生成装置500用于生成实时的路链信息，进而生成实时道路交通信息。浮动用户数据库中所保存的历史浮动用户数据可被图3中的浮动用户数据分析装置220所利用，用于更新用户信息数据库100。\n[0096] 有了保存在数据库130中的浮动用户数据和保存在数据库100中的用户偏好信息，路链信息生成装置500就能生成路链的信息如拥堵状态，并将路链信息保存在路链信息数据库150中。浮动用户既可以是自驾车主，也可以是出租车司机和公交车司机等。链路信息生成装置500对这三种浮动用户的处理过程基本相同，都是要先检查中心系统中是否保存了关于浮动用户的先验知识。\n[0097] 下面举例说明当浮动用户为自驾车主时，中心系统如何生成链路交通信息。例如自驾车浮动用户1234在位于中心的用户信息数据库100中保存了自己上下班时常走的路线，如图2.1中的(b)和(c)所示，用户上下班的常用路线也可能是有多条。保存在数据库\n100中的常用路线即可以是用户主动输入的，也可以是浮动用户数据分析装置220通过分析用户车辆行驶数据得到，当然这需要浮动用户长期上传车辆行驶数据。\n[0098] 设定常用路线后，用户每天上班前向中心请求个性化交通信息服务，例如早上9点从家里到办公室的最佳上班路线和最短旅行时间，中心系统将利用当前的实时道路交通信息，计算用户所保存的多条常用上班路线中哪一条路线最畅通，然后将最佳路线返回给用户。因为上下班路线是用户自己设定的，所以最简单的情况下，中心系统只需以文本形式向用户发送最佳路线编号，用户就能明白路线的具体内容。例如向用户发送一条包含路线编号的手机短信，这种方式使得用户的终端设备可以非常简单，当然如果用户终端设备具有路线显示功能，也可以向用户发送更详细的路线或导航信息。当系统将结果返回给用户\n1234时，同时会向用户请求浮动用户数据上传。如果用户同意上传数据，那么用户一旦行驶在上班的路线上，其客户端就应该将车辆的位置、速度等信息作为浮动用户数据上传到中心系统的浮动用户数据库中，这些数据再经过中心系统的路链信息生成装置500生成实时交通信息。\n[0099] 图10是浮动用户为自驾车主时，位于中心的装置500计算路链的实时交通信息的流程图。浮动用户数据至少包含经纬度信息，所以第一步S511将浮动用户数据匹配到地图中的路链上：一般情况下，每个浮动用户数据对应若干个可能的匹配结果。步骤S513判断用户路线(常用路线或预测路线)是否已知，如果用户路线已作为用户偏好保存在数据库\n100中，例如浮动用户当前行驶路线1上，而路线1是用户的常用路线之一，被作为用户偏好保存在用户信息数据库100中。根据图2.1中的(c)所示的示例，路线1的信息中会进一步包含路链的信息。如果系统已知浮动用户将通过哪些路链，那么步骤S515就可以从浮动用户数据在地图上的多个匹配结果中，精确的计算出浮动用户实际所处的路链和在路链上的位置。\n[0100] 系统在执行步骤S515时会遇到两种情况。一种情况是，已知用户会运行在某常用路线上，例如路线1，而且用户也确实按常用路线1行驶，此时对用户所处位置的确定比较简单，只需将用户上传的GPS数据在路线1中寻找匹配点。另一种情况是，已知用户会运行在某常用路线上，例如路线1，但用户中途改变的行驶路线，没有按照计划路线行驶，那么在路线1中就找不到用户上传的GPS数据的匹配点，此时可以采用两种处理方法：1.将当前GPS数据抛弃，不做任何处理，个别车辆的GPS数据的缺失不会对整个路网产生太大影响。\n2.用最短距离法，确定用户所处的位置，即将用户上传的GPS数据匹配到最近的路链上。图\n11中的(a)是用户的常用路线1，图11中的(b)是用户按照路线1行驶时上传的GPS数据在地图上的位置，图11中的(c)是用户未按照路线1行驶时上传的GPS数据在地图上的位置，对于图11中的(b)所示的情况，尽管GPS有漂移，但用户按照路线行驶，所经过的路链已知，所以GPS位置的匹配可以非常准确。对于图11中的(c)所示的情况，部分GPS点偏离路线1太远，不可能是由GPS漂移造成的，说明了用户未按照路线行驶，车辆的实际所处路链只能根据各路链到GPS点距离远近来判断，或则干脆将该GPS数据抛弃。\n[0101] 如果用户没有设定常用路线，系统不知道浮动用户将通过哪些路链。那么图10中步骤S517根据用户保存在数据库100中的其它驾驶偏好(除常用路线以外的用户信息)等先验知识，从多个匹配点中计算出最佳的匹配点，得到浮动用户所处的路链和在路链上的位置。因为GPS信号漂移、建筑物遮挡、数据上传间隔大等等原因，并不能保证每一条路链上都能获得浮动用户数据，即当前计算所得的路链和上一条计算所得的路链可能并不相连，中间有缺失。此时，步骤S515或S517会根据已知的用户路线或驾驶偏好计算出所缺失的路链。一旦浮动用户实际所经过的路链被确定，步骤S519计算浮动用户所经过的路链的实时信息，如拥堵状态等，并将路链信息保存在路链信息数据库150中。\n[0102] 一般来说，一条路链的实时交通信息是由通过这条路链的所有浮动用户的数据计算得到的，不是由一个浮动用户的数据决定的，除非在一段时间内(例如5分钟)某路链上只有一个浮动用户通过。中心系统计算路链的实时交通信息，也是分时间段的，即路链的实时交通信息每隔一段时间更新一次(例如每隔5分钟计算一次)。图12是路链信息的一个示例，图中用路链的平均速度代表路链拥堵程度，但路链拥堵程度还可以用路链旅行时间等来表达拥堵程度，路链信息也不仅限于拥堵程度等。\n[0103] 浮动用户还可以是公交车(司机)或公交乘客，下面举例说明当浮动用户数据是公交车(司机)或公交车乘客上传的数据时，中心系统如何生成链路交通信息。因为公交路线(规定路线)相对固定，可以直接从公交公司获取每条路线所包含的路链信息，并保存在用户信息数据库100中。用户只需上传一个公交路线编号，中心系统就知道用户将要经过的所有路链。对于公交车(司机)来说，它(他)可能会被调度到不同的路线上进行行驶，对于公交乘客来说，他可能也有多条公交路线是经常走的，所以一个用户编号可能对应多条公交路线，如图13中的(a)所示，每条公交路线所包含的路链信息可以按照图13中的(b)所示的格式进行保存。如图13中的(a)所示，当用户为公交车(司机)时，“用户起点名称”对应公交路线的起点站名称，“用户终点名称”对应公交路线的终点站名称。当用户为公交乘客时，“用户起点名称”对应用户上车的站点名称，“用户终点名称”对应用户下车的站点名称。\n[0104] 以下将来自于公交车辆上的浮动用户数据称为公交车辆数据，包括公交车、公交车司机和公交乘客上传的数据。图14所示为公交车辆数据的内容。因为上传的公交车辆数据中包含用户编号和公交路线编号，所以如果公交车辆的路线信息保存在数据库100中，那么通过用户编号或公交路线编号就能很容易计算出公交车辆数据中的GPS点(经纬度信息)是对应到哪些路链上，由于公交路线很少临时改变，因此这种匹配是非常准确的。如果公交车辆的运营路线信息不可知，未被保存在信息数据库100中，就忽略这条公交车辆数据，不进行处理，即不用于生成路链实时交通信息。\n[0105] 因为公交车辆的路线和出发时刻都是相对固定的，如果浮动用户是公交车辆或公交车乘客，用户偏好采集就相对简单的多。公交车乘客可以通过图3中的人机界面提供自己经常乘坐的公交路线，公交车辆(司机)也可以通过人机界面提供车辆的路线和发车时间等。因为公交系统的运行是有一整套路线和时间安排的，所以公交车的路线和时间信息可以集中批量输入到中心系统中。即使不手动输入公交车的运营路线，只要公交车上传数据，浮动用户数据分析装置220也可通过分析历史数据自动分析出公交车的运营路线，进而设定浮动用户的偏好信息。\n[0106] 考虑到一辆公交车可能被调拨到不同的公交路线上，所以安装在公交车上的客户端设备必须能够设定当前公交车的运营路线，并且将当前路线信息和公交车的经纬度信息实时传送给中心端，公交车路线设定模块如图15中的406所示，上传的数据如图14所示。\n如果上传公交车辆数据的客户端设备为公交司机或乘客的便携式设备，如手机等。那么这些设备中也必须有相应模块能够让用户设定当前路线编号并上传到中心。\n[0107] 中心系统得到公交路线信息和实时公交车辆数据后，生成路链信息的流程图如图\n16所示。第一步S711将公交车辆数据匹配到地图中的路链上：一般情况下，每个公交车辆数据对应若干个可能的匹配结果，这种匹配不能得到准确的路链。步骤S713判断公交车辆的路线(规定路线)是否已知，即是否保存在用户信息数据库100中。如果公交车辆的路线信息保存在数据库100中，那么步骤S715可以从公交车辆数据在地图上的多个匹配结果中，准确的计算出公交车辆实际经过的路链，当前所处的路链和在路链上的位置。步骤S719计算浮动公交车辆所经过的路链的实时信息，如拥堵状态等，并将路链信息保存在路链信息数据库150中。\n[0108] 此外，由于公交车辆有可能被临时借调到其他路线上，可以允许公交公司或公交司机对规定路线进行选择。\n[0109] 当浮动用户是公交车辆或公交司机时，该用户主要是向中心上传实时公交车辆数据，并不需要中心系统反馈实时交通信息给浮动用户，因为无论交通是否拥堵，公交车辆只用按既定路线行驶。当然公交车辆也可以接收实时交通信息用于向公交车上的乘客反应当前交通状况或者预测达到下一站点所需时间，但是这一功能已经能够被现有的其它技术所实现，并不是本发明的重点，所以不再详细说明。\n[0110] 当浮动用户是公交乘客时，用户通过终端设备向中心请求去往目的地的最佳公交路线。如果用户已经在中心系统中设定了自己常用的公交路线，并且有多条常用公交路线能够达到目的地，那么中心系统根据每条公交路线所经过的道路上的交通拥堵情况，或者是公交车本身的拥挤程度，为用户选择一条最快的路线或者最舒适的路线。公交车拥挤程度信息，可以由司机操作公交车上的终端设备来设定，并上传到中心系统；也可以用现有的其它技术来实现，因为这一功能不是本发现的重点，所以不在本说明书中详细说明，而是假设中心系统能够获取每辆公交车的拥挤程度。如果用户没有事先设定往来于目的地之间的常用路线，那么中心系统可以根据实时交通信息或公交拥挤信息为用户计算出一条路线，并在用户乘车时采集用户终端设备上传的GPS信息。中心系统此时提供给用户的路线必须是换乘次数最少的，因为乘客在换乘过程中上传的GPS信息是不能用于计算交通状况的，所以必须尽量减少换乘的次数，最好是没有换乘。\n[0111] 当用户选择乘坐中心所推荐的公交路线后，可以发送路线编号给中心系统，中心系统计算用户预计到达的时间并反馈给用户。公交车行驶过程中，中心系统采集用户终端设备上传的GPS信息，当然用户也可以选择不上传GPS信息，但是，这样在旅途中用户终端设备上也就无法实时更新预计到达的时间。如果用户终端设备能够实时上传GPS信息，即使上传的频率比较慢，例如每分钟上传一次，中心系统也能够按照图16中的步骤处理GPS数据，用于计算实时交通信息。图17显示了公交车用户与中心系统之间进行数据交互的流程。在这一过程中，中心系统和公交用户实际上是采用了互惠互利合作模式。\n[0112] 当浮动用户数据是公交车辆数据时，中心系统计算出来的实时道路交通信息可以直接发送给公交乘客使用，但是不能直接发送给自驾车用户使用，需要剔除公交车停靠车站带来的误差。只有浮动用户为自驾车或出租车用户时，浮动用户数据计算所得的实时交通信息才可以直接发送给自驾车用户使用。\n[0113] 因为公交路线是相对固定的，公交路线的每天运营时间也长短不一，如果只有公交车辆数据作为浮动用户数据并不能保证覆盖所有城市道路，所以可以用出租车上传数据作为浮动用户数据进行处理。图18显示了当浮动用户数据是出租车上传的数据时，路链信息生成装置500处理出租车数据的流程。步骤S911将出租车数据匹配到地图中的路链上：\n每个出租车数据对应若干个可能的匹配结果。步骤S913判断出租车路线是否已被中心系统获知。如果出租车装有导航仪，并且司机通过导航仪向中心系统请求路径，然后按照中心系统反馈的路径行驶，那么中心系统就准确的知道出租车的路线，即所通过的路链，出租车所上传的浮动用户数据能够被准确的匹配到路链上，从而计算出路链的交通信息。即接下来可以按照步骤S915和S923来处理。如果出租车司机并不向中心请求路径导航，那么中心系统是无法知道出租车的行驶目的地，也就不能像利用浮动用户的常用路线那样，利用保存在中心系统的出租车司机常用路线。此时转到步骤S919进行处理，因为出租车可能是在不断的上传浮动用户数据的，中心系统的路链信息生成装置500将出租车的每一次载客开始，到乘客下车视为一次完整的行驶。然后将每一次行驶分为若干段轨迹，因为这些轨迹所包含的GPS点可能比较稀少，因此并不能准确的唯一确定轨迹实际所通过的路链。步骤S919中将这些轨迹的起点和终点与保存在用户信息数据库100中的司机用户偏好(常用路线)进行比较，如果能找到起终点相近的路线，就说明这是司机的常用路线，有助于推断出其所包含的路链。再次转到步骤S915，就能准确的计算出租车所经过的路链，当前所处的路链以及在路链上的位置。如果不能找到起终点相近的路线，就说明这不是司机的常用路线，就需要结合出租车司机的其他的驾驶偏好信息进行判断，即通过步骤S921计算出浮动用户所经过的路链，当前所处的路链以及在路链上的位置，但得到的结果可能比步骤S915得到的结果精度要差。步骤S923计算出租车所经过的路链的实时交通信息，如拥堵状态。\n[0114] 浮动用户的常用路线虽然是浮动用户经常走的习惯性路线，但是浮动用户也可能偶尔不按常用路线来行驶，如遇到临时交通限行。图19中的(a)为浮动用户1234每天上班的常用路线；在图19中的(b)中，虚线部分是由临时交通限行导致的用户1234上班路线的临时改变，浮动用户1234行驶在这一段道路上时，其上传的GPS数据将无法匹配常用路线，此时路链信息生成装置500既可以剔除这部分数据，不对这部分数据进行计算路链拥堵信息，也可以结合浮动用户的驾驶偏好用常规的地图匹配方法计算路链的拥堵信息。因为中心系统能实时接收到大量的浮动用户数据，而且每条路链的实时交通信息的计算是基于多个浮动用户的数据，所以对于每位浮动用户来说，其上传的数据有部分缺失并不会影响中心系统对整个路网的拥堵情况的计算。\n[0115] 另外，浮动用户的偏好也可能发生长期性的改变，例如道路长期施工，用户不得不改变路线；或者是用户发现了更好路线；或者是公交车改变了运营路线等。如果浮动用户因偏好改变，导致其上传的浮动用户数据经常性的与已知的常用路线不匹配，那么路链信息生成装置500就要将此信息反馈给用户信息采集装置200，用于更新用户的偏好信息。\n[0116] 生成了路链拥堵信息后，系统就可以向用户提供各种路线的拥堵程度或旅行时间。用户请求响应装置600用于响应浮动用户的服务请求。例如，当用户向中心系统请求某条路线的旅行时间或达到某个目的地的旅行时间时，用户可以通过手机短信或其它通信方式发送目的地名称、他要走的路线的名称或编号，如果用户请求的路线是常用路线，并且已经作为用户偏好保存在位于中心的用户信息数据库100中，那么中心系统只需要路线名称或编号信息，就知道该路线所包含的所有路链，从路链信息数据库150中可以生成整个路线的旅行时间提供给浮动用户，并且可以在用户驾驶过程中不断的提供该路线上最新的交通状态。用户往来于某些地点之间的常用路线可能有多条，那么中心系统就可以通过装置600反馈给用户多条路线的信息，供用户选择。如果用户的请求中已经包含所需的路链信息，例如用户车辆上的导航仪计算出到达目的地的路线，将该路线的详细信息发送到中心系统，那么即使这条路线不曾保存在中心系统中，用户请求响应装置600也能够提供该路线的旅行时间信息，并且还可以在路线比较拥堵时向用户反馈更好的其他路线供用户选择。如果用户请求信息中不包括路链信息，所请求的目的地也不曾保存在用户信息数据库中，中心系统仍然可以通过用户请求响应装置600生成一条或多条路线提供给用户。并且在用户驾驶过程中不断的提供该路线上最新的交通状态。\n[0117] 本发明所述系统的用户既可以是只请求服务，不提供浮动用户数据的普通用户，也可以是提供浮动用户数据的浮动用户，浮动用户也可以只提供浮动用户数据不请求服务，如出租车司机、公交车司机等。浮动用户因为提供浮动用户数据，所以可以比普通用户享受更加丰富的个性化的交通信息服务。普通用户向中心系统请求交通信息服务时，也就意味着用户要驾车出行，用户在行驶中可以通过客户端设备向中心系统上传行驶数据，此时他就由普通用户转变为了浮动用户，向系统提供浮动用户数据，而他提供的浮动用户数据又将用于中心系统生成后续的交通信息为其他的用户服务。他自己在出发前和行驶过程中所接收到的交通信息又是由基于其他浮动用户数据由中心系统计算得到的。\n[0118] 图20显示了本实施例中的浮动用户和中心系统之间是如何互惠合作的。当浮动用户A请求个性化交通信息服务时，例如早上7点从家里到办公室的最佳上班路线和最短旅行时间，中心系统将利用从其他浮动用户那得到的浮动用户数据计算用户A想要的信息。当系统将结果返回给用户A时，同时会向用户A请求浮动用户数据上传，如果用户A同意上传数据，一旦用户A行驶在上班的路线上，其客户端就能将用户A所乘车辆的位置、速度等信息作为浮动用户数据上传到中心系统的浮动用户数据库中，中心系统利用保存在浮动用户数据库的数据生成交通信息。中心系统既可以按照用户路线向用户提供个性化的交通信息，也可以向用户提供整个路网的交通信息。但是用户通常只关心自己所走的路线上的情况，所以向用户提供个性化的交通信息是非常重要的。例如，同一条路线公交乘客接收到的旅行时间和自驾车司机接收到的旅行时间可能是不同的，因为公交乘客接收到的旅行时间中包括了公交停靠站的时间。\n[0119] 由公交车辆数据所计算出来的道路拥堵情况会包含公交车停靠站的时间，这和自驾车用户想知道的信息存在差别，需要剔除公交车停靠站的影响才能被自驾车用户所利用。但是由公交车辆数据所计算出来的道路拥堵情况，能够直接被公交车乘客直接利用。例如公交乘客B从家到办公室上班有多条公交路线可供选择，乘客B是系统的浮动用户，并且已经将从家到办公室的公交路线作为用户偏好保存在中心系统中。当乘客B向中心发送请求，希望知道最快到达办公室的公交路线时。用户请求响应装置600计算每条从乘客B家到办公室的公交路线所需花费的时间，将最佳的路线返回给用户。同时请求乘客B在乘坐公交车时上传公交车辆数据。因为是乘坐公共交通车辆，所以公交乘客的个人隐私能够得到保护。即使公交乘客不愿意上传数据，大量公交车辆本身上传的数据也足够为公交乘客服务。\n[0120] 在本实施例中，如果要得到整个路网的交通信息，需要系统中有足够多的浮动用户提供浮动用户数据。为了解决这个问题，在本实施例中，浮动用户除了自驾车用户，还包括公交车辆、公交车乘客，出租车等。\n[0121] 本发明所述系统中用户的形式可以是多种多样的，无论是不提供浮动用户数据的普通用户，还是提供浮动用户数据的浮动用户，都不限于以上所提到的几种类型。任何人或物，只要乘坐交通工具，或是交通的参与者，都可以成为本发明所述系统的普通用户和浮动用户。前述实施例只是本发明的一种具体实现形式，本发明并不局限于前述实施例。因系统中普通用户或浮动用户的不同而产生的不同系统实现，都属于本发明描述的范围。\n[0122] 虽然在以上描述中，图4、图10、图16和图18都是以中心系统为执行实体对本发明进行了详细描述，但是这些方法流程并不局限于仅在中心系统实现，也可以由客户端系统实施。这样的实施例是本领域普通技术人员容易根据以上启示实现的，为了行文流畅和简洁，在此省略对这些实施例的详细描述。\n[0123] 此外，在以上的描述中，针对各个实施方式，列举了多个单元结构实例或步骤实例，虽然发明人尽可能地标示出彼此关联的实例，但这并不意味着这些实例必然按照相应的标号存在对应关系。只要所选择的单元结构实例或步骤实例所给定的条件间不存在矛盾，可以在不同的实施方式中，选择标号并不对应的实例来构成相应的技术方案，这样的技术方案也应视为被包含在本发明的范围内。\n[0124] 至此已经结合优选实施例对本发明进行了描述。应该理解，本领域技术人员在不脱离本发明的精神和范围的情况下，可以进行各种其它的改变、替换和添加。因此，本发明的范围不局限于上述特定实施例，而应由所附权利要求所限定。