著录项信息
专利名称 | 一种用于终端上显示路况的方法、装置 |
申请号 | CN201110460387.5 | 申请日期 | 2011-12-31 |
法律状态 | 暂无 | 申报国家 | 中国 |
公开/公告日 | 2013-07-03 | 公开/公告号 | CN103186986A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G08G1/0967 | IPC分类号 | G;0;8;G;1;/;0;9;6;7查看分类表>
|
申请人 | 高德软件有限公司 | 申请人地址 | 浙江省杭州市滨江区长河街道网商路699号4号楼5楼508室
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 阿里巴巴(中国)有限公司 | 当前权利人 | 阿里巴巴(中国)有限公司 |
发明人 | 胡润波;曾利非;李宾;张祥飞 |
代理机构 | 北京集佳知识产权代理有限公司 | 代理人 | 逯长明;王宝筠 |
摘要
本发明实施例公开了用于终端上显示路况的方法、装置及设备,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;所述方法包括:接收路段的路况数据;根据输入的路况查询区域和道路数据中道路的外接矩形信息,从道路数据中获得与路况查询区域相交的待显示道路;从路况数据中,获得构成待显示道路的路段的路况状态;根据待显示道路的第一类指定点的第一类坐标,绘制待显示道路;在待显示道路上显示构成待显示道路的路段的路况状态。本发明通过使用一种比现有地图体积更小的道路数据,在客户端实现了显示路况的功能,可以脱离现有地图,具有下载、升级方便的优点。
1.一种用于终端上显示路况的方法,其特征在于,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,其中所述第一类指定点为线参考上的点,该点用来代表线参考的形状及位置,所述第一类坐标为基于地图平面坐标系的坐标或经纬度坐标,所述道路由路段构成;所述方法包括以下步骤:
接收路段的路况数据;
根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;
从所述路况数据中,获得构成所述待显示道路的路段的路况状态;
根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;
在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。
2.根据权利要求1所述的方法,其特征在于,根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路的步骤具体包括:
将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标;
根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。
3.根据权利要求1所述的方法,其特征在于,在所述待显示道路上显示路况状态之前还包括:
将所述待显示道路上相连的且路况状态相同的路段进行合并。
4.根据权利要求2所述的方法,其特征在于,根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路的步骤之前还包括:
对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标,进行偏移。
5.根据权利要求4所述的方法,其特征在于,所述进行偏移之前还包括:
根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀。
6.一种用于终端上显示路况的装置,其特征在于,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,其中所述第一类指定点为线参考上的点,该点用来代表线参考的形状及位置,所述第一类坐标为基于地图平面坐标系的坐标或经纬度坐标,所述道路由路段构成;所述装置包括:
接收单元,用于接收路段的路况数据;
待显示道路获取单元,用于根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;
路况获取单元,用于从所述路况数据中,获得构成所述待显示道路的路段的路况状态;
道路绘制单元,用于根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;
路况显示单元,用于在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。
7.根据权利要求6所述的装置,其特征在于,所述道路绘制单元具体包括:
坐标转换子单元,用于将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标;
绘制子单元,用于根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。
8.根据权利要求7所述的装置,其特征在于,所述道路绘制单元还包括:
偏移子单元,用于对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标进行偏移,并在完成后通知所述绘制子单元。
9.根据权利要求8所述的装置,其特征在于,所述道路绘制单元还包括:
抽稀子单元,用于在所述进行偏移之前根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀,并在完成后通知所述偏移子单元。
一种用于终端上显示路况的方法、装置\n技术领域\n[0001] 本发明涉及交通信息领域,尤其是涉及一种用于终端上显示路况的方法、装置。\n背景技术\n[0002] 交通/旅行信息是构建智能运输系统的重要组成部分,它可以将实时和预测的道路路况及各类旅行相关的事件,以图形、文本或者语音的方式展示给终端用户,为个人出行、交通调度决策等提供重要的参考依据。一种典型的应用场景就是:在某时刻,用户想查看当前某路段或某区域的路况,如拥堵还是顺畅,则可以利用客户端(或称终端)向服务器端发送查询请求,获得服务器端返回的信息,并在客户端加以显示,从而了解该路段或区域的路况。\n[0003] 现有的一种技术方案是:\n[0004] 完全由服务端来组织应用数据,客户端只做简单呈现。例如:假如客户端需要在本地屏幕绘制某一区域内的交通信息状态,它向服务端进行请求后,服务端根据请求提取出所需的数据,实时渲染出该区域内所有道路路况信息的图片,然后返还给客户端,客户端只需要显示图片即可。方案的缺点是:一方面主要工作都是集中在服务器端,使得服务器端压力较大,另一方面该方案流量过大,占用大量的带宽,拖慢下载的速度,延长了客户端的响应时间,降低了用户体验效果。\n[0005] 现有技术中另一常见的方案是:\n[0006] 客户端预装数字地图,然后通过网络间歇性地从服务端获取到路况信息;在解析成功后,通过一定手段将这些信息匹配到数字地图上,例如预先与数字地图建立映射表,或者下发时提供足够的附加信息,然后在本地的地图进行模糊查找,更新对应的状态;在查询或显示时,根据之前保存的状态返回所需的结果。该方案把一部分工作分担到了客户端,解决了服务器端压力较大的问题,且服务端下发的只有路况数据,因此也节约了流量,缩短了响应时间。\n[0007] 但是,发明人在实现本发明的过程中,发现该方案具有如下缺点:\n[0008] 该方案中客户端需要携带复杂的、体积庞大的地图,动辄上百兆,这样使得地图的存储、下载都不方便,同时也会带来地图更新、升级等诸多难题,使得维护成本很大。\n发明内容\n[0009] 本发明实施例要解决的技术问题是:使客户端可以基于小数据量的地图显示路况。\n[0010] 本发明实施例提供了一种用于终端上显示路况的方法,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;所述方法包括以下步骤:\n[0011] 接收路段的路况数据;\n[0012] 根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;\n[0013] 从所述路况数据中,获得构成所述待显示道路的路段的路况状态;\n[0014] 根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;\n[0015] 在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0016] 优选的,根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路的步骤具体包括:\n[0017] 将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标;\n[0018] 根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。\n[0019] 优选的,在所述待显示道路上显示路况状态之前还包括:\n[0020] 将所述待显示道路上相连的且路况状态相同的路段进行合并。\n[0021] 优选的,根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路的步骤之前还包括:\n[0022] 对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标,进行偏移。\n[0023] 优选的,所述进行偏移之前还包括:\n[0024] 根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀。\n[0025] 本发明实施例还提供了一种用于终端上显示路况的装置,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;所述装置包括:\n[0026] 接收单元,用于接收路段的路况数据;\n[0027] 待显示道路获取单元,用于根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;\n[0028] 路况获取单元,用于从所述路况数据中,获得构成所述待显示道路的路段的路况状态;\n[0029] 道路绘制单元,用于根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;\n[0030] 路况显示单元,用于在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0031] 优选的,所述道路绘制单元具体包括:\n[0032] 坐标转换子单元,用于将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标;\n[0033] 绘制子单元,用于根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。\n[0034] 优选的,所述道路绘制单元还包括:\n[0035] 偏移子单元,用于对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标进行偏移,并在完成后通知所述绘制子单元。\n[0036] 优选的,所述道路绘制单元还包括:\n[0037] 抽稀子单元,用于在所述进行偏移之前根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀,并在完成后通知所述偏移子单元。\n[0038] 本发明实施例还提供了一种显示路况的终端,包括:\n[0039] 存储器:用于存储道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;\n[0040] 处理器:用于接收路段的路况数据;根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;从所述路况数据中,获得构成所述待显示道路的路段的路况状态;根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0041] 本发明实施例的方法、装置及设备,通过使用一种比现有地图体积更小的道路数据,在客户端实现了显示路况的功能,不但可以脱离现有地图、具有下载、升级方便的优点,而且也使得客户端资源开销减小,无论外存、内存或CPU的耗用都限定在很低的水平,便于在各类资源有限的瘦客户端上使用。\n附图说明\n[0042] 为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。\n[0043] 图1是本发明实施例一方法的流程示意图;\n[0044] 图2是本发明实施例二方法的流程示意图;\n[0045] 图3是实施例二中线参考与点参考的示意图;\n[0046] 图4是实施例二中线参考、点参考及坐标点的示意图;\n[0047] 图5是实施例二中生成道路数据时坐标偏移的示意图;\n[0048] 图6是实施例二中根据矩形区域查找线参考的示意图;\n[0049] 图7是实施例二中合并状态段的示意图;\n[0050] 图8是实施例二中剪裁矩形区域外坐标点的示意图;\n[0051] 图9是实施例二中转换为屏幕坐标时道路偏移处理的示意图;\n[0052] 图10是实施例二中转换为屏幕坐标时屏幕坐标抽稀处理的示意图;\n[0053] 图11是实施例三装置的示意图;\n[0054] 图12是实施例四设备的示意图。\n具体实施方式\n[0055] 下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。\n[0056] 实施例一\n[0057] 图1是本发明实施例一方法的流程图,用于终端上显示路况,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;包括以下步骤:\n[0058] S101:接收路段的路况数据;\n[0059] S102:根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;\n[0060] S103:从所述路况数据中,获得构成所述待显示道路的路段的路况状态;\n[0061] S104:根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;\n[0062] S105:在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0063] 实施例二\n[0064] 图2是本发明实施例二方法的流程示意图,包括:\n[0065] S201:预存道路数据。在本实施例中,需要预先在终端即客户端上存储所述道路数据。存储时可以是通过下载的方式存储和/或通过直接预装的方式存储。如果是下载的方式,由于所述道路数据的体积非常小,因此可在终端每次初始化程序时进行下载,以得到最新的道路数据,对于现有技术中体积庞大的地图来讲这一点是很难想象的。当然也可以在所述道路数据版本有更新后再下载,或者只下载增量包等。\n[0066] 在本实施例中,在终端(或称客户端)上存储所述道路数据之前,还需要有一个预处理过程,以得到所述道路数据。该预处理过程包括如下步骤:\n[0067] 第一,从地图上选取若干条道路,例如可以选取那些能够采集到路况的道路或者主干路。以下将这些被选取的道路称为线参考。参见图3所示,其中水平的道路与竖直的道路都被采集了路况信息,则在预处理时根据道路的名称或其他属性,将这两条道路分别作为两条线参考。\n[0068] 一条线参考上会有众多的点,参见图4。其中有的点可以用来代表线参考的形状及位置等,可称为坐标点或形状点,选取这些点作为第一类指定点。所述第一类坐标可以为基于所述地图平面坐标系的坐标或经纬度坐标。其中所述地图平面坐标系是指,以地图中的某点为原点(例如地图的中心点或左下角的点)建立平面直角坐标系(例如x轴平行于地图的长边、y轴平行于地图的宽边),则地图上所有的点都具有了x、y坐标。线参考上还有的点可以代表一些重要的节点或路口,可以选取这些点作为第二类指定点,以下将第二类指定点称为点参考,所述点参考将一条线参考分割成多个路段。\n[0069] 需要指出的是,在本实施例中,点参考与坐标点是互不相同的点,其各自职能不同:坐标点用来表示道路的坐标,以描绘道路的形状和位置,而点参考则用来表示道路上的路段,而所述路段是显示路况的基本单位。此外,在本实施例中为了便于区别及处理,给这些线参考及点参考都分配了唯一标识序号或称编号。参见图3所示,为两条线参考分别赋予线类型的编号L1、L2,为其上的点参考分别赋予点类型的编号P1、P2、P6、P7等。实际上这种划分道路的方法已经被整理成TMC规范,这种编号被称为位置码(LocationCode),因此上面线类型的编号与点类型的编号可分别称为线类型的位置码和点类型的位置码。当然,在本发明的其他实施例中,还可以用其他方式来标记这些线参考和点参考。图3中P1与P2之间的路段可以用P1—P2表示(不带方向时),或用P1→P2、P2→P1表示(带方向时)。\n[0070] 根据图3中各点参考的归属及顺序关系可以得到一个位置表,参见表1所示:\n[0071] 表1\n[0072] \n点参考的位置码 P1 P2 … P5 P6 P7 … P10\n所属的线参考 L1 L1 L1 L2 L2 L2\n前序点的位置码 NA P1 P4 NA P6 P9\n后序点的位置码 P2 P3 NA P7 P8 NA\n[0073] 表1中,将某点参考在所属的线参考上前面紧邻的点参考称为其前序点、后面紧邻的称为其后序点。所述前后可这样规定,即在正方向上,靠近起点的点参考在前面,远离起点的点参考在后面。一条线参考可以有正反两个方向,可以任意规定一个方向为线参考的正方向。\n[0074] 第二,将位置表处理成二进制文件,该文件中记录了点参考所属及前后关系数据。\n通过该文件,能够由任何一个点参考查询到它所属的线参考及前后关系。另外优选的,为了减少对内存的使用、提高前后点参考的查找效率,在得到该文件过程中可以对数据结构做一些优化处理,处理的方法如下:\n[0075] a)将点参考P1、P2、…、Pn按照编号的大小升序(或降序)排列,这样可以通过二分查找法迅速定位某个点参考在位置表中的序号,平均时间复杂度为Log2(n),这种方案无须任何附加索引,减少了内存占用。当然,如果十分讲究查询效率,也可以使用哈希表,但是需要为索引表分配额外的内存。\n[0076] b)前序点与后序点不直接记录位置码,而直接存其在位置表中的序号,例如:P1是位置表中第一条记录,因此序号为0,P2序号为1,P3序号为2,以此类推.,则P2的前序点序号为0,后序点序号为2,然后可以直接定位到这两条记录,无须再进行二分查找。\n[0077] 一个类似北京这样的城市,大约4000个左右的点参考便可以很好地覆盖城市的所有主要道路,按照上面的格式编译成二进制文件后,大约只需要30KB左右的空间。\n[0078] 第三、根据由位置表生成的二进制文件,并结合道路表和映射表,获得道路数据。\n其中道路表是描述线参考上各路段的属性以及形状的数据文件,包含很多属性字段,每一个字段能够表示路段的不同属性,例如表示路段的等级、路段的宽度、路段的长度、路段的用途等等,同时道路表中也包含路段的形状信息,即坐标点的第一类坐标信息。映射表是描述点参考与路段之间映射关系的表格文件。\n[0079] 道路数据中记载的信息可以参见表2和表3:\n[0080] 表2\n[0081] \n[0082] 其中,外接矩形是几何学中的一个基本概念,可根据如下方法获得(以直角坐标系为例):找到曲线上坐标点中的最大x坐标值和最小x坐标值,以及最大y坐标值和最小y坐标值,以上四个值所构成的矩形即该曲线的外接矩形。\n[0083] 表3\n[0084] \n点参考的位置码 P1 P2 P3 P4 P5 …\n在线参考正向坐标序列中的位置 0 5 9 11 18 \n在线参考反向坐标序列中的位置 19 14 9 6 0 \n到后序点经过的坐标点个数 5 4 2 7 0 \n到前序点经过的坐标点个数 0 5 5 3 6 \n[0085] 通过表3可以看出:在P1、P2等所在的L1中,正向坐标点序列中有18个坐标点,反向坐标序列中有19个坐标点(注意,线参考的正反向不一定对称,它们可能是两条车道,也可能是两条互逆的道路),参见图4,其中路段P1→P2有5个坐标点,P2→P3有4个坐标点,P3→P4有2个坐标点,P4→P5有7个坐标点,总计18个坐标点,可以从线参考的正向坐标序列中读出。路段P5→P4有6个坐标点,P4→P3有3个坐标点,P3→P2有5个坐标点,P2→P1有5个坐标点,总计19个坐标点,可以从线参考的反向坐标序列中读出。\n[0086] 为了达到较好的显示效果,在生成道路数据时可以进行如下处理:\n[0087] i)线参考的分级\n[0088] 分级是为了防止查询或显示时,所有道路都呈现出来,屏幕大小有限,如果显示道路过多,既降低了效率,也显得凌乱,因此在生成道路数据时对道路即线参考分别进行重要度的评估,使得终端可以在不同比例尺下选择合适的道路进行展示。\n[0089] ii)坐标点的抽稀\n[0090] 每条道路可能含有大量坐标点序列,但是在工程应用上,不一定需要这么多点,例如一条线段,理论上只需要两个端点坐标,中间其它的点都是无用的。因此,在生成道路数据时可以对道路的坐标序列进行抽稀,在保持道路轮廓的基础上去除意义不大的坐标点,以减小数据量。\n[0091] iii)坐标的偏移\n[0092] 在地图上有一种单线双向路,它的正向坐标与反向坐标序列在空间上镜像重叠的,如果不将其分离,则在描绘时必然叠在一起,导致被压盖的路况的无法呈现,因此,在生成道路数据时需要针对这种道路的坐标点做一个平移(按照中国的交通法则,沿行车方向将其右移1~2米即可),参见图5所示,图5中水平细线为偏移前的原道路,两条水平粗细为偏移后的两条单向道路。经过这种处理后,所有单线双向道路都成为了两条单向道路。\n[0093] 最终生成的道路数据的大小取决于道路的数量、长度与形状。以北京这样的大城市(约900多个线参考)为例,得到的道路数据大概为300~500KB,而一般的中型城市,大概在100~200KB之间,相比动辄上百兆的地图,数据量要小的多\n[0094] S202:创建空间索引。预存了道路数据后,可以在每次程序启动时根据所述道路数据中所述每条所述道路的外接矩形信息创建空间索引,以便于而后可以根据输入的区域和所述空间索引搜索到与该区域相交的线参考。空间索引是指依据空间对象的位置和形状或空间对象之间的某种空间关系按一定的顺序排列的一种数据结构。因为在获得道路数据时记录了每个线参考的外接矩形信息,因此可以使用RTree等空间索引树进行空间索引。\n本步骤为可选步骤,若使用其他非空间索引的方法根据输入的矩形区域获得第一道路集合时,可以不预先创建空间索引。\n[0095] S203:接收路段的路况数据。所述路况数据包含构成所述道路的路段的路况状态。\n在本实施例中,所述路况数据下发时的具体形式可以是“点参考+方向+步长+路况状态”,其中步长即所需要经过的点参考的个数。例如:“L1从P1开始,沿正方向两个步长拥堵”(即P1→P3的路段拥堵)、“在L2距离P7反向1步长处发生交通事故”等等,将这四个参数数字化后,只需要几个字节便能描述一条道路的路况,请求一个城市的所有主要道路的路况也只需要几十KB,相比每次请求图片大大减少了流量。\n[0096] 此外,终端接收路况数据的时机,可以是定期地接收和/或向服务器端发送请求后再接收被请求的路况数据。另外,所述路况数据可以是包含所有路段的路况数据,也可以是只包含部分路段的路况数据,例如定期更新路况数据时,终端第一次接收的路况数据包含所有道路的所有路段的路况状态,在此之后,终端可以向服务器端上传前一次的状态(如时间戳等),请求更新信息,服务器端只需要将自上次以来变化了的路况数据下发,即只下发那些路况有变化的道路的路段即可,从而进一步减少了交互的流量。\n[0097] S204:等待查询。即等待在终端输入一个矩形区域(或称矩形范围、搜索矩形),然后在终端查询该矩形区域内的路况。在本实施例中,该矩形区域与终端的屏幕相对应,当在终端屏幕上来回拖动查看时,相当于在不断输入不同的矩形区域,或者说是在不断的改变该矩形区域。在本发明其他实施例中,该区域也可以是用户在屏幕上指定或绘制的一个区域,形状可以是矩形或圆形等。\n[0098] S205:获得与输入矩形区域相交的线参考。即根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路。当输入一个矩形区域后,通过所述空间索引查找出所有与输入的矩形区域相交的线参考,待显示道路即这些相交的线参考,一般为一条或多条线参考,以下将这些查找到的线参考组成的集合称为第一道路集合。当然也可能没有找到与输入的矩形区域相交的线参考,此时可以提示用户或不进行任何处理。\n[0099] 如图6所示,A、B、C、D为四个线参考,使用它们的外接矩形插入RTree后,如果输入图6中矩形框所示的搜索矩形,则能很快查询出与其相交的线参考A、B、D,而其他的线参考(如C)则不会被列入结果集合中,即第一道路集合中,这样便减少了后续问题的处理规模,且能实现指定范围内路况信息的查询。\n[0100] S206:根据重要度过滤。本步骤为可选步骤。可以结合当前显示比例尺,根据重要度对第一道路集合中的线参考先进行一次过滤,将重要度不符合条件的线参考过滤掉。即,如果线参考的重要度达不到显示阈值,则不做后续处理(即不描画)。如果线路的重要度及显示阈值配置合理,可以保证每一级比例尺下显示的路段数都在相同的数据级,既提高了处理效率,也使得显示的层次更加分明。\n[0101] S207:获得路段对应的路况状态。即从所述路况数据中,获得构成所述待显示道路的路段的路况状态。在本实施例中,因为接收到的路况数据中已包含了所有路段的路况状态信息,因此可以获得第一道路集合中线参考上各路段对应的路况状态。\n[0102] S208:合并状态段。即将所述待显示道路上相连的且路况状态相同的路段进行合并。对于一个线参考,每个路段的路况状态都可能不同,但是如果两个连续路段的路况状态相同,则可以将其合并为一个状态段,以图7为例,线参考L1的正向可以划分为两个状态段:P1→P3为拥堵段,P3→P5缓行;反方向可以划分为三个状态段:P5→P4拥堵,P4→P2缓行,P2→P1畅通。注意该步骤为可选步骤,且该步骤的位置并不唯一,只要是在显示路况状态之前即可。\n[0103] S209:区域外剪裁。本步骤为可选步骤。由于第一道路集合中的线参考可能有一些坐标点在输入的矩形区域之外,所以可以将该矩形区域外的线段裁去,从而进一步减少坐标点及线段的个数,以减少资源占用并提高效率。裁剪的方式参见8图所示,从状态段的两端相向而行搜索,在一端每次选择两个相邻的点,检查它们组成的线段是否与该矩形相交或者被矩形包含,直至找到第一个与该矩形相交或者完全在矩形内的线段为止,之前的点都截去,最终只剩下图中实线上的坐标点。经过这一处理后,所有所述矩形区域外的线段都被滤除。\n[0104] S210:坐标转换。即,将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标。所述屏幕坐标是以屏幕中的某点(例如左上角)为原点、以像素为基本单位的直角坐标。在线参考被划分为状态段之后,可以根据状态段所包含的路段,从状态段所在线参考的坐标序列中获取对应的坐标点的第一类坐标(例如经纬度坐标),然后将其转换为屏幕坐标。\n[0105] S211:进行抽稀处理。本步骤为可选步骤。即,根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀。虽然在获得道路数据时已经进行过坐标抽稀(可称为一次抽稀),但那是针对第一类坐标的抽稀,如果一次抽稀的抽稀阈值设置得过大,则会损失路径质量,在屏幕上放大到最小比例尺时,显示的路径走样。但是,当比例尺很大时,一个像素可能就对应空间上几十米的距离,这是许多点就重合在一堆,一方面浪费了内存,另一方面会导致描绘出的线段抖动得厉害,所以在屏幕显示时可以对得到的屏幕坐标再进行抽稀(可称为二次抽稀),既节约了资源,也使得线段更加平滑。图10为未进行二次抽稀与进行了二次抽稀的对比效果图,可以看到二次抽稀后的线路更加平滑。\n[0106] S212:进行偏移处理。本步骤为可选步骤。即,对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标,进行偏移。在视野很大的界面下,道路在进行路况等交通信息展现的时候,两条道路会很近,由于屏幕分辨率有限,不同的第一类坐标转化为屏幕坐标后可能对应到同一像素,造成本来平行的道路重叠在一起,所以可以将原本平行的但转换为所述屏幕坐标之后重叠在一起的所述道路,进行偏移处理。偏移的算法与生成道路数据时类似,不过此处是基于屏幕坐标,偏移量以像素为单位,可以根据显示比例尺进行微调,实践证明,通过偏移后,平行道路可以被很好地显示,参见图9。当然,偏移处理也可以在二次抽稀的步骤之前。\n[0107] S213:绘制所述待显示道路。即根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。\n[0108] S214:显示路况。即,在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。例如根据拥堵状态如拥堵、缓行、畅通,将对应状态段描绘成红、黄、绿等颜色的线。\n[0109] 实施例三\n[0110] 图11是本发明实施例三装置的示意图,用于终端上显示路况,所述终端存储有道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;所述装置包括:\n[0111] 接收单元1101,用于接收路段的路况数据;\n[0112] 待显示道路获取单元1102,用于根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;\n[0113] 路况获取单元1103,用于从所述路况数据中,获得构成所述待显示道路的路段的路况状态;\n[0114] 道路绘制单元1104,用于根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;\n[0115] 路况显示单元1105,用于在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0116] 优选的,所述道路绘制单元1104具体包括:\n[0117] 坐标转换子单元,用于将所述待显示道路的第一类指定点的第一类坐标转换为屏幕坐标;\n[0118] 绘制子单元,用于根据所述待显示道路的第一类指定点的屏幕坐标,绘制所述待显示道路。\n[0119] 优选的,所述道路绘制单元1104还包括:\n[0120] 偏移子单元,用于对所述待显示道路中原本平行但转换为所述屏幕坐标之后重叠在一起的道路的第一类指定点的屏幕坐标进行偏移,并在完成后通知所述绘制子单元。\n[0121] 优选的,所述道路绘制单元1104还包括:\n[0122] 抽稀子单元,用于在所述进行偏移之前根据指定的抽稀阈值,对所述待显示道路的第一类指定点的屏幕坐标进行抽稀,并在完成后通知所述偏移子单元。\n[0123] 对于装置实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可\n[0124] 实施例四\n[0125] 图12是本发明实施例四设备的示意图,所述设备为一种用于显示路况的终端,包括:\n[0126] 存储器1201:用于存储道路数据,所述道路数据包括道路的外接矩形信息,道路的第一类指定点对应的第一类坐标,所述道路由路段构成;\n[0127] 处理器1202:用于接收路段的路况数据;根据输入的路况查询区域和所述道路数据中道路的外接矩形信息,从所述道路数据中获得与所述路况查询区域相交的待显示道路;从所述路况数据中,获得构成所述待显示道路的路段的路况状态;根据所述待显示道路的第一类指定点的第一类坐标,绘制所述待显示道路;在所述待显示道路上显示所述构成所述待显示道路的路段的路况状态。\n[0128] 对于设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。\n[0129] 需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。\n[0130] 本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于计算机可读取存储介质中,这里所称得的存储介质,如:ROM/RAM、磁碟、光盘等。\n[0131] 以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。
法律信息
- 2020-06-02
专利权的转移
登记生效日: 2020.05.13
专利权人由高德软件有限公司变更为阿里巴巴(中国)有限公司
地址由100080 北京市昌平区科技园区昌盛路8号B1座1-5层变更为310052 浙江省杭州市滨江区长河街道网商路699号4号楼5楼508室
- 2015-07-15
- 2013-11-13
实质审查的生效
IPC(主分类): G08G 1/0967
专利申请号: 201110460387.5
申请日: 2011.12.31
- 2013-07-03
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| | 暂无 |
2010-12-13
| | |
2
| |
2009-12-23
|
2008-06-18
| | |
3
| |
2008-04-02
|
2007-07-20
| | |
4
| |
2010-09-29
|
2010-05-11
| | |
5
| |
2010-05-19
|
2009-11-30
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |